Confirmed messages to and from server issue

ChirpStack Network Server
1

Hi, first thanks for the great software.

I’ve been using your server with some success but have run into issues with confirmed messages.

If sending confirmed messages from the lora-server to an end-device, then if the end-device replies with an ACK faster than around 9 seconds then everything works, but if it takes longer than that then the server doesn’t acknowledge the next message. If the end device is also using confirmed up messages then the server never acknowledges any subsequent message while also attempting to resend the data.

In the LoRa spec the only reference I can find to any times is the ACK_TIMEOUT which seems to only apply to end-devices receiving a frame with the ACK set within that time.
In the details timing section (sect. 18) it says that the end-device may transmit an ACK at “its own discretion” and doesn’t specify a time limit.

I’m just wondering if I’m missing something in the spec or if the server behaves differently, or if possibly there’s a bug in the lora mac stack I’m using (lmic on arduino for reference).
I also did some quick tests on an mDot and had some similar issues.

Also for reference the payload is the same each time.

Here are the results of my basic tests.
Down in this case refers to messages from the server to the end device.
Up refers to messages from the end-device to the server.

Down: Unconfirmed
Up: Unconfirmed
Delay: ~10 sec
Result: Good

Down: Confirmed
Up: Unconfirmed
Delay: ~10 sec
Result: Good

Down: Unconfirmed
Up: Confirmed
Delay: ~10 sec
Result: Bad. Alternates between: receiving data with ACK set, and not receiving any data with ACK not set

Down: Unconfirmed
Up: Confirmed
Delay: ~8.2 sec
Result: Good. Receives data each frame with ACK set

Down: Confirmed
Up: Confirmed
Delay: ~10 sec
Result: Bad. After receiving one frame with data and with ACK set, all following frames have no data and no ACK set, however frames get passed onto application

Down: Confirmed
Up: Confirmed
~8.2 sec delay
Result: Good. Each frame contains data with ACK set

2

The best thing to do would be to look into the frame logs, which you’ll find in the LoRa App Server web-interface. There you’ll find the full LoRaWAN frames sent and received (including message type and if the ACK is set or not).

From there you can compare to how your node sees the information. E.g. when you would expect an ACK but the ACK is set to false in the LoRaWAN frame log (LoRa App Server), then you know there is an issue with your firmware.

3

Hi thanks for the quick response.

I did end up finding and fixing the problem, which I’ll go over for anyone with a similar issue. And found turning on the frame logs helped a lot in seeing what was going on.

The loraserver log was giving the error message
‘level=error msg=“processing rx packet error: get node-session error: node-session does not exist or invalid fcnt or mic” data_base64=…’

Essentially the LMIC stack was sending an ACK with the same FCntUp as the previous message, which the server was rejecting.
Possibly related to another topic here and your blog post about the security implications.
When sending data quicker it was incrementing the FCntUp and not running into the issue.

Making the LMIC stack always increment the FCntUp fixed all the issues here, and seems to be what the server expects.