FB 6591 verschiedenes

fesc · 5 Sep 2019

Zur Updateprozedur:

Das update image besteht im wesentlichen aus einer uimg Datei, ~~welche in der AVM_UPD_TMP partition abgelegt wird~~. Sie enthaelt filesystem/kernel fuer je Atom/ARM ~~und wird beim reboot von UEFI installiert (also nicht mehr aus dem laufenden OS).~~

Ich weiss nicht ob das ein bekanntes Format ist, ich habe in meinem repository (src/uimg) ein kleines tool zum extrahieren abgelegt. Zum wieder Zusammenbauen muss ich es noch erweitern, aber fuers reinschauen reichts.

Edit:
Oben stand mal wieder Mist. Der update via update partition ist zwar vorgesehen, aber nicht implementiert. Stattdessen wird das tool /bin/burnuimg direkt von cgi-bin/firmwarecfg aufgerufen.
Das uimg tool taugt jetzt auch zum re-gernerieren eines uimg files.

sockd · 25 Sep 2019

Bei einer 6591 Vodafone Box (2000 2858) mit FRTIZ!OS 7.03 gibt es (oh Wunder) in der Weboberfläche keinen Menüpunkt für ein Firmwareupdate.
Und über Adam2 kann scheinbar nichts mehr geändert werden. Alles wird entweder gar nicht erst geändert oder ist spätestens nach Reboot wieder zurück gesetzt.

fesc · 28 Sep 2019

Demnächst gibts eine Anleitung wie man nach Anlöten der seriellen Schnittstelle sich einloggen bzw. die FritzBox 6591 "wie ueblich" modifizieren kann. Für heute ist es zu spät.
Aber wie gesagt, ums loeten kommt man (noch?) nicht herum.

fesc · 28 Sep 2019

Hier eine Beschreibung wie man per serieller Schnittstelle Zugriff auf die FritzBox-6591 bekommt.

Das ganze setzt voraus daß man etwas mit Hardware/Lötkolben/Linux umgehen kann, wer sich das nicht zutraut, Finger weg!
Es versteht sich dass man das nicht mit Provider-/Mietboxen machen sollte!
Disclaimer: Keine Garantie für dass ich mich nicht irgendwo vertippt habe! Man sollte prinzipiell verstehen was man hier tut.
Wer das hier liest, bitte auf das Datum des letzten updates achten. Ich werde das nicht bis in alle Ewigkeit maintainen.
Die Prozedur funktioniert unter Umständen NICHT für gebrandete Providerboxen (firmware_version != avm). Siehe Sektion bzgl. branding am Ende.

Die 6591 hat zwei RS232 Konsolen (4-pin through-holes), eine für den Atom, eine für den ARM core. Im Prinzip können beide verwendet werden um sich einzuloggen bzw. eine firmware-Modifikation vorzunehmen. Aber:

Über die Atom-Konsole kann man sowohl ein Update als auch Recovery durchführen, sollte man sich die Box "gebrickt" haben. Es ist also die zu bevorzugende Variante.
Die Atom-Konsole wird mit 1.8V betrieben, d.h. man benötigt einen RS232 Adapter der das kann (siehe thread weiter unten), oder man muss für die üblichen USB Adapter noch einen Pegelwandler dazwischenschalten.
Hier tut es ein ganz einfaches Platinchen mit Transistorschaltung, gibts bei Ebay, maker shops etc (ja, auch ein "3.3V auf 5V" Modell sollte gehen, zumindest tut es das bei mir).
Die ARM Konsole läuft mit 3.3V. Hiermit kann man eigentlich "nur" eine modifizierte Firmware einspielen (bei mindestens einer FW-Version hat auch das nicht funktioniert, s.u.).

Update: Es sieht so aus als ob die Prozedur mit Boxen neueren Produktionsdatums so nicht mehr funktioniert. Folgende Versionsausgabe in den Supportdaten scheint ein solches Modell zu identifizieren:

Code:

DMI: Intel Corporation PUMA 7 C0 PLATFORM/TBD, BIOS CGM2.86C.627075.R.1910091149 10/09/2019

Bei solchen Boxen geht das Update wie gehabt über ftp im bootloader. Details hier

Prozedur

Gehäuse möglichst zerstörungsfrei öffnen. Die Position der Laschen erkennt man in etwa am Bild oben (je 3 links. rechts, unten).
ARM und/oder Atom Konsole anbringen (Pin header anlöten oder, wenn möglich, Verbindung temporär irgendwie anklemmen). Auf dem Bild oben:
1. Atom Konsole: oben (am silbernen shield), Belegung von links nach rechts: 1.8V (eckig), Rx, Tx, GND.
  1. Bei einem passenden 1.8V Adapter nur Rx, Tx, GND anschliessen.
  2. Für einen Pegelwandler muss V/GND der "Low" Seite an 1.8V/GND des Steckers angebunden werden, entsprechend die "High" Seite an 3.3V/GND des RS232 Adapters.
    Am besten nochmal nachmessen.
2. (Optional) ARM Konsole in der Mitte, Belegung andersherum: GND, Tx, Rx, 3.3V (Eckig). Hier nur GND/Rx/Tx anschließen.
Terminal-Programm öffnen, mit 115200/8/n/1 ohne flow control verbinden.
Box einschalten und sich wie üblich nach ein paar Sekunden an der EVA Konsole per ftp anmelden:

ftp 192.168.178.1
Folgende Kommandos:

quote SETENV kernel_args mute=0
quote REBOOT

Die mute=0 Einstellung bleibt prinzipiell persistent.
Je nachdem welche Konsole man verbunden hat sollten nach einiger Zeit Ausgaben kommen (u.A. vom kernel), am Ende return drücken und man hat eine shell.
Das wird natürlich erst einmal nicht klappen, weil man (RS232-Gesetz!) Rx und Tx vertauscht hat, also umdrehen und noch einmal versuchen.

Hat man Zugriff auf die Shell kann man ein modifiziertes Atom rootfilesystem einspielen, z.B. mit Netzwerklogin.
Ich haben meine Toolchain (https://bitbucket.org/fesc2000/ffritz/src/6591/) bereits auf die 6591 angepasst, so dass man sich ein solches modifiziertes Image generieren kann (wer nur die Konsole zum einloggen verwenden will kann natürlich auch das original Image nehmen).
Zum Bauen:

Code:

git clone --branch 6591 https://bitbucket.org/fesc2000/ffritz
cd ffritz
make

Wer Optionen anpassen will (z.B. eine andere Firmware version) der kopiere vor dem make Kommando die Datei conf.mk.dfl nach conf.mk und editiere letztere. Siehe auch den Kommentar am Ende dieses Textes bzgl. branding.

Installation

Die Methode von der Atom-Konsole ist im Prinzip im README.md beschrieben. Für die ARM Konsole muss man die unten beschriebenen Kommandos mittels

rpc sh -c "kommandos"

ausführen. Ich empfehle das nicht, denn es funktioniert wohl nicht zuverlässig und wenn etwas schief geht benötigt man eh die Atom Konsole.

Das update-image (hier z.B. release23/fb6591_7.12-23.tar) in das NAS Verzeichnis auf der box kopieren.
Entpacken:

cd /var/media/ftp; tar xf fb6591_7.12-23.tar
Update installieren (dauert ca. 20sek):

/sbin/burnuimg /var/media/ftp/var/firmware-update.uimg || echo FAILED
Wenn erfolgreich, bootbank switch und reboot:

/bin/aicmd pumaglued uimg switchandreboot
Nach dem reboot sollte fuer einige Zeit ein telnet daemon laufen. Einloggen, ssh login credentials vergeben (passwd oder pubkey nach /.ssh/authorized_keys), sichern (nvsync), fertig.
Der telnet service wird nach ein paar Minuten terminiert.

Den bootbank-switch kann man auch wie üblich in der EVA ftp console mittels "quote SETENV linux_fs_start 0|1" (gefolgt von "quote REBOOT" !) durchführen. Wenn eine bank gar nicht bootet wird auch ein automatischer switch durchgeführt.

Recovery
Sollte man sich beide Bootbänke so zerstört haben so dass kein Linux mehr bootet hilft nur noch die Atom-Konsole.

Die Datei var/firmware-update.uimg im release-tarball auf einen USB stick kopieren.
USB Stick an die FritzBox anschliessen.
Box einschalten. Um in die EFI-Shell zu gelangen muss man
1. auf der Konsole "exit" eingeben während der EVA ftp server läuft (nach der Ausgabe von "EvaHack ready"),
2. unmittelbar gefolgt von ein paar mal Escape-Taste.
"map" eingeben. Hier werden die device mappings aufgelistet. Der USB stick sollte etwa so erscheinen:

FS2: Alias(s):HD36c0b:;BLK22:
PciRoot(0x0)/Pci(0x14,0x0)/USB(0x2,0x0)/HD(1,MBR,0x0047BD56,0x40,0x7807C0)
Das image in den Speicher laden (FS2: ggf. ändern wie in Schritt 4 gelistet):

load2mem -f FS2:\firmware-update.uimg

.. und sich die angegebene Adresse kopieren.
Üblicherweise möchte man das aktuelle boot Image beibehalten und auf das backup Image schreiben. Dazu die bootbank umschalten:

aid toggle
aid update
Jetzt das Image programmieren (Adresse aus schritt 5):

update -a A -s 0x513A010
Bei Erfolg ("Congrats! Looks like everything went as planned! Your flash has been updated! Have a good day!") rebooten:

reset

Die Box sollte jetzt mit dem neuen Image starten.

Gebrandete Boxen
Diese starten nicht mit der firmware für retail boxen, was in der Grundeinstellung auch für das von mir gebaute image gilt!

Wer eine eigene box (also keine gemietete!) hat und es trotzdem probieren will, der kopiere vor dem "make" (um ein modifiziertes image zu bauen) den patch "user-oem.patch" sowohl in das "atom" als auch in das "arm" Verzeichnis. Damit ignoriert die box beim starten die "firmware_version" Einstellung und geht von "avm" aus.

Wichtig:

Damit ist nicht das branding entfernt, und einige Features werden nicht funktionieren (insbesondere auto-update).
Ob das bei zukünftigen firmware-versionen so funktioniert kann ich nicht sagen/testen. Was ein Grund ist warum der patch per default nicht "aktiviert" ist.

------------------------

Edit: Vergessen, VIELEN Dank an @Flole für die wertvolle Unterstützung!
Edit2: Pegelwander, RS232 Vcc sollte 3.3V sein.
Edit3: EFI shell: Atom statt ARM Konsole
Edit4: Recovery Sektion
Edit5: Hinweis zu Providerboxen
Edit6: Ein paar Schönheitskorrekturen.
Edit7: Installationskommandos für ARM Konsole entfernt.
Edit8: Update zu neuen modellen
Edit9: Update bzgl. branding
Edit 10: Link auf README bzgl. update-prozedur bei neuerem BIOS

sockd · 29 Sep 2019

Vielen Dank für deinen Support, fesc!

Bei einer 7.03 Vodafone Box geht scheinbar das "rpc" Kommando nicht auf der ARM-Konsole.
Bin auf der ARM-Konsole komplett verbunden und sehe alles, bei jeglichem "rpc sh -c …" Kommando passiert aber - nix - ausser dass der Cursor in die nächste Zeile springt...
Evtl. funktioniert das rpc Kommando erst ab der 7.04 final oder 7.08 beta?

Meinen Spannungswandler für die ATOM-Konsole bekomme ich erst in den nächsten Tagen... dann werde ich mit der 7.04 und 7.08 noch mal testen wenn ich die drauf habe...

fesc · 29 Sep 2019

Theoretisch könntest du noch schauen ob vielleicht nur die Ausgabe nicht kommt .. wenn das kommando ausgeführt wurde sollte das entpackte tar image auf dem NAS sichtbar sein (var). Dann geht evtl auch das update kommando.

Wie gesagt, ein nicht funktionierendes rpc gabe es auch schon einmal bei einer aelteren 6490 7.x firmware.

sockd · 29 Sep 2019

Ähnliches hatte ich auch vermutet... Aber var existiert nicht, selbst ein einfaches

Code:

rpc sh -c "ls /var/media/ftp/"

kommt auch nach 10 Minuten nicht zurück bzw, es kommt keine Regung...
Nur bei CTRL+C hast du wieder den Prompt... wo man auch alles machen kann... nur rpc sh -c passiert halt nüschts...

ice012345 · 30 Sep 2019

Danke für Arbeit und Mühe @fesc

Hab soweit alles wie beschrieben getan aber Fritzbox ist danach( Webif ) nicht erreichbar, zurück auf die andere bootbank geht wieder alles mit kdg branding, so wie gehabt.
Muss man nach deiner Prozedur nicht wie bei 6490 firmware_version auf avm umstellen? Wenn ja wie?

sockd · 30 Sep 2019

Ja, das muss auf jeden Fall umgestellt werden. Nach einem Blick ins Beta .uimg würde ich sagen, dass die Variable OEM umgesetzt werden muss auf avm.

Code:

           # passt der OEM ?
           if [ ! -z "${OEM}" ] ; then
               oem_found=0
               for i in  avm ; do
                   if [ "$i" = "${OEM}" ] ; then
                       echo "OK - OEM ${OEM} is supported"
                       oem_found=1
                       break
                   fi
               done
               if [ "$oem_found" = "0" ] ; then
                   echo "OEM ${OEM} not supported"
                   exit $INSTALL_WRONG_HARDWARE
               fi
           fi
           echo OK - accept this update for device Fritz_Box_HW233a ...
           korrekt_version=1

Mangels Spannungswandler komme ich aber noch nicht an den ATOM-Core dran um zu suchen, wo er das hernimmt...

ice012345 · 30 Sep 2019

Bei mir bleibt der OEM=kdg
Hat alles wie von @fesc beschrieben geklappt ohne Fehlermeldung aber OEM bleibt auf kdg. Wenn ich es manuell ändere ist es bei Neustart wieder kdg.

sockd · 30 Sep 2019

Ja, das ist möglicherweise im urlader oder woanders gespeichert... Das Update oben macht ja nur ein update der Firmware... Da wird ja der Urlader/das Environment nicht geändert... So wie es auch ein normales FW-Update macht...
Adam2 scheint inzwischen bei vielen Settings nur noch Read-Only bzw. Temp zu sein...

fesc · 30 Sep 2019

ice012345 schrieb:
firmware_version auf avm umstellen

So wie ich das sehe sollte das auch per SETENV persistent gesetzt werden koennen. OEM ist keine nvram variable, die wird in etc/init.d/rc.conf aus firmware_version abgeleitet.
Ich gehe davon aus das "SETENV firmware_version avm" gefolgt von "GETENV firmware_version" wie erwartet "avm" ergibt. Genauso wie ein reboot nach SETENV wen man unmittelbar danach wieder in EVA geht und firmware_version ausliest.
Wenn es nach dem fehlgeschlagenen reboot wieder umgestellt ist, dann muss es wohl noch eine andere OEM spezifische Variable geben mittels derer das zurueckgesetzt wird.

Ansonsten könnte man im filesystem noch den OEM check in etc/rc.d/rc.conf auskommentieren, und zwar sowohl im ARM und dem Atom fs. Ich weis allerdings nicht ob-wie firmware_version noch ausgewertet wird (in ein paar binaries taucht es noch auf).

@ice012345, welche firmware version hast du denn? Gibt es irgendwelche Fehlermeldungen auf der Konsole beim booten der alternativen firmware?

Generell:
Ich wurde eh empfehlen die Original Firmware vor irgendwelchen Experimenten zu sichern wenn man schon Mietboxen modifizieren will (wovon ich kein Freund bin ...). Das geht m.W. nur mit Atom Konsole, welche eMMC partitionen das sind ist weiter oben gelistet. Lesen kann man sie auch in der ARM konsole, aber man muss sie ja irgendwohin abspeichern.

ice012345 · 30 Sep 2019

Ob man es durch EVA firmware_version dauerhaft umstellen kann kann ich nicht mehr probieren, weil durch kleine Unachtsamkeit habe ich jetzt auf beide Partitionen 7.08-Beta beschrieben.

@fesc ich hatte die 7.03 kdg Version vorher drauf. Habe nach deine Anleitung auch die modifizierte 7.08-Beta drauf installiert ohne Fehler.
Die Alternative firmware bootet nach der serielle konsole hoch, aber box vergibt Netzwerkkarte keine ip Adresse und kann nicht auf die webif auch nicht durch Notfall ip-Adresse. Wlan wird auch nicht gestartet.

koyaanisqatsi · 30 Sep 2019

fesc schrieb:
Wenn es nach dem fehlgeschlagenen reboot wieder umgestellt ist, dann muss es wohl noch eine andere OEM spezifische Variable geben mittels derer das zurueckgesetzt wird.

Bei meiner 1&1 Box mit Branding "1und1" und der entsprechenden Version des Bootloaders ( oder wars Urlader? ) existiert eine schreibgeschützte "firmware_version" separat von "environment" in: /proc/sys/urlader
Siehe...

Anleitung zum Ändern des "Branding" bei FritzBox - (auch) für DAUs

Ohne exakte Angabe - z.B., um welche Bootloader-Version es sich handelt - dürfte das auch eher wieder für Verwirrung sorgen. Eine 7580, die sich tatsächlich über den Bootloader (dauerhaft) auf ein anderes Branding umstellen läßt, hatten wir hier nämlich auch noch nicht (zumindest nicht so oft)...

www.ip-phone-forum.de

...abgesehen von dieser Änderung, existiert das Branding fix im ~~Bootloader~~ "urlader", Siehe...

Anleitung zum Ändern des "Branding" bei FritzBox - (auch) für DAUs

Ohne exakte Angabe - z.B., um welche Bootloader-Version es sich handelt - dürfte das auch eher wieder für Verwirrung sorgen. Eine 7580, die sich tatsächlich über den Bootloader (dauerhaft) auf ein anderes Branding umstellen läßt, hatten wir hier nämlich auch noch nicht (zumindest nicht so oft)...

www.ip-phone-forum.de

fesc · 1 Okt 2019

Ich kann bestätigen dass es nicht möglich ist per EVA die firmware_version variable und damit das Branding zu ändern. Eventuell ist das hardcoded im urlader (welcher sich ebenso im eMMC befindet, man koennte ihn also auch austauschen, was ich hier allerdings nicht beschreiben werde ..).

Da ich im Augenblick aus verschiedenen Gründen (z.B. weil meine 6591 mein Internetzugang ist) wenig experimentieren kann, und ich wie gesagt kein Freund von Mietboxexperimenten bin, nur soviel:

Ich habe in meinem repository noch einen patch hochgeladen welcher sowohl ARM als auch Atom FS so ändert dass in etc/init.d/rc.conf die OEM variable auf den default (avm) gesetzt wird, egal was in firmware_version steht. Bei mir funktioniert das, ob es das auch bei anderen Werten tut weiss ich nicht.

Nochmal:
Wer mit provider-firmware spielt sollte diese vorher zumindest sichern so dass man die box theoretisch wieder in den Originalzustand versetzen kann. Dazu braucht man in jedem Fall Zugang auf die Atom Konsole!

sockd · 2 Okt 2019

Die firmware_version ist fest im urlader gespeichert.
Es ist möglich ihn zu modifizieren, ich werde aber hier auch nicht beschreiben wie man das macht.
Habe also jetzt eine 6591 mit firmware_version avm und 7.04er Fritz!OS drauf und es funktioniert soweit alles.
Allerdings gibt es kein Menüpunkt zum updaten der Firmware... Evtl. ist da noch ein Check irgendwo eingebaut...

jebeyer · 2 Okt 2019

Kleiner Hinweis: momentan liegt auf dem öffentlichen Update-Server von AVM, sowohl die Release-07.04 als Image und auch noch eine Recover.exe für die 6591. Schnell sein...
http://download.avm.de/fritzbox/fritzbox-6591-cable/deutschland/

sockd · 2 Okt 2019

Erst:
FRITZ!Box 6591 Cable suchen an: 192.168.178.1
Eine Anlage gefunden! - Ermitteln der aktuellen Version.
Version erfolgreich ermittelt!
Hardware: FRITZ!Box 6591 Cable
Urlader: 308740911
Firmware: 161.07.04

Dann:
This program may be corrupted(Crc-error)!
Please reload the program from support-server or contact your support-distributor.
Dieses Programm enthaelt keine gueltige Firmware (Crc-Fehler)!
Bitte laden sie das Programm nochmal vom Support-Server oder kontaktieren sie den Support.

jebeyer · 2 Okt 2019

Dann ist offenbar das enthaltene FW-Archiv korrupt bzw. nicht vollständig.
Kann man nur immer mal wieder nachschauen, ob es eine aktualisierte Version gibt (solange das überhaupt noch möglich ist).

Das Recover Programm an sich, scheint ja funktional.

Man könnte natürlich mal bei AVM anfragen...
Entweder weckt man "schlafende Hunde" oder sie lehnen den Support dafür ab, unter Verweis darauf, dass es ja (offiziell?) eigentlich gar keine Release Images bzw. ein Recover-Programm für Kabelboxen gibt.

Getreu dem Motto: Es kann nicht sein, was nicht sein darf...

Da fragt man sich allerdings so langsam, ob oder warum das bei AVM niemanden auffällt, und der Server bzw. das Verzeichnis oder zumindest die Dateien wieder entfernt werden und/oder nicht wenigstens mit einem Login/Passwort gesichert sind.

Das Release Image war ja auch schon mal längere Zeit frei auf dem Server verfügbar "verschwand" kurzfristig und ist jetzt inkl. zusätzlichen Recover wieder verfügbar. Ein (einmaliges) "Versehen" war es ja ganz offensichtlich nicht.

Entweder wars der Praktikant... oder aber, es ist doch "Absicht".

depadre · 12 Okt 2019

Hat einer von euch die Recovery.exe für die 6591 gesichert und könnte diese zur Verfügung stellen? Lg

FB 6591 verschiedenes

Mitglied

Neuer User

Mitglied

Mitglied

Neuer User

Mitglied

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Mitglied

Neuer User

IPPF-Urgestein

Mitglied

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Statistik des Forums