No uplink ACK on confirmed retry

ChirpStack Network Server
1

What happened?

I am testing using some devices which are using mbed-os 5.13 LoRaWAN stack on chirpstack-docker on US915 band. During the test, I found that sometimes the server would report UPLINK_FCNT_RETRANSMISSION three times in a row once in a while.

image
image970×1232 63.7 KB

Further check, we realize that the device retries to send the same message on the same frame-counter because it failed to receive the first ACK. We did configure the device to send a confirmed message with 3 retries. Our assumption is confirmed by checking on the gateway live lorawan frames

image
image915×797 62.9 KB

What did you expect?

I noticed in 2017 on this forum thread [Acks for retransmissions of confirmed uplink] that you decided Chirpstack would not send ACK on a confirmed retry uplink with the same frame-counter.

Would you consider enabling option to send ACK for a retransmission, since it is part of mbed-os LoRaWAN stack? :slight_smile:

We also have an existing setup where we use the same device and the same mbed-os 5.13 LoRaWAN stack only this time on 868 band and using loraserver-docker <5233d24>.

Using this setup, we don’t have a problem with uplink retransmission. Is there policy difference between those two versions regarding uplink retransmission?

Step to reproduce

Steps:

  1. Deploy a chirpstack-docker container (in my case I was using US915 band)

  2. Prepare a device that would periodically send a confirmed uplink with 3 retries if it failed to receive ACK from the server.

  3. Wait until the ‘error’ shows up.

2

Would you consider enabling option to send ACK for a retransmission, since it is part of mbed-os LoRaWAN stack?

This is not possible in a secure way.

This situation happens when the uplink was received and processed, but the device did not receive the downlink. In this case, it might re-try sending the same uplink but as the frame-counter was already seen by the NS, it is rejected as you describe.

LoRaWAN 1.1 does offer a way to implement this in a secure way, given that the re-transmision is transmitted on a different channel as the channel is used as one of the MIC parameters. By collecting the used MICs for the last frame-counter, a NS can distinguish a replay-attack from a re-transmission.

However for LoRaWAN 1.0, a replay-attack and re-transmission can not bit distinguished, providing an option to send an ACK for a re-transmission would never be secure.

1 Like