.titleBar { margin-bottom: 5px!important; }

[Problem] Freetz Image für 7390 flashen ohne RUKernelTool

Dieses Thema im Forum "Freetz" wurde erstellt von bighegi, 21 Nov. 2018.

  1. bighegi

    bighegi Neuer User

    Registriert seit:
    9 Apr. 2011
    Beiträge:
    25
    Zustimmungen:
    1
    Punkte für Erfolge:
    3
    Hallo zusammen,
    ... mir ist was blödes passiert: Ich hatte in der AVM Firmware den Haken für die Auto-Updates übersehen. Jetzt hat sich meine 7390 auf AVM FitzOS 6.85 geflasht.

    Aus der Vergangenheit weiß ich, dass es vielfach nicht funktioniert ein sehr großes Freetz-Image über das AVM-Webinterface zu flashen. - Da landete ich regelmäßig in der Reboot-Schleife.

    Die konnte ich mit RUKernelTool beheben (oder gleich damit flashen). Das ist ja derzeit mangels aktueller Version nicht möglich.

    Jetzt habe ich zwar davon gelesen ein 75xx mit YourFritz von der Linux-Kommandozeile zu flashen (wäre für mich einfacher als der Weg über Windows), aber dazu braucht man ein in.memory Image, welches ich für die 7390 nicht erstellen kann (freetz trunk 14995).

    Kann mir jemand einen einfachen (und möglichst sicheren) Weg sagen, wie ich mein Freetz-Image auf die 7390 bekomme? - Vorzugsweise Linux, aber Windows geht zur Not auch.

    Besten Dank
    Bighegi.
     
  2. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,629
    Zustimmungen:
    633
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    Bei der 7390 kann man einfach über den Bootloader in die "mtd1"-Partition schreiben ... dazu kann man (u.a.) auch "eva_store_tffs" nehmen (erster Parameter ist das MTD, zweiter das Image), selbst wenn der Name suggerieren mag, daß man damit nur die TFFS-Partitionen beschreiben könne (was bei den Modellen mit (kleinem) SPI auch tatsächlich so ist).

    Ach so ... dazu nimmt man einfach die "kernel.image", denn bei der 7390 ist die "filesystem.image" ohnehin nur 0 Byte groß.
     
  3. bighegi

    bighegi Neuer User

    Registriert seit:
    9 Apr. 2011
    Beiträge:
    25
    Zustimmungen:
    1
    Punkte für Erfolge:
    3
    Hallo Peter,
    danke für Deine Antwort. Hört sich ja nicht so kompliziert an. Dennoch bin ich etwas verwirrt, weil ich auf diesem Wege bislang gar nicht unterwegs war.

    Das klingt also nach
    "eva_store_ttfs mtd1 7390_06.85-freetz-devel-14995.de_20181121-204631.image"​

    nur woher nehme ich "eva_store_ttfs" Ist das ein YourFritz Kommando? - Wenn ich das auf meiner Linux-Box ausführe, muss ich doch noch irgendwie die Verbindung zur 7390 herzaubern.

    Danke & Gruß

    BigHegi

     
  4. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,629
    Zustimmungen:
    633
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    Einfach mal suchen ... wie man in den FTP-Server im Bootloader kommt, ist mehr als ausführlich (und auf verschiedenen "knowledge levels") beschrieben.

    Die Datei "7390_06.85-freetz-devel-14995.de_20181121-204631.image" heißt ja offensichtlich nicht "kernel.image", oder? In #2 schrieb ich ja noch, daß man eine solche Datei (mit dem Namen "kernel.image") in dieses MTD schreiben solle. Die Frage, wie man aus der Freetz-Datei jetzt die "kernel.image" gewinnt, würde ich also noch verstehen (kleiner Tipp am Rande: diese ".image"-Datei von AVM oder Freetz ist ein TAR-File) ... aber warum das nach dem gezeigten Kommando aus #3 klingen sollte, verstehe ich nicht.

    Ja, "eva_store_tffs" ist eines der Skripte aus den "eva_tools" im YourFritz-Repository.

    Aber das ist alles tatsächlich (und zwar meist auch mehrfach) beschrieben (von "discovery" bis zum FTP-Login) und der kleine Teil, der vielleicht nicht ins Auge springt (nämlich "eva_store_tffs" zum Schreiben), wurde hier bereits erwähnt.

    Wenn Dir das zu kompliziert erscheint, mußt Du eben etwas anderes verwenden, z.B. das alte "push_firmware", denn wenn man ein Freetz-Image hat (und das nicht aus einem Board stammt, wo es solche "Komplett-Images" zum Download gibt, weil man dann natürlich solche Fragen nicht hier, sondern auch in diesem Board stellen würde), dann sollte man ja sein Kopie des Trunks haben, in dem dieses Skript enthalten ist.
     
  5. bighegi

    bighegi Neuer User

    Registriert seit:
    9 Apr. 2011
    Beiträge:
    25
    Zustimmungen:
    1
    Punkte für Erfolge:
    3
    Hallo Peter,
    danke für Deine Hinweise. - Und sorry, das mit dem image hatte ich falsch gelesen, der Tag war einfach schon zu lang und voll.

    Ich habe mal eine Weile rumgesucht, ich denke Du meintest sowas wie diese Anleitung: https://www.ip-phone-forum.de/threa...-aus-yourfritz-eva_tools.298591/#post-2264928. Leider bin ich bei "eva_store_tffs" in diesem Zusammenhang aber nicht so recht fündig geworden.

    Habe also das YourFritz repository von Github runtergeladen.
    Du schreibst oben im Thread nichts dazu, wie ich eine IP als Parameter mitgebe. Im Script "eva_store_tffs" habe ich daher die box-ip auf 192.168.2.33 angepasst
    box_ip=${3:-192.168.2.33}​

    Ferner habe ich das Firmware-Image mit tar entpackt und mir daraus die "kernel.image" gegriffen.

    Also los: Mit "eva_discover" halte ich die Box beim Booten an, so dass ich einen FTP machen kann. - Das scheint zu klappen. Der Upload aber (noch) nicht. Mein Versuch war - basierend auf der Doku im o.g. Link wie folgt:

    eval $(./eva_discover INTERFACE=eth1 FROM=192.168.2.250 TO=192.168.2.33 BLIP=1);[ "$EVA_FOUND" = "1" ] && ./eva_store_tffs mtd1 /tmp/test/var/tmp/kernel.image ​

    Ich bekomme ein paar anfängliche BLIP-Punkte ("Sending Boradcast Packets ......" die dann wieder verschwinden und das war es dann.

    Dabei habe ich es wohl geschafft, meine Box in eine Reboot-Schleife zu schicken. - OK, das wird heute Abend nichts mehr.

    Irgendwas mache ich mit eva_store_tffs noch falsch. - Bleibt die Frage nur was?

    Danke & Gruß

    BigHegi.
     
  6. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,629
    Zustimmungen:
    633
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    Das, was da "im Original" stand, heißt ja übersetzt: Nimm den dritten Parameter als "box_ip", sofern er existiert, ansonsten den Wert hinter dem Minuszeichen - bei mir sicherlich mit "192.168.178.1" die "Standardadresse" einer FRITZ!Box (würde ich mal "aus dem Bauch" behaupten, ohne das zu überprüfen). Anstelle dieser Änderung hätte man also auch einfach die Adresse als dritten Parameter angeben können - nur falls es "Nachahmer" geben sollte.

    Ansonsten sollte "eva_store_tffs" ein Protokoll der FTP-Session speichern ... da die 7390 nur ein OS hat, ist nach einem erfolglosen Schreibversuch halt gar kein System mehr verfügbar. Setzt man hier jetzt das Recovery-Programm von AVM ein, macht das auch nichts anderes, als die Firmware (halt die, welche im Programm selbst enthalten ist) über den FTP-Server in diese Partition zu schreiben.

    Ich weiß nicht, wie das Timing bei der 7390 ist ... da ja beim Schreiben der Flash-Partitionen diese zuerst zu löschen sind, kann es bis zum Beginn der Datenübertragung etwas dauern (nach dem "STOR" wird - iirc - erst mal gelöscht, bevor die Data-Connection etabliert wird) und sollte das Skript darauf mit Timeout reagieren (es ist halt für das Flashen der wesentlich kleineren TFFS-Partitionen gedacht, wo das Löschen auch schneller geht), muß man die Wartezeiten ggf. noch weiter anpassen.
     
  7. bighegi

    bighegi Neuer User

    Registriert seit:
    9 Apr. 2011
    Beiträge:
    25
    Zustimmungen:
    1
    Punkte für Erfolge:
    3
    Hallo Peter,
    vielen Dank für Deine Mühe.

    Ich habe da das Gefühl, das für "eva_store_tffs" da noch irgendwas mit dem Aufruf nicht klappt. - Aber eins nach dem anderen. Basierend auf dem o.g. Thread habe ich mir ein Script "eva_flash7390.sh" gebaut und gem. der lokalen Netzwerkadressen angepasst. Das sieht so aus und bekommt als Parameter ($1) die kernel.image-Datei:
    Code:
    #!/bin/sh
    eval $(./eva_discover INTERFACE=eth1 FROM=192.168.2.250 TO=192.168.2.33 BLIP=1)
    if [ "$EVA_FOUND" = "1" ]; then
       printf "FRITZ!Box gefunden unter der IP-Adresse %s" "$EVA_IP" 1>&2
       ./eva_store_tffs mtd1 $1 $EVA_IP
    else
       printf "FRITZ!Box nicht gefunden" 1>&2
    fi
    
    Wenn ich das Script aufrufe und nichts weiter mache, kommt der BLIP "." bis die rebootende 7390 gefunden ist (was gem Script bestätigt wird) und dann hängt es ...
    Code:
    [email protected]:/usr/local/src/YourFritz/eva_tools$ ./eva_flash7390.sh /tmp/var/tmp/kernel.image
    FRITZ!Box gefunden unter der IP-Adresse 192.168.2.33
    
    Eine Log-Datei wird nicht erstellt.
    Drücke ich dagegen ca. 5 sek. nach der IP-Meldung <STRG>+<C> um das Ganze abzubrechen, passiert folgendes:
    ... und es wird auch eine Logdatei geschrieben:
    ... aber irgendwas "klemmt" da dennoch, denn selbst nach 15 min. hängt er da immer noch und braucht ein weiteres <STRG>+<C> um zum Prompt zurückzufinden. Ich habe zwar auf diesem Wege es bislang einmal geschafft ein Image hochzuschießen und mich aus der Boot-Schleife befreit ... aber das Ganze funktioniert nicht zuverlässig reproduzierbar.

    Habe also mal Deinen Vorschlag aufgegriffen und mit den Timeouts gespielt. in der "eva_store_tffs" habe ich den "nc" timeout Parameter über eine Variable oben bei den Konstanten veränderbar gemacht:
    In Zeile 103 aus der "60" den Verweis auf die Konstante gebastelt:
    Und in Z. 226 den "-w" Parameter ergänzt:
    Aber auch das hat das Verhalten nicht wirklich verändert.
    Irgendwas klemmt da noch mit der guten EVA. - Any Ideas?

    Danke & Gruß
    BigHegi
     
  8. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,629
    Zustimmungen:
    633
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    Man kann es ja auch mit einem "normalen" FTP-Client und "put" versuchen ... wobei das Log ja bis zur letzten 150-Meldung korrekt aussieht. Danach schreibt das Skript die Image-Datei in den FIFO und wenn die Daten übertragen wurden, sollte die Box eigentlich mit "226" antworten. Das hört sich hier so an, als würde das Ende der Datei (also das Ende des "cat" in Zeile 110: https://github.com/PeterPawn/YourFritz/blob/master/eva_tools/eva_store_tffs#L110) nicht erkannt und damit wartet die Box auf weitere Daten ... das wäre die erste Vermutung anhand der Beschreibung.

    Dafür gäbe es beim "nc" die Option "-N" ... damit sollte bei EOF auf STDIN dann die Verbindung auch abgebaut werden - ggf. kann man das auch noch mit der Option "-q" koppeln, die eine Wartezeit nach dem EOF auf STDIN angibt, bevor die Verbindung geschlossen wird.

    Bringt das beides nichts (das "-q" beinhaltet ein "-N", es sollte also ein Test mit "-q 10" ausreichen, dann dauert es eben noch 10 Sekunden nach dem Übertragen der Datei, bevor die Verbindung geschlossen wird) hilft es ja vielleicht, wenn man hinter das "cat" noch direkt ein explizites Schließen des FIFO setzt:
    Code:
    cat $file >$storefifo && eval "exec $upstream>&-" &
    
    Damit wird nach dem Ende des "cat" das Handle für STDIN des "nc" geschlossen ... damit sollte die Data-Connection dasselbe Schicksal erleiden.

    Wobei ich nicht sicher bin, ob das "cat" tatsächlich erst dann endet, wenn die Daten auch weggeschrieben wurden aus dem FIFO ... mit etwas Pech kommt das "exec" (das macht ja das "close" für das Handle) auch zu früh und das "nc" leert dann die Buffer nicht mehr - das Ergebnis wäre ein "Datenverlust" am Ende der Übertragung, der bei SquashFS-Images direkt zu Problemen führt, weil an deren Ende die Verwaltungsinformationen stehen. Daher würde ich das auch nur in Verbindung mit "-q" verwenden.
     
  9. bighegi

    bighegi Neuer User

    Registriert seit:
    9 Apr. 2011
    Beiträge:
    25
    Zustimmungen:
    1
    Punkte für Erfolge:
    3
    Gut, werde die Tage mal mit den Optionen zum nc spielen. - Das würde im günstigsten Fall das 2. <STRG>+<C> klären bzw. ersparen.

    Aber warum ich zu Beginn des eva_store_tffs-Scriptes nach 5 Sek. ein erstes <STRG>+<C> benötige damit der Transfer anläuft ist für mich damit noch nicht klar.
    Und eigentlich ist das schon sehr schräg. Irgendein Kommando muss da "klemmen", welches auf diesem Wege abgeschossen wird. Hab grad noch keine Idee, wie man dem auf die Spur kommt.

    Egal, trotzdem erstmal danke und bis die Tage

    BigHegi.
     
  10. vaxinf

    vaxinf Neuer User

    Registriert seit:
    17 Feb. 2016
    Beiträge:
    142
    Zustimmungen:
    7
    Punkte für Erfolge:
    18
    #10 vaxinf, 24 Nov. 2018
    Zuletzt von einem Moderator bearbeitet: 25 Nov. 2018
    Hier "mein" windows-bat-Skript zum updaten eines beliebigen kernel-images auf die mtd1-Partition.
    Das Skript braucht ncftp, das als freeware für windows zur Verfügung steht.
    Das kernel-Image wird erzeugt aus
    cat kernel.raw kernelsquashfs.raw > kernel_patched.image
    im Verzeichnis build/modified/kernel
    nachdem man das freetz-Image per make produziert hat.
    Bestimmt nicht perfekt, aber für mich OK.

    Voraussetzung ist ein Ethernet-Interface konfiguriert mit IP 192.168.178.11 / NETMASK 255.255.255.0
    und keinem Default-Route-Eintrag (mit ping -t 192.168.178.1 testen, ob FB7390 über das Netzwerk erreichbar ist.).

    Have FUN
    eberhard
    Code:
    === update_fb7390_freetz.bat =============================================================
    [USER=104278]@echo[/USER] OFF
    SET ip=192.168.178.1
    :NOCHMAL
    ECHO **********************************************
    ECHO Stromversorgung von der FB jetzt ausstecken!
    ECHO **********************************************
    
    ECHO Stromversorgung ausgesteckt?
    SET /P X=(J)a, (N)ein oder (A) bbruch?
    IF /I "%X%"=="J" goto :JA
    IF /I "%X%"=="N" goto :NOCHMAL
    IF /I "%X%"=="A" goto :ENDE
    
    :JA
    ECHO **********************************************
    ECHO Stromversorgung jetzt in die FB stecken!
    ECHO **********************************************
    ECHO Warten auf aktive Fritzbox... [%ip%]
    
    :fbstilloff
    PING %ip% -n 1 -w 1 | FIND /i "TTL" >nul 2>&1
    if errorlevel 1 (
    timeout 1 >nul
    echo|set /p="."
    GOTO fbstilloff
    )
    
    ECHO Fritzbox gefunden [%ip%]
    
    [USER=104278]@echo[/USER] open 192.168.178.1> %temp%\ftp_fb.txt
    [USER=104278]@echo[/USER] adam2>> %temp%\ftp_fb.txt
    [USER=104278]@echo[/USER] adam2>> %temp%\ftp_fb.txt
    [USER=104278]@echo[/USER] quote SETENV firmware_version avm>> %temp%\ftp_fb.txt
    [USER=104278]@echo[/USER] quote REBOOT>> %temp%\ftp_fb.txt
    [USER=104278]@echo[/USER] quit>> %temp%\ftp_fb.txt
    @echo:>> %temp%\ftp_fb.txt
    
    ftp -s:%temp%\ftp_fb.txt >nul
    del %temp%\ftp_fb.txt
    
    ECHO Warten auf Shutdown... [%ip%]
    
    :fbon1
    PING %ip% -n 1 -w 1 | FIND /i "TTL" >nul 2>&1
    if errorlevel 1 (
    GOTO fboff1
    ) else (
    timeout 1 >nul
    echo|set /p="."
    GOTO fbon1
    )
    
    :fboff1
    ECHO Shutdown fertig! [%ip%]
    ECHO Warten auf den Neustart... [%ip%]
    
    :fbstilloff1
    PING %ip% -n 1 -w 1 | FIND /i "TTL" >nul 2>&1
    if errorlevel 1 (
    timeout 1 >nul
    echo|set /p="."
    GOTO fbstilloff1
    )
    
    ECHO Fritzbox wieder aktiv! [%ip%]
    
    [USER=104278]@echo[/USER] open 192.168.178.1> %temp%\ftp_unsetenv_provider.txt
    [USER=104278]@echo[/USER] adam2>> %temp%\ftp_unsetenv_provider.txt
    [USER=104278]@echo[/USER] adam2>> %temp%\ftp_unsetenv_provider.txt
    [USER=104278]@echo[/USER] quote UNSETENV provider>> %temp%\ftp_unsetenv_provider.txt
    [USER=104278]@echo[/USER] quote SETENV firmware_version avm>> %temp%\ftp_unsetenv_provider.txt
    [USER=104278]@echo[/USER] quote UNSETENV country>> %temp%\ftp_unsetenv_provider.txt
    [USER=104278]@echo[/USER] quote UNSETENV language>> %temp%\ftp_unsetenv_provider.txt
    [USER=104278]@echo[/USER] quit>> %temp%\ftp_unsetenv_provider.txt
    @echo:>> %temp%\ftp_unsetenv_provider.txt
    
    ftp -s:%temp%\ftp_unsetenv_provider.txt
    del %temp%\ftp_unsetenv_provider.txt
    
    ncftpget -t 5 -V ^
    -o doNotGetStartCWD=1,useFEAT=0,useHELP_SITE=0,useCLNT=0,useSIZE=0,useMDTM=0  ^
    -W "quote MEDIA SDRAM" ^
    -W "quote RETR env" ^
    -u adam2 -p adam2 ^
    -C 192.168.178.1 ^
    env %temp%\env.txt 2>nul
    
    echo *************************************************
    type %temp%\env.txt
    echo *************************************************
    
    type %temp%\env.txt | Findstr /b /c:HWRevision  > %temp%\HWRevision.txt
    for /f "tokens=1-2*" %%i in (%temp%\HWRevision.txt) do (
      set/a hw = %%j
      )
     
    if "%hw%" == "156" (
    echo Fritz_Box_7390 erkannt
    echo *************************************************
    echo Firmwareupdate wird nun gestartet
    echo Dauer ca. 1:30 min.
    echo Nun die Fritzbox auf keinen Fall ausschalten!
    echo *************************************************
    ) ELSE (
    echo Keine Fritz_Box_7390. Firmwareupdate abgebrochen!
    goto ENDE
    )
    
    ncftpput ^
    -o doNotGetStartCWD=1,useFEAT=0,useHELP_SITE=0,useCLNT=0,useSIZE=0,useMDTM=0  ^
    -W "quote MEDIA FLSH" ^
    -u adam2 -p adam2 ^
    -C 192.168.178.1 ^
    kernel_patched.image mtd1
    
    ECHO **********************************************************
    ECHO Datenbereich nur Loeschen, wenn FB nicht regulaer startet!
    ECHO Normalerweise diese Frage mit (N)ein beantworten!
    ECHO **********************************************************
    
    ECHO Soll Datenbereich komplett geloescht werden?
    SET /P X=(J)a, (N)ein?
    IF /I "%X%"=="J" goto :LOESCH
    goto OHNELOESCH
    
    :LOESCH
    
    del %temp%\empty.txt 2>nul >nul
    fsutil file createnew %temp%\empty.txt 0 >nul
    
    ncftpput ^
    -o doNotGetStartCWD=1,useFEAT=0,useHELP_SITE=0,useCLNT=0,useSIZE=0,useMDTM=0 ^
    -W "quote MEDIA FLSH" ^
    -u adam2 -p adam2 ^
    -C 192.168.178.1 ^
    %temp%\empty.txt mtd3
    
    ncftpput ^
    -o doNotGetStartCWD=1,useFEAT=0,useHELP_SITE=0,useCLNT=0,useSIZE=0,useMDTM=0 ^
    -W "quote MEDIA FLSH" ^
    -u adam2 -p adam2 ^
    -C 192.168.178.1 ^
    %temp%\empty.txt mtd4
    
    del %temp%\empty.txt
    
    :OHNELOESCH
    
    type %temp%\env.txt | Findstr /b /c:wlan_key > %temp%\wlan_key.txt
    [USER=104278]@echo[/USER] open 192.168.178.1 > %temp%\quote_wlan.txt
    [USER=104278]@echo[/USER] adam2>> %temp%\quote_wlan.txt
    [USER=104278]@echo[/USER] adam2>> %temp%\quote_wlan.txt
    [USER=104278]@echo[/USER] | set /p="quote SETENV ">> %temp%\quote_wlan.txt
    type %temp%\wlan_key.txt>> %temp%\quote_wlan.txt
    [USER=104278]@echo[/USER] quote SETENV firmware_version avm>> %temp%\quote_wlan.txt
    [USER=104278]@echo[/USER] quote REBOOT>> %temp%\quote_wlan.txt
    [USER=104278]@echo[/USER] quit>> %temp%\quote_wlan.txt
    @echo:>> %temp%\quote_wlan.txt
    
    ftp -s:%temp%\quote_wlan.txt >nul
    
    ECHO Fritzbox wird nun neu gestartet.
    ECHO Kontrollieren Sie, dass die Fritzbox regulaer hochfaehrt.
    
    ECHO Soll bei einer weiteren FB der Firmwareupdate gestartet werden?
    SET /P X=(J)a oder (N)ein?
    IF /I "%X%"=="J" goto :NOCHMAL
    IF /I "%X%"=="N" goto :ENDE
    
    :ENDE
    del %temp%\HWRevision.txt
    del %temp%\quote_wlan.txt
    del %temp%\wlan_key.txt
    del %temp%\env.txt
    ECHO Updateskript wird beendet!
    =============================================================================

    //edit by stoney: [CODE] TAG [/CODE] gesetzt
     
  11. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,629
    Zustimmungen:
    633
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    vs.
    Ist das jetzt schon die erwähnte Not?

    Das ist wohl wahr ... einfach weil die "zusammengesetzte" Datei mit Kernel + SquashFS-Image bereits vom Freetz-Build in "fwmod" erzeugt wird, denn in Zeile 1650 (https://github.com/Freetz/freetz/blob/master/fwmod#L1650) wird das Dateisystem an den Kernel angefügt. Man kann also auch einfach die "kernel.image" aus dem "modified"-Verzeichnis verwenden (wie oben in #2 schon erwähnt, auch wenn sie da noch aus dem gepackten Freetz-Image kommen sollte) und braucht sich nicht erst noch das passende File zu erzeugen.

    Die an dieser "kernel.image" noch zusätzlich hängenden 8 Byte für die Prüfsumme (CRC32-Wert samt "magic") kann man entweder noch entfernen oder auch gefahrlos mit schreiben lassen, solange das Image nicht tatsächlich durch diese 8 Byte zu groß wird.

    Wobei mich auch die Frage umtreibt, warum da jemand zweimal mit dem MS-FTP-Client auf die Box zugreifen will und warum beim ersten Mal nur "firmware_version" gesetzt wird ... das dann aber auch beim zweiten Mal noch einmal.

    Gibt es dafür irgendeinen plausiblen Grund?

    Die weiteren Sessions kann man dann noch nachvollziehen (wobei das ja problemlos auch zuvor schon zu klären und dann "in einem Rutsch" zu schreiben wäre) ... jedoch das "Löschen" der TFFS-Partitionen mit "leeren Dateien" scheint wohl auch eine Unsitte zu sein, die man nicht mehr "wegbekommt" - im Gegensatz zu anderen Boxen schadet es bei der 7390 aber meist nicht, weil wesentliche Einträge vom Bootloader wieder restauriert werden - wenn auch nicht alle.

    Bei anderen Modellen kann man davon nur abraten und so sollte man das generell nicht so machen (dann muß man nicht immer erst auf das Modell schauen), sondern besser gleich ein vernünftiges TFFS-Image aus den Environment-Daten erzeugen und das dann schreiben.

    Wenn das tatsächlich so problemlos wäre mit diesem "Löschen", warum macht sich dann das AVM-Recovery-Programm eigentlich die Arbeit und erzeugt stattdessen ein passendes Image? Das könnte ja dann auch einfach mit Länge 0 schreiben ... ich wage mal die These, daß AVM (gute) Gründe hat, wenn man den beschwerlicheren Weg nimmt.
     
  12. vaxinf

    vaxinf Neuer User

    Registriert seit:
    17 Feb. 2016
    Beiträge:
    142
    Zustimmungen:
    7
    Punkte für Erfolge:
    18
    #12 vaxinf, 24 Nov. 2018
    Zuletzt bearbeitet: 26 Nov. 2018
    1.) Das "Löschen" ist optional.
    2.) Jeder kann diesen Quelltext nach seinem Gusto modifizieren, wenn jemand meint, dass etwas nicht OK ist.
    3.) Ich habe mit Hilfe dieses Skripts mehrmals eine FB7390 mit Freetz-Images bzw. modifizierten squashfs der Original-Firmware (Stichwort fwmod) bespielt und keine Probleme registriert. Sicheheitshalber werden ja die env-Daten ausgelesen und abgespeichert.
    4.) Meine "Lösung" ist ausdrücklich nur für eine 7390 bestimmt und wird abgebrochen, wenn eine andere FB nimmt. Wer das modifiziert, dann mtd3/4 löscht und dadurch einen Briefbeschwerer produziert, der ist selbst dafür verantwortlich.
    5.) Das Setzen bestimmter env-Größen vor dem flashen dienst dazu, dass in der abgespeicherten env-Datei die Werte drin stehen, die auch später gelten sollen.
    6.) Um sicher zu stellen, dass nicht durch das optionale Löschen nicht doch env-Einstellungen gelöscht wurden, die wichtig ist, habe ich das erneute Setzen von Variablen nach dem flashen eingebaut. Außerdem ist es völlig unschädlich so etwas zweimal zu tun.
     
  13. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,629
    Zustimmungen:
    633
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    Ich habe ja gar kein Interesse daran, das zu modifizieren (oder habe ich das irgendwo zum Ausdruck gebracht?) ... ich hatte halt die Hoffnung, Du wüßtest, was da geschieht und könntest mir irgendwie erklären, welchen Sinn der allererste Aufruf des MS-FTP-Clients haben soll. Wenn das nicht der Fall ist ... auch gut - das "Bienchen", weil da mal kein "debug bin" für den FTP-Client enthalten ist, hatte ich ja auch "vergessen" - denn das ließ eben bei mir die Hoffnung keimen, Du könntest den Sinn der erwähnten Aktion erklären.

    Und selbst wenn das Löschen nur optional ist ... ich nehme mir trotzdem die Freiheit, von diesem Vorgehen abzuraten - und zwar aus grundsätzlichen Erwägungen, die ich auch oben schon erläutert habe.

    Es kann auch gut sein, daß Du damit schon sehr viele FRITZ!Boxen "bearbeitet" hast ... das habe ich gar nicht bestritten. Hast Du vielleicht trotzdem ein "Angebot" einer Erklärung, warum AVM dann nicht ebenfalls einfach hingeht und die beiden TFFS-Partitionen nur "löscht"? Hast Du jemals Überlegungen in dieser Richtung angestelt? Wenn ja, was haben diese denn ergeben?

    Denn das waren die eigentlichen Fragen, die ich mich traute zu stellen ... wenn ich der Ansicht gewesen wäre, das würde so gar nicht funktionieren, hätte ich das ganz bestimmt auch so deutlich geschrieben. Wenn da aber - für mich zumindest - unplausible Schritte enthalten sind oder solche, die bei anderen Boxen ggf. Probleme bereiten und so auch gar nicht erforderlich wären, dann darf man das ja wohl noch "bemerken" und seinerseits nach einer (möglichst sinnvollen) Begründung dafür fragen.

    Wenn Du vor dem Schreiben von "mtd3" und "mtd4" noch einen Neustart des Windows-PCs eingebaut hättest, würde ich genauso fragen ... nur springt hier der (vermutlich) fehlende Sinn halt fast jedem ins Auge und das mag bei den Abläufen in der Batch-Datei nicht immer der Fall sein.
     
  14. bighegi

    bighegi Neuer User

    Registriert seit:
    9 Apr. 2011
    Beiträge:
    25
    Zustimmungen:
    1
    Punkte für Erfolge:
    3
    Hallo zusammen,

    danke vaxinf für Deinen Input.

    Hmmm, eher nicht. - Da ich nativ unter Linux arbeite und immer erst einen Windows-Rechner booten müsste, wäre ein rudimentäres Script mit dem ich genauso weit komme wie unter Linux nicht etwas, dem ich den Vorzug gewähren würde. - Aber das ist keine Kritik an vaxinf und dem Script, sondern lediglich persönlicher Geschmack und Bequemlichkeit.

    Reproduzierbar ist es doch. Auch zuverlässig!
    Habe mit zwei verschiedene Images auf jew. zwei verschiedene 7390 geschrieben. These:
    1. Das erste <STRG>+<C> beendet einen Hänger von "nc" in Zeile 226, der potentiell mit Peters Vorschlag (-N oder -q) gelöst werden kann.
    2. Das zweite <STRG>+<C> beendet einen Hänger von "nc" in Zeile 103, der potentiell mit Peters Vorschlag (-N oder -q) gelöst werden kann.
    Dafür spricht, dass eva_store_tffs genau 2x nc aufruft und dass der zweite Aufruf ja solch ein Hänger von "nc" zu sein scheint. - Also wäre es sehr naheliegend, dass beim ersten Aufruf auch schon was schief geht. - Ob das jetzt an meiner Umgebung / Distro (Debian 9.6) oder an der 7390 weiß ich nicht.

    Zum testen davon komme ich aber erst irgendwann kommende Woche. - Ich halte Euch auf dem Laufenden!

    Gruß
    BigHegi.
     
    alis123 gefällt das.
  15. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,629
    Zustimmungen:
    633
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    Die Boxen verhalten sich jeweils etwas anders (auch zu diesem Thema habe ich irgendwo ein paar Berichte gesammelt) ... gerade auch was das mehrfache Einloggen in den Bootloader (zwischen zwei Reboots) und die dabei notwendigen Aktionen, damit der sich nicht "aufhängt", betrifft. Der "gemeinsame Nenner" aller Modelle, den auch AVM nach meiner Erfahrung immer nutzt, ist das erfolgreiche Einloggen in den Server, bevor man sich mit einem "QUIT" (das sendet ein Client dann als Reaktion auf ein "BYE") wieder verabschiedet.

    Wie der Name schon sagt, war das Timing beim "eva_store_tffs" in erster Linie auf die VR9-Modelle und das Beschreiben der relativ kleinen TFFS-Partitionen dort, abgestimmt. Man darf die Data-Connection nicht vor der Antwort auf das "PASV" (oder "[email protected]") öffnen ... aber das geht ja i.d.R. ohnehin nicht, weil man erst mit der 227-Antwort die Portnummer für die (passive) Verbindung erhält.

    Einige Modelle (bzw. deren Bootloader) akzeptieren schon von diesem Zeitpunkt an eine eingehende Verbindung auf diesem Port (und antworten gleich mit einem SYN) und bei anderen geht das erste SYN (vom Client, das wird ja direkt beim Aufruf des "nc" dann gesendet) erst mal ins Leere und erst auf dessen Wiederholung hin (die dann i.d.R. auch erst nach der 150-Antwort vom Server erfolgt), funktioniert die Verbindung dann.

    Wobei ich das mit dem SIGINT (das ist ja das Ctrl-C) trotzdem nicht verstehe ... denn ich wage mal die These, daß damit keines der "nc"-Kommandos beendet wird (die laufen ja asynchron im Background mit und sind damit gar nicht einzeln per SIGINT erreichbar von der Console - sie würden höchstens mit abgebrochen (wenn's gut läuft), wenn der Parent beendet wird), sondern das "read" in Zeile 37, wo auf die Antworten des FTP-Servers gewartet wird. Die kommen natürlich auch nur dann, wenn das Datenende für die Übertragung in der Data-Connection erkannt wird und so lange wartet das Skript halt ansonsten im "read" (da gibt es absichtlich auch kein "timeout", obwohl einige Shells das auch könnten ... z.B. die "bash" mit der Option "-t").

    Aber dem Skript fehlt ohnehin sooo viel an vernünftigem Code ... bricht man z.B. das Skript ab, bleibt (dank fehlendem "trap") auch gerne mal ein Zombie (oder gar zwei) mit der "nc"-Instanz übrig - denn das "kill" für diese würde in die entsprechende "trap"-Behandlung gehören. Aber der Aufwand, da irgendwas Neues zu basteln, lohnt wirklich nicht mehr - meine Pläne für die Zukunft mit C# und PowerShell (auch unter Linux) habe ich an anderen Stellen ja deutlich gemacht. Ob die Leute dann "socat" und "nc" (in der richtigen Geschmacksrichtung) oder das PS-Paket (https://github.com/PowerShell/PowerShell) installieren müssen, macht am Ende bei der "Anwendung" ja keinen großen Unterschied und wer dann PS Core nicht länger braucht, wenn er mit der Box fertig ist, deinstalliert es halt einfach wieder.
     
  16. bighegi

    bighegi Neuer User

    Registriert seit:
    9 Apr. 2011
    Beiträge:
    25
    Zustimmungen:
    1
    Punkte für Erfolge:
    3
    Hallo Peter,
    hatte mit dem ganzen Krams das ein- oder andere Mal weiter rumgespielt, bin aber nicht wirklich weiter gekommen. Etwaige mods an dem eva_store_tffs haben auch nicht dazu geführt, dass ich um SIGINT herumkam. ... Na egal. Was ich aber gemacht habe, ist mir ein kleines wrapper script drumherum gebastelt, dem ich direkt die image-Datei aus dem Freetz-Build vorwerfen kann. - Aktuell sieht das ganz so aus:

    Code:
    #!/bin/sh
    printf "Extrahiere kernel.image aus Firmware-Image ..."
    tar xvf $1 ./var/tmp/kernel.image
    printf "... fertig. - Bereite Flash vor ..."
    printf ""
    eval $(./eva_discover INTERFACE=eth1 FROM=192.168.2.250 TO=192.168.2.33 BLIP=1)
    if [ "$EVA_FOUND" = "1" ]; then
       printf "FRITZ!Box gefunden unter der IP-Adresse %s" "$EVA_IP" 1>&2
       ./eva_store_tffs mtd1 ./var/tmp/kernel.image $EVA_IP
    else
       printf "FRITZ!Box nicht gefunden" 1>&2
    fi
    printf "Lösche extrahiertes kernel.image ..."
    rm -rf ./var/tmp/kernel.image
    printf "... fertig!"
    ... schön ist was anderes und damit habe ich für den Moment einen Workaraund, wieder ein Freetz-Image auf eine zerflashte oder originale 7390 zu bekommen.
    Insofern erstmal besten Dank und bis bald.

    BigHegi.