[Gelöst] adam2 - "quote SETENV linux_fs_start 1" funktioniert nicht

jha4711

Neuer User
Mitglied seit
1 Feb 2020
Beiträge
140
Punkte für Reaktionen
43
Punkte
28
Update 23.6.22:
Einfache Lösung gefunden, siehe
Post #9 weiter unten ...
... oder noch wesentlich umfangreicher nach Tipps (
Post #10) von @PeterPawn: "Das gibt es (praktisch alles) auch in Form von Shell-Skripten (https://github.com/PeterPawn/YourFritz/blob/main/eva_tools/eva_switch_system)"

Hallo zusammen,

Hintergrund: nachdem meine gepatchte FRITZ!Box 6591 über Nacht einen automatischen Update auf die neueste Laborversion gemacht hat, komme ich mal wieder nicht per SSH auf diese Box und "müsste" sie jetzt erneut "patchen". Ich weiß, ich weiß - über Patches gehen die Meinungen auseinander - darum soll es daher auch gar nicht gehen. Mein Problem bezieht sich eher auf den Original vom Bootloader-Prozess kurzzeitig aktivierten "ADAM2 FTP Server" (EVA) der FRITZ!Box, der ja unabhängig vom Patch eigentlich immer funktionieren müsste.

Mein Problem: Normalerweise könnte ich jetzt ja die 2.Bootbank ganz einfach über adam2 und "quote SETENV linux_fs_start 1" aktivieren, denn ich weiß ja, dass die 2.Bootbank einen funktionierendes image enthält. ABER: Die Box will einfach nicht von dieser aktuell Backup Bootbank booten. Beim Reboot (sowohl über "quote REBOOT" - als auch über "Stromstecker ziehen" - beides ausprobiert) zeigt sie bei "quote GETENV linux_fs_start" wieder die Bootbank "0" an. Sprich wie der Titel dieses Posts sagt: "quote SETENV linux_fs_start" funktioniert bei dieser Box einfach nicht und ich müsste über einen Workaround gehen und die aktive Bootbank überschreiben - was aus eigener Erfahrung auch wunderbar funktioniert.

Trotzdem die Frage: Das Problem scheint nicht unbekannt, denn auch @fesc scheint das laut einer README-6591.md auf seinem Repository schon einmal beobachtet zu haben ...
- Under certain circumstances (i have not yet tried to figure out when/why exactly) the
bootbank switch does not seem to work. It is generally also OK to write to the ACTIVE partition
and not change linux_fs_start.
... geht dort aber nicht näher darauf ein, weil es für das Patchen einen Workaround gibt, direkt in die aktive Bootbank zu schreiben. Daher die Frage: Hat jemand hier im Forum eine schlüssige Erklärung für dieses Phänomen?

Vielen Dank für eure Zeit und euer Feedback



P.S.: Vielleicht habt Ihr auch Lust eine damit verbundene 2.Frage zu beantworten. Eine weitere Beobachtung im Zuge dieses Problems ist, dass bei meinem FTP Client (ftp auf der Commandline auf einem mac) die Ausgabe des adam2 der 6591 nicht zu den Eingaben passt. Auf ein SETENV gibt die Box dann das Ergebnis des GETENV aus. Das muss ja irgendwie mit dem FTP-Client und Puffern zu tun haben. Ich hänge mal eine Befehlsfolge an (bei "ftp>" habe ich dann nur RETURN gedrückt)...

Bash:
ftp> quote GETENV linux_fs_start
linux_fs_start        0
ftp> quote GETENV linux_fs_start
ftp>
ftp> quote GETENV linux_fs_start
200 GETENV command successful
ftp> quote GETENV linux_fs_start
linux_fs_start        0
ftp> quote SETENV linux_fs_start 1
ftp>
ftp> quote SETENV linux_fs_start 1
200 GETENV command successful
ftp>
ftp> quote SETENV linux_fs_start 1
linux_fs_start        0
ftp>
ftp> quote SETENV linux_fs_start 1
ftp>
ftp> quote SETENV linux_fs_start 1
200 GETENV command successful
ftp>
ftp> quote SETENV linux_fs_start 1
linux_fs_start        0
ftp>
ftp> quote SETENV linux_fs_start 1
ftp>
ftp> quote SETENV linux_fs_start 1
200 GETENV command successful
ftp>
ftp> quote SETENV linux_fs_start 1
linux_fs_start        0

Frage: Kennt jemand auch dieses Problem und hat eine schlüssige Erklärung? Oder muss ich auf einen anderen FTP-Client ausweichen bzw. gibt es ggf. Schalter (mit passive Mode, Binary Mode habe ich bereits ohne Erfolg "rumgespielt"), die mir noch nicht in den Sinn gekommen sind?

Update: Dank Feedback von @NDiIPP gibt es zu dieser Frage schon Antworten, z.B. hier



 
Zuletzt bearbeitet:
Frage: Kennt jemand auch dieses Problem und hat eine schlüssige Erklärung? Oder muss ich auf einen anderen FTP-Client ausweichen bzw. gibt es ggf. Schalter (mit passive Mode, Binary Mode habe ich bereits ohne Erfolg "rumgespielt"), die mir noch nicht in den Sinn gekommen sind?

Das ist doch das alte "Puffer-Problem", da gab es auch schon ein paar Beiträge zu:
https://www.ip-phone-forum.de/threads/debranding-der-fritz-box-6490-cable-kdg.307362/post-2378114

Wenn man dann bspw. mehrmals den gleichen Befehl hintereinander absetzt macht man damit das Problem nicht besser. Man muss sich dann einfach damit zufrieden geben, dass die Ausgabe bzw. Reaktion des Bootloader ggf. nicht mit den Erwartungen übereinstimmt, da zuerst noch ältere Zeilen aus dem Puffer angezeigt werden anstatt der aktuellen.
 
  • Like
Reaktionen: jha4711
Nein, gibt es auch bei Windows und auch bei Linux.
 
Wann tritt das auf? Liegt das an dem FTP-Client?
 
Wann tritt das auf? Liegt das an dem FTP-Client?
Im Post von @PeterPawn auf den @NDiIPP hier verwiesen hat steht es so ...
Das Durcheinander bei der FTP-Ausgabe entsteht mit ziemlicher Sicherheit deshalb, weil Du da irgendeinen FTP-Client benutzt, der mit den (nicht standardkonformen Multi-Line-)Antworten des FTP-Servers in EVA bei einem (erfolgreichen) GETENV nicht klarkommt und falsch "buffert".
... also JA - muss wohl am FTP-Client liegen, weil der FTP-Server der FRITZ!Box wohl solche "Multi-Line-Anworten" verschickt, mit denen nicht jeder FTP-Client umgehen kann.
 
OK dann habe ich wohl bisher Glück gehabt denn bei dem originalen FTP von Windows sowie beim SFTP von WinSCP hatte ich bisher keine Probleme.
 
Bildschirmfoto 2022-06-21 um 16.02.43.png

Ich habe jetzt einmal den Tipp mit dem Paketmonitor von @PeterPawn verfolgt: Die Antwort vom FTP-Server der FRITZ!Box auf ein "quote GETENV linux_fs_start" sind halt tatsächlich mehrere Zeilen (Zeilentrenner 0x0d 0x0a 0x0d 0x0a) und damit kann mein FTP-Client auf dem mac (mit den Standardeinstellungen jedenfalls) nicht umgehen und liefert nur bis zum ersten CR LF (0x0d 0x0a). Beim zweiten "quote GETENV linux_fs_start" liefert er dann das CR LF (also die leere Zeile) und erst beim dritten "quote GETENV linux_fs_start" kommt der Rest "200 GET ENV command successful" des eigentlich ersten "quote GETENV...".

Interessanter Exkurs ;-) - Dank für diese Hinweise!
Next steps: Vielleicht kann man/ich dem mac FTP-Client ja beibringen, damit umzugehen....habe aber noch nichts gefunden.

Es gibt zwar den "cr" Befehl, aber da der Mac einen anderen Zeilentrenner (nur CR / 0x0d) zu verwenden scheint, klappt das irgendwie auch leider nicht ...

ftp> cr
Carriage Return stripping off.
ftp> cr
Carriage Return stripping on.

Update: Und nachvollziehbar ist mit dem Paketmonitor eben auch, dass ein "quote SETENV .." direkt nach einem "quote GETENV ..." tatsächlich den Server veranlasst, das SETENV durchzuführen, man sieht im Paketmonitor den "200 SETENV command successful" ... aber vom FTP-Client wird das halt "noch" nicht angezeigt - eben wegen dieses "Pufferproblems". Folglich könnte man die Sequenz ...
Code:
ftp [email protected]
Connected to 192.168.178.1.
220 ADAM2 FTP Server ready
331 Password required for adam2
Password:
230 User adam2 successfully logged in
ftp> quote GETENV linux_fs_start
linux_fs_start        0
ftp> quote SETENV linux_fs_start 1

ftp> quote REBOOT
200 GETENV command successful
ftp> quote REBOOT
200 SETENV command successful
ftp> quote REBOOT
221 Thank you for using the FTP service on ADAM2
ftp> quote REBOOT
221 Goodbye.
ftp> quote REBOOT
421 Service not available, remote server has closed connection
....
zum Umstellen der Boot-Bank auch auf so einem Client machen - muss halt die Ausgabe "ignorieren" und den "quote REBOOT" wiederholen, bis die Box tatsächlich bootet..... wenn da bei mir nicht noch das erste Problem wäre ;):rolleyes::mad:
 
Zuletzt bearbeitet:
"Kaum macht man's richtig, schon funktioniert's" ....

Lösung gefunden, "mein" Problem ist damit gelöst, Danke für eure Mithilfe!

Also mithilfe und dank der Tipps zum "FTP Puffer-Problem" habe ich eine für mich akzeptable (und für andere Apple mac User ggf. ebenso interessante) Lösung zu den beiden o.g. Problemen gefunden, weil ich eben nicht auf einen anderen FTP-Client (linux, windows) zurückgreifen konnte bzw. wollte.

Kurzfassung: Bei Problemen mit dem "quote SETENV ..." im FTP-Client "einfach" mal das "nc" Kommando (netcat) - und zwar ohne dem "quote" - ausprobieren.

--> Damit hat - zumindest bei mir auf einer FRITZ!Box 6591 mit "BIOS CGM2.86C.627075.R.1910091149 10/09/2019" - dann auch ein "SETENV linux_fs_start <n>" gekappt und ich konnte anschließend wieder via "ssh" auf die vor dem automatischen Update laufende (in meinem Fall modifizierte) Firmware zugreifen :D:D:D

Langfassung:
  • mac per Netzwerkkabel mit Port 1 der FRITZ!Box verbinden
  • mac Ethernetanschluss auf statische IP-Adresse 192.168.178.n (1 < n < 255) einstellen
    • Ergänzung/Nachtrag/Tipp 14.1.23: Und noch ein Tipp, der für Profis "selbstverständlich", für andere aber ggf. hilfreich sein kann....
      • Angenommen der Mac hat aktuell im LAN eine IP-Adresse aus einem anderen Netz als die 192.168.178.0/24 und man will während der Aktion nicht auf diese "Standard" IP-Adresse verzichten, kann man sich über sogenannte "Alias" IP-Adressen helfen.
        Man muss also nicht die reguläre IP-Adresse durch eine 192.168.178.x Adresse ersetzen, sondern man erstellt sich eine zusätzliche "Alias" Adresse im 192.168.178er Subnetz um "nur" für diese Aktion (z.B. Bootbank-Switch) mit der FRITZ!Box zu kommunizieren
        Code:
        Anlegen eines Alias:
        sudo ifconfig <interface> alias 192.168.178.<xyz> 255.255.255.0  (1 < xyz < 255, interface i.d.R "en0")
        z.B. 
        sudo ifconfig en0 alias 192.168.178.2 255.255.255.0
        Jetzt kann man sowohl mit der FRITZ!Box im adam2-Modus (192.168.178.1) als auch mit allen anderen Geräten im LAN (und Internet) arbeiten. Natürlich nur, wenn die aktuell im adam2-Modus befindliche FRITZ!Box nicht der Default-Router ist ;)
        Nach der Aktion entfernt man den Alias einfach wieder via
        Code:
        Löschen des Alias:
        sudo ifconfig <interface> -alias 192.168.178.<xyz>
        i.B. 
        sudo ifconfig en0 -alias 192.168.178.2
  • Stromkabel der FRITZ!Box ziehen und wieder einstecken (ein Reboot aktivierte bei meiner FRITZ!Box den EVA jedenfalls nicht)
  • nach ca. 10 sek. und in einem Fenster von ca. 5 sek. (nur solange ist der EVA aktiv) den Befehl "nc 192.168.178.1 21" absetzen (Tipp: im 2.Fenster ein PING auf die 192.168.178.1 - den "nc" Befehl erst absetzen, sobald das PING von der FRITZ!Box beantwortet wird)
  • user adam2
  • pass adam2
  • GETENV linux_fs_start
  • SETENV linux_fs_start n (n = 0 oder 1)
  • REBOOT

voila

Logfile von einer meiner Sitzungen:
Bash:
nc 192.168.178.1 21
220 ADAM2 FTP Server ready
user adam2
331 Password required for adam2
pass adam2
230 User adam2 successfully logged in
GETENV linux_fs_start
linux_fs_start        0
 
200 GETENV command successful
SETENV linux_fs_start 1
200 SETENV command successful
REBOOT
221 Thank you for using the FTP service on ADAM2
221 Goodbye.

und anschließend die Bestätigung durch Blick auf die Aktive Bootbank via ssh (noch) über die Notfall IP-Adresse der FRITZ!Box ...

Bash:
ssh [email protected]
Warning: Permanently added '169.254.1.1' (RSA) to the list of known hosts.
 
 
BusyBox v1.29.3 () built-in shell (ash)
 
ermittle die aktuelle TTY
tty is "/dev/pts/1"
disable start/stop characters and flowcontrol
# switch_bootbank
SELECTED boot bank        1
RUNNING firmware version: 07.39 LabBETA 97061  [/dev/mmcblk0p9]  modified 30 75c8caf 06/08/22,23:36
BACKUP firmware version: 07.39 LabBETA 97333  [/dev/mmcblk0p3] 
 
Execute the following command to flip boot bank and reboot:
 
/bin/aicmd pumaglued uimg switchandreboot
#

Der Switch auf Bank 1 hat also geklappt, die modifizierte Firmware "07.39 LabBETA 97061" wurde aktiviert und die eigentlich "ungewollt" durch den in der Nacht automatisch installierten Update installierte Original Firmware "07.39 LabBETA 97333" könnte jetzt wieder via "ssh" und "scp" mit einer modifizierten Version überschrieben werden.
 
Zuletzt bearbeitet:
Das gibt es (praktisch alles) auch in Form von Shell-Skripten (https://github.com/PeterPawn/YourFritz/blob/main/eva_tools/eva_switch_system) und die sollten (m.W., ansonsten hätte ich gerne mal ein Protokoll, woran es am Ende scheitern soll) auch unter MacOS funktionieren, wenn man die notwendigen Dateien per Homebrew installiert hat (https://formulae.brew.sh/formula/git + https://formulae.brew.sh/formula/socat - ggf. auch noch ein netcat oder eine bash, das hängt halt davon ab, was auf dem System schon existiert) und das Repository auf das lokale System geklont hat.

Gut - MacOS ist bekanntlich ein (Net-)BSD-Derivat und kein Linux ... aber so "ganz im Regen" werden auch MacOS-Nutzer nicht stehen gelassen. Da fehlt(e) wohl nur die entsprechende Information (ich glaube, man nennt das "missing link") ... das sollte anderen - von diesem Problem - Betroffenen nicht so ergehen, wenn sie ihrerseits ein wenig suchen (und ohne so eine Suche, werden sie auch diesen Thread hier ja nicht finden).

Aber auch das "buffer problem" bei "normalen" FTP-Clients mit (korrekter) Behandlung von "multi-line responses" wurde hier ja (erneut) untersucht (und glücklicherweise wohl auch genau so bestätigt) ... dem Vorteil der "eigenen Anschauung" steht dann halt der Nachteil gegenüber, daß wohl mehr Zeit bis zur Lösung aufgebracht werden mußte. Ich will ja nur dem Eindruck entgegen treten, daß man sich diese Informationen unbedingt selbst erarbeiten MUSSTE und sie nicht auch durch eine (qualifizierte) Suche hätte finden können (und sicherlich noch so manches andere, was in diesem Zusammenhang von Bedeutung sein könnte) - ob der Zeitaufwand dafür dann geringer gewesen wäre, als wenn man das alles selbst herausfindet, hängt sicherlich auch davon ab, mit welchem Kenntnisstand man seine Recherche oder die eigenen Versuche beginnt.

EDIT:
Ich habe mal ein (nur wenig abgewandeltes) Shell-Skript eingecheckt (https://github.com/PeterPawn/YourFritz/blob/main/eva_tools/eva_switch_system_no_discovery), was die Umschaltung auch ohne vorherigen (internen) Aufruf von eva_discover ausführen kann. Dann muß man zwar immer noch selbst dafür sorgen, daß die Box irgendwie passend angehalten wird, aber das kann man dann auch noch nach einem Schreiben mit eva_store_tffs (o.ä., was kein System aus dem RAM startet) verwenden, obwohl auch die (wiederholte) Verwendung von eva_discover NICHTS schadet, wenn die Box bereits im Bootloader angehalten wurde - dann antwortet sie auf das erste UDP-Broadcast-Paket und das "discover" (im Sinne von "aufspüren") ist sofort wieder beendet. Der Vorteil bei der Verwendung ohne "Discovery" ist, daß man dann auch kein socat braucht - das ist nur für das Aussenden von Broadcast-Paketen erforderlich.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: jha4711
das hängt halt davon ab, was auf dem System schon existiert .... und das Repository auf das lokale System geklont hat.
YEP - genau dieser Aspekt war in meinem Fall wohl der springende Punkt!

Ich wollte in dem Moment halt mit einem "Vanilla" mac ganz schnell und unkompliziert die Bootbank switchen - OHNE irgendetwas anderes zu installieren, ohne lange zu recherchieren wo ich z.B. Dein Repo finde etc. Und ich wusste noch, dass ich doch "nur" ein "SETENV linux_fs_start <x>" an den adam2 absetzen muss.
Und da das in meinem Fall mit FTP nicht gegangen ist, habe ich "mir persönlich" halt die Alternative Lösung über das nc "erarbeitet".

Du kannst Dir sicher sein, dass ich mir beim nächsten "Problem" Deine Tools besser anschauen werde. Irgendwie hatten mich die ".cs" Kürzel abgeschreckt und ich dachte das seien nur Windows Tools (und das kommt davon, wenn man sich die Zeit nicht nimmt und nicht richtig liest - ein grundsätzliches Problem von mir)

Dein Script ...

Code:
./eva_switch_system
Calling: ./eva_switch_system <interface> <requested ip address of the box> <own ip address to use>

werde ich das nächste mal bestimmt ausprobieren - aber jetzt ist die Box halt wieder im Keller verbaut ;).

Und die Tatsache, dass Du vor 40 Min. einen neuen git-commit

commit ce04c8570956a21b36205d45f7d1a2140b329f30 (HEAD -> main, origin/main, origin/HEAD)
Author: YourFritz <[email protected]>
Date: Thu Jun 23 10:05:21 2022 +0200

eva_tools: add a variant of 'eva_switch_system', which doesn't rely on discovery

gemacht hast lässt mich ein bisschen hoffen, dass mein Problem-Thread Dich dazu ein wenig animiert hat.

Prinzipiell hast Du natürlich völlig recht, dass es viele Wege nach Rom gibt und die Recherche und der Versuch über die Installation von Tools wie Deinen (wobei man aber eben nicht unbedingt ein homebrew auf seinen mac haben will bzw. hat) hätte mich auch zum eigentlichen Ziel "Switch Bootbank" geführt .... evtl. sogar schneller und leichter .... Räder doppelt erfinden zu wollen, ist ja wirklich nicht die beste Wahl.

Aber noch einmal: Für jetzt und die Zukunft weiss ich nach diesem Exkurs, wie ich den Bootbank-Switch "ganz einfach" mit einer 6591, einem Netzwerkkabel und jedem beliebigen Mac hinbekomme - ganz ohne eine andere, zusätzliche Softwareinstallation bzw. Konfiguration. Und das ist für mich persönlich ein wichtiger Erfolg - auch wenn Du mit allem was Du schreibst Recht hast!

Daher 1.000 Dank für die absolut gerechtfertigte Betrachtung aus einem anderen Blickwinkel. Deine Beiträge sind sowieso immer eine extrem wertvolle Bereicherung, auch dafür vielen Dank!

Den initial Post werde ich noch einmal überarbeiten, dass andere Leser die ggf. zuerst hier landen, sofort auch auf Deine Tools hingewiesen werden!
 
  • Like
Reaktionen: PeterPawn
… habe ich "mir persönlich" halt die Alternative Lösung über das nc "erarbeitet".

BTW:
Ich bevorzuge ja schon seit Jahren die "netcat-Variante" (anstatt der "ftp-Variante"), aus verschiedenen Gründen (zwar beim anmelden etwas mehr Tipparbeit (USER + PASS) aber man spart sich dann eben das "quote" bei den Befehlen und umgeht eben auch die Multiline-Problematik, was mich ursprünglich wohl ebenfalls primär dazu brachte nc zu verwenden. Aber das sorgt hier im Forum mitunter auch mal für Irritationen, so wie bspw. >hier<. ;)
 
  • Like
Reaktionen: jha4711
und die sollten (m.W., ansonsten hätte ich gerne mal ein Protokoll, woran es am Ende scheitern soll) auch unter MacOS funktionieren,

Nachdem meine "Spiel" - FRITZ!Box 6591 Cable heute Nacht schon wieder ein automatisches Update (Laborversion: 97646) installiert hat und danach schon wieder nicht per ssh erreichbar war (meine Schuld, wenn ich "Depp" auch jedes mal vergesse, das autom. Update zu deaktivieren), musste ich also erneut die Bootbank wechseln. Mit dem "nc" Befehl (netcat - eine mögliche Lösung des hier im Thread ursprünglich geschilderten Problems) hat das jetzt auch wunderbar in kürzester Zeit geklappt und ich kam wieder per ssh auf die Box ...

ABER

... ich denke, ich "schulde" @PeterPawn noch mind. ein Protokoll vom Versuch das ganze auch mal mit seinen eva_tools auszuprobieren. Also "here we go" mit Protokollen von diesem Versuch auf einem Apple mac unter macOS Catalina - 10.15.7 mit bereits installiertem "homebrew" Version 3.5.3 ...

Erster Schritt - nach einem "git clone https://github.com/PeterPawn/YourFritz.git" - cd YourFritz/eva_tools einfach mal ./eva_discover aufrufen und schauen, was passiert ...

Code:
eva_tools % ./eva_discover
YourFritz Shell Script Library: [W] Missing 'ip' utility, it's needed by one or more imported functions.
YourFritz Shell Script Library: [W] Missing 'md5sum' utility, it's needed by one or more imported functions.
YourFritz Shell Script Library: [W] Missing 'realpath' utility, it's needed by one or more imported functions.
./eva_discover: line 282: [: /Applications/VMware: binary operator expected
"socat" utility couldn't be found or isn't executable.

Was auch immer der mac hier mit den /Applications/VMware ... zu tun haben will, liegt irgendwie daran, dass "socat" noch nicht installiert ist .... also ignorieren und weiter ...

... Fakt ist, dass die Tools 'ip', 'md5sum' und 'realpath' fehlen. Installieren wir die mit homebrew (md5sum ist bei den coreutils dabei - siehe Bemerkung unten)

Code:
brew install iproute2mac
brew install coreutils

Bemerkung Anfang .....
"Natürlich" hatte ich der Reihenfolge der Ausgabe entsprechend nach dem "brew install iprout2mac" ein "brew install md5sha1sum" gemacht, was auch geklappt hatte. Allerdings hat dann das dritte "brew install coreutils" einen Hinweis gebracht ...

Code:
brew install coreutils
Please `brew unlink md5sha1sum` before continuing.

.. gesagt getan ...

Code:
brew unlink md5sha1sum
Unlinking /usr/local/Cellar/md5sha1sum/0.9.5_1... 3 symlinks removed.

und dann erst das

Code:
brew install coreutils

... Bemerkung Ende.

ok, egal wie - jetzt kennt auch mein System die drei vorher "missing" commands.... also neuer Versuch - sieht schon besser aus ....

Code:
eva_tools % ./eva_discover
Please specify the network interface name with 'INTERFACE=<name>' parameter.
Please specify the IP address of this computer with 'FROM=<ipv4>' parameter.
Please specify the IP address to assign to the FRITZ!Box device with 'TO=<ipv4>' parameter.

Blick in das script .... default_interface=eth0 ist typisch linux - auf dem mac heißt "mein" Interface aber "en0" - also nächster Versuch ...

Code:
eva_tools % ./eva_discover INTERFACE=en0
sed: /proc/mounts: No such file or directory
The value 'en0' specified for 'INTERFACE' is invalid.

Versuch über "eva_switch_system", was ja "eva_discover" aufruft liefert quasi das gleiche Ergebnis ...

Code:
eva_tools % ./eva_switch_system
Calling: ./eva_switch_system <interface> <requested ip address of the box> <own ip address to use>

Also alle Parameter angegeben ....
Code:
eva_tools % ./eva_switch_system en0 192.168.178.1 192.168.178.123
sed: /proc/mounts: No such file or directory
The value 'en0' specified for 'INTERFACE' is invalid.

... jetzt höre ich auf - bitte nicht übel nehmen. Schließlich klappt der BootBank - Switch auf dem mac über den netcat (nc) wunderbar.

Anbieten könnte ich lediglich, beim nächsten Labor Update über einen mac noch etwas oder modifizierte Scripts aus dem git-Repository ausprobieren zu können. Bei Interesse dann gerne hier als Kommentar hinterlassen - vielleicht denk ich dann dran.
"Tschüss und schönen Gruß"
 
heute Nacht schon wieder ein automatisches Update (Laborversion: 97646) installiert hat und danach schon wieder nicht per ssh erreichbar war
Deshalb mache ich immer den Key1+2 in der FW weg (oder ersetze ihn durch meinen eigenen) dann kann die nie selbst ein Update machen.
 
  • Like
Reaktionen: jha4711
Ich wollte nur mal eben Danke sagen!

@jha4711 @PeterPawn

Ich bin beim googlen auf diesen Thread gestoßen. Auf Grund eurer Expertise konnte ich meine beiden Fritz Repeater 2400 auf den alten Softwarestand zurückversetzen. Das letzte Update 7.50 von AVM hat mein Mesh instabil gemacht. Eine recovery-Version der alten Software gibt es bei AVM nicht und war auch sonst nirgends aufzutreiben. Mit meinem MacBook und euren netcat Befehlen bewaffnet konnte ich auf beiden Repeatern die zweite Bootbank aktivieren und auf die dort vorhandene Software 7.29 zurückkehren.
Mein Mesh ist jetzt wieder stabil.

schönes Wochenende!
 
  • Like
Reaktionen: PeterPawn und jha4711
Eine recovery-Version der alten Software gibt es bei AVM nicht und war auch sonst nirgends aufzutreiben.
Eine Anlaufstelle wäre hier im Board zu finden (für die Zukunkt ;))

 
  • Like
Reaktionen: buzz-dee
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.