DLOS8 Logs Connected, TTN Console Shows Disconnected

Gateways Dragino Gateways
1

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.
  1. 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.
  2. 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.
  3. 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.

2

Hi Neils, 2 things to try.

  1. For the server address try just

without the explicit port1700 call out.
(2) also more common to see Dragino GW’s listed under the

Form for the system eui vs the concentrator specific eui. Have you tried registering using that rather than the

eui ? as neither version appears to exist in the system:-

image
image1194×178 11.3 KB

(though its late and likely that is me doing incorrect/incomplete search!) what have you used as the GWID on the TTN console (not GWID on GW GUI/firmware) - this can be freeform text (see the (?) mark).

Suggest persist with UDP attempts for now then move to BS later if desired once connection/operation proven (the auth adds an extra layer of complication if you are struggling.

Do you have a functioning node generating traffic in proximity of the GW? If so can you see it uplinking in the GW local console?

3

Or alternatively, as revealed via a forum search, that the connection state is not updated in realtime on the web console due to the constraints of keeping such data in server memory.

There are some discrepancies between reality and Dragino documentation, but what you have put as Gateway ID is Gateway EUI in the docs and the Dragino MAC registration with the IEEE is for a MAC-L starting A84041, example shown in the docs. I’ve never looked that hard but the 0016c0 is likely to be the concentrator chipset as that is a prefix registered to Semtech.

You have the Pull & Push Acks being logged at the gateway. What you’ve not said is whether you are seeing these keep alive messages in the web console log.

As @Jeff-UK says and appears in countless other such discussions on the forum - yes, this is a nudge to using the vast knowledge base that has built up over the years - the acid test is a known good device sending uplinks.

Please consider in your debugging & conclusions that TTN hosts over 24,000 gateways and processes over 1,200 messages per second, Dragino is a popular brand that has its own forum section, so overall, best to travel hopeful in so much as assume it is your end and not TTN. If you’ve followed the vendor & TTS docs (linked bottom right of every console page) and searched the forum to no avail, don’t go all out trying to fix fundamentals, just ask!

4

Boy do I feel silly. All these issues I had were because my server is actually on the TTS (derp). The dragino folks helped me sort this out. Many thanks for your time trying to help and sorry from a newbie