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

bighegi

Neuer User
Mitglied seit
9 Apr 2011
Beiträge
33
Punkte für Reaktionen
2
Punkte
8
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.
 
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ß.
 
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
 
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.
 
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.
 
box_ip=${3:-192.168.2.33}
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.
 
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:
hegi@zomba:/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:
hegi@zomba:/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^CFound AVM bootloader: AVM EVA Version 1.1939 0x0 0xB40D
... und es wird auch eine Logdatei geschrieben:
220 ADAM2 FTP Server ready
USER adam2
331 Password required for adam2
PASS adam2
230 User adam2 successfully logged in
SYST
215 AVM EVA Version 1.1939 0x0 0xB40D
TYPE I
200 Type set to BINARY
MEDIA FLSH
200 Media set to MEDIA_FLASH
P@SW
227 Entering Passive Mode (192,168,2,33,36,177)
STOR mtd1
150 Opening BINARY data connection

... 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:
nc -w $nc_timeout $data_ip $data_port <&$upstream 2>/dev/null 1>&2 &
Und in Z. 226 den "-w" Parameter ergänzt:
nc -w $nc_timeout $box_ip $box_port <&$outstream >&$instream 2>/dev/null &

Aber auch das hat das Verhalten nicht wirklich verändert.
Irgendwas klemmt da noch mit der guten EVA. - Any Ideas?

Danke & Gruß
BigHegi
 
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.
 
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.
 
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
 
Zuletzt bearbeitet von einem Moderator:
Vorzugsweise Linux, aber Windows geht zur Not auch.
vs.
Hier "mein" windows-bat-Skript zum updaten eines beliebigen kernel-images auf die mtd1-Partition.
Ist das jetzt schon die erwähnte Not?

nachdem man das freetz-Image per make produziert hat.
Bestimmt nicht perfekt, aber für mich OK.
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.
 
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.
 
Zuletzt bearbeitet:
2.) Jeder kann diesen Quelltext nach seinem Gusto modifizieren, wenn jemand meint, dass etwas nicht OK ist.
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.
 
Hallo zusammen,

danke vaxinf für Deinen Input.

Ist das jetzt schon die erwähnte Not?

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.

Drücke ich dagegen ca. 5 sek. nach der IP-Meldung <STRG>+<C> um das Ganze abzubrechen, passiert folgendes:
[upload startet]
... 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.

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.
 
  • Like
Reaktionen: alis123
Ob das jetzt an meiner Umgebung / Distro (Debian 9.6) oder an der 7390 weiß ich nicht.
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 "P@SW") ö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.
 
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.
 
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.