.titleBar { margin-bottom: 5px!important; }

[Frage] WLAN Repeater 1750E modifizieren

Dieses Thema im Forum "FRITZ!Box Fon: Modifikationen" wurde erstellt von hermann72pb, 29 Nov. 2018.

  1. er13

    er13 Aktives Mitglied

    Registriert seit:
    20 Dez. 2005
    Beiträge:
    1,000
    Zustimmungen:
    19
    Punkte für Erfolge:
    38
    Kleiner Hinweis: die Unterstützung für 1750 ist seit gestern in trunk enthalten, zumindest im Sinne, es kann direkt ausgewählt werden (ohne Umwege über 4020).

    Der NMI-Vektor wird wie bei allen anderen Boxen mit diesem einfach entfernt. Das ist der Hauptgrund, warum kernel.image im "no freetz"-Modus kürzer ist. Der zweite Grund ist vermutlich die Tatsache, dass AVM ein via NFS-exportiertbares SquashFS erzeugt und Freetz dagegen nicht.

    Bisher hat das blinde Entfernen vom NMI-Vektor zu keinen Nebeneffekten geführt. Sofern kernel.image am Ende kleiner ist als 0xBE0000, so kann es natürlich einfach daran scheitern, dass nicht mal Nachschauen, ob an dem Offset sich ein NMI-Vektor befindet, möglich ist. Eventuell reicht es, das zu kurze kernel.image auf 0xBE0000 + 4096 mit dummy 0-Werten aufzufüllen.
     
  2. hermann72pb

    hermann72pb IPPF-Promi

    Registriert seit:
    6 Nov. 2005
    Beiträge:
    3,611
    Zustimmungen:
    2
    Punkte für Erfolge:
    38
    #22 hermann72pb, 2 Dez. 2018
    Zuletzt bearbeitet: 2 Dez. 2018
    Ich habe oben Crash-Report hinzugefügt. Bitte kritisch durchschauen, ob euch da was einfällt...
    @er13: Meinst du, soll ich mit dem direkten Auswählen von 1750 lieber weiter testen, als mit nofreetz? Denn ich vermute stark, dass mich dort ähnliche Probleme erwarten, wenn sogar nicht noch mehr...

    EDIT: @PeterPawn: Zum Thema "mit netcat ausprobieren": Ich habe mich doch durchgekämpft. Obwohl ich es immer noch hier nicht finden kann, was man da als Parameter eingeben muss. War ein reines Ausprobieren. Man muss es mal wissen, dass man bei netcat noch "user" und "pass" schreiben muss. Ich meine es irgendwo so gesehen zu haben, bis ich darauf kam, hat es aber gedauert... 10-15 Minuten mit hin und her. Danach war ich drin. Der Repeater hat brav so lange im Boot-Modus gewartet.
    Und es ist so, wie du vermutest: reboot kann ich absetzen, danach kommt "221 Goodbye.", ABER die Box rebootet tatsächlich nur, wenn ich mit STRG-D die Verbindung trenne. Das wird das Problem von push_firmware sein. Es kommt übrigens bei push_firmware immer auch eine Fehlermeldung "ftp: setsockopt (ignored): Permission denied". Könnte sein, dass darin das Problem liegt?
     
  3. er13

    er13 Aktives Mitglied

    Registriert seit:
    20 Dez. 2005
    Beiträge:
    1,000
    Zustimmungen:
    19
    Punkte für Erfolge:
    38
    Aus Deinem Crash-Log:
    Code:
    [    4.599994] squashfs: SQUASHFS error: Major/Minor mismatch, older Squashfs 3.76 filesystems are unsupported
    
    7.01 nutzt SquashFS-4.x. 4020 passt als sinnvolle Vorlage demnach doch nicht, s. config/avm/packaging.in#L6 (4020 in Fritz!OS-6.8x nutzt den Kernel 2.6.32).

    Es wäre besser, wenn Du 1750 direkt auswählst, auf "no freetz" umstellst und dann make aufrufst, sprich keins der Schritte manuell ausführst. Es dauert dann zwar deutlich länger, weil die Toolchain gebaut wird (es ist zwar nicht notwendig, aber Stand jetzt wird sie gebaut), aber dafür ist das Risiko des Anwenderfehlers deutlcih geringer.
     
  4. hermann72pb

    hermann72pb IPPF-Promi

    Registriert seit:
    6 Nov. 2005
    Beiträge:
    3,611
    Zustimmungen:
    2
    Punkte für Erfolge:
    38
    Copy-Paste-Fehler:
    Code:
    ---> kernel:  downloading...tools/freetz_download dl/fw ""7530_07.02"-release_kernel.tar.xz" "" "72042917adc8e11569e14138ee581cd8"
    
    --2018-12-02 16:36:56--  http://freetz.magenbrot.net/7530_07.02-release_kernel.tar.xz
    Auflösen des Hostnamens freetz.magenbrot.net (freetz.magenbrot.net) … 31.172.113.113
    Verbindungsaufbau zu freetz.magenbrot.net (freetz.magenbrot.net)|31.172.113.113|:80 … verbunden.
    HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
    Länge: 90345600 (86M) [application/x-xz]
    Wird in »dl/fw/7530_07.02-release_kernel.tar.xz« gespeichert.
    
    7530_07.02-release_kernel.tar.xz     100%[====================================================================>]  86,16M  5,93MB/s    in 14s     
    
    2018-12-02 16:37:11 (6,10 MB/s) - »dl/fw/7530_07.02-release_kernel.tar.xz« gespeichert [90345600/90345600]
    
    Download succeeded - "http://freetz.magenbrot.net/7530_07.02-release_kernel.tar.xz"  ->  saved to folder "dl/fw"
    MD5 mismatch for dl/fw/7530_07.02-release_kernel.tar.xz: 72042917adc8e11569e14138ee581cd8 750f8e9800f77d7bb8fc345e635602e2
    
    --2018-12-02 16:37:11--  http://freetz.wirsind.info/7530_07.02-release_kernel.tar.xz
    Auflösen des Hostnamens freetz.wirsind.info (freetz.wirsind.info) … 188.165.115.52
    Verbindungsaufbau zu freetz.wirsind.info (freetz.wirsind.info)|188.165.115.52|:80 … verbunden.
    HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
    Länge: 90345600 (86M) [application/octet-stream]
    Wird in »dl/fw/7530_07.02-release_kernel.tar.xz« gespeichert.
    
    7530_07.02-release_kernel.tar.xz     100%[====================================================================>]  86,16M  6,78MB/s    in 13s     
    
    2018-12-02 16:37:24 (6,59 MB/s) - »dl/fw/7530_07.02-release_kernel.tar.xz« gespeichert [90345600/90345600]
    
    Download succeeded - "http://freetz.wirsind.info/7530_07.02-release_kernel.tar.xz"  ->  saved to folder "dl/fw"
    MD5 mismatch for dl/fw/7530_07.02-release_kernel.tar.xz: 72042917adc8e11569e14138ee581cd8 750f8e9800f77d7bb8fc345e635602e2
    
    --2018-12-02 16:37:25--  http://freetz.3dfxatwork.de/7530_07.02-release_kernel.tar.xz
    Auflösen des Hostnamens freetz.3dfxatwork.de (freetz.3dfxatwork.de) … 31.172.113.113
    Verbindungsaufbau zu freetz.3dfxatwork.de (freetz.3dfxatwork.de)|31.172.113.113|:80 … verbunden.
    HTTP-Anforderung gesendet, auf Antwort wird gewartet … 404 Not Found
    2018-12-02 16:37:25 FEHLER 404: Not Found.
    
    Download failed - "http://freetz.3dfxatwork.de/7530_07.02-release_kernel.tar.xz"  ->  error code 8
    make/linux/kernel.mk:30: recipe for target 'dl/fw/7530_07.02-release_kernel.tar.xz' failed
    make: *** [dl/fw/7530_07.02-release_kernel.tar.xz] Error 1
    
    
    Ich weiß zwar nicht, warum er mal die Quellen einer 7530 braucht, aber egal, ich versuche es entweder unter menuconfig unter override zu bereinigen (wenn es mir gelingt) oder die Quellen dort sogar ganz zu löschen, wie es bei 4020 der Fall war.

    MfG
     
  5. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,621
    Zustimmungen:
    629
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    Ein großer Teil der Fragen hat sich in meiner "Abwesenheit" ja schon erledigt ... zum Kopieren des NMI-Vectors (denn schaden kann er eigentlich auch nicht, zumindest nicht, solange der AVM-Kernel verwendet wird und damit die Adressen passen sollten, so es tatsächlich welche sind):

    Einfach mit "dd" und den passenden Parametern "bs=256 skip=$(( 0xBE00 )) count=16" die 4 KB ab 0xBE0000 aus der AVM-Datei ausschneiden und diesen Block an die Kombination aus "kernel.image" und "filesystem.image" ("kernel.image" ist hier tatsächlich der pure, aber bereits gepackte Kernel und nicht das "combined file") an Position 0xBE0000 wieder anfügen, nachdem man die Kombination dieser beiden Dateien (ebenfalls durch "dd" von "/dev/zero" mit den passenden Parametern, die natürlich von der Länge der anderen beiden Files abhängen) auf die notwendige Größe aufgeblasen hat.

    Erst danach kommt dann die Prüfsummenbildung (die man für die Installation über den Bootloader aber ohnehin nicht braucht - die können max. noch als Absicherung gegen Platzprobleme beim Entpacken für das direkte Update im FRITZ!OS dienen) ... die Scorpion-basierten Devices sind eben wieder eine etwas andere Plattform (auch wenn sie MIPS sind, so sind sie doch 74K und schon wieder etwas anders organisiert, auch im Startprozess) und ich würde mich nicht darauf verlassen, daß bei älteren Architekturen (und das waren bisher eigentlich immer ältere) das Auslassen des NMI-Boot-Vectors keine Folgen hatte.

    Da braucht bloß beim Design mal ein NMI als "Mittel der Wahl" für eine Unterbrechung in einer bestimmten Situation vorgesehen sein (vom Prozessorhersteller oder vom Gerätedesigner) und schon macht sich das Fehlen des Vectors im laufenden Betrieb auch bemerkbar. Bei den alten Geräten war das ja deshalb nicht der Fall, weil ziemlich früh in der Initialisierung dann auch die entsprechenden Register mit anderen Basisadressen für diese Sprungverteiler geladen wurden ... wenn das hier nicht geschieht, kann diese Tabelle theoretisch über die gesamte Betriebszeit vonnöten sein.

    EDIT: "seek" war falsch (ist für die Ausgabe), oben auf "skip" korrigiert.
     
  6. er13

    er13 Aktives Mitglied

    Registriert seit:
    20 Dez. 2005
    Beiträge:
    1,000
    Zustimmungen:
    19
    Punkte für Erfolge:
    38
    @hermann72pb:
    in Deiner .config sind vermutlich noch die OVERRIDE-Einstellungen aktiv/enthalten. 72042917adc8e11569e14138ee581cd8 ist jedenfalls die Checksum von AVM_SOURCE_4020_06_50 und 750f8e9800f77d7bb8fc345e635602e2 - von AVM_SOURCE_7530_07_02

    Die Sources von 7530.07.02 werden deswegen benötigt, weil es bisher keine 07.0X Sources für 1750/6820 gibt (diese Modelle verwenden ab Fritz!OS-7 den Kernel 4.4.60) und 7530.07.02 neben 4040.07.01 bisher die einzigen von AVM veröffentlichten 4.4.60er Sources sind.

    Kleine Anmerkung am Rande: in dem Paket source-files-FRITZ.Box_scrpn_7490-07.01.tar.gz sind auch 4.4.60er Kernel-Sources enthalten, da weiß ich allerdings nicht, was es auf sich hat. Denn 7490 und scrpn passen irgendwie nicht zusammen, was auch immer die mysteriöse 7490-HW238 für eine Box sein mag.

    @PeterPawn:
    Sicher? Ich hätte gesagt, es ist eher genau umgekehrt, es ist das bereits "combined" image (um mal bei Deinen Begriffen zu bleiben). Es könnte sein, dass man es auch an das "pure" kernel.image dran gehängt werden kann und erst danach das filesystem.image, aber das würde etwas Platz verschwenden. Bei den anderen Boxen befindet sich der NMI-Vektor jedenfalls "mitten" im SquashFS-Image (was eben dafür sprechen würde, dass es das "combined" file ist).
     
  7. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,621
    Zustimmungen:
    629
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    #27 PeterPawn, 2 Dez. 2018
    Zuletzt bearbeitet: 2 Dez. 2018
    Ich meinte meinen Satz, daß man die beiden Ausgangsdateien "kernel.image" und "filesystem.image" zusammenkopieren müsse:
    , um den "Rumpf" für die Verlängerung der Datei auf 0xBE0000 zu erhalten.

    Zwar stört auch die Signatur am "combined file" (so es von "fwmod" erzeugt wurde) wohl nicht wirklich beim "Verlängern" (die 8 Byte sind dann eben keine Nullen, was das SquashFS ja nicht interessiert, das ist davor schon beendet), aber ich hatte das eben "von Hand" beschrieben (weil ich das selbst auch so machen würde) und nicht auf der Basis der bereits "fertigen" Datei "kernel.image".

    Die heißen nun mal beide so ... wobei es in Freetz sogar sein kann, daß der "pure Kernel" einen anderen Namen hat als "kernel.image" - deshalb habe ich das ja auch noch genauer erklärt, welche Datei (mit welchem Inhalt) ich eigentlich damit meinte.

    PS: Ich gehe mal davon aus, daß 238 der Repeater 3000 sein wird.

    PPS: Ich würde die (aufgefüllte) Datei hier in etwa so erzeugen (wenn sicher ist, daß sie kürzer als 0xBE0000 wäre ohne den Vector) ... den puren Kernel nenne ich mal "raw" zur Unterscheidung:
    Code:
    cat kernel.image.raw filesystem.image.raw /dev/zero | dd bs=256 count=$(( 0xBE00 ))
    
    (ungetestet)
    und dann mit "dd" die 16 Blöcke mit dem Vector noch dahinterkopieren.

    Wenn man es tatsächlich als Option einbauen wollte, den Vector ebenfalls zu übernehmen für andere Modelle, müßte man ja auch unterscheiden, ob das SquashFS hier zu splitten ist (wie es beim Entpacken dann "reverse" erfolgt für die Leseoperationen) oder ob der Vector "reine Zugabe" ist.

    Was mich hier halt stutzig macht, ist die Länge des Blocks ... die 4 KB sind deutlich mehr, als jeder bisher bekannte "NMI Boot Vector" und daher nehme ich mal an, daß es nicht mehr ausschließlich dieser ist, auch wenn der halt am Beginn dieser zusätzlichen Daten steht.

    Wenn ich mir die AVM-Datei ansehe, ist das SquashFS wohl bei 0xB80800 irgendwo beendet (zumindest die "sinnvollen und komprimierten Daten", denn da sind schon viele Nullblöcke ab diesem Offset) ... wobei das auch nur eine Vermutung ist und ich nicht im Superblock nachgesehen habe, ob das tatsächlich der Fall ist.

    Wenn das hinten noch die Verwaltungsinformationen des SquashFS-Images sein sollten (die Werte waren aber - iirc - deutlich anders als potentielle Offsets im SquashFS-Image), ist der Vector vielleicht doch "normal lang" ... so genau habe ich nicht hingesehen.

    Wobei das simpel sein sollte, denn die Länge des Images steht ja auch gleich irgendwo am Beginn des Superblocks ... ich hatte nur nicht genug Interesse bisher, das genauer zu untersuchen.
     
  8. hermann72pb

    hermann72pb IPPF-Promi

    Registriert seit:
    6 Nov. 2005
    Beiträge:
    3,611
    Zustimmungen:
    2
    Punkte für Erfolge:
    38
    #28 hermann72pb, 2 Dez. 2018
    Zuletzt bearbeitet: 2 Dez. 2018
    @er13: Bei der 4020 stand eigentlich im menuconfig, dass es dafür keine Sources gibt. Darum war ich davon ausgegangen, dass die Stelle entsprechend leer ist. Ich habe jetzt einfach die korrekte MD5 da eingetragen und somit läuft er jetzt erstmal weiter.
    Und ja, ich hatte zunächst mit der alten .config und "nofreetz" angefangen. Mein Gedanke war: Wenn es klappt, lösche ich im nächsten Schritt die .config und fange von vorne an. Denn in der .config mit der 4020 bin ich noch extra durch alle Einstellungen durchgegangen und habe dort alle möglichen Patches deaktiviert. Ich weiß, dass es wahrscheinlich für "nofreetz" überflüssig war, ich wollte aber auf Nummer sicher gehen...

    EDIT: Im "nofreetz"-Modus ist es durchgelaufen und ich konnte das unsignierte Image erfolgreich flashen. Die Box läuft zwar, da ich allerdings dort zuviel "abgewählt" hatte, läuft kein Telnet und ich kann auf den Repeater so gesehen per ssh/telnet immer noch nicht zugreifen.
    Ich habe inzwischen festgestellt, dass ich bei meinem Ubuntu-System kein ncftp hatte. push_firmware nimmt in dem Fall ftp. Jetzt habe ich ncftp nachinstalliert und damit geflasht. push-firmware mit ncftp war deutlich gespächiger, die Box blieb aber am Ende trotzdem "hängen". Kann ich irgendwie die angeblich hängend bleibende Verbindung "killen"?
    Ich werde jetzt .config löschen und von vorne anfangen. Diesmal aber mit FREETZ (kein nofreetz mehr), signed Image und Minimalkonfiguration...

    MfG
     
  9. er13

    er13 Aktives Mitglied

    Registriert seit:
    20 Dez. 2005
    Beiträge:
    1,000
    Zustimmungen:
    19
    Punkte für Erfolge:
    38
    ok, verstanden, wir meinen dasselbe, ich habe nur deinen Satz nicht genau gelesen

    Auch wenn da ungetestet steht, dd und Pipes bedarf iflag=fullblock (hatten wir schon mal in einem anderen Kontext)
     
  10. hermann72pb

    hermann72pb IPPF-Promi

    Registriert seit:
    6 Nov. 2005
    Beiträge:
    3,611
    Zustimmungen:
    2
    Punkte für Erfolge:
    38
    @er13 und @PeterPawn: Dank eurer Hilfe läuft es! Danke!
    Ich konnte ein signiertes MinimalImage mit FREETZ auf den Repeater erfolgreich flashen und es läuft. Telnet konnte ich auch erfolgreich starten. Nun gehe ich weiter und nehme wenigstens dropbear ins Image.
    Soll ich was mit diesen dd-s testen? Dann gebt mir bitte den vollen Einzeiler oder er13 baut es ein, ich checke aus und gebe euch die Rückmeldung ob es damit läuft.
    Zweiter offener Punkt wäre hängendes push_firmware. Ich persönlich brauche es zwar nicht mehr, würde aber für die Allgemeinheit ein Paar Experimente durchführen, damit wir es wenigstens halbwegs fixen, wenn es uns denn gelingt.

    MfG
     
  11. er13

    er13 Aktives Mitglied

    Registriert seit:
    20 Dez. 2005
    Beiträge:
    1,000
    Zustimmungen:
    19
    Punkte für Erfolge:
    38
    Das folgende gilt fürs Modden im "no freetz"-Modus. Für Dich wahrscheinlich nicht mehr relevant, da Du ja inzwischen Freetz auf dem Repeater hast. Aber der Vollständigkeit halber.

    Telnet wird nicht automatisch gestartet, es wird nur alles vorbereitet, dass es per Telefon-Codes gestartet werden kann (dies ist z.B. hier dokumentiert). Da der Repeater aber keine Telefonie unterstützt, kann über die Codes auch nichts gestartet werden. Du musst aktiv etwas anlegen, was den Telnet starten würde, s. diesen Beitrag von Peter für eine mögliche Lösung.

    Ansonsten wäre die Integration von shellinaboxd die aus Sicherheitsgründen etwas bessere Lösung. Dafür müsstest Du shellinaboxd für die Box erstmal bauen und anschließend bei modfs abschauen, wie man es integriert.
     
  12. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,621
    Zustimmungen:
    629
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    Nur dann, wenn die Eingabedatei ihrerseits ein EOF mitten in einen (partiell gelesenen) Block signalisieren kann, was hier durch das Einbinden von "/dev/zero" als letzte Quelle definitiv nicht der Fall sein kann.

    Das "cat" davor hämmert die Daten einfach der Reihe nach in Richtung STDOUT (selbst wenn beim Übergang zwischen den drei Quellen irgendwo mal keine Blockgrenze erreicht werden sollte) und jeder einzelne Read-Request des "dd" kann immer einen vollen Block (von 256 Byte Länge) lesen, solange "/dev/zero" nicht blockiert, was ich noch nie gehört/gelesen habe.

    @hermann72pb:
    Wenn das Image ohne den Vector funktioniert (das sollte man mit dem Gerät testen, indem mal alle denkbaren "Hardware"-Funktionen, die einen NMI auslösen könnten - bis hin zum Reboot, was auch durch so einen NMI ausgelöst werden könnte - genau testet oder sich die Struktur der originalen AVM-Firmware hinsichtlich des SquashFS-Images doch noch mal genauer ansieht), dann hat sich das Thema ja erledigt ... mich irritierte eben nur die eher ungewöhnliche Größe, wenn das SquashFS-Image wirklich schon davor komplett ist und da ich mich selbst dann immer nur "step by step" vom Original entferne, hätte ich das halt in das eigene Image übetragen (so es wirklich relevant ist und die Daten nicht doch zum SquashFS-.Image gehören).

    Funktioniert das auch so, vergiß das Thema "NMI Boot Vector" einfach wieder.

    @er13:
    Inzwischen hat sich die Welt auch weitergedreht und es gibt neben neuen Browsern (das FRITZ!Box-GUI selbst braucht ja auch mind. HTML5-Support) auch neue Technologien, z.B. WebSockets (auch wenn der vielgerühmte "websocketd" ein Go-Programm ist und damit für die FRITZ!Box wohl keine Alternative).

    Es gibt aber mit "Xterm.js" einen ganz netten clientseitigen Support und darauf basierend mit "ttyd" auch eine hübsche Server-Version. Die braucht dann wiederum die "libwebsockets" ... das kann aber alles keine "rocket science" sein, denn "ttyd" gibt es auch als Paket für LEDE und die Anpassungen für Freetz (bzw. die FRITZ!Box) dürften nicht so gewaltig sein.

    Da Shell-in-a-Box vom ursprünglichen Autoren nicht mehr weiterentwickelt wird (und auch die Version in Freetz dem Debian-Fork von Shell-in-a-Box um einiges hinterher hinkt - und z.B. diesen Fix nicht enthält: https://seclists.org/fulldisclosure/2018/Oct/50), spiele ich mit dem Gedanken, den "ttyd" auch für Freetz aufzubereiten.

    Nicht in naher Zukunft, aber Schritt für Schritt in "kreativen Pausen", beginnend mit der "libwebsockets". Da ich - abseits der Recherchen, was am besten wäre - noch nicht so viel Zeit investiert habe, wäre es mir auch egal, wenn das jemand anderes übernimmt ... ich will das nur vorher abstimmen / klären, damit man sich hinterher an dieser Stelle nicht wieder ins Gehege kommen kann.

    Solltest Du Dich also selbst mit dem Gedanken tragen, das Shell-in-a-Box-Paket in Freetz zu ersetzen (oder auf den Debian-Stand zu hieven), wäre es nett, wenn Du das "ansagst" ... das fiel mir nur ein, als ich von Dir etwas zu "shellinaboxd" las.
     
  13. er13

    er13 Aktives Mitglied

    Registriert seit:
    20 Dez. 2005
    Beiträge:
    1,000
    Zustimmungen:
    19
    Punkte für Erfolge:
    38
    Ich kannte ttyd bisher gar nicht und hatte demzufolge gar nicht vor, daran zu arbeiten.

    Hmm, mir ist irgendwie entgangen, wie alt die in Freetz enthaltene Version inzwischen ist. Ich versuche es auf den Debian-Stand zu aktualisieren, wobei beim 900-box_certificate.patch ich eventuell deine Hilfe benötigen werde.
     
  14. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,621
    Zustimmungen:
    629
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    #34 PeterPawn, 2 Dez. 2018
    Zuletzt bearbeitet: 2 Dez. 2018
    Da der ja (iirc) in einem Unterverzeichnis liegt und nur mit der Option aktiviert wird, kann er ja auch erst mal über die "mk"-Datei deaktiviert werden, wenn es "nicht paßt". Ich weiß selbst auch nicht, was da alles geändert ist (der PR für die Schleife beim Parsen aus dem CVE ist da auch noch gar nicht integriert in diesem Repository) und würde - wenn es wirklich notwendig ist und Du tatsächlich Hilfe brauchst - erst dann dazustoßen, wenn der Rest auf der neuen Version ist.

    Wobei mich das vermutlich nicht vom "ttyd" abhalten kann, weil auch die "libwebsockets" natürlich ein sehr lohnendes "Ziel" ist ... immerhin könnte man damit problemlos auch die (asynchrone) Ausgabe eines Shell-Skripts (oder irgendeines anderen Programms) ohne großartiges "Polling" beim Benutzer im Browser anzeigen - das macht dann CLI-Skripte wieder attraktiv, z.B. ein "modfs" im Fenster, auch ohne daß dafür ein "vollständiger" Shell-Zugriff erforderlich ist bzw. mit deutlich mehr "Formatierungsmöglichkeiten", wenn man die Daten aus dem Socket nicht direkt als Text anzeigen will, sondern ins (HTML-)DOM einbauen möchte.

    Bei "Shell-in-a-Box" oder einem Terminal-Programm muß der Benutzer immer noch "Kommandos" eingeben (die potentiell größte Fehlerquelle) ... das kann aber ohne weiteres auch ein HTML-Button sein, nur muß man dann eben irgendwie den Ausgabestream (wichtig ist hier ja das Asynchrone, auch ohne ständige XHR-Abrufe) zum Browser kriegen und da bieten sich WebSockets dann geradezu an (inkl. der Möglichkeit der sicheren Verschlüsselung, die hier automatisch eingeschlossen ist).

    PS:
    Das habe ich ja auch nicht behauptet ... ich fragte, ob Du das Shell-in-a-Box-Paket irgendwie ablösen willst und die drei Projekte habe ich nur als Beispiele (und meine "Favoriten") verlinkt bzw. angeführt.
     
  15. hermann72pb

    hermann72pb IPPF-Promi

    Registriert seit:
    6 Nov. 2005
    Beiträge:
    3,611
    Zustimmungen:
    2
    Punkte für Erfolge:
    38
    Ich wollte eure Diskussion nicht stören... , habe aber eine Frage zu meinem eigentlichen Vorhaben, warum ich überhaupt 1750 modifizieren wollte:

    Der Repeater erlaubt im Unterschied zu fast allen anderen Modellen noch nicht eigene Zertifikate für die Webseite zu importieren. Sprich, bei jedem Reboot generiert er ein selbstsigniertes Zertifikat, was mich letzte Zeit ziemlich gestört hat, weil ich mich (wie Peter bereits irgendwo hier geschrieben hat) langsam auf die Nutzung von https auch im LAN-Bereich eingewöhne. Bei meinen 7490 und 7390 habe ich erfolgreich meine WILDCARD-Letsencrypt-Zertifikate importieren können (die ich anderswo erzeugt hatte, aber das ist eine separate Geschichte) und bei den Boxen ist seitdem alles "grün". Nun war die Idee, dem 1750E-Repeater die gleichen Zertifikate auf eine andere Art und Weise irgendwie drunterzuschieben.
    Soweit so gut, und auf den ersten Blick scheint es irgendwie möglich zu sein. 1750E hat auch, wie "die großen" Boxen "/var/flash/websrv_ssl_key.pem" und "/var/flash/websrv_ssl_cert.pem" angelegt. webserv_ssl_cert.pem ist auf 1750E leer, was sie dazu veranlast, bei jedem start von ctlmgr ein neues Zertifikat zu erzeugen. Nun habe ich die Zertifikate von einer meinen Boxen auf den Repeater gebracht. Zunächst überleben sie "ctlmgr -s / ctlmgr" (stop / start), Webserver bleibt aber im https-Modus nicht gestartet. Grund dafür ist "# User Certificate" in der ersten Zeile von websrv_ssl_cert.pem. So funktioniert es auf den "großen Boxen" und scheint hier auch irgendwie darauf vorbereitet zu sein, irgendwas fehlt aber dem ctlmgr, um mit diesem "# User Certifikate" zu starten. Nebeneffekt: Der Inhalt von websrv_ssl_key.pem wird brav nach /tmp kopiert und die Zertifikate im flash überleben den Start von ctlmgr zunächst. Das WebIF ist übrigens über http (ohne ssl) erreichbar! D.h. ctlmgr ist nicht komplett tot, es fehlt nur https.
    Nun dachte ich, vielleicht hat der ctlmgr ein Problem mit dieser ersten Kommentarzeile und habe sie entfernt. Was danach passiert, ist ziemlich interessant: Beim start von ctlmgr werden die beiden Zertifikate (key und cert) auf Ursprung zurückgesetzt und wieder ein neues Zertifikat generiert.
    Also, mit "# User Certifikate" in der cert-Datei startet der Webserver nicht als https, ohne Kommentar werden die Dateien im flash überschrieben und ctlmgr startet mit einem selbstsignierten Zertifikat.
    Hat jemand Ideen, wie ich ctlmgr dazu überlisten kann, mit den User Zertifikaten zu starten?

    MfG
     
  16. er13

    er13 Aktives Mitglied

    Registriert seit:
    20 Dez. 2005
    Beiträge:
    1,000
    Zustimmungen:
    19
    Punkte für Erfolge:
    38
    Ich habe nicht vor, shellinabox zu ersetzen. Es spricht aber aus meiner Sicht nichts dagegen, eine (bessere) Alternative für shellinabox zusätzlich aufzunehmen, z.B. ttyd. Ich habe allerdings nicht vor, in naher Zukunft an dem ttyd-Paket für Freetz zu arbeiten. Shellinabox schaue ich mir jedoch an und versuche es auf den letzten Debian-Stand zu aktualisieren.

    p.s. Ich hoffe meine Antworten sind unmissverständlich :)
     
  17. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,621
    Zustimmungen:
    629
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    #37 PeterPawn, 3 Dez. 2018
    Zuletzt bearbeitet: 3 Dez. 2018
    Die Inhalte durchaus ... nur meine Fragen sind halt (leicht) mißverstanden (hoffentlich nicht mißverständlich). ;)

    @hermann72pb:
    Ich weiß zwar nicht, wie Du den privaten Schlüssel für das eigene Zertifikat importiert hast, aber wenn Du das "von Hand" in der Shell machst (der Repeater hat dafür ja kein GUI, wenn ich Dich richtig verstanden habe und man könnte das direkt über "firmwarecfg" als CGI versuchen zu installieren - das wäre dann "wie über das GUI"), mußt Du den trotzdem verschlüsseln (am besten mal nachsehen, was der automatisch generierte als Algorithmus verwendet, steht ja im Klartext im Kopf des Key-Files) ... das Kennwort dafür verrät Dir "decoder" (Funktion "privatekeypassword"), was - unter irgendeinem anderen Namen - auch im Freetz enthalten ist.

    Kann der "ctlmgr" den privaten Schlüssel nicht lesen, generiert er einen neuen ... die Kommentarzeile am Beginn des Zertifikats nutzt AVM wohl als Unterscheidung, ob es ein automatisches oder ein hochgeladenes ist. Selbst wenn die Box den privaten Schlüssel benutzen kann (weil sie ihn entziffern kann mit dem Box-Kennwort - nicht mit irgendwelchen Credentials von Benutzern zu verwechseln), muß immer noch diese Kommentarzeile im Zertifikat stehen (das ist logischerweise unverschlüsselt), damit nicht ständig eines mit der aktuellen IP-Adresse generiert wird (was dann sogar den Schlüssel aus dem Key-File beglaubigt).

    EDIT: Wenn der Import über "firmwarecfg" auch beim 1750E funktioniert, bräuchte man die Firmware dafür gar nicht modifizieren - das ist ähnlich wie beim Update der DOCSIS-Boxen. Da es sich bei "firmwarecfg" um ein CGI-Sammelsurium für alle möglichen Funktionen handelt, stehen die Chancen nicht so schlecht, daß der Import auch dann noch funktioniert, wenn der Punkt im GUI beim Repeater ausgeblendet wird - eigentlich ist das ja nur ein Teil der Lua-Seite, daher müßte da sogar irgendwo eine Variable abgefragt werden, ob die Seite "verstümmelt" werden soll oder nicht. Man könnte also sogar mal nachsehen, ob man das Interface nicht direkt wieder freischalten kann, indem man den Test einfach rauspatcht.
     
  18. er13

    er13 Aktives Mitglied

    Registriert seit:
    20 Dez. 2005
    Beiträge:
    1,000
    Zustimmungen:
    19
    Punkte für Erfolge:
    38
    Hmm, alles nur vom Lesen her.

    Fürs Importieren des eigenen Certificates ist remote_https.lua zuständig. Diese wird wiederum nur dann angezeigt, wenn CONFIG_REMOTE_HTTPS=y ist. Dies für 1750 aber der Fall.

    Damit muss meinem Verständnis nach lediglich die Fernwartung auf 443 einmal aktiviert werden, das Certificate importiert und anschließend die Fernwartung wieder deaktiviert werden (ggf. zu Testzwecken erst aktiviert lassen).

    Und wenn meine Interpretation richtig ist, dann müsste es auch mit einer Original-Firmware funktionieren.

    p.s. Und wenn remote_https.lua doch aus keinem Untermenü heraus auswählbar ist, dann einfach den Pfad auf einer anderen Box abschauen und auf 1750 diesen händisch eingeben (müsste sowas wie ${BOX}/internet/remote_https.lua sein).
     
  19. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,621
    Zustimmungen:
    629
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    #39 PeterPawn, 3 Dez. 2018
    Zuletzt bearbeitet: 3 Dez. 2018
    EDIT: Irrtum meinerseits - Aufklärung weiter hinten im Thread:

    So einfach ist es dann leider doch wieder nicht (ich hatte ja nicht nachgesehen und nur Optionen benannt) ... die "remote_https.lua" unterscheidet sich von der in den DSL-Routern - der Zertifikate-Teil ist gar nicht vorhanden und weder über eine Variable ausgeblendet, noch kann man mit einem Eintrag in der "menu_data.lua" oder den "erlaubten Seiten" beim "lp"-Parameter etwas erreichen.

    Damit fällt der Weg also schon mal aus ... mit etwas Glück funktioniert der direkte Upload über "firmwarecfg" (z.B. mit "curl" aufgerufen, weil das ein "multipart/form-data"-Request sein muß) trotzdem, weil AVM (zumindest bisher) keine Code-Teile dort ausgeschlossen hatte. Das kann man sich dann mit einem Browser von einer anderen Box abschauen (zumindest mit einem, der auch den Blick in den Netzwerkverkehr erlaubt mit passenden Developer-Tools) ... das Einhalten der Reihenfolge der Parameter im POST-Body ist dabei wichtig.

    Wenn das klappt, kann man sich ja überlegen, die relevanten Code-Teile für das Zertifikat wieder in die "remote_https.lua" hineinzupatchen - dann wäre das wenigstens an derselben Stelle wie bei anderen Geräten und gleich ein passendes GUI.

    Der Weg mit dem Kopieren von Hand bleibt einem ja immer noch als ultima ratio ...
     
  20. er13

    er13 Aktives Mitglied

    Registriert seit:
    20 Dez. 2005
    Beiträge:
    1,000
    Zustimmungen:
    19
    Punkte für Erfolge:
    38
    #40 er13, 3 Dez. 2018
    Zuletzt bearbeitet: 3 Dez. 2018
    Sicher?

    Hier ist das Delta zwischen 1750.07.01 und 7490.07.01:
    Code:
    --- 1750.07.01/original/filesystem/usr/www/avm/internet/remote_https.lua
    +++ 7490.07.01/original/filesystem/usr/www/avm/internet/remote_https.lua
    @@ -133,6 +133,21 @@
     cmtable.add_var(ctlmgr_save, "remoteman:settings/https_port" , g_DEFAULT_HTTPS_PORT)
     end
     ctlmgr_save = array.cat(ctlmgr_save, ctlmgr_del)
    +if box.post.activate_remote_ftp then
    +if box.post.random_activatable == "on" and box.post.remote_ftpport == "" then
    +cmtable.add_var(ctlmgr_save, "ctlusb:settings/storage-ftp-internet-with-random-port", "1")
    +end
    +cmtable.add_var(ctlmgr_save, "ctlusb:settings/storage-ftp-internet", "1")
    +cmtable.add_var(ctlmgr_save, "ctlusb:settings/ftp-server-enabled", "1")
    +cmtable.add_var(ctlmgr_save, "ctlusb:settings/nas-enabled", "1")
    +cmtable.save_checkbox(ctlmgr_save, "ctlusb:settings/internet-secured" , "use_ftps")
    +if box.post.manuell_ftp_port ~= "" then
    +cmtable.add_var(ctlmgr_save, "ctlusb:settings/storage-ftp-internet-port" , box.post.remote_ftpport)
    +end
    +else
    +cmtable.add_var(ctlmgr_save, "ctlusb:settings/storage-ftp-internet", "0")
    +cmtable.add_var(ctlmgr_save, "ctlusb:settings/internet-secured" , "0")
    +end
     local errcode, errmsg = box.set_config(ctlmgr_save)
     if errcode ~= 0 then
     local criterr = general.create_error_div(errcode,errmsg)
    @@ -422,6 +437,32 @@
     <div><?lua box.out(get_address( true ))?></div>
     </div>
     </div>
    +<br>
    +<input type="checkbox" id="remoteFtpActive" name="activate_remote_ftp" onclick="onRemoteftpActiv(this.checked)" <?lua if g_ctlmgr.ftp_from_internet then box.out('checked') end ?>><label for="remoteFtpActive">{?159:818?}</label>
    +<p class="form_input_explain">
    +{?159:106?}
    +</p>
    +<div class="formular" id="ftp_box">
    +<p>
    +{?159:803?}
    +</p>
    +<div>
    +<label for="uiViewRemoteFTPPort">{?159:993?}</label>
    +<div class="container ftpindent">
    +<input type="text" id="uiViewRemoteFTPPort" name="remote_ftpport" maxlength="5" onkeyup="modifyFTPAddress()" value="<?lua box.html(g_ctlmgr.ftp_port) ?>">
    +<label for="uiViewRemoteFTPPort">{?159:470?}</label>
    +</div>
    +</div>
    +<div id="ftpAddressBox" class="columns">
    +<div class="fakeLabel">{?159:759?}</div>
    +<div><?lua box.out(get_ftp_address()) ?></div>
    +</div>
    +<div <?lua if g_ctlmgr.expertmode_active == "0" then box.out([[style="display:none;"]]) end ?>>
    +<br>
    +<input type="checkbox" id="uiViewUseFtps" name="use_ftps" onclick="onFtpsOnly()" <?lua if g_ctlmgr.ftps_only then box.out('checked') end ?>><label for="uiViewUseFtps">{?159:13?}</label>
    +</div>
    +</div>
    +<input type="hidden" name="random_activatable" value="<?lua box.html(g_ctlmgr.random_activatable) ?>">
     </div>
     </div>
     <hr>
    
    Ich sehe da außer FTP/FTPS und NAS nichts, was entfernt wurde. Alles, was irgendwie user_cert referenziert, ist weiterhin auch in der remote_https.lua von 1750 enthalten.

    Edit: und insbesondere sind alle onCert*-Funktionen da inkl. der wichtigsten im Kontext dieses Threads onCertImport