FRITZ!Box 5690 Pro – Was hat sich zwischen den INHAUS-Builds 137414 und 137565 wirklich geändert?
FRITZ!OS: 08.40
Vergleich: 08.40-137414-Inhaus → 08.40-137565-Inhaus
Untersuchung: 15.10.2026 | Firmware-Diff v10.18, ergänzende ELF-/ARM-Maschinencode-Tiefenanalyse
Wichtig: Das ist eine unabhängige technische Analyse zweier Original-Firmware-Images,
kein offizielles AVM-Changelog. Eine mögliche Fehlerbehebung wird nur dort als solche bezeichnet, wo sie tatsächlich belegt ist.
1. Zusammenfassung
Der Firmware-Vergleich hat 20 geänderte beziehungsweise neue Binärdateien gemeldet; entfernte Binärdateien wurden nicht gefunden. Betroffen sind Mesh, Zigbee, Qualcomm/WLAN, das Realtek-Dateisystem und zwei AppArmor-Profile. Allerdings hat nicht jede andere SHA256-Prüfsumme eine geänderte Funktion zur Folge.
Das auffälligste Ergebnis betrifft die Mesh-Nachbarschaftsverwaltung: In der Mesh-Bibliothek wurden ein Timeout-Wert, die Weitergabe eines IP-Präfixparameters und weitere Programmabschnitte verändert. Der Mesh-Analyzer besitzt außerdem einen neuen Prüfaufruf.
2. Mesh – Versionswechsel und nachgewiesene Programmänderungen
Datei:
Code:
ALT: 1.349-MyFritzOSP1_RC7-0-g28a43609
NEU: 1.350-MyFritzOSP1_RC8-0-gc6f09fe3
Die ausführbare ELF-Sektion
wächst von 2.848.664 auf 2.848.808 Bytes (+144 Bytes). Die gesamte Datei ist in beiden Versionen 4.835.176 Bytes groß. Beim Vergleich gleicher Dateipositionen unterscheiden sich 3.626.433 Bytes. Diese Zahl darf
nicht als Anteil geänderter Funktionen verstanden werden, weil auch Adressverschiebungen, Relokationen sowie Compiler-/Linker-Effekte beitragen können.
2.1 IP-Adress-Timeout: nicht nur umbenannt
Ein exportiertes Symbol des
wurde ersetzt. Die Werte wurden direkt aus den ELF-Datenbereichen gelesen:
Code:
ALT: DEFAULT_IP_ADDRESS_STALE_TIMEOUT = 5
NEU: DEFAULT_IP_ADDRESS_INACTIVITY_TIMEOUT = 606
Little-Endian-Rohwerte:
Code:
ALT: 05 00 00 00 00 00 00 00
NEU: 5e 02 00 00 00 00 00 00
Parallel änderte sich die Diagnosezeichenkette von
Code:
s ago which exceeds stale timeout of
auf
Code:
s ago which exceeds inactivity timeout of
.
Die separat vorhandene Konstante
Code:
DEFAULT_NODE_INACTIVITY_TIMEOUT
bleibt auf 4;
Code:
DEFAULT_NEIGHBOUR_TRACKING_STATUS_UPDATE_TIMER_DELAY
bleibt auf 5.
Einordnung: AVM hat einen tatsächlich gespeicherten Parameter zur IP-Adress-Inaktivität geändert. Die Formulierung
legt Sekunden als Einheit nahe, doch ohne vollständigen Aufrufkontext und Laufzeittest lässt sich
nicht beweisen, dass ein Gerät nach exakt 606 Sekunden aus dem Mesh entfernt wird.
2.2 LearnedIPAddress: Präfixparameter wird weitergereicht
Betroffene C++-Funktion:
Code:
avm::mesh::LearnedIPAddress::LearnedIPAddress(INADDR const*, unsigned char, std::bitset<32u>)
Der Funktionsumfang ändert sich von 140 auf 160 Bytes. Im alten ARM-Maschinencode wird das Präfixargument für den nachfolgenden
-Konstruktor mit
auf null gesetzt. Im neuen Code wird der ursprünglich übergebene Wert mit
gesichert und später mit
weitergegeben.
Einordnung: Diese Änderung ist unmittelbar im Maschinencode nachweisbar. Sie spricht für eine korrigierte Übergabe der IP-Präfixlänge. In welchen konkreten Fällen dadurch ein Fehler behoben wird, ist nicht verifiziert.
2.3 Weitere veränderte Funktionsgrößen
Code:
NeighbourService::update_node(...) 2372 → 2420 Bytes (+48)
LearnedIPAddress::LearnedIPAddress(...) 140 → 160 Bytes (+20)
LANService::create_eth_interface_monitors() 1196 → 1192 Bytes (-4)
Im alten und neuen
wurden jeweils 6.619 exportierte Funktionssymbole mit denselben Namen und 1.080 gleich benannte externe Funktionsimporte ermittelt. Die Konstruktor-Aliase C1/C2 sind dabei keine zwei unabhängigen Änderungen. Zahlreiche gleich benannte Funktionen zeigen aufgrund der Neuerstellung andere Maschinenbytes; ein Großteil davon kann durch Verschiebungen erklärt werden. Es wäre falsch, daraus tausende funktionale Bugfixes abzuleiten.
2.4 Mesh-Analyzer: zusätzliche Prüf- und Beendigungsaufrufe
Datei:
Die
-Sektion wächst von 22.744 auf 22.792 Bytes (+48 Bytes). Neu als dynamische Funktionsimporte erkannt:
Code:
daemonmng_slab_periodic_check
exit
Der neue ARM-Code enthält einen tatsächlichen
-Aufruf zur
Code:
daemonmng_slab_periodic_check
-PLT-Adresse. Vor dem Aufruf werden die Register
,
und
jeweils mit
belegt. Ein neuer
-Aufruf ist ebenfalls sichtbar.
Einordnung: Hier wurde zusätzliche Programmlogik eingebaut. Welche Einheit die Werte 51200 haben und unter welchen Bedingungen die Routine eingreift, ist aus der Binäranalyse allein nicht sicher zu bestimmen. Ein Programmabsturz oder eine bestimmte Fehlerbehebung ist dadurch nicht belegt.
2.5 Welche Mesh-Komponenten KEINEN geänderten Programmcode zeigen
Die folgenden Dateien haben zwar unterschiedliche komplette SHA256-Prüfsummen, aber bytegleiche
-Sektionen sowie identische geprüfte Code-/Datensektionen:
Code:
usr/sbin/meshd .text: 8.828 Bytes, bytegleich
usr/lib/libmesh_analyzer_client.so .text: 3.152 Bytes, bytegleich
usr/lib/libmesh_plcservice.so.0 .text: 125.044 Bytes, bytegleich
Die gemessenen Änderungen betreffen bei diesen drei Dateien GNU-Build-ID und
-Prüfsumme. Weiterhin sind diese vier Dateien komplett SHA256-identisch:
Code:
usr/lib/libmesh_shared.so.0
usr/share/ctlmgr/libmesh_plugin.so
usr/share/moved/libmove_meshd_d.so
usr/share/moved/libmove_meshd_s.so
Fazit zu Mesh: Mindestens die IP-Adress-Konstante, die Präfixweitergabe und die neue Prüf-Anbindung im Mesh-Analyzer wurden tatsächlich verändert. Ein offizieller AVM-Bugfix lässt sich daraus nicht ableiten, wohl aber eine gezielte Weiterentwicklung dieser Teile.
3. Zigbee – ausschließlich die letzten 256 Bytes unterscheiden sich
Code:
lib/firmware/lrwpan/hw279_1/zncp-1.4.3.bin
Dateigröße: 323.188 Bytes
Unveränderte erste 322.932 Bytes
Danach 256 abweichende Bytes in einem zusammenhängenden Bereich
lib/firmware/lrwpan/hw279_2/zncp-1.4.3.bin
Dateigröße: 322.812 Bytes
Unveränderte erste 322.556 Bytes
Danach 255 abweichende Bytes innerhalb des 256-Byte-Endbereichs
Der eigentliche Bereich vor dem Ende ist jeweils vollständig byteidentisch. Ein 256-Byte-Signatur- oder Trailerbereich ist plausibel, aber RSA-2048 oder ein anderer Signaturtyp wurde nicht kryptografisch verifiziert.
Kein nachgewiesenes Zigbee-Funktionsupdate.
4. Qualcomm und WLAN – neue Signatur-/Build-Kennungen
Die exakt gezählten Byteabweichungen liegen bei gleicher Dateiposition wie folgt:
Code:
IPQ9574/q6_fw.b01 : 966 Bytes
IPQ9574/q6_fw.b08 : 34 Bytes
IPQ9574/q6_fw.b13 : 683 Bytes
IPQ9574/q6_fw.b14 : 33 Bytes
IPQ9574/q6_fw.b15 : 135 Bytes
IPQ9574/q6_fw.mdt : 966 Bytes
qcn9224/amss.bin : 1704 Bytes
qcn9224/m3.bin : 801 Bytes
In mehreren Dateien wechselten eingebettete Zeit-/UUID-Kennungen vom 09.10.2026 zum 14.10.2026:
Code:
q6_fw.b08 / q6_fw.b14: 09.10. 17:59 → 14.10. 17:23
qcn9224/amss.bin: 09.10. 18:03 → 14.10. 17:27
Die neuen Kennungen passen zu einem erneuten Herstellungs- oder Signierungslauf. Bei
und
sind die Änderungen sehr klein und decken sich mit erkannten UUID-/Zeitzeichenketten. Bei
,
,
und
sind weitere Prüfungen für eine Aussage über tatsächlich geänderte Firmware-Funktionen nötig.
Die von Binwalk teils gemeldeten ESP-/JBOOT-Signaturen in Qualcomm-Blobs wurden nicht unabhängig bestätigt und sind nicht als sicher erkannte eingebettete Images zu bewerten.
5. Realtek: SquashFS bis auf Dateiebene geprüft
Datei:
Code:
lib/firmware/rtk/filesystem.image
Das Image enthält einen 64-Byte-uImage-Header und anschließend ein XZ-komprimiertes SquashFS 4.0 mit 882 Inodes. Das neue uImage hat den Zeitstempel 14.10.2026, 15:44:59. Der Dateiinhaltsvergleich ergab je Version 769 erfasste Datei-/Symlink-Pfade. Es gibt weder zusätzliche noch entfernte Pfade. Genau vier Datei-Inhalte unterscheiden sich:
-
:
→
-
:
→
-
: Nur
Code:
CONFIG_SUBVERSION="-137414"
→
und
Code:
CONFIG_BUILDNUMBER="137414"
→
; keine weiteren Textzeilenänderungen.
-
: je 21 Archivpfade, identische verglichene Nutzdaten, abweichende Zeitstempel.
Das separat vorliegende äußere
enthält in beiden Versionen jeweils 33 Pfade, ebenfalls ohne neue oder entfernte Einträge und ohne geänderte verglichene Nutzdaten. Die Metadatenlisten zeigen neue Zeitstempel vom 09.10. auf den 14.10.2026.
Einordnung: In den geprüften Realtek-Dateiinhalten ist keine geänderte Funktionskonfiguration erkennbar; der Unterschied wird durch Buildnummern und TAR-Metadaten plausibel erklärt. Nicht alle möglichen Dateisystem- oder Archiv-Metadaten sind abschließend geprüft.
6. AppArmor – binäre Profile geändert
Code:
lib/apparmor.d/sbin.nqcs.bin +16 Bytes
lib/apparmor.d/usr.sbin.plcd.bin -16 Bytes
Beide Profile haben andere Prüfsummen und zahlreiche Byteabweichungen. Ob die tatsächlichen Sicherheitsregeln verändert wurden, lässt sich ohne eine passende Profil-Dekodierung beziehungsweise Original-Quellprofile nicht feststellen.
7. Prüfung und Grenzen
Die Ergebnisse basieren auf den zwei originalen AVM-Images. Die Mesh-ELF-Dateien wurden zusätzlich direkt extrahiert und mit
,
, ARM-Disassembly sowie SHA256- und Sektionsvergleichen geprüft. Beim Mesh stimmen die extrahierten ELF-Dateien in ihren SHA256-Werten mit den ursprünglichen Firmware-Diff-Ergebnissen überein.
Code:
SHA256 altes Image:
86681b87255d826a5d78ce2be287f67a526f9c5d7e1be7e32cfe611d048ecba0
SHA256 neues Image:
f6140bde86288b4affffab3bbe854951e83d2a76bc9261f059ca74d607e0a7fd
Ein Test der Mesh-Funktionen auf einer laufenden Box wurde nicht durchgeführt. Insbesondere die tatsächliche Laufzeit des neuen Timeouts und die reale Fehlerwirkung bleiben offen.
Gesamtfazit
Der Versionssprung von INHAUS 137414 auf 137565 enthält
nachweisbare Änderungen an der Mesh-/IP-Adress-Verarbeitung. Am deutlichsten sind die Änderung des NeighbourService-Timeoutwerts 5 → 606, die neue Weitergabe der IP-Präfixlänge und die zusätzliche periodische Prüfanbindung im Mesh-Analyzer. Gleichzeitig ist erkennbar, dass mehrere andere geänderte Binärdateien lediglich andere Build-/Debugdaten besitzen oder nur neue Signaturen beziehungsweise Zeitstempel tragen.
Eine definitive Aussage wie „AVM hat Fehler X behoben“ wäre ohne AVM-Changelog, Quellcode oder Praxistest unseriös. Aber die tatsächlichen technischen Änderungen lassen sich damit deutlich besser eingrenzen als durch einen gewöhnlichen
.