Albert Beukman

Forum Replies Created

Viewing 18 posts - 1 through 18 (of 18 total)
  • Author
    Posts
  • in reply to: Accessing Conduit (MTCDT-LAT1-246A-US) remotely over cellular #22599
    Albert Beukman
    Participant

    I had a similar issue even with a public IP SIM. Seems some ISPs block remote terminated connections of specific protocols for specific IP ranges.

    Unable to use HTTP config UI on MTCDT-LVW2-247A v1.4.3 via WAN static IP

    Kind regards,
    Albert

    Albert Beukman
    Participant

    Finally got to the bottom of this.

    Suspect certain ISPs block remote terminated connections of certain protocols (HTTP and SSH in this case) for certain IP ranges. The public static IP block the mobile ISP assigned in the last instance seemed to have been blocked by at least T-mobile and AT&T.

    GUI accessibility tests with IP assigned in the last instance.
    * Verizon. OK
    * Comcast. OK
    * T-Mobile. Fail
    * AT&T. Fail

    Known good SIM mentioned above succeeded in all instances.

    ISP allocated a new IP address in a different subnet, after which the GUI was accessible on the public static IP on at least Verizon, Comcast and AT&T.

    Hope this helps someone.

    Kind regards.

    Albert Beukman
    Participant

    This seems to be a SIM issue. Suspect issue with remote terminated connections.

    I pulled a known good SIM from the field.
    * The known good SIM allows HTTP connections on all 3 devices tested (2x 210Av1.3.2; 1x 247A v1.4.3).
    * The recently provisioned SIM does not allow HTTP connections on any of the devices tested.

    Waiting to hear back from service provider for specific feedback on what is wrong with this SIM and how to prevent it in the future.

    Albert Beukman
    Participant

    Done. Thanks Jeff.

    Kind regards.

    Albert Beukman
    Participant

    Spoke with cellular service provider.

    It is a public, static IP. There are no restrictions on their side on this line. They even performed a network reset, forcing the device to register again (at which time I did a power-on reset for good measure). This had no effect and I was able to recreate my original results.

    * Confirmed PPP link up and good signal.
    * UDP traffic on custom ports OK.
    * Ping from my PC OK.
    * LAN access OK.
    * HTTP fail.
    * HTTP from cell phone fail.
    * HTTP to Node-Red UI fail.
    * SSH fail.

    Please advise.

    Albert Beukman
    Participant

    Hi Jeff;

    Thanks for the response. Yes, my apologies for not being clearer; this is what I meant with “Remote Access Management is enabled for all WAN config interfaces” and “Redirect to HTTPS has no effect”.

    I.e. I have tried accessing the HTTP UI with the permutations shown below with “Via WAN” ticked under Administration->Access Configuration for the following.
    * Web-Server – HTTPS.
    * SSH.
    * ICMP.
    * Node-Red.

    Permutation 1: HTTP Redirect to HTTPS “Via WAN” ticked. FAIL.
    Permutation 2: HTTP Redirect to HTTPS “Via WAN” not ticked. FAIL.

    The Detail section in my original post holds for both permutations above.

    Kind regards,
    Albert

    in reply to: MQTT traffic but no Node-Red LoRa Net NODE traffic #22315
    Albert Beukman
    Participant

    Upgraded the LNS to v1.0.43.

    Was unable to recreate using Conduit MTCDT-LVW2-247A v1.4.3 and LNS v1.0.43. Attempted to increase traffic as this tended to correlate with the symptom reported above (using LNSv1.0.31).

    Possible contributors from LNS change logs (http://www.multitech.net/developer/software/mlinux/lora-network-server-changelog/).
    * Bug (known issue) in v1.0.31 (came by default) : Downlink will not be scheduled with uplink counter rolls over 16-bit max
    ** v1.0.26 good version
    ** > v1.0.32 good version.
    * Bug (known issue) in v1.0.37. Multiple packets for first downlink to set end-device channels and datarates through ADR or AddChannel commands may be scheduled multiple times. Downlink packets will not be cleared until ACK’d by end-device
    ** > v1.0.41 bug fix : Only one packet will be scheduled with Channel Mask or Additional Channels in first downlink. This packet will be sent until device ACK’s receipt.

    in reply to: RN2903A based device does not join (OTAA) Conduit AP anymore #22299
    Albert Beukman
    Participant

    Worked with Multitech support and posting some details in case the next developer runs into the same issue.

    Attempted solutions
    They suggested I try to manaully reset the packet forwarded (“Packet forwarder not seen” debug). This might work for the next reader of this post, but did not work for me; I got a segmentation fault. Sending hardware back to Multitech for investigation.

    Suggested course of action if you’re experiencing the same issue: Contact Multitech Support directly.

    Expected terminal commands & output

    admin@mtcap:~# ps auxw | grep lora
    admin      344  0.2  0.4   2632  1140 ?        S    Jan05   8:47 /bin/bash /usr/sbin/lora-led-updater
    admin     1907  0.0  0.1   1912   408 ?        S    Jan05   0:04 /sbin/angel /opt/lora/lora-network-server -c /var/config/lora/lora-network-server.conf --lora-eui 00:80:00:00:00:00:F0:B6 --lora-hw-1 MTCAP-LORA-1.5 --lora-prod-1 MTCAP-LORA-868 --lora-path /var/run/lora --db /var/config/lora/lora-network-server.db --noconsole
    admin     1909  1.0  1.4  17348  3608 ?        S<l  Jan05  44:18 /opt/lora/lora-network-server -c /var/config/lora/lora-network-server.conf --lora-eui 00:80:00:00:00:00:F0:B6 --lora-hw-1 MTCAP-LORA-1.5 --lora-prod-1 MTCAP-LORA-868 --lora-path /var/run/lora --db /var/config/lora/lora-network-server.db --noconsole
    admin     1928  0.0  0.1   1912   408 ?        S    Jan05   0:04 /sbin/angel /var/run/lora/1/lora_pkt_fwd
    admin     1929  2.9  0.3  35436   960 ?        S<l  Jan05 125:57 /var/run/lora/1/lora_pkt_fwd
    admin    19680  0.0  0.2   2980   584 pts/0    S+   15:33   0:00 grep lora
    admin@mtcap:~# kill 1928
    admin@mtcap:~# ps auxw | grep lora
    admin      344  0.2  0.4   2632  1140 ?        S    Jan05   8:47 /bin/bash /usr/sbin/lora-led-updater
    admin     1907  0.0  0.1   1912   408 ?        S    Jan05   0:04 /sbin/angel /opt/lora/lora-network-server -c /var/config/lora/lora-network-server.conf --lora-eui 00:80:00:00:00:00:F0:B6 --lora-hw-1 MTCAP-LORA-1.5 --lora-prod-1 MTCAP-LORA-868 --lora-path /var/run/lora --db /var/config/lora/lora-network-server.db --noconsole
    admin     1909  1.0  1.4  17348  3608 ?        S<l  Jan05  44:20 /opt/lora/lora-network-server -c /var/config/lora/lora-network-server.conf --lora-eui 00:80:00:00:00:00:F0:B6 --lora-hw-1 MTCAP-LORA-1.5 --lora-prod-1 MTCAP-LORA-868 --lora-path /var/run/lora --db /var/config/lora/lora-network-server.db --noconsole
    admin     1928  0.0  0.1   1912   412 ?        S    Jan05   0:04 /sbin/angel /var/run/lora/1/lora_pkt_fwd
    admin    20076  0.0  0.2   2980   584 pts/0    S+   15:37   0:00 grep lora
    admin@mtcap:~# kill 1928
    -bash: kill: (1928) - No such process
    admin@mtcap:~# ps auxw | grep lora
    admin      344  0.2  0.4   2632  1140 ?        S    Jan05   8:48 /bin/bash /usr/sbin/lora-led-updater
    admin     1907  0.0  0.1   1912   408 ?        S    Jan05   0:04 /sbin/angel /opt/lora/lora-network-server -c /var/config/lora/lora-network-server.conf --lora-eui 00:80:00:00:00:00:F0:B6 --lora-hw-1 MTCAP-LORA-1.5 --lora-prod-1 MTCAP-LORA-868 --lora-path /var/run/lora --db /var/config/lora/lora-network-server.db --noconsole
    admin     1909  1.0  1.4  17348  3608 ?        S<l  Jan05  44:21 /opt/lora/lora-network-server -c /var/config/lora/lora-network-server.conf --lora-eui 00:80:00:00:00:00:F0:B6 --lora-hw-1 MTCAP-LORA-1.5 --lora-prod-1 MTCAP-LORA-868 --lora-path /var/run/lora --db /var/config/lora/lora-network-server.db --noconsole
    admin    20154  0.0  0.2   2980   584 pts/0    S+   15:37   0:00 grep lora
    admin@mtcap:~# cd /var/run/lora/1
    admin@mtcap:/var/run/lora/1# ./lora_pkt_fwd 
    *** Beacon Packet Forwarder for Lora Gateway ***
    Version: 3.1.0
    *** Lora concentrator HAL library version info ***
    Version: 4.1.3;
    ***
    INFO: Little endian host
    INFO: found global configuration file global_conf.json, parsing it
    INFO: global_conf.json does contain a JSON object named SX1301_conf, parsing SX1301 parameters
    INFO: lorawan_public 1, clksrc 0
    lgw_board_setconf:397: Note: board configuration; lorawan_public:1, clksrc:0
    INFO: LBT is disabled
    INFO: antenna_gain 0 dBi
    INFO: Configuring TX LUT with 16 indexes
    INFO: radio 0 enabled (type SX1257), center frequency 868500000, RSSI offset -162.000000, tx enabled 1, tx_notch_freq 129000
    lgw_rxrf_setconf:458: Note: rf_chain 0 configuration; en:1 freq:868500000 rssi_offset:-162.000000 radio_type:2 tx_enable:1 tx_notch_freq:129000
    INFO: radio 1 enabled (type SX1257), center frequency 869400000, RSSI offset -162.000000, tx enabled 0, tx_notch_freq 0
    lgw_rxrf_setconf:458: Note: rf_chain 1 configuration; en:1 freq:869400000 rssi_offset:-162.000000 radio_type:2 tx_enable:0 tx_notch_freq:0
    INFO: Lora multi-SF channel 0>  radio 0, IF -400000 Hz, 125 kHz bw, SF 7 to 12
    lgw_rxif_setconf:577: Note: LoRa 'multi' if_chain 0 configuration; en:1 freq:-400000 SF_mask:0x7e
    INFO: Lora multi-SF channel 1>  radio 0, IF -200000 Hz, 125 kHz bw, SF 7 to 12
    lgw_rxif_setconf:577: Note: LoRa 'multi' if_chain 1 configuration; en:1 freq:-200000 SF_mask:0x7e
    INFO: Lora multi-SF channel 2>  radio 0, IF 0 Hz, 125 kHz bw, SF 7 to 12
    lgw_rxif_setconf:577: Note: LoRa 'multi' if_chain 2 configuration; en:1 freq:0 SF_mask:0x7e
    INFO: Lora multi-SF channel 3>  radio 0, IF 300000 Hz, 125 kHz bw, SF 7 to 12
    lgw_rxif_setconf:577: Note: LoRa 'multi' if_chain 3 configuration; en:1 freq:300000 SF_mask:0x7e
    INFO: Lora multi-SF channel 4>  radio 1, IF -400000 Hz, 125 kHz bw, SF 7 to 12
    lgw_rxif_setconf:577: Note: LoRa 'multi' if_chain 4 configuration; en:1 freq:-400000 SF_mask:0x7e
    INFO: Lora multi-SF channel 5>  radio 1, IF 125000 Hz, 125 kHz bw, SF 7 to 12
    lgw_rxif_setconf:577: Note: LoRa 'multi' if_chain 5 configuration; en:1 freq:125000 SF_mask:0x7e
    INFO: Lora multi-SF channel 6>  radio 1, IF 400000 Hz, 125 kHz bw, SF 7 to 12
    lgw_rxif_setconf:577: Note: LoRa 'multi' if_chain 6 configuration; en:1 freq:400000 SF_mask:0x7e
    INFO: Lora multi-SF channel 7 disabled
    lgw_rxif_setconf:485: Note: if_chain 7 disabled
    INFO: Lora std channel> radio 0, IF -200000 Hz, 250000 Hz bw, SF 7
    lgw_rxif_setconf:551: Note: LoRa 'std' if_chain 8 configuration; en:1 freq:-200000 bw:2 dr:2
    INFO: FSK channel> radio 0, IF 300000 Hz, 125000 Hz bw, 50000 bps datarate
    lgw_rxif_setconf:607: Note: FSK if_chain 9 configuration; en:1 freq:300000 bw:3 dr:50000 (50000 real dr) sync:0xC194C1
    INFO: global_conf.json does contain a JSON object named gateway_conf, parsing gateway parameters
    INFO: gateway MAC address is configured to 008000000000F0B6
    INFO: server hostname or IP address is configured to "127.0.0.1"
    INFO: upstream port is configured to "1780"
    INFO: downstream port is configured to "1782"
    INFO: downstream keep-alive interval is configured to 10 seconds
    INFO: statistics display interval is configured to 20 seconds
    INFO: upstream PUSH_DATA time-out is configured to 120 ms
    INFO: packets received with a valid CRC will be forwarded
    INFO: packets received with a CRC error will NOT be forwarded
    INFO: packets received with no CRC will NOT be forwarded
    INFO: FPGA supported features: [TX filter]  [Spectral Scan] 
    lgw_start:793: Note: calibration started (time: 2300 ms)
    lgw_start:814: Note: calibration finished (status = 191)
    Info: Initialising AGC firmware...
    Info: putting back original RADIO_SELECT value
    INFO: [main] concentrator started, packet can now be received
    
    INFO: Disabling GPS mode for concentrator's counter...
    INFO: host/sx1301 time offset=(1515425896s:885569µs) - drift=-1773900479µs
    INFO: Enabling GPS mode for concentrator's counter.
    
    INFO: [down] PULL_ACK received in 0 ms
    lgw_receive:1125: FIFO content: 1 10 0 5 12
    lgw_receive:1144: [2 17]
    Note: LoRa packet
    
    INFO: Received pkt from mote: 00DD0006 (fcnt=7973)
    
    JSON up: {"rxpk":[{"tmst":7633388,"chan":2,"rfch":0,"freq":868.500000,"stat":1,"modu":"LORA","datr":"SF8BW125","codr":"4/5","lsnr":4.0,"rssi":-89,"size":18,"data":"QAYA3QAAJR8B60z5DS+SK3/C"}]}
    lgw_receive:1125: FIFO content: 1 32 0 5 12
    lgw_receive:1144: [1 17]
    Note: LoRa packet

    Segmentation fault commands & output

    admin@mtcap:/var/log# ps auxw | grep lora
    admin      330  0.2  0.4   2632  1140 ?        S    Jan03   6:04 /bin/bash /usr/sbin/lora-led-updater
    admin    29747  2.0  0.2   2980   584 pts/0    S+   11:53   0:00 grep lora
    admin@mtcap:/var/log# cd /var/run/lora/l/
    -bash: cd: /var/run/lora/l/: No such file or directory
    admin@mtcap:/var/log# cd /var/run/lora/1/
    admin@mtcap:/var/run/lora/1# ./lora_pkt_fwd
    *** Beacon Packet Forwarder for Lora Gateway ***
    Version: 3.1.0
    Segmentation fault
    admin@mtcap:/var/run/lora/1# ps auxw | grep lora
    admin      330  0.2  0.4   2632  1140 ?        S    Jan03   6:04 /bin/bash /usr/sbin/lora-led-updater
    admin    30020  0.0  0.2   2980   584 pts/0    S+   11:56   0:00 grep lora

    EDIT: Fix second code block
    EDIT: Try to fix post to show both code blocks reliably.

    • This reply was modified 6 years, 10 months ago by Albert Beukman. Reason: Fix second code block
    • This reply was modified 6 years, 10 months ago by Albert Beukman.
    in reply to: RN2903A based device does not join (OTAA) Conduit AP anymore #22298
    Albert Beukman
    Participant

    Additional detail Multitech Support requested requested as follows for the reader of this article’s reference.
    * Did not reconfigure the for ABP during manual add process – was throwing the kitchen sink at the problem at this stage.
    * Experimental setup did change slightly between join and not join. Change deemed to be negligible as it was approx. 0.002 of observed effective end-device range. (e.g. if we’ve established reliable 1000 ft range, relative position changed by approximately 2 feet).
    * We do not have Multitech end-devices to test with.
    * I believe there is a firmware update available for the Microchip device. That being said, I’d still appreciate attention to the posted logs.
    ** Downgrading the Lora Network Server (LNS) did not have an effect. If it was a later conformancy issue, I’d expect join with earlier LNS versions.
    * I don’t have access / tools to RN2903A logs / terminal output at the moment. Will try to get these if at all possible.

    in reply to: ABP on AEP #22210
    Albert Beukman
    Participant

    Regarding the API not executing.

    Quotes copied from forum was generating the error. Pasting config into a JSON formatting tool found the issue (Google “JSON Formatter”)

    Hoping code block takes out special quote formatting:
    https://<IP-address>/api/loraNetwork?method=PUT&data={"lora":{"enableStrictCounterValidation":false}}&apply=now

    If not, copy the URL into a text editor and replace quotes by typing them. Should do the trick.

    in reply to: ABP on AEP #22206
    Albert Beukman
    Participant

    I got the same thing as Arturo above submitting.

    https://<IP-address>/api/loraNetwork?method=PUT&data={“lora”:{“enableStrictCounterValidation”:false}}&apply=now

    Also tried editing /var/config/lora-network-server.conf but the changes get reverted every time I start the network server.

    MTCAP-LNA3-915-001A Firmware1.4.4
    LNSv1.0.41

    EDIT
    POST API executes successfully (confirming I’m logged in and API should be OK)
    https://<IP-address>/api/command/save?method=POST

    EDIT
    Correction on Conduit model.

    in reply to: IPv6 support for cell interface #17880
    Albert Beukman
    Participant

    Hi Mike;

    Indeed. My apologies for the vagueness.

    Primarily the MTCDT-LVW2-210A-US as it’s Verizon that’s going to stop handing out static IPv4 addresses.

    Secondarily. MTCDT-H5-210A-US-EU-GB in case other cell providers follow suit.

    Kind regards,
    Albert

    in reply to: 2 way communication failure after AEP update to v1.3.2 #15338
    Albert Beukman
    Participant

    Thanks for following up Steve;

    Confirmed with embedded engineer that he was waiting for mac_tx_ok after 2nd up-link, but never receiving it. This was preventing the embedded application from continuing normal operation – and consequently creating the impression of a broken 2-way link.

    RN2903 output
    (A) Output where tx confirmed and no downlink pending.

    mac tx cnf 160 0205040302 [len=25]
    <20161014120058.632 RX>
    ok [len=2]
    <20161014120100.102 RX>
    mac_tx_ok [len=9]
    <20161014120101.194 RX>

    (B) Output where down-link pending

    mac tx cnf 160 0205040302 [len=25]
    <20161014120230.628 RX>
    ok [len=2]
    <20161014120232.133 RX>
    mac_rx 160 006900 [len=17]

    Confirmed with Multitech support (from raw data in network server logs) that the up-link confirmation(/ack) was not sent by the network server because said up-link was set as unconfirmed.

    Although inconsequential now, I presume the unconfirmed 2nd up-link was ACK’d by network server in 1.2.2.

    This situation is now handled in the firmware application and 2-way communication works as before.

    Kind regards.

    in reply to: 2 way communication failure after AEP update to v1.3.2 #15091
    Albert Beukman
    Participant

    Resolution on initial hypothesis. Down-link is reaching network server and end-device; Confirmed by embedded engineer. Network server log extract below.

    18:20:32:905|TRACE|MQTT message: lora/<EUI>/down
    18:20:32:906|TRACE|SQL query = SELECT address FROM nodes WHERE deveui = <EUI>;
    18:20:32:907|DEBUG|Mosquitto command received ‘down’
    18:20:32:908|DEBUG|Use port 160
    18:20:32:908|DEBUG|app data size 0
    18:20:32:908|INFO|Queue app data 3 bytes
    18:20:32:908|INFO|Scheduled 4 bytes payload

    Apparent absent up-link confirmation when down-link pending still being investigated.

    in reply to: 2 way communication failure after AEP update to v1.3.2 #15066
    Albert Beukman
    Participant

    Endpoint device using Microchip RN2903.

    Embedded engineer states that when a down-link is pending, network server is not sending ACK to uplink as it did with v1.2.2.

    Microchip feedback:
    Check the Network Server log file on the Conduit and see what it is trying to send out the gateway. If the Network Server is not sending the ACK, that is an error in MultiTech’s new software

    Opened up a support ticket with Multitech.

    Albert Beukman
    Participant

    Worked like a treat, thanks Jason.

    Enabled the Network Server Conduit’s public interface with the API request found at your link (included below) and verified by checking /var/config/lora/lora-network-server.conf after a Conduit restart.

    https://<AEP-IP>/api/loraNetwork?method=PUT&data={"udp":{"allowPublic":true}}

    Curious that this setting is not exposed in the UI.

    in reply to: Get/Set Network Server configuration in Node-Red #11969
    Albert Beukman
    Participant

    Jeff;

    No cigar yet on the PUT/POST request.

    I’ve tried 2 basic approaches without success and posted my results below. I’d appreciate input.

    Node-Red setup as Inject-Function-HTTP Request-Debug. Function block setup and Debug output shown below.

    Approach 1

    var vUsername = "admin";
    var vPassword = "password";
    var vAuthHeader = vUsername + ":" + vPassword;
    
    var vPayload = {"rx2Datarate" : 10};
    
    msg.headers = {"Authorization": "Basic " + vAuthHeader.toString('base64') };
    msg.method = "PUT";
    msg.url = "https://127.0.0.1/api/loraNetwork/lora/";
    msg.payload = vPayload;
    
    return msg;

    Output 1
    { "topic": "", "payload": "{\n \"code\" : 400,\n \"error\" : \"[rx2Datarate] property is not set\",\n \"status\" : \"fail\"\n}\n", "_msgid": "b29428dc.4d6bd8", "headers": { "cache-control": "no-cache", "content-type": "application/json", "transfer-encoding": "chunked", "date": "Mon, 28 Mar 2016 19:28:07 GMT", "server": "rcell" }, "method": "PUT", "url": "https://127.0.0.1/api/loraNetwork/lora/", "statusCode": 400 }

    Approach 2

    var vPayload = "10";
    //Same Auth header construction as approach 1
    msg.headers = {"Authorization": "Basic " + vAuthHeader.toString('base64') };
    msg.method = "PUT";
    msg.url = "https://127.0.0.1/api/loraNetwork/lora/rx2Datarate";
    msg.payload = vPayload;
    
    return msg;

    Output 2
    { "topic": "", "payload": "{\n \"code\" : 400,\n \"error\" : \"path [loraNetwork] leads to an incompatible element. Path Element Type [OBJECT] Update Data Element Type [NULL]\",\n \"status\" : \"fail\"\n}\n", "_msgid": "afd2e493.502d18", "headers": { "cache-control": "no-cache", "content-type": "application/json", "transfer-encoding": "chunked", "date": "Mon, 28 Mar 2016 19:30:55 GMT", "server": "rcell" }, "method": "PUT", "url": "https://127.0.0.1/api/loraNetwork/lora/rx2Datarate", "statusCode": 400 }

    Exchanging the PUT with POST leads to different feedback, but failures nonetheless.

    • This reply was modified 8 years, 8 months ago by Albert Beukman. Reason: Pedantic. Fix comment in approach 2
    • This reply was modified 8 years, 8 months ago by Albert Beukman. Reason: Fix changed formatting after edit
    in reply to: Get/Set Network Server configuration in Node-Red #11968
    Albert Beukman
    Participant

    Thanks Jeff

    The GET works like a treat. I will try the PUT next.

    For forum reference, the Node-Red HTTP request node allows for basic authentication, which makes for a very simple flow when retrieving a param. You can also build these credentials up in the header as below.

    var vUsername = "username";
    var vPassword = "password";
    var vHeader = vUsername + ":" + vPassword;

    msg.headers = {"Authorization": "Basic " + vHeader.toString('base64') };
    msg.method = "GET";
    msg.url = "https://127.0.0.1/api/loraNetwork/lora/rx2Datarate";

    return msg;

Viewing 18 posts - 1 through 18 (of 18 total)