FRITZ!Box 7690 - FRITZ!OS 8.25 Release vom 25.06.2026

Ich denke auch, dass nach dem „WPA“ einfach nur das Komma vergessen wurde.
 
  • Like
Reaktionen: Kullematz
@Fritzebox

Die besten Ergebnisse habe ich erzielt, indem ich die Einstellungsübernahme deaktiviert und die Kanäle fest vergeben habe.
Verschlüsselung zu den Clients auf WPA2, und PMF auf aus.
Mit diesen Einstellungen läuft der 2400er als WLAN-Brücke auch bei mir. Die Einstellungsübernahme habe ich deaktiviert, weil er ein eigenes WLAN für ältere Geräte im Keller anbieten soll. Die PV-Anlage und die Optimierer sind mittels eines Switches per Kabel am 2400er angeschlossen.

PS: meine erste Mail war ziemlich unpräzise, denn bei "im MESH" würde ich Einstellungsübernahme und gleiche WLAN-Namen erwarten.
 
Hallo zusammen,
gibt es schon Erfahrungen, ob diese Version an Glasfaseranschlüssen auch mit der standardmäßig ja vermutlich weiterhin aktivierten Hardware-Paketbeschleunigung diesbezüglich fehlerfrei läuft?
 
So habe ich das jetzt auch eingestellt, weil Handys regelmäßig Probleme mit dem Wlan meldeten, die es gar nicht gab. Allerdings musste ich einige Echo dots und den Laptop neu mit dem Wlan verbinden, die wollten das Wlan gar nicht mehr nutzen und waren der Meinung, dass es zwei Wlan-Netze gibt, obwohl SSID und Schlüssel gleich waren.
 
Das ist für mich normales Verhalten, daß eine Verbindung mittels WPA2 und WPA3 oder PMF von Clients unterschiedlich gehandhabt werden und hernach die Verbindung gelöscht und neu eingerichtet werden muß.
Hab mich schon daran gewöhnt.
Ob dies tatsächlich so sein soll kann ich nicht beurteilen, nur habe ich diese Beobachtungen in meinem Umfeld schon vor Jahren gemacht.
 
Dann würde aber Band Steering nie funktionieren, wenn das 2,4 GHz Netz WPA2 und das 5 GHz Netz WPA2+WPA3 nutzt, was aber in der Standardeinstellung der Fritzbox der Fall ist. Oder man muss bei jeder Neuanmeldung eines Dualband-Gerätes, welches WPA3 unterstützt, vorher das 5 GHz Netz ausschalten.
 
Wenn es grundsätzlich mit WPA2 verbunden ist (war), kann es ja auch bei WPA2+3 einbuchen.
Aber vielleicht liegt es ja auch an für mich unergründlich anderem.
 
Bitte einmal die Supportdaten erstellen, lokal abspeichern und dort nach "BEGIN SECTION PA" suchen.
Steht dort unterhalb von " /proc/net/avm_pa/brief"
Version: 2.182.1.4-release_smart24p2-smart24p2 on Linux version x.x.xxx ([email protected]) (gcc version 8.4.0 (Buildroot -g162062dc) ) #1 SMP PREEMPT 2026-04-30
oder ist dort ein anderer Eintrag vorhanden?
Bitteschön, Versionsnummer ist gleich:

2.182.1.4-release_smart24p2-smart24p2 on Linux version 5.4.213 ([email protected]) (gcc version 8.4.0 (Buildroot -g91c9c7f8)) #1 SMP PREEMPT 2026-06-12
 
  • Like
Reaktionen: tango501
Hallo zusammen,
gibt es schon Erfahrungen, ob diese Version an Glasfaseranschlüssen auch mit der standardmäßig ja vermutlich weiterhin aktivierten Hardware-Paketbeschleunigung diesbezüglich fehlerfrei läuft?
Bis jetzt sehe ich kein Problem bei mir hinter einem Glasfaser-ONT, Hardwarebeschleunigung ist aktiv, über LAN und WLAN kommt die volle Geschwindigkeit an.
 
  • Like
Reaktionen: atzebonn und churchy
Hi, nach dem Update ist mir aufgefallen dass in den WLAN Funkkanal-Einstellungen die empfohlene automatische Einstellung nicht aktiv war. Hatte ich dann aktiviert und übernommen. Als ich mich das nächste Mal angemeldet hatte, war die Einstellung wieder auf manuell anpassen gestellt. Hat das noch jemand beobachtet? Ich komme von der 8.22 (die 8.20 hatte ich übersprungen).

Gruß Björn
 
Funkkanal-Einstellungen automatisch setzen (empfohlen)
und
Autokanäle bei Funkkanal-Einstellungen anpassen
bleiben hier über logoff/-on wie vor logoff eingestellt erhalten

kam von Labor
 
Wenn es grundsätzlich mit WPA2 verbunden ist (war), kann es ja auch bei WPA2+3 einbuchen.
So ist es. Wenn man das Gerät aber einbucht und es sucht sich WPA3 aus, was man ja nicht beeinflussen kann, dann kann es sich nicht automatisch auch auf 2,4 GHz verbinden, wenn dort wegen der Kompatibilität nur WPA2 möglich ist.
 
  • Like
Reaktionen: FehlendeInfos
Kurzes Feedback: Nach Update auf 8.25 läuft bei mir bis jetzt alles einwandfrei.
 
  • Like
Reaktionen: maciboy und erik
was man ja nicht beeinflussen kann
Eben, daher auch die eventuelle Notwendigkeit neu zu verbinden, wenn man zuvor WPA2+3 hatte.
Insbes. bei bei Autoeinstellungen, wo zumeinst der höchste Standard ausgewählt wird, der damit wegfällt.
 
Ich habe seit der 8.25 folgendes beobachtet
Gemäß Anleitung : https://www.kuketz-blog.de/pi-hole-einrichtung-und-konfiguration-mit-fritzbox-adblocker-teil1/

Wurde der FritzBox (Konfiguration besteht schon während der 8.24xxxxxx LABOR Phase) im Bereich Heimnetz -> Netzwerk -> Netzwerkeinstellungen -> Erweiterte .... -> IPv4 -> lokaler DNS die IPv4 des Pi-Hole (Core 6.4.2; FTL 6.6.2) eingetragen.
Im Pi-Hole wiederum wird unter System -> Settings -> DNS als Custom DNS u.a die FritzBox IPv4 Adresse angegeben und zusätzlich unter Conditional Forwarding folgedes: true,192.168.178.0/24,192.168.178.1,fritz.box

Nun kommt im Pi-Log immer folgender Fehler
CONNECTION_ERRORConnection error (192.168.178.1#53): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)

Ich habe den Eintrag schon mal gelöscht und wieder neu eingetragen. In der FriztBox mal testweise die lokale DNS IPv4 auf 192.168.178.1 und in Schritt 2 direkt wieder auf die lokale IPv4 des Pi-Hole zurück gestellt.
Hat alles nichts geändert. Es gibt im Pi-Hole noch 2 weitere Conditional Forwardings zu Domain Controler 1 und 2 -> hier keinerlei Probleme.
Mit der FritzBox gab es diese Fehler vor der 8.25 auch nicht (bzw. nur sporadisch aber vernachlässigbar selten)
Der Unterschied in den Konfigs zu vorher ist das Update FritzBox von LABOR auf 8.25, daher eine neue Auffälligkeit in meinen Beobachtungen seit dem Update.

Ich weiß natürlich nicht wieviele hier im Forum zeitgleich Kuketz.Blog folgen und evtl. ähnliche oder annähernd gleiche Konfigurationen nutzen?
Daher hier mal meine Beobachtungen diesbezüglich in den "Sammler zur FW 8.25".

Gruß
Peter
 
Ich hab das auch sporadisch, bin aber der Meinung dass das schon mit den Laborversionen immer wieder auftrat. Ich habe aber auch das Gefühl, dass es mit dem Abruf der lokalen DNS Daten von der Fritzbox immer mal Probleme gibt (teils falsche oder geänderte DNS Namen von lokalen Geräten).
 
nur sporadisch aber vernachlässigbar selten
in Zahlen ausgedrückt (für meinen Fall) 1x pro Woche oder sogar nur 1x in 14 Tagen über den Daumen.

Momentan habe ich diese Meldung mindestens 1x / Tag bzw. mehrfach täglich. Hatte mit dem Pi gestern morgens den Fehler drin, dann musste nach apt update -> apt upgrade ein Neustart her und damit ist der Fehlerspeicher erstmal leer. Nachmittags / Abends war der Fehler bereits wieder drin.
 
Mit dem eingebautem DNS-Server der Fritzbox 7690 (aktuelle Firmware) gibt es offenbar noch mehr Effekte im Bereich ipv6 und ddns-Hosts:

------------------- cut ----------------------------------------------------------------------------------------------------------------------------------------------------------------
Von der Fritzbox genutzte DNS-Server
2003:180:2:a000::53 (aktuell genutzt für Standardanfragen)
2003:180:2:b000::53
217.237.151.142
217.237.150.188

host -t aaaa peanuts-ii.myddnshost.de fritz.box
Using domain server:
Name: fritz.box
Address: 192.168.40.254#53
Aliases:

peanuts-ii.myddnshost has no AAAA record

host -t aaaa peanuts-ii.myddnshost 2003:180:2:a000::53
Using domain server:
Name: 2003:180:2:a000::53
Address: 2003:180:2:a000::53#53
Aliases:

peanuts-ii.myddnshost has IPv6 address 2003:ca:f28:ed00:2e44:fdff:fe33:9d85

host -t aaaa peanuts-ii.myddnshost 2003:180:2:b000::53
Using domain server:
Name: 2003:180:2:b000::53
Address: 2003:180:2:b000::53#53
Aliases:

peanuts-ii.myddnshost has IPv6 address 2003:ca:f28:ed00:2e44:fdff:fe33:9d85

host -t aaaa peanuts-ii.myddnshost 217.237.151.142
Using domain server:
Name: 217.237.151.142
Address: 217.237.151.142#53
Aliases:

peanuts-ii.myddnshost has IPv6 address 2003:ca:f28:ed00:2e44:fdff:fe33:9d85

host -t aaaa peanuts-ii.myddnshost 217.237.150.188
Using domain server:
Name: 217.237.150.188
Address: 217.237.150.188#53
Aliases:

peanuts-ii.myddnshost has IPv6 address 2003:ca:f28:ed00:2e44:fdff:fe33:9d85

host -t a peanuts-ii.myddnshost fritz.box
Using domain server:
Name: fritz.box
Address: 192.168.40.254#53
Aliases:

peanuts-ii.myddnshost has address 91.1.189.24

host -t a peanuts-ii.myddnshost 2003:180:2:a000::53
Using domain server:
Name: 2003:180:2:a000::53
Address: 2003:180:2:a000::53#53
Aliases:

peanuts-ii.myddnshost has address 91.1.189.24

---------------------------------------- cut ---------------------------------------------------------------------------------------------------------------------

Wie man unschwer erkennt, liegt es nicht an den der Box zugewiesenen DNS-Server, die antworten korrekt.

Die TTL ist beim ddns-Anbieter auf 60 Sekunden gesetzt und ich habe über zwei Tage erfolglos auf eine Änderung im DNS-Cache der Fritzbox gewartet. Ich habe das mit mehreren DYN-DNS Anbietern getestet, war immer das gleiche Ergebnis.

myddnshost ist ein Fake-Hostnamen, in den Abfragen wurde natürlich der real existierende verwendet!
Und nach einem Reboot der Box hat solch natürlich an dem Verhalten nichts geändert.

Es ist auf der Box kein DHCP-Server aktiv, da nützt der Tipp den dhcp-Server mal anzuhalten und neu starten nichts. Schon mal gar nicht bei ipv6 ;)
ipv4 wird aber korrekt gehandelt, wenn ich das richtig überblicke. Große, bekannte Hosts wie heise.de mit statischer ipv6-IP scheinen nicht betroffen zu sein. Gibt wohl ein Problem mit den kurzen TTL-Zeiten für die AAAA-Records.

Von daher würde ich dem DNS-Server der Fritzbox derzeit nicht 100%ig über dem Weg trauen.
Ich habe versucht, das Verhalten auf einer Fritzbox 7530ax bei einem Bekannten nachzustellen, da scheint es aber zu funktionieren.

Die Fritz-KI hat mit gestern mitgeteilt, dass sie ein Ticket mit Nennung der Ticket-ID bei Fritz zu dem Thema eröffnet hat, aber es kam noch keine Reaktion von Fritz.
 
Hallo zusammen,
gibt es schon Erfahrungen, ob diese Version an Glasfaseranschlüssen auch mit der standardmäßig ja vermutlich weiterhin aktivierten Hardware-Paketbeschleunigung diesbezüglich fehlerfrei läuft?

Das Problem besteht leider weiterhin und wurde NICHT behoben.

Nach Upgrade auf 8.25 zeigt sich das identische Bild wie bei allen Versionen (inkl. Betas), die nach der 8.02 folgten.
Downstream schnell, Upstream bricht teils mehr um die Hälfte ein. Eventuell wird das Problem auch nur bei "flotteren" Verbindungen sichtbar, das ist meine Vermutung. Weswegen zB alle mit Upload ~150mbps oder weniger das Problem eventuell gar nicht sehen.

Hier ein Bild zum verdeutlichen (Speedtest ist egal, hier wars der Zack, auf speedtest.net selbes Bild. Uhrzeit etc. egal).

FBF7690_Bug.png
 
  • Wow
Reaktionen: maciboy
Kostenlos!

Statistik des Forums

Themen
248,872
Beiträge
2,303,459
Mitglieder
378,532
Neuestes Mitglied
Nik320