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?