Downlink issue with Semtech v1 protocol


I am encountering an issue on downlink messages.
My first installation was on Google Cloud, and thought that this issue may be due to a misconfig, and decided to put everything in one box, but the issue still persists.

I realized there was an issue when no downlink messages was displayed when looking at data and frames in the web app console, and also that my gateway was constantly sending the downlink message after my device sent an uplink, even if it was unconfirmed.
In other words, Chirpstack stack is believeing that sending the downlink message failed, constantly retries as it keeps it in the queue, and on each try the gateway is actually sending the message through the air.

After analyzing Semtech UDP datagrams, My LoRaWAN gateway is apparently dealing with v1 (byte 0). In v1, the gateway doesn’t acknoweldge (TX_ACK) it accepted the (PULL_RESP) downlink message for transmission.
Also I see that Chirpstack sends v1 Semtech datagrams to my gateway, which is correct.

So I suspect that a Chirpstack component, probably the network server, is waiting for this ack to define the downlink message has been accepted by the gateway, stops retrying, and displays it in the console.

Uplink messages are handled properly.

Logs will follow this message as I don’t have access to my test env yet, but if anybody has an idea on why this is behaving like this, it is very welcome.

The ChirpStack Network Server does not wait for an ACK or nACK. It stores the downlink(s) (e.g. RX1 / RX2) in Redis and when there is an ACK, it is logged. If there is a nACK, it will retry with the second downlink option (e.g. RX2).

When the gateway does not send any ACK / nACK, then the downlink is probably sent if everything was configured correctly, but this is only an assumption.

Any reason not to update the Packet Forwarder on your gateway?


I made some deeper investigations and found the issue. There are two actually.

First I will answer your question about upgrading the packet_forwarder: there is none, it is a custom implentation of Smtech protocol:

I am trying to make this single channel gateway work and finally succeeded, here are some hints:

Downlink packets are send over the air, but are not displayed and logs show and TX ACK coming from the gateway are not recognized:
I figured out that the gateway uses V1 packets. It is threfore not supposed to send ACKs, I believe. I made some changes to the code, for it to be V2, and now the downlink are diplayed and no errors in the logs.

Seond issue about downlinks constantly being sent after an uplink: I found out that these were MAC commands sent by Chirpstack, and it appears the device I use doesn’t want to process them. I need to dig further.

Hi @brocaar , is this a strict assumption made by the network server? I am seeing a situtation where it appears as if the network server is not incrementing the FCntDown when it doesn’t recieve the txack for the gateway. I need to do more investigation but this is my working hypothesis after a few days of debugging.
As to why not switch to v2 protocol?: Some older hardware doesn’t seems to support it.

The TX_ACK is required as only then ChirpStack knows that the downlink has been (or will be) transmitted by the gateway. In this case the downlink application payload is not removed from the queue in case the gateway could not transmit the downlink. Without the TX_ACK from the gateway, this would not be possible.