[Problem] Neues Debranding Problem: FB7490 1&1, HWRevision: 185, Subversion: 6 (2017)

Loman · 1 Feb 2017

Moin.

Ich habe gestern das neuste Modell der FB7490 von 1&1 bekommen.

Jahrelang hatte ich nie Probleme mit dem debranden. Bei diesem Modell lässt sich ums Verrecken mit keiner bekannten Methode das
Branding von "1und1" auf "avm" umstellen. Ich hab die verschiedensten Recovery von 06.05 bis 06.80 durchgehabt. Der Wert "1und1" wird
jedes mal zurück gesetzt. Auch die Methode die mtd6-Partition (also die urloader-config) zu patchen bringt mich nicht weiter.

Zwar habe ich dann auch beim Kaltstart dauerhaft "avm", jedoch habe ich dann auch hier das Problem, das kein Werksreset oder
Recovery dann zu einem erfolgreichen Initialboot führt. Alles endet immer in einem Bootloop. Auch nach der Tag-Umstellung
hilft kein einziges AVM-Recovery-File das Teil zu bereinigen. Auch das manuelle löschen der mtd3+mtd4 bringt keine
Änderungen. Normal hat die urloader-mtd-Methode jahrelang immer zu einem dauerhaften Erfolg geführt - jetzt nicht mehr!

Aufgefallen ist mir, das diese Box nicht nur eine neue HWSubrevision (6) hat, sondern auch die Versionsnummer des Bootloaders
viel neuer ist als bei der älteren Hardware.

Im Ergebnis habe ich jetzt wieder das 1und1-Branding drin und die letzte Freetz 6.80 damit erfolgreich laufen

...Und nein, ich nehme das jetzt aus Prinzip nicht so hin, denn irgendwo muss das Ganze ja auch eine Ursache haben, der
ich nunmal gerne auf den Grund gehen will ;-)
- Betrifft mich das nämlich heute, wird es zukünftig bei allen nnderen 1&1-FB7490-Usern dieses Debranding-Problem auch geben,
somit würden auch andere User hier mit Sicherheit an einer Problemlösung interessiert sein ?

...und ja: Ich habe schon lange die serielle Console nachgerüstet gehabt - denn ohne die hätte ich das Teil gestern gar nicht mehr
aus den Bootloops rausbekommen.

Anbei mal die urloader-Werte des Auslieferzustandes (gekürzt auf das Wesentliche):

HWRevision 185
HWSubRevision 6
ProductID Fritz_Box_HW185
SerialNumber 0000000000000000
annex B
autoload yes
bootloaderVersion 1.3179
bootserport tty0
cpufrequency 500000000
firstfreeaddress 0x81116240
firmware_info 113.06.60
firmware_version 1und1
flashsize nor_size=0MB sflash_size=1024KB nand_size=512MB
linux_fs_start 1
memsize 0x10000000
modetty0 38400,n,8,1,hw
modetty1 38400,n,8,1,hw
mtd0 0x400000,0x3400000
mtd1 0x0,0x400000
mtd2 0x0,0x40000
mtd3 0x40000,0xA0000
mtd4 0xA0000,0x100000
mtd5 0x0,0x200000
my_ipaddress 192.168.178.1
prompt Eva_AVM
ptest
req_fullrate_freq 250000000
sysfrequency 250000000
urlader-version 4179
usb_device_id 0x0000
usb_manufacturer_name AVM
usb_revision_id 0x0000

Jetzt meine Fragen:

- Kennt jemand evtl. eine funktionstüchtige "mtd-Patchmethode" damit das dauerhaft drin ist ?
- Evtl. gleich den ganzen bootloader mal downgraden (und die personalisierten Daten
vorher dort noch mit rein patchen) ?
- Oder ist es vielleicht ganz simpel und ich habe lediglich ein manuelles Komando
im adam2 oder der telnet-console übersehen, welches jetzt zusätzlich noch
mit geändert werden muss - vor dem Einsatz des AVM "recovery.exe-file" ?

Nochmal mein Hinweis: Ich habe sämtliche Methoden und Varianten durch, die bisher
dokumentiert sind und die auch google hergibt. Den Bootloader zu patchen war
dann wirklich die letzte Methode (JTAG-Hardware habe ich auch hier, Experimenten
sehe ich da auch gern risikolos und entspannt entgegen)

PeterPawn · 1 Feb 2017

Kannst Du mir mal einen Dump des Bootloaders (und ggf. auch die - notfalls anonymisierten, aber eigentlich lieber ungeänderten - Support-Daten wg. des Flash-Aufbaus und der "dmesg"-Ausgaben beim Start, auch im Bootloader-Dump kannst Du den - bekannten - Config-Bereich dann unkenntlich machen, wenn Du Bedenken wg. der MAC-Adresse und wg. des WLAN-Keys haben solltest, aber nichts weiter, sonst bringt das nichts mehr und auch sonstige Änderungen an den Support-Daten oder am Dump bräuchten zumindest eine Form, bei der die Eindeutigkeit der originalen Angaben nicht in Mitleidenschaft gezogen wird) an eine der E-Mail-Adressen aus dem GPG-Key im GitHub-Repository senden?

Ich vermute mal, daß AVM bei den neueren Modellen jetzt auch den Bootloader so angepaßt hat, daß der "OpenFirmware"-konform das Environment auf einem anderen Weg an den Kernel übergibt, so wie es bei den beiden neuen Modellen (75x0) dem (äußeren) Anschein nach der Fall ist (vielleicht sogar schon bei den 40x0-Modellen, das hat mich nie so richtig interessiert). Wobei das dann eine andere Behandlung bei der Initialisierung ergeben müßte ... was war denn für eine FRITZ!OS-Version installiert? Für die 06.80 liegen die Quellen ja noch nicht vor, aber bis zur 06.62 durchaus - nur ist in dieser Hinsicht da kein Unterschied zu finden gewesen, wenn mich mein Gedächtnis nicht im Stich läßt und an das OF-konforme Handling des Environments schon in der 06.60 kann ich mich auch nicht erinnern ... aber es könnte ja tatsächlich schon "angelegt" gewesen sein und nur mangels Daten in älteren HWRevisionen nicht berücksichtigt werden - vielleicht gilt das sogar für den kompletten FDT, daß der jetzt im Bootloader hinterlegt ist (macht ja irgendwo auch Sinn) und beim Booten der Kernel einen passenden Pointer übergeben kriegt und da könnte dann auch noch einmal ein (weiteres) Environment enthalten sein.

Als die ersten Berichte über die Probleme beim dauerhaften Ändern von "firmware_version" auftauchten, dachte ich zuerst noch daran, daß AVM nun auch für das Branding nur noch das "zeitweilige Überschreiben" zuläßt - irgendwo muß es Flags in der Datenstruktur geben, welche Einstellungen temporär bzw. permanent überschrieben werden dürfen. Daß beim "Debranden" nur der Wert im TFFS überschrieben wurde und in einem Dump des Bootloaders immer noch das "originale Branding" aus der Finalisierung stand, war ja bekannt ... auch wenn es den meisten wohl nicht bewußt war. Wenn hier jetzt auch die Modifikation der Daten aus der Finalisierung nicht den gewünschten Erfolg bringt, dann wird es wohl irgendwo noch eine weitere Struktur mit diesen Daten geben, die ggf. wg. einer Maskierung oder einer Komprimierung nicht auf den ersten Blick als solche ersichtlich ist. Da das bisher auch nur für die 7580 berichtet wurde und da mit einiger Wahrscheinlichkeit ein FDT von der Box kommt (die hat auch mehr Platz für den Bootloader reserviert), ist das bei der 7490 tatsächlich ein spannendes Thema.

Auf welchem Weg hast Du eigentlich den Dump des Bootloaders erzeugt? Ich frage u.a. deshalb, weil es auch denkbar ist, daß der entsprechende Kernel-Treiber für den Flash-Zugriff Teile des Bootloaders "ausblendet" ... das gab es z.B. bei der 7390 für den NOR-Flash an der Stelle des "NMI vector gap", das wurde beim Lesezugriff einfach übersprungen, wie man in den entsprechenden Quelltexten aus dem OSS-Paket sehen kann. Wenn das auch für die Bootloader-Partition irgendwo im SPI-Treiber hinzugekommen ist, dann muß ein aus dem laufenden System heraus erzeugter Dump nicht 1:1 dem tatsächlichen Inhalt entsprechen und dann könnten sich auch dort Daten aus der Finalisierung "verstecken". Anders als bei "klassischem" NOR-Speicher, der direkt in den Adressraum des Prozessors eingeblendet wird, müßte bei SPI-Flash ja auch ein FDT erst einmal ins RAM kopiert werden (und kann dabei dann "demaskiert" oder dekomprimiert werden, wobei auch Änderungen am Environment möglich wären, bis hin zu einer komplett dynamisch erzeugten Struktur für das Environment), bevor er an den Kernel verfüttert werden kann.

So ein FDT hat eine Signatur und diese sollte sich (wenn er ohne Maßnahmen zur Verschleierung eingebettet ist) problemlos finden lassen (notfalls sogar noch im /dev/mem bei laufendem System) ... etwas anderes macht das Zeug in "avm_kernel_config" im GitHub-Repo ja auch nicht, wenn es nach einem FDT im Dump des Konfig-Bereiches sucht.

Existiert so ein FDT auch schon direkt im Bootloader, steigt zumindest die Wahrscheinlichkeit, daß auch das Environment auf diesem Weg übergeben wird und die Daten im TFFS bzw. im Finalisierungsbereicht für neuere Kernel-Versionen irrelevant sind, weil es eine "fixe Kopie" dieser Daten im FDT gibt und nur (überschreibbare) Werte aus dem TFFS als Overlay herangezogen werden. Schon die Frage, wie dann Änderungen an Werten im Environment (aus dem System heraus) gespeichert werden (vermutlich nicht im Bootloader

) und ob die schon vom Bootloader oder erst vom TFFS-Treiber im Kernel "gemischt" werden mit den "festen" Einstellungen, wäre eine neue Untersuchung wert. Daher ist auch die Seriennummer der Box (die ersten Stellen) wichtig (finde ich nicht in #1), weil man nur mit deren Kenntnis ein vermutlich baugleiches Modell erstehen könnte (genauso "alt" oder jünger).

Loman · 1 Feb 2017

@PeterPawn: Du hast Post mit Anhang.

Ich schau mir die Infos von Dir jetzt auch nochmal genauer an. Ich täte mich erheblich leichter, wenn ich eine kleine "Kollektion" an verschiedenen Bootloadern irgendwie bekommen könnte.
Die jeweils vorletzten Versionen wären sicher hilfreich um herauszufinden ab welcher Version der Zirkus dann losgeht. Ob die HW-Sub-Revision 6 dann mit älteren Loadern auch fehlerfrei
noch rennt in allen Dingen müsste ja ebenso noch verifiziert werden.

Ich denke grundsätzlich sollte ja nichts gegen ein shell-script sprechen, welches die personalisierten Daten aus dem "bad"-loader vorher ausliest und bei einem älteren loader
dann einfügt. Im Anschluss dann der direkte flash - mit anschliessendem verify. Das wäre sicherlich schnell und schmerzlos, und Ruhe ist, oder ? ;-)

- - - Aktualisiert - - -

KunterBunter schrieb:
Das "neue Debranding Problem" ist bereits bekannt und wurde hier im Forum schon diskutiert. Eine Abhilfe gibt es noch nicht, zumal das Problem auch nicht so brennend ist. Ein 1&1 Branding bringt ja keine Nachteile.

Eben, das schrieb ich ja bereits: Ich weiss das es keine Nachteile hat - nur wenn man jahrelang mit derartiger Hardware zu tun hat, dann weiss man aus Erfahrung, das so etwas erst der Anfang ist seitens
der Hersteller. Spätestens bei einer anderen Box - wo es dann aufgrund von Einschränkungen der Firmware sehr wohl massive Auswirkungen haben kann - ist es dann brennend relevant.
Ich sag nur 7362xx, 736x(ewe) und die neue 758x. Jeder will die "neuste" Hardware haben - aber keine die "bad-loader" die dann dort drin sind...
- Daher nehme ich mich gerne jetzt schon diesen Problemen an - bevor die Aktionen der Hersteller so richtig nervig für die Mehrheit der User werden können. Bei sowas bin ich ein gebranntes Kind

Micha0815 · 1 Feb 2017

Ein ähnliches Problem mit HWSubRevision 6 trat wohl hier neulich schon mal auf :-Ö

LG

Shirocco88 · 1 Feb 2017

bei FB7580 mit bootbootloaderVersion 1.3229 funktioniert das Un-Branding von 1und1 nach avm ebenfalls NICHT mehr;Quelle: http://www.ip-phone-forum.de/showthread.php?t=203652&p=2198493&viewfull=1#post2198493

Loman · 2 Feb 2017

Shirocco88 schrieb:
bei FB7580 mit bootbootloaderVersion 1.3229 funktioniert das Un-Branding von 1und1 nach avm ebenfalls NICHT mehr;Quelle: http://www.ip-phone-forum.de/showthread.php?t=203652&p=2198493&viewfull=1#post2198493

...und eben genau deshalb schrieb ich ja oben schon, das ich es für mich nicht dabei belasse, das ein 1und1-branding auf der 7490 "keine Nachteile" bringt.

Das ist ja leider eher der normale "deutsche Weg": Solange wie es irgendwie geht - treiben wir eben auch keinen Extraaufwand.

Nur muss man, wenn schon
alte Modelle nachträglich solche Spielchen bekommen, spätestens jetzt wach werden. Die Berichte hier bestätigen nur meine anfängliche Vermutung.

Zuerst hatte ich die Vermutung für die Zukunft und anderen Modelle ja nur so geäussert. Stunden später kommen schon die ersten Modell-Bezeichnungen der
jetzigen Geräte ans Licht. Das "Problem" ist also schon "recht präsent" und sollte auch zeitnah angegangen werden - für eigentlich alle aktuellen Modelle die derzeit
gebrandet als "Gratis-Kisten" von den ISPs weggegeben werden.

Besonders ärgerlich finde ich ja, das die 7580-Box von 1und1 bis dato mit Freetz noch nicht so wirklich warm wird
- da fängts beim Bootloader und den originalen Images dort ebenso schon an.

Ach ja, Thema 1&1: die 7580, die dort als "Business-Server" angeboten wird, bekommen auch PRIVATE VERTRAGS-BESTANDSKUNDEN bei Verlängerung angeboten!

Kostet 89 oder 99 Euro einmalig - also nix mieten. Muss man denen aber sagen - sonst gibts ne schwarze 7490 mit eben genau diesem Bröselloader "HW6" ;-)

- - - Aktualisiert - - -

@PeterPawn:

Zu Deinen Fragen mal die erste Rückmeldung:

Da ich mich selber auch bei verschiedenster Hardware geistig dabei ertappe, wie ich alle möglichen Scenarien mir so vorstelle - es dann oftmals aber ganz banal war, habe ich es mir zur Angewohnheit
gemacht, die meisten Dinge nach der "Mr. Spock" - Methode anzugehen. Dabei gilt: Ich weiss nicht was es ist - ich weiss jedoch, was es mit Sicherheit nicht ist, so gibt es auch hier
einige Dinge, die man wohl mit Sicherheit von der Liste der Vermutungen schon streichen kann. Als da wären:

- Es funktionieren auch 2 Jahre alte Firmwares mit der Version 6.05. Sowohl ueber das Recovery, als auch gefreezt.
- die neuste Hardwareversion ist also auch mit steinalten Firmwares noch kompatibel.
- Dadurch das die alten Firmwares problemlos mit dem neuen Bootloader einen initialen Init schaffen, sind keine neuen Funktionen hinzugekommen, wie versteckte Teile im Flash,z.b. denn damit
wären die ganz alten Firmwares nicht mehr kompatibel.
- Es spielt keine Rolle, welche Firmware-Version mit dem Recovery nach einem direkten mtd6-Patch verwendet wird. den Loop gibts in allen Versionen
- Die Recoverys der uralten Versionen haben ja keine Updates für neue Loader-Funktionen erhalten. Die .exe Files können auch nur das, was Ihnen vor 2 Jahren schon mit auf
den Weg gegeben worden ist. Die Plattmachmethode und Restauration rennt bei denen auch mit dem neuen Loader ganz gleich ab.
- Die Probleme fangen eigentlich nach dem 2. Boot an. Das ist der Teil, wo die mtd3+mtd4 neu initialisiert werden, bzw. der Flash teile vorher umkopiert.
- Der Loop entsteht erst im 3. Boot. Zuvor wird noch die mtd5-Partition ordentlich formatiert und nach diesem reboot fängt beim 4. reboot dieses mtd5-formatieren immer wieder von
vorne an - nebst diverser daemon-fehlermeldungen und einem auslösen des hardwarewatchdogs. Das ist ein Zeichen dafür, das irgendwo in dem "Tristate-Filesystem" wohl diverse symlinks und verzeichnisse
noch nicht auf das neue branding (oder eben avm) vollständig angepasst worden sind bei den ersten Durchläufen.
- Du sprachst von Sourcen der 7390 wo teile vom kernel-flash-treiber anders gemappt wurden... Ja bei der 7490 gibts ja auch die sourcen. Ich denke in keiner der älteren Versionen
ist da ein Support für einen Bootloader drin - einen Loader den es damals noch nicht gab - somit kann der neue Bootloader auch keine neuen Funktionen von alter Firmware "erwarten".
- Die Verwendung des vorhandenen Original-Brandings bei den verschiedenen Recovery-Versionen bis hin zur Version 6.05 zeigt sehr gut auf, das es im Grunde keinerlei Probleme mit der
Kompatibilität bei Hard- & Software gibt.

Mein derzeitiges Fazit: des Rätsels Lösung wird mit Sicherheit im mtd3/4 bei den inital-boots zu finden sein. den mtd6-urloader von anfang an ordentlich zu patchen, findet ja auch seinen weg
in die mtd3+mtd4 - da habe ich nachgesehen gehabt - nur dürfte hier dann irgend etwas inkonsistent sein was den kompletten, sauberen Init dann ab dem 3. reboot verhindert...
Ich denke, auch in weiser Vorrausschau bei den neueren Modellen, macht wohl ein script/tool zum direkten "patchen" der mtd3 + Kopie nach mtd4 am meisten Sinn.
Im Ergebnis bleibt dann auch hier der urloader auf dem original-branding - nur sorgt dann eben nicht der 1. boot für den mtd3/mtd4-init. Irgendwie müsste man dann eine Bearbeitung
nur leider genau zwischen dem recovery und initial-boot drin haben. Ansonsten werden ja auch weiterhin die "nichtflüchtigen" urloader-werte wieder verwendet.

Mein Lösungsansatz geht dahin, das man bei aktiver, gebooteter Box, wo das Branding noch aktiv ist, ein fake-file oder script hoch lädt, welches diese mtd3/mtd4-Änderungen dann
auf der box direkt live macht. Anschliessend darf dann nur nicht mehr mit der jetzigen Wiki-Methode "recovery durchlaufen lassen" gearbeitet werden.
Idealerweise dann evtl. die Firmware mit Deinen Scripten über adam2 rein. Zumindest muss irgendwie verhindert werden, das ein anderer Initial-Process nochmals Änderungen
an der mtd3/4 vornimmt - bevor die neue Firmware überhaupt mal anständig hochgekommen ist....

Zu den weiteren Fragen schreib ich Dir morgen, da muss ich noch einige Werte dann raussuchen. Etwas aber schon vorweg: Geliefert wurde das Ding mit der normalen 6.60-Version
und der Teil der Seriennummer ist: J033 - was wohl ein ziemlich neues Datum sein müsste ;-)

Ansonsten macht die Sub-Revision 6 für mich denselben schlechten Eindruck, wie es seit Jahren bei den Linksys wrt-modellen der Fall ist:
Jede neue Hardwareversion ist irgendwie "beschissener" geworden in der Qualität und Verarbeitung. Meine andere 2 Jahre alte 7490 hat da schon eine etwas
solidere Verarbeitung als das was ich jetzt hier habe. Die Hersteller werden leider immer raffgieriger, je mehr sie produzieren von einem Produkt.
So eine miese Antennenverarbeitung wie bei der HW6 habe ich bei meiner HW2 sicherlich nicht. Auch die ganze SMD-Verarbeitung ist da Einiges anständiger.
Obwohl es eine 7490 ist - bekommt man hier schnell den Eindruck, es handelt sich um eine abgespeckte "Provider-Billigversion" die unbedingt günstiger produziert werden muss.
...mal schaun ob diese Hardware auch mehr als 2 Jahre lebt oder vorher schon wg. Materialverschleiss aufgibt. NAND-Fehler hat diese Box ja ab Werk schon mehr als
genug.

PeterPawn · 2 Feb 2017

So ganz blicke ich im Moment bei Deiner Beschreibung mit 2. und 3. Bootvorgang noch nicht durch - bin aber für heute auch schon zu fertig, um das noch zu vertiefen.

Ich lese mir das morgen oder am WE noch einmal durch ... ggf. melde ich mich per PM (vom Forum), wenn ich so gar nicht durchsteige. Ich habe Dich dafür erst einmal freigeschaltet, solltest Du auch nur selektiv annehmen, wäre es nett, wenn Du mich dort einträgst.

Das mit irgendwelchen verbogenen Symlinks in einen Zusammenhang zu bringen, klingt (außerhalb von Freetz) beim ersten Lesen nicht schlüssig - wenn das System (und Du schreibst ja, daß dessen Alter egal ist) bis zum Initialisieren des yaffs2-FS in /dev/mtd5 kommt, dann ist das irgendwo mitten im Init-Prozess (S15-filesys, wenn ich mich nicht irre) und da kann das System eigentlich nur dann in einen Loop verfallen, wenn das Löschen von "recovered=x" aus "firmware_info" nicht richtig funktioniert.

Das geht dann aber wieder in die Richtung "Schreibzugriff auf das Environment aus dem lfd. System heraus" und die erfolgen eigentlich über das TFFS - da müßte also ein neuer Eintrag mit "firmware_info" (und da geht es um die Versionsnummer, nicht das Branding) und ohne "recovered"-Zusatz im TFFS landen (sollte man beim "ersten Run" ja auch noch irgendwann dumpen können, notfalls über die Supportdaten - man muß dem Einrichtungsassi nicht bis zum Ende folgen).

Aus dem Stand überlegt, würde nur das Fehlschlagen dieses Schreibvorgangs (oder das Ignorieren des neuen Wertes beim nächsten Start) zur beschriebenen Schleife beim Initialisieren von MTD5 führen, zumal das Rücksetzen von "recovered" auch bereits in S01-head (am Ende) erfolgt und damit gar nicht von irgendeinem Erfolg des Formatierens abhängig ist. Jedoch würde ein "Formatfehler" beim nachfolgenden Mountversuch natürlich auch Probleme machen und dann formatiert das Gerät ggf. beim nächsten Start schon wegen dieses Fehlers noch einmal.

Aber vielleicht sind wir auch bloß nicht ganz konform bei der "Zählung" der Bootvorgänge und ich verstehe unter dem zweiten etwas anderes als Du. Wie gesagt, für heute bin ich erledigt ... morgen wird es eng und damit vielleicht eher Wochenende, bevor ich den Nerv dafür habe.

So als allerletzten Gedanken noch folgendes: Bist Du sicher, daß nicht einfach nur der Flash so kaputt ist (Du schreibst ja von Fehlern ab Werk, auch wenn die (in Grenzen) normal sind bei NAND-Flash), daß bei Schreibversuchen in den SPI-Flash(!) Probleme auftreten und daher vielleicht Daten in bestimmten Partitionen dort bei Dir einfach nicht richtig gespeichert werden? Mach doch mal einen Dump vom SPI nach dem ersten Run und schaue nach, ob die Partitionen MTD3 und MTD4 wirklich gültige (und erwartbare) Inhalte haben. Am Ende ist es vielleicht gar kein neuer Bootloader (zumindest nicht im Ablauf, auch wenn die Versionsnummer schon höher ist), sondern "nur" ein Problem beim (dauerhaften) Speichern der Änderungen im SPI-Flash, die dann natürlich nach dem nächsten "Kaltstart" auch wieder weg wären. Wobei die Box dann eigentlich auch bei allen anderen Einstellungen unter Amnesie leiden müßte und das wäre Dir wahrscheinlich (auch mit 1&1-Branding) schon längst aufgefallen.

Wenn die Box mit 1&1-Branding läuft, würde ich dort per "modfs" ein System mit Shell-Zugriff auf der Box installieren (falls Du noch keinen hast, ich weiß nicht, ob auf der Seriellen ein getty gestartet wird bei der 7490) und dann mal in aller Gemütsruhe den Aufbau des TFFS analysieren und zwar vor und nach irgendwelchen Schreiboperationen und auch mal nach einem erzwungenen Wechsel der (TFFS-)Partition mit gleichzeitigem Komprimieren der Daten. Vermutlich läßt sich das alles irgendwie auf das TFFS zurückführen, was an Symptomen geschildert wurde - vielleicht hat auch nur eine der beiden (alternativ genutzten) TFFS-Partitionen einen Hau, dann tritt das Problem auch nur "spontan" auf, wenn gerade diese Partition beim Start das "neuere" TFFS enthält (das wird ja anhand der Daten am Beginn der Partition entschieden) und damit das "erste Einlesen" nicht funktioniert.

Aber das ist auch alles Spekulation ... wenn Du Dich da einfach Stück für Stück vorwärts tastest und - tatsächlich wie Spock - nur logische Schlußfolgerungen ziehst (damit dann auch nichts als "gegeben" überspringst), dann findet man das bestimmt. Ich bin mir halt nicht sicher, wie weit AVM den Bootloader geändert haben mag - überraschend wäre das ja schon irgendwo - und da könnte dann die simple Erklärung (Ockhams Rasiermesser läßt grüßen) auch am Ende ein Hardware-Defekt im SPI-Flash sein. Von der schlechteren Qualität (zumindest in der "Anmutung") hast Du ja auch schon berichtet - wobei solche Probleme wie kalte Lötstellen oder gebrochene Leiterbahnen auf dem (oder im) PCB bei seriellem Flash schon sehr unwahrscheinlich werden, wenn sie nur Teile des Speichers betreffen sollen.

Bei der (m.W. einzigen) anderen 7490 mit Problemen beim Setzen des Annex im Environment könnte es sich wahrscheinlich auch noch um eine Fehlbedienung handeln ... wobei da nähere Angaben zur Box noch fehlen und ich schon etwas skeptisch bin, wie "schnell" es neuere 7490 (noch dazu in A/CH-Ausführung) denn nun von der Produktion bis nach A oder CH geschafft haben sollen, wenn das für eine 1&1-Box (falls ich das nicht falsch bei Dir verstanden habe) und eine A/CH-Box fast zeitgleich (erstmalig) auftreten soll.

Wobei das "J" dann zumindest die an anderer Stelle aufgetauchte Frage nach dem "I" und der Verwechselungsgefahr mit der "1" geklärt hat - vielleicht ist die Verwechselungsgefahr und schlechte Erfahrung mit dem "B" in 2011 tatsächlich auch der Grund, warum es 2015 kein "G" gab.

Loman · 2 Feb 2017

Also Flash ist trotz der Fehler einwandfrei in Ordnung - sehe ich bei Verwendung des 1und1-Brandings bei Verwendung der Original-Firmwares.
Wobei sich die Ecc-Debug-Ausgaben bei der 6.80 so richtig bemerkbar machen, die 6.60 meldet solche ecc-Fehler erst gar nicht in dieser Menge.
habe das mit beiden Speicherbänken, also 0 und 1, durchgespielt. Die ecc-fehler liegen ueber den ganzen NAND-Bereich gleichmässig verteilt.
Ich denke da wurde der logspam-level wohl etwas erhöht in der 6.80 - oder nach den letzten Labors vergessen wieder abzusenken für die Final

Aufgrund Deiner oberen Erläuterung hilft mir die Info von Dir wieder mal erheblich weiter:

Es ist tatsächlich so, das zwar die upzudatende neue Version bei der Firmware-Version angezeigt wird, aber tatsächlich das ", Recovery=3 oder 2"
nicht gelöscht wird. Nach dem Loop-Abbruch und auslesen im adam2 mit serieller console war das ",recovery=x" auch jedes mal noch gesetzt.
Natürlich bin ich auch auf die Idee gekommen, das "softmässig" mal zu überschreiben - was im RAM auch angenommen wird, und habe dann
ohne weiteren reboot mit dem "go"-command den init weiter laufen lassen. In Summe ist das System dann jedoch immer noch in einem Tristate
Zustand gewesen, hatte irgendwann einen segfault und der watchdog hats dann erneut resetet - womit dann natürlich wieder der recovery-level
wieder aktiv wurde. Durch den reboot wird alles wieder zurückgesetzt. Ist das Ding jedoch einmal fertig gebootet und man
ändert im laufenden Betrieb das Branding "soft", reagiert das laufende Webinterface ja quasi sofort in Echtzeit. Also ein fertig
gebootetes Image kann sehr wohl "live" mit diesen temp. Settings bis zum nächsten Hard-Reboot auch "sauber" weiter arbeiten.
...gut das geht deshalb, weil im laufenden Betrieb das Backend auf die /proc/sys/urloader/enviroment-Sachen zugreift - nicht auf die Flashinhalte
selber. Die AVM-Recoverys werden, dadurch das sie ja uralt sind, vor der Restauration wohl mit Sicherheit nicht nur auf
den urloader, sondern auch auf den Inhalt der mtd3/mtd4-Sache zugreifen ? Soweit ich es verstanden habe, muss das jeweilige Recovery
ja die nachfolgenden Init-Läufe "sauber" vorbereiten und dazu aufgrund des Auslesens von IST-Zuständen eine entsprechende
Recovery-Entscheidung zuvor treffen und entsprechende preconfigs für die mtd3/mtd4 mit auf den Weg geben für diesen Init.

Wobei wir dann bei dem Thema sind: Das soft-setzen von "firmware_version" ueber "ENV" uebersteht ja den Einsatz mit anschliessendem
AVM-Recovery, wenn kein reboot selber durchgeführt wird dazwischen. Somit halte ich es für wahrscheinlich, das sich selbst die
uralten Recoverys nicht nur dem "ENV" bedienen für den Versions-Check, sondern vielleicht auch andere Daten mit heranziehen.

Da fällt mir jetzt ein, da könnte wohl ein weitergehender TCP-Dump der Recovery-Kommunikation ggfs. Ideen liefern. Ich denke nicht,
das diese Kommunikation verschlüsselt ist - Nicht bei Uralt-Versionen ;-)

Ich müsste jetzt mal rausfinden, was die mtd3/mtd4-Sachen dann live treiben. Ich wette, dort findet nämlich keinerlei Anpassung statt.
Es fehlt quasi sowas wie ein "nvram commit", damit die temp. Änderungen auch in den TFFS+Kopie sofort mitübernommen werden,
nachdem man das enviroment geändert hat im laufenden Betrieb.

Mit modfs und diesen Sachen habe ich bislang noch nicht gearbeitet - ich komme eher aus der Cisco/Linksys/Tomato/Openwrt-Ecke, da kenne ich
die Firmware-Spielchen schon im Schlaf. Bei den Fritzboxen und den ganzen Dingen muss ich mich auch erst mal im Schnellverfahren
einarbeiten - da helfen mir Deine Infos schon sehr weiter - da ich so direkter zum Ziel kommen kann und mich detailierter den eigentlichen
Bereichen dann zuwenden kann. Also für mich sind der mtd3/4-Bereich jetzt mal relevant wie deren Inhalt zu welchem Zeitpunkt dann
aussieht. Zumindest wissen wir mal, das sich an der Firmware selber nichts verändert hat - da sie teilweise schon ueber 2 Jahre alt ist.
Also muss man dort auch nicht wirklich intensiver suchen, denke ich mal.

Ich werd dann mal weiter loggen und dumpen und comparen ;-)

Meinen mtd6-dump habe ich Dir ja gestern schon per email gesendet, müsstest Du eigentlich bekommen haben ?
Mir würde es helfen, wenn Du mir noch mtd6-Dumps von evtl. Deinen Boxen zukommen lassen kannst.
ich würde da gerne Binary-Compares machen - ich habe nur keine Quellen für weitere Bootloaderversionen auf die
Schnelle eben auftun kommen

Was den Lagerstand in AT angeht, ist es so das Firmen wie UPC ueber Ihren Globalen Einkauf, meist bereits ein Jahr vorher
schon die Dispositionen machen. Dort kommen aber seit Jahren eher die abgespeckten Versionen zum Einsatz.
Die meisten östr. Boxen haben kein Branding, nur eben die "Intl/AT-HW-Version". Ich habe viele Jahre in Österreich in der ISP-Branche
in Rechenzentren gearbeitet, die Access-Provider waren dort quasi die Büronachbarn, und man war privat dann selber
auch deren Produkt-Kunde, daher kenne ich die Österreich-Versionen und Vertriebswege eigentlich sogar besser als
die in Deutschland. Schlafen tun die in Österreich jedenfalls nicht, und nicht nur im Mobilfunk ist man da technologisch
oftmals weiter als in Deutschland. Dort sitzen auch keine Riesenkonzerne wie hier, wo Vieles sehr träge ist.
Da ist die Entscheidungsfutterkette in fast allen Bereichen erheblich kürzer als hier. (Ist ja auch nur 1/10 des Deutschen Marktes)

Was meine "arbeiten" an der Fritzbox angeht, so behandele ich dieses Problem genau so wie ich das beruflich
seit Jahrzehnten schon mache: Ich mache Troubleshooting und Hardware-Debugging. Da ist man das Pferd
von Hinten aufziehen schon gewöhnt - ebenso ist es ein Vorteil bei der Box nicht so tief in der Entwicklung
seit Jahren schon drin zu stecken - dadurch sehe ich oft Dinge, die der Entwickler so gern mal übersieht. Ich habe
dieses Problem selber bei Tomato und OpenWRT - da bin ich dann wegen dem gesammelten Wissen selber
oft Blind bei einfachen Problemen und sehe alle möglichen anderen Dinge zuerst. Ich zumindest finde Problemlösungen
eher, wenn ich direkte Hinweise zum "Zielbereich" bekomme - dann kann ich mich dort auch gezielter einarbeiten
und nehme dann eben nicht den ganzen Ballast der Entwicklung zeitlich mit auf. Meine Ansätze sind eher
serielle Console und JTAG und erst mal mit Hardware dabei gehen, anstelle mir über Firmwareabläufe bei einem
neuen Gerät mir unnötig einen Kopf zu machen ;-) - Ich bin halt bei den Hardware-MODs fitter als bei der
Software-Entwicklung.

Micha0815 · 2 Feb 2017

PeterPawn schrieb:
...
Bei der (m.W. einzigen) anderen 7490 mit Problemen beim Setzen des Annex im Environment könnte es sich wahrscheinlich auch noch um eine Fehlbedienung handeln ... wobei da nähere Angaben zur Box noch fehlen und ich schon etwas skeptisch bin, wie "schnell" es neuere 7490 (noch dazu in A/CH-Ausführung) denn nun von der Produktion bis nach A oder CH geschafft haben sollen ...

Laut TE war es ein Modell für "Down-Under" und nicht für A-CH.

In der Bucht sah ich schon Kartonagen mit englisch-sprachigem Aufdruck, was für A-CH eher untypisch.

LG und nur zur Erläuterung

PeterPawn · 4 Feb 2017

Ich habe jetzt mehrfach die Ergänzungen in #6 und den Beitrag #8 gelesen, bin aber - ich muß es zu meiner Schande gestehen - nicht wirklich daraus schlau geworden. Daher greife ich mal das heraus, was ich glaube verstanden zu haben und dazu ein paar Korrekturen bzw. Darstellungen, wie das aus meiner Sicht (und Erfahrung) funktioniert:

1. Ich habe keine Bedenken hinsichtlich des NAND-Flashs der Box, der kommt mit ein paar fehlerhaften Zellen problemlos klar und das verwendete "Dateisystem" ist dort ja auch genau dafür ausgelegt, mit schadhaften Zellen oder Blöcken umgehen zu können. Meine "Bedenken" bzgl. des Flash-Speichers bezogen sich auf den SPI-Flash - dort stehen der Urlader (in den ersten 256 KB) und die beiden TFFS-Partitionen (jeweils 384 KB) in den verfügbaren 1024 KB der gesamten Flash-Größe ("sflash_size=1024KB" in "flash_size" im Firmware-Environment). Da die beiden TFFS-Partitionen im Wechsel verwendet werden, wäre es zumindest denkbar, daß nur eine der beiden fehlerhaft ist (dort gibt es m.W. auch keine weiteren Mechanismen zur Fehlererkennung oder gar -korrektur) und es immer dann zu Problemen kommt, wenn die gerade gültigen Werte in diese Partition geschrieben werden - wo sie dann hinterher nicht mehr richtig gelesen werden können und daher gehen dann Änderungen "verloren".

2. Das "Komprimieren" einer TFFS-Partition umfaßt das Auslesen aller noch gültigen Einträge und das Schreiben derselben "am Stück" als neuer Inhalt der Partition. Da neue Einträge bis zu einem festgelegten Füllstand "hinten" angefügt werden an die bereits vorhandenen Daten, entstehen im Laufe der Zeit "Lücken" mit alten, ungenutzten Daten innerhalb der Partition und diese werden bei der Komprimierung dann geschlossen, womit der Füllstand (die "Marke" für das nächste Schreiben) dann wieder sinkt. Da gibt es auch keine Prüfsummen oder ähnliches - auch komprimierte Streams (zlib-deflate wird für die "Dateien" dort verwendet, wenn sie über den TFFS-Treiber geschrieben werden) haben keine CRC-Werte am Ende, wie das ansonsten bei solchen Dateien üblich wäre nach den einschlägigen RFCs (Adler32).

3. Bei der Verwendung des Recovery-Programms wird das Environment der vorhandenen Box ausgelesen (ganz normal über FTP, allerdings "am Stück" und nicht mit einzelenen "GETENV"-Kommandos) und die "Counter" (letztere sehen manches Mal wie ein Relikt aus längst vergangenen Boxen aus (bei einer 6490 sind wohl alle Werte "u") und manchmal scheinen sie auch sinnvolle Angaben zu enthalten, die aber inzwischen wohl falsch "benannt" sind, wenn eine nagelneue 7490 bei "run_years" bereits Werte > 0 enthält). Mit diesen Angaben baut das Recovery-Programm dann ein TFFS-Image und schreibt dieses Image in beide Partitionen mit einer identischen ID, so daß es auch egal ist, welche Partition die neuere Version enthält und damit ist nach Recovery immer die erste Partition in Verwendung, weil der Code nur dann die zweite nehmen würde, wenn sie aktueller (aka kleiner) wäre (das gilt jetzt für "legacy TFFS", inzwischen gibt es andere Implementierungen, aber nicht für die 7490):

Code:

1784     if(ctx->avail_mtd[0].segment_id == 0 && ctx->avail_mtd[1].segment_id == 0){
1785         panic("[%s] no valid filesystem on mtds \"%s\" and \"%s\"!\n",
1786               __func__, ctx->avail_mtd[0].mtd->name, ctx->avail_mtd[1].mtd->name);
1787     }
1788
1789    [COLOR="#FF0000"] if(ctx->avail_mtd[0].segment_id > ctx->avail_mtd[1].segment_id){[/COLOR]
1790         put_mtd_device_wrapped(&(ctx->avail_mtd[1]));
1791         ctx->active_mtd = &(ctx->avail_mtd[0]);
1792     } else {
1793         put_mtd_device_wrapped(&(ctx->avail_mtd[0]));
1794         ctx->active_mtd = &(ctx->avail_mtd[1]);
1795     }
1796
1797     pr_info("[%s] Using segment %u (avail: %u + %u)\n", __func__,
1798                 ctx->active_mtd->segment_id,
1799                 ctx->avail_mtd[0].segment_id,
1800                 ctx->avail_mtd[1].segment_id);
1801
1802     pr_info("[%s] mtd%u size=0x%llx\n",
1803             __func__, ctx->active_mtd->mtd_idx, ctx->active_mtd->mtd->size);

Im Anschluß an das Schreiben der TFFS-Partitionen (ein Update des Bootloaders habe ich bei der 7490 noch nie gesehen, ich finde in meinem "Einflußbereich" auch nicht eine einzige 7490 (die wurden zwischen Nov. 2014 und Dez. 2016 gekauft, teils deutsche, teils internationale Firmware, 1&1-Branding und "Retail", also wirklich bunt gemixt und auch verteilt in D/A/CH), die einen anderen Loader als die Version 2964 hätte) wird dann ein "ganz normales Firmware-Image" in den Speicher geladen und von dort gestartet - im Verlauf der Initialisierung dieses Systems stellt es dann selbst fest (in /sbin/flash_update), daß es aus dem RAM gestartet wurde und schreibt sich umgehend selbst in die passenden (NAND-)Flash-Partitionen; die Auswahl erfolgt anhand des aktuellen Wertes von "linux_fs_start". Nach dem Schreiben in den Flash startet die Box dann neu und lädt jetzt das System aus dem Flash-Speicher.

Damit wird dann vielleicht auch klar, warum man beim "Nummerieren" von Bootvorgängen besser genauere Angaben macht. Auf einer seriellen Konsole sieht man natürlich den zusätzlichen Bootvorgang nach dem Schreiben in den Flash sehr genau ... ist man auf die von den LEDs vermittelten Signale angewiesen, muß man schon sehr genau hinsehen, um das Ende des Flashens (indirekt, über das kurzzeitige Aufleuchten aller LEDs beim Initialisieren der GPIO-Ports) nicht zu verpassen oder man kennt sich genau mit den verschiedenen "Blinksignalen" aus. Daher braucht es bei einer Beschreibung "die xyz-LED blinkt dann immer" auch immer die Angabe, was zuvor alles passierte, wann so ein Blinken dann begann (als Zeitdifferenz zum Start der Box) und welche Frequenz dieses Blinken denn nun genau hat. Erst daraus läßt sich dann halbwegs ableiten, was so ein Blinken eigentlich besagen will - die LEDs sind nun einmal fast alle "doppelt belegt".

Auch einige Berichte "Recovery geht nicht" haben ihre Ursache in diesem Vorgehen und der (unbestreitbaren) Tatsache, daß die Leute die finale Ausgabe des Recovery-Programms nicht lesen. Dort steht m.W., daß die Box erst nach dem nächsten Neustart das gerade zu installierende System enthält und das sollte man eben ernst nehmen und die LEDs entsprechend beobachten. Da der oben angesprochene Flash-Vorgang für das System (Schreiben aus dem RAM in die NAND-Partititionen) durchaus etwas Zeit benötigt, signalisiert die Box das mit einer blinkenden Info-LED (oder war es "Power"? ich bin nicht 100% sicher, irgendwas "am Rand" blinkt halt). Da hier auch die gerade aktive Partition verwendet wird, führt ein vorzeitig unterbrochenes Schreiben (durch erneuten Restart seitens des Benutzers) auch zu einem nicht vollständigen Update von Kernel oder Dateisystem und da es beim Booten kein automatisches "failover" gibt, wenn eine Partition "leer" ist oder keine gültigen Daten enthält (das ist für den Bootloader auch nicht ganz einfach zu ermitteln), bleibt die Box dann beim nächsten Start einfach hängen oder stürzt ab (Boot-Loop) oder was auch immer. Man sollte also bei der Verwendung des Recovery-Programms die LEDs der Box gut im Auge behalten und mehr dorthin schauen als auf das Display des verwendeten Windows-PCs (je ein Auge ist die optimale Lösung).

eifelman · 4 Feb 2017

Interessantes Thema, auch wenn ich die Hälfte aufgrund fehlender entsprechender Vorkenntnise nicht verstehe.

Wie ich hier rauslese, scheint AVM bei den neuen 7490 was geändert zu haben, dass diese bei Debranding nach einigen Neustarts in einem Bootloop hängen und für den Normalo quasi nur noch als Briefbeschwerer zu gebrauchen sind. Soweit richtig?

Ist davon auszugehen, dass alle 75x0 Modelle davon auch betroffen sind? Ich frage aus eigenen Interesse - habe eine 7560 von 1&1 und bei dieser, als FW 06.80 installiert war, mittels adam2 die firmware_version von 1und1 zu avm geändert. Danach habe ich die Box mittels Recovery auf die neueste FW 06.81 gebracht. Branding ist weg und sie verhält sich (noch) normal. Wurde seither aber erst 2 mal neugestartet.

Besteht ein Risiko, dass meine 7560 auch bald Probleme macht? Falls ja, würde ich lieber, solang es noch möglich ist, die firmware_version wieder zurück auf 1und1 stellen.

qwertz.asdfgh · 5 Feb 2017

eifelman schrieb:
Wie ich hier rauslese, scheint AVM bei den neuen 7490 was geändert zu haben, dass diese bei Debranding nach einigen Neustarts in einem Bootloop hängen und für den Normalo quasi nur noch als Briefbeschwerer zu gebrauchen sind. Soweit richtig?

Nein. So wie ich das verstanden habe (und um ehrlich zu sein ist die Beschreibung des TE nicht ganz einfach zu verstehen bzw. undeutlich) hat das Ändern auf die ursprüngliche Variable das Problem wieder beseitigt (also kein Briefbeschwerer).

eifelman schrieb:
Falls ja, würde ich lieber, solang es noch möglich ist, die firmware_version wieder zurück auf 1und1 stellen.

Dazu besteht wohl derzeit kein Anlass.

koyaanisqatsi · 5 Feb 2017

Moin

:?:

Besteht ein Risiko, dass meine 7560 auch bald Probleme macht? Falls ja, würde ich lieber, solang es noch möglich ist, die firmware_version wieder zurück auf 1und1 stellen.

Eindeutig: Ja
Da alleine schon die Anbieterauswahl von 1&1 dazu führt, dass die Box über TR-069 provisioniert wird.
Theoretisch können sie dir also eine neue Firmware mit dem "neuen" Bootloader aufspielen.
...vielleicht als unbedarfter Knopfdruck eines hochmotivierten (Support) Mitarbeiters.
(Murphy sagt: Den Teufel an die Wand malen)

Shirocco88 · 5 Feb 2017

FB75x0: die fehlende Möglichkeit des "Un-Brandings" bei FB7580 betrifft derzeit IMHO nur den "1&1 BusinessServer" mit bootbootloaderVersion 1.3229;weitere Quellen: #5

sneaker2 · 5 Feb 2017

Inwiefern betrifft das bei der 7580 "nur" den "1&1 BusinessServer"? Gibt es denn noch andere gebrandete Varianten der 7580? Oder ist damit gemeint, daß man bei der freien Retail-Version das Branding ändern kann (Sinn sei mal dahingestellt)?

Micha0815 · 5 Feb 2017

Durchaus vorstellbar, dass die FB7580 auch z.B. in A-CH oder Down-Under mal auftaucht?
LG

Loman · 6 Feb 2017

So mal eine erste Rückmeldung zu den 2017er 7490 1&1 Kisten:

Ich habe nun, dank der freundlichen Unterstützung durch PeterPawn, erfolgreich einen Bootloader-DOWNGRADE bei der 1&1 7490er durchgeführt.
Zuerst einmal: Es entstehen sehr wohl gewisse "Nachteile" - wenn man die 1&1-Box mit dem Branding einfach so weiter verwendet.
(Bei einem anderen ISP evtl!)

Beim Downgrade des Bootloaders sind sofort zwei Variablen aufgefallen, die es in der 1&1-Version gar nicht mehr gibt:
TR069_accountname und TR069_passwordhash. Diese Variablen konnte ich nur mit dummy-Werten füllen, da beide Angaben
für die 1&1-Varianten NICHT (mehr) vorhanden sind!!

Es handelt sich somit tatsächlich bei den neuen Versionen um eine "leicht kastrierte" Box die auf einen ISP optimiert
worden ist.

Diese individuellen tr069-Daten sind sehr wohl wichtig bei ISPs die nach wie vor keine Config-Daten herausrücken,
und ausschliesslich über diese Verfahren die Daten auf die Boxen befördern. Die "StartCode"-Sache ist ja im Grunde
eine Eigenentwicklung von 1&1. Auch bei einigen anden Sub-Funktionen (z.b. Cloud-Sachen anderer Anbieter) ist die branded
Version etwas eingeschränkter als die "avm"-Variante.

Also abschliessend: Ein Downgrade des Bootloaders der HW6 auf einen Bootloader der HW2 oder 3 ist problemlos möglich,
wenn man zuvor noch den config-Bereich mit einem Hexeditor entsprechend bearbeitet hat. (Übernahme der MAC-Adressen
aus dem neueren Loader nach entsprechend vorherigem dumpen).

Achtung: Nach dem BL-Downgrade funktioniert kein einziges "hashed" Passwort mehr!

Direkt nach dem Downgrade sollte in derselben Session unbedingt noch ein erase mtd3+mtd4 gemacht werden,
danach sofort mit der entsprechen Recovery hinterher. Ich empfehle hier die Version 6.20.
Von dort aus dann entsprechend die erste Freetz-Version rein (z.b. 6.50) - und ab dann ueber Freetz
selber bis zur 6.80´er upgraden. Der Weg über adam2/ftp zum manuellen setzen von "firmware_version" ist
bei vorherigem Löschen von mtd3+mtd4 nicht mehr nötig - hier werden dann die gepatchten Werte des
urloaders genommen.

Es ist jetzt wohl davon auszugehen, das auch die 7362SL von 1&1 ähnlich kastriert sein dürfte. Im Grunde hat dann
künftig keine einzige "schwarze Kiste" mehr individuelle tr069-Daten im urloader drin. Jeder der aber sowieso
alles von Hand konfiguriert, hat dann hier tatsächlich keine wirklichen Nachteile dadurch... ;-)

Also bei mir rennt das ganze jetzt seit 3 Tagen stabil als ATA ;-)

BTW: Ich habe hier jetzt bewusst keine Step-By-Step-Anleitung geschrieben, da das Ersetzen des
Bootloaders, nebst auch der Beschaffung eines älteren passenden Loaders, eine nicht zu unterschätzende
"Briefbeschwerer-Situation" hervorrufen kann. Solange man ein JTAG-Interface griffbereit hat, kann man
das jedoch recht entspannt angehen.

Man sollte sich zumindest gut mit dem auslesen und flashen im laufenden Betrieb auskennen, bevor
man mit dieser Methode dem Debranding endgültig auf die Pelle rückt ;-)

Micha0815 · 6 Feb 2017

Loman schrieb:
...
Achtung: Nach dem BL-Downgrade funktioniert kein einziges "hashed" Passwort mehr! ...

Könntest Du dies freundlicherweise etwas näher erläutern. Betrifft dies die Import-/Exportfunktion einer Sicherungsdatei (FB*.export).

LG und Tx

Loman · 6 Feb 2017

Micha0815 schrieb:
Könntest Du dies freundlicherweise etwas näher erläutern. Betrifft dies die Import-/Exportfunktion einer Sicherungsdatei (FB*.export).

LG und Tx

Wenn Du bei bei einer laufenden Installation NUR den Bootloader tauscht und anschliessend sofort rebootest, sind die Enviroment Variablen ja erst einmal unverändert.
Beim nächsten Bootvorgang kannst Du dann weder mit telnet, noch ftp oder ueber das AVM-Webinterface einloggen. Deshalb schrieb ich, das nach dem
BL-Downgrade in jedem Fall ein vollständiger Cleanup in derselben laufenden Session erforderlich ist. mtd3+4 müssen danach also vollständig neu erstellt werden, deshalb
im Anschluss auch das erforderliche vollständige Recovery durchführen.

KunterBunter · 6 Feb 2017

Loman schrieb:
Es ist jetzt wohl davon auszugehen, das auch die 7362SL von 1&1 ähnlich kastriert sein dürfte.

Nein, davon ist nicht auszugehen.

[Problem] Neues Debranding Problem: FB7490 1&1, HWRevision: 185, Subversion: 6 (2017)

Neuer User

IPPF-Urgestein

Neuer User

IPPF-Promi

Aktives Mitglied

Neuer User

IPPF-Urgestein

Neuer User

IPPF-Promi

IPPF-Urgestein

Neuer User

IPPF-Promi

IPPF-Urgestein

Aktives Mitglied

Mitglied

IPPF-Promi

Neuer User

IPPF-Promi

Neuer User

IPPF-Urgestein

Statistik des Forums