[Info] Wie verwende ich denn nun die Skript-Dateien aus YourFritz/eva_tools?

Für die 7490 gibt es ein fertiges Image: https://raw.githubusercontent.com/P...b5714184f16a2ffd7348955b/skip_auth.image.7490 - es spielt an dieser Stelle auch keine Rolle, welche FRITZ!OS-Version auf der Box installiert ist (allerdings habe ich es mit 07.21 noch nicht getestet). Solange AVM beim FRITZ!OS-Update nichts (Entscheidendes) am Aufbau der "ar7.cfg" ändert und der "@SkipAuthFromHomenetwork"-Modus noch existiert, sollte das auch bei einer 07.21 klappen.

EDIT: Hier: https://www.ip-phone-forum.de/threa...l-recovery-a-la-avm-oder-besser-nicht.294386/ ist der originale Thread - aber #1 ist nicht mehr 100% korrekt, weil sich einiges geändert hat. Man müßte/sollte also bis zum Ende des Threads lesen, wenn man noch Infos sucht - andererseits braucht man die Box ja nur mit dem oben verlinkten Image booten (easy, wenn man den Umgang mit den Dateien aus diesem Thread hier beherrscht) und sich dann (ohne jedes Kennwort) dort aus dem LAN anmelden (nachdem die Box mit dem "richtigen" FRITZ!OS noch einmal - automatisch - gestartet wurde).
 
@Mods: Ausnahmsweise mal meinerseits als zwei Beiträge nacheinander, weil die Inhalte praktisch nichts miteinander zu tun haben und sich an unterschiedliche "Adressaten" richten - wenn das nicht in Ordnung ist, bitte einfach zusammenlegen.

Wie ich gerade feststelle steht selbiges in #91. Verdammt, das hätte mir Zeit gespart
Ich will hier (erst recht nicht nach einem Dank) eigentlich auch kein Wasser in den Wein gießen ... aber wenn man #1 genau (und bis "zum Ende" - zumindest bis zum Ende des Linux-Teils) liest, steht das dort auch schon:
Anders als "eva_discover" braucht nun "eva_to_memory" anstelle von "socat" auch nur noch eine Version von "netcat" (unter dem Namen "nc"), wobei hier die "Geschmacksrichtung" aus dem "netcat-openbsd"-Paket die erste Wahl ist. Das "netcat-traditional" (das ist m.W. die GNU-Version) kennt einige der verwendeten Parameter nicht [...]
und auch das wurde nur aus dem "originalen Thread" kopiert (steht dort mithin also noch einmal).

Das mag nicht "prominent" genug hervorgehoben sein, damit es - nach der Code-Box mit dem Aufruf - noch gelesen wird ... ich kann aber #1 auch nicht mehr ohne weiteres ändern, aufgrund von Beschränkungen durch die Xenforo-Software.
 
Recovern musst du nicht. zumindest früher konntest du kurze Zeit nach dem Booten angeben "Passwort vergessen". Dann wurde die Box zurückgesetzt und du konntest sie dann neu einrichten
 
@PeterPawn: Danke für den Link auf das skip_auth.image.7490

... Man müßte/sollte also bis zum Ende des Threads lesen, wenn man noch Infos sucht - andererseits braucht man die Box ja nur mit dem oben verlinkten Image booten (easy, wenn man den Umgang mit den Dateien aus diesem Thread hier beherrscht) und sich dann (ohne jedes Kennwort) dort aus dem LAN anmelden (nachdem die Box mit dem "richtigen" FRITZ!OS noch einmal - automatisch - gestartet wurde).

Wird das skip_auth.image.7490 eigentlich geflashed oder mit diesem nur einmalig gebootet und dabei das Passwort zurückgesetzt? Ich frage, denn Im erstgenanntem Fall müsste ich nach dem Rücksetzen dann ja wieder ein "reguläres" Image flashen, das vorher auf der Box war, oder?
 
Weder noch ... aber hier verweise ich dann doch auf den anderen Thread (Link oben) - es macht keinen Sinn, das alles noch einmal zu erzählen/erklären.
 
Weder noch ... aber hier verweise ich dann doch auf den anderen Thread (Link oben) - es macht keinen Sinn, das alles noch einmal zu erzählen/erklären.

Du hattest davon gesprochen, dass in dem von Dir angegebenen Thread "nicht mehr alles aktuell wäre". Daher hatte ich nachgefragt. Eine kurze Info wäre dann hier nicht als Dopplung, sondern als aktueller Stand zu sehen, über die sich vielleicht auch andere freuen würden.
 
Das "nicht mehr aktuell" bezieht sich nur auf die dort als Beispiele gezeigten Kommandofolgen, die man nach einer Umorganisation im GitHub-Repo nicht mehr 1:1 "abschreiben" kann (was auch nie meine Absicht war, ich will bekanntlich eher "Denkanstöße" oder "Beispiele" geben und keine Rezepte) - und der Hinweis in #101 war ja, daß man dort den Thread "bis zum Ende" lesen sollte, womit man auch an #24 und #38 (da stehen Beispiele für das Klonen) und anderem vorbeikommen sollte.

Und neben meinem Hinweis, daß #1 im anderen Thread nicht mehr 100% aktuell ist, steht ja auch ausdrücklich noch:
andererseits braucht man die Box ja nur mit dem oben verlinkten Image booten
- gepaart mit dem Hinweis, daß die Box danach von selbst noch einmal neu startet. Ich kann daher auch nicht verstehen, wie man auf die Idee kommt, danach müsse man noch eine andere Firmware flashen - was wäre denn dann der "Vorteil" der von mir offerierten "Ersten Hilfe"? Außerdem ist eben im anderen Thread haarklein erläutert, WIE dieses spezielle "skip-auth"-Image arbeitet, welche Änderungen durch das gebootete System an der Box vorgenommen werden und warum das funktioniert - bis hin zum "Zeigen" des dabei eingesetzten Shell-Skripts.

Warum ein "aktueller Stand" (in diesem Thread hier) jetzt - an dieser Stelle, die sogar noch "weiter hinten" ist, als im anderen Thread - besser gefunden oder öfter gelesen werden sollte, als Beiträge in dem anderen Thread, leuchtet mir nicht ein - egal wieviele Leute sich darüber freuen würden. Es gibt sicherlich auch andere (habe ich auch oft genug schon gelesen), die keinen Bock mehr auf "ausführliche Beiträge" meinerseits haben und wenn das am Ende nur das Wiederholen bereits anderweitig bereitgestellter Informationen ist, kann ich das sogar nachvollziehen.

Zumal ein "nicht mehr 100%" (und nochmal: mit Betonung darauf, daß der "Rest" der Beiträge im anderen Thread dann die korrigierten Infos enthält, denn ich schrieb ja auch in #101 schon, dann solle man den Rest des anderen Threads auch noch lesen) ja auch nicht automatisch als "da stimmt praktisch nichts mehr" zu werten ist - die kleinen "Ungenauigkeiten", die sich aus der (absichtlich vorgenommenen) Reorganisation der Repositories bei GitHub ergeben haben, sind vielleicht 2-4 Prozent "vom Ganzen" und da das von mir Geschriebene ohnehin eher darauf baut, daß die Leute den Inhalt verstehen (sonst könnte ich mir die Erklärungen ja auch sparen), fällt das bei mir unter "Änderungen wegen technischen Fortschritts" und daran sollte man sich - auch bei anderen Geräten und Anleitungen - eigentlich schon gewöhnt haben.
 
  • Like
Reaktionen: Parallix
Danke PeterPawn zu Deinen klärenden Ausführungen!

Der Hintergrund meiner Nachfrage war ja der, nach UI-Passwort-Verlust Zugriff auf eine Box zu bekommen, ohne dass deren umfangreiche Konfiguration verloren geht. Es ist wohl nur zu verständlich, dass man sich in einem solchen Fall lieber einmal mehr vergewissert, ob man alles richtig verstanden hat.

Persönlich bin ich übrigens ein Fan guter Rezepte und würde hier im Forum auch nie jemanden kritisieren, der einem bei einem Problem mit einem bereits ausprobierten Rezept aus der Patsche hilft. In diesem Sinne nochmals Danke!
 
  • Like
Reaktionen: Micha0815
Hallo,

ich wollte mal nachfragen, ob es verkehrt ist, das Powershell-Skript ./eva-ftp-client.ps1 mit
Code:
if (-not (.\EVA-FTP-Client.ps1 -Address $BoxIP -ScriptBlock { SwitchSystem } -Verbose -Debug))
, weil ja im Erfolgsfalle ein "true" zurückgegeben wird? ... EVA-Discover.ps1 gibt auch ein "true" bei einer erfolgreichen Verbindung zurück, welches ich abfragen kann...

Vielen Dank.
 
Ich habe mich zumindest bemüht, jeweils den richtigen Hinweis auf Erfolg oder Mißerfolg eines der Skripte zurückzugeben ... die PowerShell gibt halt am Ende die noch in der Pipeline befindlichen Daten auf der Console aus (bei einem "einfachen Aufruf" ist die Pipeline halt "beendet", wenn das Skript abgearbeitet wurde) - wobei der jeweilige Datentyp dann selbst für seine Darstellung verantwortlich ist (ToString()-Methode) und bei boolean-Werten ist das dann eben True oder False als Zeichenkette.

Wertet man das Ergebnis anderweitig aus (eben z.B. mit einem if, wie oben), wird der Wert dafür aus der Pipeline gelesen und damit am Ende nicht länger "angezeigt".
 
Meine jüngsten Änderungen (https://github.com/PeterPawn/YourFritz/commit/cae5d5bcdabf4b6787ee8280a51ac8d67bab42eb) an EVA-Discover.ps1 machen irgendwelche Firewall-Profile bzw. -Freigaben überflüssig, solange nichts "Exotisches" mit den IP-Adressen passiert (z.B. das Suchen nach der aktuellen Adresse einer Box durch die Angabe von 0.0.0.0 als Ziel).

Die Verwendung der "Notfall-Adresse" ist (m.M.n.) eine schlechte Idee, weil bei zwei oder mehr Boxen im Heimnetz (solange man das nicht tatsächlich alles extra neu verkabelt für das Flashen) auch immer eine davon auf diese Adresse reagieren wird - ich würde eher bei der 192.168.178.1 bleiben bzw. gar keinen Standardwert für die Adresse mehr setzen.

Das würde ich heute für meine Skripte auch nicht mehr machen ... aber inzwischen ist es eben auch (als "Mesh") deutlich häufiger der Fall, daß da mehr als eine Box im Netz vorhanden ist und während man z.B. eine Box mit IP-Adresse 192.168.178.12 (bei lokalem Netz 192.168.178.0/24) problemlos auch "verkabelt" flashen kann, wird auf 169.254.1.1 IMMER irgendeine FRITZ!Box (wenn es eine gibt) reagieren (und man weiß nie genau, welche das ist, wenn es mehrere sein könnten).

Außerdem solltest Du noch ein paar mehr Tests einbauen ... denn z.B. Get-NetIPInterface ist nicht immer vorhanden (falls das auch mit älteren Windows-Versionen funktionieren soll bzw. falls dieser Fall, daß das Windows-System zu alt ist, auch erkannt und angezeigt werden soll).

Auch der verwendete Alias Ethernet für das kabelgestützte Netzwerk-Interface ist nicht zwingend der richtige - den Namen kann man ändern und bei Computern mit mehr als einem (Ethernet-)Interface (z.B. Mainboards mit 2 GbE-Schnittstellen) ist es auch sehr wahrscheinlich, daß es unterschiedliche Namen (ggf. mit einem Suffix in Form einer Nummer) gibt.

Wenn Du das Skript generell auf kabelbasierte Interfaces beschränken willst (wobei gerade in Mesh-Umgebungen das auch mit WiFi-Interfaces ginge), kannst Du Dir die Index-Werte für derartige Interfaces auch "suchen" lassen: $ifIndex =$(Get-NetAdapter -Physical | Where-Object { $_.PhysicalMediaType -eq "802.3" } | Select ifIndex) (das kann auch ein Array sein, wenn es mehr als ein Interface gibt) - den Status des Kabels (falls das direkt an der Box angeschlossen ist) liefert die Property MediaConnectionState beim Get-NetAdapter für dieses Interface ... der würde ja "wechseln", wenn man die Box stromlos macht bzw. wenn man sie mit Strom versorgt.

Wenn Du das "Extrahieren" der Dateien aus einem TAR-File mit einbindest, kannst Du auch gleich eine "Erkennung" des richtigen Formats einbauen - das spart den kompletten Parameter isBootableImage (und die möglichen Fehler, die man da machen kann). Ein TAR-File enthält immer die Zeichenkette ./var/ in den ersten sechs Bytes der Datei - das läßt sich leicht überprüfen oder man testet für bootfähige Images auf den Header mit der Signatur und der "Beschreibung" des Kernels, der bei diesen Images am Beginn steht.
 
Ich wollte einfach ein "Wrapper-Skript" für mich schreiben, der den Aufruf Deiner Skripte "automatisiert" ;) ... Aber Deine Hinweise finde ich gut und mal sehen, wie weit ich mit meinen eingeschränkten Powershell-Kenntnissen komme..

Aber grundsätzlich hatte ich folgendes Endanwender-Szenario im Kopf:
neue FritzBox auspacken, auf den Tisch stellen, den Laptop per LAN an die Box anschließen, flashen, Einstellungen vornehmen und dann erst ins Netzwerk einbinden. Ich habe bisher noch nie eine "neue" Box in mein bestehendes Netzwerk gehängt.

Im Standalone-Betrieb bekommt ja der Standard-Laptop seine IP per DHCP, der läuft während des startens der Box noch nicht, daher habe ich die Box immer mit ihrer APIPA-Adresse angesprochen. Wenn ich die Box im Standalone-Betrieb mit ihrer IP 192.168.178.1 ansprechen möchte, braucht das LAN-Interface ja eine feste IP, oder? Sollte das LAN-Interface sich eine APIPA-Adresse generieren, dann kann ich doch nicht auf die 192.168.178.1 zugreifen, oder?

Wenn ich die Box ins bestehende Netzwerk einhänge, dann kann ich sie zwar flashen, aber direkt auf der Box keine Einstellungen vornehmen, da der Switch der "neuen" Box keine IP im bestehenden Netzwerk bekommt, oder?
 
Bei einer direkt (und alleine) verkabelten Box ist die Adresse praktisch egal - die Daten können ja nirgendwoanders hin.

Aber wie geschrieben ... die Benutzung einer bereits komplett verkabelten Box mit ihrer ganz eigenen IP-Adresse (die sie im "normalen Betrieb" ja auch hat/haben muß - da kann man ja auch nicht mit "gemeinsamen" Adressen arbeiten und jede Box kriegt ihre eigene) ist überhaupt kein Problem - man muß die IP-Adresse nur kennen, beim Aufruf angeben und nicht mehr als die eine FRITZ!Box gleichzeitig neu starten. Dann reagiert auch nur diese eine Box auf die UDP-Pakete und meldet sich zurück, NACHDEM sie die gewünschte Adresse eingestellt hat. Und natürlich kann so eine Adresse auch eine sein, die man in seinem LAN grundsätzlich für "neue Boxen" reserviert - es ist auch nicht "Pflicht", daß die verwendete Adresse tatsächlich im FRITZ!OS dieser Box bereits eingestellt ist/wurde. Man kann sich also auch eine (zum eigenen LAN passende) IP-Adresse für diese Zwecke "ausdenken".

Und wenn man tatsächlich "standalone" arbeiten will und nur PC und FRITZ!Box direkt miteinander verbindet, bleibt das Prinzip weiterhin dasselbe. Solange man den PC auf DHCP hat, kriegt der (früher oder später) von Windows eine APIPA-Adresse, wenn sich kein DHCP-Server findet - dann gibt man für die FRITZ!Box eben einfach eine dazu passende an. Die 169.254.1.1 ist DANN zwar tatsächlich so gut wie jede andere Adresse für die FRITZ!Box (solange die APIPA-Adresse nur eine 16er-Maske verwendet), aber sie ist eben "gefährlich", solange man sie in einem komplett verkabelten Netz verwendet - denn darauf reagiert dann JEDE FRITZ!Box (und jeder Repeater) in diesem Netz und es ist ein reines Glücksspiel, ob man die richtige "trifft".
 
Aha... Wenn mein Laptop aber eine APIPA-Adresse hat, weil er eben nicht im Heimnetz ist, dann muss ich ja die Box mit ihrer APIPA-Adresse ansprechen, ausser ich vergebe dem Laptop eine feste IP aus dem C-Netz ?...

Oder denke ich jetzt komplett verkehrt??!
 
Du mußt doch für diesen Fall nur ermitteln, WELCHE APIPA-Adresse Dein PC tatsächlich hat und dann kannst Du für die FRITZ!Box eine dazu passende verwenden (und zwar "intern" im Skript - der Benutzer muß davon gar nichts mitbekommen, außer Du protokollierst irgendetwas dazu in seine Richtung) - das wird üblicherweise auch NICHT die 169.254.1.1 sein, weil nur eine Chance von 1:256 besteht, daß APIPA für Dich die .1 im dritten Tupel auswürfelt. Die Box selbst hat nun mal (im Bootloader) auch keine "eigene" APIPA-Adresse - eine "Notfall-IP" von 169.254.1.1 wird erst über die ar7.cfg vom FRITZ!OS (aber halt auf jeder Box) gesetzt und hat mit dem Loader rein gar nichts zu tun.

Du kannst natürlich auch bei Deiner 169.254.1.1 BLEIBEN ... nur schränkt das (nach meiner Ansicht) das Skript (und damit seinen Nutzen) eben unnötig ein. Gerade dann, wenn es wirklich nur ein einziges Interface gibt, das tatsächlich "up" und "connected" ist (ggf. auch nur wg. passender Einstellungen zum MediaSense) und obendrein ggf. noch 802.3 als MediaType hat (wie schon mal geschrieben, kann man das auch über WiFi machen, wenn man nur einen passenden (anderen) AP hat, denn die (startende) FRITZ!Box ist halt noch nicht per WLAN erreichbar), ist es ja nun gar kein Problem, die "richtigen" IP-Adressen zu ermitteln und dann daraus die IP-Adresse für die Box abzuleiten. Vielleicht mußt Du Dich einfach mal von der Vorstellung lösen, daß die IP-Adresse hier tatsächlich eine "tragende" Rolle spielt - das tut sie üblicherweise eben nicht und die Box verwendet einfach die Adresse, die man ihr "aufträgt".

Die sendet die Pakete auch einfach wieder an die IP- und die MAC-Adresse zurück, von der die Anforderung kommt - etwas wie ARP wird von der Box selbst gar nicht verwendet, auch wenn die auf entsprechende Anfragen reagiert. Das kann man sich problemlos in einem Mitschnitt ansehen - allerdings vergleicht wohl auch der rudimentäre IP-Stack im Bootloader die Zieladresse. Wenn die nicht stimmt (was man z.B. mit einem falschen, statischen ARP-Eintrag testen/simulieren kann), gibt es auch keine Antwort.
 
Aber wenn mein Laptop eine APIPA-Adresse verwendet, kann ich vom Laptop aus nicht die FritzBox mit ihrer 192.168.178.1 im Standalone-Betrieb ansprechen, richtig?
 
Warum nicht? Wenn die Route der Pakete, die keine "lokale Zustellung" ermöglichen (was ja genau dann der Fall ist, wenn die IP-Segmente nicht zueinander passen), über den einzigen aktiven Netzwerk-Adapter führt, landen auch diese Pakete auf dem (einzigen) Kabel. Ich weiß aus dem Stand nicht, was Windows mit den Gateway-Einstellungen macht, wenn es eine APIPA-Adresse zuweist ... aber solange die Default-Route auch über dieses Interface geht, kommen die Pakete auch bei der FRITZ!Box vorbei. Du brauchst ja nur mal Dein Laptop an eine FRITZ!Box mit deaktiviertem DHCP-Server hängen ... wenn die Netzwerkkarte dann eine APIPA-Adresse hat, kannst Du (a) diese Konfiguration näher anschauen und (b) sogar mit einfachem Ping versuchen, die FRITZ!Box zu erreichen. Wobei dann wieder deren Konfiguration (solange sie sich nicht im Bootloader befindet) für die "Antworten" passen müßte - vielleicht testest Du das also tatsächlich besser gleich mit dem Bootloader der FRITZ!Box.
 
Danke erstmal, ich werde ein wenig testen ;)
 
Hallo, also nun klappt insgesamt der Flash-Vorgang sogar über Powerline und WLAN ;) .. ganz was wildes. Allerdings bekomme ich einen Fehler, egal ob direkt per LAN verbunden oder auf anderem Wege, sobald ich

Code:
EVA-FTP-Client.ps1 -Address 192.168.1.5 -Scriptblock { BootDeviceFromImage $bootableImage } -Verbose -Debug

aufrufe:

Code:
AUSFÜHRLICH: INFO: flashe Firmware...
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.3258 0x0 0x46409

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

200 GETENV command successful

================
DEBUG: Memory size found    : 0x20000000 (512 MB)
DEBUG: Memory size used     : 0x08000000 (128 MB)
DEBUG: Image size found     : 0x0219dc00
DEBUG: Set memory size to   : 0x05e62400
DEBUG: Set MTD RAM device to: 0x85e62400,0x88000000
DEBUG: Sent
SETENV memsize 0x05e62400
================
DEBUG: Response:
200 SETENV command successful

================
DEBUG: Sent
SETENV kernel_args_tmp mtdram1=0x85e62400,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
'C:\Users\Public\Downloads\FreetzTheBox\Images\7590_07.27.all_freetz-ng-18401-4abc33eda_20210610-074814.NAND_bootable.i
mage' to '0x85e62400 0x88000000' ...
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,1,5,12,16)

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

================
DEBUG: Sent
SETENV memsize 0x20000000
================
DEBUG: Response:
120 Service not ready, please wait

================
DEBUG: Sent
UNSETENV kernel_args_tmp
================
DEBUG: Response:
120 Service not ready, please wait

================
DEBUG: Sent
QUIT
================
DEBUG: Response:
120 Service not ready, please wait

================
Ausnahme beim Aufrufen von "Invoke" mit 0 Argument(en):  "Error uploading image file."
In C:\Users\Public\Downloads\FreetzTheBox\EVA-FTP-Client.ps1:638 Zeichen:21
+                     $ScriptBlock.Invoke()
+                     ~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : RuntimeException


Die Box startet danach neu und alles funktioniert so, wie es soll ... sogar mit dem "neuen" Image...
 
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.