LoRaWAN OTAA join request is seen by the gateway but the node never joins: what is wrong?

The console showing a join accept is useful information: the server verified the request's integrity code, so the DevEUI, JoinEUI and AppKey match. The problem is on the way back down: the node is not hearing, or not decoding, the downlink. (If no accept were generated at all, key byte order would be the first suspect: LMIC expects the two EUIs least-significant byte first and the AppKey most-significant byte first.)

Know the timing you are aiming at. The join accept is sent in a receive window that opens 5 seconds after the end of the join request, with a second window at 6 seconds. The node listens for only a few symbol times in each, so everything depends on opening the window at the right moment, on the right frequency and data rate.

Timing is the most common cause with small microcontrollers. At SF7 a symbol lasts 1.024 ms and the downlink preamble is about 12.5 ms long, so a clock that is off by 1 % over 5 s (50 ms) opens the window after the preamble has gone. Boards with a ceramic resonator or an internal RC oscillator are typical victims. LMIC-based stacks let you widen the window to compensate, for example LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100) for a 1 % allowance.

Avoid long blocking code or heavy serial printing between the transmit-complete event and the receive windows, because that delays the scheduler as well.

Check the DIO wiring. In LoRa mode an LMIC-type stack needs DIO0 (transmit done and receive done) and DIO1 (receive timeout) connected to the microcontroller and listed correctly in the pin map. With DIO1 missing, the uplink works but the receive windows are not handled properly, and joins fail in exactly this way.

Also confirm that the frequency plan matches on both sides. In US915-style plans the network usually listens on one sub-band of eight channels only, and the node must be restricted to the same one, otherwise most join requests go unheard and joining takes very long or never succeeds.

Two more things to check. First, do not test with the node right next to the gateway: a few tens of centimetres between antennas overloads the receivers, and the symptoms include corrupted or missed downlinks. Keep a few metres and preferably a wall between them. Make sure the gateway really can transmit as well; some single-channel or receive-only packet forwarders show uplinks but never send downlinks.

Second, the DevNonce. Recent LoRaWAN versions expect the join nonce to increase, and the server rejects a value it has already seen. A node that loses its counter on every reset shows up in the console as a nonce error rather than a join accept; the fix is to store the counter in non-volatile memory or to reset the used nonces in the console.