[Frage] WLAN Repeater 1750E modifizieren

[hermann72pb]

Die WLAN-Repeater werden weder von FREETZ noch von modfs unterstützt, wenn ich es richtig verstehe. Ich würde mir gerne zu meinem 1750E-Repeater einen Zugang verschaffen, um mich dort zwecks SSL-Zertifikate für HTTPS-Verbindung umzuschauen und die bei jedem Reboot selbstsignierten Zertifikate durch eigene zu ersetzen.
Da es letzte Zeit viele Veränderungen bei AVM bzgl. telnet-Sperren, Signieren und Verpacken von Images gab, weiß ich langsam nicht, wo ich anfangen soll...
Seit kurzem hat der Repeater auch eine 7.01-Firmware bekommen:
http://ftp.avm.de/fritzwlan/fritzwl...eater_1750E.en-de-es-it-fr-pl.134.07.01.image
Wenn man sie entpackt, findet man unter /var/tmp eine leere filesystem.image, eine kernel.image (mit der eigentlichen Firmware) und eine System.map.lzma.
Ich finde leider keine Informationen zu 1750E, ob es eine "NAND-Box" ist, oder besser gesagt welcher der Fritzboxen der Repeater vom Speicheraufbau, Prozessor, Flash usw. am nächsten ist.
Ich konnte heute mit dem Bootloader des Repeaters per FTP/ADAM "reden" und habe festgestellt, dass

quote GETENV linux_fs_start
501 environment variable not set

liefert.
Soll wohl heißen, dass der Repeater keine NAND-Box ist und es weder mit dem "Schattenimage" funktioniert noch modfs darauf laufen kann (davon abgesehen, dass der Repeater weder NAS noch USB hat). Darum wäre ich froh, wenn ich auf die Art und Weise, wie im Thread FRITZ!Box 7580 - Firmware 153.06.90 - Telnet-Service freischalten (geht auch für 7560 und 7590) beim Repeater zunächst wenigstens telnet freischalten könnte. Mir ist bewußt, dass die Anleitung von einer 7580 hier nicht komplett übernommen werden kann, aber vielleicht zumindest zum Teil.
Eine andere Alternative wäre, mit der FREETZ-Buildumgebung rumzuspielen, die ich habe. Damit könnte man zumindest die Firmware auspacken, busybox austauschen, telnet-Start irgendwo in rc.S einfügen und mit diesen zwei kleinen Änderungen eine leicht angepasste Firmware versuchen zu packen. Bloß dafür kenne ich mich mit dem ganzen Signierungs- und Packungszeug gar nicht aus und werde garantiert da was falsch machen. Da man anschließend das erste (hoffentlich signierte) Image per FTP/ADAM auf den Repeater bringen würde, kann man da schnell den Repeater "zerschießen", wenn man nicht aufpasst. Darum wäre ich besonders bei dem Vorgehen auf Rat und Tat angewiesen.

MTD-Bereiche, die ich über FTP/ADAM ermitteln konnte:

mtd0 0x9F000000 0x9F000000
mtd3 0x9F020000 0x9FF00000
mtd6 0x9F000000 0x9F020000
mtd9 0x9FF00000 0x9FF80000
mtd11 0x9FF80000 0xA000000

Ich meine mich dunkel zu erinnern, irgendwo in den Tiefen der AVM-FTP-Server auch GPL-Quellen für den Repeater mal gesehen zu haben, finde es jetzt aber auf Anhieb nicht, seitdem AVM die Quellen so tief versteckt.

Wie soll ich am Besten vorgehen?

MfG

 

[NDiIPP]

Der Repeater 1750E nutzt den Qualcomm Scorpion SoC (QCA955x) mir 16MB NOR-Flash (ohne DualBoot). Die gleiche Plattform (Qualcomm Scorpion, Single-Boot und 16MB NOR-Flash) nutzen neben dem 1750E auch noch folgende weitere AVM-Produkte:

• FRITZ!Box 6820 LTE (hier allerdings mit NAND-Flash und DualBoot!),
• FRITZ!WLAN Repeater 450E
• FRITZ!WLAN Repeater 1160 und
• FRITZ!WLAN Repeater DVB-C.

Auch die Fritzbox 4020 dürfte damit stark verwandt sein, sie nutzt statt des Qualcomm Scorpion eben nur den Qualcomm Dragonfly SoC (QCA9561) mit ebenfalls 16MB NOR-Flash und "Single-Boot".

Jedenfalls lassen sich die Firmware-Images der oben genannten AVM-Produkte, die auf der Qualcomm Scorpion und Dragonfly Plattform basieren und NOR-Flash besitzen, derzeit bereits mit Freetz im "nofreetz-Modus" modifizieren. Als Box wählt man dazu die Fritzbox 4020 aus (diese wird zumindest von Freetz unterstützt, so wie auch die 6820 LTE) mit einem anschließenden "make tools". Dann kann es bereits "losgehen"...

Da die Fritzbox 6820 LTE als einziges Modell aus dieser Qualcomm-Familie mit MIPS74Kc-Prozessor NAND-Flash besitzt (inklusive DualBoot) und somit ein anderes Firmware-Image Format verwendet kann man diese in Freetz als "Quell-Modell" für den "nofreetz-Modus" nicht auswählen, daher nimmt man die 4020 die ebenfalls mit 16MB NOR-Flash läuft.

 

[MuP]

Ich meine mich dunkel zu erinnern, irgendwo in den Tiefen der AVM-FTP-Server auch GPL-Quellen für den Repeater mal gesehen zu haben, finde es jetzt aber auf Anhieb nicht, seitdem AVM die Quellen so tief versteckt.

Wie soll ich am Besten vorgehen?

Geht schneller als Suchen:
"Der Source Code der als Open Source verbreiteten Dateien kann schriftlich angefordert werden über [email protected] "

 

[NDiIPP]

Noch schneller geht es wenn man gleich auf dem extra von AVM dafür eingerichteten Server "osp.avm.de" nachschaut (ich finde das übrigens ziemlich "aufgeräumt", ein wenig versteckt vielleicht aber nicht "tief versteckt")...

 

[MuP]

Seit kurzem hat der Repeater auch eine 7.01-Firmware bekommen ... Ich meine mich dunkel zu erinnern, irgendwo in den Tiefen der AVM-FTP-Server auch GPL-Quellen für den Repeater mal gesehen zu haben, finde es jetzt aber auf Anhieb nicht, seitdem AVM die Quellen so tief versteckt.

Noch schneller geht es wenn man gleich auf den extra von AVM dafür eingerichteten Server "osp.avm.de" nachschaut...

Wo ist dort die 7.01 zu finden ... oder sind die OpenSource-Sources aus 2014 unverändert in der 7.01 in Verwendung?

 

[NDiIPP]

Nirgends. Der TE hat auch nicht explizit nach dem Sourcecode für Ver. 7.01 gefragt (für die grundlegende Erkundung bzgl. Flashspeicher usw. reicht auch das dort bereits vorhandene Quelltextpaket).

 

[NDiIPP]

@Ndi Davon sind nicht alle QCA955x basiert

Die von mir genannten Produkte basieren imo auf dem QCA955x (bzw. welche von den mir genannten Modellen sollen nicht auf dem QCA955x basieren?). Die, die ich nicht erwähnt habe, nutzen freilich andere SoCs.

 

[hermann72pb]

@cuma: Ticket erstellen geht derzeit nicht, da trac seit längerer Zeit offline ist. Entwickelst du denn seit Jahren als "closed source" weiter für dich alleine oder kann man deine Erfolge irgendwo in der freien Wildbahn (z.B. auf git oder sonst wo im Web) finden? Dein Bild für die 1750 zeigt aber eine ziemlich alte 6.23-Firmware. Würde es auch mit 7.01 laufen? Denn zumindest bei den 7390 und anderen Boxen fängt es gerade seit den Firmwares >~6.50 "spannend" zu werden, die Firmware überhaupt auf die Box drauf zu bekommen.
@MuP & @NDiIPP: Meine Versuche, diesen neuerdings extra für OSS eingerichteten FTP-Server von AVM spontan zu finden (google, andere Suchmaschinen, AVM-Suche) waren nicht vom Erfolg gekrönt. Daher meine Bezeichnung als "versteckt". Wenn man es sich gemerkt hat, dass es osp.avm.de heißt, mag es sein, dass es einfach klingt, wenn man es aber nicht weiß, findet man es nicht. Früher ist man über die AVM-Webseite irgendwann mal durch ein Paar Links auf der entsprechenden Seite des allgemeinen FTP-Servers gelandet. Heute nicht. Wir müssen es aber nicht vertiefen.
Und weil ich es nicht gefunden hatte, wusste ich nicht, ob die Quellen für 7.01 schon da sind. Da die Firmware an sich für den Repeater erst seit ein Paar Tagen gibt, dauert es mit den Sourcen vermutlich länger. Für die Anfangsversuche brauche ich die Sourcen aber nicht wirklich. Ich könnte aber die AVMs eigentlich wieder zum Thema OSS-Verletzung nerven, wie ich es früher öfter gemacht hatte. Aber "schneller" wird es nicht, glaub mir @MuP. Bei den "Flagschiffen" hat es damals 3-6 Wochen gedauert, bis die AVM sich überhaupt bewegt haben. Dann bekamen aber alle hier im Forum fast zeitgleich die Standard-Mail, dass die Sourcen nun auf dem FTP-Server liegen. Immer das selbe Katze-Maus-Spiel. Bei so einem Nieschenprodukt 1750E, den zudem wahrscheinlich kaum einer modifizieren will, kann man den Leidensdruck bei AVM nicht so schnell aufbauen. Ich rechne nicht mehr mit den Sourcen von FW7.01 für den 1750E in diesem Jahr.
@NDiIPP: Danke für die Informationen und für die entscheidenden Tipps mit dem "nofreetz" und 4020 als Basis. "nofreetz" und "make tools" kenne ich zwar nicht, werde mich dann entsprechend "durchkämpfen", wenn ich Zeit dafür finde. Kann sein, dass "nofreetz" was ähnliches ist, was früher "alien" hieß?
Wenn ich dich richtig verstanden habe, brauche ich bei dem Modell mit dem modfs von PeterPawn nicht anzufangen, weil es ja von der dualboot-Fähigkeit der Box quasi "lebt", wenn ich es richtig überblicke.

MfG

 

[NDiIPP]

Denn zumindest bei den 7390 und anderen Boxen fängt es gerade seit den Firmwares >~6.50 "spannend" zu werden, die Firmware überhaupt auf die Box drauf zu bekommen.

Zumindest bei den Modellen mit Ethernetport (z.B. 450E oder 1750E) stellt das kein Problem dar (über den Bootloader). Problematischer ist es dann evtl. nur bei Modellen ohne Ethernetport (z.B. 1160), bei diesen Modellen würde ich aber wohl auch keine modifizierte Firmware ausprobieren wollen selbst wenn das auf Basis einer älteren Firmware, die noch auf dem Gerät läuft, vielleicht möglich wäre.

Meine Versuche, diesen neuerdings extra für OSS eingerichteten FTP-Server von AVM spontan zu finden (google, andere Suchmaschinen, AVM-Suche) waren nicht vom Erfolg gekrönt. Daher meine Bezeichnung als "versteckt". Wenn man es sich gemerkt hat, dass es osp.avm.de heißt, mag es sein, dass es einfach klingt, wenn man es aber nicht weiß, findet man es nicht.

Dass es das Problem sein könnte hatte ich mir schon fast gedacht. Aber für mich ist das eher "nur ein wenig versteckt" aber eben nicht "tief versteckt".
Unter "tief versteckt" verstehe zumindest ich dann tatsächlich etwas anderes...

Kann sein, dass "nofreetz" was ähnliches ist, was früher "alien" hieß?

Nein. Man könnte den nofreetz-Modus vielleicht eher als Ersatz für modfs betrachten. Also Firmware entpacken (mit fwmod), gewünschte Modifikationen durchführen und wieder packen. Man beachte dafür auch das Script "fwmod_custom" in Freetz, das was dort im Bereich "all_no_freetz()" steht wird im nofreetz-Modus beim packen der Firmware ausgeführt, dort sind auch schon ein paar Beispiele enthalten die man für eigene Modifikationen heranziehen kann.

Vorteil des "nofreetz-Modus": Man ist nicht darauf angewiesen, dass eine bestimmte Firmware-Version oder gar bestimmtes Repeater/Fritzbox-Modell von Freetz unterstützt wird, es reicht bereits wenn das verwendete Image-Format seitens Freetz bzw. fwmod unterstützt wird (daher in diesem Fall die Wahl der Fritzbox 4020 per menuconfig). Damit ist man dann auch nicht auf die von @cuma erwähnte direkte Unterstützung von Repeatern seitens Freetz angewiesen.

Wenn ich dich richtig verstanden habe, brauche ich bei dem Modell mit dem modfs von PeterPawn nicht anzufangen, weil es ja von der dualboot-Fähigkeit der Box quasi "lebt", wenn ich es richtig überblicke.

Jein. Dualboot ist (oder war) für modfs sicherlich eine Voraussetzung aber eben nicht nur. Es gibt auch etliche DualBoot-Modelle von AVM die von modfs nach wie vor nicht unterstützt werden, dazu gehört die gesamte GRX5-Reihe mit bspw. Fritzbox 7560, 7580 oder 7590 oder die Broadcom-Modelle 7581 und 7582 oder auch die Modelle 6820 LTE, 7530 (Qualcomm) oder 6360, 6490 und 6590 (Puma 5/6). Alles DualBoot-Modelle von AVM aber von modfs werden (bis jetzt) eben nur die DualBoot-Modelle unterstützt die entweder auf dem VR9 oder AR10 (Lantiq/Intel) basieren. Ein Modell mit SoC von Qualcomm (egal ob DualBoot oder nicht) wird von modfs bisher nicht unterstützt.

 

[hermann72pb]

@NDiIPP: Danke für die ausführliche Aufklärung. Da ich letzte Jahre hier nicht besonders aktiv war, kenne ich diese "nofreetz"-Geschichte gar nicht, "fwmod_custom" dagegen aber aus den früheren Jahren schon. Sind denn diese Erkenntnisse, die du hier preisgegeben hast, in irgendeinem Blog/Wiki veröffentlich oder ist sowas heute nicht mehr "in"? Vor 10 Jahren (wo ich noch hier etwas intensiver unterwegs war) hatten wir versucht dies so gut es ging im FREETZ-Wiki zu posten oder zur Not auch in Form von eigenen Threads hier in IPPF, die damals noch etwas sachlicher und nicht so emotional gelaufen sind, als es heutzutage leider öfter der Fall hier in IPPF ist. Da es freetz.org momentan dauerhaft 502-offline ist, und wehavemorefun.de nicht mehr webseiten-technisch online zu sein scheint, kenne ich da leider momentan auch keine gute Anlaufstelle für. Früher konnte man durch denic.de wenigstens herausfinden, ob die Webseite XY noch demjenigen gehört, der sie früher gepflegt hat. Seit dieser Datenschutz-Orgie von EU sind mittlerweile auch die Zeiten ade. Also, man bekommt die benötigten Informationen heutzutage deutlich schwieriger, obwohl man mehr vernetzt ist. Die GIT-Kopie der FREETZ.Wiki ist zwar grundsätzlich gut, ist aber offline und wird dann nicht mehr gepflegt, was auch sehr schade ist.
Aber genug Gerede... Ich taste mich zunächst durch diese "nofreetz"-Geschichte durch und dann mal sehen, vielleicht gelingt es mir sogar meine 1750E da in die Liste der unterstützten Boxen aufzunehmen und den Stand von cuma zu erreichen, allerdings dann mit FW 7.01. Ich halte euch auf dem Laufenden...

MfG

 

[NDiIPP]

Sind denn diese Erkenntnisse, die du hier preisgegeben hast, in irgendeinem Blog/Wiki veröffentlich

https://freetz.org/wiki/help/howtos/development/repack_fw#Verwendungvonfwmodimnofreetz-Modus

bzw. (da freetz.org derzeit offline):
https://freetz.github.io/wiki/help/...ck_fw.html#Verwendungvonfwmodimnofreetz-Modus

Da es freetz.org momentan dauerhaft 502-offline ist, und wehavemorefun.de nicht mehr webseiten-technisch online zu sein scheint,

https://boxmatrix.info/wiki/BoxMatrix

Beides (freetz.org offline und wehavemorefun nicht mehr vorhanden) also noch keine wirkliche Ausrede, ist jetzt halt nur woanders zu finden (freetz-Website siehe Kopie bei GitHub) bzw. hat einen neuen Namen...

 

[hermann72pb]

boxmatrix hatte ich auch schon mal ergoogelt, mir war aber die Hintergrundgeschichte dazu nicht bekannt, dass es der offizielle Nachfolger von wehavemorefun nun ist. Und hier im IPPF wird es gerade mal nur 1x am Rande erwähnt: boxmatrix.info. Es scheint relativ neu zu sein und vom Ansatz her und von der Idee her wahrscheinlich sogar moderner als zuvor. Bloß, ich bin kein ### und kein IRC-Freak und verstehe von vielen Sachen da nur Bahnhof. Ich habe auf Anhieb nicht verstanden, wie man dort z.B. eigene Sachen ins WIKI posten kann und ob es überhaupt dort so gewollt ist. Wahrscheinlich muss man sich da wieder einlesen. Bloß dafür habe ich leider keine Zeit, genau so wenig, um mich in IRC einzuarbeiten. Trotzdem danke für die Quelle. Rein passiv als Informationsquelle mit einer funktionierenden Suche und Verlinkung kann man sie alle Male gut gebrauchen.
Zur Offline-Kopie des trac-s hatte ich es oben schon erwähnt: Das ist und bleibt eine Übergangslösung. Die gefühlte Hälfte der Links funktionieren nicht und so richtig suchen kann man da auch nicht (ja, ich weiß es gab dafür irgendeinen Hack mit GOOGLE, man muss aber diesen Hack erstmal wieder suchen und finden, um zunächst suchen zu können). Darum ist die Situation derzeit für einen, der nicht gerade die letzten drei Jahre dort und hier im IPPF intensiv mitgelesen hat, schon sehr frustrierend. Ist aber meine persönliche Meinung und ich werde mich da durchkämpfen.
Danke fürs "Update"!

MfG

 

[koyaanisqatsi]

Moin

Google und mein bevorzugtes metager.de erlauben den site: Parameter.
Das ist kein Hack, wird aber garantiert von Hackern gern benutzt.


Beispiel: site:ip-phone-forum.de koyaanisqatsi signieren firmware

 

[hermann72pb]

Danke für den Tipp. Ich meinte aber etwas anders, als ich vom "Hack" gesprochen hatte: Freetz-Wiki jetzt auf GitHub Pages erreichbar. Mag sein, dass es sogar ähnlich über site: funktioniert, das klang aber so, als ob es dort eingebaut wurde oder werden sollte, quasi als Ersatz für die standard-trac-Suche.

Ist aber jetzt hier an der Stelle egal. Und metager nutze ich auch, wenn ich von der "präparierter" Google-Suche genervt bin.

Jetzt bin ich aber genug mit euren Informationen und Tipps versorgt und muss nur Zeit für finden...

MfG

 

[PeterPawn]

Ja, leider ist der PR (https://github.com/Freetz/freetz.github.io/pull/1) für das Umstellen der Suche im geretteten Wiki-Inhalt auf Google, immer noch nicht in das Upstream-Repo mit dem Wiki-Inhalt eingepreist.

Ich wage mal die Prognose, daß der Trac-Server in der alten Form nicht wiederauferstehen wird und damit auch die alten Tickets weg sind, sofern sich niemand die Arbeit macht und die DB auf irgendeine andere Plattform umstrickt bzw. dort aus den DB-Inhalten neue "Issues" generiert.

Aber das war lange genug bekannt (quasi "angesagt") und wenn sich niemand um die Sicherung der alten Tickets gekümmert hat, war es wohl nicht wichtig genug.

Ich fand und finde diese Idee ohnehin nicht gut (die Gründe kann man hier nachlesen: https://github.com/Freetz/freetz/pull/37#issuecomment-385399651), daher kam für mich die Beschäftigung mit dem Sicherungsproblem auch nicht in Frage.

Wenn jemand aktuell Probleme hat (wie auch @hermann72pb z.B. beim "callmonitor"), kann man diese ja nunmehr als GitHub-Issue melden und damit die "Neuzeit" bei den Tickets einläuten. Da kein Aas mehr im Trac suchen kann, kann einem auch niemand vorwerfen, man würde nur ein Problem erneut melden, was im Trac-Ticket #xyz schon lange "behandelt" würde.

 

[er13]

WLAN Repeater bzw. Powerline Modelle sind nicht viel anders als die Fritz!Boxen (sind mit den NOR-Boxen vergleichbar). Der Aufwand, diese Framework-technisch zu unterstützen, dürfte geringer sein als z.b. die Unterstützung neuer Architekturen (X86, ARM). Es ist nur so, dass es bisher keine richtige Nachfrage da war bzw. kein Patch zur Verfügung gestellt wurde. 1750 zu unterstützen ist meiner Einschätzung nach eine Frage von maximal 2 Stunden.

 

[hermann72pb]

@er13: Für dich vielleicht ja, wenn du es tagtäglich machst. Ich würde sicherlich etwas länger brauchen. Mache ich aber gerne, um in die Thematik wieder etwas intensiver einzusteigen. Wie oben bereits empfohlen, steige ich zunächst mit "nofreetz" ein und dann mal sehen. Vielleicht nehme ich mir einfach eine Box als Beispiel und per Copy-Paste füge die 1750E an entsprechenden Stellen von Config.in ein. Da muss ich natürlich auch noch alle patches durchgehen und genau überlegen, welche denn bei der Box überhaupt Sinn machen. Aber vermutlich wird sich make schon mal melden, wenn es mit einem oder mit anderem Patch nicht geht.
Und wo ich es mir gerade diagonal angesehen habe: Config.in habt ihr ganz schön zerpflückt und weggepackt. Ist zwar schön und strukturiert jetzt, erleichtert aber in meinem konkreten Falle die Suche nicht unbedingt: Früher hätte ich in einer Datei gesucht, jetzt muss ich zunächst hinter dem Sinn der Aufteilung von Config.in hinterhersteigen. Und nur so mal am Rande: Ich bin kein gelernter/studierter Informatiker, wie ganz viele von euch...
Von daher, es wird schon seine Weile dauern.

MfG

 

[hermann72pb]

Mein erster Versuch mit "nofreetz" war leider erfolglos. Ausgewählt hatte ich (wie oben empfohlen) 4020 als Vorlage (wobei es wahrscheinlich egal wäre). Dann Firmware der 7050E nach dl heruntergeladen und unter menuconfig als Quelle angegeben. Image wurde gebaut und signiert. Danach habe ich kernel.image (aus modified) mit push_firmware auf 1750E übertragen. Danach waren alle LEDs dunkel, was relativ komisch ist. Der Repeater scheint nach dem beschreiben von mtd1 nicht zu rebooten (warum auch immer), obwohl "push_firmware" eine erfolgreiche Übertragung und reboot vermeldet. Also, Stecker raus wieder rein und der Repeater geht danach in die ewige Reboot-Schleife (Power-LED blinkt ein paar mal, danach leuchten alle LEDs kurz auf und es geht wieder von vorne los).
Um den Repeater zu retten, habe ich ihm wieder die kernel.image, allerdings diesmal aus "original" mittels push_firmware verpasst. Und diesmal blieb Power-LED leuchten, Repeater schien wieder nicht von alleine zu rebooten, obwohl push_firmware es erfolgreich vermeldet. Wieder Stecker raus, Stecker rein. Diesmal bootete der Repeater mit der gereteten Original-Firmware. Also, push_firmware funktioniert schon mal. Das ist das einzig positive. Nun meine Fragen:
1. Im Unterschied zu "nofreetz"-Anleitung aus der WIKI, wo es steht, dass alle Patches und Beispiele zunächst auskommentiert sind, scheint es doch andersrum zu sein. Denn ich musste nichts aktivieren, einige Patches waren da unter "all_no_freetz" bereits aktiviert. Ich kann natürlich jetzt versuchen, sie alle zu deaktivieren und damit eine Firmware bauen. Mal sehen, ob ich damit Erfolg habe. Und dann schrittweise weiter...
2. Die modifizierte kernel.image war kleiner als nicht modifizierte. Das gibt mir schon was zu bedenken...
3. Die von mir ausgewählte 4020 hat noch keine 7.01-Firmware. Bei der 1750E experimentiere ich natürlich mit der Firmware 7.01. Kann das der Grund sein? Soll ich vielleicht eine andere Box als Vorlage nehmen? Wenn ja, welche?
4. Dass der Repeater nach "push_firmware" immer aus dem Stecker gezogen werden muss, ist etwas nervig. Ist ein solches Verhalten bereits jemandem (vielleicht bei einer anderen Box) aufgefallen? Gibt es dazu abhilfe? Ich könnte natürlich nächstes Mal versuchen den "hängenden Repeater" per ftp zu erreichen, nachdem push_firmware meinte, dass es bereits rebootet wurde. Mal sehen, ob die ftp-Verbindung noch bestehen bleibt und ich per Hand den Repeater überreden kann zu rebooten...

EDIT: Das Deaktivieren aller Skripte und Patches unter all_no_freetz bringt auch keinen Erfolg mit sich. Modifiziertes kernel.image ist immer noch kleiner als Original.
Mit dem Aufhängen des Repeaters passiert es auch, wenn man "zufuss" per FTP mit dem Bootloader redet und danach mit "quit" die FTP-Verbindung verlässt. Danach konnte z.B. push_firmware die Box nicht ansprechen. Man musste wieder den Stecker ziehen. Kann sein, dass da irgendwelche Probleme mit dem unsauberen Schließen der FTP-Verbindung gibt?

MfG

 

[PeterPawn]

Der Repeater hat wieder eine Firmware, die unterhalb des NMI-Boot-Vectors schon "fertig hat" ... ich würde (einfach mal zum Test und aus reiner Vorsicht) den originalen Block (aus dem AVM-Image) zwischen 0xBE0000 und 0xBE1000 auch noch (vor der Prüfsumme und natürlich auch erst am Offset 0xBE0000, nachdem hinter dem SquashFS-Image bis dahin aufgefüllt wurde mit Nullen) an die (fertige) "kernel.image" anfügen - die Daten in diesen 4 KB sehen schon verdächtig nach "echten Sprungtabellen" aus, besonders die ab 0xBE0490.

Etwas kleiner kann die Datei am Ende ruhig werden (die 4 KB des NMI-Boot-Vectors fehlen schon mal per se, wenn man sie nicht anfügt) und die Kompression könnte etwas effizienter sein - das beobachte ich beim "modfs" auch immer mal wieder - der Kompressor bei AVM hat offenbar "schlechtere" (bzw. eher andere) Parameter. Die Frage wäre also, was "kleiner als" am Ende in absoluten Zahlen bedeutet.

Am besten schaut man auf die Inodes, die vom "mksquashfs" eingepackt werden ... die originale Firmware hat 2589 Inodes und wenn die gesamte Modifikation nur aus dem Hinzufügen des Symlinks für den Telnet-Daemon besteht (beim Repeater kann aber der "telefon"-Daemon den nicht starten und man muß das noch hinzufügen - z.B. zur S85-apps, wie ich es im "modfs"-Thread mal beschrieben habe ... die gibt es auch in dieser Firmware), dann sollten es beim Einpacken eben 2590 sein. Ich würde mich im ersten Anlauf auch erst mal auf diese zwei Änderungen (Symlink von /usr/sbin/telnetd nach /bin/busybox und die Zeile zum Starten in der /etc/init.d/S85-apps) beschränken ... so behält man den Überblick über die Änderungen und kann Kontrollen wie den Vergleich der Daten der eingepackten Dateisysteme noch "zu Fuß" machen.

Die AVM-BusyBox in der Firmware enthält jedenfalls sowohl das "telnetd"-Applet als auch den AVM-Patch für den Test des Symlinks, wie man mit einem "strings" leicht verifizieren kann.

Wenn man während "fwmod" die Daten des neuen FS nicht angezeigt kriegt, kann man hinterher mit "unsquashfs<irgendwas> -k -stat kernel.image" die Daten des neuen FS auch noch einmal abfragen. Wenn Du Hilfe brauchen solltest beim Aufbau der zu flashenden Datei, solltest Du die Ausgabe dieses Kommandos für beide Dateisysteme (das originale und das von Freetz erstellte) hier "vorzeigen".

----------------------------------------------------------------------------------------------------------------------------------

Die Bootloader verhalten sich sehr unterschiedlich ... bei manchen muß man sich korrekt anmelden nach dem "connect", bevor man sie mit "quit" wieder verlassen darf und auch dann beenden sie nicht immer von selbst die TCP-Connection - das kann sogar das REBOOT-Kommando dann verzögern, bis der Client seinerseits die Verbindung schließt.

Ich würde in so einem Falle "nc" anstelle eines FTP-Clients nehmen (da hat man mehr Kontrolle, auch über das Schließen von STDIN mit Ctrl-D) und erst mal das Verhalten des Bootloaders genauer unter die Lupe nehmen ... das sorgt zumindest dann nicht mehr für Kopfzerbrechen, ob ein bestimmtes Verhalten nun am Bootloader oder an der gerade geschriebenen Firmware bzw. am FTP-Dialog dabei liegt.

Auf der sicheren Seite (was die mehrmalige "Erreichbarkeit" des FTP-Servers innerhalb eines Startzyklus angeht) ist man nach meiner Erfahrung dann, wenn man sich vernünfig anmeldet und erst dann mit "QUIT" beendet (das macht eigentlich das AVM-Recovery-Programm auch immer so) ... deshalb verhalten sich meine "eva_tools" auch unterschiedlich unter Linux (wo es mir zuviel war, einen funktionsfähigen FTP-Client in das Discovery-Skript zu packen, weil das ansonsten mit "socat" arbeitet - im Gegensatz zu den anderen Skripten, die mit "nc" ans Werk gehen ... die Linux-Version versucht also in den Standardeinstellungen gar nicht erst ein "connect" zum FTP-Server) und unter Windows. Bei den PowerShell-Versionen ist es ja simpel, ein "normales" FTP-Login auch noch zu versuchen und daher halten diese die Box dann auch durch die FTP-Verbindung direkt nach dem "Finden" fest - in den Standardeinstellungen, denn man kann es natürlich abstellen.

Ansonsten kann man das Flashen ja auch mal mit "recover-eva" aus dem Freetz-Trunk versuchen ... das ist zwar auch "blind" bei der korrekten Fehlerbehandlung, aber "push_firmware" ist irgendwie noch viel mehr "old-style", auch wenn es bei OEM-Boxen (Alice, Telekom, usw.) vielleicht mehr kann - das ist hier ja aber gar nicht die Aufgabenstellung. Und eine Auswertung des Fehlercodes bei einem "ncftpput"-Aufruf springt einem bei "push_firmware" jetzt auch nicht gerade ins Auge ... die kann ich aber auch nur übersehen haben, weil es durch die "Zusatzfunktionen" etwas unübersichtlich im Skript ist.

 

[hermann72pb]

... ich würde (einfach mal zum Test und aus reiner Vorsicht) den originalen Block (aus dem AVM-Image) zwischen 0xBE0000 und 0xBE1000 auch noch (vor der Prüfsumme und natürlich auch erst am Offset 0xBE0000, nachdem hinter dem SquashFS-Image bis dahin aufgefüllt wurde mit Nullen) an die (fertige) "kernel.image" anfügen - die Daten in diesen 4 KB sehen schon verdächtig nach "echten Sprungtabellen" aus, besonders die ab 0xBE0490.

Und wie mache ich es am Besten? Soll ich die Stelle in fwmod (oder wo auch immer) finden, wo schon was ähnliches getan wird und dort einfach die Adresse erweitern oder per Copy-Paste noch eine Zeile dem Code hinzufügen, wo es gemacht wird oder meintest du eher zufuss an fwmod vorbei? Bevor ich wieder 3 Stunden danach suche, wäre einen Anschubser in die richtige Richtung für mich schon mal wertvoll. In der Art, wie du es mit nc und Co. ausführlich durchgekaut hast. So detailliert muss es nicht sein, Anschubsen mit 2-3 Stichworten oder ein Link zu einem von deinen wertvollen Erklärungen in einem anderen Thread genügt schon.
Ich habe irgendwie das Gefühl, dass die Box ziemlich früh "einfriert" und dann per watchdog rebootet. Das Verhalten ist auf jeden Fall deutlich anders, als vor ein Paar Tagen mit meiner 7490 und dem callmonitor. Dort hatte man wirklich 3-4 Minuten Zeit und konnte sich auf der Box einloggen und sogar was machen. Hier kommt es definitiv gar nicht zu. Übrigens, macht es Sinn hier diese tolle Support-Datei mit der letzten Kernel-Panik herauszufischen? Gibt es die denn überhaupt bei dem Repeater? Ich schaue mal und melde mich, wenn ich was dazu finde.
Ich baue gerade die Firmware nochmal auf einem "echten" Linux-Rechner (Mint, Ubuntu basiert). Davor war es in der VM mit FREETZ-LINUX (der natürlich auf Ubuntu 18 LTS mittlerweile hochgezogen ist). Ich erwarte da keine großen Unterschiede, da beides fast den gleichen Ubuntu als Grundlage hat, aber sicher ist sicher... Für push_firmware musste ich sowieso den Linux-Rechner nehmen. Es ist jetzt einfach bequemer dort gleich dann zu bauen, um kernel.image nicht immer hin und her schieben zu müssen.
Und die von er13 oben angekündigten 2 Stunden habe ich alleine schon mit dieser "nofreetz"-Orgie verbraten. Wobei ich dadurch natürlich eine Menge gelernt habe und mich jetzt hier langsam anfange in der Thematik wieder zurecht zu finden. Es ist aber wirklich durch diese Signaturen, Nullfüllen-Geschichten usw. deutlich komplizierter geworden, als es noch vor 10 Jahren war...

EDIT: Und bitte ein Tipp (Stichwörter für die Suche oder direkt Link zum Thread), wie ich den nc richtig "bedaten" muss, um mit dem Bootloader zunächst überhaupt zu reden. Mag sein, dass ich vor lauter Wald die Bäume nicht sehe, meine Suche in FREETZ-Wiki und hier im Forum nach "nc eva", "netcat ftp eva adam2" und allen weiteren noch denkbaren Kombinationen brachte mich höchstens zu irgendwelchen irrelangen Diskussionen in den 100-seitigen Threads oder was ähnlichem, aber zu keinem Einzeiler. Auch das Studieren von deinem eva-tools-Skript brachte mich auch zu keinem Erfolg... Um das Ding durchzudringen, benötige ich weitere 2-3 Stunden, die ich nicht habe...

EDIT2: Crash-Report habe ich nun auch herausgefischt (s. Anhang).
EDIT3: Mac-Adressen im Crash-Report unkenntlich gemacht.

MfG