[Problem] 7360: blinkt 4 mal dann grün, nicht erreichbar nach flash, firmware_info: recovered=2

[HarryHase]

sehr ähnliches Problem wie hier: http://www.ip-phone-forum.de/showthread.php?t=232256

Nur behebt es sich bei mir nicht von selbst.

1) Das komische ist ich komme an die Box nur über LAN3 (1/2/4) geht nicht.
2) Mit ru_kernel_tools kann ich die Box in Adam2 anhalten und auch die firmware info setzen, dann erkennen die recover.exe die box und restaurieren sie ABER dann bootet die Box nicht und es ist wieder recovered=2 gesetzt

Ich habe noch eine 7260 hier und da ist mit aufgefallen dass dort mtd0 nicht angezeigt wird, bei der defekten Box schon

Box_defekt

firmware_info: recovered=2
firstfreeaddress: 0x81133770
kernel_args: annex=B
mtd0: 0x90000000,0x90000000
mtd1: 0x90020000,0x91F80000
mtd2: 0x90000000,0x90020000
mtd3: 0x91F80000,0x91FC0000
mtd4: 0x91FC0000,0x92000000
req_fullrate_freq: 250000000
sysfrequency: 250000000
urlader-version: 3473
usb_board_mac: 9C:C7:A6:12:C5:14
usb_device_id: 0x0000
usb_manufacturer_name: AVM
usb_revision_id: 0x0000

box_gut

crash: [0]c0616d45,55d51159,1[1]0,0,0[2]3b6f080,55d51159,1[3]0,0,0
firmware_info: 124.06.50
firstfreeaddress: 0x810F2268
jffs2_size: 16
mtd1: 0x90020000,0x91F80000
mtd2: 0x90000000,0x90020000
mtd3: 0x91F80000,0x91FC0000
mtd4: 0x91FC0000,0x92000000
provider: netcologne_7360_210115
sysfrequency: 250000000
urlader-version: 2475
usb_board_mac: 34:31:C4:F5:59:23
usb_device_id: 0x0000
usb_device_name: USB DSL Device

jemand eine Idee?

 

[PeterPawn]

Das "recovered=2" in "firmware_info" ist vollkommen normal, nachdem man Recovery ausgeführt hat. Anhand dieses Wertes erkennt die Firmware (ziemlich früh in /etc/init.d/Sxx-irgendwas), daß sie den NAND-Flash (bei bestimmten Modellen) ebenfalls löschen soll.

Ansonsten sind die Auszüge aus den Urlader-Einstellungen ja eher uninformativ ... da sieht man nicht einmal wirklich sicher, daß die zweite Box (angeblich ja eine 7260) tatsächlich dasselbe Modell ist, wie die erste (zumindest bei der EVA-Version ist das schon mal nicht der Fall).

Wenn das die komplette Ausgabe des Auslesens mit dem ruKernelTool sein sollte, dann funktioniert offensichtlich die LAN-Verbindung nicht richtig, weil praktisch beide Listen unvollständig sind. Da solltest Du vermutlich mal mit einem ordentlichen "RETR env" rangehen ... das ruKT liest das ganze Zeug m.W. mit einzelnen "GETENV"-Kommandos und vermutlich klappt davon die Hälfte nicht (das sollte die Debug-Ausgabe aber zeigen). Ich würde auch mal einen FE-Switch zwischen Rechner und Box schalten, das hört sich für mich nach einem Problem mit "auto sensing" an.

 

[HarryHase]

oh sorry, habe vergessen zu erwähnen das ich identische Ausgaben weggelassen habe, aber hier noch mal die Vollständigkeit der defekten Box

  Box-Informationen:
    ProductID:                 Fritz_Box_HW196
    HWRevision:                196
    HWSubRevision:             2
    SerialNumber:              0000000000000000
    annex:                     B
    autoload:                  yes
    bootloaderVersion:         1.2473
    bootserport:               tty0
    cpufrequency:              500000000
    firmware_info:             recovered=2
    firmware_version:          avm
    firstfreeaddress:          0x81133770
    flashsize:                 nor_size=32MB sflash_size=0KB nand_size=0MB
    kernel_args:               annex=B
    maca:                      9C:C7:A6:12:C5:10
    macb:                      9C:C7:A6:12:C5:11
    macdsl:                    9C:C7:A6:12:C5:13
    macwlan:                   9C:C7:A6:12:C5:12
    memsize:                   0x08000000
    modetty0:                  38400,n,8,1,hw
    modetty1:                  38400,n,8,1,hw
    mtd0:                      0x90000000,0x90000000
    mtd1:                      0x90020000,0x91F80000
    mtd2:                      0x90000000,0x90020000
    mtd3:                      0x91F80000,0x91FC0000
    mtd4:                      0x91FC0000,0x92000000
    my_ipaddress:              192.168.178.1
    req_fullrate_freq:         250000000
    prompt:                    Eva_AVM
    sysfrequency:              250000000
    tr069_passphrase:          tL5HehgfjghJ4N
    tr069_serial:              00040E-9CC7862C510
    urlader-version:           3473
    usb_board_mac:             9C:C7:A6:12:C5:14
    usb_device_id:             0x0000
    usb_manufacturer_name:     AVM
    usb_revision_id:           0x0000
    usb_rndis_mac:             9C:C7:A6:12:C5:15
    wlan_key:                  7868ghhkh


  Flash-/Speichergrößen:
    Memsize:   134.217.728 Bytes (131.072 kB, 128 MB, 0,1 GB)
    mtd0:                0 Bytes
    mtd1:       32.899.072 Bytes (32.128 kB, 31,4 MB)
    mtd2:          131.072 Bytes (128 kB, 0,1 MB)
    mtd3:          262.144 Bytes (256 kB, 0,3 MB)
    mtd4:          262.144 Bytes (256 kB, 0,3 MB)


  ProductID:   Fritz_Box_HW196
  HW-Revision: 196  => FRITZ!Box Fon WLAN 7360 v2 (32 MB)

Wie schon geschrieben, Zugang nur über LAN3

 

[PeterPawn]

Noch einmal ... versuche mal über "RETR env" das gesamte Environment auszulesen.

Warum?

Weil diese Anzeige im ruKT nur auf extrem kurzen TCP-Paketen beruht, da eben immer nur ein "GETENV variable" gesendet wird und eine entsprechende Antwort zurückkommt.

Das Schreiben der neuen Firmware verwendet aber maximal lange Blöcke (was ja offenbar nicht richtig funktioniert, wenn die Box hinterher nicht startet) und das Auslesen des Environments auch (solange da genug zusammenkommt, allerdings sollte es für ein komplettes Paket mit MTU-Länge reichen).

Und noch einmal ... was passiert denn an den anderen Ports, wenn Du da einen FE-Switch zwischen die FRITZ!Box und den verwendeten PC hängst? Es ist schon recht merkwürdig, wenn da nur ein einzelner LAN-Port funktioniert ... wobei es sicherlich nicht unmöglich ist, denn m.W. (das ist mit entsprechender Vorsicht zu genießen), sind die PHYs für die ersten beiden Ports im Chipsatz und für die anderen beiden gibt es jeweils einen getrennten. Aber da 3 und 4 ja auch noch FE-PHYs sind, bin ich bis zu einem entsprechenden Test erst einmal skeptisch, ob es eben nicht nur am "auto sensing" für den Ethernet-Modus (FD/HD, Geschwindigkeit) liegt. Das erklärt zwar noch nicht, warum da LAN4 auch nicht geht, aber entsprechende Toleranzen (die PHYs machen das m.W. in Hardware aus, was sie können und verwenden wollen) wären ja auch eine Erklärung.

 

[DieWilde13]

Hast Du das richtige Recovery genommen?
Laut diesem Post passt auf die HW196 die avm Firmware-Version die mit 124 anfangen und zur 7360 v2 gehören.

 

[HarryHase]

Ich habe einen switch dazwischen gesetzt, dann geht es auch mit LAN4. Also gehen jetzt 3 und 4, das Deiner Aussage oben entspricht.
Da die LED genau 4 mal blickt (ich lasse einen dauerping auf die box laufen) was zwischen 3-4 Pingantworten entspricht hat das bestimmt auch ohne switch funktioniert, nur das timing halt nicht gepasst.

Bei RETR env kommt

551 unknown Mediatype


Recoverys habe ich alle von der V2 genommen, auf der anderen Box ist das recovery exe auch durchgelaufen

- - - Aktualisiert - - -

quote MEDIA FLSH
->200 Media set to MEDIA_FLASH
quote RETR env
425 can't open data connection

 

[PeterPawn]

Ein Beispiel, wie Du das Environment über EVA auslesen kannst, findest Du hier: https://github.com/PeterPawn/YourFritz/blob/master/eva_tools/eva_get_environment

 

[HarryHase]

okay da muss ich dann ja mit einer linux büchse dran, dass muss ich die Tage mal in Ruhe durchlesen und machen, wird voraussichtlich erst nächste Woche was.

Danke schon mal soweit, wenn noch jemand eine Idee hat ...

 

[HarryHase]

Bin auf Dienstreise, aber habe mir das schon mal remote vorbereitet.
@PeterPawn: ich habe alles in ein file gepackt, ausführbar gemacht und einfach mal aufgerufen (ohne das eine Fritzbox dran, die kann ich nicht remote anschließen). Dabei erhalte ich 2 Fehlermeldungen

 ./env.sh
./env.sh: 31: read: Illegal option -u
./env.sh: 192: ./env.sh: Bad substitution

Liegt es daran das keine Box dran hängt, oder liegt es an meinem ubuntu, muss ich was anderes nutzen?

 

[PeterPawn]

Wie soll ich jetzt aus diesen drei Zeilen erkennen können, was Du da gemacht hast?

Schon mit "alles in ein file gepackt" bin ich etwas unschlüssig, ob Du nicht bereits da einen Kardinalfehler begehst. Es werden zwei Shell-Skripte benötigt, einmal das eigentliche Skript zum Auslesen des Environments und dann noch die Helper-Funktionen in der Datei yourfritz_helpers. Normalerweise würde ich erwarten, daß jemand das ganze GitHub-Repo mit den passenden Befehlen clont, wenn er damit arbeiten will und dann würde automatisch der Symllink auf yourfritz_helpers auch stimmen, selbst wenn es in einem anderen Unterverzeichnis liegt. Was Du da nun gemacht haben könntest, kann ich ja nur raten ... mir fallen bestimmt fünf grundverschiedene Interpretationen des von Dir Geschriebenen ein.

Ansonsten (aber das ist max. geraten, nur wegen der zweiten Deiner drei Zeilen) würde ich darauf tippen, daß das "read"-Kommando Deiner Shell keine Option "-u" kennt. Zwar steht im SheBang tatsächlich /bin/sh, das ist aber auf "normalen Systemen" (und das sollte auch für Dein Ubuntu eigentlich gelten) ein Synonym (zumindest meistens) für /bin/bash und ggf. müßtest Du das eben anpassen, wenn Du ein System mit einer Busybox verwendest ... es wäre denkbar, daß die Busybox da keine Auswahl des File-Descriptors zuläßt über -u.

 

[HarryHase]

sorry, damit bin ich abgehängt. Dein Annahme 1 ist richtig. Kardinalfehler, da ich nichts verstehe. Bitte was muss ich machen?

 

[PeterPawn]

Wie wäre es als erstes mit einer Beschreibung der Umgebung, in der Du das ausführen willst (Maschine, Distribution, Version) und einer Aufzählung/Erklärung dessen, was Du bei "alles in ein file gepackt" nun wirklich gemacht hast?

Ansonsten nimmt man "git clone <repo>" und erhält eine lokale Kopie der Verzeichnisstruktur im entsprechenden Repository. Dann braucht man nichts "zusammenkopieren", dann ruft man einfach im richtigen Moment (den kann man bei Vorhandensein der passenden Programme - hier ist "socat" das entscheidende - auch von "eva_discover" ermitteln lassen) das Skript mit der IP-Adresse der FRITZ!Box (i.d.R. die 192.168.178.1) als ersten Parameter EDIT: Quatsch, im Repo steht die "dumme Variante" mit fester IP-Adresse /EDIT auf und sieht dann im Terminal die Ausgabe. Ruft man den Skript-Interpreter mit "-x" auf, sollte sogar jedes Kommando im Terminal protokolliert werden (auf stderr).

 

[HarryHase]

Also ich habe keine Ahnung von Programierung, Reposetorys, clone und sonst was.
Ich dachte dass das ein bash-scrpit ist was ich in einer Linux Umgebung aufrufen muss, daher habe ich den Inhalt Deines links in eine Datei kopiert und versucht es auszuführen. Das ist aber falsch.
Wie ich jetzt aber Deinen Ausführung entnehme steckt da viel mehr hinter, was ich noch nie gemacht habe

Ich habe ein Ubuntu 14.04.01 und einen raspberry pi zur Verfügung.


ABER ich will ja lernen, darum lese ich prarallel mit google hilfe und habe auf dem ubuntu jetzt mal ein

 git clone https://github.com/PeterPawn/YourFritz

gemacht, womit ich mir wohl einen lokalen clone erzeugt habe. Zumindest sehe ich eine Unterstruktur und Dateien.

- - - Aktualisiert - - -

in /YourFritz/eva_tools
gibt es dann die Datei eva_get_environments. Ich denke dass die aufgerufen werden muss.
aber dann

/YourFritz/eva_tools$ ./eva_get_environment
./eva_get_environment: 31: read: Illegal option -u
./eva_get_environment: 192: ./eva_get_environment: Bad substitution
/YourFritz/eva_tools$

- - - Aktualisiert - - -

Ist einen andere Linux distribution dafür besser geeignet?

 

[PeterPawn]

Dann bist Du ja schon dicht dran ... als nächstes klärst Du jetzt ab, wohin /bin/sh zeigt oder änderst die erste Zeile in "eva_get_environment" gleich sicherheitshalber in /bin/bash.

Dann das Skript (sicherheitshalber) einfach mal direkt aufgerufen und wenn kein anderer Fehler auftaucht als die zu erwartenden (die Box ist ja im falschen Modus, zumindest sollte man das annehmen), dann tippt man das Kommando (nachdem man die vorherige Instanz abgebrochen hat) noch einmal ein und wartet mit dem Absenden, bis die FRITZ!Box (die natürlich mit einem LAN-Kabel mit der Maschine direkt verbunden ist oder auch über den erwähnten Switch) von den 5x Blinken bei Herstellen der Stromversorgung das erste Aufleuchten absolviert hat. Schickt man jetzt das Kommando ab, sollte das Timing eigentlich passen ... und das Skript den kompletten Inhalt des Environments der Box auslesen und ausgeben.

 

[HarryHase]

na also ...

Found AVM bootloader: AVM EVA Version 1.2473 0x0 0xB40D
Environment read from device:
HWRevision            196
HWSubRevision         2
ProductID             Fritz_Box_HW196
SerialNumber          0000000000000000
annex                 B
autoload              yes
bootloaderVersion     1.2473
bootserport           tty0
cpufrequency          500000000
firstfreeaddress      0x81133770
firmware_info         recovered=2
firmware_version      avm
flashsize             nor_size=32MB sflash_size=0KB nand_size=0MB
kernel_args           annex=B
maca                  9C:C7:A6:12:C5:10
macb                  9C:C7:A6:12:C5:11
macwlan               9C:C7:A6:12:C5:12
macdsl                9C:C7:A6:12:C5:13
memsize               0x08000000
modetty0              38400,n,8,1,hw
modetty1              38400,n,8,1,hw
mtd0                  0x90000000,0x90000000
mtd1                  0x90020000,0x91F80000
mtd2                  0x90000000,0x90020000
mtd3                  0x91F80000,0x91FC0000
mtd4                  0x91FC0000,0x92000000
my_ipaddress          192.168.178.1
prompt                Eva_AVM
req_fullrate_freq     250000000
sysfrequency          250000000
tr069_passphrase      tL5slfjsklfjklHJ4N
tr069_serial          00040E-957858712C510
urlader-version       3473
usb_board_mac         9C:C7:A6:12:C5:14
usb_device_id         0x0000
usb_manufacturer_name  AVM
usb_revision_id       0x0000
usb_rndis_mac         9C:C7:A6:12:C5:15
wlan_key              dfslfkjsfsjkfhklsfj

 

[PeterPawn]

Na ja, das sieht eigentlich erst einmal richtig aus ... solange der Parameter "annex" auf "B" steht, sollte die Wiederholung in "kernel_args" nicht nötig sein und vermutlich ist das "B" ohnehin auch in der 7360v2 Standard (muß man eben mal in die rc.conf schauen).

Jetzt würde ich mit dem Switch dazwischen einfach noch einmal (mit der richtigen Originalfirmware, nicht mit einem Freetz-Image) einen Recovery-Versuch starten ... dann sollte die Box auch in der Lage sein, da ein ordentliches System zu flashen.

Wenn nicht, ist vielleicht wirklich der NOR-Flash im entscheidenden Bereich (irgendwo zwischen 0x90020000 und 0x91F80000, wo Kernel und Dateisystem landen) so kaputt, daß die Box nicht mehr booten will.

Vermutlich könnte man auch dann noch etwas mit dem Aufbau des NOR-Flashs tricksen (die 32 MB dürften kaum vollständig benötigt werden), aber das wäre dann bei so einer alten FRITZ!Box auch nur noch "Spaß am Gerät" und hätte mit Wirtschaftlichkeit nichts mehr zu tun (weil man die fehlerhafte Stelle recht umständlich lokalisieren müßte, wenn der Bootloader der 7360v2 überhaupt ein System direkt in den Speicher laden und ausführen kann).

Auch würde das die Frage nicht klären, warum da bei LAN1 und LAN2 das Auto-Sensing nicht funktionieren will ... denn auch die sollten bei einem FE-Switch automatisch auf 100 MBit/s FD schalten können und wenn man die Box erst einmal in EVA angehalten hat, kann man die Ports in aller Ruhe durchprobieren.

Wenn das tatsächlich nicht funktioniert (und zwar nicht einmal für die 5 Sekunden im Bootloader, wo man das an den LEDs am Switch ja auch sehen sollte), dann hat die Box ja ohnehin ein elektrisches Problem und dann wäre ein davon in Mitleidenschaft gezogener Flash-Speicher auch denkbar.

Das Netzteil wirst Du ja mit der anderen Box schon über Kreuz getestet und damit als Fehlerquelle ausgeschlossen haben, blieben also event. noch die Spannungswandler in der Box - auch wenn die 7360v2 wohl nicht so anfällig ist wie die 7270-Modelle, aber als VR9-Modell braucht sie auch wesentlich mehr Power.

 

[HarryHase]

Habe das gerade noch mal probiert, das ändert nichts und zur Sicherheit habe ich ein Netzteil einer 7490 genommen.

ABER ich habe die Box noch mal anhalten lassen und dann den Port auf 1 umgesteckt. Der Link auf dem Switch geht dann! Also ist da etwas elektrisch etwas, ein Ping auf 192.168.178.1 oder 169.254.1.2 wird nicht beantwortet.

Wenn da eh nicht mehr viel zu retten ist, kann man nicht mtd1 - 4 aus einer anderen Box mal rein braten oder löschen (den bootloader natürlich nicht löschen). Kann man dabei dann nicht sehen wenn es zu schreibfehlern in gewissen Bereichen kommt (dann Kernschrott für mich)

 

[PeterPawn]

Das mit dem Switch mußt Du schon systematisch und nacheinander machen (ping ist zwar auch eine Möglichkeit, aber keines ohne Unterbrechungen), weil die MAC-Adresse der Box auf allen Ports dieselbe ist und so ein Switch ja auch eine Tabelle führt, an welchem Port er welche MAC-Adresse hat. Entweder du startest nach jedem Umstecken den Switch neu (Strom aus/an) und machst erst dann das "ping" oder das Ergebnis ist etwas fragwürdig. Schon gar nicht darfst Du mehrere Ports gleichzeitig an den Switch anschließen, weil auch das (je nach Switch und dessen Firmware) die merkwürdigsten Ergebnisse liefern kann.

Beim Flashen in EVA sieht man m.W. nichts bzw. wenn, würde das von Recovery-Programm ja auch bemerkt. Höchstens noch in der seriellen Konsole könnte etwas stehen, wenn ein Fehler auftritt - da gibt es sicherlich entsprechende Nachrichten im Bootloader.

Ob die Prüfsummen-Kommandos per FTP noch funktionieren, weiß ich für die 7360v2 nicht, aber was soll es bringen, wenn Du MTD1 überschreibst (das ist Kernel+Dateisystem und wird ohnehin bei Recovery gelöscht und anschließend programmiert) oder MTD3/MTD4 (das sind die TFFS-Partitionen und auch die werden bei Recovery mit frischem Inhalt versehen).

Nur MTD2 (das ist EVA selbst) wird nicht bei jeder Recovery-Version neu geschrieben und ich würde auch nicht auf die Idee kommen, da einfach die Partition aus der anderen Box zu schreiben, denn da stehen schon die "Geburtsdaten" der Box drin und die sind individuell.

Du könntest höchstens mal das Recovery-Programm auseinandernehmen (z.B. mit 7-Zip in die .data-Sektion schauen), ob da eine andere Bootloader-Version enthalten ist, diese extrahieren und die Daten aus der derzeitigen Bootloader-Partition dort eintragen. Dann sollte die sich m.W. auch nach MTD2 schreiben lassen, aber ich würde das auch nur im äußersten Notfall machen.

Wenn Du wirklich unbedingt noch testen willst und die Box tatsächlich schon abgeschrieben hast, könnte man mal versuchen, die MTD2-Partition aus dem laufenden FRITZ!OS der zweiten Box heraus zu sichern, die hatte ohnehin die neuere Loader-Version, wenn ich mich richtig an die ersten Ausgaben der Urlader-Variablen erinnere.

Dann könnte man hingehen und in der Binärdatei mit einem Hex-Editor die Variablen im entsprechenden Segment zu ersetzen (das ist an irgendeinem festen Offset, ich müßte auch erst nachlesen, an welchem, irgendwo in der Nähe von 0x800 - nicht mit den "fallback values" für den Notfall verwechseln, die stehen viel weiter hinten) mit den Werten, die aus dem ausgelesenen Environment stammen. Dann könnte man (so es überhaupt funktioniert) versuchen, auch MTD2 über den Bootloader neu zu schreiben. Sollte das vorgesehen sein, müßte sich eigentlich der Loader selbst um seine "relocation" vor dem Löschen der einzelnen "erase lines" kümmern, falls der direkt aus dem "memory mapped" NOR-Flash laufen sollte und nicht ohnehin vorher schon in den Hauptspeicher kopiert wurde.

Aber Du kannst ja auch mal von Hand mittels "eva_store_tffs" versuchen, die Firmware zu flashen (notfalls eine ältere) ... auch wenn der Name etwas anderes suggeriert, kann man mit "eva_store_tffs MTD1 <image-file>" auch eine NOR-Firmware flashen und nicht nur neue TFFS-Partitionen. Auch dabei sieht man sicherlich keine Meldungen über Schreibfehler (das FTP-Protokoll sieht solche detailierten Meldungen einfach nicht vor), aber zumindest sollte man das abschließende "226" sehen, wenn die Übertragung funktioniert haben müßte.

Aber das ist alles zusätzlicher Aufwand (auch Lernaufwand vermutlich) und da wäre der nächste logische Schritt eigentlich die Bestückung der Seriellen, weil man da auch dem Bootloader auf die Finger schauen kann und dann ggf. sogar offensichtliche Fehlermeldungen zum Flash-Speicher sehen sollte (wie die aussehen, sieht man schon im Hexdump des Bootloaders). Wenn da der Flash-Speicher als defekt angezeigt wird (da gibt es vermutlich auch passende Kommandos zum Testen desselben), dann vermutlich auch gleich mit der Angabe, wo der Fehler liegt und dann könnte man sich ein Image bauen, was um den schadhaften Bereich "herumarbeitet".

Aber auch das ist Aufwand ... beim Wiederbeschaffungswert einer 7360v2 mit 32 MB (irgendwas zwischen 60 und 80 EUR) ist mit etwas Pech schon die Ausgabe für die Hardware beim Löten der Pins für die serielle Schnittstelle (falls man auch noch eine Lötstation kaufen muß) der "wirtschaftliche Totalschaden" ... auch wenn die Preise für die v2 vermutlich erst einmal etwas anziehen werden, wenn die jetzt das Update auf 06.50 kriegt und das in die v1 oder die SL nicht hineinpaßt.

 

[HarryHase]

Ich glaube Du hast Recht, zwar habe ich PINS und Lötstation, aber vermutlich werde ich sie ungeöffnet als defekt in ebay vertickern .... Ich lasse mir das noch mal durch den Kopf gehen, bin eh jetzt über das WE weg ...