Änderung im Bootloader der GRX5-Boxen?

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
15,274
Punkte für Reaktionen
1,751
Punkte
113
Kann es sein, daß AVM bei den Bootloadern der GRX5-Modelle (endlich) tatsächlich eine Änderung vorgenommen hat und man dort nur noch an den FTP-Server im Bootloader herankommt, wenn der Grund für den Neustart (der im Speicher abgelegt wird und so einen Neustart auch übersteht) passend erscheint (z.B. "Power-On-Reboot")?`

Das wäre ja eine gute Nachricht, weil dann die bisher (bei anderen Geräten) definitiv vorhandene Möglichkeit des Angriffs auf den Bootloader (über Kabel) nach einem provozierten Neustart (egal ob über GUI-Zugriff oder durch das Ausnutzen von Fehlern i.V.m. einem Watchdog - gesetzt, bei diesem Reboot-Grund bleibt EVA-FTP auch stumm) auch nicht mehr gegeben wäre.

Das ist allerdings eine reine Vermutung auf der Basis des beobachteten Verhaltens bei einer 7580 (bootloaderversion 1.3229) - es kann natürlich genauso gut auch einfach ein Fehler im Bootloader sein, so daß da auf nichts reagiert wird, wenn die Box "nur" neu gestartet wird. "Nichts" meint dann sowohl Broadcasts auf UDP-Port 5035 als auch ICMP-Pakete als auch Verbindungsversuche auf TCP-Port 21.

Wie der Bootloader auf die anderen denkbaren Werte für diesen Eintrag:
Code:
Temperature-Reboot
Power-On-Reboot
Software-Reboot
NMI-Watchdog
Firmware-Update
Software-Watchdog
jeweils reagiert und wann er (sofern das tatsächlich beabsichtigtes Verhalten ist) den FTP-Server anwirft und wann nicht, müßte man genauer untersuchen.

Aber ich will zumindest mal festhalten (die Aufgabe des EVA-Zugriffs stellt sich bei einer Modifikation ja fast zwangsläufig, zumindest bei neuen Geräten), daß es da durchaus Unterschiede geben könnte und man bei Problemen (auch wenn man das sicherlich ohnehin machen würde) mit einem Statuswechsel bei der Stromversorgung auch wieder besser klarkommen könnte.

Vielleicht fühlt sich ja jemand mit einer weiteren GRX5-Box (und einem anderen Bootloader) dazu berufen, das mal zu verifizieren ... es wäre zumindest ein weiteres Puzzle-Teil, ob das tatsächlich absichtlich geschah (was dann die Angriffsfläche auf den Bootloader auf Stromausfälle oder provozierte PoR durch den Besitzer reduzieren würde) oder doch nur ein Fehler ist, der ja auch ganz einfach darauf beruhen könnte, daß eine zweite Initialisierung des Switches im Bootloader (wenn der bereits vom vorher laufenden System konfiguriert war) nicht erfolgreich ist, weil da irgendwo ein Reset zuvor vergessen wurde.

Der ganze Teil mit EVA ist ja von AVM selbstgestrickt (an den Hersteller-Code dran bzw. hinein oder drumherum, wie es gerade paßt und was beim jeweiligen Chip am besten geht - das kann man in den verschiedenen Bootloader schön sehen) und damit auch das Initialisieren des Netzwerks in dieser frühen Phase.

Da wäre also so ein Fehler auch nicht wirklich verwunderlich ... wobei ich dann fast geneigt bin zu wetten, daß es dann für die Produktionstest-Geschichten einen anderen Loader gibt, denn da wäre es sicherlich eher hinderlich, wenn eine Box nach einem "Soft-Reboot" nicht in den FTP-Server kommt (die PTEST-Variable wird ja bei jedem Start auch wieder gelöscht und muß neu gesetzt werden) und dann wäre das - sofern es nicht doch Absicht ist - sicherlich auch schon bemerkt (und behoben) worden.

Diesen "Reboot Status" (der auch noch als Pseudo-File "reboot_status" unter "/proc/sys/urlader" abzurufen ist im laufenden System) gibt es ja jedenfalls schon wesentlich länger als die GRX5-Modelle (auch bei der 7490 existiert entsprechender Code, ebenso bei der 7412 und auch bei Puma6-Modellen) und bisher hat es zumindest immer noch funktioniert, auch bei einer "soft-gestarteten" FRITZ!Box dieser Modellreihen in den Bootloader zu kommen.

Diese 7580 ist also nun mein erstes Gerät, bei dem das so nicht mehr klappt - es fällt auch nicht auf Anhieb auf, weil man ja häufig statt eines Reboots auch einfach den Stecker zieht, wenn man es eilig hat.
 
  • Like
Reaktionen: HarryHase
Das würden meine vielen "Fehlversuche" mit normalen reboots erklären und warum das recovern nicht klappte, bisher war ich nie auf den Netzstecker angewiesen und und da die Box in einem anderem Zimmer steht war ich zu faul ....
Wenn ich aus dem Urlaub zurück bin kann ich das noch mal überprüfen
 
Code:
HWRevision 225
HWSubRevision 1
ProductID   Fritz_Box_HW225
SerialNumber H284
bootloaderVersion   1.3082
ptest

Nach Neustart per GUI kein Zugriff zum Bootloader möglich - nach PoR kein Problem

Vll. hilfts
 
Zuletzt bearbeitet:
  • Like
Reaktionen: HarryHase
Damit ist das zumindest schon mal die zweite Box (und kein Defekt der meinigen) - wobei mir unklar ist, welches Modell das nun ist. Bei einer 7490 ist die HWSubRevision 1 noch Mitte 2016 wohl eher unwahrscheinlich (meine ist von 2015 und schon HWSubRevision 3), die 7580 war Mitte Juli 2017 m.W. noch nicht erschienen und damit bleibt wohl nur die 7560 (ja auch mit GRX5) übrig. Damit wäre das (neben der anderen Bootloader-Version) dann auch noch ein anderes Modell, wenn meine Schlußfolgerung stimmen sollte. Andererseits habe ich irgendwo auch eine 7580 (wohl als Vorab-Exemplar) gesehen, deren Seriennummer mit H27 beginnt - es könnte also auch eine 7580 sein (dann bleibt trotzdem die andere Loader-Version übrig). Wenn das jetzt auch noch bei einem Loader mit einer höheren Versionsnummer (bzw. dem mit der höchsten derzeit bekannten, auch wenn ich nicht weiß, welche das wäre) so sein sollte, dann ist es wohl Absicht.
 
Sorry ist eine 7580 UI (225) ergänzt/geändert
 
Bei anderen Tests habe ich dann noch festgestellt, daß bei meiner 7580 (Loader 1.3229 bzw. 4229) jetzt auch nicht mehr die LAN-Ports im Switch miteinander verbunden sind, solange sie im Bootloader "herumsteht". Damit kann man jetzt auch nicht mehr aus "LAN 4" ausbrechen, indem man die Box (so es denn nach einem Soft-Reset überhaupt gelingt, s.o.) im Bootloader einfach festhält.

Aber auch bei dieser Box ist die Verwendung von LAN1 (oder LAN A) für das Recovery-Programm nur eine "Empfehlung" (die so auch in den Dialogboxen steht) ... das hat problemlos auch über LAN3 und LAN4 funktioniert, WAN habe ich nicht getestet.

Dafür habe ich (nachdem ich lange kein AVM-Recovery-Programm verwendet hatte) festgestellt, daß die "Vorbelegung" für das Durchlöchern der Firewall nur "öffentliche Netzwerke" betrifft. Da mein PC aber die MAC-Adresse der Box bereits als "privates Netz" kannte, wollte das erst einmal nicht funktionieren ... die Antworten der Box (die UDP-Pakete von Port 5035) erreichten einfach das Recovery-Programm nicht (obwohl sie im Wireshark zu sehen waren).

Das ist ohnehin eine Klippe, an der man scheitern kann ... bei der ersten Benutzung des Recovery-Programms (das gilt für jede Version wieder neu) erscheint der Firewall-Dialog ja erst, wenn die erste UDP-Antwort von der startenden Box eintrifft (beobachtet auf W10 - noch 1607, aber das sollte dem Recovery-Programm egal sein). Wenn man da nicht schnell genug ist und den Zugriff gestattet (oder wenn man erst noch die zusätzliche Checkbox für "privates Netzwerk" auch noch auswählen muß, wie ich), dann ist die Zeitspanne des Wartens für den Bootloader auch schon durch und der startet einfach weiter die Box mit dem aktuell installierten System.

Hier sollte man also von Beginn an zwei Versuche einkalkulieren ... beim ersten erlaubt man den Zugriff in den Firewall-Einstellungen und bricht dann das Recovery-Programm ab (was sich bei mir auch weigerte, sich einfach schließen zu lassen und immer wieder auf Adresse 0.0.0.0 weitersuchen wollte) und startet es einfach noch einmal (die Box auch noch einmal stromlos machen). Dann sollte es im zweiten Anlauf reibungslos funktionieren, denn die zusätzliche potentielle Pause entfällt.

Wenn AVM dann auch noch die "abschließende Nachricht" im Recovery-Prozess etwas ändert, wäre das sehr zu begrüßen ... "Die Wiederherstellung des Gerätes ist nach einem Neustart abgeschlossen." kann eben nur allzu leicht auch als Aufforderung aufgefaßt werden, man möge doch nun bitte einen Neustart anstoßen. Das dürfte bei den meisten über das "Steckerziehen" erfolgen und dann unterbricht man im schlechtesten Falle gerade das Schreiben in die UBIFS-Partition ... denn das dauert inzwischen schon etwas, bis nach dem Ende des Recovery-Programms dann auch die Firmware wirklich im Flash gelandet ist und die Box von alleine neu startet. Wer dabei gleich noch die Box wieder an ihren ursprünglichen Standort verbringen will (weil die Verkabelung/der Standort für Recovery geändert wurde), der steht vor einem ähnlichen Dilemma, wenn er nicht lange genug wartet mit dem "Rücktransport".

Außerdem ist mir noch ein Unterschied aufgefallen (das erste Mal, daß ich da wirklich genau hingesehen habe) ... der Bootloader verwendet im FTP-Server unterschiedliche Angaben für "memsize", je nachdem, wie man das abfragt. Ruft man das komplette Environment über "RETR env" ab, stehen dort 128 MB drin (0x08000000) und fragt man den Wert einzeln mit "GETENV" ab, sind es die tatsächlich installierten 512 MB (0x20000000). Damit ist dann auch geklärt, warum/wie das Recovery-Programm nur 128 MB beim Laden des Images ins RAM verwendet - das berechnet die Daten ja anhand der geladenen Datei (aus der auch gleich noch das TFFS-Image fürs Zurücksetzen der Einstellungen generiert wird) und dort sind es eben nur 128 MB. Das muß man halt berücksichtigen/wissen, falls man doch mal selbst am "memsize" herumfummelt - der Wert wird ja beim Booten ohnehin jedesmal neu gesetzt.

Aber auch das vom Recovery-Programm erzeugte TFFS-Image enthält eben nur diese 128 MB in "memsize" ... wenn man sich da ein eigenes baut, muß man sich ggf. entscheiden (falls das mit 512 MB nicht funktionieren sollte). Beim Schreiben über den Bootloader wird ja (anders als bei der Speicherung) auch bei NAND-Flash dasselbe Format verwendet - es wird halt nur ein einziges Mal nach "mtdnand" geschrieben und nicht in zwei (SPI-)Partitionen, wie bei den VR9-Geräten mit NAND und SPI. Ich kann mich auch noch an irgendeinen Thread erinnern, wo schon Zweifel bzgl. des tatsächlich installierten Speichers aufkamen, weil da eben auch nur die 128 MB sichtbar waren in einem Mitschnitt.

Gleichzeitig habe ich ziemliche Probleme, diese 7580 von einer neueren Version (da hatte ich leichtsinnigerweise auch mal aus Interesse das Mesh-Labor installiert) wieder auf die 06.54 zu bringen oder auch von der 06.83 auf die 06.54. Da fällt mir - reproduzierbar - der vorhandene TFFS-Inhalt aus in der älteren Version bzw. nach Start einer 06.83 (zuvor mit Recovery in die andere Partition installiert) mit dem Schreiben neuer Einstellungen ins TFFS, startet die 06.54 erst mal gar nicht mehr.

Den Symptomen nach würde ich da auf eine Änderung am TFFS-Code durch AVM tippen (so daß die 06.54 mit neueren Strukturen nicht mehr klarkommt und dann Panik kriegt und rebootet) ... aber das muß ich mir erst noch einmal in den Quellen ansehen. Es könnte aber eben auch sein, daß bei der 7580 (dann sicherlich bei allen GRX5-Modellen) ein "Rückschritt" über eine bestimmte Version hinaus tatsächlich nach dem Löschen des TFFS schreit (wie es beim Recovery ja auch automatisch geschieht) - das braucht noch weitere Tests.
 
Code:
HWRevision 225
HWSubRevision 1
ProductID   Fritz_Box_HW225
SerialNumber H284
bootloaderVersion   1.3082
ptest

Nach Neustart per GUI kein Zugriff zum Bootloader möglich - nach PoR kein Problem

Vll. hilfts
Wie liest du diese Info aus? Support data?
 

Anhänge

  • photostudio_1503084001169.jpg
    photostudio_1503084001169.jpg
    153.2 KB · Aufrufe: 27
Versuch doch mal nach einem Neustart per GUI per eva/adam in den FTP zu kommen.

Nach stromlos funktioniert es immer
 
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.