Environment-Variablen/Werte von fabrikneuen FRITZ!Boxen

[NDiIPP]

Leider wurde das Thema "FRITZ!Box-Kennwort auf Geräterückseite falsch" bereits von einem Moderator geschlossen (normalerweise wäre mir das kein neues Thema Wert gewesen, aber nun habe ich ja keine Wahl mehr).
Allerdings hatte ich mir, angeregt durch dieses Thema von @Roland7, bei einer (mutmaßlich) fabrikneuen Fritzbox (eine 7590) das erste mal genauer das Bootloader-Environment angesehen (und zwar bevor die Box das erste mal die Firmware bzw. den Kernel bei mir starten konnte). Siehe dazu ein Ausschnitt aus Beitrag #11 aus dem oben erwähnten Thema:

BTW:
Habe gerade eine neue 7590 (lag bei mir schon eine Weile ungeöffnet herum) bei der Gelegenheit mal untersucht. Der Aufkleber passt jedenfalls schon mal zum Environment und der ausgelesene Counter:

reboot_major          0
reboot_minor          0
run_hours             0
run_days              0
run_mounths           0
run_years             0

lässt auch den Schluss einer fabrikneuen, bisher ungenutzten, Box zu (es sei denn ein "Zwischenbesitzer" hätte den ebenfalls zurückgesetzt). Auch die Variable "linux_fs_start" fehlt (was alleine aber noch kein Beleg wäre, schließlich hätte sie ja dennoch genutzt werden können und auch das Recovery-Tool hätte angewendet werden können).

Interessant fand ich aber der Wert der Variable "firmware_info": 154.07.01,recovered=1
Ist das "recovered=1" etwa normal bei einer (tatsächlich) fabrikneuen Box? Hatte ich früher zugegebenermaßen noch nie untersucht und derzeit habe ich auch nur diese Box welche bisher (angeblich) neu ist...

Bei gebraucht erworbenen Boxen gehört es bei mir mittlerweile zum Standard-Vorgang, als allererstes die Box im Bootloader anzuhalten und das Environment und den Counter auszulesen (bevor sie bei mir das erste mal die Firmware lädt) sowie anschließend die Box (bspw. per Recovery-Tool von AVM) zurückzusetzen und mit der neuesten Firmware zu flashen (bei DualBoot-Modellen auch in beiden Partitionen mit einem anschließenden "normalem" Firmwareupdate), unabhängig davon, ob dies der Vorbesitzer bereits getan hat oder nicht. Bei neu erworbenen Boxen hatte ich das aber bisher nicht gemacht (werde ich in Zukunft aber nun auch bei diesen machen ), also zumindest was das Auslesen des Counter und Environment betrifft.


Bekannt ist ja jedenfalls schon länger, dass bei DualBoot-Modellen die Variable "linux_fs_start" erst beim nächsten (regulären) Firmware-Update angelegt wird (anstatt "linux_fs_start 0" bei Auslieferung). Neu war mir jedenfalls der angehängte Wert "recovered=1" bei der Variable "firmware_info". Ich kannte bisher (aus der Praxis) nur "recovered=2" (Recover, also nach dem Einsatz des Recovery-Tool von AVM) oder "recovered=3" (Laden der Werkseinstellungen bspw. per Webinterface).


Laut der /etc/init.d/E03-flash_update (7590, FRITZ!OS 7.12) wird wohl auch bei recovered=1 das UBI-Filesystem neu angelegt:
1|2) # [1:ar7man 2:recover 3:factorydef]

Aber das passiert ja nur, wenn die Firmware aus dem RAM gestartet wird (sonst wäre ja auch die Filesystem-Partition weg und die Box könnte nicht mehr starten) und das ist beim 1. Start einer fabrikneuen Box beim Kunden nicht der Fall.

Daher frage ich mich gerade, ist dieser recovered-Wert bei "firmware_info" bei allen (mutmaßlich) fabrikneuen Fritzboxen vorhanden bzw. normal (also noch bevor diese beim Kunden das erste mal gestartet wird)? Wenn ja, wie lange ist das schon der Fall bzw. bei/seit welchen Modellen?

Wenn ich das richtig verstanden habe (bitte korrigieren falls ich mich täusche), wird auch bei recovered=1 das TFFS neu erstellt (also quasi Laden der Werkseinstellungen), aber wozu ist das notwendig bei einer "fabrikneuen" Box?

 

[stoney]

Bekannt ist ja jedenfalls schon länger, dass bei DualBoot-Modellen die Variable "linux_fs_start" erst beim nächsten (regulären) Firmware-Update angelegt wird (anstatt "linux_fs_start 0" bei Auslieferung). Neu war mir jedenfalls der angehängte Wert "recovered=1" bei der Variable "firmware_info". Ich kannte bisher (aus der Praxis) nur "recovered=2" (Recover, also nach dem Einsatz des Recovery-Tool von AVM) oder "recovered=3" (Laden der Werkseinstellungen bspw. per Webinterface).

Hab das mit dem angehängten recovered=1 ebenfalls im Auslieferungszustand stehen gehabt (füge die ausgelesenen ENVs vom PC aus nachträglich ein)

7520

DMC                   SL1
HardwareFeatures      nand=0xC2F1809502,cpu=0x979
HWRevision            247
HWSubRevision         2
ProductID             Fritz_Box_HW247
SerialNumber          L0457xxxxxxxxxxx
annex                 B
autoload              yes
bootloaderVersion     1.10211
firstfreeaddress      0x8824E568
firmware_info         175.07.03,recovered=1
firmware_version      1und1
flashsize             nor_size=0MB sflash_size=0KB nand_size=128MB
maca                  98:xx:xx:xx:xx:xx
macb                  98:xx:xx:xx:xx:xx
macwlan               98:xx:xx:xx:xx:xx
macwlan2              98:x:xx:xx:xx:xx
macdsl                98:xx:xx:xx:xx:xx
memsize               0x10000000
mtd0                  0x0,0x2C00000
mtd1                  0xB00000,0xF00000
mtd2                  0x0,0x2C0000
mtd3                  0x2C0000,0xB00000
mtd4                  0xF00000,0x1300000
mtd5                  0x1300000,0x8000000
my_ipaddress          192.168.178.1
prompt                Eva_AVM
usb_board_mac         98:xx:xx:xx:x:xx
usb_device_id         0x0000
usb_device_name       USB DSL Device
usb_manufacturer_name  AVM
usb_revision_id       0x0000
usb_rndis_mac         98:xx:xx:xx:xx:x
webgui_pass           xxxxxx
wlan_key              xxxxxxxxxxxx
wlan_ssid             FRITZ!Box#7520#xx

 

[PeterPawn]

Ich würde das "ar7man" eher in Richtung "ar7 - manufacturing" interpretieren und der Unterschied zwischen 1 und 2 auf der einen und 3 auf der anderen Seite ist m.W. das Löschen (des Inhalts) einer vorhandenen "config"-Partition (zumindest bei der 7490).

Ich nehme mal an, daß da bei den Tests in der Produktion irgendwelche Daten in der YAFFS2-Partition (bei GRX ist das dann eine UBI-Partition, aber eine, die zu klein für ein UBIFS-Formatierung ist, weil die Anzahl der LEBs (Logical Erase Blocks) nicht dafür reicht bei der geringen Größe - also wird das für die Tests im Werk verwendete Image da ggf. auch wieder YAFFS2 oder JFFS2 speichern, was in den Release-Versionen aber nicht enthalten ist) gespeichert werden könnten. Ich habe allerdings bisher auch bei neuen Boxen da noch nichts in den Partitionen gefunden, ist aber auch schon länger her, daß ich das geprüft habe und ich habe nicht jede Woche eine fabrikneue Box in der Mangel, der ich schon vor dem ersten Start auf die Finger sehen kann.

Diese "config"-Partition wird dann erst beim nächsten Start gelöscht, nachdem/während das OS installiert wurde, aber vielleicht hat AVM da auch nicht die "Geduld" (bzw. Zeit), um die Boxen nach der Kalibrierung und Finalisierung noch einmal mit dem "richtigen" OS komplett starten zu lassen und hängt die gleich ab, nachdem sie (per TFTP oder "psupportd_sendmsg") die erfolgreiche Installation gemeldet haben. Wobei auch der finalisierte Bootloader (mit den "Geburtsdaten") ja irgendwie installiert werden muß, da gibt's also vermutlich "spezialisierte Images" für diese Tests und das Finalisieren (sieht man auch an den "Resten" verschiedener Skripte, die in "ptest" verwendet werden und im ausgelieferten System nur "Dummies" sind).

Wobei das bei einer 7590 auch komisch ist (und wohl doch auf das Schreiben des "ersten" TFFS-Images zurückzuführen sein dürfte - ob bei der Produktion tatsächlich aus dem RAM installiert wird durch einen Neustart, bezweifle ich irgendwie auch) ... denn AVM hat da beim Übergang von VR9 auf GRX ohnehin ein (zumindest mögliches) Problem beim Umgang mit dem "recovered=X" eingebaut - vermutlich ohne das überhaupt zu bemerken (für "Absicht" sehe ich jedenfalls keine Anzeichen).

Während ja bei den VR9-Modellen die Firmware-Installation in den Flash-Speicher schon vor dem "pivot_root" auf das SquashFS-Dateisystem erfolgt und es danach sofort einen Neustart gibt, bei dem "firmware_info" noch einmal denselben Wert hat, läuft das bei den GRX-Boxen deutlich anders.

Hier wird ja sofort das SquashFS-Dateisystem als "rootfs" gemountet und bei der Abarbeitung der "/etc/init.d/rc.S" (bis 07.19) wird zuerst "/etc/init.d/S01-head" ausgeführt, wobei in dieser dann bereits der Wert von "recovered=X" ausgelesen und in der Environment-Variablen "Recover_was_here" gespeichert wird, bevor er - schon in dieser "S01-head" - dann auch sofort gelöscht wird.

Das Skript zum Installieren des OS im Flash (/etc/init.d/E03-flash_update) wird erst nach allen anderen "S0*"-Dateien aufgerufen ... darin wird dann anhand von "Recover_was_here" auch entschieden, ob jetzt der Teil des NAND-Flashs, der über UBI verwaltet werden soll (das ist alles, was nicht Bootloader, TFFS oder Kernel wäre), mittels "ubiformat" neu initialisiert wird oder nicht ... da gehört sowohl diese "config"-Partition dazu, als auch die beiden "filesystem"-Partitionen und das "nand-filesystem" fürs NAS.

Nur diesem "ubiformat" ist es jetzt auch zu verdanken, daß bei den GRX-Modellen tatsächlich event. vorhandener alter NAS-Inhalt auch gelöscht wird ... das, was bei diesen Modellen dann noch in der "S15-filesys" steht:

if [ -n "${AvmUserDataDev}" ] && [ -n "${mtd_nand}" ] && [ -n "${Recover_was_here}" ] ; then
## erase (formatting) due to preceding recover
## ubi: truncate volume (wipe it out)
nand_erasestring="ubiupdatevol ${AvmUserDataDev} -t"
echo "[ubi/Recover] Internal Memory erasing with cmd: ${nand_erasestring}"
if ${nand_erasestring} ; then
echo "[ubi/Recover] Internal Memory erasing done"
else
echo "[ubi/Recover] Internal Memory erasing failed"
fi
fi

, ist - zumindest im kommentierten Fall des "preceding recover" - nur noch Theaterdonner.

Das wirkt zwar noch beim Zurücksetzen auf die Werkseinstellungen (da ist "Recover_was_here" ja dann "3" und außerdem erfolgt(e) kein Neustart und auch kein "ubiformat" in "E03-flash_update"), aber wenn tatsächlich das Recovery-Programm verwendet wurde, wurde das "recovered=X" auch schon bei dem Start, der letztlich zur Installation führte, wieder gelöscht und wenn das System in der "S15-filesys" vorbeikommt (nämlich beim nächsten Start, nunmehr aus dem Flash), ist da gar kein "Recover_was_here" mehr gesetzt und daher wird da auch (bei den GRX-Boxen) nichts noch einmal formatiert.

Wie gesagt ... wenn AVM das hier nur nach dem Resultat beurteilt, macht man "alles richtig", weil das "ubiformat" in der "E03-flash_update" auch den Inhalt der NAS-Partition entsorgt. Aber wehe, wenn das irgendwann mal unabhängige Partitionen sein sollten (z.B. bei einer Box mit eMMC fürs NAS und "normalem" NAND-Flash für "den Rest") und das "ubiformat" dann das Löschen der alten NAS-Inhalte nicht automatisch mit einschließt ... dann wäre es wohl wieder notwendig, das "recovered=X" über den Installationsprozess hinaus zu retten oder zumindest die (NAS-)Partition gesondert zu löschen.

Im Moment mag das noch alles gut ausgehen ... aber mir fehlt in den entsprechenden Skript-Dateien auch der Hinweis darauf, daß es nicht nur eine glückliche Fügung ist, daß beim "ubiformat" eben ALLES in dem durch UBI verwalteten Teil des NAND-Flashs gelöscht wird (was ja u.a. auch dafür verantwortlich ist, daß nach Recovery das System in der zweiten Partition bei diesem Modellen ebenfalls nicht mehr benutzbar ist, weil auch dessen "filesystem"-Partition davon betroffen ist).

 

[NDiIPP]

Danke @stoney und @PeterPawn. Scheint also (mittlerweile?) normal zu sein bei Auslieferung im "fabrikneuen" Zustand bei VR9, GRX5 und IPQ-Modellen.


Wie schon erwähnt, hatte ich bisher bei fabrikneuen Boxen nicht nachgeschaut. Nur bei einer 6490 von UM, welche ein UM-Kunde vor etwas über einem Jahr geliefert bekommen hatte (Ende 2018) hatte ich mal nachgeschaut. Da war dieser Wert jedoch nicht vorzufinden. Die Box war zwar nicht nigelnagelneu (laut Seriennummer) aber auch nicht so alt, dass man davon hätte ausgehen können, dass sie bereits bei einem anderen UM-Kunden in Betrieb war. Also die Box kam wohl eher unbenutzt aus dem Lager.

Ich hatte damals bei dieser (mutmaßlich) neuen (weißen) 6490 von UM auch nur deshalb zu Beginn Environment und Counter ausgelesen (vor dem 1. Start), weil ich die aktuelle Firmware für UM-Boxen vor dem 1. Start und Einrichtung darauf installieren wollte (allein schon um sofort die Vorzüge von FRITZ!OS 6.8x nutzen zu können was ja bei der 6490 aufgrund der damit neuen Prozessoraufteilung nicht gerade unerheblich war) und das quasi nur die Vorbereitung zum flashen der aktuellen UM-Firmware per Bootloader war (das war möglich, da ich das cvc-File der damals aktuellen FRITZ!OS-Version für UM-Boxen zur Verfügung hatte, sie wurde also nicht mit der Retail-Firmware geflasht da sie bei diesem UM-Kunden betrieben werden sollte).

Jedenfalls fehlte (erwartungsgemäß) bei dieser 6490 im Environment noch die Variable linux_fs_start und ausgeliefert wurde sie laut "firmware_info" mit der Ver. "141.06.52". In das alternative Partitionsset installierte ich dann (vor dem allerersten Start) die Ver. 141.06.88 für UM-Boxen (welche damals noch bei nur wenigen UM-Kunden bereits im Einsatz war). Also entweder macht das AVM bei den Puma6-Modellen nicht oder es liegt an einer etwas anderen Behandlung der Provider-Modelle. Oder die Box war doch nicht unbenutzt.


Ansonsten kann man diesen Wert in der Variable "firmware_info" wohl als weiteres Indiz nutzen, um zu erfahren, ob man beim Erwerb einer neuen Fritzbox tatsächlich eine neue Fritzbox erworben hat und bspw. nicht bereits einen in Benutzung gewesenen Rückläufer, eine "refurbished" Box o.ä. Ein Beweis ist es natürlich nicht, da sich das natürlich wie der Counter entsprechend ändern lässt.

 

[Micha0815]

Leider wurde das Thema "FRITZ!Box-Kennwort auf Geräterückseite falsch" bereits von einem Moderator geschlossen

Da der dortige TE mittlerweile mit etwas Anlaufschwierigkeiten dank @PeterPawns PS-Scripten seine Box auslesen konnte und mich per PN kontaktierte ... ein paar sachdienliche Erkenntnisse aus meiner Sicht.

DEBUG: Response:
150 Opening BINARY data connection
226 Transfer complete

================
HWRevision            236
HWSubRevision         2
ProductID             Fritz_Box_HW236
SerialNumber          L261...............7
annex                 B
autoload              yes
bootloaderVersion     1.3584
firstfreeaddress      0x8824DE08
firmware_info         164.07.03
firmware_version      avm
flashsize             nor_size=0MB sflash_size=0KB nand_size=128MB
...
memsize               0x10000000
mtd0                  0x0,0x2C00000
mtd1                  0xB00000,0xF00000
mtd2                  0x0,0x2C0000
mtd3                  0x2C0000,0xB00000
mtd4                  0xF00000,0x1300000
mtd5                  0x1300000,0x8000000
my_ipaddress          192.168.178.1
prompt                Eva_AVM
...
webgui_pass           bekannt
wlan_key              123...
wlan_ssid             FRITZ!Box#7530#KC
....
================
DEBUG: Sent
RETR count
================
DEBUG: Response:
150 Opening BINARY data connection
226 Transfer complete

================
reboot_major          1
reboot_minor          0
run_hours             2
run_days              0
run_mounths           0
run_years             0

Die Serial auf dem Aufkleber ist identisch bis auf die Endziffer 9 statt 7. (Neben anderem WLAN-Key, GUI-Passwort, SSID, CWMP-Account... versteht sich).
Laut Serial am Montag -Omen est Nomen- dem 24.6.2019 produziert, wo wohl schon Schulferien in Berlin und Brandenburg waren. Neben dem Counter weist imho fast alles auf einen Fehler beim "Verheiraten" von Platine und Unterschale hin, wobei zu hoffen ist, dass es sich nicht als fortlaufender "Fliessbandfehler" auf die ganze Tagescharge auswirkte?
Ich meine, dass damit die dunklen Verschwörungstheorien halbwegs ausgemerzt sind.
Persönlich denke ich dabei an einen "Ferienjobber", der unwissend ggfs. einen Montagefehler o.ä. rasch cachieren wollte am ersten Arbeitstag ...
LG
Falls der "Schliesser" diesen Beitrag verschieben mag ... büddeschon

 

[KunterBunter]

Schulferien in Berlin und Brandenburg

Nicht die Falschen loben. Die Fertigung ist, wenn überhaupt in Deutschland, wohl immer noch in BW.

 

[Micha0815]

Nicht die Falschen loben

Ok, dann schieben wir es auf den lustlosen Praktikanten, der dem Produktionsleiter und Schwiegervater-in-spe eins auswischen wollte ... DuW

 

[NDiIPP]

Nachtrag: Im Gegensatz zu Fehlprägungen der staatlichen "Münzen" dürfte eine fehlerhafte "Werks-Box" keinen gesteigerten Sammlerwert als Kuriosum erzielen

Sicher?