Überblick

Kommen von einem Gerät keine Daten an, lässt sich die Netzwerkverbindung Schritt für Schritt eingrenzen:

Die Tests müssen aus demselben Netz bzw. APN wie das Gerät ausgeführt werden – idealerweise auf dem Gerät oder Gateway selbst (viele Gateways bieten eine Shell oder ein Diagnose-Menü). Ein Test vom Büro-PC sagt nichts über das Netz des Geräts aus.

Die freizugebenden Zieladressen und Ports stehen auf der Seite Firewall-Whitelist.

Grundkonfiguration prüfen

Bevor Ziele und Ports getestet werden, muss die Grundkonfiguration des Geräts stimmen. Das ist allgemeines Netzwerkwissen, führt bei Inbetriebnahmen vor Ort aber regelmäßig zu Fehlern:

• IP-Adresse (DHCP oder statisch): Per DHCP erhält das Gerät IP-Adresse, Gateway und DNS-Server automatisch. Bei einer statischen IP-Adresse müssen alle drei manuell korrekt eingetragen sein.
• Default-Gateway: Ohne korrektes Gateway hat das Gerät zwar eine IP-Adresse, erreicht aber das Internet nicht.
• DNS-Server: Muss aus dem Netz erreichbar sein (UDP/TCP-Port 53). Bei privaten APNs stellt meist der Mobilfunkanbieter den DNS-Server bereit.
• Uhrzeit (NTP): Das Gerät muss seine Uhrzeit per NTP synchronisieren können (UDP-Port 123 ausgehend). Mit falscher Uhrzeit schlägt die TLS-Zertifikatsprüfung fehl, weil Zertifikate nur in einem bestimmten Zeitraum gültig sind – der Port-Test mit nc meldet in diesem Fall trotzdem Erfolg. Bei LoRaWAN-Gateways leidet zusätzlich das Downlink-Timing.

Ping: nur begrenzt aussagekräftig

ping ist ein einfacher erster Test, ob überhaupt eine Internetverbindung besteht und ob der Hostname aufgelöst wird (die aufgelöste IP steht in der ersten Ausgabezeile). Über die Freigabe der eigentlichen Ports sagt ein Ping dagegen nichts aus: Ping nutzt das Protokoll ICMP, das Firewalls unabhängig von TCP- und UDP-Freigaben erlauben oder blockieren.

Für eine belastbare Prüfung deshalb Namensauflösung und Port getrennt testen.

Namensauflösung prüfen (nslookup)

nslookup fragt den im Netz konfigurierten DNS-Server, welche IP-Adresse zu einem Hostnamen gehört. Es sendet dafür keinen Verkehr an das Ziel selbst.

nslookup consumers.mq.iot-hub.com

Erwartetes Ergebnis:

Server:		1.1.1.1
Address:	1.1.1.1#53

Non-authoritative answer:
Name:	consumers.mq.iot-hub.com
Address: 3.124.22.77

• Server ist der gefragte DNS-Server, Address unter Non-authoritative answer die aufgelöste IP-Adresse des Ziels.
• Bei Hosts mit dynamischer IP-Adresse (z. B. dem MQTT-Broker) kann die angezeigte IP abweichen – entscheidend ist, dass eine Adresse zurückkommt.
• can't find … oder connection timed out bedeutet: Die Namensauflösung funktioniert im Netz bzw. APN nicht. Das Gerät kann das Ziel dann gar nicht erst finden.

Port prüfen (nc)

nc (netcat) baut testweise eine TCP-Verbindung zum Zielport auf und trennt sie sofort wieder (-z), -v gibt das Ergebnis aus:

nc -vz consumers.mq.iot-hub.com 8883

Erwartetes Ergebnis:

Connection to consumers.mq.iot-hub.com port 8883 [tcp/*] succeeded!

Ein succeeded bedeutet, dass der TCP-Verbindungsaufbau vollständig geklappt hat: Das Anfragepaket (SYN) ist beim Ziel angekommen und dessen Antwort (SYN-ACK) wieder beim Gerät. Damit sind Hinweg und Rückweg durch die Firewall geprüft – genau die Kombination, die auch das Gerät braucht.

Was der Test nicht prüft:

• TLS und Anmeldung: Ob Zertifikatsprüfung, Benutzername/Passwort oder Topic stimmen, zeigt erst eine echte Verbindung des Geräts (bzw. der TLS-Test im MQTT-Tab unten).
• UDP: UDP kennt keinen Verbindungsaufbau und liefert keine garantierte Antwort. nc -u meldet deshalb oft Erfolg, auch wenn nichts ankommt. UDP-Verbindungen (LwM2M, Semtech UDP Packet Forwarder) werden stattdessen über die Logs geprüft.

Unter Windows leistet PowerShell dasselbe:

Test-NetConnection consumers.mq.iot-hub.com -Port 8883

Der Test ist erfolgreich, wenn in der Ausgabe TcpTestSucceeded : True steht.

Checkliste je Anbindungsart

nslookup consumers.mq.iot-hub.com
nc -vz consumers.mq.iot-hub.com 8883

Name:	consumers.mq.iot-hub.com
Address: 3.124.22.77

Connection to consumers.mq.iot-hub.com port 8883 [tcp/*] succeeded!

openssl s_client -connect consumers.mq.iot-hub.com:8883 \
  -servername consumers.mq.iot-hub.com </dev/null | grep "Verify return code"

Connecting to 3.124.22.77
depth=3 C=US, O=Internet Security Research Group, CN=ISRG Root X1
verify return:1
depth=2 C=US, O=ISRG, CN=Root YR
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=YR2
verify return:1
depth=0 CN=consumers.mq.iot-hub.com
verify return:1
DONE
    Verify return code: 0 (ok)

nslookup lwm2m.niotix.io

Name:	lwm2m.niotix.io
Address: 35.204.45.127

nslookup ns.fireflyiot.com
nc -vz ns.fireflyiot.com 443

Name:	ns.fireflyiot.com
Address: 52.59.18.61

Connection to ns.fireflyiot.com port 443 [tcp/https] succeeded!

openssl s_client -connect ns.fireflyiot.com:443 \
  -servername ns.fireflyiot.com </dev/null | grep "Verify return code"

Connecting to 52.59.18.61
depth=3 C=US, O=Internet Security Research Group, CN=ISRG Root X1
verify return:1
depth=2 C=US, O=ISRG, CN=Root YR
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=YR2
verify return:1
depth=0 CN=ns.fireflyiot.com
verify return:1
DONE
    Verify return code: 0 (ok)

nslookup fireflyiot.com

Name:	fireflyiot.com
Address: 52.59.18.61

nslookup niotix.io
nc -vz niotix.io 443

Name:	niotix.io
Address: 3.124.112.130

Connection to niotix.io port 443 [tcp/https] succeeded!

Ergebnisse deuten