AVM FRITZ!BOX 4020 - Auslieferungsfirmware 147.06.25

[Meeeenzer]

funktioniert die 4020 denn als WLAN und DECT-Repeater?

 

[Joe_57]

Glaub ich nicht, da die 4020 wohl kein DECT kann.

Joe

 

[Daniel Lücking]

DECT ist in der Box nicht enthalten - das kann erst die 4080 irgendwann.

 

[andiling]

WLAN Repeater geht allerdings.

 

[Daniel Lücking]

Hatte die Box nun auch mit einem ZTE-Stick via UMTS am Netz. Hier zeigt sich die gute Vorarbeit an der FRITZ!OS-FIrmware, die nun neue Hardware-Kombinationen und Konzepte möglich macht.

Ein bisschen OT:

Klar: Hemnisse, wie DECT und 5 GHz-WLAN, die gemeinsam mit dem 2.4 GHz-WLAN auf der Platine Platz finden müssten ohne sich gegenseitig zu beeinflussen hat die Box nicht. Was ich nun noch vermisse wären einzelne Geräte, die


- DSL-Modem und Gigabit-Lan-Anbindung & DECT bereit stellen um danach beliebig ein Netzwerk aus 4020 / 4080-Boxen aufbauen zu können. Schade, das die 7412 kein DECT-Ula hat und auch der Lan-Port kein GigabitPort ist.

7412 und 4080 wären für mich perspektivisch die beste Kombination.

 

[Meeeenzer]

Danke Euch! Habe mir mal aus Spass eine 4020 auf Amaz... bestellt, da ich nach wie vor von der Performance des 1750E nicht restlos überzeugt bin. Ich werde berichten, ob die 4020 das besser kann oder nicht.

 

[eisbaerin]

@Daniel Lücking: Kannst du dir bitte nochmal #18 und #19 anschauen.

 

[leseratte10]

Wurde denn nun auf der 4020 der Telnet-Client entfernt?

Probier doch mal, den in der Export-Datei selber wieder zu aktivieren. Benötigt weder Telefon noch Pseudo-Update.
Und wäre es möglich, dass du mal Supportdaten erstellst und die vollständig hier postest? (oder sind da irgendwelche Privaten daten drin? Meines Wissens werden die ja in den Supportdaten komplett entfernt).

 

[PeterPawn]

Wenn nicht auf dem FTP-Server und auch unter www.avm.de sämtliche Links zur Firmware für die 4020 (noch?) fehlen würden, könnte man das ja schnell und unkompliziert ermitteln.

Ich habe auch nicht jede Produkt-Freigabe seitens AVM "auf dem Schirm", aber ist das bisher auch so gewesen, daß erst nachträglich aktuelle Firmware (inkl. Recovery-Tools) bereitgestellt wurde?

Ich will nicht spekulieren, ob AVM da jetzt nur noch den "Online-Weg" für Updates vorsieht ... aber vielleicht kann ja mal jemand in der Box nachsehen, ob die Möglichkeit des dateibasierten Updates überhaupt vorhanden ist (in der "erweiterten Ansicht" ggf.)?

Auch diese Box wird ja (vielleicht?) mit einer Produkt-CD ausgeliefert (wenn man nicht zu sehr sparen will, um den "Kampfpreis" zu realisieren)? Wenn ja, ist dort eine Recovery-Datei enthalten? Wenn ja, paßt die zur 06.25? Das wäre ja ein Hinweis, wie lange die 06.25 schon für die 4020 "eingetütet" ist, denn wenn das erst noch ins "Presswerk" mußte, dann sind > 4 Wochen ja noch vorsichtig geschätzt. Welche Version (inkl. Build-Datum) hat denn die Firmware? Das sollte ziemlich am Beginn in den Support-Daten stehen (wenn man an die noch herankommt ... das könnte AVM ja auch problemlos "abschaffen").

 

[eisbaerin]

Ja, das war schon immer so (zumindest die letzten 5 Jahre).
Die Auslieferungs-FW oder Recovery gab es nie auf FTP, immer erst das 1. Update.
Und das kann Monate, manchmal Jahre dauern.

 

[leseratte10]

Ich will nicht spekulieren, ob AVM da jetzt nur noch den "Online-Weg" für Updates vorsieht ...

Selbst wenn, muss der Online-Updater die Firmware ja auch irgendwoher bekommen. Zumindest bei den mir vorliegenden 7270 (habe es vor einiger Zeit getestet) holen sich die Fritzboxen die Firmwareupdates ebenfalls nur von ftp://ftp.avm.de/fritz.box/*/firmware/*.image

 

[PeterPawn]

Selbst wenn, muss der Online-Updater die Firmware ja auch irgendwoher bekommen.

Das ist schon noch ein wenig komplizierter ... auch wenn der SOAP-Request für das Feststellen neuer Updates (jason.avm.de/updatecheck/BoxFirmwareUpdateCheck) bei anderen Modellen im Klartext (als HTTP anstelle von HTTPS) abläuft, ist das ja problemlos möglich, den auch zu verschlüsseln.

Und Deine FRITZ!Box 7270 mit aktueller Firmware holt sich zwar das Image tatsächlich vom FTP-Server, aber ob da eines liegt (das aktueller ist) und unter welcher Adresse das zu finden ist, erfragt sie vorher über den erwähnten SOAP-Request. Selbst die Authentizität der Server-Antwort wird dabei geprüft, es ist also nicht mal eben möglich, durch eine gefälschte Antwort die Box zu einem Download aus einer dubiosen Quelle zu veranlassen (was man ansonsten mit DNS-Spoofing/-Poisoning für jason.avm.de ja erreichen könnte).

Das notwendige Zertifikat für die zusätzliche TLS-Verschlüsselung bei dieser Abfrage wäre sogar in aktueller Firmware schon vorhanden, damit wird u.a. die Identität des MyFRITZ!-Servers bei AVM geprüft. In der verschlüsselten Kommunikation würde man dann den Download-Pfad für solche Firmware-Images nicht mehr ermitteln können (solange man sich nicht als MITM dort einklinkt).

Schon bei den bisher existierenden Modellen ist das Namensschema für den FTP-Server auch alles andere als einheitlich, bei einem vollkommen neuen Modell (wo man auf alte Zöpfe eigentlich nur wenig Rücksicht nehmen müßte) kann man da ja auch vollkommen neue Wege beschreiten (und nicht nur neue Pfade erfinden).

Selbst Firmware-Updates "mit Wasserzeichen" wären problemlos denkbar ... es ist z.B. möglich, bei der Anfrage nach einem Update noch den "public key" des Boxzertifikats mit zu übermitteln. Dann nimmt man auf der Serverseite diesen Key her und verschlüsselt einen zufällig gewählten Wert (wozu der gut ist, darauf komme ich gleich) mit diesem "public key" ... der Theorie nach kann nun nur jemand mit dem passenden "private key" diese Daten wieder entschlüsseln. Mit dem erwähnten zufälligen Wert verschlüsselt jetzt der ausliefernde Server (egal ob HTTP-, FTP- oder was auch immer) das Firmware-Image (symmetrisch) bei der Übertragung zusätzlich, sogar das Erstellen eines "on demand"-Images wäre bei Boxen mit NAND-Flash denkbar, wo dann im "äußeren Image" (das ist das, was dort unter /wrapper gemountet ist nach dem pivot_root) ein entsprechendes "Wasserzeichen" liegen könnte. Da nur die "Empfänger-Box" den zufälligen Wert entschlüsseln kann und damit auch das übertragene Firmware-Image nur für diese Box geeignet ist, wäre das durchaus eine Lösung, wie man eine FRITZ!Box weiter "verriegeln" kann. Ob das am Ende rechtens ist wegen der GPL oder ob man das auch wieder "knacken" kann, ist hier ja nicht das Thema ... aber so einfach muß es der Hersteller einem nicht unbedingt machen, an die Firmware eines Gerätes zu gelangen, wenn er dort entsprechende Gegenmaßnahmen treffen will.

 

[koyaanisqatsi]

Moin

@PeterPawn: Du machst mir Angst

Was mich zu der Frage führt: Gehen Pseudofirmwareupdates überhaupt mit dieser Box?

telnetd
In der gerade erschienenen Labor Firmware für die 7360 (ohne SL) steht explizit in "7360 - infolab.txt":

1. Dieses Labor ist eine Vorschauversion des in Kürze erscheinenden Updates. Es enthält Anpassungen zur besseren Unterstützung aktueller Angebote bei den Internetanbietern.

2. System: Hinweis - Zugang zur FRITZ!Box per Telnet wird nicht mehr unterstützt

 

[eisbaerin]

@PeterPawn: Erklär' hier ja nicht so viele Tricks, sonst macht AVM das wirklich noch.

 

[PeterPawn]

Du machst mir Angst

Nicht meine Absicht ... aber wenn AVM sich anstrengen will, wird es härter ... aber eben auch für Angreifer.

Was mich zu der Frage führt: Gehen Pseudofirmwareupdates überhaupt mit dieser Box?

Ich vermute mal, dazu bräuchte es wenigstens wieder die Möglichkeit, ein Update als Datei hochzuladen (die Frage ist ja noch offen) ... wie sich die Signaturprüfung verhält, wird man wohl erst erahnen können (so es niemand vorher aus der Firmware extrahiert), wenn es mal jemand mit einer solchen Box ausprobiert.

Wenn die Signaturprüfung ähnlich läuft wie (vermutlich, ich habe es immer noch nicht getestet vor lauter Streß) bei der 7490-06.25-Beta/Labor, dann wird wohl auch mit Pseudo-Images nichts mehr zu machen sein ... außer wir schmeißen alle unsere Rechenpower zusammen und spekulieren darauf, daß die AVM-Keys zur Signaturprüfung auf einer FRITZ!Box (dann wahrscheinlich mit zu wenig Entropie) oder auf einem alten Debian-System (das war glaube ich Debian, was die schwachen Schlüssel erzeugte wegen des PRNG-Fehlers) erzeugt wurden und wir in der Lage sind, für einen der in der Firmware enthaltenen "public keys" (/etc/avm_public_key[1-3]) den zugehörigen "private key" zu errechnen oder (bei zu wenig Entropie und damit "doppelt vorhandenen" Primzahlen) durch Vergleiche mit anderen FRITZ!Boxen oder Schlüsseln zu ermitteln.

Wobei diese Schlüssel sicherlich nicht auf einer FRITZ!Box generiert wurden ... das war nur ein Joke.

OT: Aber irgendwo bei AVM gurken die privaten Schlüssel garantiert "durch's Netz"; ich möchte zwar daran glauben, daß die irgendwo ordentlich (z.B. auf einer Chipkarte) gespeichert sind und nur zum Signieren von Firmware herausgeholt werden, aber das wäre tatsächlich "durchdachter", als ich es in der Realität vermute. Von der (denkbaren) Möglichkeit, daß AVM auch dubiose Updates für "lawful interception" signiert, ganz zu schweigen ... irgendwie ist es schon merkwürdig, wenn da seitens AVM niemals irgendeine Prüfsumme "offiziell" bekanntgemacht wird. Automatisch ist ja ganz nett ... aber verlangt eben auch "unbegrenztes Vertrauen" in den Hersteller. Wenn irgendwo im Rahmen eines Ermittlungsverfahrens das "Schnüffeln" erlaubt wird, dann dürfte es ein Leichtes sein (nehmen wir mal an, die ermittelnde Behörde hat die MAC-Adresse der betreffenden FRITZ!Box), genau für diese FRITZ!Box eine passende Antwort auf die Update-Anfrage zu erstellen und dann eine entsprechend präparierte Firmware bereitzustellen. Insofern (man mag es Paranoia nennen) ist die von AVM eingebaute Möglichkeit des automatischen Updates auch nicht so ganz ohne ... wer jetzt aber tatsächlich glauben will, daß es unbedingt die "Erlaubnis" des Besitzers braucht, damit die Box selbst im Hintergrund mit allen möglichen Diensten Kontakt aufnimmt, der könnte in so einem Falle ja "allow_background_comm..." auch ausschalten. Das hat zwar primär alles nichts mit der 4020 zu tun, aber als erste Vertreterin einer neuen Spezies von FRITZ!Boxen kann es sicherlich nicht verkehrt sein, wenn man die bisherigen Erkenntnisse zu anderen Boxen im Kontext dieses Modells noch einmal hinterfragt ... bei der letzten "Neuerscheinung" in größerem Stil (das waren m.E. die DOCSIS-Modelle) waren die Rückschlüsse auf andere FRITZ!Boxen ja auch nur noch bedingt korrekt.

BTT: Aber die erste Variante (Errechnen eines "private keys") wäre vermutlich ohnehin illegal und es ist über EVA immer noch leichter, ein eigenes System zu laden und zu starten, als unbedingt ein Pseudo-Update machen zu wollen. Solange man auch das "von Hand" machen müßte, ist mit dem kompletten Laden eines Systems, das nicht im Flash liegt, nur ein zusätzliches "Reboot" verbunden ... wer das nicht immer wieder machen will (erinnert an den "tethered jailbreak" beim iOS), der flasht eben aus diesem System heraus seine eigene Version.

 

[leseratte10]

Wofür ist denn ein Pseudo-Firmwareupdate so wichtig? Telnet lässt sich (wenn vorhanden) doch auch über die Einstellungsdatei einschalten. Oder haben die die Export-Prüfsummenberechnung geändert?

 

[koyaanisqatsi]

Telnet lässt sich (wenn vorhanden) doch auch über die Einstellungsdatei einschalten.

Tja, so muss ich das zur Zeit machen, wenn ich den "ausversehen" deaktiviert habe, anstatt nur zu killen.
Denn er lässt sich jetzt schon in der 7360SL 6.20 nach Deaktivierung nicht mehr aktivieren.
..aber was ist wenn die busybox den (telnetd) nicht mehr enthält?

 

[PeterPawn]

Bisher enthielt noch jede FRITZ!OS-Firmware den telnetd in der Busybox (das mag sich künftig ändern), selbst die bei den DOCSIS-Modellen. Der Start wurde auf anderem Weg unterbunden.

@koy: Wie muß man sich das "Deaktivieren" oder "Killen" des Telnet-Daemons denn vorstellen? Was hat das für einen Sinn?

Ansonsten - ohne Zusammenhang zur vorhergehenden Frage - kann man natürlich auf Pseudo-Updates eigentlich auch verzichten ... Binaries stellt man auf dem USB-Stick bereit und für das Ausführen eigener Kommandos sollte man gleich in die Firmware eine "ordentliche Lösung" (SIAB oder Dropbear) integrieren, die kann notfalls auch vom USB-Stick starten und so läßt sich auch über das pure Vorhandensein des passenden "Volumes" steuern, ob die originale AVM-Firmware oder die mit den eigenen Modifikationen verwendet werden soll. Das Wiederherstellen des "Normalzustands" nach dem Starten eines Firmware-Uploads ist ja auch eher nicht trivial (hatten wir doch letztens erst irgendwo anders) und sollte "ohne Not" nur in Ausnahmefällen erfolgen.

Das ist eigentlich darauf ausgelegt, daß nach dem Ausführen von "prepare_fwupgrade" wirklich in nicht allzu ferner Zukunft ein Neustart erfolgt und für das "Zuschalten" von irgendwelchen Features ist so ein "Pseudo-Update" seit geraumer Zeit eher nicht mehr das Mittel der Wahl. Ich kenne sogar Leute, die immer noch das alte Image (das hier irgendwo noch durch's Forum geistert) für das Aktivieren des telnetd benutzen (das klappt auch nicht mehr, wenn AVM den Link nicht einbaut, jedenfalls solange man den telnetd in der AVM-Busybox verwenden will ... aber das nur nebenbei) und sich dann bemühen, in den knapp 3 Minuten, die ihnen vor dem Neustart bleiben, irgendwas Sinnvolles zu tun.

@leseratte10:
Der Start über das Editieren der fx_conf in der Export-Datei funktioniert auch nur auf Boxen mit Telefonie-Funktion, da der dann aus dem "telefon"-Daemon heraus erfolgt. Wird dieser Daemon nicht gestartet, gibt es auch keinen Telnet-Service, das ist z.B. auf den Repeatern ein Problem, denn dort gibt es den "telefon"-Daemon nicht.

 

[koyaanisqatsi]

Gaaans, einfach...

Mit telnet musst du ersteinmal drauf, sonst geht irgendwie keine Modifikation, und ich hab sowieso keine startbare debug.cfg.
Dann starte ich natürlich dropbear oder shellinaboxd.
...und in der featovl.cfg hab ich PATH so wie ich es brauch gesetzt.

Wenn also erledigt: killall telnetd
...ausser ich hab ein paar eigene telnetd Server mit meiner busybox erstellt, dann doch eher: kill -9 PID

Wenn du ihn per AVM Mittel deaktivierst, dann: Import/Export

Mit killall oder kill ist telnetd nach Neustart wieder da, erreichbar.

die kann notfalls auch vom USB-Stick starten und so läßt sich auch über das pure Vorhandensein des passenden "Volumes" steuern

Wie?
Ohne telnetd, ohne freetz, ohne debug.cfg?

...abgesehen davon muss ich ja die "grossen Pakete" von USB ausführen, bei 300 Kilobyte internen Speicher.

 

[Daniel Lücking]

Ein Bild von der Übersicht währe ganz nett.


Der Expertenmodus heißt vielleicht mal wieder anders und ist auch wo anders versteckt?
Früher hieß es ja auch "Erweitere Ansicht".

Definitv kein Expertenmodus mehr enthalten. Zumindest nicht in der Auslieferungsfirmware. Der Text in der Hilfe ist auch nur der Standard-Text, der sich nicht explizit auf das 4020-UserInterface bezieht.



Und: ich habe den Link aus der 7490-Firmware versucht - kein Effekt bei der 4020.