AVM fliegt aus dem Haus. Schade, ich habe denen lang die Treue gehalten.
Ich kann OpenWRT empfehlen.
Derzeit am liebsten auf TP-Link-Hardware.
Hallo Besucher, der Thread wurde 7,7k mal aufgerufen und enthält 48 Antworten
letzter Beitrag von Gerrit am
Linux und WLAN: Warum ist das immer so eine Trauergeschichte. Auch Raspi
- muellerarmack
- Erledigt
-
-
AVM fliegt aus dem Haus. Schade, ich habe denen lang die Treue gehalten.
Ich kann OpenWRT empfehlen.
Derzeit am liebsten auf TP-Link-Hardware.
Danke für den Tipp, die Lösung kannte ich in der Tat noch nicht. Ich hatte einst über pfsense nachgedacht, scheint mir aber für Heimgebrauch zu überdimensioniert zu sein. Über OpenWRT habe ich kurz recherchiert. Scheint auch mit AVM Produkten zu gehen. Was ich nicht verstanden habe: Ist es mit Freetz vergleichbar, d.h. werden "nur" Funktionen hinzugeflashed oder ersetzt es vollständig die orig Firmware. Letzteres wäre mir lieber.
-
Ich glaube ich muss eine Entschuldigung an die Linux-Gemeinde richten und ich könnt echt einen Strahl k[ZENSUR]. Nach dem Reboot der Fritze gehts nun.
Freu mich sehr, dass es nun wieder klappt! Aber kein Grund sich zu entschuldigen. FritzOS ist Linux basiert. ;D
Aber im Ernst, ich bin froh dass du den Stress hinter dir hast. Linux macht in der Regel wirklich selten Probleme mit diesen Dingen. Das hat andere Sorgen, das freie OS. Aber ich bin verliebt, und deswegen auch ein bischen blind.
-
Was ich nicht verstanden habe: Ist es mit Freetz vergleichbar, d.h. werden "nur" Funktionen hinzugeflashed oder ersetzt es vollständig die orig Firmware. Letzteres wäre mir lieber.
OpenWRT ersetzt die vorhandene Firmware vollständig. Es ist modular aufgebaut und unzählige Pakete für alle erdenklichen Funktionen können nachinstalliert werden.
Interessant finde ich auch die x86-Version zum Einsatz z. B. in virtuellen Maschinen, das kommt mit wenig RAM aus.
-
ja, was das DNS angeht verbockt das AVM schon immer. Und auch ihr Mesh ist nicht ohne Macken. Letztens eine zweite AVM 7490 als Meshrepeater eingebunden und das ging nach stundenlanger Fehlersuche auch erst, also ich den Meshmaster, die HauptFritzbox neu gestartet habe.
Die machen halt ihre Hausarbeiten nicht mehr, sondern sind eher beschäftigt mit Einbindung von Thermostaten oder Wetterinformationen auf ihren Mobiltelefonen.
-
Zwei Fritzboxen im Nezt ist auch so ein Thema, meistens danach ein Fall für zurück auf Werkseinstellungen. Das SMB Thema is auch noch nicht gelöst (Sind da aber in guter Gesellschaft mit vielen anderen Produkten)
-
Zwei Fritzboxen im Nezt ist auch so ein Thema, meistens danach ein Fall für zurück auf Werkseinstellungen. Das SMB Thema is auch noch nicht gelöst (Sind da aber in guter Gesellschaft mit vielen anderen Produkten)
Zwei???? Wer redet von zwei? Ich habe einen zentralen Router und ca. 5 Boxen die als reiner Repeater degradiert wurden. Plus noch mal eine Powerlan-Verbindung. Das funktioniert auch wirklich gut, das muss man AVM schon lassen, aber der DNS-Dienst bzw. die Verdrahtung mit der Obefläche ist seit den 10er schon immer ein graus. -
Zwei???? Wer redet von zwei?
War auf den Post davor bezogen.
... Letztens eine zweite AVM 7490 als Meshrepeater eingebunden und das ging nach stundenlanger Fehlersuche auch ....
-
Ah ja die FritzBox. An die hab ich jetzt nicht gedacht, aber stimmt, die kann manchmal schon über sich stolpern und sehr seltsame Dinge machen. Mir fällt auch wieder ein, nachdem ich das mit dem "no host to route" gelesen hab, dass ich mal dasselbe Problem hatte. Neustart der Box und alles lief wieder. DNS ist bei AVM durchaus ein Thema... die FB an sich ist ja schon ein tolles Teil, aber bei DNS verkackt AVM. Daher lass ich die DNS Geschichten von einem eigenen DNS Server machen, der nebenbei auch Pi-Hole zur Verfügung stellt. Gibt's auch für Pi's
Vielleicht ist das ne Überlegung wert, bevor du die FB wirklich rauswirfst. -
Ah ja die FritzBox. An die hab ich jetzt nicht gedacht, aber stimmt, die kann manchmal schon über sich stolpern und sehr seltsame Dinge machen. Mir fällt auch wieder ein, nachdem ich das mit dem "no host to route" gelesen hab, dass ich mal dasselbe Problem hatte. Neustart der Box und alles lief wieder. DNS ist bei AVM durchaus ein Thema... die FB an sich ist ja schon ein tolles Teil, aber bei DNS verkackt AVM. Daher lass ich die DNS Geschichten von einem eigenen DNS Server machen, der nebenbei auch Pi-Hole zur Verfügung stellt. Gibt's auch für Pi's
Vielleicht ist das ne Überlegung wert, bevor du die FB wirklich rauswirfst.Mh...leider nicht so ganz einfach die Lösung. Ich nutze in der Tat einen Pihole (übrigens auf einen Pi 1, läuft super). Mit dem vorletzten Versionssprung hat der pihole auch einen brauchbaren DNS an Board, wobei das nun wirklich keine Rocketscience ist. Eine simple Tabelle, wo ich Hostname und IP eintragen kann. In der Fritze stelle ich den DNS auf den Pihole um. Das funktioniert gut, ABER dieser Pseudo Fritz DNS läuft ja immer noch, auch wenn kein Client den verwendet, die Fritze selbst intern schon und das kriege ich ohne custom Firmware auch nicht weg.
In diesem Falle hatte die Fritze intern den PI mit .250 gespeichert. Vermutlich war das die erste Adresse bevor ich auf die statische .105 eingestellt habe. Das ist erst mal per se auch nicht schlimm. Soll die Fritze denken, was sie will, alle meine Clients gehen auf den Pihole. Dumm ist nur, das die Fritze immer noch der zentrale Switsch ist und wenn der meint .105 gibts nicht .250 aber schon, obwohl das Müll ist, dann nützt mir der lokale DNs auch nix mehr. Der löst ja nur hostname auf IP auf.
Vor 2010 kannte ich solche Bugs nicht, das kam erst zw. 10-20 auf. Je bunter die Oberfläche wurde, desto mieser die Funktionalität. Eigentlich wirklich schade, denn die Hardware kann so viel mehr und Funktionsumfang mit Telefonie, Webspace ist eigentlich wirklich toll.
Was mich in diesem Zusammenhang auch interessieren würde, da Ihr keine Problem mit Linux & Wlan habt, ob nicht auch die Fritze dafür verantwortlich ist, dass bei meinem NUC die WLAN Verbindung hin- und wieder einfriert....mmmhh
-
Dass die FB mit den IP-Adressen macht was sie will, kenn ich leider auch zu gut
Wenn man nicht von Anfang an in der FB die MAC Adresse des Pi einträgt (mit der gewünschten IP), dann gilt erstmal das, was der DHCP Server der FB vergibt - und das ist meistens nicht was man will. Ich hatte viel zu oft Probleme damit, die IP auf eine feste IP umzustellen, die FB verweigerte das. Erst nach einem Neustart der Box klappte das. AVM hat in der Hinsicht leider schlampige Arbeit geleistet.Du könntest noch auf dem Pi-Hole einen DHCP Server aktivieren (glaub ich hat Pi-Hole sogar schon drin), den in der FritzBox abschalten, und die meisten Probleme sollten weg sein. Die FB wäre dann ein reines Gateway. Ist sicher einen Versuch wert.
Parameter wären im DHCP folgende einzustellen -> DNS: IP des Pi-Hole, Gateway die FB, DHCP -> Pi-Hole. -
Dass die FB mit den IP-Adressen macht was sie will, kenn ich leider auch zu gut
Wenn man nicht von Anfang an in der FB die MAC Adresse des Pi einträgt (mit der gewünschten IP), dann gilt erstmal das, was der DHCP Server der FB vergibt - und das ist meistens nicht was man will. Ich hatte viel zu oft Probleme damit, die IP auf eine feste IP umzustellen, die FB verweigerte das. Erst nach einem Neustart der Box klappte das. AVM hat in der Hinsicht leider schlampige Arbeit geleistet.Du könntest noch auf dem Pi-Hole einen DHCP Server aktivieren (glaub ich hat Pi-Hole sogar schon drin), den in der FritzBox abschalten, und die meisten Probleme sollten weg sein. Die FB wäre dann ein reines Gateway. Ist sicher einen Versuch wert.
Parameter wären im DHCP folgende einzustellen -> DNS: IP des Pi-Hole, Gateway die FB, DHCP -> Pi-Hole.ja, guter Punkt. Darüber hatte ich auch schon nachgedacht. Ich werde aber über kurz oder lang die AVM-Kisten ausmustern.
-
Teste es einfach bevor du die FB ausmusterst, vielleicht sparst du dir damit Kosten und weiteren Ärger
Ein neuer Router muss ja auch erst eingerichtet werden, und vor allem, erst der passende gefunden werden. Das ist ja auch nicht so einfach. -
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.
-
Ich nutze eigentlich nie einen Netzwerk-Manager sondern konfiguriere es über /etc/network/interfaces (bzw. "interfaces.d/"), sowohl auf dem PC (Debian) als auch im RPi. Damit fahre ich eigentlich immer ganz gut und hatte auch nie Probleme.
Allerdings nutze ich als DHCP- und DNS-Server nicht die Fritz, sondern eine eigene dhcp/bind-Installation (die wiederum auf einem cubitruck läuft). Ich kann nicht sagen, ob das gravierende Unterschiede macht.
Probleme hatte ich mal mit einem WLAN-USB-Stick, der gerne mal zwischendurch ausstieg und nur durch Neubooten wiederzubeleben war (oder rausziehen und reinstecken). Das lag dort aber definitiv an der Hardware und/oder dem Treiber. -
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.
-
Linux-Systeme bieten so wahnsinnig viel tolles ggü. Windows, daher ist es so traurig, dass man bei "einfachen" Features anfangen muss zu frickeln.
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.
Was können die Kernel-Entwickler dafür, dass "PI OS light" es anscheinend verbockt hat?
Resultat ist das indertat Linux usb und andere nicht-datacenter hardware, keine hardware-bug-workarounds haben und nicht so stabiel functionieren.
Ich kenne das genau andersherum. Der Herstellertreiber ist voller Hacks, bekommt Resets nicht richtig hin (u.a. weil Hardware States in globalen Variablen gespeichert werden, die genau einen USB-Reset nicht mitbekommen) und ist nichtmal BE/LE-agnostisch. Wenn dann einmal fähige Kernel-Entwickler drübergeschaut haben, ist der Code nur noch ein Drittel so lang (weil sauber die Kernel-Routinen genutzt werden und nicht irgendein von Windows importierter Frickelkrams) und funktioniert auch auf allen Plattformen.
Wird also wohl auf den Hersteller und die konkreten OSS-Entwickler jeweils ankommen.
-
Was können die Kernel-Entwickler dafür, dass "PI OS light" es anscheinend verbockt hat?
In dem spziellen Fall hatte es die Fritzbox verbockt. Raspian OS trägt da keine Schuld.
-
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.
