Frame Counter Down for Confirmed Messages does not increment

I use a Lorawan 1.0.2 node that is OTAA and tries to send confirmed up messages.
After joining only the first message is confirmed correctly (fcntup = 0, fcntdown = 0).
The second up message is again confirmed with fcntdown = 0, and the confirmation message is accordingly discarded by the node. The up message is then repeated several times (and not again confirmed, which is correct).
Currently I need to rejoin before sending each confirmed message.
We monitored the communication between Server and Gateway and we are sure the fcntdown is permanently 0.
ChirpStack Installation is Windows:
App-Server: 3.17.6
Network-Server: 3.16.2

Thanks in advance for your help.


Can someone please comment? Is someone using confirmed up messages and can monitor the frame counter down? I need to know if this is a problem with the node or with the network server.

Thanks again,

Have you checked the LoRaWAN frames tab of the device? There you can inspect the full LoRaWAN frame.

Thanks for your help!
But that’s interesting as well: There’s no single downlink frame visible. Neither in Device Data Tab nor in Frame Tab.
Nevertheless I see the ack frames with fCntDown=0 incoming on the device (by in circuit debugging of the actual Lora Module) and our server admin monitored the communication between Network Server and Gateway and also confirmes my observations.

Regards, Johannes

If could be that you have a really old Semtech UDP Packet Forwarder installed on your gateway, which doesn’t send TX acknowledgements (indicating if the gateway is able to send the downlink). Only on receiving an ACK ChirpStack will show the downlink in the web-interface and increment the frame-counter.

Could you check your packet-forwarder version?

This is could be a trace.
We have a Kerlink LoRa Iot Station 868 with Chirpstack Gateway Bridge 3.14.0 (Linux ARMv5) installed. The packets are transmitted to a Mosquitto on the Network Server.
By monitoring the communication we clearly see no “event/ack” topics. Could this be a problem of the configuration of the Gateway?
We used the example file at Configuration but changed the marshaler to json.

Regards, Johannes

We have it solved!
There was still the old poly_pkt_fwd running. We updated the packet forwarder according to and everything works fine.

Thank you very much!

Regards, Johannes