Weiteres intermittierendes WLAN-Problem
Nachdem ich mein langwieriges Problem mit dem "unzuverlässigen" WLAN-Verbindungsaufbau auf meinem Laptop vor einigen Wochen lösen konnte, habe ich mich jetzt einem anderen Problem zugewandt, was leider immer noch existiert. Wenn ich den Laptop bei mir zuhause ins WLAN einbuche, gibt es ab und zu die Notwendigkeit, ein ssh auf meinen Desktop-PC (mit LAN-Anbindung an den Router) zu machen. Genau dabei beobachte ich intermittierende "Hänger" mit einer Dauer von manchmal wenigen Sekunden, manchmal aber bis zu 2 Minuten. Beide Rechner haben ein aktuell gehaltenens OpenSuse, mittlerweile also 15.1. Im tcpdump sind dann Paketverluste zu sehen: Die Pakete, die der Laptop schickt, kommen nicht auf dem PC an und/oder umgekehrt und werden daher wiederholt, bis sie irgendwann dann doch wieder durchkommen. Weder das Netzwerk noch die CPU sind zu dem Zeitpunkt saturiert. Das Problem scheint mit einer besonders hohen Wahrscheinlichkeit in den ersten Minuten nach dem Einbuchen aufzutreten. Später scheint sich das wieder "einzurenken"? Was auch spannend und seltsam ist: Es scheint nur ssh betroffen zu sein und oft auch nur eine von eventuell mehreren parallel bestehenden ssh-Sitzungen - die anderen laufen problemlos durch und ein eventuell parallel laufender ping zeigt normale Latenzen und keinen Paketverlust! Also kann es ja eigentlich nicht am WLAN-Treiber und auch nicht am Router, an dem ich mich einbuche, liegen, denn die wissen ja nix von Sessions auf der TCP-Ebene. Es sieht mir am ehesten nach einem Fehler in openssh aus, aber wieso tritt der dann nur auf, wenn einer der beteiligten Rechner über WLAN angebunden ist? Im LAN beobachte ich den Fehler nie! Ach ja, angefangen hat das Ganze recht plötzlich, wenn ich mich richtig entsinne, Anfang 2019 oder Ende 2018. Vielleicht durch einen Update, der damals reinkam. Kennt jemand das Problem oder hat jemand noch irgendeine Idee, wie man das eingrenzen könnte? Ich sehe mich selber zwar durchaus als "Netzwerker" an, bin bei dem Problem aber doch ein bisschen ratlos... -- 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
Manfred Haertel, DB3HM schrieb:
Was auch spannend und seltsam ist: Es scheint nur ssh betroffen zu sein und oft auch nur eine von eventuell mehreren parallel bestehenden ssh-Sitzungen - die anderen laufen problemlos durch und ein eventuell parallel laufender ping zeigt normale Latenzen und keinen Paketverlust! Also kann es ja eigentlich nicht am WLAN-Treiber und auch nicht am Router, an dem ich mich einbuche, liegen, denn die wissen ja nix von Sessions auf der TCP-Ebene.
Nachdem ich den Post vorhin abgeschickt habe, habe ich durch Googlen noch einen interessanten Hinweis gefunden, der zumindest im Ansatz logisch klingt: Es könnte am "Quality of Service" liegen. Denn openssh scheint sowas zu setzen, und zwar wird anscheinend das ToS-Feld im IP-Header auf 0x10 gesetzt. Bei anderen Paketen, die der Laptop aussendet, ist das nicht so, da bleibt ToS auf 0x0. Was könnte nun aber meinen Router veranlassen, solche Pakete manchmal zu verwerfen, wenn sie über WLAN kommen? Probehalber habe ich mal mit "ssh -o IPQoS=0" getestet, das wäre dann wohl ein möglicher Workaround, da ist das Problem nicht aufgetreten. Da es aber ein intermittierendes Problem ist, ist das natürlich kein Beweis, dass diese Spur richtig ist (mein intermittierendes WLAN-Einbuchungs-Problem war ja auch nach einer Änderung tagelang weg und ist dann wieder gekommen). Und außerdem möchte ich das Problem auch verstehen... -- 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
Am Montag, 11. November 2019, 09:54:34 CET schrieb Manfred Haertel, DB3HM:
(...). Denn openssh scheint sowas zu setzen, und zwar wird anscheinend das ToS-Feld im IP-Header auf 0x10 gesetzt. Bei anderen Paketen, die der Laptop aussendet, ist das nicht so, da bleibt ToS auf 0x0.
Wirklich das ToS-Feld? Eigentlich sollte seit der Version 7.8 stattdessen der Nachfolger DSCP benutzt werden. Diese Version ist Ende August 2018 erschienen, das würde sogar zu deinem "Anfang 2019 oder Ende 2018. Vielleicht durch einen Update, der damals reinkam." passen.
Was könnte nun aber meinen Router veranlassen, solche Pakete manchmal zu verwerfen, wenn sie über WLAN kommen?
Wenn du nicht geschrieben hättest, dass dein openssh weiterhin ToS benutzt, dann hätte ich vermutet, dass dein Router Probleme mit DSCP hat weil er es noch nicht kennt oder falsch interpretiert und so eine seiner Queues einfach vollläuft ...
Probehalber habe ich mal mit "ssh -o IPQoS=0" getestet, das wäre dann wohl ein möglicher Workaround, da ist das Problem nicht aufgetreten.
Hast du vielleicht in irgendeiner ssh-config IPQoS bereits gesetzt?
Da es aber ein intermittierendes Problem ist, ist das natürlich kein Beweis, dass diese Spur richtig ist (mein intermittierendes WLAN-Einbuchungs-Problem war ja auch nach einer Änderung tagelang weg und ist dann wieder gekommen). Und außerdem möchte ich das Problem auch verstehen...
Ja, ist auf jeden Fall wieder einmal spannend! :) Gruß Jan -- The solving of a problem lies in finding the solvers. -- 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
Jan Ritzerfeld schrieb:
Denn openssh scheint sowas zu setzen, und zwar wird anscheinend das ToS-Feld im IP-Header auf 0x10 gesetzt. Bei anderen Paketen, die der Laptop aussendet, ist das nicht so, da bleibt ToS auf 0x0.
Wirklich das ToS-Feld? Eigentlich sollte seit der Version 7.8 stattdessen der Nachfolger DSCP benutzt werden.
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? 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?!
Diese Version ist Ende August 2018 erschienen, das würde sogar zu deinem "Anfang 2019 oder Ende 2018. Vielleicht durch einen Update, der damals reinkam." passen.
Passt leider nicht so ganz. Wenn ich mir das in /var/log/zipp/history betrachte, ist der Sprung von openssh 7.6 auf 7.9 mit dem Update von OpenSuse von 15.0 auf 15.1 im Mai passiert. 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.
Wenn du nicht geschrieben hättest, dass dein openssh weiterhin ToS benutzt, dann hätte ich vermutet, dass dein Router Probleme mit DSCP hat weil er es noch nicht kennt oder falsch interpretiert und so eine seiner Queues einfach vollläuft ...
Denkbar, dass das ein Missverständnis zwischen ToS und DSCP ist (das würde ich aber gern genauer verstehen). Auch denkbar, dass irgendeine Queue vollläuft, das würde die intermittierende Eigenschaft des Problems erklären, aber in meinem WLAN ist zum fraglichen Zeitpunkt auch nicht wirklich viel los...
Probehalber habe ich mal mit "ssh -o IPQoS=0" getestet, das wäre dann wohl ein möglicher Workaround, da ist das Problem nicht aufgetreten.
Hast du vielleicht in irgendeiner ssh-config IPQoS bereits gesetzt?
Nicht bewusst. Und grade auch noch mal kontrolliert, nein, ist nicht explizit gesetzt. -- 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
Manfred Haertel, DB3HM schrieb:
Wirklich das ToS-Feld? Eigentlich sollte seit der Version 7.8 stattdessen der Nachfolger DSCP benutzt werden.
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?
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?! Hmm... Wenn ich ein ssh -vvv mache, schreibt mir ssh aus:
debug3: ssh_packet_set_tos: set IP_TOS 0x10 was ich ja auch schon mit Wireshark gesehen habe. Jetzt habe ich mir grade mal das aktuelle openssh 8.1 selbst compiliert und siehe da: debug3: ssh_packet_set_tos: set IP_TOS 0x48 Fragt sich jetzt, woher dieser Unterschied kommt... -- 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
Am Montag, 11. November 2019, 14:03:40 CET schrieb Manfred Haertel, DB3HM:
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. 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
(...). Passt leider nicht so ganz. Wenn ich mir das in /var/log/zipp/history betrachte, ist der Sprung von openssh 7.6 auf 7.9 mit dem Update von OpenSuse von 15.0 auf 15.1 im Mai passiert.
Stimmt.
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?
(...). Denkbar, dass das ein Missverständnis zwischen ToS und DSCP ist (das würde ich aber gern genauer verstehen).
Ich befürchte, dass ohne die Firmware deines Routers im Quelltext zu kennen, wir da nicht viel verstehen können. Es sei denn du hast lokal noch eine Firewall laufen die irgendwie auf das ToS-Feld reagiert.
Auch denkbar, dass irgendeine Queue vollläuft, das würde die intermittierende Eigenschaft des Problems erklären, aber in meinem WLAN ist zum fraglichen Zeitpunkt auch nicht wirklich viel los...
Und wenn der Router da einfach eine total unpassende Queue auswählt, die vielleicht nur super wenig Bandbreite zulässt oder nur drei gleichzeitige Verbindungen? 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.
(...). Nicht bewusst. Und grade auch noch mal kontrolliert, nein, ist nicht explizit gesetzt.
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. Gruß Jan -- Facts do not cease to exist because they are ignored. -- 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
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
Am Montag, 11. November 2019, 18:35:05 CET schrieb Manfred Haertel, DB3HM:
(...). Also ist es ToS, und 0x10 ist sozusagen die ToS-Weise "low delay" zu fordern.
Ja, den Unterschied siehst du mit IPQoS="af21 cs1" in Wireshark. Ich kenne das noch von iptables, da gab es beispielsweise --set-tos aber jetzt wohl auch set-dscp.
(...). Das könnte natürlich das Verhalten erklären, ibs. warum bei den selbst-compilierten Varianten DSCP aktiv ist.
Ja, dieses Posting von dir hatte ich erst nach dem Abschicken gelesen.
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.
Ich habe auf build.opensuse.org nachgeguckt, da sieht man auch die Maintenance-Updates, aber mir ist kein Patch anhand des Namens aufgefallen, in alle reingeguckt habe ich dann auch nicht, es reicht ja zu wissen, dass sich die openSUSE-Version anders als Upstream verhält. Und das "absichtlich" weil auch "man ssh_config" dazu passt.
(...). Kann ich nicht ausschließen. Es handelt sich um eine Fritzbox, die so eingestellt ist, dass sie sich selber updated.
Okay, ich hab auch eine und bin mir nicht sicher, ob das QoS der Fritzbox nicht sowieso nur fürs Internet gilt. Das würde dann eher für Probleme mit WMM sprechen. Und an irgendwelche Probleme mit IP-TV und WMM und der Fritzbox erinnere ich mich dunkel ...
Ä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.
Wahrscheinlich sind die meisten schon dann glücklich wenn es einfach wieder funktioniert. Und wenn da auch noch WMM mit all seinen Optionen mitspielt wird das ja nicht gerade einfacher die tatsächliche Ursache herauszufinden (vom Funk selbst mal ganz abgesehen).
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.
Gefühlt würde ich "none" benutzen wollen allein weil das so schön selbstbeschreibend ist.
"ssh -o IPQoS=0" beeinflusst übrigens nur die ausgehenden Pakete des Clients (in dem Fall der Laptop), aber möglicherweise ist das schon ausreichend.
Ja, mein NAS mit dem ich getestet habe sendet ja weiter ToS (weil älteres openssh), davon habe ich mich zuerst in Wireshark verwirren lassen (wieso ändert sich mit IPQoS jetzt garnix?).
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.
Korrekt.
Bislang sind alle Tests mit IPQoS=0 gut gegangen, aber ich will nicht zu früh jubeln.
;)
(...). Danke, werd ich mir auch mal anschauen.
Und dann gibt es noch U-APSD (Unscheduled Automatic Power Save Delivery) als Teil vom WMM, bei dem der AP Daten zwischenspeichert, sodass das Endgerät kurzeitig in den Energiesparmodus wechseln kann. Wär ja sonst zu einfach. Aber ich weiß nicht, ob die Fritzbox das kann.
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.
Klar! Aber wenn der "Sonderweg" von openSUSE Probleme mit der Fritzbox macht und Upstream nicht, dann wär das schon nen Bug-Report wert.
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...
Mein 2,4-GHz-WLAN hat auch nicht soviel Last, aber durch die gefühlten 60 Nachbars-Netze kann ich darüber nicht zu jeder Zeit Musik streamen, vor allem wenn nur der Client beide Basisstationen hören kann (hidden station problem).
Aber mal sehen, vielleicht sind wir ja schon auf dem richtigen Weg!
Jedenfalls habe ich mal wieder viel gelernt. :-D Gruß Jan -- Character is what you know you are, not what others think you are. -- 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
Hallo Am 11/11/2019 um 19.24 schrieb Jan Ritzerfeld:
Ich habe auf build.opensuse.org nachgeguckt, da sieht man auch die Maintenance-Updates, aber mir ist kein Patch anhand des Namens aufgefallen, in alle reingeguckt habe ich dann auch nicht, es reicht ja zu wissen, dass sich die openSUSE-Version anders als Upstream verhält. Und das "absichtlich" weil auch "man ssh_config" dazu passt.
kann es das sein: openssh-8.1p1-1.1.src.rpm Patch35: openssh-7.9p1-revert-new-qos-defaults.patch commit 101aa2f70c937abb428c9433c39ba0fd9a91fe6b Author: Hans Petter Jansson <hpj@cl.no> Date: Thu Jun 20 23:54:11 2019 +0200 Revert IPQoS DSCP AF21/CS1 from upstream due to bugs in other software .... Reverts OpenBSD-Commit-ID: d11d2a4484f461524ef0c20870523dfcdeb52181 Holger -- 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
Am Montag, 11. November 2019, 19:41:25 CET schrieb Holger Bruenjes:
Hallo
Am 11/11/2019 um 19.24 schrieb Jan Ritzerfeld:
Ich habe auf build.opensuse.org nachgeguckt, da sieht man auch die Maintenance-Updates, aber mir ist kein Patch anhand des Namens aufgefallen, in alle reingeguckt habe ich dann auch nicht, es reicht ja zu wissen, dass sich die openSUSE-Version anders als Upstream verhält. Und das "absichtlich" weil auch "man ssh_config" dazu passt.
kann es das sein: (...). Patch35: openssh-7.9p1-revert-new-qos-defaults.patch (...). Revert IPQoS DSCP AF21/CS1 from upstream due to bugs in other software .... Reverts OpenBSD-Commit-ID: d11d2a4484f461524ef0c20870523dfcdeb52181
Ja, ist es. Danke! Keine Ahnung warum ich den Patch trotz des sprechenden Namens nicht gefunden habe. Der ist nämlich auch im Update für die 15.1. X-) Gruß Jan -- The trouble with the rat race is that even if you win, you're still a rat. -- 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
Am Mon, 11 Nov 2019 08:48:34 +0100 schrieb "Manfred Haertel, DB3HM" <Manfred.Haertel@rz-online.de>:
Nachdem ich mein langwieriges Problem mit dem "unzuverlässigen" WLAN-Verbindungsaufbau auf meinem Laptop vor einigen Wochen lösen konnte, habe ich mich jetzt einem anderen Problem zugewandt, was leider immer noch existiert.
Wenn ich den Laptop bei mir zuhause ins WLAN einbuche, gibt es ab und zu die Notwendigkeit, ein ssh auf meinen Desktop-PC (mit LAN-Anbindung an den Router) zu machen. Genau dabei beobachte ich intermittierende "Hänger" mit einer Dauer von manchmal wenigen Sekunden, manchmal aber bis zu 2 Minuten. Beide Rechner haben ein aktuell gehaltenens OpenSuse, mittlerweile also 15.1.
Im tcpdump sind dann Paketverluste zu sehen: Die Pakete, die der Laptop schickt, kommen nicht auf dem PC an und/oder umgekehrt und werden daher wiederholt, bis sie irgendwann dann doch wieder durchkommen. Weder das Netzwerk noch die CPU sind zu dem Zeitpunkt saturiert.
Das Problem scheint mit einer besonders hohen Wahrscheinlichkeit in den ersten Minuten nach dem Einbuchen aufzutreten. Später scheint sich das wieder "einzurenken"?
Was auch spannend und seltsam ist: Es scheint nur ssh betroffen zu sein und oft auch nur eine von eventuell mehreren parallel bestehenden ssh-Sitzungen - die anderen laufen problemlos durch und ein eventuell parallel laufender ping zeigt normale Latenzen und keinen Paketverlust! Also kann es ja eigentlich nicht am WLAN-Treiber und auch nicht am Router, an dem ich mich einbuche, liegen, denn die wissen ja nix von Sessions auf der TCP-Ebene.
Versuche es einmal mit iwlist(8) oder iwspy(8). das liefert vielleicht einen Hinweis. Also zB. iwlist scan, oder iwspy getthr.
Es sieht mir am ehesten nach einem Fehler in openssh aus, aber wieso tritt der dann nur auf, wenn einer der beteiligten Rechner über WLAN angebunden ist? Im LAN beobachte ich den Fehler nie!
Bei ssh versuche mal Debugging mit ssh -vv. [...] -Dieter -- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E -- 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
Dieter Klünter schrieb:
Versuche es einmal mit iwlist(8) oder iwspy(8). das liefert vielleicht einen Hinweis. Also zB. iwlist scan, oder iwspy getthr.
iwspy funktioniert leider nicht mit dem Broadcom-WL-Treiber. iwlist funktioniert, aber mir fällt da leider nichts auf.
Bei ssh versuche mal Debugging mit ssh -vv.
Auch da leider gar nichts auffälliges zum fraglichen Zeitpunkt. -- 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
participants (4)
-
Dieter Klünter -
Holger Bruenjes -
Jan Ritzerfeld -
Manfred Haertel, DB3HM