JoinRequest–JoinAccept loop

Question

This is a repost from the forum, as the original topic didn’t seem to get enough visibility and we’re still experiencing the issue.
Original topic:
https://forum.chirpstack.io/t/lost-join-accept-on-gateway-bridge/25647

Some devices that were working perfectly fine just a few days ago are now stuck in a continuous JoinRequest–JoinAccept loop. Here is one example:

We’ve checked all the available logs (that I could find at least) but haven’t found anything useful—there’s essentially the same information as shown in the web interface. I’d be glad to share the logs if anyone has ideas on how we could debug this further and identify the root cause.

Since we have quite a large number of devices, my initial suspicion was that there aren’t enough resources to process every packet in time. To mitigate this, I added another instance of the Application Server with the Network Server (now running two ChirpStack container replicas). I also installed MQTT forwarders on some of the gateways—originally, a single instance of the Gateway Bridge was running on the server—but unfortunately, this didn’t change anything.

Any tips or suggestions would be greatly appreciated!

Orne Brocaar · Answer

Given that you see a JoinAccept in the web-interface means that the gateway did send an acknowledgement of transmission as only on receiving an ack, ChirpStack will show the JoinAccept.

If the ChirpStack Gateway Bridge is running on the gateway, you could try (on the gateway):

sudo tcpdump -AUq -i lo port 1700

If the GW Bridge is running on a VM, then you could try (on the gateway / on the GW Bridge VM):

sudo tcpdump -AUq port 1700

An other option is to use a spectral scanner to see if the gateway is actually transmitting the downlink.

ChrisG · Answer

In the instances where I have devices in this join loop state the issue usually arrises from the end device not receiving the join request due to either poor signal or interference. How far apart are the gateway and this device, also out of curiosity what model is the gateway and the end device?

One thing you could try is increasing the transmit power the gateway uses. I think chirpstack defaults to a transmite power of 20 when the default is left in the regional config.

You can edit this in the regional .toml files if you edit the line "downlink_tx_power". Depending on your gateway that value can be pushed much higher (in my image above it is from a tektelic kona-mega gateway, and I have it set for 36dBm which is the absolute max for the US915 region). This setting can significatly improve the range your gateway transmissions will reach. Just make sure you stay within regional specifications, and watch for your gateway to start giving 'TX_POWER' errors in the TX packets/status graph. If that happens you need to lower the tx_power because it has exceeded the gateways ability.

JoinRequest–JoinAccept loop

2 Answers