DLOS8 Logs Connected, TTN Console Shows Disconnected

neils
Tue, 29 Jul 2025 22:15:27 +0000
Dragino Gateways

Gateway Model: Dragino DLOS8 Firmware Version: lgw-5.4.1746500086 (Build Time: Tue 09 May 2025 10:54:46 AM CST) - [Verify this from your System Overview, as it might have reverted from my previous guess] Gateway EUI (from concentrator EUID in logs): 0016c001f1d01c99 Region: AU915 The Things Network Server Address: au1.cloud.thethings.network:1700 (for UDP Packet Forwarder)

Problem Description:

My Dragino DLOS8 gateway consistently shows as “Disconnected” in The Things Network Console, despite its SSH logs indicating successful two-way communication with au1.cloud.thethings.network:1700 via the Semtech UDP Packet Forwarder.

Key Troubleshooting Steps Already Performed (and their results):

1. Internet Connectivity: Confirmed active and stable. Gateway shows “Internet Connection OK” in its web UI.

2. Firmware Update: Successfully updated to the latest stable firmware (lgw-5.4.1746500086).

3. Time Synchronization (NTP): Post-firmware update, the gateway’s system time is consistently correct (verified via web UI System Overview). The logs also show correct timestamps after initial boot sequence.

4. LoRaWAN Configuration: Frequency Plan (AU915, Sub-band 2) and server addresses/ports (au1.cloud.thethings.network:1700) are correctly set in the gateway’s web UI.

5. Gateway EUI Consistency:

The EUI registered in The Things Network Console has been repeatedly updated and re-registered to precisely match the concentrator EUID=0x0016c001f1d01c99 value reported in the gateway’s packet forwarder logs. (Note: This EUI is different from the EUI on the physical device label/web UI Gateway ID field: a84041fffe2a9a66, indicating the software overrides the configured EUI).

Gateway has been deleted and re-registered in TTN Console multiple times, with waits in between, to ensure no stale data.

6. Firewall Check: The gateway’s SSH logs show consistent PULL_ACK (gateway to server) and PUSH_ACK (server to gateway) messages, unequivocally proving that UDP port 1700 is open and bidirectional communication is occurring between the gateway and TTN. This rules out router/ISP firewall blocking.

7. Browser/Console Check: The “Disconnected” status persists even when checking from different browsers and different computers/network connections (e.g., mobile data), ruling out local browser caching issues.

8. Basic Station Attempt: Tried Basic Station. Logs consistently showed (404) Not Found from CUPS, suggesting an authentication/identity mismatch, even after rigorous API key and certificate setup. This led back to re-confirming the EUI used by the software.

The core issue is that despite clear log evidence of successful UDP communication and acknowledgements from TTN, the gateway’s status in The Things Network Console remains “Disconnected.” This points to an internal issue within TTN’s backend or console display regarding this specific gateway’s identification or connection state.

6 posts - 4 participants