Einbindung von LabBeta für 5590 in freetz

[maverick3005]

Jetzt mal eine blöde Frage zur 5590 LabBeta:

Wie baue ich in welche config Files mal eine passende LabBeta für die 5590 ein ?

Ich habe nur die direkte Download-URL bislang:
https://avm.de/fileadmin/user_upload/DE/Labor/Download/fritzbox-5590-fiber-labor-102864.zip
sowie:
https://download.avm.de/inhaus/MOVE21/5590Fiber/FRITZ.Box_5590_Fiber-07.39-102064-Inhaus.image

im Juis selber habe ich bislang auch nur die "Inhaus" gefunden.

Ich kann mir irgendwie nicht ganz vorstellen, das eine "Musterconfig" wie bei der 7490:
dea42b7

hier so einfach ohne weitere Infos & configs ausreicht, da es auch keine weiteren basis-config Files gibt so wirklich.

Eine Doku, wie ich sowas initial für neue Versionen erstellen kann (oder auto generieren kann) habe ich nirgend wo gefunden.
So tief bin ich der Materie leider auch nicht drin.

[fda77]

Wenn du ne doku willst, schreib sie. Ansonsten ist der code die doku
5c129a6
4bb3010
c8164cd
fb65294
Nach je so einem commit läuft eine github-action die noch ein paar dinge generiert

[maverick3005]

Wenn du ne doku willst, schreib sie. Ansonsten ist der code die doku 5c129a6 4bb3010 c8164cd fb65294 Nach je so einem commit läuft eine github-action die noch ein paar dinge generiert

...also beim github-action steig ich dann mangels Ahnung auch erst mal aus. Vorhandene lokale Files etwas editieren,
download URL + checksum erstellen, sowie die Kernel-Version ermitteln würd ich gerade noch selber hinbekommen.

Ich hab im IPPF in den 5590-Beta Threads etliches gefunden, was das Thema v6/Timeouts/WLAN & co. angeht, sodas
da ne Beta schon recht hilfreich ist, da doch viele User mit der Stabilität der 7.30 und v6 noch massiv Probleme haben.

Ein Bekannter fagte mich die Tage nach einem Beta-Support für dieses Gerät und ich habe ihm erst mal eine
Wunsch-Freetz für 7.30 erstellt, die wohl auch einigermassen laufen soll....

[fda77]

Mal im ernst, mit den links oben kann das ein dressierter Affe.
Wenn du keine Lust hast das zu machen musst du warten (ewig?) oder dir jemand suchen der die 5 zeilen tippt. Viel Glück

[maverick3005]

Ich mache mich mal an die entsprechenden Files und erstelle mal ein lokales diff. Kannst Du zumindest damit etwas anfangen ?

[fda77]

Viel einfacher, ein PR: https://freetz-ng.github.io/freetz-ng/SUPPORT.html#pull-request
Das kannst du dann bei jeder neue Version machen, ich hab da nämlich keine Lust mehr dazu ;-)

[maverick3005]

Aus Zeitmangel hab ich schnell mal was versucht. Bitte schau mal bei den issues, evtl. kannst Du Dich ja erbarmen, die wenigen extra Schritte in 5 Minuten noch schnell von Hand zu fixxen ?

[fda77]

Als pull request wäre es besser

[maverick3005]

Den Zusammenhang mit den bei github ablaufenden "generate" Prozessen habe ich noch nicht ganz verinnerlicht, daher habe ich erst mal nur die offensichtlich zu ermittelnden Daten als Basics eingetragen.

[maverick3005]

Sieht mal gut aus für den ersten Versuch:

Alle Menüs, Funktionen, Optionen sehen gut aus, bestehende Daten aus der 7.30 config wurden sauber übernommen,
"autoupdate-Dienste" haben sich nicht "magisch" wieder von selber eingeschaltet, und auch tr069/tr369.cfg wurde 1:1
ohne Reaktivierung übernommen.

Auch sind keine Segfaults oder oops im logfile vorhanden.

Es verbleibt das gemeldete Problem, das sich die Bank 2 nicht flashen lässt, und das "push_firmware" ein Fixxing für das
62MB grosse .image wohl noch braucht ;-)

[maverick3005]

Ach das ist ja mal nett:
(Da habens auch nur über 10 Jahre gebraucht das Feature zu implementieren...)

Der letzte Punkt: "PPPoE mit Mini-Jumbo Frames" (also MTU 1508), damit auch bei Telekom/1und1 die MTU nicht mehr 1492 ist.
Das Problem, laut eines Freundes in München an seinem Fiberanschluss ist jedoch: Die Telekom hat es im BNG (wie erwartet)
natürlich wieder nicht aktiv. Weder auf VDSL noch auf Fiber. Er sagte mir aber, das es in verschiedenen Ecken in Deutschland auch
im Telekom-Netz teilweise gehen würde...

Diese Funktion ist auch in der 7490 und 7590 FOS 7.50 jetzt drin. Bei der 7590 ist es sogar aktiv (automatisch)!
Theoretisch sollte jetzt beim PPPoE-Handshake dann gleich auch eine "ppp"-MTU von 1500 ohne clamping gehen ?

(Bei der 5590 ist der Haken allerdings per default derzeit in der Beta noch nicht gesetzt)

"Netzwerkschleifen-Check" dürfte dann wohl STP über die LAN-Bridge sein - was beim anstecken eines LAN-Ports dann zur Folge
hat, das es bis zum ersten Ping erst mal etwas länger dauert bis der Port auch aktiv wird, da erst mal ein (BPDU)-Loop-Test statt findet.

[maverick3005]

hmmm... für eine LabBeta-Version wird das wohl wenig Sinn machen. Das mache ich gerne wenn die eine Final Version releasen.

Aber was haben die Kernel Module mit der Fehlermeldung beim "push_firmware" genau zu tun?
Das Teil kann das erstellte image ja nicht mehr "parsen" ?

Ja da steht auch: "Wireshark & recovery.exe loggen"...

Möchtest Du noch ein Wireshark log haben ? Ich habe die Box vom Bekannten noch bis zum Wochenende zur Verfügung.

Da ist wohl bei den Rückmeldungen zwischen den Zeilen auch Einiges unter gegangen, was Du jetzt geclosed hast.

Wenn keine Kernel-Module extra benötigt werden, wieso fehlen jetzt auf einmal Module ?
Ich dachte das wird erst mal 1:1 vom Stock Image übernommen und nur ein paar extras vom Freetz dann wie gewohnt
hinzugefügt.

Wo ist da der Zusammenhang, das weder push_firmware, AVM-WebIF oder das FreetzWeb-IF nach dem erstmaligen 7.39 Install
keine weiteren Updates (oder Downgrades!) mehr zulässt ?

[fda77]

Gibt keinen. Die "andere" Patition kann ohne loop nicht gemountet werden (und keine details ausgelesen) - und das Modul gibt es ohne sourcen nicht. Es ist ja eine andere Kernelversion

hmmm... für eine LabBeta-Version wird das wohl wenig Sinn machen. Das mache ich gerne wenn die eine Final Version releasen.

Seh ich nicht so, ist aber deine Sache. In der GPL gibt es für AVM keine Ausnahme

Möchtest Du noch ein Wireshark log haben ? Ich habe die Box vom Bekannten noch bis zum Wochenende zur Verfügung.

Klar, hast du schon eine recovery mit der neuen Methode?

[maverick3005]

AVM liefert die reguläre 7.30 recovery, von dort aus wird dann ueber das AVM WebIF direkt auf die 7.39 upgedated.

Die Recovery ist ja immer im Beta-Zip-File mit drin. Weitere "Differenzen" ergeben sich dann im direkten Vergleich noch
aus dem original "install" shell script aus dem beta-image selber. Da wird jetzt bei der Beta zusätzlich zu den Final-Versionen
nicht nur der urloader sondern auch die Trustzone mit einem binary upgedated.

Bei der 7.30 ist zwar ebenfalls ein tzupdate mit im Image, jedoch wird das nicht im "install" shell script verarbeitet, hier wird
nur der urloader upgedated, bzw. auf aktuelle Version geprüft.

Ich wundere mich lediglich über die ursprüngliche Meldung, das ein 7.30 freetz image noch problemlos vom push_firmware gelesen wird, ein Image für 7.39 allerdings einen "Parsing" Fehler ergibt und aktuell einzig nur genau einmal über das Freetz WebIF geflashed
werden kann, wenn zuvor ein Freetz 7.30 einmal schon drauf war (und dann im media/ftp Bereich die renamten Fit-images natürlich auch zur Verfügung gestellt werden...)

Ich schau mal wg. dem Wireshark-Log. Das mit dem fehlenden Loop für die 2. Bank ist mir jetzt auch klar.

Brauchst Du da nur die initiale Kommunikation nehme ich an ?

[fda77]

Klar, hast du schon eine recovery mit der neuen Methode?

Okay, du hast es nicht kapiert. Das war rhetorisch!!1 Gibt nicht

[maverick3005]

Doch, da es kein recovery für die 7.39+ selber gibt kann ich nur ein wireshark log für die 7.30 machen.

Das Update selber auf die 7.39 erfolgt ja offiziell innerhalb des AVM WebIF in weiterer Folge. Somit "intern" innerhalb einer
laufenden 7.30-Version und den dort drin enthaltenden Originalscripts die sich auch die "update" Scripte aus dem Beta-Image
wohl noch zur Hilfe nehmen. Wie sonst sollte ein Update im AVM-Web IF denn dann ablaufen ?

Somit bleibt weiterhin die Erkenntnis das im Grunde zur Zeit von noch 7.29, wo es überhaupt kein recovery.exe gab,
auch damals wohl niemals ein Wireshark Log vorgelegen hat. DAS kann man jetzt zu Kontrollzwecken aber (endlich) noch nachholen.

Die Chance das bestimmte "Adress-Bereiche" oder was auch immer da "anders" sind, als das was mit der "Versuchsmethode" damals
"geschätzt" wurde ist schon da.

Mehr kann ich da nicht tun. Du möchtest das closen ? Ja dann mach. Mehr als mich da auch bemühen kann ich nicht.

Ich finde es trotzdem Schade, das sonst keinerlei Feedback von anderen Usern als Beitrag dazu kommt :-(

[fda77]

Du hast doch geschrieben dass du es nicht für nötig hälst dich an avm zu wenden

[maverick3005]

Entschuldige bitte, das nicht alle sich seit Jahren mit freetz beschäftigen und aus Ihrer Sicht versuchen auf Ihre Weise etwas beizutragen.

Man kann sich auch ab und zu mit einfacher Logik erst einmal behelfen:

Wenn ich KEIN "neueres" Recovery zur Verfügung habe, jedoch eine AVM WebIF-Version, die in der Lage ist, eine neuere Version fehlerfrei
zu flashen, dann würden entsprechendene "parsing"-Infos ggfs. sich im Image der 7.30 Version auch befinden ?

z.b. das Flashscript was aktuell eingesetzt wird muss ja auch entsprechende Flash-Operationen durchführen und gewisse Werte beinhalten. Damit könnte man ggfs, auch die (fehlerhaften) Werte für das push_firmware erst einmal fixxen.

Zumindet wäre das mein nächster Gedankengang als "dummer" Mitdenker.

[fda77]

Nach deiner unfreundlichen Aktion von vor ein paar Monaten brauchst du von mir gar nichts zu erwarten

[maverick3005]

Ich weiss nicht was oder wer damit gemeint sein soll? Ich fühle mich hier nicht angesprochen, da ich lediglich bei der betreffenden Box
für einen Bekannten seinen kleinen Wunsch zur Beta umsetzen wollte.

Aber für alle anderen Interssierten, damit wir den Thread im Anschluss closen können als erledigt:

Mit freetz erzeugtes FOS 7.30 Image - OK:

./push_firmware 5590_07.30.all_freetz-ng-21278-3def93864_20230220-222041.image

 * Analyzing '5590_07.30.all_freetz-ng-21278-3def93864_20230220-222041.image' ...
 * Product: Fritz_Box_HW272 (FRITZ!Box 5590)
 * Using command: ftp
 * Target host: 192.168.178.1
 * Outgoing IP: 192.168.178.2
 * Flash mode: fit-boot
 * Allowed memory size: 1024 MB
 * Designated linux_fs_start: <other>

 !!! WARNING !!! WARNING !!! WARNING !!! WARNING !!! WARNING !!!
 !!!  THERE IS NO WARRANTY AT ALL !!! USE AT YOUR OWN RISK   !!!

 * Are you sure, that you want to flash this file to the device?
   5590_07.30.all_freetz-ng-21278-3def93864_20230220-222041.image
   Proceed? (y/[n])

---

Das Stock-Image FOS 7.30: OK

./push_firmware FRITZ.Box_5590-07.30.image

 * Analyzing 'FRITZ.Box_5590-07.30.image' ...
 * Product: Fritz_Box_HW272 (FRITZ!Box 5590)
 * Using command: ftp
 * Target host: 192.168.178.1
 * Outgoing IP: 192.168.178.2
 * Flash mode: fit-boot
 * Allowed memory size: 1024 MB
 * Designated linux_fs_start: <other>

 !!! WARNING !!! WARNING !!! WARNING !!! WARNING !!! WARNING !!!
 !!!  THERE IS NO WARRANTY AT ALL !!! USE AT YOUR OWN RISK   !!!

 * Are you sure, that you want to flash this file to the device?
   FRITZ.Box_5590-07.30.image
   Proceed? (y/[n]) n

---

Das original AVM-Image 7.39: ERROR beim Parsing.

./push_firmware FRITZ.Box_5590_Fiber-07.39-102864-LabBETA.image

 * Analyzing 'FRITZ.Box_5590_Fiber-07.39-102864-LabBETA.image' ...
Error: it is not known how to flash a fit-boot image with 'rootfs_ram' method yet.
Error: run a recovery.exe and get a capture by wireguard or tcpdump to add it.
Error: meanwhile install an older firmware and flash this one by the web interface.

---

Und das selbst erzeugte 7.39 Freetz-Image:

./push_firmware 5590_07.39.all-rev102864_labor_freetz-ng-21297-a1ddabda1_20230223-014300.image

 * Analyzing '5590_07.39.all-rev102864_labor_freetz-ng-21297-a1ddabda1_20230223-014300.image' ...
Error: it is not known how to flash a fit-boot image with 'rootfs_ram' method yet.
Error: run a recovery.exe and get a capture by wireguard or tcpdump to add it.
Error: meanwhile install an older firmware and flash this one by the web interface.

Fazit: Es hat absolut nichts mir irgendwelchen fehlenden Kernel-Modulen oder Sourcen zu tun, sondern schlichtweg,
das push_firmware die neueren fit-images mit den derzeiten Werten nicht mehr korrekt parsen kann, somit liegt das Problem
in einem Fixxing von push_firmware.

Bei der aktuellen Datenlage wäre also zumindest ein direkter Vergleich zwischen den beiden AVM-Stock-Images wohl ein guter Weg,
ggfs. Änderungen bei den Start & Endadressen, ggfs. max Image-Size, Ram-Werten. usw. einmal binär zu vergleichen.

Dazu liegen ja beide Stock-Images auch vor.

Das genannte Kernel/Loop-Problem für die bequemere Freetz 2 Bank-Verwaltung ist logisch und eher ein Luxus-Problem in
der BetaPhase ohne weitere Sourcen.

Für die Praxis würde es zumindest reichen, das mit push_firmware sowohl ein original LabBeta, als auch ein aktuell lauffähiges
Freetz-Image auf diesem Wege als sinnvoll nutzbare Lösung erst mal wieder laufen würden.
Somit kann man auf das AVM-WebIF, als auch auf das Freetz WebIF in der BetaPhase erst einmal verzichten. Die vorhandenen
configs bleiben dabei auch erhalten und Rücksetzungen aller Art entfallen ebenso.

Alles Weitere würde sich dann mit entsprechenden Sourcen, sobald diese verfügbar sind, dann auch ergeben.

Somit ist der derzeitige Weg die Beta Version erfolgreich und lauffähig zu flashen dieser:

- Die Box sollte bereits auf FOS 7.30 Stock geflashed sein
- Dann mit push_firmware erstmalig ein erstelltes 7.30 freetz image einspielen
- umgehend im media/ftp Ordner die renamten fit-images hochladen mit ftp oder scp für 7.30 UND 7.39
- Im Anschluss einmal rebooten das für die FOS 7.30 beim nächsten boot der Fiberteil wieder verfügbar ist und der Watchdog nicht auslöst, bzw. keine "Hänger" wg. fehlendem Fiberteil entstehen.
- Dann im Freetz WebIF einmalig das erstellte freetz 7.39 Beta einspielen
und ggfs. 2x im Anchluss rebooten.

Dann ist die freetz LabBeta lauffähig, und rennt bislang absturzfrei mit allen Funktionen.

Unabhängig davon werde ich von der verfügbaren 7.30 recovery.exe noch ein Wireshark-Mitschnitt machen und ablegen und die
Box im Anschluss mit der LabBeta an meinen Bekannten wieder zurückgeben mit dem Hinweis, das wenn er im Livebetrieb dann
doch Probleme bekommt, das er mit seiner recovery.exe wieder auf die bisher genutze FOS 7.30/freetz zurückkehren kann.

Den Hinweis auf ggfs. sporadische Reboots und noch bestehende Probleme bei der WLAN-Verwendung hatte ich bereits weiter gegeben und für WLAN wird ein bestehender AsusWRT weiter verwendet mir dem er immer voll zufrieden war.

[fda77]

Schön dass du mich für so blöd hälst

[maverick3005]

und abschliessend noch die verwertbaren? Wireshark FTP-Zeilen vom 7.30 Recovery:

178	12.484690000	192.168.178.20	192.168.178.1	FTP	59	Request: SYST
180	12.484787000	192.168.178.1	192.168.178.20	FTP	95	Response: 215 AVM EVA Version 1.11985 0x0 0xC6409
181	12.484959000	192.168.178.20	192.168.178.1	FTP	80	Request: SETENV memsize 0x3d540000
183	12.487311000	192.168.178.1	192.168.178.20	FTP	85	Response: 200 SETENV command successful
184	12.487451000	192.168.178.20	192.168.178.1	FTP	175	Request: SETENV kernel_args_tmp "avm_fwupdate mtdram1=0x7d540000,0x80000000 mtdparts_ext=update-image.0:0x2ac0000@0x0(fit-image)"
186	12.487548000	192.168.178.1	192.168.178.20	FTP	85	Response: 200 SETENV command successful
189	12.487784000	192.168.178.1	192.168.178.20	FTP	78	Response: 200 Type set to BINARY
190	12.487926000	192.168.178.20	192.168.178.1	FTP	66	Request: MEDIA SDRAM
192	12.488011000	192.168.178.1	192.168.178.20	FTP	84	Response: 200 Media set to MEDIA_SDRAM
193	12.488148000	192.168.178.20	192.168.178.1	FTP	59	Request: P@SW
195	12.488239000	192.168.178.1	192.168.178.20	FTP	104	Response: 227 Entering Passive Mode (192,168,178,1,30,193)
199	12.503741000	192.168.178.20	192.168.178.1	FTP	81	Request: STOR 0x7d540000 0x80000000
201	12.503815000	192.168.178.1	192.168.178.20	FTP	90	Response: 150 Opening BINARY data connection
33043	20.822813000	192.168.178.1	192.168.178.20	FTP	77	Response: 226 Transfer complete

[fda77]

Überflüssig, das ist die alte methode die bereits funktioniert

[maverick3005]

Uhr hier zum direkten Vergleich noch die Analyse beider Stockimages mit "fitdump.sh":

image.its.730.txt
image.its.739.txt

Dort konnten alle Teile jeweils sauber exportiert & analysiert werden. Somit könnte es wohl ein Offset-Problem im push_firmware
lediglich sein. Auch die jeweiligen "Load-Adressen" sind doch recht unterschiedlich.

730: 

lrwxrwxrwx 1 root root       13 Feb 23 21:51 filesystem.image -> image_010.bin
-rw-r--r-- 1 root root  3390831 Feb 23 21:51 image_001.bin
-rw-r--r-- 1 root root    16258 Feb 23 21:51 image_002.bin
-rw-r--r-- 1 root root 28045312 Feb 23 21:51 image_003.bin
-rw-r--r-- 1 root root  1192166 Feb 23 21:51 image_004.bin
-rw-r--r-- 1 root root     1114 Feb 23 21:51 image_005.bin
-rw-r--r-- 1 root root   991053 Feb 23 21:51 image_006.bin
-rw-r--r-- 1 root root  3343694 Feb 23 21:51 image_007.bin
-rw-r--r-- 1 root root     7130 Feb 23 21:51 image_008.bin
-rw-r--r-- 1 root root     7129 Feb 23 21:51 image_009.bin
-rw-r--r-- 1 root root  7815168 Feb 23 21:51 image_010.bin
-rw-r--r-- 1 root root     7635 Feb 23 21:51 image.its
lrwxrwxrwx 1 root root       13 Feb 23 21:51 kernel.image -> image_007.bin

und 739:

lrwxrwxrwx 1 root root       13 Feb 23 21:50 filesystem.image -> image_010.bin
-rw-r--r-- 1 root root  3480936 Feb 23 21:50 image_001.bin
-rw-r--r-- 1 root root    14703 Feb 23 21:50 image_002.bin
-rw-r--r-- 1 root root 31596544 Feb 23 21:50 image_003.bin
-rw-r--r-- 1 root root  1198920 Feb 23 21:50 image_004.bin
-rw-r--r-- 1 root root     1238 Feb 23 21:50 image_005.bin
-rw-r--r-- 1 root root  1133331 Feb 23 21:50 image_006.bin
-rw-r--r-- 1 root root  3734861 Feb 23 21:50 image_007.bin
-rw-r--r-- 1 root root     7500 Feb 23 21:50 image_008.bin
-rw-r--r-- 1 root root     7498 Feb 23 21:50 image_009.bin
-rw-r--r-- 1 root root  7118848 Feb 23 21:50 image_010.bin
-rw-r--r-- 1 root root     7545 Feb 23 21:50 image.its
lrwxrwxrwx 1 root root       13 Feb 23 21:50 kernel.image -> image_007.bin

Das Format hat sich zumindest nicht geändert.

[maverick3005]

Das fällt zumindest sofort auf zwischen beiden Teilen:

730:

       qcaarmv8_HW272_squashFS_filesystem {
            description = "squashFS for qcaarmv8_HW272";
            #address-cells = <0x00000001>;
            avm,data-align = <0x00001000>;
            data = /incbin/("image_003.bin"); // size: 28045312, offset=0x003400e0
            type = "filesystem";
            compression = "none";
            load = <0x43000000>;
            avm,kernel-args = "mtdram=ram-filesystem,0x43000000,0x44b00000 mtdparts_ext=ram-filesystem:28045312@0x0(rootfs_ram)";
            hash_0 {
                algo = "crc32";
                value = <0x5605953b>;
            };
        };

739:

       qcaarmv8_HW272_squashFS_filesystem {
            description = "squashFS for qcaarmv8_HW272";
            avm,image-version = <0x00000001>;
            #address-cells = <0x00000001>;
            avm,data-align = <0x00001000>;
            data = /incbin/("image_003.bin"); // size: 31596544, offset=0x00355abc
            type = "filesystem";
            compression = "none";
            load = <0x43000000>;
            avm,kernel-args = "mtdram=rootfs_ram,0x43000000,0x44f00000";
            hash_0 {
                algo = "crc32";
                value = <0xc73c390e>;
            };
        };

...die lieben kernel-argparameter...

[fda77]

Erinnerst du dich an den screenshot mit den ganzen roten pfeilen in einem deiner ganzen anderen issues? Dort bist du nun wieder