7530AX: push_firmware & mount/Busybox Problem

[freetz-ng-mod]

Hi, Leute ich habe nun ca 5H versucht eine 7530AX zu freetzen. Was mir aber absolut nicht gelingt. Ich habe alles versucht.
-cmd ncftp -mf -ram 512 -lfs 1
-cmd ncftp -mf -ram 512 -lfs 0
-cmd ncftp -mf -ram 512
-cmd ncftp -mf
-cmd ncftp -ram 512 -lfs 1
-map 0x20000000
Und so weiter.
Hat hier noch jemand eine Idee. Ach ja ich habe die Box bestimmt schon 10 Mal mit FRITZ.Box_7530_AX-07.29-recover.exe recoverd. die Orginal FW über die AVM Seite auch schon geuppt. Eingerichtet ist sie auch schon.

Oder liegt es daran,

fitimg-0.7.1

• Fixed: 5590 freetz names: filesystem.image = ARM, filesystem2 = PRX, filesystem3 = Boot, etc
• Added: Extract mode only appends a .fit filename extension if the -i option is passed.
• Fixed: Bumped the (C) date (was still 2021).

Denn noch ist fitimg-0.7.0 in freetz drin

[freetz-ng-mod]

Ohne zusatz
Using command: ncftpput
Target host: 192.168.178.1
Outgoing IP: 192.168.178.11
Flash mode: fit-boot
Allowed memory size: 384 MB
Designated linux_fs_start:

MAPSTART=0x00000000
FULLSIZE=0x18000000 (384 MB)
MAPLIMIT=0x18000000
FILESIZE=0x023a0000 (~35 MB)
FREESIZE=0x15c60000 (~348 MB)
MTDSTART=0x15c60000

LibNcFTP 3.2.5 (January 17, 2011) compiled for linux-x86_64-glibc2.27
Uname: Linux|xmg-ultra|5.13.0-10027-tuxedo|#29~20.04.1tux1 SMP Thu Jan 20 10:52:53 UTC 2022|x86_64
Contents of /etc/debian_version:
bullseye/sid
Contents of /etc/issue:
Ubuntu 20.04.3 LTS \n \l
Glibc: 2.31 (stable)
220: ADAM2 FTP Server ready
Connected to 192.168.178.1.
Cmd: USER adam2
331: Password required for adam2
Cmd: PASS xxxxxxxx
230: User adam2 successfully logged in
Logged in to 192.168.178.1 as adam2.
Cmd: MEDIA SDRAM
200: Media set to MEDIA_SDRAM
Cmd: SETENV memsize 0x15c60000
200: SETENV command successful
Cmd: SETENV kernel_args_tmp "avm_fwupdate mtdram1=0x15c60000,0x18000000 mtdparts_ext=update-image.0:0x023a0000@0x0(fit-image)"
200: SETENV command successful
Cmd: TYPE I
200: Type set to BINARY
Cmd: MLST 0x15c60000 0x18000000
502: Command not implemented
Cmd: PASV
227: Entering Passive Mode (192,168,178,1,95,32)
Cmd: STOR 0x15c60000 0x18000000
150: Opening BINARY data connection
/tmp/freetz_tTB/fitboot.flash: ETA: 0:00 32.66/ 35.62 MB 9.46 MB/s 226: Transfer complete
/tmp/freetz_tTB/fitboot.flash: 35.62 MB 1.56 MB/s
Cmd: SETENV linux_fs_start 1
200: SETENV command successful
Cmd: QUIT
221: Thank you for using the FTP service on ADAM2
Cmd: QUIT
221: Goodbye.

Mit -mf
Using command: ncftpput
Target host: 192.168.178.1
Outgoing IP: 192.168.178.11
Flash mode: fit-boot
Allowed memory size: 384 MB
Designated linux_fs_start:

MAPSTART=0x00000000
FULLSIZE=0x18000000 (384 MB)
MAPLIMIT=0x18000000
FILESIZE=0x023a0000 (~35 MB)
FREESIZE=0x15c60000 (~348 MB)
MTDSTART=0x15c60000

LibNcFTP 3.2.5 (January 17, 2011) compiled for linux-x86_64-glibc2.27
Uname: Linux|xmg-ultra|5.13.0-10027-tuxedo|#29~20.04.1tux1 SMP Thu Jan 20 10:52:53 UTC 2022|x86_64
Contents of /etc/debian_version:
bullseye/sid
Contents of /etc/issue:
Ubuntu 20.04.3 LTS \n \l
Glibc: 2.31 (stable)
220: ADAM2 FTP Server ready
Connected to 192.168.178.1.
Cmd: USER adam2
331: Password required for adam2
Cmd: PASS xxxxxxxx
230: User adam2 successfully logged in
Logged in to 192.168.178.1 as adam2.
Cmd: MEDIA SDRAM
200: Media set to MEDIA_SDRAM
Cmd: SETENV memsize 0x15c60000
200: SETENV command successful
Cmd: SETENV kernel_args_tmp "avm_fwupdate mtdram1=0x15c60000,0x18000000 mtdparts_ext=update-image.0:0x023a0000@0x0(fit-image)"
200: SETENV command successful
Cmd: TYPE I
200: Type set to BINARY
Cmd: MLST 0x15c60000 0x18000000
502: Command not implemented
Cmd: PASV
227: Entering Passive Mode (192,168,178,1,95,32)
Cmd: STOR 0x15c60000 0x18000000
150: Opening BINARY data connection
/tmp/freetz_vUx/fitboot.flash: ETA: 0:01 28.19/ 35.62 MB 9.48 MB/s 226: Transfer complete
/tmp/freetz_vUx/fitboot.flash: 35.62 MB 1.56 MB/s
Cmd: SETENV linux_fs_start 0
200: SETENV command successful
Cmd: QUIT
221: Thank you for using the FTP service on ADAM2
Cmd: QUIT
221: Goodbye.

mit -ram 512
Using command: ncftpput
Target host: 192.168.178.1
Outgoing IP: 192.168.178.11
Flash mode: fit-boot
Allowed memory size: 512 MB
Designated linux_fs_start:

MAPSTART=0x00000000
FULLSIZE=0x20000000 (512 MB)
MAPLIMIT=0x20000000
FILESIZE=0x023a0000 (~35 MB)
FREESIZE=0x1dc60000 (~476 MB)
MTDSTART=0x1dc60000

LibNcFTP 3.2.5 (January 17, 2011) compiled for linux-x86_64-glibc2.27
Uname: Linux|xmg-ultra|5.13.0-10027-tuxedo|#29~20.04.1tux1 SMP Thu Jan 20 10:52:53 UTC 2022|x86_64
Contents of /etc/debian_version:
bullseye/sid
Contents of /etc/issue:
Ubuntu 20.04.3 LTS \n \l
Glibc: 2.31 (stable)
220: ADAM2 FTP Server ready
Connected to 192.168.178.1.
Cmd: USER adam2
331: Password required for adam2
Cmd: PASS xxxxxxxx
230: User adam2 successfully logged in
Logged in to 192.168.178.1 as adam2.
Cmd: MEDIA SDRAM
200: Media set to MEDIA_SDRAM
Cmd: SETENV memsize 0x1dc60000
200: SETENV command successful
Cmd: SETENV kernel_args_tmp "avm_fwupdate mtdram1=0x1dc60000,0x20000000 mtdparts_ext=update-image.0:0x023a0000@0x0(fit-image)"
200: SETENV command successful
Cmd: TYPE I
200: Type set to BINARY
Cmd: MLST 0x1dc60000 0x20000000
502: Command not implemented
Cmd: PASV
227: Entering Passive Mode (192,168,178,1,95,32)
Cmd: STOR 0x1dc60000 0x20000000
150: Opening BINARY data connection
/tmp/freetz_97I/fitboot.flash: ETA: 0:00 31.12/ 35.62 MB 9.49 MB/s 226: Transfer complete
/tmp/freetz_97I/fitboot.flash: 35.62 MB 1.56 MB/s
Cmd: SETENV linux_fs_start 1
200: SETENV command successful
Cmd: QUIT
221: Thank you for using the FTP service on ADAM2
Cmd: QUIT
221: Goodbye.

mit -ram 512 -mf
Using command: ncftpput
Target host: 192.168.178.1
Outgoing IP: 192.168.178.11
Flash mode: fit-boot
Allowed memory size: 512 MB
Designated linux_fs_start:

MAPSTART=0x00000000
FULLSIZE=0x20000000 (512 MB)
MAPLIMIT=0x20000000
FILESIZE=0x023a0000 (~35 MB)
FREESIZE=0x1dc60000 (~476 MB)
MTDSTART=0x1dc60000

LibNcFTP 3.2.5 (January 17, 2011) compiled for linux-x86_64-glibc2.27
Uname: Linux|xmg-ultra|5.13.0-10027-tuxedo|#29~20.04.1tux1 SMP Thu Jan 20 10:52:53 UTC 2022|x86_64
Contents of /etc/debian_version:
bullseye/sid
Contents of /etc/issue:
Ubuntu 20.04.3 LTS \n \l
Glibc: 2.31 (stable)
220: ADAM2 FTP Server ready
Connected to 192.168.178.1.
Cmd: USER adam2
331: Password required for adam2
Cmd: PASS xxxxxxxx
230: User adam2 successfully logged in
Logged in to 192.168.178.1 as adam2.
Cmd: MEDIA SDRAM
200: Media set to MEDIA_SDRAM
Cmd: SETENV memsize 0x1dc60000
200: SETENV command successful
Cmd: SETENV kernel_args_tmp "avm_fwupdate mtdram1=0x1dc60000,0x20000000 mtdparts_ext=update-image.0:0x023a0000@0x0(fit-image)"
200: SETENV command successful
Cmd: TYPE I
200: Type set to BINARY
Cmd: MLST 0x1dc60000 0x20000000
502: Command not implemented
Cmd: PASV
227: Entering Passive Mode (192,168,178,1,95,32)
Cmd: STOR 0x1dc60000 0x20000000
150: Opening BINARY data connection
/tmp/freetz_vNI/fitboot.flash: ETA: 0:00 35.00/ 35.62 MB 9.48 MB/s 226: Transfer complete
/tmp/freetz_vNI/fitboot.flash: 35.62 MB 1.56 MB/s
Cmd: SETENV linux_fs_start 0
200: SETENV command successful
Cmd: QUIT
221: Thank you for using the FTP service on ADAM2
Cmd: QUIT
221: Goodbye.

-ram 512 -map 0x20000000
Using command: ncftpput
Target host: 192.168.178.1
Outgoing IP: 192.168.178.11
Flash mode: fit-boot
Allowed memory size: 512 MB
Designated linux_fs_start:

MAPSTART=0x20000000
FULLSIZE=0x20000000 (512 MB)
MAPLIMIT=0x40000000
FILESIZE=0x023a0000 (~35 MB)
FREESIZE=0x1dc60000 (~476 MB)
MTDSTART=0x3dc60000

LibNcFTP 3.2.5 (January 17, 2011) compiled for linux-x86_64-glibc2.27
Uname: Linux|xmg-ultra|5.13.0-10027-tuxedo|#29~20.04.1tux1 SMP Thu Jan 20 10:52:53 UTC 2022|x86_64
Contents of /etc/debian_version:
bullseye/sid
Contents of /etc/issue:
Ubuntu 20.04.3 LTS \n \l
Glibc: 2.31 (stable)
220: ADAM2 FTP Server ready
Connected to 192.168.178.1.
Cmd: USER adam2
331: Password required for adam2
Cmd: PASS xxxxxxxx
230: User adam2 successfully logged in
Logged in to 192.168.178.1 as adam2.
Cmd: MEDIA SDRAM
200: Media set to MEDIA_SDRAM
Cmd: SETENV memsize 0x1dc60000
200: SETENV command successful
Cmd: SETENV kernel_args_tmp "avm_fwupdate mtdram1=0x3dc60000,0x40000000 mtdparts_ext=update-image.0:0x023a0000@0x0(fit-image)"
200: SETENV command successful
Cmd: TYPE I
200: Type set to BINARY
Cmd: MLST 0x3dc60000 0x40000000
502: Command not implemented
Cmd: PASV
227: Entering Passive Mode (192,168,178,1,95,32)
Cmd: STOR 0x3dc60000 0x40000000
150: Opening BINARY data connection
/tmp/freetz_jQj/fitboot.flash: ETA: 397:25 0.12/ 35.62 MB 1.52 kB/s =Starting abort sequence.
/tmp/freetz_jQj/fitboot.flash: ETA: 397:25 0.12/ 35.62 MB 1.52 kB/s =Cmd: ABOR
^CNo response received to abort request yet; closing data connection.
^C
aborted

[freetz-ng-mod]

Könnte mir wer das von hier
https://boxmatrix.info/wiki/FIT-Image#EVA-Upload
In die push_firmware einbauen. So das ich das nochmal versuchen kann die 7530AX zu freetzen

[fda77]

Sollte jetzt ohne Parameter flashbar sein. Wenn du welche angibst müssen es die richtigen sein

[freetz-ng-mod]

Mit ncftp geht es nicht

LibNcFTP 3.2.5 (January 17, 2011) compiled for linux-x86_64-glibc2.27
Uname: Linux|xmg-ultra|5.13.0-10027-tuxedo|#29~20.04.1tux1 SMP Thu Jan 20 10:52:53 UTC 2022|x86_64
Contents of /etc/debian_version:
bullseye/sid
Contents of /etc/issue:
Ubuntu 20.04.3 LTS \n \l
Glibc: 2.31 (stable)
Could not connect to 192.168.178.1 -- try again later: Connection timed out.
Retry Number: 1
Could not connect to 192.168.178.1: No route to host.
Cannot recover from miscellaneous open error -118.
ncftpput: cannot open 192.168.178.1: could not connect to remote host.

./push_firmware 7530AX_07.29.all_freetz-ng-18944MO-ee0d4487f.image -cmd ftp

• Analyzing '7530AX_07.29.all_freetz-ng-18944MO-ee0d4487f.image' ...
• Product: Fritz_Box_HW256 (FRITZ!Box 7530 AX)
• Using command: ftp
• Target host: 192.168.178.1
• Outgoing IP: 192.168.178.50
• Flash mode: fit-boot
• Allowed memory size: 512 MB
• Designated linux_fs_start:

!!! 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?
  7530AX_07.29.all_freetz-ng-18944MO-ee0d4487f.image
  Proceed? (y/[n]) y

• You should now reboot your box (192.168.178.1). Waiting for shut down.
  Switch off, if reboot is not detected because it happens too quickly.
  Some newer bootloader versions allow to flash on power-cycle only.
  ..................

• MAPSTART=0x00000000

• FULLSIZE=0x20000000 (512 MB)

• MAPLIMIT=0x20000000

• FILESIZE=0x023b0000 (~35 MB)

• FREESIZE=0x1dc50000 (~476 MB)

• MTDSTART=0x1dc50000

• No reply from box, assuming switch-off or restart. Trying to re-detect box.
  Waiting .....ping: connect: Das Netzwerk ist nicht erreichbar
  .. found!

• Detected linux_fs_start: '0'

• Designated linux_fs_start: 1

• No reply from box, assuming switch-off or restart. Trying to re-detect box.
  Waiting ........ping: connect: Das Netzwerk ist nicht erreichbar
  .. found!

• Box is back up again, initiating transfer.

Debugging on (debug=1).
---> TYPE I
---> MEDIA SDRAM
---> SETENV memsize 0x1dc50000
---> SETENV kernel_args_tmp avm_fwupdate mtdram1=0x1dc50000,0x20000000 mtdparts_ext=update-image.0:0x023b0000@0x0(fit-image)
Syntax error: Invalid number of parameters
ftp: setsockopt (ignored): Permission denied
---> PASV
---> STOR 0x1dc50000 0x20000000
---> SETENV linux_fs_start 1
---> QUIT

done

Nach dem Hochfahren bootet sie einfach neu.
Und kein Freetz drauf
also noch mal
./push_firmware 7530AX_07.29.all_freetz-ng-18944MO-ee0d4487f.image -cmd ftp

• Analyzing '7530AX_07.29.all_freetz-ng-18944MO-ee0d4487f.image' ...
• Product: Fritz_Box_HW256 (FRITZ!Box 7530 AX)
• Using command: ftp
• Target host: 192.168.178.1
• Outgoing IP: 192.168.178.50
• Flash mode: fit-boot
• Allowed memory size: 512 MB
• Designated linux_fs_start:

!!! 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?
  7530AX_07.29.all_freetz-ng-18944MO-ee0d4487f.image
  Proceed? (y/[n]) y

• You should now reboot your box (192.168.178.1). Waiting for shut down.
  Switch off, if reboot is not detected because it happens too quickly.
  Some newer bootloader versions allow to flash on power-cycle only.
  ............

• MAPSTART=0x00000000

• FULLSIZE=0x20000000 (512 MB)

• MAPLIMIT=0x20000000

• FILESIZE=0x023b0000 (~35 MB)

• FREESIZE=0x1dc50000 (~476 MB)

• MTDSTART=0x1dc50000

• No reply from box, assuming switch-off or restart. Trying to re-detect box.
  Waiting .....ping: connect: Das Netzwerk ist nicht erreichbar
  .. found!

• Detected linux_fs_start: '1'

• Designated linux_fs_start: 0

• No reply from box, assuming switch-off or restart. Trying to re-detect box.
  Waiting ........ping: connect: Das Netzwerk ist nicht erreichbar
  .ping: connect: Das Netzwerk ist nicht erreichbar
  .. found!

• Box is back up again, initiating transfer.

Debugging on (debug=1).
---> TYPE I
---> MEDIA SDRAM
---> SETENV memsize 0x1dc50000
---> SETENV kernel_args_tmp avm_fwupdate mtdram1=0x1dc50000,0x20000000 mtdparts_ext=update-image.0:0x023b0000@0x0(fit-image)
Syntax error: Invalid number of parameters
ftp: setsockopt (ignored): Permission denied
---> PASV
---> STOR 0x1dc50000 0x20000000
---> SETENV linux_fs_start 0
---> QUIT

done

Nach dem Hochfahren bootet sie einfach neu.
Und kein Freetz drauf
Ich habe das ganze auch mit - mf getestet, das gleiche spiel

[fda77]

Du hast die aktuelle Version des Scriptes von heute verwendet?

[fda77]

Und vergiss am besten das "-m", mittlerweile wir automatisch erkannt welches Format es ist. Eigentlich könnte man den parameter rauswerfen

[fda77]

Ich nochmal... es ist egal welche Version, solang 512mb verwendet werden, was ja oben zu sehen ist. Sollte damit also eigentlch funktionieren. Versuch am besten ein minimales Image ohne irgend was

[freetz-ng-mod]

Ja habe vorher git pull gemacht und ein neues Image gebaut

[fda77]

Die FTP-Befehle von dir sehen gut aus, wie auf https://boxmatrix.info/wiki/FIT-Image#History , flashen sollte funktionieren solange das Image überhaupt startet

[freetz-ng-mod]

Also er flash ja. Fährt dann weiter hoch, und macht dann ein Reboot. Und wie gesagt, kein freetz darauf.

[fda77]

Hm, da kann man so nichts dazu sagen. Es könnte

• ein Fehler im fitimg sein (glaub ich nicht, 6000 lief auch auf anhieb)
• ein Fehler irgendwo in freetz.

Am besten sieht man das mit einer seriellen Console.
Ansonsten kannst du versuch eine ältere avm (ohne freetz) zu flashen, um zu schauen ob das flashen auch wirklich funktioniert. Eigentlich genau wie bei den 6000 Tests

[freetz-ng-mod]

Werde morgen mal den 6000 mit FRITZ.Repeater_6000-07.29-recover.exe und dann noch mal versuchen ihn zu freetzen

[freetz-ng-mod]

Hier mal das was ncftp sagt

LibNcFTP 3.2.5 (January 17, 2011) compiled for linux-x86_64-glibc2.27
Uname: Linux|xmg-ultra|5.13.0-10027-tuxedo|#29~20.04.1tux1 SMP Thu Jan 20 10:52:53 UTC 2022|x86_64
Contents of /etc/debian_version:
bullseye/sid
Contents of /etc/issue:
Ubuntu 20.04.3 LTS \n \l
Glibc: 2.31 (stable)
Could not connect to 192.168.178.1 -- try again later: Connection timed out.
Retry Number: 1
Could not connect to 192.168.178.1: No route to host.
Cannot recover from miscellaneous open error -118.
ncftpput: cannot open 192.168.178.1: could not connect to remote host.

Und hier das mit ftp

Debugging on (debug=1).
---> TYPE I
---> MEDIA SDRAM
---> SETENV memsize 0x1dc50000
---> SETENV kernel_args_tmp avm_fwupdate mtdram1=0x1dc50000,0x20000000 mtdparts_ext=update-image.0:0x023b0000@0x0(fit-image)
Syntax error: Invalid number of parameters
ftp: setsockopt (ignored): Permission denied
---> PASV
---> STOR 0x1dc50000 0x20000000
---> SETENV linux_fs_start 1
---> QUIT

done

Grade noch mal neu aus gecheckt Image gebaut und es nochmal versucht. Das gleiche Spiel flash zuende box fährt weiter hoch und rebootet dann.

EDIT
quote GETENV linux_fs_start
linux_fs_start 1
grade mal getestet

[fda77]

Du hast scheinbar gar keine FTP Verbindung zum Bootloader Could not connect to 192.168.178.1: No route to host. dann wird auch nichts hochgeladen

[freetz-ng-mod]

./push_firmware 6000_07.29.all_freetz-ng-18931MO-945e2861e.image -cmd ncftp -ram 1024 -map 0x40000000

 * MAPSTART=0x40000000
 * FULLSIZE=0x40000000	 (1024 MB)
 * MAPLIMIT=0x80000000
 * FILESIZE=0x01540000	 (~21 MB)
 * FREESIZE=0x3eac0000	 (~1002 MB)
 * MTDSTART=0x7eac0000

flash geht ^

./push_firmware 6000_07.29.all_freetz-ng-18931MO-945e2861e.image -cmd ncftp

 * MAPSTART=0x00000000
 * FULLSIZE=0x40000000	 (1024 MB)
 * MAPLIMIT=0x40000000
 * FILESIZE=0x01540000	 (~21 MB)
 * FREESIZE=0x3eac0000	 (~1002 MB)
 * MTDSTART=0x3eac0000

flash geht nicht ^

grade schnell gehacht FRITZ.Repeater_6000-07.29-recover.exe

[fda77]

Ich glaub du hast da was vertauscht.

1. ram ist eh bei beiden 1Gb, kann man also weglassen
2. MAP ist 0x8... wenn du 0x4... angegeben hast

MAPLIMIT=0x40000000 ist default

[fda77]

Mal was ganz anderes, versucht du ein 6000 Image auf eine 7530ax zu flashen?

[freetz-ng-mod]

So der 6000 ist wieder freetz aber mit

./push_firmware 6000_07.29.all_freetz-ng-18931MO-945e2861e.image -cmd ncftp -ram 1024 -map 0x40000000

ohne -ram 1024 -map 0x40000000 flasht er erst nicht
das geht hier grade nur um 6000

AB hier nun 7530AX
ich glaube, der flasht überhaupt nicht. Weil wenn ich ncftp nutze bricht er ja ab.
Mit ftp sagt er ja, er würde flashen, aber er fährt ja weiter die Box hoch. Die LED blinken auch weiter beim 6000 bleibt die LED ja an

ncftp

LibNcFTP 3.2.5 (January 17, 2011) compiled for linux-x86_64-glibc2.27
Uname: Linux|xmg-ultra|5.13.0-10027-tuxedo|#29~20.04.1tux1 SMP Thu Jan 20 10:52:53 UTC 2022|x86_64
Contents of /etc/debian_version:
  bullseye/sid
Contents of /etc/issue:
  Ubuntu 20.04.3 LTS \n \l
Glibc: 2.31 (stable)
Could not connect to 192.168.178.1 -- try again later: Connection timed out.
Retry Number: 1
Could not connect to 192.168.178.1: No route to host.
Cannot recover from miscellaneous open error -118.
ncftpput: cannot open 192.168.178.1: could not connect to remote host.

ftp

Debugging on (debug=1).
---> TYPE I
---> MEDIA SDRAM
---> SETENV memsize 0x1dc50000
---> SETENV kernel_args_tmp avm_fwupdate mtdram1=0x1dc50000,0x20000000 mtdparts_ext=update-image.0:0x023b0000@0x0(fit-image)
Syntax error: Invalid number of parameters
ftp: setsockopt (ignored): Permission denied
---> PASV
---> STOR 0x1dc50000 0x20000000
---> SETENV linux_fs_start 0
---> QUIT

done

[freetz-ng-mod]

Soll ich wieder was testen wegen, den Patches
363ffac

[fda77]

Ne, das ändert nichts daran. Das ist sicherer (googeln)

[freetz-ng-mod]

So ich habe die 7530AX noch mal neu gepusht mit FW 7.22.

bootslotctl get_fw_version 1
07.29-92446
bootslotctl get_fw_version 0
07.22-85878

Wie man sehen kann sind nun 2 Verschidene Version drauf

time sh fitdump.sh /dev/mtdblock1

/dts-v1/;
// magic:		0xd00dfeed
// totalsize:		0x2307d37 (36732215)
// off_dt_struct:	0x38
// off_dt_strings:	0x2307c08
// off_mem_rsvmap:	0x28
// version:		17
// last_comp_version:	16
// boot_cpuid_phys:	0x0
// size_dt_strings:	0x12f
// size_dt_struct:	0x2307bd0

/ {
    description = "FIT for HW256";
    timestamp = <0x60140631>; // Fri Jan 29 12:57:21 UTC 2021
    avm,gu-version = <0x00014f76>;
    images {
        brcma9TZ_HW256_kernel {
            description = "Kernel for brcma9TZ_HW256";
            avm,variants = [00];
            #address-cells = <0x00000001>;
            data = /incbin/("image_001.bin"); // size: 192275, offset=0x00000140
            type = "kernel";
            arch = "arm";
            os = "linux";
            compression = "lzma";
            load = <0x10800000>;
            entry = <0x10800000>;
            hash_0 {
                algo = "crc32";
                value = <0xf653ffe8>;
            };
        };
fitdump.sh: line 1: can't create : nonexistent directory
        brcma9TZ_HW256_flat_dt_0 {
            description = "Device Tree for brcma9TZ_HW256_0";
            #address-cells = <0x00000001>;
            data = /incbin/("image_002.bin"); // size: 599, offset=0x0002f164
            type = "flat_dt";
            arch = "arm";
            compression = "lzma";
            load = <0x10000000>;
            avm,kernel-args = [00];
            hash_0 {
                algo = "crc32";
                value = <0x2040d9dd>;
            };
        };
fitdump.sh: line 1: can't create : nonexistent directory
        brcma9_HW256_kernel {
            description = "Kernel for brcma9_HW256";
            avm,variants = [00];
            #address-cells = <0x00000001>;
            data = /incbin/("image_003.bin"); // size: 2671511, offset=0x0002f4b4
            type = "kernel";
            arch = "arm";
            os = "linux";
            compression = "lzma";
            load = <0xc0008000>;
            entry = <0xc0008000>;
            hash_0 {
                algo = "crc32";
                value = <0x434de15d>;
            };
            avm,kallsyms {
                avm,endianess = "LE";
                avm,kernel_text_start = <0xc0008000>;
                avm,names = <0xc0520920>;
                avm,token_table = <0xc058c9c0>;
                avm,token_index = <0xc058cd40>;
                avm,num_syms = <0xc0520910>;
                avm,addresses = <0xc04fb9d0>;
                avm,relative_base;
                avm,offsets;
            };
        };
fitdump.sh: line 1: can't create : nonexistent directory
        brcma9_HW256_flat_dt_1 {
            description = "Device Tree for brcma9_HW256_1";
            #address-cells = <0x00000001>;
            data = /incbin/("image_004.bin"); // size: 3822, offset=0x002bb9f4
            type = "flat_dt";
            arch = "arm";
            compression = "lzma";
            load = <0xc07ab000>;
            hash_0 {
                algo = "crc32";
                value = <0xf1bcb28a>;
            };
        };
fitdump.sh: line 1: can't create : nonexistent directory
        brcma9_HW256_flat_dt_0 {
            description = "Device Tree for brcma9_HW256_0";
            #address-cells = <0x00000001>;
            data = /incbin/("image_005.bin"); // size: 3824, offset=0x002bc9c8
            type = "flat_dt";
            arch = "arm";
            compression = "lzma";
            load = <0xc07ab000>;
            hash_0 {
                algo = "crc32";
                value = <0x3c89305f>;
            };
        };
fitdump.sh: line 1: can't create : nonexistent directory
        brcma9_HW256_squashFS_filesystem {
            description = "squashFS for brcma9_HW256";
            #address-cells = <0x00000001>;
            avm,data-align = <0x00001000>;
            data = /incbin/("image_006.bin"); // size: 33857536, offset=0x002bd9b4
            type = "filesystem";
            compression = "none";
            load = <0x19c00000>;
            avm,kernel-args = "mtdram=ram-filesystem,0x19c00000,0x1bd00000 mtdparts_ext=ram-filesystem:33857536@0x0(rootfs_ram)";
            hash_0 {
                algo = "crc32";
                value = <0x82df7fac>;
            };
        };
fitdump.sh: line 1: can't create : nonexistent directory
    };
    configurations {
        brcma9TZ_HW256_config_0 {
            kernel = "brcma9TZ_HW256_kernel";
            fdt = "brcma9TZ_HW256_flat_dt_0";
        };
        brcma9_HW256_config_1 {
            kernel = "brcma9_HW256_kernel";
            fdt = "brcma9_HW256_flat_dt_1";
            squashFS = "brcma9_HW256_squashFS_filesystem";
        };
sed: : No such file or directory
sh: invalid number ''
        brcma9_HW256_config_0 {
            kernel = "brcma9_HW256_kernel";
            fdt = "brcma9_HW256_flat_dt_0";
            squashFS = "brcma9_HW256_squashFS_filesystem";
        };
sed: : No such file or directory
sh: invalid number ''
    };
};

Command exited with non-zero status 1
real 6m 44.72s
user 0m 4.54s
sys 0m 55.24s

rm -r fit-dump/
time sh fitdump.sh /dev/mtdblock4
Da kommt immer noch mist bei raus

time sh fit-findfs.sh /dev/mtdblock1
rootfs_type=squashfs rootfs_offset=2873780 rootfs_size=33857536
real 0m 21.10s
user 0m 3.02s
sys 0m 23.01s

time sh fit-findfs.sh /dev/mtdblock4
Da kommt immer noch mist bei raus

So nun habe ich noch mal ein Update über die AVM seite gemacht

bootslotctl get_fw_version 0
07.22-85878
bootslotctl get_fw_version 1
07.22-85878

wget https://github.com/PeterPawn/YourFritz/raw/fit-tools/fit_tools/fitdump.sh

time sh fitdump.sh /dev/mtdblock4

/dts-v1/;
// magic:		0xd00dfeed
// totalsize:		0x230dd37 (36756791)
// off_dt_struct:	0x38
// off_dt_strings:	0x230dc08
// off_mem_rsvmap:	0x28
// version:		17
// last_comp_version:	16
// boot_cpuid_phys:	0x0
// size_dt_strings:	0x12f
// size_dt_struct:	0x230dbd0

/ {
fitdump.sh: eval: line 2: syntax error: unexpected ")"
fitdump.sh: eval: line 2: syntax error: unexpected ")"
Command exited with non-zero status 1

real 0m 5.73s
user 0m 0.17s
sys 0m 1.26s

time bootmanager debug verbose

Unable to find value of WLAN key (xxxxxxxxxxxxxxxxxxxx xx:xx:xx:xx:xx:xx) in dump file, try again with maca value ().
>>>>>>>>>> debug output of bootmanager script <<<<<<<<<<
system type = IPQ4019
system selector = 1
system is switched = false
device branding = 
device branding is changeable = 
current branding = avm
sh: invalid number ''
inactive system is installed = true
>>>>>>>>>>>>>>>>>>>> running system <<<<<<<<<<<<<<<<<<<<
sh: invalid number ''
active kernel = /dev/mtdblock0
sh: invalid number ''
active filesystem = /dev/mtdblock0
active system version = 256.07.22-85878
active system date = 29.01.2021, 13:56:09 Uhr (epoch: 1611924969)
active system modification date = 26.03.2022, 21:24:04 Uhr (epoch: 1648326244)
active system modification source = Freetz-NG
brandings supported on active system = 1und1 avm avme
branding used by active system = avm (immutable)
>>>>>>>>>>>>>>>>>> alternative system <<<<<<<<<<<<<<<<<<
sh: invalid number ''
inactive kernel = /dev/mtdblock0
sh: invalid number ''
inactive filesystem = /dev/mtdblock0
sh: invalid number ''
sh: invalid number ''
inactive filesystem mounted on /var/tmp/10849_1648326949/alt_root
inactive system version = 256.07.22-85878
inactive system date = 29.01.2021, 13:56:09 Uhr (epoch: 1611924969)
inactive system modification date = 26.03.2022, 21:24:04 Uhr (epoch: 1648326244)
inactive system modification source = Freetz-NG
brandings supported on inactive system = 1und1 avm avme
branding used by inactive system = avm (immutable)
inactive filesystem dismounted

real 0m 4.57s
user 0m 1.47s
sys 0m 2.99s

So nun habe ich die Box noch mal mit -mf gepusht
time sh fit-findfs.sh /dev/mtdblock4
Da kommt immer noch mist bei raus

[PeterPawn]

Auch hier noch einmal ... es gibt NICHTS Neues, was man testen müßte.

Bei den ganzen Aktionen mit dem Flashen habe ich jetzt immer noch nicht verstanden (anhand dessen, was oben steht), woher die Images nun stammen.

Wenn Du mittels bootslotctl etwas "beweisen" willst, mußt Du schon dazu schreiben, welches System eigentlich gerade aktiv ist - das wäre dann bootslotctl get_active.

Schon die Anzeige system type = IPQ4019 sollte ja ein deutliches Zeichen dafür sein, daß dieses Skript so NICHT für die 7530ax gedacht ist und dort auch (noch) nicht funktioniert. Die "Erkennung" für dieses Modell ist da noch gar nicht enthalten - das BRINGT also NICHTS, das jetzt schon auf dieser Box in dieser Form zu testen.

Es wäre sogar denkbar, daß die Box auch mit einem falsch aufgebauten FIT-Image noch booten kann, solange die "Gesamtgröße" stimmt (also ausreichend Daten in den Hauptspeicher kopiert werden), der Kernel gefunden und entpackt werden kann (was vermutlich auch kein Problem ist, denn der steht i.d.R. VOR dem Filesystem in der Image-Datei und für den ändert sich nichts, wenn man das Dateisystem dahinter austauscht) und dann noch die Daten für kernel-args auch so weit passen, daß am Ende das passende SquashFS-Image vom Kernel gemountet werden kann. Es ist also noch kein Beweis für ein KORREKT AUFGEBAUTES Image, wenn die Box damit startet ... insofern bringt es mit dem Test auf der Box auch nicht wirklich etwas, wenn das immer wieder dasselbe Image sein sollte ... und von "neu gebaut" habe ich nichts gelesen, nur von "neu geflasht".

Wenn Du das Image überprüfen willst (also die Datei fit-image), dann mußt Du das dafür auch nicht unbedingt auf die Box flashen lassen ... das fitdump.sh (und auch fit-findfs.sh) sollten genauso auf JEDER beliebigen Maschine (zumindest auf einer, die LE-Byte-Order benutzt, was bei jedem x86-PC der Fall ist und auch bei einem RasPi, etc.) funktionieren - denn genau das war ja die Intention dabei, daß die NICHT (oder nur so weit, wie wirklich notwendig) von einer Plattform abhängig sind.

Wenn Du da also immer wieder dasselbe Image verwenden solltest (ich lese nichts Gegenteiliges), dann bringt auch dieser Test nicht wirklich etwas.

Ich bleibe jedenfalls dabei, daß mein Code zum Zerlegen eines FIT-Images korrekt arbeitet - als "Beweis" dient mir die Tatsache, daß ich ohne weiteres aus der erzeugten image.its-Datei mit dem mkimage-Programm (aus dem u-boot-Projekt) wieder eine 1:1-Kopie der Eingabedatei erzeugen kann - allerdings natürlich (zunächst mal) OHNE den AVM-Header und mit einem neuen Wert im timestamp auf der Ebene der images, was aber "zu erwarten" ist - das ist die jeweilige Uhrzeit der Erstellung des Images und beim Zerlegen gebe ich in der its-Datei auch noch einen Kommentar mit aus, in dem der Wert in ein lesbares Datum umgewandelt wurde.

Aber solange diese "Umwandlungen" funktionieren und dabei das erwartete Ergebnis zustande kommt, IST (zumindest für mich) der genutzte Code korrekt - wenn das dann bei einem anderen Image NICHT funktioniert (und ich habe ja irgendwo GENAU aufgeschlüsselt, wo das bei dem Image, was Du mir mal als mtdblock4-Dump zugeschickt hast, alles nicht plausibel war), dann liegt die Schlußfolgerung nahe, daß dieses Image einen falschen Aufbau hat. Warum das noch nicht automatisch auch dazu führen muß, daß die Box damit gar nicht erst gestartet werden kann, habe ich versucht zu erklären.

Die Zeilen fitdump.sh: line 1: can't create : nonexistent directory kann ich mir im Moment auch nicht richtig erklären ... eigentlich dürfte ohne eine Option -f kein zusätzliches mkdir erfolgen - da schaue ich noch einmal nach.

Die weiteren Tests mit bootmanager waren ohnehin nicht erforderlich ... wie ich an anderer Stelle schon erklärt habe. Obendrein würde eine AKTUELLE Version (die zugegebenermaßen bisher gar nicht verfügbar war im öffentlichen Repo) jetzt auch ihre Versionsnummer als allererstes ausgeben, damit diese Sch***-Raterei, was das nun für eine Version gewesen sein KÖNNTE, endlich ein Ende hat.

# BM_DEBUG_FIT=1 BM_DEBUG_FIT_IMAGE=/var/media/ftp/YourFritz/fit-image.7530 sh /var/media/ftp/YourFritz/bootmanager debug verbose
yf_bootmanager version = 0.8.4-202203201227
>>>>>>>>>> debug output of bootmanager script <<<<<<<<<<
system type = Puma6/7
system selector = 0
system is switched = false
device branding = avm
device branding is changeable = true
current branding = avm
FIT image info loaded from cache file.
inactive slot contains a FIT image = true
>>>>>>>>>>>>>>>>>> alternative system <<<<<<<<<<<<<<<<<<
inactive slot = /var/media/ftp/YourFritz/fit-image.7530
rootfs_type = squashfs
rootfs_offset = 2874080 (0x2bdae0)
rootfs_size = 32849920 (0x1f54000)

Und NEIN, auch das ist nichts zum "Nachmachen" ... das ist nur ein Beispiel, wo ich auf der 6490 (als LE-Maschine) den Teil des Codes, der SquashFS-Images mounten soll, speziell für FIT-Images und mit einer Kopie der fit-image aus der AVM-Firmware, teste - und damit bin ich NOCH NICHT FERTIG.

Bei allem Verständnis für "Ungeduld" ... bitte erst mal nichts mehr testen (bzw. die Ergebnisse nicht mehr zeigen), bis ich wieder darum bitte.

Solche Ausgaben wie sh: invalid number können von allem möglichen stammen - bis hin zum Fehlen der 64-Bit-Arithmetik, wie ich gerade auf älterer Firmware von AVM festgestellt habe. Das bringt mich also auch bei der Fehlersuche nicht wirklich weiter (der einzige Fehler, den ich derzeit NICHT erklären kann, ist das mit dem mkdir oben) und kostet nur zusätzlich Zeit, weil ich auch bei den genauen "Rahmenbedingungen" häufig nur raten kann - siehe die Frage oben, was das denn nun für ein Image mit der 07.22-85758 sein mag und ob dafür nicht "schon klar" war, daß dessen Aufbau einfach nicht stimmt. Wenn Du mir dasselbe Problem mit einer Image-Datei von AVM zeigst (ich hatte schon betont, daß ich deren Aufbau für "maßgeblich" halte), dann denke ich noch mal darüber nach, wo meine Implementierung ggf. fehlerhaft arbeitet - ansonsten ist das NICHT mein Tisch.

[PeterPawn]

@freetz-ng-mod:
Bist Du sicher, daß die Ausgaben am Beginn hier: #483 (comment) auch tatsächlich mit der Version von fitdump.sh erzeugt wurden, die ich gestern (korrigiert) hier: PeterPawn/YourFritz@1e19224 eingecheckt hatte?

Wenn ich in den Code schaue, sieht das (am Ende eines Nodes in der FDT-Struktur) so aus, als würde es beim Schreiben in der "Verzeichnis" der Node-Namen zum Problem kommen - das kann aber eigentlich nur dann passieren, wenn diese Zeile: https://github.com/PeterPawn/YourFritz/blob/1e1922434218ff6d63830efeefb5a0c19533cf16/fit_tools/fitdump.sh#L670 nicht funktioniert und das dürfte eigentlich auch nicht passieren, denn selbst wenn readlink und realpath fehlen sollten, mache ich das noch "zu Fuß" rein mit POSIX-Kommandos.

Wenn das tatsächlich so sein sollte, setze mal bitte in die Zeile vor der oben verlinkten ein set -x und in der Zeile danach dann ein set +x - damit wird die Debug-Protokollierung nur für diesen Aufruf eingeschaltet und in der Ausgabe kann man dann sehen, was da nicht wie erwartet funktioniert.

OK, gefunden ... dieses "f*cking" realpath in der BusyBox arbeitet wieder anders, als das aus den "coreutils":

vidar:/home/GitHub/YourFritz/fit_tools $ realpath --version
realpath (GNU coreutils) 8.32
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Padraig Brady.
vidar:/home/GitHub/YourFritz/fit_tools $ realpath .non-existent-file
/home/GitHub/YourFritz/fit_tools/.non-existent-file
vidar:/home/GitHub/YourFritz/fit_tools $ busybox realpath .non-existent-file
realpath: .non-existent-file: No such file or directory
vidar:/home/GitHub/YourFritz/fit_tools $

Ich krieg' die Krise ...

EDIT: Erledigt: PeterPawn/YourFritz@82f55ed

[freetz-ng-mod]

Sorry , ich teste nur noch das, was ihr nun sagt.

[PeterPawn]

Nicht falsch verstehen ... es kostet halt auch immer (zusätzliche) Zeit, wenn man sich mit Problemen befassen soll/muß, die man längst gelöst hat und wo die Änderung nur noch nicht öffentlich gemacht wurde (bzw. "freigegeben").

Der Witz bei der Sache ist eigentlich der, daß ich mittlerweile wieder so weit wäre (ich habe den halben Tag meine Änderungen getestet), eine neue Version des bootmanager-Skripts testen zu lassen - vorerst aber nur mit dem Aufruf bootmanager debug verbose (auch wenn's hier wieder der falsche Thread ist). Und das macht auch nur dann Sinn, wenn geklärt ist, ob der innere Aufbau der zu untersuchenden Images auch korrekt ist - ansonsten suche ich am Ende Fehler im Skript, die an falschen Daten liegen.

Mal sehen, wie ich lustig bin - vielleicht schreibe ich nachher noch in dieser Issue (PeterPawn/YourFritz#45) eine "Anleitung", wie so ein Test konkret aussehen sollte.

[freetz-ng-mod]

Nur zur Information, mit der FW 7.31 und BB 1.34 auch noch Reboot schleife.

[PeterPawn]

Wenn ich mit dem Boot-Manager fertig bin, schaue ich (per SSH) auch da noch einmal drauf.

Wegen der Unklarheiten beim FR6000 habe ich mir ohnehin mal ein Build-System für diese ARM-Plattformen aufgesetzt, mit dem ich dann mal einen loop.ko-Driver erstellen kann zum Testen. Da fällt dann auch noch eine der BusyBoxen bei ab, die Späne machen. Außerdem kann ich dann noch mal selbst in die Support-Daten schauen, wenn Du in dem einen Slot ein funktionierendes System und in dem anderes eines, was abstürzt, hast - Du mußt dann zwar bei dem Boot-Loop irgendwann abbrechen und auf das funktionierende System umschalten, aber danach kann ich dann noch einmal einen Blick in die Ergebnisse des Absturzes, der zum Reboot geführt hat, werfen.

Zumal das bei diesen Boxen tatsächlich "komplexer" ist, wenn es zu einer Kernel-Panic kommt. Da wird das Protokoll offenbar nicht mehr direkt geschrieben, wie das bei anderen Modellen von einer speziellen Routine im TFFS-Driver erledigt wird - bei der 7530ax wird so ein panic log tatsächlich beim nächsten Start erst (in /etc/boot.d/core/tffs) in das TFFS geschrieben:

## Reset firmware_info to original value
version="$(/etc/version)"
if fw_info=$(grep ^firmware_info "${URLADER_ENV}")
then
echo "$fw_info" | sed "s/\t[^,]\+/\t$version/; s/,\?recovered=[0-9]\+//" > ${URLADER_ENV}
else
echo firmware_info $version > ${URLADER_ENV}
fi
mount -t pstore pstore /sys/fs/pstore
mknod /dev/tffs_panic c $(major_nr tffs) 96
panic_log="/sys/fs/pstore/dmesg-ramoops-0"
if [ -e $panic_log ]; then
echo "Panic log found. Copy it into tffs."
cat /proc/avm/reboot/info $panic_log > /dev/tffs_panic
rm $panic_log
fi

zumindest offenbar bei einigen "Fehlerarten".

Aber das ist noch Zukunftsmusik ... zumal ich mittlerweile aufgegeben habe zu verstehen, was da bisher genau getestet wurde und mit welchen Ergebnisse. Das machen wir dann (gemeinsam, weil das nur aus der Ferne nicht geht) ggf. noch mal von vorne - aber das MUSS ja auch nicht schlecht sein, wenn man ein Problem dann tatsächlich sauber reproduzieren kann. Denn ursprünglich gab es ja (wenn ich mich richtig erinnere) ein Problem mit dem WLAN - und dann war irgendwo plötzlich wieder etwas vom untrustedd zu lesen ... die haben aber irgendwo ziemlich unterschiedliche Aufgaben, denn der untrustedd dürfte dazu dienen, die Daten von "Subsystemen" einzusammeln, vielleicht auch noch von "Mesh"-Teilnehmern (so richtig klar ist das bisher nicht .- aber AVM ist der Service offenbar so wichtig, daß man ihn mit einem Watchdog überwacht).

[fda77]

Irgendwie hatte ich auch in Erinnerung dass die aktuelle Busybox version funktioniert, wenn man untrustedd lahmlegt...

[freetz-ng-mod]

@fda77 Das war bei der 5530, hier geht es nicht. Nur mit BB 1.27 lauft es

[fda77]

Sorry, hab den Überblick verloren :D

[freetz-ng-mod]

In der Inhaus Version wird der Kernel 4.19.183 benutzt. In der normalen Version ist 4.1.52. Vielleicht geht damit dann später auch BB 1.34.

[fda77]

Hier hatte noch jemand ein issue aufgemacht: https://github.com/Freetz-NG/freetz-ng/issues/536
Vielleicht kannst du das auch mal ausprobieren
Ich geh nicht davon aus dass die kernelversion was ändert, aber man weiss ja nie
Am besten fragst du avm gleich nach den qullen für den neuen kernel (ich glaub keine andere box nutzt diese version)

[freetz-ng-mod]

Ich habe da alles getestet, was mir eingefallen ist. Das einzige, das hilft, ist BB 1.27

[fda77]

Schau mal ins issue

[freetz-ng-mod]

Der Kernel ist

Die 7530AX rebootet alle 2 min mit der FW 7.39, mit BB 1.27
Mit BB 1.34 auch
Test mit FREETZ_REMOVE_UNTRUSTEDD und BB 1.34 auch
Test mit FREETZ_REMOVE_UNTRUSTEDD und BB 1.27 auch
Test mit FREETZ_PATCH_DISABLE_AVM_WATCHDOG und BB 1.27

Da bleibt sie Online, aber WLAN TOT und WLAN LED Disco
Denn Test mit BB 1.34 und FREETZ_PATCH_DISABLE_AVM_WATCHDOG spare ich mir dann
So Test noch mal mit BB 1.34 aber ich gebe nun in der Konsole das ein echo disable > /dev/watchdog
Box bleibt online und WLAN geht

EDIT
SO Test mit BB 1.27 aber ich gebe nun in der Konsole das ein echo disable > /dev/watchdog
Box bleibt online und WLAN geht

EDIT 2
Noch ein Test mit FW 7.31 und BB 1.34 reboote alle 2 min
Test mit FW 7.31 und echo disable > /dev/watchdog

[fda77]

Hattest du https://github.com/Freetz-NG/freetz-ng/issues/536 angeschaut? Dort steht was zu "wl*" (wlan?) devices in den logs

[steadfasterX]

die issues wurde ja abgeschaltet. was dann solche querverweise natürlich ins leere führen lassen. ich verstehe die Gründe aber ... naja egal was genau stand denn da? ich habe soeben versucht zu freetzen aber dachte ich bin zu doof. flash erfolgreich aber bootet einfach nur fritz os:

 * Analyzing 'images/7530AX_07.31.all_freetz-ng-21397-eae5d2245-ng23030_20230320-162204.image' ...                                            de -Idrivers/char/avm_net_trace/include   -I
 * Product: Fritz_Box_HW256 (FRITZ!Box 7530 AX)
 * Using command: ftp
 * Target host: 192.168.178.1
 * Outgoing IP: 192.168.178.22
 * Flash mode: fit-boot
 * Allowed memory size: 512 MB
 * Designated linux_fs_start: <other>
 * File: images/7530AX_07.31.all_freetz-ng-21397-eae5d2245-ng23030_20230320-162204.image

 * MAPSTART=0x00000000
 * FULLSIZE=0x20000000	(512 MB)
 * MAPLIMIT=0x20000000
 * FILESIZE=0x024fd61b	(~36 MB)
 * ALIBYTES=0x000029e5	(~10 kB)
 * FREESIZE=0x1db00000	(~475 MB)
 * MTDSTART=0x1db00000

 * No reply from box, assuming switch-off or restart. Trying to re-detect box.
   Waiting ................ping: connect: Das Netzwerk ist nicht erreichbar
.ping: connect: Das Netzwerk ist nicht erreichbar
.ping: connect: Das Netzwerk ist nicht erreichbar
.. found!

 * Box is back up again, initiating transfer.

Debugging on (debug=1).
---> TYPE I
---> MEDIA SDRAM
---> SETENV memsize 0x1db00000
---> SETENV kernel_args_tmp "avm_fwupdate mtdram1=0x1db00000,0x20000000 mtdparts_ext=update-image.0:0x24fd61b@0x0(fit-image)"
---> PASV
---> STOR 0x1db00000 0x20000000
---> QUIT

done

[fda77]

Dass man alte nicht mehr lesen kann ist blöd, ich hab auf selbst schliessende issues umgestellt

[freetz-ng-mod]

Durchgelesen ja. Aber noch nicht dazu gekommen es zu teste. werde es heute oder morgen mal testen.