[HowTo] Flash-Script für 7490
- Ersteller Christoph_F
- Erstellt am
Danke für den Tipp, aber ich bin auf einem Raspberry Pi 2 unterwegs, also ich arbeite mit der bash. 
Allerdings gibt es beim Wiedereinschalten folgenden Fehler:
Werden hier wirklich die korrekten Zeilen des Skripts von PeterPawn aus YourFritz angegeben?
26-39 (32: "read: Illegal option -u"):
195-201 (198: "[: xFRITZ.Box_7490.113.06.30.image.eva: unexpected operator"):
281-290 (288: "./eva_to_memory: Bad substitution"):
Sorry, da steige ich nicht mehr durch.
Mir ist nicht klar, was "read -u $instream -r line" macht, ebenso die beiden anderen Zeilen, welche auf meinem System ein Problem verursachen. Ich erinnere, dass PeterPawn Posix nutzt (oder?), d.h. da wundert es mich natürlich nicht, dass es bei mir nicht reibungslos auf Anhieb klappt. Gerne würde ich das beheben, bräuchte aber etwas Unterstützung von Leuten, die Ahnung von Skripting haben (inkl. PeterPawn, natürlich). Herzlichen Dank!
Allerdings gibt es beim Wiedereinschalten folgenden Fehler:
Code:
Warte auf Einschalten von „192.168.178.1“…
..... 192.168.178.1 gefunden!
Debugging on (debug=1).
---> QUIT
./eva_to_memory: 198: [: xFRITZ.Box_7490.113.06.30.image.eva: unexpected operator
./eva_to_memory: 32: read: Illegal option -u
./eva_to_memory: 288: ./eva_to_memory: Bad substitution26-39 (32: "read: Illegal option -u"):
Code:
#
# helper functions
#
read_ftp_response()
{
local line=" -" rc=0 instream="$1" log="$2"
[COLOR=#ff0000] while read -u $instream -r line; do[/COLOR]
[ ! -z "$log" ] && echo "$line" >&$log
[ "${line:3:1}" != "-" ] && break
done
rc=$?
echo "$line"
return $rc
}195-201 (198: "[: xFRITZ.Box_7490.113.06.30.image.eva: unexpected operator"):
Code:
#
# check file size
#
[COLOR=#ff0000] if [ x$filename == x ]; then[/COLOR]
echo "Missing file name."
exit 1
fi281-290 (288: "./eva_to_memory: Bad substitution"):
Code:
#
# now open a connection to the box
#
nc $box_ip $box_port <&$outstream >&$instream 2>/dev/null &
control_connection=$!
data_connection=""
line="$(read_ftp_response $instream $logstream)"
[COLOR=#ff0000] ec=${line:0:3}[/COLOR]
if [ x$ec == x220 ]; then
login_to_box $instream $outstream $logstream
...Mir ist nicht klar, was "read -u $instream -r line" macht, ebenso die beiden anderen Zeilen, welche auf meinem System ein Problem verursachen. Ich erinnere, dass PeterPawn Posix nutzt (oder?), d.h. da wundert es mich natürlich nicht, dass es bei mir nicht reibungslos auf Anhieb klappt. Gerne würde ich das beheben, bräuchte aber etwas Unterstützung von Leuten, die Ahnung von Skripting haben (inkl. PeterPawn, natürlich). Herzlichen Dank!
Zuletzt bearbeitet:
Danke für den Tipp, aber ich bin auf einem Raspberry Pi 2 unterwegs, also ich arbeite mit der bash.
Bist Du Dir sicher ?
Raspberry verwendet eigentlich u.a. Rasbian, ein Debian Derivat, d.h. es wird Dash statt Bash verwendet!
Code:
freetz@raspberrypi:~$ ls -la /bin/sh
lrwxrwxrwx 1 root root 4 Mär 30 2012 /bin/sh -> dash
freetz@raspberrypi:~$Vorschlag: von Dash auf Bash umstellen und erneut testen.
Oja, da ist mir ein Fehler unterlaufen - danke! Ich werde es später probieren. Jetzt habe ich es doch mit der "Recovery/Downgrade"-Methode gemacht (läuft noch), und dann sehe ich, ob meine Box überhaupt mit freetz-devel/.60 stabil läuft.
Schade:
Schade:
Das verstehe ich jetzt aber nicht. Ich hatte verstanden, dass es mit dieser Methode klappt, d.h. dass die AVM FW .51 (auf die ich ja zuvor das Downgrade gemacht habe) das nicht prüft. Nun aber wohl doch?
Zuletzt bearbeitet:
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,269
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
@ao:
Bitte einen Thread benutzen, nicht mehrere ... wenn Du die "bash" als Shell verwendest und alle notwendigen Programme installiert hast (nc, socat), dann sollte das auch problemlos unter Raspbian laufen - auch wenn ich nicht mehr genau weiß, was bei mir (RasPi 3, u.a. auch mit ebendiesem System) angepaßt werden mußte. Das, wo ich nicht explizit nach der "bash" "verlange", sollte auch mit der "ash" der BusyBox funktionieren.
Überall POSIX-kompatibel zu arbeiten (damit die blöde "dash" auch geht), scheitert i.d.R. schon daran, daß im POSIX-Standard keine "substrings" ohne zusätzliche Programme verarbeitet werden können ... das macht es dann so richtig schnell. :-(
Sofern ich also nicht bei einem Skript explizit dazuschreibe, daß dieses auch mit einer POSIX-kompatiblen Shell funktioniert, ist die Basis immer "ash" - ansonsten steht im SheBang dann auch explizit die "bash" drin, wenn die "ash" nicht ausreicht.
Bitte einen Thread benutzen, nicht mehrere ... wenn Du die "bash" als Shell verwendest und alle notwendigen Programme installiert hast (nc, socat), dann sollte das auch problemlos unter Raspbian laufen - auch wenn ich nicht mehr genau weiß, was bei mir (RasPi 3, u.a. auch mit ebendiesem System) angepaßt werden mußte. Das, wo ich nicht explizit nach der "bash" "verlange", sollte auch mit der "ash" der BusyBox funktionieren.
Überall POSIX-kompatibel zu arbeiten (damit die blöde "dash" auch geht), scheitert i.d.R. schon daran, daß im POSIX-Standard keine "substrings" ohne zusätzliche Programme verarbeitet werden können ... das macht es dann so richtig schnell. :-(
Sofern ich also nicht bei einem Skript explizit dazuschreibe, daß dieses auch mit einer POSIX-kompatiblen Shell funktioniert, ist die Basis immer "ash" - ansonsten steht im SheBang dann auch explizit die "bash" drin, wenn die "ash" nicht ausreicht.
qwertz.asdfgh
IPPF-Promi
- Mitglied seit
- 18 Feb 2011
- Beiträge
- 4,467
- Punkte für Reaktionen
- 65
- Punkte
- 48
maceis
Mitglied
- Mitglied seit
- 9 Apr 2006
- Beiträge
- 687
- Punkte für Reaktionen
- 4
- Punkte
- 18
Ich brauch leider auch noch etwas Unterstützung.
Ich arbeite in freetz-linox auf einer VM und will die neue Box meines Bruders freetzen.
Ich habe das Skript von Christoph_F verwendet, kann aber eva_to_memory .... auch manuell aufrufen und es scheint durchzulaufen.
Sehr schnell (nach wenigen Sekunden) kommt folgende Ausgabe
Offensichtlich schlägt das dd-Kommando fehl, weil das FLAG count_bytes auf meinem System nicht geht.
Dadurch wird eine leere image.eva Datei erstellt.
Wäre für Unterstützung sehr dankbar.
Gruß
maceis
Ich arbeite in freetz-linox auf einer VM und will die neue Box meines Bruders freetzen.
Ich habe das Skript von Christoph_F verwendet, kann aber eva_to_memory .... auch manuell aufrufen und es scheint durchzulaufen.
Sehr schnell (nach wenigen Sekunden) kommt folgende Ausgabe
Offensichtlich schlägt das dd-Kommando fehl, weil das FLAG count_bytes auf meinem System nicht geht.
Dadurch wird eine leere image.eva Datei erstellt.
Wäre für Unterstützung sehr dankbar.
Gruß
maceis
Zuletzt bearbeitet:
welches System nutzt du denn ? Freetz-VM 1.4.1.ova, RPi, ???
was liefert "dd -?"
könntest Du Bitte den genauen Befehl zur Erstellung der image.eva, inkl. Befehlsausgaben beifügen, so dass es reproduzierbar wird.
Zuletzt bearbeitet:
maceis
Mitglied
- Mitglied seit
- 9 Apr 2006
- Beiträge
- 687
- Punkte für Reaktionen
- 4
- Punkte
- 18
bash hab ich
Das Problem ist:
Wenn ich "iflag=count_bytes" weglasse, wird ein image.eva gespeichert und auch auf die Box geladen.
Wenn ich die Box danach starte, ist aber immer noch die alte FW drauf.
Irgendwie glaub ich, dass es nur noch ein kleiner Schritt ist, der mir fehlt.
Um halb vier heute nacht hab ich vorläufig aufgegeben.
Gruß
maceis
PS: mit einem "echo" vor dem dd-Kommando:
Variante 1:
Variante 2:
Edit:
Ach so ja , System:
Edit 2:
Wenn ich das richtig verstanden habe, könnte man auch die image.in-memory-Datei nehmen.
Ist das richtig?
Und die müsste man eigentlich auch über ftp manuell auf die Box laden können, richtig?
Allerdings: hochgeladen wird es ja, nur die Box nimmt die freetz-FW dann nicht.
und nc ist bei mir
Das Problem ist:
Wenn ich "iflag=count_bytes" weglasse, wird ein image.eva gespeichert und auch auf die Box geladen.
Wenn ich die Box danach starte, ist aber immer noch die alte FW drauf.
Irgendwie glaub ich, dass es nur noch ein kleiner Schritt ist, der mir fehlt.
Um halb vier heute nacht hab ich vorläufig aufgegeben.
Gruß
maceis
PS: mit einem "echo" vor dem dd-Kommando:
Variante 1:
Variante 2:
Edit:
Ach so ja , System:
hab ich neulich erst aktualisiert mit "apt-get upgrade"
Edit 2:
Wenn ich das richtig verstanden habe, könnte man auch die image.in-memory-Datei nehmen.
Ist das richtig?
Und die müsste man eigentlich auch über ftp manuell auf die Box laden können, richtig?
Allerdings: hochgeladen wird es ja, nur die Box nimmt die freetz-FW dann nicht.
Zuletzt bearbeitet:
ich verwende "Debian 8 (jessie)" und da ist die DD Option "iflag=count_bytes" enhalten:
Welches System nutzt Du ?
Code:
freetz@Pi:~$ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"
NAME="Raspbian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
...
Code:
freetz@Pi:~$ dd --help
Aufruf: dd [OPERAND...]
oder: dd OPTION
Kopieren einer Datei, Konvertierung und Formatierung gemäß der Operanden.
bs=BYTES BYTES Bytes auf einmal lesen und schreiben (siehe ibs=,obs=)
cbs=BYTES BYTES Bytes auf einmal konvertieren
conv=CONV Datei gemäß kommagetrennter Schlüsselwörter‐Liste konvertieren
count=N nur N Eingabeblöcke kopieren
ibs=BYTES Lesen von BYTES Bytes auf einmal (Voreinstellung: 512)
if=DATEI aus DATEI statt von der Standardeingabe lesen
iflag=FLAGS anhand der kommagetrennten Symbolliste lesen
obs=BYTES BYTES Bytes auf einmal schreiben (Voreinstellung: 512)
of=DATEI in DATEI statt in die Standardausgabe schreiben
oflag=FLAGS anhand der kommagetrennten Symbolliste schreiben
seek=N N obs‐große Blöcke am Anfang der Ausgabe überspringen
skip=N N ibs‐große Blöcke am Anfang der Eingabe überspringen
status=WELCHE WELCHE Info nicht auf dem Standardfehlerkanal ausgegeben
werden soll. „noxfer“ unterdrückt die übertragungsstatistik
und „none“ alle Ausgabenwelches Skript wirft "dd: ungültiges Eingabeflag: 'count_bytes'" aus ?
bitte mit Skriptausgaben beifügen, so dass es nachvollziehbar wird.
- - - Aktualisiert - - -
Verwendest Du dd aus coreutils paket ?
Code:
root@Pi:~# which dd
/bin/dd
root@Pi:~# [COLOR=#0000ff]dpkg -S /bin/dd
coreutils: /bin/dd[/COLOR]
root@Pi:~# dpkg -l | grep coreutils
ii coreutils 8.23-4 armhf GNU core utilities
ii realpath 8.23-4 all coreutils realpath transitional package
root@Pi:~#maceis
Mitglied
- Mitglied seit
- 9 Apr 2006
- Beiträge
- 687
- Punkte für Reaktionen
- 4
- Punkte
- 18
Bitte auch meinen letzten Beitrag nochmal lesen.
Hab was editiert und ergänzt.
Wie gesagt, ich glaube ich hab ein image, dass okay ist und hochgeladen wird.
Das dd ist aus dem 7490install.sh Skript oben aus diesem Thread
Muss jetzt leider in die Arbeit und bin erst gegen 9 oder 10 wieder da.
Danke schon mal für Euer Feedback und Eure Unterstützung.
Hab was editiert und ergänzt.
Wie gesagt, ich glaube ich hab ein image, dass okay ist und hochgeladen wird.
Das dd ist aus dem 7490install.sh Skript oben aus diesem Thread
Muss jetzt leider in die Arbeit und bin erst gegen 9 oder 10 wieder da.
Danke schon mal für Euer Feedback und Eure Unterstützung.
Nein, bei NAND-Boxen geht das nicht wie bei NOR-Boxen per Bootloader-FTP "STOR" Befehl, deshalb gibt es ja für NAND-Boxen das YourFritz/eva_tools/eva_to_memory
- - - Aktualisiert - - -
==> nimm doch YourFritz/eva_tools/eva_to_memory, dann gibt es kein Problem mit dd
- - - Aktualisiert - - -
==> Vorschlag: das aktuelle freetz-linux-1.4.1.ova aus:
https://sourceforge.net/projects/freetz-linux/
https://sourceforge.net/projects/fr...z-linux-1.4.1/freetz-linux-1.4.1.ova/download
verwenden, dies basiert Ubuntu auf 14.04 und nicht Ubuntu 12.04 und deren veraltete coreutils.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,269
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
Es geht bei der Aktion mit "count_bytes" ja nur darum, die letzten 8 Byte einer Image-Datei abzuschneiden, da dort eine Prüfsumme enthalten ist, die zu unerwünschten (und wie man hier sieht auch fatalen) Verschiebungen der Lage der Daten im Speicher führt.
Läßt man den "iflags"-Parameter weg, werden eben 8 Byte zuviel kopiert und damit landet das Dateisystem an einer falschen integralen Grenze (habe ich auch ausführlich erläutert am Beginn dieses Threads).
Ich habe ja bereits am Beginn des Threads mit @Christoph_F darüber diskutiert ... hier hätte Lesen und Verstehen von #2 (wenn ich das ab #27 richtig verstanden habe) ja vielleicht einiges an Zeit und Aufwand sparen können. Meine Version (image2ram) sollte ohne diese Vereinfachung mit dem "iflags"-Parameter auskommen ... ggf. braucht sie etwas länger beim Kopieren, weil sie mit kleineren Blöcken arbeitet. Da man das nicht alle 5 Minuten wiederholt, sollte das keine entscheidende Rolle spielen.
- - - Aktualisiert - - -
Ja, ich habe gerade noch einmal nachgelesen (ist halt schon wieder lange her) ... ein Aufruf von "image2ram < freetz.image >freetz.memory_image" sollte aus dem TAR-Archiv die Daten korrekt extrahieren.
Wobei natürlich bei der Verwendung von Freetz-Images auch direkt das erzeugte "in-memory"-Image verwendet werden kann ... das ist ja schließlich nur dafür überhaupt erzeugt. Wieso hier im konkreten Fall mit dem TAR-File gearbeitet werden soll, verstehe ich ohnehin nicht.
Läßt man den "iflags"-Parameter weg, werden eben 8 Byte zuviel kopiert und damit landet das Dateisystem an einer falschen integralen Grenze (habe ich auch ausführlich erläutert am Beginn dieses Threads).
Ich habe ja bereits am Beginn des Threads mit @Christoph_F darüber diskutiert ... hier hätte Lesen und Verstehen von #2 (wenn ich das ab #27 richtig verstanden habe) ja vielleicht einiges an Zeit und Aufwand sparen können. Meine Version (image2ram) sollte ohne diese Vereinfachung mit dem "iflags"-Parameter auskommen ... ggf. braucht sie etwas länger beim Kopieren, weil sie mit kleineren Blöcken arbeitet. Da man das nicht alle 5 Minuten wiederholt, sollte das keine entscheidende Rolle spielen.
- - - Aktualisiert - - -
Ja, ich habe gerade noch einmal nachgelesen (ist halt schon wieder lange her) ... ein Aufruf von "image2ram < freetz.image >freetz.memory_image" sollte aus dem TAR-Archiv die Daten korrekt extrahieren.
Wobei natürlich bei der Verwendung von Freetz-Images auch direkt das erzeugte "in-memory"-Image verwendet werden kann ... das ist ja schließlich nur dafür überhaupt erzeugt. Wieso hier im konkreten Fall mit dem TAR-File gearbeitet werden soll, verstehe ich ohnehin nicht.
IMHO: Bitte auch die Bootloader-Variable "linux_fs_start" Variable im Auge behalten, sonst wird ggf. das "falsche" System überschrieben;d.h. Befehl "eva_switch_system xxx" vorher eingebenQuelle:
an etwaige nachfolgende Leser:
die Recherche ergab folgendes, das Erstellen des Freetz-in-memory Image für NAND-Boxen ist mind. seit rev. 14049, d.h. seit 17.01.2017 im Trunk enthalten.
http://freetz.org/browser/trunk/fwmod?rev=14049
d.h. nach "fwmod" ist weder "./7490install.sh" noch "image2ram" mehr erforderlich, das geht mit direkt mit "./eva_discover" sowie "./eva_to_memory 7490_06.83-freetz-devel-14237.de_20170421-185342.image.in-memory"
ggf. nach $IP als Argument bei eva_discover bzw. eva_to_memory angeben.
die Recherche ergab folgendes, das Erstellen des Freetz-in-memory Image für NAND-Boxen ist mind. seit rev. 14049, d.h. seit 17.01.2017 im Trunk enthalten.
http://freetz.org/browser/trunk/fwmod?rev=14049
Code:
1729 #[COLOR=#0000ff] Create in-memory image [/COLOR]
1730 img_name="${FW_IMAGES_DIR:-$DIR}/${modimage}"
1731 if [ "${FREETZ_AVM_HAS_UPDATE_FILESYSTEM_IMAGE}" == "y" ]; then
1732 echo0 "creating in-memory image ${img_name}.in-memory"
1733 {
1734 cat "$KERNEL_MOD" | dd bs=256 conv=sync 2>/dev/null;
1735 cat "$FILESYSTEM_MOD" | dd bs=256 conv=sync 2>/dev/null;
1736 } > "${img_name}.in-memory"
1737 fid.h. nach "fwmod" ist weder "./7490install.sh" noch "image2ram" mehr erforderlich, das geht mit direkt mit "./eva_discover" sowie "./eva_to_memory 7490_06.83-freetz-devel-14237.de_20170421-185342.image.in-memory"
ggf. nach $IP als Argument bei eva_discover bzw. eva_to_memory angeben.
Zuletzt bearbeitet:
maceis
Mitglied
- Mitglied seit
- 9 Apr 2006
- Beiträge
- 687
- Punkte für Reaktionen
- 4
- Punkte
- 18
Danke Euch allen für Eure Tipps.
Ich kann leider nicht laufend hier mitlesen und mich ständig auf dem Laufenden über die neuesten (ja, ich weiß, ist nicht mehr ganz so neu) Entwicklungen halten,
Ich muss auch zugeben, dass vieles, was die regulars hier schreiben, zu hoch für mich ist.
Auch habe ich #2 gelesen, aber (zugegebenermaßen) nicht alles verstanden.
Ich versuche halt, mir selbst zu helfen, so gut ich kann und erst dann zu fragen, wenn ich alleine nicht mehr weiter weiß.
Bin eben erst heimgekommen, und werden nach dem Essen genauer lesen, was Ihr alles empfohlen habt und hoffe, dass ich damit klarkomme.
Ich melde mich später noch mal und berichte die Ergebnisse.
Gruß
maceis
- - - Aktualisiert - - -
Hallo nochmal;
tja, ich glaube, jetzt hab ich was kaputt gemacht.
Ich konnte zwar "./eva_to_memory 7490_06.83-freetz-devel-14237.de_20170421-185342.image.in-memory" erfolgreich ausführen mit folgendem Ergebnis.
Leider startet die Box trotzdem nicht mehr.
Ich komme nur noch mit ftp drauf.
Nur wenn ich die Variable "linux_fs_start" ändere, fährt die Box noch hoch und zwar mit einer ziemlich alten AVM-FW.
Auf dieser "Seite" möchte ich aber (zumindest vorläufig) nichts machen.
Kann man da noch was machen, um das ganze wieder zu reparieren.
Ich muss dazusagen, dass ich nur ein uraltes virtuelles Windows irgendwo liegen habe und deswegen noch kein recover versucht habe.
Gruß
maceis
Ich kann leider nicht laufend hier mitlesen und mich ständig auf dem Laufenden über die neuesten (ja, ich weiß, ist nicht mehr ganz so neu) Entwicklungen halten,
Ich muss auch zugeben, dass vieles, was die regulars hier schreiben, zu hoch für mich ist.
Auch habe ich #2 gelesen, aber (zugegebenermaßen) nicht alles verstanden.
Ich versuche halt, mir selbst zu helfen, so gut ich kann und erst dann zu fragen, wenn ich alleine nicht mehr weiter weiß.
Bin eben erst heimgekommen, und werden nach dem Essen genauer lesen, was Ihr alles empfohlen habt und hoffe, dass ich damit klarkomme.
Ich melde mich später noch mal und berichte die Ergebnisse.
Gruß
maceis
- - - Aktualisiert - - -
Hallo nochmal;
tja, ich glaube, jetzt hab ich was kaputt gemacht.
Ich konnte zwar "./eva_to_memory 7490_06.83-freetz-devel-14237.de_20170421-185342.image.in-memory" erfolgreich ausführen mit folgendem Ergebnis.
Leider startet die Box trotzdem nicht mehr.
Ich komme nur noch mit ftp drauf.
Nur wenn ich die Variable "linux_fs_start" ändere, fährt die Box noch hoch und zwar mit einer ziemlich alten AVM-FW.
Auf dieser "Seite" möchte ich aber (zumindest vorläufig) nichts machen.
Kann man da noch was machen, um das ganze wieder zu reparieren.
Ich muss dazusagen, dass ich nur ein uraltes virtuelles Windows irgendwo liegen habe und deswegen noch kein recover versucht habe.
Gruß
maceis
Zuletzt bearbeitet:
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,269
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
Einfach auf genau demselben Weg noch einmal eine AVM-Firmware installieren ... im Gegensatz zum AVM-Recovery-Programm bleiben dann die Einstellungen und der NAS-Inhalt erhalten.
Manchmal lesen die Leute aber auch nicht gründlich (soll zumindest schon mal vorgekommen sein - in anderen Threads) ... nachdem so ein Image in die Box geladen wurde, muß es erst einmal starten dürfen und sich selbst in den NAND-Flash schreiben. Dabei blinkt dann die Info-LED vor sich hin (wie bei jedem anderen Update auch) und wenn das Flashen beendet ist, startet die Box noch einmal von selbst (man sieht auch das an den LEDs), diesmal aus dem Flash-Speicher.
Es ist zwar (theoretisch) auch denkbar, ein nicht funktionierendes Image zu erzeugen und in die Box zu übertragen ... aber ich würde (aus leidfoller Ervahrung) eher auf ein Problem bei der Anwendung tippen und bei einem AVM-Image anstelle des Freetz-Images kann nun eigentlich gar nichts mehr schiefgehen. Erst dann, wenn das AVM-Image auch nicht starten will, würde ich über "firmware_info" noch den (NAS-)NAND-Flash löschen lassen (da hängt meine 7490 auch gerne mal, zumindest wenn der Füllstand dort hoch ist) ... ansonsten kann da eigentlich nur wenig schiefgehen und ein "Leider startet die Box trotzdem(?) nicht mehr(?)." ist als Beschreibung auch nicht sehr hilfreich. Solange also der FTP-Server im Bootloader noch erreichbar ist, würde ich das als Allererstes noch einmal wiederholen mit dem Freetz-Image und dabei dann einfach einmal beobachten, was die LEDs so anzeigen - das kann man dann im Anschluß hier sogar schriftlich festhalten und dann können andere vielleicht auch eine Idee entwickeln, wo es am Ende klemmen könnte.
Manchmal lesen die Leute aber auch nicht gründlich (soll zumindest schon mal vorgekommen sein - in anderen Threads) ... nachdem so ein Image in die Box geladen wurde, muß es erst einmal starten dürfen und sich selbst in den NAND-Flash schreiben. Dabei blinkt dann die Info-LED vor sich hin (wie bei jedem anderen Update auch) und wenn das Flashen beendet ist, startet die Box noch einmal von selbst (man sieht auch das an den LEDs), diesmal aus dem Flash-Speicher.
Es ist zwar (theoretisch) auch denkbar, ein nicht funktionierendes Image zu erzeugen und in die Box zu übertragen ... aber ich würde (aus leidfoller Ervahrung) eher auf ein Problem bei der Anwendung tippen und bei einem AVM-Image anstelle des Freetz-Images kann nun eigentlich gar nichts mehr schiefgehen. Erst dann, wenn das AVM-Image auch nicht starten will, würde ich über "firmware_info" noch den (NAS-)NAND-Flash löschen lassen (da hängt meine 7490 auch gerne mal, zumindest wenn der Füllstand dort hoch ist) ... ansonsten kann da eigentlich nur wenig schiefgehen und ein "Leider startet die Box trotzdem(?) nicht mehr(?)." ist als Beschreibung auch nicht sehr hilfreich. Solange also der FTP-Server im Bootloader noch erreichbar ist, würde ich das als Allererstes noch einmal wiederholen mit dem Freetz-Image und dabei dann einfach einmal beobachten, was die LEDs so anzeigen - das kann man dann im Anschluß hier sogar schriftlich festhalten und dann können andere vielleicht auch eine Idee entwickeln, wo es am Ende klemmen könnte.
maceis
Mitglied
- Mitglied seit
- 9 Apr 2006
- Beiträge
- 687
- Punkte für Reaktionen
- 4
- Punkte
- 18
Zunächst mal, Danke für Deine Unterstützung.
Die Box befand sich zu Beginn in Werkseinstellung.
Da gibts also nichts zu verlieren und der NAS Speicher müsste eigentlich ziemlich leer sein.
Meine Beobachtungen:
Die Box durfte natürlich schon mehrmals neu starten, dabei habe ich in einem Terminalfenster einen Ping laufen, damit ich sehe wann das Netzwerk hochkommt.
Nach dem "./eva_to_memory ..." blinkt die Info LED einige Sekunden lang schnell, dann blinkt nur doch die Power LED.
Nach ca. 2 Minuten bekomme ich vier bis 5 ping Antworten, dann kommt zwei Minuten lang keine Antwort mehr.
Dann kommen wieder 4 bis 5 ping Antworte und der Vorgang wiederholt sich etwa im zwei Minuten Rhythmus.
Während der ping Antworten zeigt mir ein map auf die Box, dass Port 21 offen ist.
Ich kann ich dann auch mit ftp ... verbinden.
Ich hab auch schon mehrmals und mit zwei verschiedenen Freetz Images den Vorgang wiederholt.
Ihr könnt das natürlich nicht wissen, aber bevor ich hier nachfrage, probier ich immer wiederholt, um eigene Flüchtigkeitsfehler ausschließen zu können.
Kaum etwas wäre mir peinlicher, als hier "dumme" Fragen zu stellen, nur um dann festzustellen, dass es sich um einen einfachen Eingabefehler handelt.
Ich probier jetzt mal Deinen Tipp mit dem Original AVM Image.
Wenn Du Lust hast, könntest Du mal vorsorglich beschreiben (oder steht das vielleicht sogar schon irgendwo beschrieben?), wie man mit "firmware_info den NAND Flash löscht", obwohl der Füllstand dort minimal sein sollte (s. oben).
Danke und Gruß
maceis
- - - Aktualisiert - - -
So, ich hab jetzt folgendes gemacht:
Danach kommt der Prompt wieder.
Ich vermisse die Zeile:
Image uploaded to device.
Die Info LED blinkt (natürlich?) jetzt nicht mehr schnell und die Box bleibt bis zum Stecker ziehen per ftp erreichbar. Beim wieder Einstecken, geht es wieder mit dem oben beschriebenen 2-Minuten Rhythmus los.
Die Box befand sich zu Beginn in Werkseinstellung.
Da gibts also nichts zu verlieren und der NAS Speicher müsste eigentlich ziemlich leer sein.
Meine Beobachtungen:
Die Box durfte natürlich schon mehrmals neu starten, dabei habe ich in einem Terminalfenster einen Ping laufen, damit ich sehe wann das Netzwerk hochkommt.
Nach dem "./eva_to_memory ..." blinkt die Info LED einige Sekunden lang schnell, dann blinkt nur doch die Power LED.
Nach ca. 2 Minuten bekomme ich vier bis 5 ping Antworten, dann kommt zwei Minuten lang keine Antwort mehr.
Dann kommen wieder 4 bis 5 ping Antworte und der Vorgang wiederholt sich etwa im zwei Minuten Rhythmus.
Während der ping Antworten zeigt mir ein map auf die Box, dass Port 21 offen ist.
Ich kann ich dann auch mit ftp ... verbinden.
Ich hab auch schon mehrmals und mit zwei verschiedenen Freetz Images den Vorgang wiederholt.
Ihr könnt das natürlich nicht wissen, aber bevor ich hier nachfrage, probier ich immer wiederholt, um eigene Flüchtigkeitsfehler ausschließen zu können.
Kaum etwas wäre mir peinlicher, als hier "dumme" Fragen zu stellen, nur um dann festzustellen, dass es sich um einen einfachen Eingabefehler handelt.
Ich probier jetzt mal Deinen Tipp mit dem Original AVM Image.
Wenn Du Lust hast, könntest Du mal vorsorglich beschreiben (oder steht das vielleicht sogar schon irgendwo beschrieben?), wie man mit "firmware_info den NAND Flash löscht", obwohl der Füllstand dort minimal sein sollte (s. oben).
Danke und Gruß
maceis
- - - Aktualisiert - - -
So, ich hab jetzt folgendes gemacht:
Danach kommt der Prompt wieder.
Ich vermisse die Zeile:
Image uploaded to device.
Die Info LED blinkt (natürlich?) jetzt nicht mehr schnell und die Box bleibt bis zum Stecker ziehen per ftp erreichbar. Beim wieder Einstecken, geht es wieder mit dem oben beschriebenen 2-Minuten Rhythmus los.
Zuletzt bearbeitet:
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,269
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
Bei einem Inhalt von "recovered=2" in "firmware_info" (wenn da noch eine Versionsnummer steht, wird das mit einem Komma abgetrennt von ihr) formatiert die Firmware den NAND-Speicher (für NAS) neu.
Zwei Minuten sind allerdings eine sehr lange Zeit ... in diesem Zeitraum sollte die Box tatsächlich bereits komplett gestartet sein und - egal was da ansonsten noch passiert - wenigstens auch mal die LEDs fürs WLAN angeworfen haben.
Das schnelle Blinken der Info-LED dürfte/sollte der Schreibvorhgang sein ... aber vor dem Blinken der Power-LED sollte dann eigentlich noch ein Neustart erfolgen - zu erkennen am kurzen Aufblinken aller LEDs gleichzeitig (steht oben aber so nicht). Das irritiert mich aber heftig ... normalerweise wird die Info-LED nach dem Flashen erst unmittelbar vor dem "reboot"-Kommando wieder abgeschaltet.
Es gibt zwar im (neuen) Shell-Skript zum Flashen auch noch die Möglichkeit, sich den Erfolg über den Upload auf einen TFTP-Server "bestätigen" zu lassen, aber das wäre erst dann für mich ein Mittel der Wahl (außer ich habe das alles schon beisammen, was man dafür braucht), wenn nichts anderes mehr geht.
Wenn die Beobachtung/Beschreibung der LEDs nur falsch war und die Box nach dem Flashen tatsächlich neu startet, kann man auch noch einmal über EVA den Inhalt von "firmware_info" löschen ... startet dann überhaupt ein init-Prozess auf der Box, wird sehr früh bei der Initialisierung diese Variable mit der Versionsnummer der gestarteten Firmware neu geschrieben und kann beim nächsten Start als "Anzeiger" verwendet werden, daß die Box darüber hinwegkam.
Ansonsten kann man auch mit einer älteren Version (solange diese dieselben TFFS-Strukturen verwendet, es sollte also schon ein 3.10er-Kernel sein und mithin mindestens eine 06.5x) ein ggf. vorhandenes Protokoll für "crashes" oder "kernel panic" über die Support-Daten auslesen - wie gesagt: In den angegebenen zwei Minuten müßte die FRITZ!Box schon lange bis zum Start der USB-Devices (auch da hilft es ggf., wenn man einen Stick mit einer LED verwendet, bei der man den erfolgten Zugriff dann sehen kann) gekommen sein, wenn alles mit rechten Dingen zugeht.
Als Vergleich mal der "Zeitplan" einer 7490, nachdem der Kernel gestartet wurde (also anhand der Ausgaben in /proc/kmsg; da kommen also noch ein paar wenige Sekunden für das Entpacken des Kernels ins RAM dazu):
In der relativ langen "Pause" von 20 bis 80 wird in erster Linie der DSL-Teil gestartet (E40-dsl) und noch ein paar "Kleinigkeiten", die man aber von außen nicht richtig erkennen kann - vielleicht sieht man noch das Initialisieren des (internen) S0-Bus, wenn man da ein ISDN-Gerät angeschlossen hat (wenn die 7362SL überhaupt internes ISDN hat). Aber schon dabei sollte eben die Power-LED beim Beginn der DSL-Synchronisation ihren Rhythmus beim Blinken wechseln ... von langsamem Ein/Aus zu zwei kurzen Ein, gefolgt von einem längeren Aus - auch das kann ich oben irgendwie nicht erkennen. Bleibt wieder die Frage, ob die Box gar nicht bis zu diesem Punkt kommt oder ob die Beschreibung zu ungenau war/ist.
Jedenfalls ist so ein Dauer-"ping" ohnehin das denkbar schlechteste Diagnosewerkzeug ... da ist sogar ein Switch noch genauer, weil der dann irgendwann das "media sense" anzeigt. Die Gründe für ausbleibende Antworten auf ein "ping" können eben vielfältig sein und man kann aus dem Fehlen einer solchen Antwort praktisch nicht darauf schließen, wo die Box nun gerade sein könnte bei ihrer Initialisierung.
Die angegebenen Zeiten sind auch nur "Richtwerte", die schwanken je nach Ausstattung der Box und nach angeschlossener Peripherie bzw. nach Verbindungen zur Außenwelt - aber daß sich über 120 Sekunden bei einer startenden FRITZ!Box außer der Power-LED so gar nichts rührt (kein USB und nichts) und es nicht einmal das "andere Blinken" beim Versuch der Synchronisation gibt, ist schon sehr ungewöhnlich.
Von der Beschreibung mit den vier oder fünf ICMP-Replies her würde ich auf WLAN-Probleme tippen (das kommt halt direkt nach dem LAN), wenn ich mir denn sicher wäre, daß das nicht nur die Antworten des Bootloaders bei irgendeinem erneuten Startversuch sind - da aber auch der sich durch das gleichzeitige kurze "Aufflackern" aller LEDs ankündigt (erst recht bei einer Boot-Schleife), bin ich ggü. der bisherigen Schilderung halt noch sehr skeptisch.
- - - Aktualisiert - - -
Bei allem (ohnehin nicht übermächtigen) Verständnis für "ich kann nicht alles gleichzeitig lesen" ... aber ein "normales" AVM-Image direkt auf die Box zu laden, ohne es erst mit "image2ram" umzuwandeln, zeugt auch davon, daß Du hier in diesem sehr kurzen Thread (und sogar in den mehr oder weniger an Dich gerichteten Antworten) schlicht "nicht aufgepaßt" hast.
Außerdem kann man bei jedem Bootversuch nur ein einziges Mal ein Image hochladen ... hier gab es mindestens zwei Versuche. Man sieht es daran, daß der installierte Speicher bereits um die Größe des Images verringert wurde - normalerweise würde der bis 0x90000000 gehen.
- - - Aktualisiert - - -
Theoretisch funktionieren vielleicht sogar mehrere Image-Uploads - solange die integralen Grenzen stimmen. Aber auch darauf würde ich mich erst dann verlassen, wenn ich es selbst erfolgreich getestet habe und da Du hier ja noch auf der Suche nach dem Stein der Weisen bist, der das überhaupt erst einmal ins Rollen bringen soll, würde ich nicht gleich mit einer Übung für "advanced users" starten.
Zwei Minuten sind allerdings eine sehr lange Zeit ... in diesem Zeitraum sollte die Box tatsächlich bereits komplett gestartet sein und - egal was da ansonsten noch passiert - wenigstens auch mal die LEDs fürs WLAN angeworfen haben.
Das schnelle Blinken der Info-LED dürfte/sollte der Schreibvor
Es gibt zwar im (neuen) Shell-Skript zum Flashen auch noch die Möglichkeit, sich den Erfolg über den Upload auf einen TFTP-Server "bestätigen" zu lassen, aber das wäre erst dann für mich ein Mittel der Wahl (außer ich habe das alles schon beisammen, was man dafür braucht), wenn nichts anderes mehr geht.
Wenn die Beobachtung/Beschreibung der LEDs nur falsch war und die Box nach dem Flashen tatsächlich neu startet, kann man auch noch einmal über EVA den Inhalt von "firmware_info" löschen ... startet dann überhaupt ein init-Prozess auf der Box, wird sehr früh bei der Initialisierung diese Variable mit der Versionsnummer der gestarteten Firmware neu geschrieben und kann beim nächsten Start als "Anzeiger" verwendet werden, daß die Box darüber hinwegkam.
Ansonsten kann man auch mit einer älteren Version (solange diese dieselben TFFS-Strukturen verwendet, es sollte also schon ein 3.10er-Kernel sein und mithin mindestens eine 06.5x) ein ggf. vorhandenes Protokoll für "crashes" oder "kernel panic" über die Support-Daten auslesen - wie gesagt: In den angegebenen zwei Minuten müßte die FRITZ!Box schon lange bis zum Start der USB-Devices (auch da hilft es ggf., wenn man einen Stick mit einer LED verwendet, bei der man den erfolgten Zugriff dann sehen kann) gekommen sein, wenn alles mit rechten Dingen zugeht.
Als Vergleich mal der "Zeitplan" einer 7490, nachdem der Kernel gestartet wurde (also anhand der Ausgaben in /proc/kmsg; da kommen also noch ein paar wenige Sekunden für das Entpacken des Kernels ins RAM dazu):
| Zeit | Aktion |
| 2 | Switch wird initialisiert, spätestens hier geht das Interface auf "nicht bereit", ggf. schon vorher |
| 10 | LED-Treiber wird geladen, normalerweise beginnt hier dann die Power-LED langsam zu blinken (nicht das Doppelblinken bei der DSL-Synchronisation, das kommt erst später) |
| 11-18 | ISDN und DECT wird initialisiert (binäre Komponenten werden in die Prozessoren übertragen) |
| 18 | YAFFS2-Dateisystem für den NAS-Speicher wird gemountet |
| 80 | USB-Geräte werden eingebunden - die Anzahl der USB-Geräte verschiebt dann weitere Aktionen ... bei mir gibt es zwei Geräte, einen 16 GB-Stick und eine HDD mit zwei ext3-Partitionen´und einer Swap-Partition |
| 95 | Netzwerk wird gestartet (ungefähr hier sollte dann auch auf "ping" geantwortet werden) |
| 98 | WLAN wird gestartet (WLAN-LED sollte blinken), dauert zwischen 10 und 30 Sekunden |
In der relativ langen "Pause" von 20 bis 80 wird in erster Linie der DSL-Teil gestartet (E40-dsl) und noch ein paar "Kleinigkeiten", die man aber von außen nicht richtig erkennen kann - vielleicht sieht man noch das Initialisieren des (internen) S0-Bus, wenn man da ein ISDN-Gerät angeschlossen hat (wenn die 7362SL überhaupt internes ISDN hat). Aber schon dabei sollte eben die Power-LED beim Beginn der DSL-Synchronisation ihren Rhythmus beim Blinken wechseln ... von langsamem Ein/Aus zu zwei kurzen Ein, gefolgt von einem längeren Aus - auch das kann ich oben irgendwie nicht erkennen. Bleibt wieder die Frage, ob die Box gar nicht bis zu diesem Punkt kommt oder ob die Beschreibung zu ungenau war/ist.
Jedenfalls ist so ein Dauer-"ping" ohnehin das denkbar schlechteste Diagnosewerkzeug ... da ist sogar ein Switch noch genauer, weil der dann irgendwann das "media sense" anzeigt. Die Gründe für ausbleibende Antworten auf ein "ping" können eben vielfältig sein und man kann aus dem Fehlen einer solchen Antwort praktisch nicht darauf schließen, wo die Box nun gerade sein könnte bei ihrer Initialisierung.
Die angegebenen Zeiten sind auch nur "Richtwerte", die schwanken je nach Ausstattung der Box und nach angeschlossener Peripherie bzw. nach Verbindungen zur Außenwelt - aber daß sich über 120 Sekunden bei einer startenden FRITZ!Box außer der Power-LED so gar nichts rührt (kein USB und nichts) und es nicht einmal das "andere Blinken" beim Versuch der Synchronisation gibt, ist schon sehr ungewöhnlich.
Von der Beschreibung mit den vier oder fünf ICMP-Replies her würde ich auf WLAN-Probleme tippen (das kommt halt direkt nach dem LAN), wenn ich mir denn sicher wäre, daß das nicht nur die Antworten des Bootloaders bei irgendeinem erneuten Startversuch sind - da aber auch der sich durch das gleichzeitige kurze "Aufflackern" aller LEDs ankündigt (erst recht bei einer Boot-Schleife), bin ich ggü. der bisherigen Schilderung halt noch sehr skeptisch.
- - - Aktualisiert - - -
Bei allem (ohnehin nicht übermächtigen) Verständnis für "ich kann nicht alles gleichzeitig lesen" ... aber ein "normales" AVM-Image direkt auf die Box zu laden, ohne es erst mit "image2ram" umzuwandeln, zeugt auch davon, daß Du hier in diesem sehr kurzen Thread (und sogar in den mehr oder weniger an Dich gerichteten Antworten) schlicht "nicht aufgepaßt" hast.
Außerdem kann man bei jedem Bootversuch nur ein einziges Mal ein Image hochladen ... hier gab es mindestens zwei Versuche. Man sieht es daran, daß der installierte Speicher bereits um die Größe des Images verringert wurde - normalerweise würde der bis 0x90000000 gehen.
- - - Aktualisiert - - -
Theoretisch funktionieren vielleicht sogar mehrere Image-Uploads - solange die integralen Grenzen stimmen. Aber auch darauf würde ich mich erst dann verlassen, wenn ich es selbst erfolgreich getestet habe und da Du hier ja noch auf der Suche nach dem Stein der Weisen bist, der das überhaupt erst einmal ins Rollen bringen soll, würde ich nicht gleich mit einer Übung für "advanced users" starten.
Zuletzt bearbeitet:
maceis
Mitglied
- Mitglied seit
- 9 Apr 2006
- Beiträge
- 687
- Punkte für Reaktionen
- 4
- Punkte
- 18
Okay, das Freetz image ist jetzt auf der Box - Halleluja!
Ich kann allerdings nicht behaupten, zu wissen, wie genau ich das geschafft habe.
Ja, Du hast recht, ich hab das zwischendurch auch mehrmals hintereinander ohne Neustart versucht, dann aber nach Neustart nochmal von vorne.
Hat aber leider auch nicht zum Erfolg geführt.
Jedenfalls habe ich dann versucht ein Recover durchzuführen, was jedoch mit Fehlermeldung (Firmware der Fritzbox 7490 ist mit der Recover Firmware inkompatibel) beendet wurde. Durch diesen Thread angeregt habe ich die Variablen firmware_version auf avme und firmware_info auf 113.06.83 gesetzt und die recover.exe nochmal laufen lassen.
Da kam dann:
In firmware_info stand dann mal "113.06.83,recovered=3" und kurz darauf gar nichts mehr.
Irgendwann habe ich das Recover abgebrochen.
Dann hab ich wieder auf die Box geschaut und gesehen, dass die WLAN LED an ist und hab ein nmap gemacht.
Als ich gesehen hatte, dass jede Menge Ports offen waren, hab ich mich am Webinterface angemeldet, und siehe da, Freetz war drauf.
Nochmal vielen herzlichen Dank für Deine Geduld und Unterstützung.
Ich verstehe, dass Du manchmal leicht genervt bist, wenn ich (oder andere) so schwer von Begriff sind und / oder nicht genau lesen (oder "aufpassen", wie Du sagst).
Soll jetzt keine Ausrede sein, aber ich hatte einen stressigen Tag und meine Aufmerksamkeit ist auch nicht grenzenlos.
Morgen muss ich wieder arbeiten (eigentlich sollte ich nur Mo-Fr arbeiten müssen) und ich wollte halt noch nicht aufgeben.
Wenn ich mir konzentriert anlesen könnte, wie z. B. der Bootvorgang genau abläuft, wie der Bootloader funktioniert, wie freetz im Detail arbeitet und solche Sachen, würde ich das gerne machen. Ist aber mit einer zugegeben schwachen Basis im Selbststudium leider nicht ganz einfach, die verfügbare Informationsflut zu sortieren und zu filtern.
Ich bin jedenfalls froh, dass ich diese Hürde auch irgendwie überwunden habe.
Hätte ich ohne Hilfe sicher nicht geschafft.
Danke nochmal und Gruß
maceis
Ich kann allerdings nicht behaupten, zu wissen, wie genau ich das geschafft habe.
Ja, Du hast recht, ich hab das zwischendurch auch mehrmals hintereinander ohne Neustart versucht, dann aber nach Neustart nochmal von vorne.
Hat aber leider auch nicht zum Erfolg geführt.
Jedenfalls habe ich dann versucht ein Recover durchzuführen, was jedoch mit Fehlermeldung (Firmware der Fritzbox 7490 ist mit der Recover Firmware inkompatibel) beendet wurde. Durch diesen Thread angeregt habe ich die Variablen firmware_version auf avme und firmware_info auf 113.06.83 gesetzt und die recover.exe nochmal laufen lassen.
Da kam dann:
Das wiederholte sich zig male.
In firmware_info stand dann mal "113.06.83,recovered=3" und kurz darauf gar nichts mehr.
Irgendwann habe ich das Recover abgebrochen.
Dann hab ich wieder auf die Box geschaut und gesehen, dass die WLAN LED an ist und hab ein nmap gemacht.
Als ich gesehen hatte, dass jede Menge Ports offen waren, hab ich mich am Webinterface angemeldet, und siehe da, Freetz war drauf.
Nochmal vielen herzlichen Dank für Deine Geduld und Unterstützung.
Ich verstehe, dass Du manchmal leicht genervt bist, wenn ich (oder andere) so schwer von Begriff sind und / oder nicht genau lesen (oder "aufpassen", wie Du sagst).
Soll jetzt keine Ausrede sein, aber ich hatte einen stressigen Tag und meine Aufmerksamkeit ist auch nicht grenzenlos.
Morgen muss ich wieder arbeiten (eigentlich sollte ich nur Mo-Fr arbeiten müssen) und ich wollte halt noch nicht aufgeben.
Wenn ich mir konzentriert anlesen könnte, wie z. B. der Bootvorgang genau abläuft, wie der Bootloader funktioniert, wie freetz im Detail arbeitet und solche Sachen, würde ich das gerne machen. Ist aber mit einer zugegeben schwachen Basis im Selbststudium leider nicht ganz einfach, die verfügbare Informationsflut zu sortieren und zu filtern.
Ich bin jedenfalls froh, dass ich diese Hürde auch irgendwie überwunden habe.
Hätte ich ohne Hilfe sicher nicht geschafft.
Danke nochmal und Gruß
maceis
Neueste Beiträge
-
Fritz!DECT 302 regelt nicht mehr- Letzte: Jstessi
-
[Problem] FritzBox 7590 2,4GHz WLAN nur noch sehr sehr schwach- Letzte: Zwanzigeinundzwanzig
-
7590 flashen stor mtd1 funktioniert nicht
- Letzte: KunterBunter
-
[Sammlung] Fritz!Box 5690Pro, Inhaus/Labor 7.90, Pfad 'Smart24P1FCS'- Letzte: QBiT|RAMOC
-
[Frage] Voip und VPN
- Letzte: Multireed
