DFR1093-915 Built-in Server — Join Accept never received by node (OTAA)

Hardware:

Gateway: DFR1093-915, Built-in Server modeNode: Ezurio Sentrius RS262-INT (LoRaWAN 1.0.4, US915)

Setup confirmed correct:

AppKey — MIC-verified successfully on every join requestAppEUI/JoinEUI — confirmed matching between device and gatewaySub-band — FSB2 (channels 8–15, 65) matching on both sidesRF link — strong bidirectional signal (SNR 9–17 dB, RSSI -40 to -53 dBm)Region — US915 confirmed on device

Symptom:
Node continuously sends valid Join Requests (confirmed via Real-time Data → Data log, filtered by JoinRequest type). Gateway logs a single corresponding JoinAccept in response — correct DevAddr assigned, correct JoinEUI echoed back, correct RX1 frequency (923.9 MHz, matches spec formula for channel 65: 923.3 + 0.6×(65-64)). But the node never completes the join — LoRaWAN Info page on the device stays at "Not Connected," RSSI/SNR frozen at 0, indefinitely.

Example log entry (exported JSON):

 

JoinRequest: 16:11:31.052067010Z, freq 904600000, BW500SF8 JoinAccept:  16:11:31.195666815Z, devAddr 00FA1A7A, joinEui F9C60ECEA3ADC6BD, freq 923900000, BW500SF7

Notes:

Per LoRaWAN spec, the node's RX1 window for a Join Accept doesn't open until 5 seconds after the Join Request (JOIN_ACCEPT_DELAY1). The gap in the log above is ~143ms — unclear if this reflects actual over-the-air TX timing or just when the event was logged internally. Adjusting Rx1 Delay in Mode Configuration from 1→5 did not change this logged gap or fix the join.Pre-filling the "Join EUI" field during manual device registration seemed to prevent a JoinAccept from being generated at all in earlier attempts; leaving it blank (auto-detected from the incoming request) was required to get a JoinAccept logged.Repeated across multiple full device reboots and fresh device re-registration — same result each time, new DevAddr generated each attempt, never received by node.

Question: Is there a known issue with the Built-in Server's Join Accept downlink scheduling/timing for OTAA joins? Is there a way to verify actual over-the-air TX time vs. gateway concentrator scheduling accuracy (e.g., does this gateway have GPS-disciplined timing, or software-only scheduling)?