Linux und WLAN: Warum ist das immer so eine Trauergeschichte. Auch Raspi

Quote from merlintwa

Den meisten fehrnseher sind nicht Linux, sondern Android und sind am meisten basiert auf Android apps mit unglaublich viel mehr fehler-detect und workarounds als standart Linux software.

Deckt sich nicht mit meiner Wahrnehmung.

Ich hab mal zu Android 4-Zeiten selbst an damals CyanogenMod ein paar Commits in dem Umfeld gemacht. Unter Android hat wenigstens damals auch alles WPASupplicant und Co benutzt. Ganz normaler Kram wie unter Standard-Linux auch. Nichts Besonderes. Natürlich kein Ubuntu-NetworkManager oder sowas, aber hey.

Und wenn mir jemand erzählen will, dass Android Apps im allgemeinen sauber und/oder fehlertolerant geschrieben sind, muss ich lachen, sorry. Im allgemeinen sind Apps ja wohl eher ranzig geschrieben.

Android / IOS sauber? Sicher nicht nee. Fast alles nur Junior programmer

Aber wie ich selbst oft mit meine einge apps mitgemacht habe beklagen sich Kunden uber standig-crashende apps wenn man den Garten in- und aus lauft. Das hab ich fur meine Desktop apps niemals gehort. Und, wenn es genugend leute sich beklagen wird es linksum order rechtsum ja "gepatchet". Standart Andoird Junior dev style: Alle network-events => app restart. Functioniert besser als nichts, boss = happy.

Aber die > 1Million user apps wie WhatsApp, YouTube, Browsers, banking apps, google apps, instagram, usw usw haben tatsachlich ganz complexe netzwerk-recovery sachen on-board.

Fur Linux, PC sind es in meine erfahrung nur den Browser die solche complexe netwerk sachen haben

Schau dir z.b. mal ein network-capture mit Wireshark an von ein browser wenn das netwerk fehlt. Unglaublich was es alles versucht wird wieder auf neu verbindung zu bekommen, meiner meinung jedenfals.

Kannst Du da mal konkret werden, was da Deiner Meinung nach vom Browser versucht wird? Was hat der denn mit NetworkManager und Konsorten zu tun bitte?

Das einzige, was ich mir in Sachen Browser auf der Leitung/Wireshark im Reconnect-Fall vorstellen kann, ist Rumgerödel in Sachen Capturing Portal und ggf. Session Resumption im Umfeld von HTTP3/QUIC. Hat aber beides mit WLAN-Fehlerhandling auf Treiberebene nichts zu tun.

(und nebenbei, die ganzen Google-Apps benutzen ja vermutlich eh QUIC und haben entsprechend eher kein Problem mit wechselnder Netzwerkverbindung)

Ich kann auch grundsätzlich den "heilsbringenden automatischen Reset" (im Treiber) nicht nachvollziehen. Alle WLAN-Hardware von mir läuft völlig stabil, und das ist kein teurer Krams oder so. Da kann ich morgens ein SSH aufmachen und den Tag über idlen lassen, das ist abends immer noch verbunden. Und das in der Stadt mit 20+ anderen Routern in der unmittelbaren Umgebung.

Ok, meiner erfahrung ist anders, uber stabilitat von netwerk. Waran das exact liegt, weiss ich nicht.

Fur mich ist SSH etwas wunderlich. Ich habe ein beispiel von ein 24/7 SSH - session zwichen zwei server in zwei rechencentrums in Afrika, wobei durch standige power verlust im land (auch bei den Telco) die routers ~10x pro tage restarten, und oft fur viele minuten sogar stunden down sind.

Wenn ich nichts mache, keine berichte gesendet werden, bleibt SSH functionieren ohne probleme, weil mit TCP ja default *keine* keep-alives macht. Und wen ein router power-fehlt kommen auch keine TCP Reset-packets, also beide seiten von den SSH verbindung bemerken nichts davon. Komt power wider zuruck bevor ich eine taste beruht, bleibt alles functionieren.

Stel ich aber TCP 30-sec keepalives ein, oder gibt es ein SSH mit log-file dump continue data, dan fuhrt jeden power-verlust langer als den TCP re-transmit timeout zum verlust von verbindung.

Wie das exact so functioniert? Weiss ich nicht aber ich find das ganz Komisch.

Also bei Browser, bemerk ich das bei netzwerk fehler viele sachen probiert werden, ich habe das interpretierts als:

- Zuerst wird ein normalen TCP request gemacht. Normalen Nagle-algortime sachen dabei.

- Komt dan innerhalb einige secunden kein antwort? Wird das nochmals versucht.

- Kommen OS netzwerk fehler? Dan wird abhanging von fehlercodes:

- In parallel, nochmals mit anderen source-IP versucht (ipv4/ipv6, aber auch local IPs LAN/WLAN/VPNs)

- DNS auf neu probiert, *in parallel* von meherere DNS (wenn es meherere eingestellt sind)

- HTTP-DNS versucht

- Mit OS- functionen (strace) sockets force-closed und neu opened

- Noch laufenden background requests force-closed

- Ein error-meldung gezeigt an den user, aber sonstdem noch immer weiter im backgruond neu sockets versucht zu offnen, ips heraus zu finden, und expoinential-backoff retries

- Http requests mit HTTP1.0 versucht stat 1.1

Ja wie das alles und in welcher weise und was exact das OS selbst macht und was den browser exact sebst macht das hab ich nicht vollig studiert.

Aber, normalen TCP/IP Linux/PC software ohne http libraries, bleibt oft bei ein einzelne gethostbyname anruf mit IPv4, ein ein einzige socket anruf, und das reicht fur 90% aller datacenter software. Bei ein TCP timeout wird entweder ein error gelogd und folgt kein retry, oder es folgt ein absturtz.

Quote from merlintwa

- In parallel, nochmals mit anderen source-IP versucht (ipv4/ipv6, aber auch local IPs LAN/WLAN/VPNs)

- DNS auf neu probiert, *in parallel* von meherere DNS (wenn es meherere eingestellt sind)

- HTTP-DNS versucht

Das ist doch (fast) ganz normal? Klar wird IPv4 UND IPv6 versucht (wenn der Server entsprechende DNS-Einträge hat und DNS überhaupt erreichbar war).

Unterschiedliche Interfaces durchzuprobieren halte ich eher für einen Konfigurationsfehler irgendwo. Insbesondere kann der Browser natürlich auch gar nicht die Betriebssystemrouten ändern. Wäre ja auch eine krasse Sicherheitslücke.

Falls DNS nicht geht, klar werden alle Server durchprobiert (schon vom OS bzw. den DNS-Libs).

Und DoH, klar, das gibt's halt auch (wer's noch nicht abgeschaltet hat ).

Hat aber alles mit WLAN genau gar nichts zu tun, denn das ganze Gebastel da hilft einem hängenden WLAN(-Treiber) auch nicht wieder auf die Sprünge.

So als Anekdote, über das WLAN hier hab ich aus Versehen mal per X-SSH-Forwarding einen gparted gestartet und eine 2TB-Server-Partition durch die Gegend geschoben. Das hat einen Tag gedauert - mit dem grafischen Tool dazu die ganze Zeit über SSH und WLAN. Da hab ich dann schon etwas geschwitzt. Hat aber alles geklappt.

Quote from 1570

Das ist doch (fast) ganz normal? Klar wird IPv4 UND IPv6 versucht (wenn der Server entsprechende DNS-Einträge hat und DNS überhaupt erreichbar war).

Vielleicht, ist nicht meine erfahrung. IPv6 / IPv4 support ist in viel applications "best effort" und nicht so stabiel als nur IPv4 - wird also ofter ausconfiguriert in meine erfahrung weil alles stabieler wird.

Bei ein hangenden WLAN treiber oder TCP stack, hilft doch oft um soviel moglich sockets force-closed zu machen. Das kann ein treiber ein "kick" geben. Zum beispiel weil es zufiel interne buffers offen sein, oder wenn intern auf ein mutex gewartet wird.

Force close kann nur den application selbst machen. Der TCP stack warten bis ein socket timeout passiert + 2 minuten FIN_WAIT, und macht dan noch nicht immer ein gute cleanup.

Noch so eine anekdote: Android 4 hatte damals ein apache-http-lib 1.0 im basis-OS-java set mitgeliefert. Diese lib hatte einen bug das den DNS timeout default nicht eingestellt war (also infinite timeout) und auch nicht extern vom API calls zu beeinflusen war. Das hatte viel arger bekommen, und viele app hangups verursacht genau wenn WLAN packet drops passieren bei DNS versuche.

Damals war app size viel mehr ein issue als jetzt also wird fast immer diese built-in buggy library von apps verwendet.

Mussten alle >1M user apps also die letzte version diesen library entweder selbst mitkomiplieren oder eine andere library gebrauchen.

Naja damit will ich sagen, wenn es WLAN probleme auftreten - un in meine erfahrung passierst das bei sehr viele leute, sehr oft - dan sind basis-OS sachen nicht zureichend oder daueren viel zu lang (2+ minuten)

Aber wenn ich deine berichte so lese gibt es keine WLAN dropouts in dein setup also das ist super!

Fur meine eigene long-term SSH sessions gebrach ich X2Go. X2Go is sehr sensitive fur WLAN dropouts, hab ich bemerkt, aber das Linux GUI oberflach bleibt ja functionieren wenn die verbingung fehlt also sehr gut fur solche setups. Also ganz gut fur monat oder sogar jahren-lange linux sessions.

Einge tage kann ich den ganzen tag ohne probleme mit X2Go eingelogd bleiben. Andere tage, 10 oder mehr dropouts pro tag.

Im betriebs netzwerk wenn einer meine collega's ein Windows10 update downloadet, dan fehlt x2go jeden 15 minuten. Danach bleibt es 100% functionieren den ganzen tag. Wenn ich bekabeltes netzwerk im betriebsnetzwerk gebrauche dan functioniert x2go aber fast immer ohne probleme, auch wenn windows 10 updates platzfinden.

Quote from merlintwa

Vielleicht, ist nicht meine erfahrung. IPv6 / IPv4 support ist in viel applications "best effort" und nicht so stabiel als nur IPv4 - wird also ofter ausconfiguriert in meine erfahrung weil alles stabieler wird.

Ein Problem ist bei IPv6 wohl auch, dass bei Servern, die sowohl IPv6 als auch IPv4 können, häufiger mal IPv6 kaputtgeht, ohne dass es bemerkt wird, weil die meisten Clients entweder IPv4 sind oder automatisch Fallback machen. Wenn dann ein Client auf IPv6 besteht, weil ja ein AAAA-Record da ist, hat der ein Problem.

Das mit IPv6 als Dual Stack ist einfach von Anfang an eine schlechte Idee gewesen.

Quote from merlintwa

Bei ein hangenden WLAN treiber oder TCP stack, hilft doch oft um soviel moglich sockets force-closed zu machen.

Hm. Wieso sollte das so sein? Von TCP bekommt der WLAN-Treiber doch gar nichts mit, soweit ich mich erinnere. Der reicht nur Ethernet-Frames weiter und schreibt selbst keinerlei State (auf TCP-Ebene) mit. Wäre ja auch eine furchtbare Design-Entscheidung, alle WLAN-Treiber nochmal in den TCP-Layer reinschauen zu lassen, schon aus Security-Aspekten (ein halber TCP/IP-Stack im WLAN-Treiber, großes Kino!).

Ich könnte mir vorstellen, dass das Force Close in den Applikationen gemacht wird, um die eigenen Threads zu killen, die sonst ewig (oder wenigstens sehr lange) auf Daten warten und ggf. Ressourcen blockieren bzw. auf dem einen oder anderen Mutex sitzen. Speziell bei Browsern mit ihren teilweise Single Threaded-UIs (wenigstens bei Firefox gibt's da immer noch einige Leichen im UI-Keller) kann ich mir gut vorstellen, dass das eine gangbare Notlösung ist. Aber mit dem WLAN-Treiber wird das dann weniger zu tun haben, und bei sauberer Programmierung (keinen Mutex während IO halten, Coroutinen nutzen, Timeouts setzen etc.) sollte das auch nicht nötig sein.

Falls du mal einen Stick brauchst der unter Linux funktioniert und eine externe Antenne zulässt, nimm Pollin 711929.