Jan Ritzerfeld schrieb:
OK, sagen wir es präziser: Das zweite Byte im IP-Header ist 0x10. Woran sehe ich denn, ob das ToS oder DSCP/ECN ist?
Gar nicht. Also außer so wie du es gemacht hast:
Wenn ich annehme, dass es DSCP ist, dann ist das eigentliche DSCP die oberen 6 Bits von 0x10, also 0x4, und das ist in der DSCP-Definition nicht definiert?!
Korrekt.
Also ist es ToS, und 0x10 ist sozusagen die ToS-Weise "low delay" zu fordern.
Ich kann es hier lokal aber auch nachvollziehen. openSUSE scheint das rausgepatcht zu haben, es war jedenfalls mal in der 15.1 aktiv: https://lists.opensuse.org/opensuse-factory/2019-05/msg00008.html
Das könnte natürlich das Verhalten erklären, ibs. warum bei den selbst-compilierten Varianten DSCP aktiv ist. Ich hab auch mal in das Source-RPM reingespickt, da finde ich keinen solchen Patch, aber die Source-RPMs sind ja vom Release-Stand (also Mai 2019) und da könnte DSCP noch drin gewesen sein.
Im fraglichen Zeitraum (November 2018 bis Januar 2019) gab es von OpenSuse nur kleinere Patches innerhalb der 7.6er Version. Und ich bin ziemlich sicher, dass ich das Problem im Januar 2019 nach einem längeren Urlaub schon hatte und relativ sicher, dass es in 2018 noch nicht aufgetreten ist.
Vielleicht ein Update der Router-Firmware?
Kann ich nicht ausschließen. Es handelt sich um eine Fritzbox, die so eingestellt ist, dass sie sich selber updated. Ähnliche Probleme werden übrigens hin und wieder ibs. in Verbindung mit der Fritzbox gemeldet, wie meine Recherche ergeben hat, aber ohne dass die Ursache erklärt wird. Es wird dann meist eben "ssh -o IPQoS=0" empfohlen (oder der entsprechende Eintrag in der ssh_config, was wohl der "richtigste" Weg ist) oder auch (funktional sicher gleichwertig) "iptables -t mangle ... --set-tos 0", meist tatsächlich mit der 0. "ssh -o IPQoS=0" beeinflusst übrigens nur die ausgehenden Pakete des Clients (in dem Fall der Laptop), aber möglicherweise ist das schon ausreichend. Es gibt aber auch eine entsprechende Option für die sshd_config des PCs, die ich noch "ziehen" könnte, falls man das in der anderen Richtung auch brauchen sollte. Bislang sind alle Tests mit IPQoS=0 gut gegangen, aber ich will nicht zu früh jubeln.
Oh, da fällt mir ein, es gibt ja auch noch WMM, also QoS direkt im "WLAN", das die Pakete tatsächlich auf TCP-Ebene analysiert und einordnet: http://wifi-insider.com/wlan/wmm.htm https://wireless.wiki.kernel.org/en/developers/documentation/mac80211/queues Du könntest das also mit iperf mal versuchen nachzustellen, also passende Pakrtgröße und TOS-Feld.
Danke, werd ich mir auch mal anschauen.
Ja, ist bei mir auch so. Den neuen Standardwert für IPQoS bekommst du mit: ssh -o IPQoS="af21 cs1" ... Ich würde das auch mal testen, also statt IPQoS=0.
Mach ich, wenn klar ist, dass es mit der 0 funktioniert. Andererseits dürfte die 0 schon der defensivste Weg sein, denn dann werden die ssh-Pakete sicher so behandelt wie alle anderen und die haben ja keine Probleme. Und sooo viel Last hat mein Wohnzimmer-LAN nun auch nicht, dass ich da unbedingt QoS bräuchte... Aber mal sehen, vielleicht sind wir ja schon auf dem richtigen Weg! -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org