Wenn die FRITZ!Box komplett einfriert — kein WLAN, kein LAN, Web-Oberfläche tot, nicht einmal mehr Ping — denkt man zuerst an Hardware. Bei mir lief das aber wochenlang so, und am Ende war es ein Firmware-Bug der FRITZ!Box 6670 Cable, der nur in einer sehr spezifischen Konstellation auftrat: sobald iPhone oder iPad ins Gastnetz wollten. Vodafone-Leihgerät, FRITZ!OS 8.21, Apple-Geräte als Auslöser. Klingt nach einer absurd kleinen Schnittmenge — und ist es auch.
Das Fehlerbild: komplette Box tot, nicht nur das Gastnetz
Ein Crash bedeutete hier nicht „Internet langsam“ oder „WLAN bricht ab“. Die Box war komplett weg. Kein Haupt-WLAN, kein Gast-WLAN, kein LAN, fritz.box nicht erreichbar, auch nicht die Reserve-IP 169.254.1.1. Ping ging ins Leere. Erst der Stromzyklus stellte das Gerät wieder her. Das Ereignisprotokoll wurde beim Neustart geleert, was die Diagnose nicht gerade erleichtert hat. Und der Push-Service, mit dem die Box im Fehlerfall eine Mail verschicken soll? Funktioniert nicht, wenn die Box gerade gar keine Internet-Verbindung mehr aufbauen kann. Das Werkzeug für den Fehlerfall fällt genau dann aus, wenn man es bräuchte.
Der Crash trat 10 Minuten bis mehrere Stunden nach dem Verbinden eines Apple-Geräts ins Gastnetz auf, völlig unvorhersehbar. Die Info-LED ging nach 30 bis 60 Minuten Stillstand auf Rot. Mit der Vorgängerbox 6660 Cable hatte das Problem milder ausgesehen — da fiel nur das Gastnetz aus, Hauptnetz und LAN blieben erreichbar. Mit dem Umstieg auf die 6670 und einem FRITZ!OS-Update wurde aus dem „Gastnetz hängt sich auf“ das „komplette Box hängt sich auf“. Ein Upgrade, könnte man sagen.
Diagnose mit zweiter FRITZ!Box als Werkzeug
Bevor man bei einem Provider-Gerät zum Support greift, sollte man die eigenen Hausaufgaben machen — sonst bleibt das Ticket in der ersten Sortierstufe hängen. Werksreset hatte nichts gebracht. Vodafone hatte sogar die komplette Hardware getauscht, gleiches Modell, identisches Verhalten. Die Apple-Geräte funktionierten an einer anderen FRITZ!Box anstandslos, „Private WLAN-Adresse“ war deaktiviert, manuelle IP, manueller DNS — kein Effekt. Es musste also an dieser konkreten Firmware in Kombination mit Apples WLAN-Verhalten liegen. Mit einer alten FRITZ!Box 6490 Cable als Diagnose-Werkzeug ließ sich der Bug systematisch eingrenzen:
- Beobachtungstest über Tage: Solange iPhone und iPad nicht zu Hause waren, lief die 6670 tagelang stabil. Sobald die Geräte zurück waren, kam der nächste Crash binnen Stunden.
- Isolierter Reproduktionstest: SSIDs umbenannt, alle anderen Geräte ausgesperrt, nur iPhone und iPad im Gastnetz. Crash nach 40 bis 50 Minuten. Damit war klar: kein anderes Gerät verantwortlich.
- Setup A — Apple via zweiter Box ins Gast-LAN: Die alte 6490 als reiner Access Point per LAN-Kabel an den Gast-LAN-Port (LAN5) der 6670 gehängt. Apple-Traffic kam jetzt nicht mehr über WLAN, sondern über LAN ins Gastnetz. Crash trotzdem. Damit war der WLAN-Stack der 6670 raus aus dem Verdacht — der Bug sitzt im Gast-LAN-Bridge-Pfad.
- Setup B — gleiche Geräte, aber an LAN4 statt LAN5: Die 6490 jetzt am Hauptnetz-Port. Identische Apple-Geräte, identischer Traffic, nur eben Hauptnetz statt Gastnetz. Seitdem läuft die Box. Über eine Woche stabil. Hauptnetz-Code also ebenfalls aus dem Verdacht.
- Frequenzband-Test: 5 GHz testweise aus, nur 2,4 GHz aktiv. Crash trat trotzdem auf. Wi-Fi 7 und Multi-Link Operation sind also nicht das Problem — der Bug liegt tiefer.
Die Crash-Logs in /proc/avm/log_sd/ waren übrigens alle leer. Kein Kernel-Panic, sondern ein User-Space-Daemon, der sich aufhängt. Was genau, weiß nur AVM.
AVM-Support, Workaround und ein paar unschöne Details nebenbei
Beim AVM-Support kam zuerst die erwartbare Antwort: ein Sachbearbeiter, der das Problem auf „Benutzeroberfläche nicht aufrufbar“ verkürzte, einen Standard-Knowledge-Base-Artikel verlinkte und das Wort „korrelativ, nicht kausal“ verwendete. Erst nach der dritten sauber dokumentierten Test-Mail übernahm ein zweiter Sachbearbeiter mit konkreteren Diagnose-Anfragen. Hier hilft, was bei jedem Hersteller-Support hilft: strukturierte Mails, klare Reproduktionsschritte, Support-Daten mit Versand-ID, Hartnäckigkeit. Ein Vodafone-Techniker bestätigte am Telefon, dass das Firmware-Problem der 6670 bekannt sei und ein Update aussteht — mündlich, nicht schriftlich, versteht sich. „Bug bestätigt, aber kein Termin für Fix“ ist Realität, mit der Provider-Kunden leben müssen.
Wer Support-Daten an AVM verschickt, sollte vorher kurz reinschauen: WLAN- und Login-Passwörter werden als SECRET redigiert, Telefonnummern und Geräte-MACs stehen im Klartext drin. WLAN-Passwort nach dem Versand sicherheitshalber rotieren, Telefonnummern bei Bedarf vorher schwärzen. Das Telefon-Codeverfahren *99# zum Auslösen von Support-Daten im Crashfall hilft auch nicht weiter — die Box kann im Crash genauso wenig telefonieren wie mailen.
Der Workaround ist denkbar simpel: Apple-Geräte landen jetzt im Haupt-WLAN, nicht mehr im Gastnetz. Seit über einer Woche stabil. Wer aus Datenschutz- oder Strukturgründen Geräte getrennt halten will, kann eine zweite FRITZ!Box per LAN-Kabel ans Hauptnetz koppeln und dort eine eigene SSID aufspannen — funktional ist das wie ein Gastnetz, nur ohne den Bug. Eine alte 6490 als Diagnose- und Reserve-Box ist im Heimnetz sowieso Gold wert.
Was bleibt: Provider-Firmware und die Geduld der Diagnose
Zwei Punkte bleiben hängen. Erstens: Provider-gebrandete FRITZ!OS-Versionen hinken der AVM-Retail-Firmware regelmäßig hinterher, was bekannte Bugs in der Vodafone-Variante länger leben lässt als nötig. Bei Vodafone Kabel hat man als „routerfreier“ Kunde de facto sowieso nur die Wahl zwischen verschiedenen FRITZ!Box-Modellen — die Marktmacht ist also eindeutig verteilt, und das Tempo der Updates wird genau dort entschieden, wo man als Kunde am wenigsten dran rütteln kann. Zweitens, der wichtigere Punkt für alle, die in fremden oder eigenen Heimnetzen Bugs jagen: immer nur eine Variable auf einmal ändern, jedem Test mindestens drei Tage geben. Wer das nicht macht, zieht Schlüsse aus Zufall. Und sucht den nächsten Bug an der falschen Stelle.
