Downlink for Class A not incrementing

[Ragav]

Hello all,

I’m using the latest version of Chirpstack, version 4.0.0.rc2, and while using it with a Class-A end-device, I observed something different.

Process of events:

1. Class-A end-device joined the network and sent the first uplink.
2. I queued multiple downlinks, with the same data, both manually and using python api’s.
3. First downlink goes to the sensor, sensor reads and it and formulates a response uplink.
4. Second uplink(Response) is received by the network and shows the data properly.
5. Second downlink(which has already been queued into the downlink) is sent to the sensor and Application server receives a TxACK from the gateway.
6. But sensor is rejecting the second downlink because the downlink frame counter has not been incremented.

Application server also follows the same and does not increment the downlink, it stays at 1.
Please see the following screenshots for the same in the Application server.

I have managed to narrow it down to tx_ack.rs file:

But I’m confused as to why mac_version is required for frame increment function. Any pointer to this would be helpful.

[brocaar]

Are you sure you are on rc2, because there was indeed an issue (in rc1) related to this:

Fix mac_version -> mac_version().

To answer your question:

The mac-version is needed, because LoRaWAN 1.1 has two downlink frame-counters, one for mac-layer payloads (n_f_cnt_down) and one for application payloads (a_f_cnt_down).

[Ragav]

Thanks for confirming on that, I rechecked the repo that I had, and while updating I missed some steps and now after a complete refresh, its working as expected.