3
Verbindungsabbrüche OpenWRT+Digibox bei Transfers nach paar Sekunden
Hallo
Erhalte bei Datenübertragungen nach paar Sekunden Verbindungsabbrüche.
Transfers mit bspw. iperf3 oder scp brechen reproduzierbar nach ca. weniger als ~1-10s ab (connection lost, inkl. bestehender ssh Verbindungen, d.h. ssh Sitzung muss neu aufgebaut werden).
Sitze hinter zwei Routern:
- PC ist beliebig (Linux, Windows).
- Digibox: v11.01.03.103
- OpenWRT: v19.07.6 und v19.07.7
- - Konfiguration auf verschiedener Hardware verschiedener Hersteller, aber selbes Problem
- - Firewall ist für den Test offen gewesen.
- - Masquerading auf WAN ist eingeschaltet. Kein MSS Clamping.
- - Hardware+Software flow offloading aktiviert (das abzuschalten wäre auch noch ein Versuch wert)
Das folgende hingegen funktioniert (= keine Verbindungsabbrüche):
... ohne OpenWRT Router:
... im komplett anderen Netzwerk, aber mit selben OpenWRT Router:
Sprich: Erst die Kombination von OpenWRT+Digibox erzeugt das Problem.
Könnte ein Konflikt vorliegen, vielleicht wegen DHCP?
Habe bereits OpenWRT Router dynamisch DHCP-adressiert als auch statisch adressiert ins Digibox-Netz eingebunden (einmal DHCP static lease in Digibox Konfiguration, einmal manuell via OpenWRT, allerdings in den DHCP Pool der Digibox rein, aber ohne IP Konflikt), ohne Erfolg.
Hab auch mal nach der MTU geschaut. MTU ist innerhalb im Problemnetzwerk bei 1500, geht erst danach auf 1492:
Im komplett anderen, funktionierenden Netzwerk bleibt MTU durchweg bis zum externen Zielserver bei 1500.
Was könnte die Ursache sein? Welche Informationen braucht es, um das Problem besser eingrenzen zu können?
Viele Grüße und Danke im Voraus!
Edit: Versionsnummern hinzugefügt ;)
Erhalte bei Datenübertragungen nach paar Sekunden Verbindungsabbrüche.
Transfers mit bspw. iperf3 oder scp brechen reproduzierbar nach ca. weniger als ~1-10s ab (connection lost, inkl. bestehender ssh Verbindungen, d.h. ssh Sitzung muss neu aufgebaut werden).
Sitze hinter zwei Routern:
PC --> OpenWRT --> Digitalisierungsbox --> Internet- Digibox: v11.01.03.103
- OpenWRT: v19.07.6 und v19.07.7
- - Konfiguration auf verschiedener Hardware verschiedener Hersteller, aber selbes Problem
- - Firewall ist für den Test offen gewesen.
- - Masquerading auf WAN ist eingeschaltet. Kein MSS Clamping.
- - Hardware+Software flow offloading aktiviert (das abzuschalten wäre auch noch ein Versuch wert)
Das folgende hingegen funktioniert (= keine Verbindungsabbrüche):
... ohne OpenWRT Router:
PC --> Digitalisierungsbox --> InternetPC --> OpenWRT --> Kabelmodem --> InternetKönnte ein Konflikt vorliegen, vielleicht wegen DHCP?
Habe bereits OpenWRT Router dynamisch DHCP-adressiert als auch statisch adressiert ins Digibox-Netz eingebunden (einmal DHCP static lease in Digibox Konfiguration, einmal manuell via OpenWRT, allerdings in den DHCP Pool der Digibox rein, aber ohne IP Konflikt), ohne Erfolg.
Hab auch mal nach der MTU geschaut. MTU ist innerhalb im Problemnetzwerk bei 1500, geht erst danach auf 1492:
# traceroute --mtu ...
traceroute to x (x), 30 hops max, 65000 byte packets
1 OpenWRT (10.10.1.1) 0.474 ms F=1500 0.836 ms 0.455 ms
2 Digibox (192.168.2.1) 1.016 ms 1.367 ms 0.722 ms
3 ... (...) 23.517 ms F=1492 61.274 ms 48.957 ms
...Was könnte die Ursache sein? Welche Informationen braucht es, um das Problem besser eingrenzen zu können?
Viele Grüße und Danke im Voraus!
Edit: Versionsnummern hinzugefügt ;)
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 667338
Url: https://administrator.de/contentid/667338
Printed on: April 26, 2024 at 05:04 o'clock
3 Comments
Latest comment
Dann schalte mal MSS-Clamping ein.
MTU 1492 ist für PPPoE vollkommen normal (PPP-Frames haben 8 Bytes header) und teste dann nochmal.
MTU 1492 ist für PPPoE vollkommen normal (PPP-Frames haben 8 Bytes header) und teste dann nochmal.
Zwischenstand:
- MSS-Clamping brachte keinen Erfolg. Hatte das dann noch zusätzlich auch in der Digibox aktiviert (TCP/MSS-Clamping auf 1492).
- Habe dann MTU mal durchgängig auf 1492 gesetzt, mit und dann ohne Clamping, auch ohne Erfolg.
- Auch das Abschalten der og. Offloading-Optionen in OpenWRT änderte nichts.
scp mit Verbose meldet:
Teilweise friert er auch einfach nur mitten im Transfer ein oder stirbt schon nach den ersten Bytes.
Wie kann ich genauer sehen, was evtl. den Abbruch verursacht? Hab mit wireshark einen trace, alles Weitere muss ich aber erstmal verschieben.
Falls ihr aber derweil Tipps oder Hinweise habt, immer her damit
Meint ihr, das könnte evtl auch direkt an Telekom liegen und lässt sich u.U. nicht ohne Weiteres beheben?
- MSS-Clamping brachte keinen Erfolg. Hatte das dann noch zusätzlich auch in der Digibox aktiviert (TCP/MSS-Clamping auf 1492).
- Habe dann MTU mal durchgängig auf 1492 gesetzt, mit und dann ohne Clamping, auch ohne Erfolg.
- Auch das Abschalten der og. Offloading-Optionen in OpenWRT änderte nichts.
scp mit Verbose meldet:
...
debug2: channel 2: window 1966080 sent adjust 131072
debug3: send packet: type 1
client_loop: send disconnect: Broken pipe
debug3: mux_client_read_packet: read header failed: Broken pipe
debug2: Control master terminated unexpectedly
lost connectionWie kann ich genauer sehen, was evtl. den Abbruch verursacht? Hab mit wireshark einen trace, alles Weitere muss ich aber erstmal verschieben.
Falls ihr aber derweil Tipps oder Hinweise habt, immer her damit
Meint ihr, das könnte evtl auch direkt an Telekom liegen und lässt sich u.U. nicht ohne Weiteres beheben?
Lösung: Die Ursache für die Verbindungsabbrüche lag an doppelten MAC-Adressen. Ein zweiter Router im Netzwerk, der die gleiche OpenWRT Konfiguration aufgespielt bekam, hatte am WAN auch die gleichen MAC-Adressen bekommen (MAC steht ja in /etc/config/network, die gleichzeitig Teil der zu sichernden Konfiguration ist).
Ein Überschreiben der MAC in der Luci-Web-GUI unter Interfaces bewirkte seltsamerweise keine MAC-Änderung für WAN, man muss händisch in die MAC Adressen ändern.
Ein Überschreiben der MAC in der Luci-Web-GUI unter Interfaces bewirkte seltsamerweise keine MAC-Änderung für WAN, man muss händisch in
/etc/config/network