[HowTo] Flash-Script für 7490

Christoph_F

Neuer User
Mitglied seit
5 Dez 2006
Beiträge
80
Punkte für Reaktionen
1
Punkte
8
Hallo,

wie man weiß, verweigert die 7490 mit neuerer AVM-Software die Installation unsignierter Versionen über die Web-Oberfläche und „push_firmware“ aus Freetz funktioniert auch nicht bei diesem Modell.

Für letzteres habe ich mir einen – recht primitiven – Ersatz gebastelt; die Ideen und Programmschnipsel dafür stammen aus hiesigen Threads von PeterPawn, dessen „YourFritz“ und „push_firmware“ aus Freetz. Soweit bei jenen Werken Nutzungsbedingungen genannt sind, handelt es sich um die GPL Version 2 und somit steht das hier als davon abgeleitetes Werk auch unter der GPLv2. Es ist also ausdrücklich gestattet, das auch Nicht-Privat weiterzuverwenden und dabei zu verändern.

Eine Warnung vorweg: die meisten Sicherheits-Überprüfungen habe ich weggelassen, man kann also Unsinn damit machen, insbesondere inkompatible Firmware auf die Box schreiben.
Getestet ist es nur unter Debian (so ungefähr Jessie) x86/x86_64 Multiarch, also Linux.

Es besteht aus 2 Teilen: zunächst einem Progrämmchen, das nur dazu dient, die Box nach dem Start im EVA-Modus „abzufangen“ und diesen aufrechtzuerhalten, es wird sich einfach an- und wieder abgemeldet. Das habe ich eigenständig gelassen, weil es auch zu anderen Zwecken nützlich ist, beispielsweise um danach von Hand zwischen den beiden alternativen Firmware-Speicherplätzen der 7490 umzuschalten.

eva-login.sh:
Code:
#!/bin/sh
ip="192.168.178.1"
for ARG in $@
do
 if [ ! x"$ARG" = x ]
 then
  ip="$ARG"
 fi
done
#echo "Warte auf Ausschalten von „$ip“…"
#while ping -c1 -w1 $ip > /dev/null
#do
# echo -n "·"
# sleep 0.2
#done
#echo " Keine Antwort mehr."
echo "Warte auf Einschalten von „$ip“…"
while ! ping -c1 -w1 $ip > /dev/null
do
 echo -n "."
 sleep 0.2
done
echo " $ip gefunden!"
ftp -n -p<<ENDE
open $ip
user adam2 adam2
debug
quit
ENDE

Die Funktionsweise ist von „push_firmware“ aus Freetz übernommen, aber ohne den ganzen Schnickschnak mit Überprüfungen und der Dateiübertragung an sich.

Ohne Parameter wird die Standard-IP-Adresse „192.168.178.1“ angenommen, jeder andere übergebene Wert wird als auflösbarer Name oder IP-Adresse verwendet.
Gibt man hier Blödsinn an, wird der Ping stets fehlschlagen und man muß mit Strg-C abbrechen.

Benötigt werden die Kommandos „ping“ und „ftp“, die installiert sein müssen, auch das wird nicht geprüft, es klappt halt einfach nicht, wenn diese nicht da oder von den Parametern her inkompatibel sind.
Der auskommentierte Teil wird nur dann benötigt, wenn man das Skript erst startet und dann die Box neu startet und die Box im Normalmodus dieselbe IP hat wie im EVA-Modus direkt nach dem Einschalten. Jener Abschnitt wartet so lange, bis die Box nicht mehr antwortet und geht dann sofort im nächsten Abschnitt zum Warten auf die nächste Antwort über, die kommt, sobald im EVA-Modus ein Ping empfangen wurde. Für jeden Ping-Versuch wird ein · gemalt.

Sobald die Box (wieder) antwortet, endet die Schleife und es meldet sich per FTP an und wieder ab. Von diesem Zeitpunkt an läuft der normale Startvorgang der Box nicht mehr weiter, man kann sich später jederzeit erneut per FTP anmelden.

Das eigentliche Datei-Übertragungs-Programm ruft das obige Skript auf, es muß im Suchpfad liegen oder man muß das 2. Skript so ändern, daß es mit relativem oder absolutem Pfad aufgerufen wird. Alternativ kann man beide in eine Datei zusammenbasteln.

Für die eigentliche Datei-Übertragung wird das folgende Skript benötigt: https://github.com/PeterPawn/YourFritz/blob/master/eva_tools/eva_to_memory

7490install.sh:
Code:
#!/bin/sh
VR="./var"
VT="$VR/tmp"
KI="$VT/kernel.image"
FI="$VT/filesystem.image"
IP="192.168.178.1"
for ARG in $@
do
 if [ -f "$ARG" ]
 then
  FIMG="$ARG"
 else
  IP="$ARG"
 fi
done
if [ -f "$FIMG" ]
then
 tar xvf "$FIMG"
 if [ -d "$VT" ]
 then
  for IMG in "$KI" "$FI"
  do
   if [ -f "$IMG" ]
   then
    dd iflag=count_bytes bs=256 if="$IMG" of="$IMG.tmp" count=$(( `stat --printf=%s "$IMG"`-8 ))
   fi
  done
  cat "$KI.tmp" "$FI.tmp" > "$FIMG.eva"
  rm -rfv "$VR"
  eva-login.sh "$IP"
  eva_to_memory "$FIMG.eva" "$IP"
 fi
fi

Der 2. Teil braucht bis zu 2 Übergabeparameter, nämlich einen Dateinamen und die IP-Adresse, falls es nicht oben genannte Standardadresse ist.

Alles, was kein gültiger Dateiname (mit Pfadangabe, falls nicht im aktuellen Verzeichnis) einer existierenden Datei ist, wird als IP/Rechnername behandelt, auch wenn das Unsinn ist. In dem Fall schlüge wieder der Ping fehl und man müßte abbrechen. Die Reihenfolge der beiden Parameter ist egal, gibt man aber mehr als 2 an, hängt von deren Reihenfolge ab, was danach genau passiert, falls etwas sinnvolles, dann würde man das auch mit genau 1-2 Parametern hinbekommen. Ohne gültigen Dateinamen geschieht überhaupt nichts.

Hat man einen Dateinamen übergeben und existiert diese Datei, wird versucht, sie im aktuellen Verzeichnis mit Tar auszupacken. Dabei wird ein Verzeichnis „./var“ mit Unterverzeichnissen erzeugt. Schlägt das fehl, werden auch nachfolgende Aktionen scheitern – abgesehen davon, die Box im EVA anzuhalten.

Geht alles gut, werden aus „./var/tmp“ der Kernel und das Dateisystem jeweils um die angehängte Prüfsumme von 8 Bytes gekürzt, diese beiden Dateien dann zusammengefügt und das Ergebnis als „$FIMG.eva“ gespeichert. Dazu muß das Verzeichnis, in dem „$FIMG“ liegt, die als Parameter übergebene Firmware-Datei, vom aufrufenden Benutzer beschreibbar sein. Danach wird die ausgepackte Datei und deren temporärer Inhalt unterhalb von „./var“ wieder gelöscht.

Für diese Aktionen werden die Kommandos „tar“, „dd“, „stat“, „cat“, „rm“ benötigt, die im Pfad liegen müssen. Die verwendete Shell muß rechnen können, um 8 Bytes von der Dateilänge abzuziehen. Der Vorgang braucht auch genügend freien Platz: temporär etwa 3 Mal die Firmware-Größe.

Nunmehr folgt die Anmeldung an der Box, danach die Übertragung der gerade erstellten Datei in deren Speicher mit Hilfe von „eva_to_memory“; wie das funktioniert, kann man hier nachlesen: http://www.ip-phone-forum.de/showthread.php?t=283039&p=2147416&viewfull=1#post2147416.

Beispiel-Aufruf:
7490install.sh ./FRITZ.Box_7490.113.06.30.image 203.0.113.5
Das erstellt ./FRITZ.Box_7490.113.06.30.image.eva und überträgt es zum Router mit der Adresse 203.0.113.5.
Die erstellte Datei bleibt auch lokal erhalten, nur die entpackte Firmware und Zwischenprodukte werden wieder gelöscht.
Es ist die Adresse anzugeben, welche der Router beim Startvorgang annimmt; wenn man ihm nur in der Weboberfläche einen von der AVM-Vorgabe abweichenden Adreßbereich vergeben hat, ist das immer noch 192.168.178.1! Der Rechner, von dem aus das Update gemacht werden soll, muß eine Adresse im selben Subnetz haben, beziehungsweise muß eine Route zum Ziel bestehen.
Die Einstellungen bleiben wie bei einem normalen Update erhalten, soweit die neu geflashte Version sie „versteht“.

- - - Aktualisiert - - -

Anmerkung: ich hätte auch „image2ram“ aus „YourFritz“ nehmen können, um die Datei umzuwandeln, das macht ein paar Prüfungen, scheint mir dafür aber länger zu laufen.

- - - Aktualisiert - - -

Zu den Voraussetzungen:
Das „eva_to_memory“ braucht zwingend das OpenBSD-Netcat! Das aus Busybox, die „klassische“ Version 1.10 oder „Netcat6“ funktionieren nicht! Wer wie ich Debian verwendet, muß also mit „update-alternatives“ bei mehreren installierten Versionen die richtige davon als „nc“ einstellen, oder anders sicherstellen, daß die OpenBSD-Version als „nc“ gefunden wird!
 
Kurze Frage ... wenn Du "eva_to_memory" verwendest, warum machst Du dann das Auffinden der Box so "unflexibel" und nimmst dafür nicht gleich "eva_discover"?

Dann braucht man keine feste IP-Adresse (man stellt indirekt die FRITZ!Box praktisch auf eine passende Adresse - bereits im Bootloader - ein) und die gesamte Funktion (na gut, fast die gesamte) von "eva_login.sh" ist dort bereits enthalten, bis hin zum Warten auf die Box. Das braucht zwar "socat" (findet man auch in so ziemlich jeder Distribution als Paket), dafür kein "ftp" - auch da ist es nun einmal so, daß die Kommandozeilen-Clients, die sich als "ftp" anheischig machen wollen, noch viel mehr differieren als beim "nc".

Das "nc" kenne ich hauptsächlich in drei Varianten: BSD (das m.E. gebräuchlichste, siehe auch das von mir irgendwo in einer Antwort verlinkte "man"-File, das genau diese Variante beschreibt), netcat 1.10 bzw. 0.7.1 (netcat-traditional) und das aus der BusyBox - wenn möglich, versuche ich mich auf letzteres zu beschränken, das geht aber nicht immer, weil einige Versionen eben beim EOF auf STDIN sofort die Verbindung mit "FIN" einseitig schließen und dann einige Serverprogramme ihre Übertragungen einfach abbrechen und ebenfalls mit "FIN" komplett beenden - hier war ich tatsächlich schon am Überlegen, ob man nicht anstelle von "nc" besser ebenfalls auf "socat" setzen sollte, aber das muß man für die Benutzung auf der Box selbst (wo meine Skripte i.d.R. auch arbeiten können) gesondert bereitstellen.

Beim FTP-Zugriff zum "Anhalten" des Startvorgangs braucht man kein Login mit Benutzernamen und Kennwort, es reicht bereits die Verbindung an sich, das macht ansonsten auch der Parameter "HOLD=1" bei "eva_discover", ist aber auch unnötig, wenn man hinterher ohnehin gleich automatisch mit der Box kommuniziert, weil das dann i.d.R. "im Zeitfenster" erfolgen wird. Da es keiner Anmeldung bedarf, würde ich beim Anhalten des Startvorgangs auch nicht auf das "ftp" zurückgreifen - man spart sich eine Abhängigkeit und eine potentielle Fehlerquelle, wenn man das einfach ebenfalls mit "nc" macht.

BTW ... auch für die Umschaltung zwischen beiden Systemen gibt es das Skript "eva_switch_system" als Beispiel, wie man "eva_discover" selbst in anderen Skript-Dateien verwenden kann und sich sein eigenes basteln könnte.

Zum Abschneiden der Prüfsumme:

  • das braucht es (wenn schon "image2ram" zu langsam ist für die eigenen Ansprüche) auch nur für die "kernel.image", jedenfalls wenn es um das Abschneiden an sich geht
  • nach meiner Ansicht ist es etwas zu optimistisch, immer davon auszugehen, daß eine solche vorhanden ist, wobei das bei der 7490 sogar noch der Fall sein könnte/sollte ... im Prinzip kann man auf diesem Wege aber auch einen Kernel und ein Dateisystem für eine NOR-Box laden, die man zuvor zerlegt hat (weil man das Dateisystem noch modifiziert hat) und dort gäbe es keine Prüfsummen
  • auch das "iflags" ist etwas sehr optimistisch (https://www.gnu.org/software/coreutils/manual/html_node/dd-invocation.html), diese Flags sind längst nicht auf allen Plattformen auch verfügbar ("These flags are not supported on all systems [...]")
  • wenn man das Dateisystem-Image gar nicht mehr umkopiert (dort stören die 8 Byte Prüfsumme nicht wirklich und das endet auch nicht automatisch an einer integralen Grenze), spart man sich auch noch Zeit und (temporären) Speicherplatz, ich habe das in "image2ram" auch nur der Vollständigkeit halber eingebaut, weil es mir da tatsächlich nicht um Geschwindigkeit ging, sondern um Kompatibilität (dazu komme ich gleich noch) und die Kommando, die etwas länger brauchen könnten (das sind die zwei "dd" mit "bs=4"), die funktionieren eben auch mit dem "dd" der BusyBox (das kennt gar kein "iflags" oder "oflags")
Das Problem ist allerdings, daß der Code im Kernel, der nach dem Beginn des SquashFS-Images sucht, das nur an einer 256-Byte-Grenze macht und da das Image an das obere Ende des Speichers geladen wird, führt eine "krumme" Größe des Dateisystem-Images (das kommt bei NOR-Modellen schon mal vor bei originaler AVM-Firmware) dazu, daß der Beginn auch nicht an einer passenden Grenze liegt. Das macht es dann doch wieder notwendig, die Prüfsumme zu entfernen - sie würde das Image im Speicher verschieben - und gleichzeitig sichert das Kopieren mit voller Blocklänge dann auch, daß der letzte Block volle 256 Byte enthält - deshalb treibt "image2ram" auch so viel Aufwand, weil es eben nicht nur mit einer Firmware für ein NAND-Modell funktioniert. Wobei die Variante bei mir, die auch NOR-Firmware "verdauen" kann, noch gar nicht veröffentlicht ist (ist mir auch erst jetzt aufgefallen), auch das "image2ram" war mehr als Beispiel gedacht (steht m.E. auch so in dem IPPF-Thread, wo ich es das erste Mal erwähne), um damit das Prinzip zu erklären.
 
Hi Peter,

nur kurz gefragt: Lässt sich Dein YourFritz auch verwenden, um Freetz über eine aktuelle (signierte) FW einer 7390/7490 zu bügeln (Oliver meinte, das "könnte funktionieren" – war sich aber nicht sicher ob und wie)?

Hintergrund: Meine 7390 hat sich ungefragt (trotz abgeschaltetem Update) auf das aktuelle offizielle Fritz!OS aktualisiert. Nach langem hin und her würde mir AVM jetzt zwar eine "downgegradete" 7390 im Austausch schicken – aber nix Backup, nix Restore (oder ist das "alte Freetz" u.U. noch in einer "inaktiven Partition", und könnte reanimiert werden?). Daher mein Gedanke, besser gleich auf 7490 "upzugraden" – vorausgesetzt, ich kann das TR069 dort wieder loswerden, und das eine oder andere Freetz-Paket installieren :smile:
 
Bei der Fritzbox 7390 gibt es keine inaktive Partition und es gibt auch kein modfs von PeterPawn dafür.
Aber man kann jederzeit per Recover auf eine ältere Version downgraden. Warum muss dir da AVM extra eine downgegradete Fritzbox 7390 im Austausch schicken? Machen die das wirklich kostenlos, obwohl du ein uraltes Freetz drauf hast?
 
Wenn ich schon eine Freetz-FW baue fliegt da zuerst TR069 raus (nicht deaktivieren sondern komplett entfernen
 
Der Auto-Update von AVM, bei dem neue Versionen automatisch installiert werden, hat nichts mit TR-069 zu tun und läuft vollkommen unabhängig davon ab.
 
Abgesehen davon macht das Entfernen von TR-069 bei einer aktuellen 7390 das WLAN kaputt, solange man nicht das betreffende Plugin wieder integrieren läßt - was dann seinerseits wieder Platzprobleme nach sich zieht, wenn man nicht mit "externals" arbeitet oder viele weitere Teile der Firmware ebenfalls entfernt - so ganz zum Spaß hat AVM das WLAN ja nicht in ein Plugin verbannt.

Um TR-069 abzuschalten, reichen im Normalfall auch die passenden Einstellungen - wenn man mal das "argo" außen vorläßt, das ist neu und ich durfte auch gerade erst "lernen", daß die Abfrage, ob man den Abruf durch AVM gestatten will, auch eher "pro forma" ist - die Box tut es nämlich auch dann bereits, wenn der Besitzer die betreffende Seite noch gar nicht zu Gesicht bekommen hatte.

Zumindest bis zum Abnicken durch den Besitzer sollte man damit schon warten ... so ein wenig fühlt man sich da wieder einmal versucht, laut "Skandal" zu schreien - das gilt in gewissem Maße auch für das automatische Update. Ich bleibe dabei, daß da in älteren Firmware-Versionen die Einstellung "nur benachrichtigen" nicht immer korrekt arbeitete und auch ich habe FRITZ!Boxen im Zugriff, bei denen entgegen dieser Einstellung das FRITZ!OS aktualisiert wurde, nachdem AVM die Reaktionen auf die Update-Anfrage offenbar geändert hat und die 84.06.51 nunmehr als "erforderliches Update" ausweist.

Wenn man das also verhindern will, ändert man am besten den öffentlichen Schlüssel für die Kontrolle der Signatur einer Antwort des AVM-Update-Services in der Firmware - dann sollte (müßte ich glatt mal testen, ob das auch tatsächlich funktioniert - wenn nicht, wäre das ja wieder ein nettes Einfallstor und die Tatsache, daß die SOAP-Antwort plakativ signiert ist, muß ja noch lange nicht bedeuten, daß diese Prüfung auch tatsächlich korrekt arbeitet) die Antwort des AVM-Servers als ungültig angesehen werden und ein auf diesem Weg angebotenes Update (wenn man nicht gleich die komplette Kommunikation mit dem Anbieter im Hintergrund per Einstellung unterbinden will, was einen dann auch von Updates für DECT-Geräte abschneidet) sollte nicht erneut installiert werden. Bisher zumindest werden die DECT-Updates nicht über diesen Service abgefragt - die sollten also weiterhin entdeckt werden können.
 
Bei der Fritzbox 7390 gibt es keine inaktive Partition und es gibt auch kein modfs von PeterPawn dafür.

Das hatte ich bereits vermutet, war aber nicht sicher. Danke für die Bestätigung!

Aber man kann jederzeit per Recover auf eine ältere Version downgraden. Warum muss dir da AVM extra eine downgegradete Fritzbox 7390 im Austausch schicken?

Man ≠ Man. Theoretisch geht das, in meinem Fall nicht: Kein Windows hier – und die recover.exe gibt's nun einmal nur für Windows. Außerdem würde bei einem regulären Downgrade auch ein Factory-Reset inklusive sein. Die Daten meiner Mods kann ich leider (ohne Freetz) nicht mehr sichern. Das Meiste habe ich zwar, aber die letzten Änderungen nicht mehr. Naja, die krieg ich auch mit der Austauschbox nicht mehr her – aber daher die Hoffnung, das irgendwie über Adam & Eva hinzubiegen.

Machen die das wirklich kostenlos, obwohl du ein uraltes Freetz drauf hast?

In diesem Fall schon. Ist aber sicher eine Ausnahme. Gerade dass ich ein "uraltes Freetz" drauf hatte belegt, dass ich das Auto-Update nicht aktiviert hatte (sonst hätte das bereits früher gegriffen). Also muss es ein Bug im Code sein, der das Malheur verursacht hat: Ein Hacker würde kaum zuerst das System aktualisieren und automatische Updates aktivieren – und ein "Force-Update" seitens AVM gab es nicht.

Wenn ich schon eine Freetz-FW baue fliegt da zuerst TR069 raus (nicht deaktivieren sondern komplett entferne

Ganz genau das ist mein Hauptanliegen. Für (fast) alles andere habe ich mir bereits Workarounds gebaut: Unbound Nameserver auf 'nem Pi (zum Glück gibt es seit der 6.50 die Möglichkeit, per DHCP auch einen internen Nameserver zu kommunizieren – wenn man die Einstellung denn gefunden hat; der Support kannte sie gar nicht), mein DynDNS entsprechend angepasst, dass es auch mit Stock Fritz!OS tut, CallMonitor via "Roger Router" (geplant, da bin ich gerade dran). Nur das TR069 werde ich so nicht los.

Der Auto-Update von AVM, bei dem neue Versionen automatisch installiert werden, hat nichts mit TR-069 zu tun und läuft vollkommen unabhängig davon ab.

Schon klar. Aber der Angriffsvektor vor gut einem Jahr hing u.a. damit zusammen – und so konnte ich mich grinsend zurücklehnen, da er bei mir nicht existierte. Außerdem stellt TR069 nicht zuletzt aufgrund des unsicheren Protokolls ein Sicherheitsproblem dar.
 
@opto:
OK, ich reduziere auf "kann kaputtmachen" ... für das Starten der Plugins wird jedenfalls das Programm "tr069fwupdate" benötigt (siehe /sbin/start_plugin.sh in der Firmware) und das wird ggf. beim Entfernen von TR-069 ebenfalls entsorgt:

http://freetz.org/browser/trunk/patches/scripts/260-remove_tr069.sh#L29

Wann das nun genau erfolgt und wann nicht (sprich, wann FREETZ_REMOVE_TR069_FWUPDATE gesetzt ist), schaue ich jetzt nicht nach ... aber sollte ein Plugin erst noch durch das "tr069fwupdate" für die Signaturprüfung müssen und das Programm fehlt, startet das betreffende Plugin nicht.
 
Abgesehen davon macht das Entfernen von TR-069 bei einer aktuellen 7390 das WLAN kaputt, solange man nicht das betreffende Plugin wieder integrieren läßt - was dann seinerseits wieder Platzprobleme nach sich zieht, wenn man nicht mit "externals" arbeitet oder viele weitere Teile der Firmware ebenfalls entfernt - so ganz zum Spaß hat AVM das WLAN ja nicht in ein Plugin verbannt.
Seit wann das denn? Wenn man die PluginIntegration nicht aktiviert, werden die Plugins normal heruntergeladen.
Die httpdl dagegen wird für Update der Firmware selbst, Dect-Telefonen sowie Dect-SmartHome Geräten verwendet. Steh so in etwa auch in der Hilfe zu dem Punkt

Irritiert mich jetzt auch. TR069 war immer das Erste, was bei mir rausflog. WLAN-Probleme hatte ich keine. Auch liegt das plugin.zip jedes Mal wieder neu in der Box. Ab welcher Version soll da ein Problem bestehen? Und welche Version hat opto installiert (Cross-Check)?

Um TR-069 abzuschalten, reichen im Normalfall auch die passenden Einstellungen - wenn man mal das "argo" außen vorläßt, das ist neu und ich durfte auch gerade erst "lernen", daß die Abfrage, ob man den Abruf durch AVM gestatten will, auch eher "pro forma" ist - die Box tut es nämlich auch dann bereits, wenn der Besitzer die betreffende Seite noch gar nicht zu Gesicht bekommen hatte.

Ui – das muss ich gleich einmal nachschauen. Ich hoffe ich finde den Krams. Komplett Abschalten ist immer noch besser als garnichts. Vielleicht magst Du zur Sicherheit schonmal posten, wo man da welche Häkchen rein/raus machen sollte? Auch für den Fall, dass ich welche übersehe.

Zumindest bis zum Abnicken durch den Besitzer sollte man damit schon warten ... so ein wenig fühlt man sich da wieder einmal versucht, laut "Skandal" zu schreien - das gilt in gewissem Maße auch für das automatische Update. Ich bleibe dabei, daß da in älteren Firmware-Versionen die Einstellung "nur benachrichtigen" nicht immer korrekt arbeitete und auch ich habe FRITZ!Boxen im Zugriff, bei denen entgegen dieser Einstellung das FRITZ!OS aktualisiert wurde, nachdem AVM die Reaktionen auf die Update-Anfrage offenbar geändert hat und die 84.06.51 nunmehr als "erforderliches Update" ausweist.

Hoppla – das ist jetzt interessant. Nochmals hervorgehoben, was ich meine: bei denen entgegen dieser Einstellung das FRITZ!OS aktualisiert wurde. Ahja. Laut AVM bin ich damit nämlich ein Einzelfall – man wisse von keinem weiteren. Mir war noch ein weiterer Fall bekannt – aber der war sich offensichtlich nicht sicher, ob er versehentlich die entsprechende Einstellung anzupassen vergaß. War ich ja zuerst auch – bis ich dann darauf kam, dass das Blödsinn ist (siehe meinen vorigen Post: Hätte ich Auto-Updates aktiviert, wäre da schon vorher was gekommen. Zwischen der 5.54 und der aktuellen 6.51 liegen ja wohl mehr als zwei Updates).

Wenn man das also verhindern will, ändert man am besten den öffentlichen Schlüssel für die Kontrolle der Signatur einer Antwort des AVM-Update-Services in der Firmware - dann sollte (müßte ich glatt mal testen, ob das auch tatsächlich funktioniert - wenn nicht, wäre das ja wieder ein nettes Einfallstor und die Tatsache, daß die SOAP-Antwort plakativ signiert ist, muß ja noch lange nicht bedeuten, daß diese Prüfung auch tatsächlich korrekt arbeitet) die Antwort des AVM-Servers als ungültig angesehen werden und ein auf diesem Weg angebotenes Update (wenn man nicht gleich die komplette Kommunikation mit dem Anbieter im Hintergrund per Einstellung unterbinden will, was einen dann auch von Updates für DECT-Geräte abschneidet) sollte nicht erneut installiert werden. Bisher zumindest werden die DECT-Updates nicht über diesen Service abgefragt - die sollten also weiterhin entdeckt werden können.

Halte uns da bitte auf dem Laufenden! Wenn das ginge, ließe sich ja auch Freetz wieder "normal flashen" – nachdem man es mit dem entsprechenden Schlüssel selbst signiert hat.

PS: Meine Signatur hier passe ich wieder an, sobald ich weiß, wo's für mich lang geht :)

- - - Aktualisiert - - -

@opto:
OK, ich reduziere auf "kann kaputtmachen" ... für das Starten der Plugins wird jedenfalls das Programm "tr069fwupdate" benötigt (siehe /sbin/start_plugin.sh in der Firmware) und das wird ggf. beim Entfernen von TR-069 ebenfalls entsorgt:

Wenn man das Häkchen gesetzt hat. "TR069 entfernen" und "tr069fwupdate" sind zwei separate Checkboxen. Habe die Freetz-VM schon runtergefahren (muss gerade ein paar (Kernel-) Updates vornehmen und neu starten, auch um "Roger Router" ans laufen zu bringen (neue Gruppe zu meinem User hinzugefügt erfordert Neuanmeldung)), kann aber danach gern nochmals nachschauen und den entsprechenden Screenshot aus "menuconfig" posten.

Wann das nun genau erfolgt und wann nicht (sprich, wann FREETZ_REMOVE_TR069_FWUPDATE gesetzt ist), schaue ich jetzt nicht nach ... aber sollte ein Plugin erst noch durch das "tr069fwupdate" für die Signaturprüfung müssen und das Programm fehlt, startet das betreffende Plugin nicht.

Wie getippst: Diese Konstante wird durch eine separate Einstellung in menuconfig getriggert. Wo ich jetzt nicht sicher bin sind weitere Abhängigkeiten; soweit ich mich erinnere, lässt sich die Checkbox nur aktivieren, wenn man auch TR069 selbst mit entfernt.
 
Das Signieren der selbst erstellten Firmware geht bereits und ist auch im Trunk enthalten.

- - - Aktualisiert - - -

Ansonsten ist das WLAN ja erst seit 06.51 in das Plugin gewandert bei der 7390 - wenn das bisher keine Probleme bereitete, ist das also kein Wunder. Wenn man beim Entfernen von TR-069 dafür sorgt, daß "tr069fwupdate" erhalten bleibt, ist ja alles in Ordnung ... eigentlich müßte da (zur Sicherheit) eine Abhängigkeit eingebaut sein, damit niemand sowohl TR-069 entfernt als auch auf die Integration verzichtet, der nicht gleichzeitig das WLAN abschalten will. Ob die existiert oder nicht, weiß ich nicht ... nicht mein Tisch.
 
Das Signieren der selbst erstellten Firmware geht bereits und ist auch im Trunk enthalten.

Komisch. Ich habe vor ein paar Tagen Trunk aktualisiert, und nochmals menuconfig laufen lassen. In Sachen Signatur ist mir nichts aufgefallen. Sollte das tatsächlich gehen, setzt es sicher Dein zuvor erwähntes "Austauschen des Zertifikats" auf der Box selbst voraus, um initial die Stock-FW durch Freetz zu ersetzen?

BTW: Hab mich gerade blöd gesucht, aber keine Einstellungen zum Abschalten von TR069 im WebUI finden können. Dafür sagt meine "Sicherungsdatei" (urgs, sichern kann man jetzt nur noch mit Passwort? Aber das Teil ist trotzdem lesbar?):

Code:
tr069cfg {
        enabled = no;
        litemode = no;
        tr181_support = no;
        dhcp43_support = yes;

Somit sollte es wohl ausgeschaltet sein. Was allerdings dhcp43 sein soll, hab ich keinen Schimmer.

Ansonsten ist das WLAN ja erst seit 06.51 in das Plugin gewandert bei der 7390

Ah, OK. Dann kann das bei mir bislang auch nicht zu Problemen geführt haben :)

Wenn man beim Entfernen von TR-069 dafür sorgt, daß "tr069fwupdate" erhalten bleibt, ist ja alles in Ordnung ... eigentlich müßte da (zur Sicherheit) eine Abhängigkeit eingebaut sein, damit niemand sowohl TR-069 entfernt als auch auf die Integration verzichtet, der nicht gleichzeitig das WLAN abschalten will. Ob die existiert oder nicht, weiß ich nicht ... nicht mein Tisch.

Jain. Soweit ich mich erinnere, stand da nur ein "depends:" auf TR069-Entfernung selbst. Müsste ich allerdings verifizieren, um es sicher sagen zu können. Im Moment komm ich da nicht ran :)

- - - Aktualisiert - - -

Hab nachgeschaut: tr069 macht nichts kaputt. Aber tr069 hat die Unteroption "fwupdate" ("default n") die Updates kaputt macht:
http://freetz.org/browser/trunk/config/ui/patches.in#L803

Ah! Danke, genau den "Schnippsel" habe ich gemeint:

Code:
config FREETZ_REMOVE_TR069_FWUPDATE
  depends on FREETZ_REMOVE_TR069 && FREETZ_AVM_HAS_TR069_FWUPDATE

Nur der Hilfstext hat sich mir nie erschlossen: "needed for updating the firmware in MT-D devices"

PS: Suboptimal ist dass tr064 immer mit tr069 rausgeworfen wird

Yupp, für irgend etwas soll man tr064 "öfter brauchen, als man denkt". Erinnere mich nur nicht mehr für was genau :)
 
Könnte dann aber trotzdem laufen
Das wäre echt überraschend ... in der Funktion "install_plugins" führt kein Weg am Aufruf von "tr069fwupdate" vorbei, dann gibt es beim Fehlen dieses Programms ein "Unbekannter Fehler 127" und das Plugin wird nicht einmal über das loop-Device gemountet. Alles andere grenzt dann an ein Wunder, sollte es trotzdem funktionieren.
 
Ähm @PeterPawn, nochmal kurz zurück zu meiner ursprünglichen Frage (ging jetzt via TR069 ein wenig unter):

Lässt sich Dein YourFritz auch verwenden, um Freetz über eine aktuelle (signierte) FW einer 7390/7490 zu bügeln (Oliver meinte, das "könnte funktionieren" – war sich aber nicht sicher ob und wie)?
 
Man ≠ Man. Theoretisch geht das,
Und auch praktisch.

in meinem Fall nicht: Kein Windows hier
Man benötigt dafür kein Windows. Rate mal warum für die NAND-Modelle dieses HowTo hier erstellt wurde, richtig, weil eben die altbekannte (betriebssystemunabhängige) FTP Upload-Methode (s.u.) mit den neuen NAND-Modellen (z.B. 7490) nicht mehr funktioniert. Aber für die NOR-Flash Modelle (z.B. 7390, der NAND-Flash der 7390 wird ja bekanntermaßen nicht für die Firmware verwendet) kann man doch weiterhin die altbekannte FTP Upload-Methode verwenden (als Freetz-Nutzer müsste man das doch eigentlich wissen):
https://freetz.org/wiki/help/howtos/development/save_mtd_2#UploadsviaFTP
[thread]242984[/thread]

Für die NOR-Modelle (incl. 7390) ist dieses HowTo hier also 1. nicht gedacht und 2. auch nicht notwendig.

Außerdem würde bei einem regulären Downgrade auch ein Factory-Reset inklusive sein.
Wenn man es selbst macht eben nicht... Also alles kein Problem.
 
Zuletzt bearbeitet:
[thread]242984[/thread]

DA ist das Teil! Ich hab mir 'nen Wolf gesucht, und den Fred nicht gefunden. Klar, Adam & Eva hatte ich ja bereits erwähnt (war mir grau in Erinnerung, dass sowas geht – aber meine letzte direkte Bekanntschaft mit den beiden liegt bereits mindestens 10 Jahre zurück. Hab's ja bislang nicht gebraucht). Danke für's Auffinden!

Für die NOR-Modelle (incl. 7390) ist dieses HowTo hier also 1. nicht gedacht und 2. auch nicht notwendig.

Yupp, alles klar. Das waren die letzten beiden Puzzle-Teile bzgl. meiner 7390. OK, dann kann ich wohl auf die Zusendung der Austauschbox verzichten – es sei denn, man berücksichtigt aus genanntem Fred:

- Für den unwahrscheinlichen Fall eines Fehlschlag sollte man eine Recovery-Möglichkeit vorbereitet/heruntergeladen haben oder ein Ersatzgerät verfügbar haben, weil man sonst ohne Internet da steht!

Und wenn ich mich recht entsinne, ist auf beschriebene Weise auch möglich: ein Downgrade, Einspielen eines gefreetzten Kernel-Images – da ja die Prüfroutine wegfällt. Ich könnte also rein theoretisch (jaja, wohl auch praktisch) auf eine gefreetzte 6.30 wechseln, der das TR069 entzogen wurde, und würde dabei dann auch die (ab 6.51 möglichen) WLAN-Probleme umgehen.

Danke für die Hinweise! Mal schauen, wann ich dazu komme. Derzeit ist es wieder einmal etwas hektisch…

Die Frage bzgl. der Verwendung des Flash-Scripts zum Freetzen einer 7490 bliebe dennoch offen – sofern REMOVE_TR069 ohne Entfernung des tr069update möglich ist, und WLAN weiterhin funktioniert :)
 
Das, was in dem gefundenen Thread für NOR-Boxen beschrieben ist, macht das "push_firmware" im Freetz genau so ... das muß man also nicht von Hand machen.

Bei jedem Zugriff über den Bootloader wird sowohl die Versionsprüfung als auch die Signaturprüfung umgangen - da läßt sich also jede beliebige (auch falsche) Firmware installieren, ohne daß sich an den Einstellungen (die liegen in den TFFS-Partitionen) irgendetwas ändern würde.

Ein Downgrade bzw. das Löschen irgendwelcher Einstellungen ist niemals etwas, das automatisch passiert - es erfordert zusätzliche Aktionen/Kommandos, damit Daten im TFFS gelöscht werden oder gar die TFFS-Partitionen mit einem neuen (nicht leeren) Image überschrieben werden, was dann im Ergebnis auch zu "Werkseinstellungen" führt, weil im Anschluß die Standardwerte geladen werden.

Bei NAND-Boxen übernimmt die Firmware selbst das Schreiben in den Flash-Speicher, nachdem sie über den Bootloader ins RAM der Box geladen wurde. Was dort geschieht, hängt also davon ab, was in der /sbin/flash_update in der geladenen Firmware steht - eine pauschale Aussage ist dort also Quatsch. Wie das bei der 7490 (und den anderen NAND-Modellen vor der 7580) funktioniert, habe ich irgendwo bei "modfs-Starter" beschrieben.
 
Beispiel-Aufruf:
7490install.sh ./FRITZ.Box_7490.113.06.30.image 203.0.113.5

Vielen Dank erstmal für dein Script, es hat mir unter Anderem sehr geholfen, eine Hardware geschädigte 7490 (der Spartan hat wohl einen Schuss) wieder zu beleben! Großen Dank auch an PeterPawn für seine Erläuterungen bzgl. des NAND der 7490 und vor Allem für sein eva_to_memory! Ohne euch hätte ich Leihe es nicht geschafft!

Aber zu dem Aufruf: Wenn ich das Script so aufrufe, erhalte ich immer ein "Befehl nicht gefunden". Ich löste (für mich) zufällig das Problem, als ich das Script mit "bash -x 7490install.sh 7490.image 2>&1 | tee log.file" loggen wollte, da es so plötzlich durchlief - allerdings nur bis zum nächsten Script-Aufruf (eva-login.sh und eva_to_memory). Ich benutzte dein Script daher nur, um mir das image.eva zu erstellen und führte die weiteren Schritte manuell aus (Box in Eva halten und das eva_to_memory).

Ein kleiner Tip noch für andere Windows 10 Benutzer: Mit dem Bash für Windows 10 funktioniert das Ganze auch bestens!


Edit: eva_to_memory läuft mit dem Windows Bash nicht richtig!
 
Zuletzt bearbeitet:
Das Shell-Skript muss zuvor ausführbar gemacht werden, z.B. mittels "chmod 755 <Shell-Skript>" ("chmod a+x <Shell-Skript>" oder "chmod u+x <Shell-Skript>" gehen auch; je nach dem, ob für alle oder nur den aktuellen User). Und es wird dann mit vorangestelltem "./" aufgerufen.
 
Zuletzt bearbeitet:
@Christoph_F:
Code:
[COLOR=#ff0000]./7490install.sh: 30: ./7490install.sh: eva-login.sh: not found
./7490install.sh: 31: ./7490install.sh: eva_to_memory: not found[/COLOR]
Ich musste in Deinem Skript noch jeweils ein "./" voranstellen, dann klappte es soweit:
Code:
[COLOR=#008000][B]./[/B][/COLOR]eva-login.sh "$IP"
[COLOR=#008000][B]./[/B][/COLOR]eva_to_memory "$FIMG.eva" "$IP"
 
Zuletzt bearbeitet:

Zurzeit aktive Besucher

Keine Mitglieder online.

Statistik des Forums

Themen
246,219
Beiträge
2,248,328
Mitglieder
373,792
Neuestes Mitglied
gilbertsamson563
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.