Hi,
Duplicate post on gitter, sorry. Just found your forum.
just wondering if loraserver has same behaviour as described here about TTN? https://www.thethingsnetwork.org/forum/t/backend-retry-policy/3599
From my tests it appears so, but maybe im missing something. So thought i would ask before spending too much more time setting up tests.
Ie the server will not send another ack if the node misses the ack and retransmits the uplink.
This is described in one of the example timing diagrams in the spec. Images from the spec are on the ttn thread.
Btw, well done on an awesome project.
Regards
Chris
LoRa Server will always ignore frames that have been seen, so when a node retransmits a confirmed uplink, the network-server will reject this. This is for security reasons as the server can’t validate if a retransmission is authentic or is a replay attack by an adversary.
Retransmitting an ACK would also mean that an adversary gets control over the airtime of gateways, which is probably not what you want.
I know that this can result in a kind of “deadlock” when the network-server processed the confirmed data up and set an ACK which was not received by the node. The node would then keep retrying without success. However I think this is the only safe way to implement this.
LoRaWAN 1.1 will probably include some changes to improve this 
When you’re interested, there are some more issues with the confirmed-data: https://medium.com/@brocaar/notes-on-lorawan-security-7e741a8ee4fa.
Thanks for the reply and your post, very interesting. Great that you’ve picked up on this issue. For now I guess we can instruct the node mac to only try one transmission. If it fails then send a new uplink, effectively implementing the retries at an application layer with something implemented to detect duplicates at the application layer.