Why Your Devices Won't Join ChirpStack: An OTAA Troubleshooting Guide

First, work out how far the join gets

An OTAA join is a two-way conversation: the device sends a join request, ChirpStack validates it, and a join accept has to travel back through a gateway to the device in a narrow receive window. A failure can happen at any point.

Before changing anything, find out which of these is true:

1. The gateway never hears the join request. Check the gateway's LoRaWAN frames view in ChirpStack. No join request there means a radio, channel or gateway problem — not a device configuration problem.
2. ChirpStack receives the join request but rejects it. Check the device's Events and LoRaWAN frames tabs, and the ChirpStack logs, for an error.
3. ChirpStack sends a join accept, but the device never gets it. You will see the join accept in the frames log, but the device keeps sending join requests.

Each case has a different set of causes.

Case 1: the gateway doesn't hear the join request

Gateway offline or misconfigured

Confirm the gateway is online and receiving other traffic. If it isn't, start with our gateway offline troubleshooting guide.

Channel plan mismatch

The device and gateway must use the same frequency plan. This is especially common in US915 and AU915, where gateways often listen on only one sub-band of 8 channels. A device sending its join on channels the gateway doesn't listen to will never be heard. Check the device firmware's sub-band setting against the gateway and the region configuration in ChirpStack.

Range and radio

Test with the device close to the gateway. If it joins at a few metres but not in the field, you have a coverage problem, not a configuration problem.

Case 2: ChirpStack rejects the join request

Unknown device

If ChirpStack doesn't recognise the DevEUI, it can't process the join. Check that the device is registered — and that the DevEUI is entered in the right byte order.

Byte order (MSB vs LSB)

Some firmware stacks and device labels show EUIs in least-significant-byte-first order, while ChirpStack expects the standard most-significant-byte-first form. A reversed DevEUI or JoinEUI is one of the most common reasons a "correctly configured" device won't join. Keys such as the AppKey are not reversed — only reverse what your firmware documentation says to.

Wrong keys or the wrong key field

The DevEUI, JoinEUI (sometimes called AppEUI) and root key must all match the device exactly. LoRaWAN 1.0.x and 1.1 use different root keys, so make sure the key is entered in the field that matches the MAC version in the device profile. A wrong key usually shows up as a MIC error.

Device profile doesn't match the device

The device profile's LoRaWAN MAC version and regional parameters revision must match what the device firmware actually implements. A mismatch can cause failed joins or a device that joins and then misbehaves. Check the device datasheet rather than guessing.

DevNonce errors

LoRaWAN uses a DevNonce in each join request to protect against replay attacks, and ChirpStack rejects a DevNonce it has already seen for that device. If a device was reset, reflashed or moved from another network, its DevNonce may repeat values already used. The fix depends on the situation — confirm it is a legitimate device and not a replay before clearing stored nonces or re-creating the device.

Case 3: the join accept never reaches the device

Downlink transmission errors

Check the gateway's downlink acknowledgements. Errors such as too late, too early or a frequency/power not supported message tell you the gateway couldn't send the join accept. "Too late" often points to latency between the gateway and the server, for example over a slow mobile backhaul.

RX window and timing issues

The device opens its receive windows a fixed time after sending the join request. If its clock or firmware timing is off, or the gateway timestamps are wrong, the join accept arrives when the device isn't listening.

Gateway duty cycle

In regions with duty cycle limits, a busy gateway may not be allowed to transmit. If many devices join at once — after a power cut, for example — some join accepts will be delayed or dropped and devices will retry.

Quick checklist

Symptom	Most likely cause
No join request in gateway frames	Channel plan, coverage, gateway offline
Unknown device	DevEUI not registered or byte order reversed
MIC error	Wrong AppKey or wrong key field for the MAC version
DevNonce error	Device reset, reflashed or replayed join
Join accept sent, device keeps retrying	Downlink timing, latency, duty cycle, RX windows
Joins then misbehaves	Device profile MAC version or regional parameters mismatch

Still stuck?

Join problems across a whole fleet — after a migration, a firmware update or a network change — need fast, structured troubleshooting. That is exactly what our support plans are for.

Talk to a ChirpStack engineer about support and incident response, or see our support plans.