[Erledigt] Alle FIT Images, die eine tzupdate enthalten Rebooten nicht mehr richtig

Master SaMMy

Aktives Mitglied
Mitglied seit
20 Apr 2016
Beiträge
1,084
Punkte für Reaktionen
217
Punkte
63
Hi Leute, mir ist dieses Problem schon vor ein paar Tagen aufgefallen. Das mein Repeater 6000 der mit freetz schon eine ganze Zeit ohne Probleme lief und auf einmal Probleme macht nach dem Updaten auf 6000-07.39-102643. Da habe ich mir so erst mal nichts bei gedacht. Da die 7530 AX(07.51-102589-Inhaus) immer noch ohne Probleme läuft. So nun gibt es ja seit heute FRITZ.Repeater_1200_AX-07.39-102534-Inhaus. So die ich dann auch Freetzen wollte und da habe ich auf einmal das gleiche Problem, das sie danach nicht mehr richtig rebootet.

Daher habe ich mir mal angeschaut, was dazuführt dass die 2 Repeater nicht mehr richtig rebooten. Daher habe ich die beiden images mal entpackt. Beide haben tzupdate Datei dabei. Die 7530AX hate sowas bis jetzt nicht dabei. Daher gehe ich davon aus, dass das Freetzen der FIT Boxen überarbeitet werden muss.
 
Hallo. Beschreib mal was rebootet nicht richtig bewirkt.

tzupdate ist nux neues, neu ist nur das Maple modell.

Ich schau mal später was sich da sonst noch ungewöhnliches tat...
 
LED Ist eine Disco. Man kommt nicht mehr ins AVM GUI (freetz natürlich auch nicht)
Beim 6000 ist der oberer LAN Port nur noch 10Mbit der, untere lauft mit 2,5 Gbit. Wenn beim 6000 es doch mal geschafft wird das WLAN angeht, stürzt die Box gleich ab.

Es hilft dann nur noch recover.exe
 
uhh, also geht aber schwer malad.
versuch mal ob du ein zeitfenster hinkriegst supportdata zu ziehen und mail die.
und falls du eine serielle konsole hast....
 
Beim 1200AX habe ich das hier gemacht
Ich komme nicht auf die Support Seite. Da steht was mit URL nicht gefunden oder so
 
villeicht hielfts es so zu machen, wenns geht:
da wäre es schon nützlich, wenn Du es mal mit einem Update per signiertem Image über das AVM-GUI probierst (dann sieht man wenigstens etwas in der Protokolldatei, die dabei von firmwarecfg nach /var/tmp geschrieben wird).
 
Hallo zusammen,
kann sein, dass ich hier mit einem ähnlichen Problem zu kämpfen habe? Wäre auch ein Repeater (1750E) mit einer etwas neueren Firmware, die mit FREETZ NG nicht laufen will. Könnt ihr für mich bitte etwas weiter herausholen, wofür dieses tzupdate gut ist, wan es einsetzt usw. Denn in meinem Fall kriege ich das Image schon irgendwie auf den Repeater mit push_firmware "reingeprügelt" (Details dazu s. in meinem Thread), bloß der bootet danach gar nicht. Netzwerkschnittstelle wird gar nicht aktiv. NO FREETZ Image läuft aber (also schon durch packen-entpacken von FREETZ NG durchgejagt, aber ohne Veränderungen).
Ich will hier nur ausgrenzen bzw. bestätigen, ob es sich in meinem Falle vielleicht auch um ähnliches Phänomen handelt.

Danke!
 
Du hast recht, beim 1750E ist es genau so. Repeater fährt nur bis zu einem bestimmten Punkt hoch. Power LED leuchtet dauerhaft, WLAN blinkt sich tu Tode. Die Signalstecken LEDs bleiben aus. LAN PORT TOT.

In der FW ist auch ein urladerupdate drin.

Firmware extrahieren, Update vorbereiten
Einige der AVM-Dienste anhalten, Teil 1 (prepare_fwupgrade start_from_internet) ...
Code:
cat: can't open '/var/run/delayed_reboot.pid': No such file or directory
rm: can't remove '/var/run/delayed_reboot.pid': No such file or directory
rmmod: can't unload module 'userman_mod': No such file or directory
rmmod: can't unload module 'isdn_fbox_fon3': No such file or directory
killall: checkservices: no process killed
ERLEDIGT
Firmware-Archiv extrahieren ...
Code:
./var/
./var/install
./var/version
./var/chksum
./var/urladerupdate
./var/tmp/
./var/tmp/filesystem.image
./var/tmp/kernel.image
./var/tmp/System.map.lzma
./var/.config
./var/.packages
./var/flash_update_4.4.ko
./var/content
./var/info.txt
./var/signature
ERLEDIGT
AVM-Dienste anhalten, Teil 2 (prepare_fwupgrade end) ...
Code:
cat: can't open '/var/run/delayed_reboot.pid': No such file or directory
rm: can't remove '/var/run/delayed_reboot.pid': No such file or directory
/etc/ewnw_devfiles.sh: checking /dev files ....
/etc/ewnw_devfiles.sh: /dev/kdsldptrace0 already exists
/etc/ewnw_devfiles.sh: /dev/kdsldptrace1 already exists
/etc/ewnw_devfiles.sh: /dev/knqos already exists
/etc/ewnw_devfiles.sh: /dev/avmtrackd already exists
/etc/ewnw_devfiles.sh: /dev/avmtrackdquery already exists
/etc/ewnw_devfiles.sh: /dev/bridgeflt already exists
/etc/ewnw_devfiles.sh: /dev/krextd already exists
/etc/ewnw_devfiles.sh: /dev/krextd_wlan already exists
/etc/ewnw_devfiles.sh: /dev files checked
ERLEDIGT
Ausführen des Firmware-Installationsskripts /var/install ...
Code:
install: have Kernel 4.4.60 - set kversion '4.4' and FlashUpdateTool '/lib/modules/4.4.60/kernel/drivers/char/flash_update/flash_update.ko'
install: check and install new firmware ...
OEM=avm
ANNEX=Ohne
testing acceptance for device Fritz_Box_HW206 ...
korrekt install type: mips74_16MB_1eth_wlan11ac_repeater_24750
device has installtype mips74_16MB_1eth_wlan11ac_repeater_24750
OK - OEM avm is supported
OK - accept this update for device Fritz_Box_HW206 ...
testing acceptance for device Fritz_Box_HW206 done
curr: 134.07.29  new: xx.07.30
debug: curr: 134.07.29
debug: new: "XX.07.30"
major_currFWver=134
middle_currFWver=7
minor_currFWver=29
middle_newFWver=7
minor_newFWver=30
check Firmware Version: xx.07.30
DEBUG: 7 >= 7
DEBUG: 30 >= 29
Accept Firmware Version: xx.07.30
install: 4.4 check files...
read 0xba1fe83b MACIG 0xc453de23
File already contains the checksum, verifying
[cs_calc_sum] sum 0xba1fe83b
Calculated checksum is BA1FE83B
Saved checksum is BA1FE83B
Checksum validation successful!
chksum for file /var/tmp/kernel.image ok
size for file /var/tmp/kernel.image ok
install: /var/urladerupdate...
install: 4.4 getting mtd to install...
install: -----------------------------------------------------
flash_startadress 520093696
kernel_update_start 520224768
bootloader_size 0x00020000
jffs2_size 0x0
Kernel_without_jffs2_size 15597568
kernel_image_size 15508744
kernel_mtd_size 15597568
Kernel_Start_Add = 520224768
Kernel_End_Addr = 520224768 + 15508744
Kernel_without_jffs2_End_Addr = 520224768 + 15597568
install: -----------------------------------------------------
install: kernel_size=15597568
install: kernel_update_start=520224768
install: kernel_update_len=15597568
install: 4.4 setting files to install...
install: /var/tmp/kernel.image to start(520224768) size(15597568)
set INFO led to blink (modul=7, state=4)
ERLEDIGT – Rückgabewert des Installationsskripts: 1 (INSTALL_SUCCESS_REBOOT)
Von /var/post_install generierter Inhalt:
Code:
#! /bin/sh
echo $0: start
sleep 1
killall run_clock
if ps | grep -v grep | grep -q telefon ; then killall telefon ; fi
if ps | grep -v grep | grep -q telnetd ; then killall telnetd ; fi
echo skip deleting language from env
echo MODE=update > /dev/avm_power
/sbin/avm_watchdog disable
echo still running:
ps
lsmod
sleep 1
echo calling /var/urladerupdate...
/var/urladerupdate
update_parameter=flash_update_file0="/var/tmp/kernel.image,520224768,15597568,crc=1"
echo clear_id 95 >/proc/tffs
echo clear_id 96 >/proc/tffs
echo reboot >/proc/sys/urlader/reboot_status
insmod /lib/modules/4.4.60/kernel/drivers/char/flash_update/flash_update.ko $update_parameter
exit 0
Das Nach-Installationsskript wird beim Neustart ausgeführt.

Das Gerät startet jetzt neu ...

Bei push kommt das hier

Code:
Connected to 192.168.178.1.
220 ADAM2 FTP Server ready
331 Password required for adam2
230 User adam2 successfully logged in
Remote system type is AVM.
Debugging on (debug=1).
---> TYPE I
200 Type set to BINARY
---> MEDIA FLSH
200 Media set to MEDIA_FLASH
local: /tmp/freetz_ePe remote: mtd1
ftp: setsockopt SO_DEBUG (ignored): Keine Berechtigung
---> EPSV
502 Command not implemented
disabling epsv4 for this connection
---> PASV
227 Entering Passive Mode (192,168,178,1,12,17)
---> STOR mtd1
421 Service not available, remote server has closed connection.
Not connected.

done
 
Sind deine Logs denn jetzt von einem 1750E oder von welchem Repeater bzw. Box? Sonst kommen wir durcheinander. Ja, ähnliche Logs von FREETZ NG Firmware Update habe ich bei meinem 1750E auch gesehen. Mit dem push_firmware kann ich dieses Verhalten aber nicht bestätigen. Ja, der 1750E ist schon etwas "zickiger" was push_firmware insbesondere aus FREETZ NG betrifft. Es gibt da diverse Tricks mit externem Netzwerk-Switch usw. Ich kann dir aber kurz erklären, wie ich es unter meinem LINUX MINT Notebook jetzt mache, damit du ihn da in diesem ADAM/EVA einigermaßen "gefangen" bekommst:
1. Zunächst richte dir eine Netzwerk-Konfiguration mit einer festen IP-Adresse ein. Bei MINT sind da mehrere Konfigurationen möglich. Da mein MINT Ubuntu-basiert ist, gehe ich davon aus, dass es auch auf anderen Debian-Ubuntu-Derivaten möglich ist. Schalte dein WLAN aus und stecke dir z.B. einen USB-to-Netzwerk-Adapter rein, da heutige Notebooks oft keine Netzwerkschnittstelle mehr besitzen. Wenn du eine hast, dann hast du Glück. Diese Schnittstelle kriegt dann eine feste IP im 192.168.178.0-Bereich, z.B. 192.168.178.10. Standard-Gateway ist dann 192.168.178.1. Fertig aus.
2. Jetzt mach ein zweites Terminalfenster auf, neben deinem ersten mit push_firmware. Oder starte eben eine zweite ssh-Session, wenn du remote dadrauf zugreifst (VM oder was weiß ich). Tippe dort schon mal "ftp 192.168.178.1", drücke aber noch kein ENTER
3. Jetzt Repeater über Netzwerkkabel mit dem Rechner verbinden. WLAN ist ja bereits aus, Repeater aber noch nicht in die Steckdose stecken.
4. Repeater in die Steckdose stecken. Rechner erkennt das Netzwerk und nimmt hoffentlich deine Konfiguration für 192.168.178.0-Netz dafür. Wenn nicht, dann bitte das berichtigen. Und jetzt ist die Schnelligkeit gefragt...
5. Im zweiten Terminal-Fenster mit dem ftp-Befehl schnell ENTER drücken. Es kommt eine Abfrage nach Benutzer und Passwort. Beides ist adam2
6. Jetzt kann man (und sollte man, glaube ich) die ftp-Session mit "quit" verlassen. Die Box ist jetzt im Bootloader "gefangen"
7. push_firmware starten, den Schritt abwarten, wo push_firmware auf den Reboot der Box wartet. Und ja, das passiert hier leider nicht automatisch
8. Repeater aus der Steckdose ziehen (Netzwerkkabel bleibt angeschlossen), 10 Sekunden abwarten, bis alle Elkos der Stromversorgung entladen sind. Den Repeater wieder einstecken
9. Die Schritte mit "passive mode" und dann "active mode" abwarten. Dauert schon seine Zeit, nicht ungeduldig werden!
10. Am Ende wird es mit "successfull" oder ähnlich quittiert und push_firmware beendet
11. Der Repeater rebootet leider aus der Situation nicht! Das meinte ich unter anderem mit "zickig". Jetzt Stecker wieder ziehen, 10 Sekunde abwarten und wieder einschalten. Die neue Firmware müsste nun drauf sein


Mit diesem "service not available" oder ähnlich hatte ich auch mal. Ich hatte es mir so erklärt, dass meine zweite FTP-Session in dem Moment noch offen war und dass der Bootloader vielleicht keine parallele FTP-Sessions erlaubt. Vergessener WLAN sorgt auch schon mal für unerklärliche Nebeneffekte mit push_firmware. Ja, es kann sein, dass er in passiv noch ans Netzwerk geht, bei active oder wo auch immer sich aber beschließt, über WLAN zu "telefonieren". Darum gehe ich jetzt immer akribisch nach der Anleitung wie oben beschrieben speziell bei meinem 1750E, der sich besonders zickig verhält.

Übrigens zur seriellen Konsole. Habe ich mir auch schon mal überlegt. Vielleicht löte ich mir das Kabel tatsächlich für solche Forschungszwecke an. Habe das schon bei vielen Devices hier gemacht. Ist manchmal echt hilfreich... 1750E ist schon sowieso für Garantie zu alt, habe hier auch zwei davon. Schaue ich mal...
 
Zuletzt bearbeitet:
Ok, lies mal dort, was ich schon alles unternommen habe. Ich schaue mal parallel, wie schnell ich es mit der seriellen Konsole hinkriege.
 
@hermann72pb
Stell dir die TrustZone als viruelle zweite CPU vor auf der ein eigenes OS läuft.
Bei Qualcomm ist das QSEE. Das ist gedacht um eine sicheren Hafen in einem unsicheren OS zu haben und stellt Cryptodienste bereit vom Signaturcheck bis DRM aber auch sichere Interrupts und Watchdogs.

tzupdate enthält das QSEE image.

Das ist etwa wie Android boot. ein onchip primärbootloader PBL startet den onflash secondary bootloader SBL wenn signatur stimmt. Der startet QSEE in der TrustZone und EVA in der normal world, wenn beide siignaturen stimmen.

Die Trustzone hat eigene Rebootfähigkeit und auch nen Watchdog.
Es gibt auch die Möglichkeit signierte befehle von der normal world aus in der secure world zu starten. Das nutzt Android, AVM aber noch nicht
Im AVM Source findet man Hander für Fast-Interrups in und aus der Trustzone.

AVM könnte diese Chain of Trust bis ins Kernel und Rootfs erweitern. Das machen sie bisher nur bei 55xx Fiber, da gibts einen ähnlichen Mechanismus beim BootLinux (5530) und beim FalconLinux (5590). Ein vermuter Sinn wären signierte DeviceTrees für Fiber und sonstige auth sachen...

Ich hab noch kein Testmodell mit FIT und würde gerne mal testen ob dtb blobs gemodded werden können. Ja fitimg hab ich komplett blind geschrieben und es lief out od the box.
 
Zuletzt bearbeitet:
Aber einen uralten WLAN Repeater 1750E mit einer solchen komplizierten Technologie auszustatten? Macht es denn Sinn? Und muss dafür der Bootloader dann auch umgeschrieben werden oder sehe ich es falsch? Bootloader umschreiben beideutet oft, dass man nicht zur alten Firmware ohne Weiteres zurückkehren kann. Würde denn AVM sowas machen?
Irgendwie passt es für mich von der Motivation für AVM nicht. Ich vermute da eher irgendwas deutlich Trivialeres.
 
Ich hab nur die trustzone erklärt. Da die ja schon ewig wenn vorhanden aktualisiert wird widersprach ich ja schon der vermutung des op.

TrustZone und EVA haben gleiche Versionsnnummern im procfs wenn alles stimmt. Wären die unterschiedlich nützt es auch nix dass die unpassende TZ signiert ist und die nebenwurkungen wären chaos.

Aber der 1750e hat einfach ein normales 128K EVA image ohne jedes drumum. Das muss also ganz andere Ursachen haben.
 

vorallem weil dieser wohl mittlerweile EOS ist

1674598751446.png

[Vermutung]
FRITZ.Box_WLAN_Repeater_1750E-07.29-100772-Inhaus.image gab es ja auch, wird wohl in diesem Zuge wohl unumgänglich/notwendig/einfacher gewesen sein für die 7.30
[/Vermutung]
 
Serielle Console an meinem 1750E dran. Ich würde aber ungerne hier die gesamten Boot-Logs für die ganze Welt posten. Beim Diagonal-Schauen habe ich da z.B. meine MAC-Adressen gesehen. Vermutlich noch mehr an privaten Informationen. Entweder schicke ich es dir per PN @hippie2000 oder sag einfach, was du da genau sehen willst. Ich habe jetzt Original 30-ger Version von AVM drauf, die ja auch läuft. Die ist zwar nicht ganz "original", aber so gut wie, weil als NO FREETZ erzeugt. Ich würde die Ausgaben der Konsole zunächst mal damit als Text absichern. Dann haben wir schon eine Variante, wie es läuft, wenn der Repeater bootet.
Übrigens: Serielle Konsole bei 1750E ist schon eine harte Nummer. Der kleine Trafo des Sperrwandlers im integrierten Netzteil macht zwar vermutlich eine Potentialtrennung, sie ist aber vermutlich nicht für die übliche Trennspannungen ausgelegt. Ich weiß zwar was ich mache, würde aber keinem empfehlen, eine serielle Konsole bei einer 1750E nachzubauen, der nicht vom Fach ist!

Edit:

Mir ist gerade gelungen, vom 1750E mit meiner "NO FREETZ" 30-ger-Firmware per AVM WebIF mein FREETZ NG Image (auch 30-ger FW) auf die Box zu bringen. "NO FREETZ" mag früher anders definiert gewesen zu sein. In meinem Falle ist es ein Original-Image mit meinen Zertifikaten. Aus diesem Grund kann ich ja nur per AVM WEBIF updaten.
Dieses Update habe ich vollständig per serielle Console aufgenommen. Es lief alles wie es soll. Danach startet der Repeater mit FREETZ NG drauf, es verhält sich schon von vorne an etwas anders mit dieser Netzwerk-Schnittstelle. Denn mit Original-FW hatte ich die richtige Zeit schon relativ früh im Log gesehen, weil der Repeater sich anscheinend per LAN schon beim Booten relativ früh synchronisiert. Dieses durchgehene 1970-01-01 bekommt man mit Original-Firmware nur, wenn man beim booten kein Netzwerkkabel angeschlossen hat. Dazu anzumerken ist, dass der Repeater als AP mit LAN und nicht als ein reiner WLAN-Repeater eingerichtet ist. Also, ich will damit sagen, dass abgesehen von anderen Sachen da vermutlich noch was faul mit dem Netzwerktreiber ist oder die Schnittstelle wird nicht hoch gefahren.
Viel interessanter ist für uns aber der Abschnitt:

Code:
Jan  1 01:00:13 ctlmgr[714]: pcpc_create_ctx: no pcpserver found
Jan  1 01:00:13 upnpd[720]: starting ... (normal)
1970-01-01 01:00:13 upnpd[720]: ready (0sec)
/etc/init.d/rc.rextd: line 42: syntax error: unexpected "else" (expecting "fi")
[FREETZ]   AVM-REXTD   /etc/init.d/rc.rextd: line 42: syntax error: unexpected "else" (expecting "fi")
rc.wlan: Start WLAN...
Jan  1 01:00:15 ctlmgr[717]: WLANLIB: wlan_plugin_init:868: prj revision 0x1c35e1c
WLAND:[00809]:01:00.15/[0015.210]:[VER]Registered new module default, DEFAULT, 0
WLAND:[00809]:01:00.15/[0015.210]:[VER]Registered new module global, GLOBAL, 0
WLAND:[00809]:01:00.15/[0015.210]:[ALW]BUILD: Oct  4 2022, 17:10:29
Jan  1 01:00:15 deviceinfod[812]: starting ... (normal)
Danach "tanzt" er mit dem WLAN und versucht WLAN immer wieder zu starten, was man an der wild blinkenden WLAN LED auch sieht.
rextd gibt es nur bei den Repeatern, wenn ich es richtig überblicke. Darum wird es schon passen, dass es vermutlich viele Repeater betrifft.
Sooo... Für heute reicht es. Morgen kann ich weitere Erkundungen mit der seriellen Konsole erst spät abends machen. Aber vielleicht ist jemand bis dahin schon mal mit diesem "line 42"-Fehler weiter...

Es war ja klar, dass die Antwort auf alle Fragen 42 ist.
 
Zuletzt bearbeitet:
Hier hat cuma / fda77 den Fehler am 10.01.2023 gemacht. Zweites "else" soll vermutlich "fi" heißen.

Bash:
        export LD_PRELOAD=libmultid.so
        fi
    fi
    $DAEMON_BIN -v 2>/dev/null
    exitval=$?
    if modlib_check_supervisor; then
        nohup $DAEMON_BIN -v 0</dev/null 1>/dev/null 2>&1 &
        exitval=0
    else
        $DAEMON_BIN -v 2>/dev/null
        exitval=$?
    else
    unset LD_PRELOAD
    sleep 1
    [ -f /tmp/flash/mod/multid.start ] && . /tmp/flash/mod/multid.start
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.