[Mikael Grah]

Yes, that solved the issue, and the log clearly shows what happened. Great, thank you!

Mar 12 10:53:27 mtcdt user.info lora-network-server: GW:00:80:00:00:00:00:9a:6c|FRAME-RX|Parsing 2 packets
Mar 12 10:53:27 mtcdt user.warn lora-network-server: Removed duplicate packet received on wrong channel, end-device may be operating close to gateway
Mar 12 10:53:27 mtcdt user.warn lora-network-server: Performing lazy check of counter, replay attack possible
Mar 12 10:53:27 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|CHECK-PKT|FCNT: 00000001 LAST-FCNT: 00000000 Duplicate: no

[Mikael Grah]

As a follow-up issue; when communication is lost I try to recover by setting the ulc to 0 in the mDot (at+ulc=0), if that doesn’t work I follow up by setting it to 1, in order to assure that it isn’t 0 repeatedly. I then save the session, wait a short period of time and shut down the modem.

Now, after issuing at+ulc=1 directly followed by at+ss followed by a 2 second “safety delay” before shutting down, it seems that the next cycle (“at+rs”) restores a state where the ulc=0. (at+ulc returns 0 OK)

Seems odd, doesn’t it?

[Mikael Grah]

Hi,

Thank you, that seems to be the issue. It’s funny, though, I started without the ss/rs and didn’t get it to work properly. For some reason or other it worked once in a while when I started using ss/rs (probably when I had the demo running several iterations in the loop.

Anyhow, I’ll verify for sure when I get the time but my initial tests show that this was indeed the case… Or at least I can easily reproduce the error with the standalone equipment right now.

From my view it was difficult to catch the gateway-side bug, I started to assume that there was a bug in the mDot/xDot AT Firmware… 😎

[Mikael Grah]

OK, so I tried the same thing with an xDot (MTMDK-) FW 3.0.0 and basically the same thing happens. Communication works, but after a reset the FCNT seem to be off:

Feb 20 11:53:14 mtcdt user.info lora-network-server: GW:00:80:00:00:00:00:9a:6c|FRAME-RX|Parsing 1 packets
Feb 20 11:53:14 mtcdt user.info lora-network-server: ED:00-80-00-00-04-00-03-49|CHECK-PKT|FCNT: 000000e2 LAST-FCNT: 00000000 Duplicate: yes

The first send fails with the log above. However, if I wait for the next transmit window, communication works as I expect:

Feb 20 11:56:03 mtcdt user.info lora-network-server: ED:00-80-00-00-04-00-03-49|CHECK-PKT|FCNT: 00000001 LAST-FCNT: 00000000 Duplicate: no

Another reset (atz) followed by at+ulc and at+dlc to verify that the counters are at 0 works:

Feb 20 11:57:49 mtcdt user.info lora-network-server: ED:00-80-00-00-04-00-03-49|CHECK-PKT|FCNT: 00000000 LAST-FCNT: 00000001 Duplicate: no

Yet another reset (atz) and an immediate send (without checking the counters):

Feb 20 11:59:15 mtcdt user.info lora-network-server: ED:00-80-00-00-04-00-03-49|CHECK-PKT|FCNT: b6c345cc LAST-FCNT: 00000000 Duplicate: yes

Reset + check counters (both 0) and now I get:

Feb 20 12:00:53 mtcdt user.info lora-network-server: ED:00-80-00-00-04-00-03-49|CHECK-PKT|FCNT: 000000e2 LAST-FCNT: 00000000 Duplicate: yes

Working with save/restore session seems to work better, but it doesn’t seem to work all the time. And if save/restore makes it work, why doesn’t my first implementation work?

And still… What causes the counters to report 0 even if the actual FCNT is not 0 when I try to send?

What am I missing?

• This reply was modified 6 years, 2 months ago by Mikael Grah.

[Mikael Grah]

Hi,

Just wanted to thank you for this topic, it helped solve an issue for me as well. I was trying to get a mDot to communicate with an AEP Conduit using ABP. I suspected the counter for a long time, but was not able to find a solution/description of how to configure the Conduit (and mDot) properly.

After reading this discussion, I’m curious about how to assure that the counters are working properly? Especially when having multiple Conduits that may be in range (or when moving between multiple conduits).

Are there any online resources describing this?

Best regards, and a happy new year to all of you!
/M

[Mikael Grah]

Thank you, that was indeed the cause.

For some reason the init.d-script overwrites the /etc/ssh/sshd_config file with the contents of /var/config/ssh/sshd_config (with some modifications) as part of the start process.

[Mikael Grah]

Hi Jeff,

Thanks for the reply. I realize that my post was a bit unclear; I uncommented the lines (removed the #’s) but when I reconnected the lines were still commented out.

I can see some of my other configuration changes in the file, changes I’ve made in the GUI, such as chaning the SSH port. Maybe there’s an automatic reqrite of the file at some point in time, for instance when I’m applyin other changes in the Remote Access configuration…

/M

[Mikael Grah]

I was just about to register the support case when the same thing happened to one of the other gateways, this time I knew exactly what happened…

I had just changed the https port on the devices. This turned out to be the problem all along. Once I realized the issue, I checked the authentication script for Node-Red and realized that it uses the https-interface to authenticate the user.

Maybe this could help someone else in the future… 🙂

Thank you for your support!

[Mikael Grah]

OK, so I finally got around to do a factory reset. All the Node-Red schematics were removed (naturally), the login credentials etc. were reset, but the DeviceHQ credentials were still registered. I assume that’s normal.

However I found another problem – I can’t log in via LAN either. I assume this was the case earlier as well… Is there another way to set (or reset) the credentials for Node-Red only?

[Mikael Grah]

Upgraded to the latest Firmware (1.4.3), that didn’t change much. I will try a factory reset later on.

[Mikael Grah]

OK, thanks. I’ll try doing a factory reset once the project is in a phase where we can experiement. I think that I’ve had the same issue with another unit as well, however that unit is in a position where we cannot experiment with it.

Anyway, I’ll try factory reset on this one and get back with the results (as soon as I get the time).

Thank you once again,
/Mikael

[Mikael Grah]

Thank you, Steve!

However, I’ve done all this, I have full access to the Conduit using both the web interface and ssh. Accessing port 1880 (https) gives me the regular Node-Red login dialogue (website), but I get “Login Failed” after entering the credentials. The same credentials work for the web interface and for ssh access and for Node-Red when I’m connnecting via LAN.

If I disable the Node-Red via WAN checkbox the conduit do not respond at all to (https://IPADDRESS:1880).

Are there any other logs to check or things I could try?

Best regards,
/M

EDIT:
Conduit version: MTCDT-H5-210A
Firmware: MTCDT 1.3.3

• This reply was modified 6 years, 7 months ago by Mikael Grah.

[Author]

Posts