ABP issue/counters not resetting

[Mikael Grah]

Hi,

I’m trying to use mDot as a modem (AT command mode) in an embedded application to communicate with a AEP Conduit gateway. After making sure that the gateway has enableStrictCounterValidation off, I still have issues with the communication.

At startup, my current setup initializes the modem for ABP, sets the ulc and dlc to 0, then saves the session with at+ss. The reason for clearing the counters is to make sure that they are reset to zero when starting up, so that the gateway will accept the messages.

After a couple of seconds of work, the unit cuts the power to the mDot and then goes to sleep.

When the unit wakes up, it turns on the power for the mDot and waits for two seconds to let the mDot wake up. It then sends the following commands, waiting for OK inbetween each:

+rs // Restore session
+dlc=0 // Clear downlink counter
+ulc=0 // Clear uplink counter

After each command the unit waits for an OK.

Next I send some data, using sendb. Most of the time this does not work. When I look at the log on the gateway, I get the following:

Feb 20 10:33:47 mtcdt user.info lora-network-server: GW:00:80:00:00:00:00:9a:6c|FRAME-RX|Parsing 1 packets
Feb 20 10:33:47 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|CHECK-PKT|FCNT: b6c345cc LAST-FCNT: 00000000 Duplicate: yes
Feb 20 10:33:47 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|CHECK-MIC|ADDR: 00:00:00:03 passed
Feb 20 10:33:47 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|PER|0.000000%
Feb 20 10:33:47 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|FCTRL|ADR:0 ADRACK:0 ACK:0 CLASS:A OPTS:0 
Feb 20 10:33:47 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|SCHED-TX|Use RX1 TOA:1165 ms
Feb 20 10:33:48 mtcdt user.info lora-network-server: GW:00:80:00:00:00:00:9a:6c|FRAME-TX|IP: 127.0.0.1:56108 CH: LC3 NODE: 00:00:00:03 FCNT: 000000c7 REPEAT: 0
Feb 20 10:33:48 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|SCHED-TX|Q-SIZE: 0 PKT-SIZE: 30372 PKT-ROOM: 242
Feb 20 10:33:48 mtcdt user.info lora-network-server: Update DC Band: 1 Duration: 1155 time-on-air available: 12780 ms
Feb 20 10:33:48 mtcdt user.info lora-network-server: GW:00:80:00:00:00:00:9a:6c|UDP-TX|JSON-SIZE:237

Note that the FCNT (uplink counter) seems to be b6c345cc rather than 0, which I would expect. Depending on the order in which I issue commands, I occatonally get 000000e7, still indicating a duplicate.

Directly after the send command (before turning the modem off) I issue a +ss and wait for two extra seconds.

The modem I’m using has the 2.0.16 firmware, but I get the same result with a mDot with FW 3.0.0 (connected to a MTMDK) if I issue a send-command directly after a reset. Note that at+dlc and at+ulc in the bench test both return 0, but the gateway still sees the FCNT as b6c345cc.

If I manually set the ulc and dlc to 0 and try send immediately, I get the same gateway FCNT (b6c345cc), however if issue an +ss (save session) after the failed send, reset the modem, restore the session (now with ulc=1 and dlc=52) and issue a new send command, this works;

Feb 20 10:44:50 mtcdt user.info lora-network-server: GW:00:80:00:00:00:00:9a:6c|FRAME-RX|Parsing 1 packets
Feb 20 10:44:50 mtcdt user.info lora-network-server: ED:00-80-00-00-00-01-09-0b|CHECK-PKT|FCNT: 00000001 LAST-FCNT: 00000000 Duplicate: no

I’m not really sure what’s going on, why doesn’t just setting the counters to 0 in the first case (right before sending) work as expected? I would expect the FCNT to be 0 and the gateway to accept the message as not being a duplicate…

Any help/insights? What am I doing wrong?

• This topic was modified 6 years, 9 months ago by Mikael Grah.

[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, 9 months ago by Mikael Grah.

[Jason Reiss]

When a duplicate is detected the FCNT value is not reporting correctly in this version of network server. It is an uninitialized value.

In the next release of network server, the value is initialized to FFFFFFFF which may show in the FCNT if the packet cannot be authenticated.

In the server update when a duplicate is received the FCNT will be set correctly.
|CHECK-PKT|FCNT: 00000002 LAST-FCNT: 00000002 Duplicate: yes

Although the enableStrictCounterValidation is set to false, the network server will still filter out duplicate messages from being reported to the application. So if the end-device is sending 0 repeatedly the payloads are not forwarded to the application.

[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… 😎

[Author]

Posts