Posts from merlintwa in thread "Linux und WLAN: Warum ist das immer so eine Trauergeschichte. Auch Raspi"

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.

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.

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.

Quote from 1570

Ist das so? Dein Android (also Linux) hat einwandfrei funktionierendes WLAN, Deine Fritzbox (also Linux) hat einwandfrei funktionierendes WLAN, Dein Fernseher (also Linux) hat einwandfrei funktionierendes WLAN.umchal

Wird also wohl auf den Hersteller und die konkreten OSS-Entwickler jeweils ankommen.

Android hat so gut functionierenden WLAN weil das umschalten zwitchen 3G/4G basestations und wifi ein fundamentelen basis function ist was ganz viel und mit unglaublich viel aufwand getestet wird.

Alle pro- android/IOS developers wissen wieviel muhe man machen muss alle OS-events rundum netzwerk-anderungen bei zu halten usw, und wie anders es ist fur Android/IOS ein always-connected app zu bauen als fur PC / Linux - mit netzwerk retries, 100en von fehlertypen usw.

Fritzbox hat *selbts* vielleicht als AP gutes WLAN, das reicht leider nicht fur den combination von client + Fritzbox.

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.

Zum beispiel: Fast alle linux software macht ein Berkley-sockets "bind" anruf beim aufstarten. Das functioniert leider *nicht* wenn dein IP etwas spater andert. Fur Linux, PC apps unterstuzten fast alle apps keine IP anderunden weil das program lauft, mus neu gestartet werden

Fur android, IOS, unterstutzen fast *alle* apps IP anderungen weil das program lauft, oder her-startet das app sichselbst immer.

Uber treiber, du hast recht, hangt ab von hersteller und entwickler.

Aber am meisten hangt das ab von *gut documentierten* hardware-probleme, so das ein entwickler dafur ein work-around machen kann. Genau diese "Documentation errata" sind enorm seldsam, weil es ja den Hersteller nichts bringt solche documente zo produzieren und damit seine eigene fehler zu zeigen.

Genau das ist das unterschied zwischen die meisten vendors, und auf welchen markets sie producten machen.

ST und NXP haben gute reputation for hobbyisten weil sie solche documentation von hardware-fehler machen.

Ich habe mich schon ofter den x86-code von mehrere USB-modul treiber wie WLAN, GSM usw in Windows angeschaut.

Was seht man: Genau wie man sich gedacht hatte, gibt es oft ein USB-device crash-detector im treiber. Und wenn so ein crash detectiert wird, sendet den PC ein magic-combo von bytes zur USB-WLAN device das das ding ein hard-reset durchgeht und auf neu gestartet wird.

Die open-source treiber fur linux, sind meistens nicht von dieselbe teams gefertigt als die Windows treiber, sondern von freiwilliger. Solche treiber machen meistens nicht solche not-losungen wie die closed-source treiber machen.

Resultat ist das indertat Linux usb und andere nicht-datacenter hardware, keine hardware-bug-workarounds haben und nicht so stabiel functionieren.

Sorry my german isn't good enough for this topic,

<rant>Linux and WLAN are really really terrible. I have had only issues with that, forever and ever. I have stopped even trying to use Linux with WLAN anymore its just not worth the pain</rant>

Anyway after also 15 years of Linux on laptops, servers, VM's, docker, and windows on laptops, servers, openWRT , pfSense and windows AD work, synology and other NAS stuff, the picture that slowly appears is that all vendors making devices (like fritzbox, like ISP routers, MS and so on) basically make lots of features available and then prodoction-test it in plugfests *only for common configurations*.

So just have a setup that isnt to spectacularily unique and chances are very good you'll have no issues.

Now in my opinion real reason why Windows has far less issues than linux are:

- Windows is tested with off-the-shelf routers in Microsoft during development, internal at Microsoft and publicly at so-called "vendor plugfests".

At a plugfest, happen every year or so, router, PC, network vendors are all allowed to bring their latest devices, they wire them all up and see if it works.

Many issues are detected and future direction of WLAN protocols are designed based on the outcome.

Very common buggy-hardware routers (sold in the millions) are accepted as part of the design, and Windows has a lot of fall-back disable-then-reenable WLAN stuff going on of 10 different types to work around known, very common buggy routers customers have.

- Windows WLAN itself is pretty buggy. For backwards compatibilty and to avoid having to fix decades old problems, the developer focus is on making the WLAN stop/re-lease/restart sequence as seamless as possible so windows apps never even realise or are even notified it happened.

- Linux on the other hand started off with *no* support of any kind of network hotplug stuff and *no* support for buggy routers. Long ago once kicked off the network you have to reconnect yourself manually.

- All Linux server high-availability server stuff, *has* to work like that, no network manager stuff as in a datacenter a drop of network is more likely to be a hardware failure than a software failure. Something like network manager on a server, will kill the 99.95% uptime of the server. So most of the linux kernal and surrounding code is really meant for complex, configure-once networking.

- The more modern network managers in laptop distros has the same sort of WLAN recovery as windows - but it has not gone through those Windows plugfests with various manufacturors and the need to work with buggy routers.

Linux can never catch up to windows without some type of similar process.

So for me, I have given up on linux with WLAN on laptops.

My advice:

- Try to stick to something very common, highest chance it will have been tested.

- Avoid WLAN for anything except laptops, phone

- OpenWRT but know its limitations and stability (similar to default firmware for most brands)

- pfSense if you are more interested in the firewall/network stack/virtual nets and whatnot. Its not much better for WLAN than OpenWRT.

- Accept WLAN cannot compete with fixed wire for stability

- Linux on laptop: Have a good network manager that can do the disconnect/reconnect stuff with as little as possible impact on apps.

Specific to WLAN is that there are a lot of known issues where AP routers of different brands in close proximity to each other (like your and your neighbours router, or if you have different brands) can strongly interfere causing WLAN to kick a device off of the AP every few minutes.

Its extremely hard to design for such issues as it is caused by random alignment of processing - this kind of thing is usually exactly found during vendor plugfests. The low-end brands typically don't go to such plugfests, or just dont care, meaning even high-end equipment can easily be affected by a low-end device nearby. And complexity of interactions with Bluetooth and other signals in the wifi bands is so high it will never be perfect.

OpenWRT is my preferred solution, but has its own set of unique challenges. Complex setups are possible but not super stable. The GUI is pretty messy for high-end usecases (I have multi-WAN, IP failover, 100s of DNS leases - the device is way overstressed). The device needs a reset every month or so on average.