
🌐 Auch auf: English · Français · Español
Jedes Homelab erreicht irgendwann den Punkt, an dem dir die Server zum Kaputtmachen ausgehen und du anfängst, den Router schief anzuschauen. Meiner ist eine FRITZ!Box 7690, die still vor sich hin WLAN und Internet macht, nie wirklich geprüft, nie wirklich hinterfragt. Eines Abends dachte ich mir: Warum nicht Claude die Zugangsdaten geben und schauen, was dabei rauskommt? Eine Regel, nicht verhandelbar: nur schauen, nichts anfassen. Keine Änderungen, nur eine ehrliche Inspektion.
Was zurückkam, war spannender als erwartet – und belegt mit echten Router-Logs, nicht mit Bauchgefühl. 🧾
🔑 Höflich reinkommen
Erstes nettes Detail: Die FRITZ!Box fragt das Passwort nie über die Leitung ab – kein einziges Mal. Statt „Sag mir dein Passwort, damit ich es prüfen kann“ spielt sie ein kleines Prüfspiel: Zuerst schickt die Box ein zufälliges Puzzleteil rüber. Das Passwort wird mit diesem Puzzleteil vermischt, zehntausende Male durch einen absichtlich langsamen Verwürfelungsprozess gejagt, und nur das verwürfelte Ergebnis geht zurück – nie das Passwort selbst. Die Box macht auf ihrer Seite exakt dieselbe Verwürfelung mit dem Passwort, das sie gespeichert hat, und wenn beide Ergebnisse übereinstimmen, bist du drin.
Das Passwort selbst wandert zu keinem Zeitpunkt und in keiner Form übers Netzwerk. Selbst jemand im selben WLAN, der jedes Paket mitschneidet, sähe immer nur das Puzzleteil und die verwürfelte Antwort – und aus keinem von beiden lässt sich das eigentliche Passwort zurückrechnen. Einen Browser braucht es dafür übrigens auch nicht – nur ein bisschen Scripting, das dieselbe Mathematik erledigt wie ein Browser. Nerdig, aber beruhigend: Der Login an sich ist solide.
Einmal drin, entpuppte sich das Web-UI-Backend der Box (data.lua) als Goldgrube – exakt dasselbe JSON, das die Admin-Oberfläche selbst benutzt, nur eben direkt abfragbar. Kein Durchklicken durch Menüs nötig. 😌
📶 Drei Dinge, die sich zu beheben lohnen
Die Sache mit WLAN-Einstellungen: Sie klingen abstrakt, bis man sie in etwas Alltägliches übersetzt. Hier also die „Erklär’s meinem Nicht-IT-Kumpel“-Version dessen, was Claude angemerkt hat – und warum.
1. Die dreispurige Straße (Kanalbreite bei 2,4 GHz)
Stell dir das 2,4-GHz-Band als schmale Straße mit genau 3 überlappungsfreien Spuren vor (Kanäle 1, 6, 11 – alles andere überlappt mit einem davon). Normalerweise nutzt dein WLAN eine Spur. Meine Box war so eingestellt, dass sie sich für mehr Tempo zwei Spuren auf einmal schnappt („40 MHz“) – nur sind das bei insgesamt 3 Spuren auf der ganzen Straße fast die komplette Fahrbahn, und das WLAN irgendeines Nachbarn parkt so gut wie garantiert auch auf einer dieser Spuren.
Der Clou: Es gibt eine eingebaute „Sei höflich“-Funktion (20/40-MHz-Koexistenz), die automatisch auf eine Spur zurückgeht, sobald sie einen Nachbarn bemerkt – und die war aus. Die Box belegte also zwei Spuren, kollidierte trotzdem mit den Nachbarn und bekam vom versprochenen Geschwindigkeitsvorteil nichts zurück, weil Kollisionen zu Neuübertragungen und langsameren Fallback-Raten zwingen. Das Schlechteste aus beiden Welten. 🚗💥🚗
2. Die breite Autobahn mit überraschender Straßensperre (5 GHz, 160 MHz + DFS)
5 GHz hat deutlich mehr Spuren, Gedränge mit den Nachbarn ist dort also nicht wirklich das Problem. Meine Box fuhr die breitestmögliche Autobahn – 160 MHz, 8 gebündelte Spuren, maximales theoretisches Tempo. Zwei Haken allerdings: Ein Teil dieses Spektrums (Kanäle 52–64) wird mit Wetter- und Flugradar geteilt. Erkennt die Box Radar, muss sie den Kanal sofort räumen, ohne Diskussion – wie eine Straße, die für einen Krankenwagen auf der Stelle gesperrt wird. Und ein so breiter Kanal verteilt dieselbe Sendeleistung dünner, was im Vergleich zu einem schmaleren 80-MHz-Kanal meist etwas Reichweite und Wanddurchdringung kostet.
Nicht direkt falsch – nur ein Kompromiss zwischen Tempo und Stabilität, von dem ich nicht wusste, dass ich ihn eingegangen war.
3. Der Ersatzschlüssel unter der Fußmatte (WPS)
WPS ist die Koppel-Abkürzung nach dem Motto „Knopf am Router drücken, Knopf am Gerät drücken, fertig“. Bequem – wie ein Ersatzschlüssel unter der Fußmatte für Gäste. Der Haken: Vor einigen Jahren haben Forscher eine Schwachstelle in der Prüfung der WPS-PIN gefunden, durch die sie sich viel schneller knacken lässt, als es bei einer 8-stelligen PIN sein dürfte. Wenn du es nicht aktiv zum Koppeln neuer Geräte nutzt, liegt da ein Ersatzschlüssel grundlos unter der Matte.
📊 Belege statt Bauchgefühl
Ab hier wurde es konkret. Claude hat das Systemprotokoll der FRITZ!Box gezogen – 1.088 Einträge über drei Wochen – und siehe da: Ich betreibe tatsächlich ein kleines Mesh (Access Points im Erdgeschoss, im 1. und im 2. Stock, nicht nur eine Box). Die Zahlen:
- 314× Radar erkannt auf den 5-GHz-DFS-Kanälen (120–124), verteilt auf die beiden APs oben, in drei Wochen. Das sind ungefähr 15-mal am Tag.
- 308 erzwungene Kanalwechsel als direkte, unmittelbare Folge dieser Radartreffer.
- 138× „sehr starke Störquelle erkannt“ auf den 2,4-GHz-Kanälen 1 und 11 – genau das Nachbar-Kollisionsproblem aus Punkt 1, schwarz auf weiß protokolliert.
- 12× war die automatische Qualitätslogik der Box selbst so unzufrieden mit den 2,4-GHz-Bedingungen, dass sie die Kanalbreite im laufenden Betrieb eigenmächtig verkleinert hat.
Das war also kein „könnte theoretisch irgendwo Probleme machen“. Das passierte seit Wochen mehrmals am Tag, ganz leise, ohne dass ich je mehr bemerkt hätte als ein gelegentliches „Hm, das WLAN hat sich gerade kurz zäh angefühlt“. 🤷
🎓 Die Moral (bis hierhin)
Nichts davon hat mit Strahlung, Gesundheit oder „zu viel WLAN“ zu tun – die Kanalbreite hat nichts mit der Sendeleistung zu tun, es geht rein ums Teilen des Spektrums und um Tempo gegen Stabilität. Aber es ist eine gute Erinnerung daran, dass „läuft doch problemlos“ und „ist tatsächlich gut konfiguriert“ zwei sehr unterschiedliche Aussagen sind – und manchmal findest du erst heraus, welche stimmt, wenn du eine KI auf deine eigenen Router-Logs ansetzt und sie bittest, einfach nur hinzuschauen. 😅
🛠️ Update: Jetzt wird tatsächlich umgeschaltet
Zurück für Runde zwei, diesmal mit Erlaubnis zum Anfassen. Wie sich herausstellte, steckte in Punkt 1 eine überraschende Wendung: Die „Nachbarstörung“ auf Kanal 1 war gar kein Nachbar. Ein frischer Scan der WLAN-Umgebung zeigte null wirklich fremde 2,4-GHz-Netze in der Nähe – jedes gemeldete „andere Netz“ trug das MAC-Präfix meines eigenen Router-Herstellers. Zwei meiner eigenen vier Mesh-Funkmodule (Hauptbox plus Repeater auf drei Etagen) hatten sich still und heimlich auf exakt denselben Kanal gesetzt und kollidierten über verschiedene Stockwerke desselben Hauses mit sich selbst. Die Nachbarn waren die ganze Zeit unschuldig. 🤦
Die Lösung dafür fiel einfacher aus als der geplante Koexistenz-Schalter: den 2,4-GHz-Kanal manuell auf 6 festgenagelt, der komplett leer war. Kanal 1 taucht in der Kanaltabelle der Box gar nicht mehr als aktiv auf, Kanal 6 schon. Keine perfekt saubere 1/6/11-Aufteilung über alle vier Funkmodule – der Kanal ist weiterhin 40 MHz breit und reicht damit immer noch etwas ins benachbarte Spektrum hinein –, aber eine echte Verbesserung gegenüber zwei meiner eigenen APs, die sich buchstäblich einen Kanal teilen.
WPS: komplett abgeschaltet. Kleine Fußnote der Genauigkeit halber – was diese Box tatsächlich anbietet, ist Push-Button-WPS, nicht die PIN-basierte Variante mit der oben beschriebenen Brute-Force-Schwäche. Der Push-Button-Modus braucht jemanden, der während eines aktiven Koppelfensters physisch an der Box steht, aus der Ferne ausnutzbar war das hier also nie. Trotzdem abgeschaltet, schlicht weil ich es nicht mehr brauche.
🚧 Der eine, der entwischt ist
Punkt 2 – die 160-MHz-Autobahn auf 80 zu verengen – ist der Teil, an dem das hier aufhört, eine saubere Erfolgsgeschichte zu sein. Wir wissen genau, was wir ändern wollen. Wir finden nur nirgends eine Stelle, an der man es tatsächlich ändern kann.
Bei der Suche nach der Einstellung wird es richtig seltsam: Das Feld ist sehr wohl noch da. Liest man die internen Daten der Box direkt über ihre API aus, zeigt sich klar ht160: active = true — die Einstellung existiert im Konfigurationsmodell, vorhanden und vollzählig. Was nicht existiert, ist irgendein Weg dorthin. Nicht über die Weboberfläche (weder versteckt hinter einem „Erweiterte Ansicht“-Schalter noch in einem eingeklappten Abschnitt – AVM hat die feingranulare Kanalbreiten-Einstellung in neueren FRITZ!OS-Versionen still und leise komplett aus der Oberfläche entfernt), und auch nicht über dieselbe API: Dieses JSON-Backend lässt dich das Feld fröhlich lesen, aber die Schreibseite – genau die Parameter, die eine Speicheranfrage bräuchte, um es tatsächlich umzulegen – ist nirgends dokumentiert, und selbst Claude, das an denselben Endpunkten herumgestochert hat, die auch die Weboberfläche nutzt, konnte keinen bestätigten, sicheren Aufruf festnageln. Undokumentierte POST-Parameter gegen einen produktiven Endpunkt zum Speichern der Konfiguration zu raten, fühlte sich genau nach der falschen Stelle zum Improvisieren an – liegst du daneben, scheiterst du nicht nur an der Kanalbreite, sondern riskierst, still und leise irgendeine völlig andere Einstellung zurückzusetzen, die du nie anfassen wolltest.
Der einzige noch funktionierende Weg, den bisher jemand gefunden hat, ist ein Drittanbieter-Tool, das die rohe Konfigurationsexportdatei der Box direkt bearbeitet und wieder importiert – und die Berichte aus der Community, wo das schiefging (eine kaputte Konfiguration, direkt aus einem Thread in einem Support-Forum), sind genau die Art Risiko, die man bei einem Router, von dem der ganze Haushalt abhängt, nicht eingehen sollte. Ein WLAN-Schluckauf ist okay. Eine Box, die gar nicht mehr antwortet, nicht.
Vorerst bleibt dieser Punkt also schlicht ungelöst – nicht weil die Lösung an sich fraglich wäre, sondern weil es derzeit keinen Weg dorthin gibt, der nicht mehr Risiko birgt, als die Einstellung wert ist. Abgelegt unter „im Auge behalten“: Bringt ein künftiges Firmware-Update eine Einstellung in der Oberfläche zurück oder taucht ein sicherer, dokumentierter API-Weg auf, ist das das Erste, was ich mir wieder vornehme.
🍂 Ausblick: FRITZ!OS 8.5 in diesem Herbst
Was praktischerweise zum eigentlichen Grund überleitet, hier dranzubleiben: Für den Herbst ist ein Upgrade auf FRITZ!OS 8.5 geplant, und das Highlight ist Werbe- und Tracker-Blocking à la Pi-hole direkt in der Box. Aktuell bedeutet diese Art Filterung auf DNS-Ebene, ein separates Gerät im Netz zu betreiben; sie nativ auf dem Router zu haben, der ohnehin im Zentrum von allem steht, wäre eine wirklich schöne Vereinfachung. Firmware-Update-Saison ist zugleich „Vielleicht kommt ja auch die Kanalbreiten-Einstellung still und leise zurück“-Saison – mehr zu beidem, sobald 8.5 tatsächlich da ist.





