Portweiterleitung IoT / TcpTest Succeeded: False

Peter_aus_Kt.Bern

Ich habe eine Portweiterleitung einer fixen internen IP Adresse192.168.zzz.zzz auf 8883 eingerichtet.

Der Dynamischer DNS-Dienst der Swisscom ist aktiviert xxx.internt-box.ch

Ich nutze die Internetbox 2

Über einen Ping erreiche ich xxxx.internet-box.ch.

Über PowerShell Test-NetConnection -computername xxxx.internet-box.ch -port 8883 versuche ich den Port "Anzupingen". Ich mache dies über das Händy, so dass ich nicht im interne Netzwerk bin.

ComputerName: xxxx.internet-box.ch
RemoteAddress: 85.5.yyy.yyy
RemotePort: 8883
InterfaceAlias: WLAN
SourceAddress: 192.168.1.104
PingSucceeded: True
PingReplyDetails (RTT): 0 ms
TcpTestSucceeded: False

Fragen:

Es kommt eine Meldung TcpTest Succeeded: False zurück. Was bedeutet dies.

SourceAdresse: 192.168.1.104; wie kommt diese zu stande? Dies ist nicht die IP Adresse bei der ich die Portweiterleitung eingerichtet habe.

PowerMac

@Peter_aus_Kt.Bern schrieb:

Fragen:

Es kommt eine Meldung TcpTest Succeeded: False zurück. Was bedeutet dies.

SourceAdresse: 192.168.1.104; wie kommt diese zu stande? Dies ist nicht die IP Adresse bei der ich die Portweiterleitung eingerichtet habe.

TcpTestSucceeded: False bedeutet, dass keine TCP-Verbindung zum Zielhost aufgebaut werden konnte. Dafür kann es viele Gründe geben. Funktioniert derselbe Test wenn du im LAN bist und als Testziel direkt die IP des IoT-Geräts angibst?

Die SourceAddress gibt an, welche lokale Netzwerkadresse auf dem ausführenden Computer verwendet wurde. Dies ist deine lokale IP im Netz deines Handyhotspots. Also eigentlich genau so wie es zu erwarten ist.

Peter_aus_Kt.Bern

Hallo PowerMac

Es kommt weiterhin False. Muss man an einem anderen Ort als bei Portweiterleitungs-Regeln noch den Port "öffnen" etwas einstellen?

Test-NetConnection -computername 192.168.1.108 -port 8883
WARNUNG: TCP connect to (192.168.1.108: 8883) failed

ComputerName: 192.168.1.108
RemoteAddress: 192.168.1.108
RemotePort: 8883
InterfaceAlias: Ethernet 4
SourceAddress: 192.168.1.120
PingSucceeded: True
PingReplyDetails (RTT): 1 ms
TcpTestSucceeded: False

Antwort zur Frage mit der IP Source Adress Adresse habe ich jetzt verstanden. Danke.

PowerMac

Also sehe ich das richtig, dein IoT-Gerät hat die IP 192.168.1.108 und dein Computer die 192.168.1.120 und beide sind im selben Netzwerk? Dann ist anscheinend der Port auf dem IoT-Device nicht offen und du müsstest dort in den Einstellungen etwas ändern. Es sei denn dass das Gerät per UDP kommuniziert statt per TCP. Um was für ein Gerät handelt es sich denn?

Peter_aus_Kt.Bern

Ja, beide Geräte sind hinter dem Router im selben Netzwerk.

Ich versuche ein Gatway AL1350 von ifm via mqtt anzusprechen.

https://www.ifm.com/ch/de/product/AL1350

hed

@Peter_aus_Kt.Bern

Die Frage stellt sich, ob MQTT im Layer 4 auf TCP oder UDP aufsetzt.. Und selbst wenn MQTT auf TCP aufsetzt ist es nicht garantiert, dass dein TCP-Tester kompatibel ist zum TCP-Stack des IoT-Devices.

Was für einen TCP-Test(er) verwendest du?

Lässt sich dieser Test(er) parametrisieren?

Am einfachsten für das Troubleshooting ist es, wenn du den TCP-Test mit einem PC am Ethernet im selben LAN wie das IoT-Device machst und den Test mit dem Netzwerk-Analyzer Wireshark aufzeichnest.. So sieht man wesentlich mehr als nur ein "false".

Hast du dich schon mit ifm oder mqtt.org in Verbindung gesetzt? Dort gibt es viele technische Informationen und sicher auch einen Support und/oder eine Community.

PowerMac

@hed Wie im Thread ersichtlich ist wird hier mit dem Powershell-Kommando Test-NetConnection getestet. Neben Ping kann der Befehl auch eine TCP-Verbindung testweise aufbauen.

MQTT läuft über eine Vielzahl von Protokollen (nicht nur IP), aber in IP-Netzwerken üblicherweise via TCP/1883 (unverschlüsselt) oder eben TCP/8883 (verschlüsselt). Da TCP auf Layer 4 sitzt und MQTT auf Layer 5 ist der Test-NetConnection-Befehl schon dafür geeignet aufzuzeigen dass da kein Service auf dem angefragten Port läuft.

@Peter_aus_Kt.Bern Den MQTT-Broker deines Geräts musst du zuerst konfigurieren, was nicht ganz trivial und auch abhängig von den eingesetzten Devices ist. Schau mal das Manual des AL1350 an ab Seite 66.

hed

@PowerMac

Ich habe nicht geschrieben, dass der TCP-Test grundsätzlich nicht geeignet ist, den Test vom Handy aus zu fahren ist jedoch sicher nicht optimal.

Wie gesagt, Test von einem PC aus fahren, mit Wireshark aufzeichnen, Protokoll analysieren.

Nur so hat man den Durchblick was zw. dem Tester und dem IoT-Device auf den Layern 2, 3,4 und 5 läuft.

Die erste spannende Frage bei der Analyse ist z.B. wie das IoT-Device auf das TCP-Syn des TCP-Tests reagiert.

Aber man kann natürlich auch im Nebel stochern und an den Parametern des IoT-Devices so lange schrauben, bis die Verbindung zufällig klappt.

Peter_aus_Kt.Bern

Hallo PowerMac

Ich hatte noch gar nicht mit dem Device / Gateway getestet. Ich wollte zuerst sicher gehen, dass der Port offen ist / respektive die Portweiterleitung funktioniert. Dies wollte ich mit Powershell-Kommando Test-NetConnection erreichen. Wenn ich das richtig verstehe, dann kann ich das mit diesem Powershell Befehl und:8883 /:1883 und der Antwort False nicht beurteilen.

Ich hatte auch mit http://www.dnstools.ch/port-scanner.html versucht. Auch hier kam die Meldung, dass der Port geschlossen ist.

Wireshark habe ich mir einmal runtergeladen (scheint etwas grösser zu sein). Hier muss ich mich zuerst schlau machen, welche Knöpfe ich drücken muss um zu sehen, ob MQTT durch meinen Router geht.

Danke erst einmal für die Hilfe.

PowerMac

@Peter_aus_Kt.Bern schrieb:

Hallo PowerMac

Ich hatte noch gar nicht mit dem Device / Gateway getestet. Ich wollte zuerst sicher gehen, dass der Port offen ist / respektive die Portweiterleitung funktioniert. Dies wollte ich mit Powershell-Kommando Test-NetConnection erreichen. Wenn ich das richtig verstehe, dann kann ich das mit diesem Powershell Befehl und:8883 /:1883 und der Antwort False nicht beurteilen.

Doch, deine Vorgehensweise war gar nicht verkehrt. Wenn Test-NetConnection das obige Ergebnis ausgibt, dann ist der Port nicht erreichbar. Das Einzige was du mit Wireshark zusätzlich herausfinden kannst ist, wie weit die TCP-Verbindung aufgebaut wird bzw. welche Antwort geschickt wird (im Firewall-Jargon "Blocked" vs. "Filtered").

Ich hatte auch mit http://www.dnstools.ch/port-scanner.html versucht. Auch hier kam die Meldung, dass der Port geschlossen ist.

Wireshark habe ich mir einmal runtergeladen (scheint etwas grösser zu sein). Hier muss ich mich zuerst schlau machen, welche Knöpfe ich drücken muss um zu sehen, ob MQTT durch meinen Router geht.

Danke erst einmal für die Hilfe.

Aaaaalso ich hab mir jetzt mal die Mühe gemacht das Handbuch zu lesen. Dort drin steht auf Seite 66: "Der IoT Core kann über die MQTT-Verbindung Daten veröffentlichen (publish)." Dh. es handelt sich offenbar um einen reinen MQTT-Client, der nur Publish-Funktionalität beherrscht (ohne Subscribe). Und damit ist auch klar, dass das Gerät keine eingehenden MQTT-Verbindungen akzeptieren wird. Letzteres tut nur ein MQTT-Broker. Wenn du einen solchen benötigst, wirst du den auf einem separaten Gerät betreiben müssen. Dazu reicht schon ein Raspberry Pi oder etwas ähnliches.

Somit wird das Portforwarding vom Router auf dein AL1350 nichts bringen, und du kannst dir auch das aufwändige Herumstochern im Nebel mit Wireshark ersparen.

Peter_aus_Kt.Bern

Hallo PowerMac

Danke für die Aufklärung (peinlich für mich).

Ich hatte mir vorgestellt, dass der MQTT Broker (BSP: Azure IoT Hub) die Kommunikation Richtung Client (AL1350) eröffnet (Anfrage / Request) und der Client gemäss den "Anweisungen" dann antwortet (Response). So hatte ich die Beispiele ab Seite 67 interpretiert.

Beispiel: Temperatur an MQTT-Broker veröffentlichen

Aufgabe: Temperatur des IO-Link Masters an einen MQTT-Broker veröffentlichen (IP-Adresse MQTT-Broker: 192.168.82.100, Port: 1883, Topic: abc).
Lösung:
• Anfrage (Request):
{ "code":"request", "cid":-1, "adr":"/timer[1]/counter/datachanged/subscribe", "data":{ "callback":"mqtt://192.168.82.100:1883/abc", "datatosend":["processdatamaster/temperature"} }
• Antwort (Response):
{ "cid":-1, "code":200 }

PowerMac

Kein Problem, so lernt man immer wieder was neues 😉

Eigentlich ist genau dieses Konzept einer der Gründe warum MQTT so erfolgreich ist. Wenn die Sensoren einmal konfiguriert sind brauchen sie bloss noch einen (fast) beliebigen Internetzugang. Um Portforwardings etc. braucht man sich gar nicht mehr zu kümmern. Und dank Azure IoT Hub ist nicht mal mehr ein lokaler Raspi nötig.

Ich wünsche dir viel Erfolg mit deinem Projekt. Cool dass du IoT nutzt 👍