[Info] FRITZ!Box-Kennwort vergessen ... was nun? (Mail-)Recovery a la AVM oder besser nicht?

Na, dann bin ich ja nicht allein ;-)

Bei mir stellt sich das zur Zeit so dar:

Gemäß Post#3 habe ich YourFritzt auf meine Raspi geclont.
Dann von den Scripten ./yf/toolbox/build_schellinabox_implant_image, ./eva_tools/eva_discover und ./eva_tools/eva_to_memory die Shell auf #! /bin/bash angepasst
Dann mit juis_check die FritzOS-Version gecheckt und heruntergeladen.
Mit build_shellinabox_implant_image das SIAB-Image erstellt (FritzOS-Größe: 27514880; SIAB-7490.image-Größe: 5670144, wohl weil dort nur benötigte Dateien drin sind).
Box vom Strom getrennt.
dann mit eva_disvover gemäß post#3 (mit meinen IP's) gestatet. eva_discover versucht die box zu erreichen
Box am Strom angeschlossen und nach wenigen Sekunden scheint eva_discover die Box erreicht zu haben (kann man deutlich erkennen, denn der Cursor springt passend eine Zeile weiter)

Dann allerdings steht der Cursor blinkend in der nächsten Zeile und wartet auf was auch immer, während die Box fröhlich ihr eigenes FritzOS bootet, bis sie letztlich vollständig hochgefahren ist und ich mich auf ihr auch per Browser anmelden kann.
Mehr passiert allerdings nicht. Im Linux kann ich jetzt warten, aber es passiert nichts.
Was sollte denn passieren? (Entschuldige Peter Pawn, wenn ich wieder was überlesen haben sollte). Müsste eine Ausgabe auf dem Linux kommen? Sollte die Box nicht das SIAB-7490.image booten? Oder habe ich das gänzlich falsch verstanden?
 
Ich kann das durchaus auch verstehen ... nicht umsonst habe ich den letzten Satz in #1 noch verfaßt, als ich selbst dann festgestellt hatte, welche Länge es am Schluß hatte.

Das war halt auch noch zu einem Zeitpunkt, wo es deutlich mehr Optionen zur Formatierung hier im IPPF gab ... jetzt machen die nicht mehr ausgewerteten BBCode-Tags das nur noch unübersichtlich. Ich hätte vermutlich auch schon länger etwas daran geändert ... leider gibt es parallel noch ein 50.000-Zeichen-Limit für Beiträge und das ist ebenfalls überschritten, ich kann also #1 nicht einmal mehr sinnvoll ändern.

Dieser Thread war eigentlich auch mehr ein Versuch, das Prinzip dieses Startens eines eigenen OS aus dem RAM zu verdeutlichen ... anhand eines konkreten Beispiels "aus dem Leben". Daß es dabei etwas weitschweifiger zugeht, als bei einer "straffen Aufzählung" der notwendigen Schritte, ist auch Absicht.

Ich kann tatsächlich auch "ganz kurz" - das setzt aber beim Leser dann noch eher voraus, daß er sich jeden Schnipsel bei Unklarheiten selbst zusammensucht ... ich finde nichts so irritierend, wie eine "Anleitung", die erst nach und nach präzisiert wird und wo sich die notwendigen Aktionen dann auf 20 Antworten verteilen - schon die fehlende Erwähnung des "sh-Problems" in diesem Thread ist ein Ärgernis, was ich so nicht vorausgesehen habe. In anderen Threads habe ich das dann gleich von Beginn an erklärt ... man lernt auch aus den Reaktionen der Leser.

Wenn es tatsächlich nur um die Verwendung der "eva_tools" gehen sollte, ist der gepinnte Thread in "Modifikationen" m.E. ohnehin die bessere "Anlaufstelle". Dieser Thread ist dann der richtige, wenn man sich ein eigenes Image basteln will, mit dem man nur bestimmte Sachen an der Box erledigen möchte ... eben z.B. das Zurücksetzen von Kennwörtern, das Ändern von Einstellungen (die in "normaler Firmware" nicht erreichbar sind - u.a. die "featovl.cfg") oder eben das "Einpflanzen" zusätzlicher Daemons in die YAFFS2-Partitionen (geht nur bei VR9-Boxen), wie es die neue Version für "Shell-in-a-Box" macht.

Was sollte denn passieren?
Wenn die Box nach "eva_discover" offensichtlich das "eva_to_memory" nicht richtig macht, fehlt auch hier vielleicht noch etwas ... ich würde am ehesten darauf tippen, daß "netcat" nicht in der richtigen Version vorliegt.

Ich habe die Voraussetzungen nicht alle noch einmal beschrieben (bzw. das erst später noch genauer aufgeschrieben, denn der andere Thread dürfte jünger sein) ... aber man sollte hier:

https://www.ip-phone-forum.de/threads/fritz-box-7580-firmware-153-06-90-telnet-service-freischalten-geht-auch-für-7560-und-7590.296678/

noch einen Blick in die ersten Absätze werfen, wenn irgendwelche Dateien sich nicht wie erwartet verhalten.

Ansonsten startet die Box (wenn "eva_to_memory" funktioniert), schreibt die Dateien in die "wrapper"-Partition und startet die Box anschließend noch einmal neu ... allerdings wird das alles nur mit den LEDs der Box signalisiert, weil die Linux-Versionen keine zusätzlichen Ausgaben erzeugen bzw. diese in Dateien schreiben und nicht direkt anzeigen.
 
Zuletzt bearbeitet:
Ich häng mich hier mal dran: Es geht um eine jungfräuliche 7430. (frisch aus der Packung)

Habe laut Post #3 ein SIAB Image zusammengebaut. (aus dem derzeitigen 6.83 Image)
Kann die SIAB.image auch gerne zur Verfügung stellen.
Code:
SHA256: C30A05551849B48E161D6582B96FC8BFBE9945FE897BBC913DE6266961F063E3

Habe das Image dann geflasht (unter Windows)
Code:
.\eva_tools\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { BootDeviceFromImage .\eva_tools\SIAB.image }

Sieht alles gut aus, Box startet dann auch neu.

Hätte nach dem Start erwartet, dass dann unter "https://192.168.178.1:8010" (Standard-IP meiner Fritz!Box 7430) eine SIAB-Session bereitsteht. (wie in #3 beschrieben)

Ist aber leider nichts da.

Was mach ich falsch? Ist beim Bauen des SIAB Images was schief gelaufen?
Muss ich vorher noch einen User und Passwort in der Box anlegen? (hab ich getestet, auch dann passiert nach dem Start nichts aufregendes).

Vllt kann ja jemand ja kurz ein SIAB Image für die 7430 bauen und nachschauen, ob es die gleiche Prüfsumme hat.
 
Ich hoffe mal, daß ich nichts bei den Binaries durcheinandergebracht habe ... hast Du denn den Zusammenbau des Images mal tracen lassen? Wurden dabei alle Dateien gefunden und kopiert? Man kann das erzeugte "ext2"-Image ja auch mal mounten lassen (halt mit Offset, die Kernel-Größe (das ist ja der Offset, wenn man die 8 Byte für eine Prüfsumme auch noch abzieht) kann man direkt der AVM-Firmware entnehmen) und sich dessen Inhalt ansehen.

Ich habe vor einigen Wochen die "Organisation" im YourFritz-Master noch etwas geändert ... damit die Binaries nicht automatisch im Checkout enthalten sind (das sollen ja auch mehr werden und damit würde ein normaler Checkout auch immer größer), ist das jetzt ein "submodule" (aus dem Repo "yf_bin" erstellt), was im "bin"-Unterverzeichnis "platziert" werden muß/soll und damit braucht das ggf. ein zusätzliches git-Kommando, damit die Binärdateien auch wirklich vorhanden sind.

Ansonsten kann man nur in der Support-Datei (in der Prozessliste) mal nachsehen ... irgendwelche Log-Dateien werden (wenn ich mich richtig erinnere) nicht erstellt.
 
Code:
YF Stand 05.04.2018 8:11 Uhr
wget http://ftp.avm.de/fritzbox/fritzbox-7430/deutschland/fritz.os/FRITZ.Box_7430.146.06.83.image

toolbox$ sudo TOOLBOX_IMAGE_SIZE=3 ./build_shellinabox_implant_image FRITZ.Box_7430.146.06.83.image > SIAB-7430.image

stat SIAB-7430.image
  Datei: SIAB-7430.image
  Größe: 5652224        Blöcke: 11040      EA Block: 4096   reguläre Datei
Gerät: 812h/2066d       Inode: 18219457    Verknüpfungen: 1
Test ist wegen fehlender HW nicht möglich

Prüfsumme ist jedes mal eine andere, daher wird diese zu diesem Vergleich eher untauglich sein.
 
Zuletzt bearbeitet:
Danke für eure schnellen Antworten!

Tracen habe ich bis dato nichts lassen - das muss ich mir auch erst mal genauer anschauen wie so ein Trace abläuft.
Das mit den Binaries habe ich gesehen, habe ich separat gecloned.

Ist auf jeden Fall schon mal eine andere checksum, das ist doof. Da läuft bei mir wohl was schief. Ich troubleshoote das nochmal (alles auf Anfang).
@stoney wärst du so freundlich mir das Image zur Verfügung zu stellen?
 
Ein Hash-Wert sollte hier nicht wirklich aussagekräftig sein ... da beim "ext2"-Image schon die Uhrzeit seiner Erstellung mit eingeht (eine "inline" erzeugte Shell-Datei hat auch das aktuelle Datum und die aktuelle Uhrzeit), ergibt sich schon zwangsläufig ein anderer Hash.

@TomTomNavigator:
Schick mir mal Dein Image (oder einen Link dahin) an eine der Adressen aus dem PGP-Key.
 
Ich habe es mal extrahiert und gemountet:
Code:
vidar:/tmp # find SIAB -type f -ls
       39   1221 -r-xr-xr-x   1  root     root      1243624 Jun  1 19:41 SIAB/bin/busybox
       99      1 -rwxr-xr-x   1  root     root          555 Jun  1 19:44 SIAB/sbin/copy_payload
      106      2 -rwxrwxrwx   1  root     root         1030 Jun  1 19:44 SIAB/sbin/rc.init
       23      0 -rwx------   1  root     root            0 Jun  1 19:44 SIAB/tmp/mtab
      104      7 -rwxr-xr-x   1  root     root         6910 Jun  1 19:44 SIAB/payload/sbin/add_startup_script
      105   1412 -rw-r--r--   1  root     root      1438332 Jun  1 19:44 SIAB/payload/sbin/shellinaboxd
      102      5 -rwxr-xr-x   1  root     root         4295 Jun  1 19:44 SIAB/payload/etc/init.d/rc.shellinaboxd
       24      1 -rw-rw-rw-   1  root     root           42 Jun  1 19:44 SIAB/etc/inittab
Ich kann da keinen offensichtlichen Fehler finden (so per Augenschein - und natürlich auch in den erzeugten Skript-Dateien und nicht nur beim Blick auf die Liste) ... man muß also genauer in den Ablauf schauen.

Dazu braucht es die Support-Daten ... erstens sollte man da in der Auflistung von "/var/tmp" sehen können, ob überhaupt etwas geschehen ist, da dann eine Datei "/var/tmp/init_rc_replacement" existieren sollte, die eine Kopie der "rc.S" von AVM ist und den zusätzlichen Aufruf für die "rc.shellinaboxd" am Beginn der "gruppe 9" verantwortet. Diese wird mittels "bind"-Mount über die originale "/etc/init.d/rc.S" gelegt ... aber die Ausgabe von "/proc/mounts" ist nicht mehr in allen Firmware-Versionen enthalten - ich weiß also nicht, ob man da schon direkt etwas sieht.

Jedenfalls wird die "add_startup_script"-Datei ja mit "-d" als Parameter aufgerufen und damit sollte sie ihre Aktionen auch ausführlich protokollieren (mit "set -x" aktiviert und in die Datei "/var/tmp/add_startup_script.log" geschrieben) und am Ende auch diese Protokoll-Datei ins TFFS (Node 141) schreiben, wo man sie entweder mit den "erweiterten Support-Daten" direkt aus dem TFFS extrahieren kann oder man nimmt den Weg über die Export-Datei, denn da ist die "/var/flash/calllog" auch enthalten (allerdings in hex).

So rein vom Ansehen finde ich jedenfalls keinen Fehler ... auch nicht bei der "Kontrolle" mit dem Inhalt eines AVM-Images. Zuerst hatte ich das "sed"-Kommando zum Hinzufügen des Starts im Verdacht, aber das sollte auch bei der 7430 passen, denn die "rc.S" ist bei AVM identisch zu anderen Modellen.
 
Zuletzt bearbeitet:
Vorweg: Vielen Dank für die Analyse!

I ... erstens sollte man da in der Auflistung von "/var/tmp" sehen können, ob überhaupt etwas geschehen ist, da dann eine Datei "/var/tmp/init_rc_replacement" existieren sollte, die eine Kopie der "rc.S" von AVM ist und den zusätzlichen Aufruf für die "rc.shellinaboxd" am Beginn der "gruppe 9" verantwortet.

Hab mir die (erweiterten) Supportdaten erstellt: Da ist nichts von init_rc_replacement zu sehen.
Nur nochmal zur Sicherheit, mehr als die beiden commands mache ich nicht.

Code:
PS C:\Users\Thomas Heinz\Downloads> .\EVA-Discover.ps1 -maxWait 120 -Debug -Verbose
VERBOSE: Sending discovery packet (1) ...
VERBOSE: Sending discovery packet (2) ...
VERBOSE: Sending discovery packet (3) ...
VERBOSE: Sending discovery packet (4) ...
VERBOSE: Sending discovery packet (5) ...
VERBOSE: Sending discovery packet (6) ...
VERBOSE: Sending discovery packet (7) ...
VERBOSE: Sending discovery packet (8) ...
VERBOSE: Sending discovery packet (9) ...
VERBOSE: Sending discovery packet (10) ...
VERBOSE: Sending discovery packet (11) ...
DEBUG: Received UDP packet from 192.168.178.1:5035 ...
VERBOSE: Trying to connect to the FTP port to hold up the device in bootloader ...
EVA_IP=192.168.178.1
True
PS C:\Users\Thomas Heinz\Downloads> .\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { BootDeviceFromImage .\SIAB.image
 }
DEBUG: Response:
220 ADAM2 FTP Server ready

================
DEBUG: Sent
USER adam2
================
DEBUG: Response:
331 Password required for adam2

================
DEBUG: Sent
PASS adam2
================
DEBUG: Response:
230 User adam2 successfully logged in

================
DEBUG: Sent
SYST
================
DEBUG: Response:
215 AVM EVA Version 1.2589 0x0 0x47409

================
DEBUG: Sent
GETENV memsize
================
DEBUG: Response:
memsize               0x08000000

200 GETENV command successful

================
DEBUG: Memory size found    : 08000000
DEBUG: Image size found     : 0x00563f00
DEBUG: Set memory size to   : 0x07a9c100
DEBUG: Set MTD ram device to: 0x87a9c100,0x88000000
DEBUG: Sent
SETENV memsize 0x07a9c100
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
SETENV kernel_args_tmp mtdram1=0x87a9c100,0x88000000
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
TYPE I
================
DEBUG: Response:
200 Type set to BINARY

================
DEBUG: Sent
MEDIA SDRAM
================
DEBUG: Response:
200 Media set to MEDIA_SDRAM

================
DEBUG: Uploading file '.\SIAB.image' to '0x87a9c100 0x88000000' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,12,12)

================
DEBUG: Sent
STOR 0x87a9c100 0x88000000
================
DEBUG: Response:
150 Opening BINARY data connection

================
DEBUG: Response:
226 Transfer complete

================
True

Naja, ich bastel die Woche mal weiter wenn ich Zeit habe, erst mal geht die normale Arbeit vor.
Danke für die super Unterstützung hier soweit!


//UPDATE:

Habe jetzt einfach nochmal das Image von stoney getestet - damit gehts!
Nunja, lag / liegt tatsächlich an meinem erstellten Image - was auch immer ich da getrieben habe.
 
Zuletzt bearbeitet:
Code:
freetz@linux-6n8s:~/YourFritz/eva_tools> ls
7412_skip_auth.image   EVA-FTP-Client.ps1   eva_to_memory      image2ram
build_in-memory_image  EVA_FTP.cs           eva_to_memory.log  prepare_jffs2_image
Discovery.cs           eva_get_environment  FTPClient.cs       profile.ps1
eva_discover           eva_store_tffs       FTPtoEVA.ps1       README.md
EVA-Discover.ps1       eva_switch_system    functions          yf_helpers
freetz@linux-6n8s:~/YourFritz/eva_tools> cat eva_to_memeory.log
cat: eva_to_memeory.log: Datei oder Verzeichnis nicht gefunden
freetz@linux-6n8s:~/YourFritz/eva_tools> cat eva_to_memory.log
220 ADAM2 FTP Server ready
USER adam2
331 Password required for adam2
PASS adam2
230 User adam2 successfully logged in
SYST
215 AVM EVA Version 1.2834 0x0 0x47409
TYPE I
200 Type set to BINARY
MEDIA SDRAM
200 Media set to MEDIA_SDRAM
P@SW
227 Entering Passive Mode (192,168,178,1,12,12)
RETR env
150 Opening BINARY data connection
226 Transfer complete
SETENV memsize 0x08000000
200 SETENV command successful
SETENV kernel_args_tmp mtdram1=0x88000000,0x88000000
200 SETENV command successful
TYPE I
200 Type set to BINARY
MEDIA SDRAM
200 Media set to MEDIA_SDRAM
P@SW
227 Entering Passive Mode (192,168,178,1,12,9)
STOR 0x88000000 0x88000000
150 Opening BINARY data connection
553 Execution failed.

Was sagt mir das log? Das 7412_skip_auth.image sollte korrekt übertragen worden sein? Btw. trotz imho korrektem clone git ... finde ich die scripte für add_user_to_fritzos und build_add_user_image nicht?
Wahrscheinlich hapert es wieder an dem "Üblichen" socat netcat und 150tausend abhängigen Paketen ;)

Code:
enp1s0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 88:ae:1d:00:36:ba  txqueuelen 1000  (Ethernet)
        RX packets 1150  bytes 395921 (386.6 KiB)
        RX errors 36  dropped 24  overruns 0  frame 0
        TX packets 1307  bytes 204798 (199.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 54  collisions 39

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Lokale Schleife)
        RX packets 5198  bytes 454388 (443.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5198  bytes 454388 (443.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlp2s0: ...

Das eva_discover script kommt auch nicht zu Potte und versteht "enp1s0" als eth0 auch nicht und will allemöglichen Parameter ;) die ja eigentlich gefunden und verarbeitet werden sollen?
Eine Distri zu finden auf Anhieb, die mit freetz und YourFritz mit Wenig Aufwand läuft, ist eher ein Glücksfall.
LG+TX4help @linux-cracks
 
Zuletzt bearbeitet:
Da wurde wohl beim Versuch mit "eva_to_memory" eine Datei mit der Länge 0 angegeben (der Fall, daß die angegebene Datei gar nicht existiert, wird im Skript getestet) ... das Skript berechnet jedenfalls den verbleibenden Speicher entsprechend. Mehr kann man ja leider nicht sehen ... weder wie die Datei heißt, noch wo sie liegt oder welche Eigenschaften ("ls -l" könnte genauso hilfreich sein, wie ein "stat") sie hat.

Die vorbereiteten Erste-Hilfe-Images sind in ein eigenes Repository ausgelagert worden (damit man das Repository auch als (kleineres, nämlich < 1 MB) ZIP-File laden kann), dieses wurde als "submodule" wieder eingebunden. Normalerweise sollte es damit beim Klonen automatisch aktualisiert werden, ansonsten helfen die entsprechenden Git-Kommandos (und nein, ich werde diese hier nicht noch einmal beschreiben) ... auch dann, wenn man die ZIP-Version lädt und entpackt. Das "Problem", daß ich im ersten Anlauf für das Einbinden die SSH-URL verwendet habe (die nur mit passendem SSH-Key funktioniert), wurde auch bereits vor sieben Tagen korrigiert.

Die Änderungen am "eva_discover" und das Erfordernis der Angabe von passenden Parametern sind inzwischen sooo alt (und mehrmals von mir beschrieben), daß mir am Ende nur bleibt, Dir dazu zu gratulieren, daß Du es jetzt auch bemerkt hast - oder war auch das nur die Wiederholung bereits "bekannter Probleme"?

Auch die Änderungen an den Dateinamen bei den Skript-Dateien in "toolbox" haben bereits vier Monate auf dem Buckel (ich habe es etwas übersichtlicher gestaltet und "Ordner" zum Ordnen eingesetzt, weil sie dafür vermutlich gedacht sind) ... warum Du die Dateien nicht findest (bzw. wo und wie Du sie überhaupt gesucht hast), konnte mir meine Glaskugel aber leider auch nicht verraten - wobei ich der ohnehin nicht mehr traue, denn sie konnte mir bei der Frage im letzten Abschnitt des ersten Absatzes ja auch schon nicht helfen.

Sollte es irgendwo eine alte Beschreibung meinerseits geben, die nunmehr entsprechender Korrekturen bedarf, wäre ein Hinweis mit Angabe des entsprechenden Threads/Beitrags im IPPF hilfreich. Es wird sicherlich auch Leute geben, die diese Dateien trotzdem noch finden, denn die Pfade in den anderen Skript-Dateien, welche diese "Hilfsdateien" benutzen wollen, sind ja auch entsprechend angepaßt (sieht man dann beim Blick in diese Dateien) und auch ein "find"-Kommando wäre sicherlich innerhalb der Dateistruktur fündig geworden ... der direkte Zusammenhang zwischen dem englischen "find" und dem deutschen "finden" ist ja auch nicht der pure Zufall.

Leider habe ich meine eigene Policy ja nie zu 100% durchgehalten, Beschreibungen nur ein einziges Mal und an einer einzigen Stelle zu verfassen ... da kann es schon sein, daß es veraltete Beschreibungen gibt. Das ist dann der Nachteil des "Nettseins" ... es wird recht unübersichtlich oder arbeitsintensiv (und merkwürdigerweise immer für den Antwortenden und andere Suchende, seltener für den Fragesteller).

Wenn solche Beschreibungen "aus meiner Feder" dann auch noch aus der Xenforo-Zeit des Boards stammen (seitdem funktionieren nun mal nicht mehr alle Formatierungen, die zuvor in vBulletin nutzbar waren und auch die Länge eines Beitrags ist nunmehr auf 50.000 Zeichen begrenzt, was das nachträgliche Ändern von Beiträgen, die vor der Einführung dieses Limits verfaßt wurden, unmöglich macht, sofern sie den Wert überschreiten), dann bin ich gerne bereit, über entsprechende Korrekturen nachzudenken - sofern man mir diese Stellen (in vernünftiger Form) aufzeigt.

Ansonsten gehört es für mich zum "kleinen Besteck" beim Suchen, daß man Ergebnisse in der umgekehrten Folge ihrer Aktualität auswertet und dann ergibt sich der Effekt automatisch, daß die neuesten Änderungen zuerst zur Kenntnis gelangen - es wäre in meinen Augen auch nicht zielführend, künftig auf weitere Änderungen zu verzichten, nur weil es früher mal anders beschrieben wurde.

Im Gegensatz zu Beschreibungen in einer eigenen Site (welche ich absichtlich nicht betreibe) werden ältere Beiträge in einem Bulletin-Board nun mal immer irgendwie von neuen Entwicklungen überholt ... aber man macht ja AVM auch keine Vorwürfe, daß die Handbücher für Versionen vor 06.5x nicht mehr zur aktuellen Firmware passen und auch die Beschreibungen im IPPF für das Flashen von Firmware über MTD0/MTD1 wurden ja (leider) nicht alle überarbeitet ... obwohl auch diese für neuere Modelle nicht mehr zutreffen. Du wirst also sicherlich nicht von mir jetzt erwarten, daß ich (proaktiv) alle alten Beschreibungen auch noch anpasse, wenn ich irgendeine kleinere Änderung vorgenommen habe ... zumal ich diese Änderungen in den meisten Fällen auch noch in einem IPPF-Beitrag erwähne oder gar erläutere.

Wenn jemand sich berufen fühlt, eigene Beschreibungen für alle Änderungen meinerseits zu verfassen, kann ich ihn oder sie nur dazu ermutigen ... eine "Verpflichtung" meinerseits, nach jeder Änderung alle bisher verfaßten Beiträge auf ihre fortdauernde Gültigkeit zu prüfen (und jede, aber auch wirklich jede Stelle zu korrigieren), besteht jedenfalls nicht. Alles, was ich schreibe und anderen zur Verfügung stelle, ist "AS IS" ... steht so auch in der Lizenz, die anderen das Recht zur Benutzung einräumt.

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

Wahrscheinlich hapert es wieder an dem "Üblichen" socat netcat und 150tausend abhängigen Paketen
Ja, das ist wahnsinnig unübersichtlich, wenn ein Skript eine passende Shell und ein weiteres Programm benötigt ("socat" und "netcat" sind es ja nur dann, wenn man auch zwei Skripte benutzen will), welches vielleicht nicht automatisch auf jedem Linux-System installiert ist, aber mit wenigen Zeilen installiert werden kann und die bisher aufgetretenen Probleme dann auch noch ausführlich beschrieben sind.

Die 150k Pakete, die ansonsten noch benötigt werden, bilden dann vermutlich das Linux-OS ... oder was meinst Du da genau? Wäre Dir ein C-Quelltext, bei dem dann die komplette Build-Umgebung vorhanden sein muß (vom Compiler bis zu den passenden Header-Files samt aller Abhängigkeiten) lieber? Wenn ja, schreib' Dir einen ... genau deshalb stelle ich ja nicht nur "Code" oder eine "Anleitung" zur Verfügung, sondern bemühe mich auch noch, dessen Funktion und ein paar Zusammenhänge (im Rahmen meiner bescheidenen Möglichkeiten) zu beschreiben.

Manchmal (aber nur manchmal) plagt mich aber auch nur die Frage, warum sich manche Leute es dann überhaupt noch antun, diese Skript-Files benutzen zu wollen, wenn das alles so furchtbar ist. Funktioniert es bei Dir nicht, benutze es einfach nicht oder gewöhne Dir rein sachliche Fragen (und der zitierte Text gehört für mich nicht in diese Kategorie) und einen angemessenen Umgang miteinander bei Deinen "Fehlermeldungen" an und dazu gehört es dann auch, daß Du einmal gegebene Antworten und erläuterte Standpunkte akzeptierst und nicht ständig aufs Neue versuchst, da irgendwie "zu bohren" ... hier offenbar wieder beim Thema "Linux-Distribution".

Wie und womit Du Deinerseits "Freetz" benutzt, hat (im räumlichen Sinne) keine tangentiale Beziehung zu meinem Gluteus Maximus ... welche Voraussetzungen für den (bei vielen merkwürdigerweise deutlich reibungsloseren) Einsatz der Angebote(!) aus dem YourFritz-Repository erfüllt sein müssen bzw. wie man diese herstellt oder was man ggf. an den Skript-Dateien ändern muß, ist hinreichend thematisiert. Ich weiß ja nicht, woher Du den "Anspruch" ableitest, daß ein und dieselbe Linux-Installation bei Dir sowohl für Freetz als auch für die YourFritz-Skripte passen müßte ... ich leite daraus jedenfalls nicht für mich die "Verpflichtung" ab, meinerseits nun auf einem Ubuntu-System zu arbeiten und zu entwickeln, nur weil Freetz sich mehr für Debian-basierte Distributionen erwärmen kann als für andere.

Gewöhnst Du Dir das Provozieren nicht ab, landest Du wieder auf der "Ignore"-Liste - dafür ist mir meine Zeit dann am Ende doch zu schade und die Hoffnung auf "Einsicht" kann ich wohl ohnehin begraben. Auch habe ich keine Lust mehr, mich im Nachgang darüber zu ärgern, daß ich mich wieder einmal zu einer Reaktion auf solche Provokationen "verleiten" ließ ... damit habe ich dann wieder den heutigen Nachmittag zu kämpfen.
 
Code:
freetz@linux-6n8s:~/YourFritz/toolbox> ls -la   
insgesamt 20556
drwxr-xr-x  4 freetz users     4096 22. Jun 19:29 .
drwxr-xr-x 27 freetz users     4096 22. Jun 19:14 ..
-rwxr-xr-x  1 freetz users    21738 22. Jun 19:14 build_add_user_image
-rwxr-xr-x  1 freetz users    21016 22. Jun 19:14 build_reset_tainted_image
-rwxr-xr-x  1 freetz users    26099 22. Jun 19:14 build_shellinabox_implant_image
-rwxr-xr-x  1 freetz users    21178 22. Jun 19:14 build_skip_auth_image
-rw-r--r--  1 freetz users 20899840  4. Dez 2017  FRITZ.Box_7412.137.06.83.image
drwxr-xr-x  2 freetz users     4096 22. Jun 19:14 image
drwxr-xr-x  2 freetz users     4096 22. Jun 19:14 scripts
freetz@linux-6n8s:~/YourFritz/toolbox> sudo ./build_skip_auth_image FRITZ.Box_7412.137.06.83.image >../7412_skip_auth.image
[sudo] Passwort für root:
freetz@linux-6n8s:~/YourFritz/toolbox> ls
build_add_user_image       build_shellinabox_implant_image  FRITZ.Box_7412.137.06.83.image  scripts
build_reset_tainted_image  build_skip_auth_image            image
freetz@linux-6n8s:~/YourFritz/toolbox> cd ..
freetz@linux-6n8s:~/YourFritz> ls
7412_skip_auth.image  bin           eva_tools  helpers  luavar                         README.md         squashfs  tr-064
addons                bootmanager   export     juis     mitmproxy-ca.pem               reported_threats  tffs      update_yaffs2
autoupdate            csharp        first_aid  led      PeterPawn.asc                  scriptlib         toolbox   YourFritz.asc
avm_kernel_config     customconfig  framework  LICENSE  PSScriptAnalyzerSettings.psd1  signimage         tools
freetz@linux-6n8s:~/YourFritz> cd ..
freetz@linux-6n8s:~> ls
Bilder  bin  Dokumente  Downloads  Musik  Öffentlich  Schreibtisch  Videos  Vorlagen  YourFritz
freetz@linux-6n8s:~> cd YourFritz
freetz@linux-6n8s:~/YourFritz> ls -la
insgesamt 164
drwxr-xr-x 27 freetz users  4096 23. Jun 15:06 .
drwxr-xr-x 18 freetz users  4096 23. Jun 14:42 ..
-rw-r--r--  1 freetz users     0 23. Jun 15:06 7412_skip_auth.image
drwxr-xr-x  3 freetz users  4096 22. Jun 19:14 addons
drwxr-xr-x  2 freetz users  4096 22. Jun 19:14 autoupdate
drwxr-xr-x  3 freetz users  4096 22. Jun 19:14 avm_kernel_config
drwxr-xr-x  2 freetz users  4096 22. Jun 19:14 bin
drwxr-xr-x  2 freetz users  4096 22. Jun 19:14 bootmanager
drwxr-xr-x  2 freetz users  4096 22. Jun 19:14 csharp
drwxr-xr-x  4 freetz users  4096 22. Jun 19:14 customconfig
cut

Der Hinweis auf eine Grösse 0 für das image war zielführend. Weshalb trotz vermeintlich richtiger Syntax nur eine leere Datei bei herumkommt? K.A. oder ggfs. ein Berechtigungsproblem.

Das eva_discover kommt mit der installierten OpenSuse Tumbleweed und nachinstalliertem netcat-openbsd wohl aufgrund der ständigen Netzwerkaktivierungen -das ist träger als unter W10- nicht zurecht.
Ergo spielt es für mich keine grössere Rolle, ob die scripte korrekt sind oder nicht, da ohne Stoppen in adam2 kein Fortgang mit darauf aufbauenden Scripten möglich.
LG
 
Wie man den Problemen mit der automatischen Netzwerkkonfiguration auch aus dem Weg gehen kann (und das mit dem Switch funktioniert auch unter Linux), habe ich in einem anderen Thread (wenn auch am Beispiel von Windows) vor nicht allzu langer Zeit noch einmal beschrieben.

Wenn man unter Tumbleweed die Netzwerk-Konfiguration über "wicked" machen läßt (auch wenn der dann halt über "systemd" läuft) und mit statischen Adressen auf dem Interface arbeitet (es gibt ja keinen DHCP-Server, wie soll "wicked" da beim "ifup" irgendwoher eine IP-Adresse beziehen), dann sollte das locker innerhalb der 5 Sekunden reagieren ... bei mir klappt das in unter einer Sekunde (trotz "systemd" muß man fast sagen).

Wenn natürlich das Interface dynamisch konfiguriert wird und bei "fehlendem Kabel" (aka stromloser FRITZ!Box) das komplette Interface abgemeldet wird, dann ist auch das oben angemerkte Problem mit dem Interface-Namen "enp1s0" nachvollziehbar ... "stirbt" das Interface oder ist es noch gar nicht vorhanden, kann auch dessen explizite Angabe beim Aufruf von "socat" (das ist dann das Ergebnis der Angabe bei "INTERFACE=") nichts daran ändern.

Das ist dann also eher eine generelle Frage der Einstellungen ... im Yast-Kontrollcenter muß/sollte man für den Netzwerk-Adapter konfigurieren (alles unter "System / Network Settings"):
Code:
General -> Activate Device -> At Boot Time
Statically Assigned IP Address -> mit entsprechenden Angaben für Adresse, Maske und Hostnamen
Dann bleibt erstens der Adapter auch dann "erhalten", wenn da mal kein Kabel drin steckt und zweitens gibt es keine Pause beim Warten auf irgendeinen DHCP-Server für die IP-Adresse, wenn das Interface aktiviert wird (was dann zwar bereits beim Booten erfolgt, aber man braucht ja ohnehin irgendeine Adresse für den Adapter und auch beim Booten kann das nervig sein, wenn der "systemd" dann erst lang und breit auf einen - ohnehin nicht vorhandenen - DHCP-Server warten will).

Gerade dann, wenn man das in einer VM betreibt, kann man sich aber auch problemlos einen zweiten Adapter basteln, der als "Bridge" direkt auf den Netzwerk-Adapter des Hosts zugreift (NAT oder "host only" funktioniert hier nicht, weil beides keine Broadcasts an die Box durchlassen würde und höchstens für "gerichtete Verbindungen" taugt, wenn da noch NAT erfolgt) und ggf. mit seiner statischen Konfiguration gar nicht dafür gedacht ist (oder zumindest nicht dafür verwendet wird), die Maschine mit dem Internet zu verbinden, sondern nur für den Zugriff auf eine startende FRITZ!Box dient. Das macht es dann vielleicht leichter, die VM auch in "wechselnden Umgebungen" einzusetzen, wo die dynamische Verwaltung des Netzwerk-Adapters für die Internet-Verbindung die bessere Idee ist.
 
Wenn man unter Tumbleweed die Netzwerk-Konfiguration über "wicked" machen läßt
Diese Option "wicked" kannte ich nicht, da ich an anderer Stelle gesucht hatte und den Menue-Punkt nicht ausgeklappt hatte. Damit läuft es neben einer statitischen IP. Danke.
Dass die Skripte rund um die *.image-Erstellung nicht laufen liegt wohl an dem leeren Verzeichnis "bin", was wohl ausgelagert wurde nach yf_bin. Das Clonen von yf_bin erwartet ein Passwort, was ich nicht kenne. Das Entpacken der *.zip Datei via "dolphine" lässt mutmasslich einige Pfade/Abhängigkeiten und Benutzerrechte abhandenkommen, sodass sämtliche generierten *.image 0Byte gross sind und die Scripte auch innerhalb gefühlter 2-3 Sekunden fertig sind, was auf einer Atom-CPU mit Auspacken->Verändern->Signaturberechnen...->Einpacken wohl unnatürlich kurz wäre.
Btw
Gerade dann, wenn man das in einer VM
Das Linux läuft native auf einem Acer EM350, wo im BIOS die VM-Option abgeschaltet/fehlt/ausgelassen wurde
LG
 
Das Clonen von yf_bin erwartet ein Passwort, was ich nicht kenne.
Etwas genauer bitte ... das Klonen von https://github.com/PeterPawn/yf_bin.git sollte kein Kennwort erfordern. Wenn da noch irgendwo eine SSH-URL dabei ist (ich verwende logischerweise SSH für die Commits, weil ich dann keine Credentials angeben muß, da die Public-Keys der verwendeten Rechner und Accounts im Repository hinterlegt sind), dann müßte ich die ändern ... aber in der ".gitmodules" sehe ich nur noch HTTPS-URLs (die ich auch ohne Kennwortaufforderung von anderen PCs aus abrufen/klonen kann) und daher verstehe ich nicht, wo da ein Kennwort erforderlich sein soll (bei SSH und fehlendem Public-Key wäre das wieder der Normalfall).

Das Auslagern der zwei Verzeichnisse mit den binären Dateien (einmal "yf_bin" im Verzeichnis "bin" und einmal "first_aid" im gleichnamigen Verzeichnis) sollte dazu dienen, beim Klonen bzw. Herunterladen als ZIP-Datei von GitHub deutlich weniger Daten zu bewegen, wenn man den Inhalt dieser beiden Verzeichnisse gar nicht benötigt. Damit sank die Datenmenge bei der Übertragung (sofern die beiden "submodules" nicht auch zu klonen sind, dann ist der Gewinn naturgemäß nicht vorhanden) von knapp 50 MB auf knapp 2 MB ... zumal auch die neuere Git-Version mit der Unterstützung des "Wire-Protokolls" nicht so schnell von mir erwartet wurde - aber der "Gewinn" ist hier ohnehin auch lange nicht so groß, selbst wenn man die Binärdateien (wie ich es bisher gemacht hatte) auf verschiedene Branches verteilt.

Theoretisch sollten die Submodule beim Klonen automatisch mit eingeschlossen werden (es gibt lokale Einstellungen, mit denen man das Ein- bzw. Ausschalten könnte) ... wenn das nicht automatisch geschieht (u.a. auch nach dem Download der ZIP-Datei), kann man sich mit dem Kommando:
Code:
git submodule update --init --remote --force <directory>
behelfen ... das sollte für das angegebene "directory" dann zum Download des eingeschlossenen Repos führen. Mit einem "ls -l <directory>" kann/sollte man sich dann davon überzeugen, daß die Dateien auch tatsächlich geklont wurden ... wobei beim o.g. Laden von Submodules die Angabe von "<directory>" optional ist und beim Fehlen der Angabe alle vorhandenen Submodules verarbeitet werden (das ist dann wieder der "volle Klon" mit allen Daten, ggf. auch mit weiteren, künftigen Submodules).

EDIT: Zum Ausführen von "git submodule" oben, muß man zuerst in das Verzeichnis mit dem geklonten Repo wechseln ...

Das Klonen inkl. Submodules gehört offenbar nicht zum "Standard-Repertoire" von "git" ... dann sollte man (sofern man die beiden Submodules auch klonen möchte) zu folgendem Kommando greifen:
Code:
git clone --recurse-submodules https://github.com/PeterPawn/YourFritz.git [<target>]

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

Wenn es keine VM ist mit dem Linux, dann sollte der "Trick" mit dem Ethernet-Switch im Normalfalle (bei jedem anderen, der ebenfalls vor dem Problem steht) auch helfen ... bei "echten" Rechnern wäre meine deutliche Präferenz, die Netzwerk-Konfiguration nicht zu ändern. Es ist i.d.R. einfacher, eine total verkonfigurierte VM wieder auf die Reihe zu bringen (je nach VM-Host (also VM-Software, z.B. VMware WS oder Player) hilft schon ein Snapshot zur Sicherung des Ausgangszustandes) als ein Bare-Metal-System.
 
Zuletzt bearbeitet:
Hmm ... das verstehe ich gar nicht mehr.

"ksshaskpass" ist ja ein SSH-Plugin und wenn das zum Einsatz kommt, wird eben ein SSH-Kennwort "abgefragt". Warum das aber für eine ganz offensichtliche HTTPS-URL erfolgt (jedenfalls steht das ja so im Fenster), verstehe ich nicht und ich kann es aus dem Screenshot leider auch nicht wirklich erkennen.

Bei mir würde so ein Problem aber auch eher selten auftauchen, da meine SSH-Keys ja bei GitHub hinterlegt sind und ich damit solche Abfragen ohnehin nicht zu Gesicht bekomme.

Aber auch beim Test auf einer definitiv "frischen" Raspbian-Installation (sogar mal mit deutscher Locale) klappt es bei mir (Repo-Stand d976e2791a1ebb7fe29ce5430beeabdcfd931cb7 vom 16.06.2018) ohne solche Nachfragen, obwohl kein SSH-Key hinterlegt ist:
Code:
pi@raspberrypi:~ $ git clone --recurse-submodules https://github.com/PeterPawn/YourFritz.git yf
Klone nach 'yf' ...
remote: Counting objects: 2602, done.
remote: Compressing objects: 100% (19/19), done.
remote: Total 2602 (delta 6), reused 20 (delta 5), pack-reused 2577
Empfange Objekte: 100% (2602/2602), 18.62 MiB | 5.94 MiB/s, Fertig.
Löse Unterschiede auf: 100% (1581/1581), Fertig.
Submodul 'bin' (https://github.com/PeterPawn/yf_bin) für Pfad 'bin' in die Konfiguration eingetragen.
Submodul 'first_aid' (https://github.com/PeterPawn/first_aid.git) für Pfad 'first_aid' in die Konfiguration eingetragen.
Klone nach '/home/pi/yf/bin' ...
remote: Counting objects: 128, done.
remote: Compressing objects: 100% (107/107), done.
remote: Total 128 (delta 23), reused 126 (delta 21), pack-reused 0
Empfange Objekte: 100% (128/128), 10.72 MiB | 4.73 MiB/s, Fertig.
Löse Unterschiede auf: 100% (23/23), Fertig.
Klone nach '/home/pi/yf/first_aid' ...
remote: Counting objects: 20, done.
remote: Compressing objects: 100% (15/15), done.
remote: Total 20 (delta 5), reused 20 (delta 5), pack-reused 0
Submodul-Pfad: 'bin': '62c3d702f4abb78ca026b69385715ceb407325bb' ausgecheckt
Submodul-Pfad: 'first_aid': '1caf1f082eb93e5e1fb88bcf1169c70674efc992' ausgecheckt
pi@raspberrypi:~ $
Mir fehlt also etwas die Phantasie, woran das nun liegen soll und ich kann es auch nicht nachstellen.

Tritt es denn immer noch auf? Was ist denn das "yourfritz-master" im Screenshot für ein Verzeichnis? Gibt/gab es darin ggf. schon eine ältere Kopie des Repos (die neue würde ja als "yf" unterhalb dieses Verzeichnisses gespeichert), die eine andere ".gitmodule"-Datei enthalten könnte? In der Version vor dem 16.06. hatte ich ja eine SSH-URL für "first_aid" hinterlegt, das dann aber geändert, nachdem mich @er13 darauf aufmerksam gemacht hatte, daß das Klonen mit SSH-URL bei ihm auch nicht klappen will.
 
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.