Counter issue

[Mikael Grah]

Hi,

I’m working with an ABP solution. The system contains of a mDot that communicates with a Conduit running the AEP model.

The conduit has StrictCouterValidation disabled. The mDot is configured to require an ACK.

Usually, the gateway shows the following log messages, and the ack is correctly receieved by the mDot:

Mar  6 19:58:43 mtcdt user.info lora-network-server: GW:00:80:00:00:00:00:9a:6c|FRAME-RX|Parsing 1 packets
Mar  6 19:58:43 mtcdt user.warn lora-network-server: Performing lazy check of counter, replay attack possible
Mar  6 19:58:43 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|CHECK-PKT|FCNT: 00000004 LAST-FCNT: 00000003 Duplicate: no
Mar  6 19:58:43 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|CHECK-MIC|ADDR: 00:00:00:03 passed
Mar  6 19:58:43 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|PER|0.000000%
Mar  6 19:58:43 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 
Mar  6 19:58:43 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|SCHED-TX|Use RX1 TOA:1165 ms
Mar  6 19:58:43 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|QUEUE-TX|DATA SIZE: 12
Mar  6 19:58:43 mtcdt user.info lora-network-server: GW:00:80:00:00:00:00:9a:6c|FRAME-TX|IP: 127.0.0.1:37875 CH: LC2 NODE: 00:00:00:03 FCNT: 00000c36 REPEAT: 0
Mar  6 19:58:43 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|SCHED-TX|Q-SIZE: 1 PKT-SIZE: 12 PKT-ROOM: 242
Mar  6 19:58:43 mtcdt user.info lora-network-server: Update DC Band: 1 Duration: 1482 time-on-air available: 8284 ms
Mar  6 19:58:43 mtcdt user.info lora-network-server: GW:00:80:00:00:00:00:9a:6c|UDP-TX|JSON-SIZE:268

I interpret this as that one package was sent, it was not a duplicate and everything works fine.

After a while there can be an error in the communication for various reasons, and the mDot does not get the ACK (any ideas what could be the reason? radio disturbances?).

Mar  6 20:14:04 mtcdt user.info lora-network-server: GW:00:80:00:00:00:00:9a:6c|FRAME-RX|Parsing 5 packets
Mar  6 20:14:04 mtcdt user.warn lora-network-server: Performing lazy check of counter, replay attack possible
Mar  6 20:14:04 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|CHECK-PKT|FCNT: 00000007 LAST-FCNT: 00000006 Duplicate: no
Mar  6 20:14:04 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|CHECK-MIC|ADDR: 00:00:00:03 passed
Mar  6 20:14:04 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|PER|0.000000%
Mar  6 20:14:04 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 
Mar  6 20:14:04 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|SCHED-TX|Use RX1 TOA:1165 ms
Mar  6 20:14:04 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|CHECK-PKT|FCNT: b6c645cc LAST-FCNT: 00000007 Duplicate: yes
Mar  6 20:14:04 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|CHECK-MIC|ADDR: 00:00:00:03 passed
Mar  6 20:14:04 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|PER|0.000000%
Mar  6 20:14:04 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 
Mar  6 20:14:04 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|CHECK-PKT|FCNT: 000000e7 LAST-FCNT: 00000007 Duplicate: yes
Mar  6 20:14:04 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|CHECK-MIC|ADDR: 00:00:00:03 passed
Mar  6 20:14:04 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|PER|0.000000%
Mar  6 20:14:04 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 
Mar  6 20:14:04 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|CHECK-PKT|FCNT: 000000e8 LAST-FCNT: 00000007 Duplicate: yes
Mar  6 20:14:04 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|CHECK-MIC|ADDR: 00:00:00:03 passed
Mar  6 20:14:04 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|PER|0.000000%
Mar  6 20:14:04 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 
Mar  6 20:14:04 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|CHECK-PKT|FCNT: b6c645cc LAST-FCNT: 00000007 Duplicate: yes
Mar  6 20:14:04 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|CHECK-MIC|ADDR: 00:00:00:03 passed
Mar  6 20:14:04 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|PER|0.000000%
Mar  6 20:14:04 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 
Mar  6 20:14:04 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|QUEUE-TX|DATA SIZE: 12
Mar  6 20:14:04 mtcdt user.info lora-network-server: GW:00:80:00:00:00:00:9a:6c|FRAME-TX|IP: 127.0.0.1:37875 CH: LC6 NODE: 00:00:00:03 FCNT: 00000c39 REPEAT: 0
Mar  6 20:14:04 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|SCHED-TX|Q-SIZE: 1 PKT-SIZE: 12 PKT-ROOM: 242
Mar  6 20:14:04 mtcdt user.info lora-network-server: Update DC Band: 2 Duration: 1482 time-on-air available: 274151 ms
Mar  6 20:14:04 mtcdt user.info lora-network-server: GW:00:80:00:00:00:00:9a:6c|UDP-TX|JSON-SIZE:255

I think that this looks like a failure of the mDot to receive the ACK, causing a retransmission? The same package, with the same FCNT is sent 5 times…

The unit communicates with the mDot using AT command mode. When the software discovers that no ACK was received, it will set the counter to 0 (at+ulc=0).

The next transmission also ends with a missing ACK:

Mar  6 20:23:16 mtcdt user.info lora-network-server: GW:00:80:00:00:00:00:9a:6c|FRAME-RX|Parsing 2 packets
Mar  6 20:23:16 mtcdt user.warn lora-network-server: Performing lazy check of counter, replay attack possible
Mar  6 20:23:16 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|CHECK-PKT|FCNT: 00000000 LAST-FCNT: 00000007 Duplicate: no
Mar  6 20:23:16 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|CHECK-MIC|ADDR: 00:00:00:03 passed
Mar  6 20:23:16 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|PER|0.000000%
Mar  6 20:23:16 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 
Mar  6 20:23:16 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|SCHED-TX|Use RX1 TOA:1165 ms
Mar  6 20:23:16 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|CHECK-PKT|FCNT: b6c645cc LAST-FCNT: 00000000 Duplicate: yes
Mar  6 20:23:16 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|CHECK-MIC|ADDR: 00:00:00:03 passed
Mar  6 20:23:16 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|PER|0.000000%
Mar  6 20:23:16 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 
Mar  6 20:23:17 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|QUEUE-TX|DATA SIZE: 12
Mar  6 20:23:17 mtcdt user.info lora-network-server: GW:00:80:00:00:00:00:9a:6c|FRAME-TX|IP: 127.0.0.1:37875 CH: LC1 NODE: 00:00:00:03 FCNT: 00000c3a REPEAT: 0
Mar  6 20:23:17 mtcdt user.info lora-network-server: ED:00-80-00-00-00-00-bd-fb|SCHED-TX|Q-SIZE: 1 PKT-SIZE: 12 PKT-ROOM: 242
Mar  6 20:23:17 mtcdt user.info lora-network-server: Update DC Band: 1 Duration: 1482 time-on-air available: 17956 ms
Mar  6 20:23:17 mtcdt user.info lora-network-server: GW:00:80:00:00:00:00:9a:6c|UDP-TX|JSON-SIZE:268

My interpretation is that the counter reset works on the mDot, the FCNT is set to 0. But for some reason the mDot sends another package, also with a FCNT of 0, which is not accepted by the gateway.

Usually it doesn’t happen this soon after the device is started. What could cause this issue? Any suggested solutions?

The mDot is placed about a meter from the gateway, and it’s in an office environment…

Could there be an issue with the mDot? Maybe an issue with the antenna?

[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?

[Jason Reiss]

The gateway is receiving duplicate packets from a single uplink.
In previous network servers this can affect the downlink frequency chosen.

Try to upgrade the network server to v1.0.43. It will filter out packets from the adjacent channels.
http://www.multitech.net/developer/downloads/

[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

[Author]

Posts