Bootloop nach DSL-Assistent Kalibrierung

DD2MIC

Neuer User
Mitglied seit
3 Mrz 2014
Beiträge
15
Punkte für Reaktionen
0
Punkte
1
Moin.
Gestern ist meine DSL Verbindung einer schwarzen 7390 ausgegangen (es war kein Gewitter, aber es könnte ein Problem bei der Telekom sein. Das habe ich noch nicht adressiert) und daraufhin wurde der interne "assistent" empfohlen.
Der lief durch und verwies dann auf einen internen DSL-Prüf-Assistenten.
Dieser sagte mit: DSL Kabel abziehen, dann "kalibrieren" klicken
Und dieses "kalibrieren" dauerte dann die ganze Nacht durch (ohwohl da laut oberfläche stand es dauert 1 Minute) und am nächsten Tag war es immer noch da. Also aufgescheinlich "eingefrohren" die ganze Sache.
Was macht man also. Reset. Ist ja eigentlich nur eine Funktion der Box und dann sollte die doch normal wiederkommen. Dem war aber nicht so.

Nun hängt sie in einem Boot-Loop. Reset (als LEDs blinken 1x) -> 4x blinken Power LED (das 4.mal etwas länger) -> 8x blinken Power LED -> Reset
Mit dem Recovery Tool (FRITZ.Box_Fon_WLAN_7390.AnnexB.06.88.exe) kommt man durch. Es werden alle Sachen neu geflasht. -> behebt aber den Fehler nicht.
Wenn man per Telnet auf Port 21 drauf geht, kann man sich per ADAM2 einloggen.

Soweit ich bislang gelernt und verstanden habe sieht das dort auch gut aus. Jedoch ist GETENV annex ein A und GETENV kernel_args ein annex=B
HWversion ist 156 und firmware_version ist avm
 
Ich vermute, dass die Box defekt ist.
 
Ich vermute, dass die Box defekt ist.
Ich komme auch immer mehr zu der Erkenntnis, aber könntest Du (oder gerne auch jemand anderes) Deine Vermutung noch etwas "untermauern".
Gibt es zB. eine "Bedeutung" hinter den Blink-Codes der 7390? 4x und dann 8x?

Das "Kalibrieren" über die Weboberfläche wird wohl hier beschrieben (nur das man weiß, was ich gemacht habe)
Genau den unter Punkt 5 beschriebenen DSL-Leitungstest wollte ich machen, aber im "Kalibrieren" ist es hängen geblieben und dann war alles eingefroren.

Und so ganz defekt kann sie ja nicht sein, aber es könnte natürlich der DSL Teil defekt sein. Da gibt es ja Hardwarelösungen um den zu "deaktivieren".
Dann hätte ich hier 2 Stück 7390er, die man noch mit den (W)LAN Funktionen und als VoiP Client nutzen könnte. (Die schwarze mit dem hier beschriebenen Fehler und eine rote, die nach Überspannung nur noch "surrt")

Ich hab auch schon in eBay neue geordert. für 1-5€ pro Stück. Eine schwarze 5140, eine rote 7050, eine weitere rote 7390, die laut Bild aber keinen interen S0 hat (das war vielleicht ein Fehlkauf...)
Ich brauche das Ding eben, damit ich am T-DSL meine VoIP Konten einfangen und dann via S0 an die HiPath weitergeben kann.

Der Internetzugang geht über FTTH mit einen Mikrotik Router.
Im Moment geht also "nur" das "Festnetztelefon" nicht.

Um einfach über die FBoxen an sich und den Bootloader noch was zu lernen war das hier ganz hilfreich
und gibt es eine Liste der "Variablen", die man mit GETENV anschauen kann?

Hier ist was https://openwrt.org/docs/techref/bootloader/eva
PRINTENV soll gehen, aber das geht bei mir nicht.

Also jede einzeln mit GETENV abfragen:
HWRevision 156
HWSubRevision 3
ProductID Fritz_Box_7390
SerialNumber 0000000000000000
annex A
autoload yes
bootloaderVersion 1.1757
bootserport tty0
country <--- gibt es nicht !!!
cpufrequency 500000000
firstfreeaddress 0x810D5A54
firmware_info 84.06.88
firmware_version avm
flashsize 0x1000000
language <--- gibt es nicht !!!
linux_fs_start<--- gibt es nicht !!!
maca 08:96:D7:4C:BE:90
macb 08:96:D7:4C:BE:91
macwlan 08:96:D7:4C:BE:92
macwlan2 08:96:D7:4C:BE:93
macdsl 08:96:D7:4C:BE:94
memsize 0x08000000
modetty0 38400,n,8,1,hw
modetty1 38400,n,8,1,hw
mtd0 0x9F000000,0x9F000000
mtd1 0x9F020000,0x9FF00000
mtd2 0x9FF00000,0x9FF80000
mtd3 0x9FF00000,0x9FF80000
mtd4 0x9FF80000,0xA0000000
mtd5 <--- gibt es nicht !!!
my_ipaddress 192.168.178.1
prompt Eva_AVM
req_fullrate_freq 166666666
sysfrequency 166666666
tr069_passphrase <-- kann man auslesen. Sollte man die veröffentlichen?
tr069_serial 00040E-0896D74CBE90
urlader-version 2757
usb_board_mac 08:96:D7:4C:BE:95
usb_device_id 0x0000
usb_device_name USB DSL Device
usb_manufacturer_name AVM
usb_revision_id 0x0000
usb_rndis_mac 08:96:D7:4C:BE:96
wlan_key <-- kann man auslesen. Sollte man aber wohl nicht veröffentlichen? Ist wahrscheinlich der "Werkskey", der hinten drauf steht?

Ich hab ja irgendwie noch die Hoffnung, das dem Kernel beim hochfahren irgendwie gesagt wird, er solle diese "Kalibrationsroutine" immer wieder starten, aber das könnte Ihm vom Bootloader ja nur über die "kernel_args" gesagt werden und da steht eben nix davon drin.

Oder gibt es noch eine Bootloadervariable, die dem Kernel diese Parameter mitteilt, die während der Kalibrierung ermittelt werden? Dann könnte man da ev. irgendwie "Standarfparameter" reinschreiben?
Die obige Liste muss ja nicht zwingend vollständig sein ;-)
 
Zuletzt bearbeitet:
Wurde schon einmal ein anderes Netzteil genommen? Manchmal kann auch das dafür verantwortlich sein, dass die Box sich komisch verhält.
 
PRINTENV soll gehen, aber das geht bei mir nicht.
Es gibt einen Unterschied zwischen der seriellen Schnittstelle (die man erst noch mit einem passenden Wandler bestücken muß) und dem (rudimentären) FTP-Server im AVM-Bootloader und der heißt auch schon seit längerem nicht mehr ADAM2 (das war mal das Original von Texas Instruments), sondern EVA und so meldet er sich ja auch beim FTP-Zugriff, selbst wenn für die "Zugangsdaten" noch die TI-Werte verwendet werden.

Das Äquivalent zum printenv wäre im FTP-Dialog ein (nur passiv mögliches) RETR env - dann hat man (in einem Zug) auch eine vollständige Ausgabe.

Ansonsten bist Du in diesem Unterforum (so, wie sich das entwickelt in diesem Thread) auch eher falsch - deutlich mehr Infos fändest Du (nach meiner Ansicht) unterhalb von "Modifikationen".
 
Wie ist denn die Artikel-Nummer der Box?
Steht da leider nicht drauf :-(
Bitte die Bilder im Anhang anschauen.
Oben auf dem schwarzen Gehäuse stand mal "Sunrise"
So etwas gibt es nicht.
eben eBay. Entweder war das Bild falsch, oder die Beschreibung... naja, 20€...

[Edit Novize: Beiträge zusammengeführt - siehe Forumsregeln]

Das Äquivalent zum printenv wäre im FTP-Dialog ein (nur passiv mögliches) RETR env - dann hat man (in einem Zug) auch eine vollständige Ausgabe.
Geht auch nicht wirklich, aber ist ja auch nicht mehr wichtig ;-)

GETENV annex
annex A

200 GETENV command successful

RETR env
551 unknown Mediatype

PASV
227 Entering Passive Mode (192,168,178,1,36,177)

RETR env
551 unknown Mediatype

Ansonsten bist Du in diesem Unterforum (so, wie sich das entwickelt in diesem Thread) auch eher falsch - deutlich mehr Infos fändest Du (nach meiner Ansicht) unterhalb von "Modifikationen".
Ich kann da gerne lesen und ggf. auch posten; Danke für den Hinweis. (kenne das Forum ja noch nicht so gut)
Aber im Grunde will ich ja gar nix modifizieren. Die Box hat mir den "original Funktionen" ja alles gemacht, was sie sollte. Nun ist sie eben defekt und hängt im bootloop. Daher hatte ich es hier versucht.

[Edit Novize: Beiträge zusammengeführt - siehe Forumsregeln]

Wurde schon einmal ein anderes Netzteil genommen? Manchmal kann auch das dafür verantwortlich sein, dass die Box sich komisch verhält.
Ja, kurzzeitig. Zeigte den gleichen Bootloop.
und jetzt ist sie seit über 20h stabil im "EVA-Modus"
 

Anhänge

  • IMG_0594.jpg
    IMG_0594.jpg
    56 KB · Aufrufe: 47
  • IMG_0595.jpg
    IMG_0595.jpg
    53.4 KB · Aufrufe: 47
Zuletzt bearbeitet von einem Moderator:
Geht auch nicht wirklich
Geht schon ... man muß es halt nur richtig machen. Wie so ein (korrekt ablaufender) FTP-Dialog aussehen sollte, ist hier (mehrfach) in diversen Beiträgen nachzulesen und notfalls versucht man das eben nicht "zu Fuß" (wenn man sich nicht wirklich auskennt), sondern nutzt entsprechende Tools, z.B. dieses: https://github.com/PeterPawn/YourFritz/blob/main/eva_tools/eva_get_environment

aber ist ja auch nicht mehr wichtig
Na dann ist's ja gut ... merke ich mir für's nächste Mal. :mad:

Ich hatte bisher halt verstanden, daß Du gerne das KOMPLETTE Environment auslesen wolltest, um damit sicherzustellen, daß bei der "Kalibrierung" keine Werte gesetzt wurden, die jetzt den korrekten Start der Box verhindern.

Der Widerspruch hinsichtlich des Annex-Wertes ist Dir ja offensichtlich selbst aufgefallen ... irgendwo findest Du dann bestimmt auch noch einen Beitrag, in dem beschrieben ist, was am Ende der resultierende(!) Wert bei dieser Konstellation im Environment ist. Ich bin mir sicher, das hier auch irgendwo beschrieben zu haben, bevor seitens AVM dann alle Versionen (sowohl beim Branding als auch bei den DSL-Versionen) praktisch zusammengefaßt wurden, was ohnehin nur für spätere Modelle als eine 7390 funktioniert, denn die hat per se schon zu wenig Platz im Flash-Speicher, um eine "All-in-one"-Version für dieses Modell zu erstellen.
 
"Sunrise" war lt. Wikipedia bis 2021 ein Schweizer Telekommunikationsunternehmen. Die Recovery muß also die aus "Other" sein.

Möglw. wurde die Box bereits ihrer Heimat-Einstellungen (u.a. dem Annex) beraubt, für D umgeflasht und leider vergessen, den Annex auch tief drin umzustellen.

Mit Glück beinhaltet die "Other"-Recovery beide Annex-Versionen; leider bin ich da nicht so firm :( .
 
  • Like
Reaktionen: totalverrückteruser
"Sunrise" war lt. Wikipedia bis 2021 ein Schweizer Telekommunikationsunternehmen.
Das ist Sunrise immer noch. Nur heisst sie jetzt Sunrise GmbH und nicht mehr Sunrise Communications AG, von deren Wikipedia-Eintrag du deinen Text kopiert (und verfälscht) hast.

In der Schweiz gibts Annex A und Annex B. Bei den Downloads von AVM sehe ich aber nur ein Recovery für Annex B.


Bildschirmfoto 2023-10-23 um 23.46.29.jpg
 
AVM hat irgendwann begonnen, die (als gesonderte Datei im Image vorliegende) DSL-Firmware 1x für Annex B in die Firmware zu packen und zusätzlich noch Dateien, mit denen aus der B-Version (durch binäres Patchen mittels bspatch) die A-Firmware erzeugt werden kann, die dann stattdessen geladen wird beim DSL-Start. Es werden also tatsächlich (iirc auch in der deutschen Firmware der 7390) beide Versionen unterstützt - nur wurde in der deutschen Version der GUI-Teil für die Umstellung ausgeblendet (https://github.com/PeterPawn/modfs/blob/master/modscripts/mod_multi_annex).
 
Hallo und ja:
- Wenn in EVA die Variable "firmware_info" auf "avme" steht, dann läuft FRITZ.Box_Fon_WLAN_7390.AnnexB.en-de-es-it-fr.06.88.exe sauber durch.
(das war der "Anfangszustand" der Box)
- Wenn in EVA die Variable "firmware_info" auf "avm" steht, dann läuft FRITZ.Box_Fon_WLAN_7390.AnnexB.06.88.exe sauber durch.

behebt aber beides den Fehler nicht.
(Kann wahrscheinlich so oft "hin und her recovern" wie man möchte. Ich hatte beides probiert.)

INFO:
In der Variable "kernel_args" steht "annex=B", aber auch wenn man hier "annex=A" setzt bringt das keine erkennbare Änderung am Verhalten.
An einem Telekom-DSL Anschluss (DSL2000, schneller ist es hier auf dem Land nicht) braucht man aber Annex B, richtig?

-- Zusammenführung Doppelpost gemäß Boardregeln by stoney

Geht schon ... man muß es halt nur richtig machen. Wie so ein (korrekt ablaufender) FTP-Dialog aussehen sollte, ist hier (mehrfach) in diversen Beiträgen nachzulesen und notfalls versucht man das eben nicht "zu Fuß" (wenn man sich nicht wirklich auskennt), sondern nutzt entsprechende Tools, z.B. dieses: https://github.com/PeterPawn/YourFritz/blob/main/eva_tools/eva_get_environment
Ein sehr gut geschriebenes Script für netcat. Hab nur leider kein Linux System hier, auf dem ich es laufen lassen könnte.
Ich kann mit PuTTY im Modus Telnet auf Port 21 gehen, oder ich kann Filezilla nehmen und über "server -> Benutzerdefinierten Befehl eingeben"
Damit kann sich dann aber wohl keine data-connection aufbauen.

Als "zu Fuß"-Methode:
- in EVA einloggen.
- TYPE I schaltet auf BINARY
- und da das Argument für MEDIA aus einer Variabeln erzeugt wird ist das eben direkt nicht zu erkennen. Da endet der "Fußweg"

Ich hatte bisher halt verstanden, daß Du gerne das KOMPLETTE Environment auslesen wolltest, um damit sicherzustellen, daß bei der "Kalibrierung" keine Werte gesetzt wurden, die jetzt den korrekten Start der Box verhindern.
Das war meine Idee/Hoffnunf bislang. Ist sie zielführend?
 
Zuletzt bearbeitet von einem Moderator:
das Argument für MEDIA aus einer Variabeln erzeugt wird
Sofern das Argument fehlt, wird halt MEDIA SDRAM befohlen: https://github.com/PeterPawn/YourFr...fbd2f63e215/eva_tools/eva_get_environment#L15

EDIT: Einzige mir bekannte Alternative wäre MEDIA FLSH, was aber nur beim Schreiben in den Flash benutzt wird. Außerdem kann man sich den kompletten Ablauf eines FTP-Dialogs auch in der ftp.log des AVM-Programms ansehen (https://www.ip-phone-forum.de/threads/wie-recovere-ich-eigentlich-richtig.299790/).

Und dann sollte auch jeder FTP-Client, der sich auf passive Verbindungen versteht (der von Windows gehört NICHT dazu), in der Lage sein, diese Datei komplett auszulesen - nur die Umschaltung auf den Passiv-Mode (sofern der nicht standardmäßig aktiv ist) nicht vergessen, damit das passende Kommando (nämlich PASV bzw. P@SV) an den Server gesendet wird.

Ist sie zielführend?
Das kann (und will) ich nicht beurteilen. Ich glaube nicht so richtig daran, daß da irgendwelche "Variablenreste" die Ursache sind ... allerdings würde ich tatsächlich zunächst mal probieren, den zusätzlichen Eintrag in kernel_args (oder wo auch immer der sich bei Dir befindet) zu entfernen (denn der löst beim DSL-Start eine abweichende Verarbeitung aus - siehe /etc/init.d/E40-irgendwas) und dann schauen, ob die Box damit wieder "stabil" startet. Danach kann man sich dann immer noch dran machen, die Box (erneut) passend einzustellen für den geplanten Verwendungszweck.

Wenn die tatsächlich an einem DSL2000-Anschluß (vermutlich ja noch als ADSL-Modem) laufen soll, wäre eine 7390 ohnehin nicht die beste Wahl - da sind noch ältere Modelle (z.B. 7270v3) fast die bessere Lösung, wobei deren FRITZ!OS natürlich auch nicht mehr so ganz taufrisch wäre.
 
BTW:
Wenn die tatsächlich an einem DSL2000-Anschluß (vermutlich ja noch als ADSL-Modem) laufen soll, wäre eine 7390 ohnehin nicht die beste Wahl - da sind noch ältere Modelle (z.B. 7270v3) fast die bessere Lösung,
Neuere Modelle wären in diesem Fall (ADSL1/2+-Anschluss) auch schon eine bessere Wahl als die 7390, bspw. 7272, 7360v2, 7362 SL, 7412, 7490, 7560, 7580. Nur zu neu sollten sie nicht sein (also nicht 7520, 7530, 7590 usw. also keine VRX518/619-Modelle). Eine 7390 würde ich an einem DSL2000-Anschluss jedenfalls nur sehr ungern verwenden…
 
Das kann (und will) ich nicht beurteilen. Ich glaube nicht so richtig daran, daß da irgendwelche "Variablenreste" die Ursache sind ... allerdings würde ich tatsächlich zunächst mal probieren, den zusätzlichen Eintrag in kernel_args (oder wo auch immer der sich bei Dir befindet) zu entfernen (denn der löst beim DSL-Start eine abweichende Verarbeitung aus - siehe /etc/init.d/E40-irgendwas) und dann schauen, ob die Box damit wieder "stabil" startet. Danach kann man sich dann immer noch dran machen, die Box (erneut) passend einzustellen für den geplanten Verwendungszweck.

Also mit UNSETENV kernel_args mal die Variable geleert. Bleibt im Bootloop.

Dann mit:
SETENV kernel_args
200 SETENV command successful
GETENV kernel_args
kernel_args
200 GETENV command successful

Die Variabel als "leer" angelegt. Bliebt im Bootloop

-- Zusammenführung Doppelpost by stoney

Ich brauche einen internen S0 Bus
 
Zuletzt bearbeitet von einem Moderator:
Kein Problem, dann nimmst du von den aufgelisteten Modellen eben eine mit S0-Bus. Also 7272, 7490 oder 7580. Aber eben nicht die 7390 (und auch nicht die 7590).
 
Dann ist die 7390 wohl tatsächlich (zumindest teilweise) defekt ... der beschriebene Bootvorgang deutet ja darauf hin, daß zumindest das System noch einigermaßen startet, dann aber beim Initialisieren irgendeiner (unbekannten) Komponente stirbt - vermutlich mit einer "kernel panic".

Will man das jetzt noch genauer untersuchen, muß man entweder die serielle Schnittstelle bestücken und sich die Ausgaben dort ansehen oder man erstellt sich ein eigenes Firmware-Image, welches man aus dem RAM startet (das kann die 7390 tatsächlich auch) und in dem man sich das TFFS irgendwohin ausgeben läßt (z.B. per TFTP, das kann auch das AVM-System aus dem Stand und es wird bei AVM auch im Rahmen der Finalisierung verwendet für die Protokollierung - zumindest bei neueren Modellen, aber das Prinzip funktioniert eben auch schon auf der 7390), denn darin ließe sich mit einiger Wahrscheinlichkeit das "panic log" finden, welches AVM auch in so einem Fall über eine spezielle Routine noch ins TFFS schreiben läßt. Üblicherweise kann man das dann beim nächsten Start auslesen - nur kommt man hier ja wahrscheinlich (mit dem regulären OS) nicht mehr so weit.
 
  • Like
Reaktionen: DD2MIC
So, heute kam "neues Material" von eBay.
Eine FBF 7050 mit arcor Branding, wie sich dann herausstellte (Siehe dazu https://www.ip-phone-forum.de/threa...-debranding-von-arcor-avm.131961/post-2532208) und eine rote 7390 mit "Einstellungen" des Vorbesitzers. Also IP unbekannt, WLAN key auch... Also einemal mit "FRITZ.Box_Fon_WLAN_7390.AnnexB.06.88.exe" dran und das lief durch wie geschmiert.

Jetzt tut die wieder ihren Dienst und alles Funktioniert. Die HiPath sieht wieder ein "ISDN Amt".

Für die 2 alten 7390er suche ich mir demnächst mal eine Hardwaremodifikation, die den DSL Teil komplett tot legt und dann können die vieleicht noch im WLAN was sinnvolles tun.

Allen Forenmitgliedern vielen Dank für die Hilfe bei meinem Problem!!!
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.