Albert Beukman
Forum Replies Created
-
AuthorPosts
-
February 15, 2018 at 1:09 pm in reply to: Accessing Conduit (MTCDT-LAT1-246A-US) remotely over cellular #22599Albert BeukmanParticipant
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,
AlbertJanuary 24, 2018 at 8:41 pm in reply to: Unable to use HTTP config UI on MTCDT-LVW2-247A v1.4.3 via WAN static IP #22477Albert BeukmanParticipantFinally 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. FailKnown 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.
January 18, 2018 at 1:59 pm in reply to: Unable to use HTTP config UI on MTCDT-LVW2-247A v1.4.3 via WAN static IP #22393Albert BeukmanParticipantThis 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.
January 16, 2018 at 10:10 am in reply to: Unable to use HTTP config UI on MTCDT-LVW2-247A v1.4.3 via WAN static IP #22351Albert BeukmanParticipantDone. Thanks Jeff.
Kind regards.
January 15, 2018 at 3:52 pm in reply to: Unable to use HTTP config UI on MTCDT-LVW2-247A v1.4.3 via WAN static IP #22343Albert BeukmanParticipantSpoke 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.
January 15, 2018 at 11:20 am in reply to: Unable to use HTTP config UI on MTCDT-LVW2-247A v1.4.3 via WAN static IP #22331Albert BeukmanParticipantHi 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,
AlbertAlbert BeukmanParticipantUpgraded 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.January 10, 2018 at 11:09 am in reply to: RN2903A based device does not join (OTAA) Conduit AP anymore #22299Albert BeukmanParticipantWorked 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.
January 10, 2018 at 11:06 am in reply to: RN2903A based device does not join (OTAA) Conduit AP anymore #22298Albert BeukmanParticipantAdditional 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.Albert BeukmanParticipantRegarding 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.
Albert BeukmanParticipantI 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.41EDIT
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.- This reply was modified 6 years, 11 months ago by Albert Beukman.
- This reply was modified 6 years, 11 months ago by Albert Beukman.
Albert BeukmanParticipantHi 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,
AlbertNovember 3, 2016 at 5:05 pm in reply to: 2 way communication failure after AEP update to v1.3.2 #15338Albert BeukmanParticipantThanks 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.
October 18, 2016 at 5:09 pm in reply to: 2 way communication failure after AEP update to v1.3.2 #15091Albert BeukmanParticipantResolution 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 payloadApparent absent up-link confirmation when down-link pending still being investigated.
October 17, 2016 at 4:27 pm in reply to: 2 way communication failure after AEP update to v1.3.2 #15066Albert BeukmanParticipantEndpoint 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 softwareOpened up a support ticket with Multitech.
July 19, 2016 at 11:35 am in reply to: No output on Conduit packet forwarder to Conduit Network Server setup #14244Albert BeukmanParticipantWorked 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.
Albert BeukmanParticipantJeff;
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
Albert BeukmanParticipantThanks 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;
-
AuthorPosts