[Problem] FritzBox 6490 Netzwerk-Setup zurücksetzen

[prisrak1]

Auch wenn ich Verzeichnisse mit dem Befehl: export PATH=$PATH:/tmp/ oder export PATH=$PATH:/home/freetz/YourFritz-master/
cd /home/freetz/YourFritz-master/tffs/
freetz@freetz-linux:~/YourFritz/tffs$ ./build_tffs_image tffs_name_table /tmp/env.txt /tmp/count.txt > /tmp/mtd.img
komt:

Spoiler: Ausgabe

...
./counter_to_tffs: 84: ./counter_to_tffs: yf_word_of: not found
./counter_to_tffs: 87: ./counter_to_tffs: yf_from_right: not found
./counter_to_tffs: 88: ./counter_to_tffs: yf_reverse_hex: not found
./counter_to_tffs: 89: ./counter_to_tffs: yf_dec2hex: not found
./counter_to_tffs: 92: ./counter_to_tffs: yf_hex2bin: not found
./build_tffs_image: 63: ./build_tffs_image: yf_hex2bin: not found

in /tmp/ wird mtd.img mit 0 groß gebildet

 

[PeterPawn]

Entweder es wurde nicht das gesamte Repository geklont oder irgendetwas anderes ist faul.

Normalerweise wird - sofern die Variable YF_SCRIPT_DIR nicht gesetzt ist - im aktuellen Verzeichnis nach "yf_helpers" gesucht und nach einem ordentlichen (und vollständigen) Klonen sollte es im Verzeichnis einen Symlink mit dem Namen "yf_helpers" geben, der auf "../scriptlib/yf_helpers" zeigt (ebenso einen Symlink für ein Verzeichnis "functions", der auf "../scriptlib/functions" zeigt) und natürlich auch das parallel zu "tffs" liegende Verzeichnis "scriptlib" mit der (inzwischen POSIX-kompatiblen, also auch "dash"-tauglichen) Shell-Library.

Ohne diese Voraussetzungen (die aber eben beim vollständigen Klonen automatisch geschaffen werden müßten) findet die Shell halt die notwendigen Funktionen nicht ... und wenn das tatsächlich ein kompletter YourFritz-Klon aus GitHub ist, bei dem dieser Fehler auftritt, dann bitte die "Fehlermeldung" dafür mit komplettem Protokoll der Session abgeben - und zwar vom Klonen aus GitHub über das Ändern des SheBang bis zum Aufruf des Skripts.

Mit einer zwischenzeitlichen Änderung an der Bibliothek und am "yf_helpers"-Skript bzw. an dessen Einbinden über die Zeile

. ${YF_SCRIPT_DIR:-.}/yf_helpers

sollte es auch nicht mehr notwendig sein, das aktuelle Verzeichnis in den Suchpfad für ausführbare Dateien aufzunehmen, wenn das gesamte "build_tffs_image" mit "./build..." aufgerufen wird, da interne Aufrufe der anderen Skriptdateien in demselben Verzeichnis (abgesehen von den Funktionen in "scriptlib") mittels

${0%/*}

den "Verzeichnisnamen" aus dem Aufruf-Namen von "build_tffs_image" ableiten.

Wenn man die Skript-Dateien von anderer Stelle aufrufen will und einen vollständigen Pfad dorthin beim Aufruf angibt, muß man eben parallel dazu über die Variable "YF_SCRIPT_DIR" noch angeben, wo das Verzeichnis "scriptlib" zu suchen ist.

 

[prisrak1]

Die Skripte können bei mir die Dateien env count leider nicht fühlen. Warum? Diese bleiben also nach wie vor leer. Ich hab also die count und nametable aus den Beiträgen von oben und meine eigene env in den temp eingefügt und einen mtd.img erzeugen lassen. Auch wenn ich meinen eigenen env überarbeite und einen mtd.img erzeuge, komme ich zwar ohne Passwort rein, aber die eigenen Einstellungen sind verschwunden. Was mache ich verkehrt?
... in env:
tr069_passphrase SECRET
....
webgui_pass SECRET
wlan_key SECRET

 

[PeterPawn]

Wenn das als Frage an mich gerichtet war, verstehe ich sie nicht - das wird ja hoffentlich nicht wirklich "Verwunderung" sein, wenn nach dem Schreiben eines TFFS-Images die Einstellungen weg sind. Jedenfalls dann, wenn man die nicht ebenfalls gesichert hat und beim "build_tffs_image" mit einbauen läßt ... irgendwie hege ich den Verdacht, daß Du (@prisrak1) da entweder keinen Plan hast, was das TFFS überhaupt ist oder Du drückst Dich sehr ungeschickt aus.

Bei "count" macht es bei der 6490 meiner Meinung nach nichts, weil man/ich mit den Werten darin (das sind alles "u"s und zwar tatsächlich für jeden Wert) ohnehin nichts anfangen kann und das daher mit Null ersetzt wird.

Wenn sich ein Environment (also "env") nicht richtig auslesen läßt, liegt das i.d.R. am falschen TFFS-Inhalt (es soll schon Leute gegeben haben, die Textdateien in MTD3 und MTD4 geschrieben haben) oder es funktioniert grundsätzlich nicht. Da es beim Auslesen sicherlich auch ein Protokoll gibt (wenn nicht, fertigt man einen Paketmitschnitt mittels "wireshark" an), muß man da aber auch nicht wirklich raten und kann sich dem Problem und seiner Ursache auch systematisch nähern.

Was das jetzt aber wieder damit zu tun hat, daß da die Funktionen aus der Shell-Library nicht gefunden werden (siehe #61), verstehe ich auch nicht.

 

[Freesurf]

Hi Leute,
also ich hab das Repository von PeterPawn gecloned (auch zweimal, weil ich mir nicht sicher war), aber es gibt keine tffs_name_table ergo kann ich auch den letzten Schritt für das bauen nicht machen.
Das env und die counter auslesen war kein Problem, hab sie mir auch mit less mal angesehen, sieht soweit okay aus (zumindest, was ich beurteilen kann). Google hat mich leider nicht weitergebracht mit der tffs_name_table kam ich auf diesen Thread und die darauf kopierte Anleitung von TriebWerk23. Hat einer einen Tip für mich?

 

[prisrak1]

nametable

510 @L
431 AutoMDIX
259 DMC
256 HWRevision
260 HWSubRevision
257 ProductID
258 SerialNumber
425 annex
385 autoload
512 bb0
513 bb1
514 bb2
515 bb3
516 bb4
517 bb5
518 bb6
519 bb7
520 bb8
521 bb9
386 bootloaderVersion
387 bootserport
428 bluetooth_key
388 bluetooth
424 country
389 cpufrequency
417 crash
390 firstfreeaddress
430 firmware_info
422 firmware_version
391 flashsize
441 jffs2_size
416 kernel_args
415 kernel_args1
423 language
408 linux_fs_start
392 maca
393 macb
394 macwlan
406 macwlan2
395 macdsl
396 memsize
397 modetty0
398 modetty1
452 modulemem
432 mtd0
433 mtd1
434 mtd2
435 mtd3
436 mtd4
437 mtd5
438 mtd6
439 mtd7
442 mtd8
443 mtd9
444 mtd10
445 mtd11
446 mtd12
447 mtd13
454 mtd14
455 mtd15
399 my_ipaddress
453 plc_dak_nmk
400 prompt
451 provider
426 ptest
401 reserved
402 req_fullrate_freq
403 sysfrequency
449 tr069_passphrase
448 tr069_serial
509 urlader-version
404 usb_board_mac
418 usb_device_id
420 usb_device_name
421 usb_manufacturer_name
419 usb_revision_id
405 usb_rndis_mac
450 webgui_pass
440 wlan_cal
427 wlan_key
456 wlan_ssid

 

[Freesurf]

@prisrak1 : Vielen Dank. Wo bekommt man denn die in der Regel her? Kann man die auch aus der Box auslesen?
Btw.: Gibt es eine Möglichkeit das originale tffs_image (mtd3/4) zu exportieren / speichern?

 

[prisrak1]

ich habs von
fesc Seite 1, #7, Punkt 6. So hat es bei mir funktioniert. Wenn es geht, dann suche ich auch nicht weiter.

 

[Freesurf]

Wer lesen kann ist klar im Vorteil, die Liste habe ich vorhin nicht gesehen, evtl weil ich nicht eingeloggt war oder einfach noch den Morgen in den Augen.. Dank dir!

 

[PeterPawn]

Die Name-Table existiert schon noch im Repository ... sie hat nur (minimal) ihren Platz geändert, nach: https://github.com/PeterPawn/YourFritz/blob/master/tffs/data/nametable_@L - es wurde halt immer unübersichtlicher in diesem Verzeichnis und daher mußte ich ein bißchen umräumen.

 

[Freesurf]

Hallo @PeterPawn,

danke für den Hinweis.
Hast Du zufällig auch noch einen Rat für die Fragestellung des Backups der mtd3/4? Ich würde die ungerne einfach überbügeln.

 

[PeterPawn]

Wenn das FRITZ!OS auf der Box nicht mehr erreichbar ist (ich gehe mal davon aus, daß dieses der Grund wäre, warum man sein eigenes TFFS schreiben will), dann wirst Du auf das Backup verzichten müssen - ansonsten wäre das ja in den "Erweiterten Support-Daten" bereits enthalten.

Ohne Background-Infos, warum Du eigentlich hier gelandet bist, ist da auch schwer ein anderer Rat zu geben ... ich bin ja auch für Backups zu haben und empfehle diese ständig (allerdings eben zu einem Zeitpunkt, wo das Gerät noch funktioniert), aber wenn das Kind schon ins Korn geworfen wurde, muß man das TFFS halt überschreiben. Ein lesender Zugriff über den FTP-Server im Bootloader (für die "echten" Daten dieser Box) sollte ja weiterhin möglich sein, wenn man nicht bereits den alten TFFS-Inhalt zerstört hat ... und dann bräuchte man auch kein Backup dieses kaputten TFFS mehr (es sei denn, man will das tatsächlich untersuchen, wie es dazu gekommen sein kann).

 

[Freesurf]

Also ich hol mal etwas aus....
Ich habe eine Unitymediabox gekauft, die bestens funktioniert (laut Beschreibung zumindest).
Auf dem ersten Partitionsset befindet sich die originale Unitymediafirmware, leider bootet sie permanent neu. Aus welchem Grund kann ich leider nicht sagen.
Ich habe mal eine andere Firmware in das zweite Partitionsset geflasht und auch die firmware_version und linux_fs_start entsprechend geändert, aber auch damit kein booten möglich.
Da ich mir nicht besser zu helfen weiß, würde ich es mit dem tffs "reset" probieren. Der Verkäufer ist keine Hilfe, angeblich ging sie problemlos, lag dann eine Weile im Schrank und wurde anschließend verkauft.
Ich hatte in einem anderen Thread von @ice012345 auch fleißig gelesen wegen seiner Box mit defektem WLAN (scheinbar Hardware), allerdings bin ich ausgestiegen bei Kabel anlöten um logfiles seriell aus / mitzulesen. Natürlich wäre ich an einer Analyse VOR dem "Überbügeln" interessiert, siehst Du da noch andere Möglichkeiten? Kann man die logfiles irgendwie über eva runterladen oder lesen?

 

[PeterPawn]

siehst Du da noch andere Möglichkeiten?

Nein ... über den Bootloader kann man nur das TFFS hinsichtlich der Environment-Variablen aus der Name-Table (zzgl. der Zählerstände - die aber m.W. dabei immer als "u" ausgegeben werden - und der Kalibrierungsdaten in "config") auslesen (soweit das bekannt ist) und auch andere Optionen (wie das Starten eines Systems im Speicher - womit man dann an andere Partitionen lesend herankäme) müssen bei der 6490 anders angegangen werden - hier verweise ich dann auf die Quellen zu den Puma6-Modellen, falls sich jemand schlau machen will, wie dort die FS-Parser im Kernel arbeiten.

Da Dir der Verkäufer die wohl ohnehin nicht mehr abnehmen wird, würde ich hier ganz einfach ohne "Beweissicherung" weitermachen und mal ein frisches TFFS-Image (natürlich mit den korrekten Daten für genau diese Box) flashen lassen ... wobei eben die Sicherung der noch erreichbaren Daten (env, counter, config) über "RETR" im Bootloader tatsächlich zum Pflichtprogramm VOR dem Überschreiben des TFFS gehört. Aber weitergehender Aufwand hinsichtlich alter Daten ist dann (meiner Meinung nach jedenfalls) verschwendete Energie und Zeit ... wobei eben ein "boot loop" auch noch sehr viele verschiedene Ursachen haben kann und man mit ein paar Versuchen das schon noch etwas eingrenzen könnte, wie weit das System wohl beim Start tatsächlich kommt - daraus kann man dann Schlüsse ziehen, wo die Fehlkonfiguration vielleicht liegt. Aber solange man am Ende ohnehin das TFFS überschreiben muß beim Versuch, die Box wieder zum "Durchstarten" zu bewegen, stellt sich halt die Frage, was man davon hat ... außer einem besseren, eigenen Verständnis, wie die Firmware eigentlich arbeitet.

 

[Freesurf]

Also auf Basis der hier genannten Anleitung habe ich die env und die counter ausgelesen, config noch nicht, werde mir mal ansehen, ob das genauso funktioniert wie env und counter und dann genauso verfahren bezüglich Sicherung.
Ich würde mich schon sehr gerne auch weiter mit der Firmware beschäftigen und verstehen, wie sie arbeitet, nur möglichst ohne Hardwareanpassungen.

 

[Freesurf]

So, Box läuft wieder, vielen Dank für die Unterstützung!

 

[wutz65]

Gibt es eine Möglichkeit an einer 6490 wieder in den Bootloader / FTP / serielle Konsole zu kommen, wenn mtd3 und mtd4 mit falschen Daten beschrieben wurde?
Beim debranden einer Box die beiden Bereiche gelöscht und beim Verusch die wieder zu erstellen einen Fehler gemacht.
Jetzt blinken einmal alle LED´s und dann nur noch die Info rot.
FTP über 192.168.178.1 nicht mehr möglich. Supportdaten hatte ich von beiden Startsets gesichert.

 

[stoney]

Wenn die Supportdaten in erweiterter Form vorliegen, kannst Du mit yourfritz/tffs/build_tffs dieses wieder erstellen und mit yourfritz/eva in mtd3/4 schreiben.

 

[Micha0815]

FTP über 192.168.178.1 nicht mehr möglich

Falls dies zutrifft, dürfte es schwer sein mit den eva_tools
LG

 

[wutz65]

Genau das ist mein Problem - aber selbst schuld ich weiß.