Ich kann mit netcat Problemlos TCP Verbindungen zwischen meinen Laptops aufbauen, auch wenn einer davon verkabelt ist und der andere im WLAN hängt. Aber UDP geht offenbar nicht übergreifend (Ethernet<->WLAN). Ist das normal? Kann man etwas einstellen, um es zu ermöglichen? Ich habe dazu leider keine Einstellmöglichkeit gefunden.
> Ist das normal? Nein. > Kann man etwas einstellen, um es zu ermöglichen? Mach die Firewall aus. > Ich habe dazu leider keine Einstellmöglichkeit gefunden. Dann musst du nochmal suchen. Teste das ueber die 127.0.0.1 lokal! Evtl. ist nur das netcat falsch gebaut.
Du sendest vermutlich zu schnell. Wenn du über Ethernet 1GBit/s an UDP Paketen sendest, ist das klar, dass über WLAN nicht alle ankommen.
oerks schrieb: > Teste das ueber die 127.0.0.1 lokal! Der Tipp hilft mir nicht, ich möchte Daten zwischen zwei Rechnern austauschen. Zunächst zwei Laptops, später wird einer davon ein Mikrocontroller werden. > Evtl. ist nur das netcat falsch gebaut. Wie kann das sein, über Ethernet geht es ja Roland P. schrieb: > Du sendest vermutlich zu schnell. Ich sende Manuell Texte wie "Hallo" und "blabla". oerks schrieb: > Mach die Firewall aus. > Dann musst du nochmal suchen. Nee, das war es auch nicht. Auf dem Empfänger Laptop starte ich "nc -vulp 9011". Der Empfänger ist mit Ethernet und WLAN angebunden. Auf dem Sender Laptop starte ich "nc -vu 192.168.0.20 9011", um den Empfänger via WLAN zu erreichen, oder 192.168.0.139 um ihn über Ethernet zu erreichen. Der Sender ist nur per Ethernet angebunden. Wenn ich über Ethernet gehe, kann ich mehrere Zeilen Text übertragen. WLAN geht wohl doch aber nur eine Zeile Text. Danach muss ich netcat auf beiden Rechnern neu starten, dann geht wieder nur eine Zeile.
Ich habe die Firewall deaktiviert und beide Laptop im gleiche Netz (WLAN oder Ethernet, macht keinen Unterschied). So klappt die Kommunikation bidirektional, beide Rechner miteinander "chatten": A: nc -up 9033 192.168.0.20 9033 B: nc -up 9033 192.168.0.79 9033 Mit Port 9011 geht bricht die Verbindung hingegen in eine Richtung nach jeder Textzeile ab. Irgend etwas stimmt mit Port 9011 nicht, aber beide Rechner zeigen mit lsof an, dass der Port frei ist (solange nc nicht läuft). --- Nachtrag: ich wollte gerade ausprobieren, welche Ports betroffen sind. Jetzt geht es gar nicht mehr, auch nicht auf Port 9033.
Sven L. schrieb: > schau halt mal mit netstat nach, ob irgendwas den Port belegt! Ergibt nach lsof keine neuen Erkenntnisse. > Oder häng dich mal mit tcpdump mit rein. Ich habe Wireshark versucht, da sehe ich auf beiden Laptops nur die Pakete, die gesendet, bzw. erfolgreich empfangen wurden. Aus irgend einem Grund empfangen die Laptops unzuverlässig.
> So klappt die Kommunikation bidirektional, beide Rechner miteinander > "chatten": > > A: nc -up 9033 192.168.0.20 9033 > B: nc -up 9033 192.168.0.79 9033 Sehr verwunderlich. Ich glaube du hast netcat noch nicht verstanden. Datentransport ueber netcat ist immer bidirektional.
Stefan ⛄ F. schrieb: > Aus irgend > einem Grund empfangen die Laptops unzuverlässig. Probier's nochmal mit TCP aus und achte mit Wireshark darauf, ob es Retries gibt. Wenn ja, hast Du ein Problem mit Packet Loss (z.B. durch diverse WLAN-APs der Nachbarn), das fällt bei TCP bloss nicht so schnell auf, weil sich das Betriebssystem darum kümmert.
Jetzt wird es interessant. Beide Rechner sind mit WLAN und Ethernet verbunden.
1 | WLAN (wlo1) A = 192.168.0.79 B = 192.168.0.20 |
2 | Ethernet (eno1) A = 192.168.0.127 B = 192.168.0.139 |
Auf Rechner A:
1 | nc -up 9011 192.168.0.20 9011 |
Auf Rechner B starte ich:
1 | nc -up 9011 192.168.0.79 9011 |
Ich Tippe auf Rechner A "Hallo" ein, um das an B zu senden. Wireshark von Rechner A zeigt das auch an, er hat über Interface eno1 gesendet. Genau in dem Moment bricht auf Rechner B das Programm Netcat mit folgender Meldung ab: "invalid connection to [192.168.0.139] from (UNKNOWN) [192.168.0.127] 9011" Rechner B zeigt keinen Empfangen Text an. Ich wiederhole das ganze nochmal, starte auf beiden Rechner netcat neu. Dann sende ich erneut "Hallo" von A nach B. Ergebnis: Dieses mal bricht netcat auf Rechner A ohne Fehlermeldung ab. Wireshark zeigt beiden Rechnern (mit vertauschen IP Adressen) an: von 192.168.0.127 nach 192.168.0.20 UDP Len=6 "Hallo" von 192.168.0.20 nach 192.168.0.127 ICMP "Destination unreachable". Ich kann das mehrmals genau so wiederholen, es bricht jetzt immer netcat auf Rechner A ab. Das hat mich auf die Lösung gebracht: Ich muss Netcat wohl auch mitteilen, welches Interface es benutzen soll. Auf Rechner A: nc -up 9011 -s 192.168.0.79 192.168.0.20 9011 Auf Rechner B: nc -up 9011 -s 192.168.0.20 192.168.0.79 9011 Dann klappt die Kommunikation in beide Richtungen. Es klappt dann auch Netz-Übergreifend (A=Ethernet, B=WLAN): Auf Rechner A: nc -up 9011 -s 192.168.0.127 192.168.0.20 9011 Auf Rechner B: nc -up 9011 -s 192.168.0.20 192.168.0.127 9011 Was lerne ich daraus? Dass man seine Werkzeuge gut kennen soll. Letztendlich bestätigt der Test, dass in meinem lokalen Netz UDP Nachrichten von Ethernet nach WLAN und zurück ausgetauscht werden können. Das will ich am Ende machen, und zwar mit ESP822 Modulen. Geht UDP eigentlich im öffentlichen Internet auch ohne Einschränkungen (mal abgesehen dass man den NAT Router entsprechend konfigurieren muss)?
Was passiert, wenn du an beiden Rechnern mal WLAN abschaltest oder das Netzwerkkabel ziehst, so das es nur einen Pfad zum anderem Rechner gibt?
Sven L. schrieb: > Was passiert, wenn du an beiden Rechnern mal WLAN abschaltest oder > das > Netzwerkkabel ziehst, so das es nur einen Pfad zum anderem Rechner gibt? Dann tritt der Fehler nicht auf.
Stefan ⛄ F. schrieb: > Was lerne ich daraus? > Dass man seine Werkzeuge gut kennen soll. Und dass es keine gute Idee ist, einen Rechner mit 2 laufenden Interfaces im gleichen Netz zu haben, das gibt gerade in Verbindung mit DHCP eklige Resultate.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.