ADAM2 auf anderer IP? (FB7390)

mMn wegschmeißen und eine andere FB nehmen.

Damit man das aber nicht falsch versteht. Ich bin auch im Repaircafe tätig. Und wir versuchen alles mögliche noch "am Leben" zu erhalten um Elektroschrott zu vermeiden. Aber man muss auch einen Schlussstrich ziehen können wo es einfach nicht mehr geht oder lohnt.
tja, schade. Ich habe halt noch die Hoffnung, dass es nur an einer verkorksten Einstellung eines Urlader-Parameters liegt. Gäb's dafür Kandidaten, die solch ein Verhalten hervorrufen könnten?
Ich konnte es auch noch mit alteren Firmware-Versionen versuchen; geht ja schnell. Habe das Recovery von 06.23 über Archive.org noch runterladen können; gleiches Ergebnis. Sind irgendwo noch ältere Firmware Dateien/Recoveries runterladbar?
Ein "Diagnose-Image" oder "Minimal-Image" von AVM gibt's nicht? Und alternative Firmware wie OpenWRT existiert für die 7390 auch nicht?
 
Das Skript braucht offenbar explizit die bash.
Es ist ja auch nicht so, daß das nicht explizit so beschrieben wäre:
Wer nicht weiß, wie er an die beschriebenen Skript-Dateien kommen soll und/oder was ggf. noch passieren muß, damit diese Dateien zur eigenen Linux-Installation passen, kann am Beginn dieses Threads nachlesen.
... und "dieser Thread" führt dann nach: https://www.ip-phone-forum.de/threa...ischalten-geht-auch-für-7560-und-7590.296678/, wo dann von mir explizit festgehalten wurde:
Was brauchen wir dafür?

  • ein Linux-System mit einer halbwegs sinnvollen Shell - die "dash" ist hier eher ungeeignet, besser nimmt man eine "bash" oder - auf Systemen mit einer BusyBox - auch die "ash" aus deren Angebot (wobei prinzipiell auch die "dash" natürlich reichen würde, aber als interaktive Shell ist sie "unterentwickelt")
Es ist ja auch nicht so, daß das jetzt hier von Dir (@regex2) zum allerersten Male "bemerkt" wurde - es gibt MEHRERE Threads, wo genau dieses Thema "Wie sollte der SheBang bei den Skript-Dateien im YourFritz-Repository aussehen bzw. warum sieht er so aus (ist ein "shebang" eigentlich trotzdem ein "er" oder eher eine "sie"?), wie er/sie/es aussieht?" auch schon ventiliert wurde und praktisch JEDER Thread, der eine Beschreibung/Verwendung der Shell-Skripte in "eva_tools" (oder auch in "signimage", etc.) beinhaltete, enthält früher oder später auch wieder einen Beitrag bzw. eine Frage, WARUM ich das denn nicht anders machen würde.

Mit
Aus Kompatibilitätsgründen wäre es daher wohl besser, wenn es #! /bin/bash enthielte.
ist das nun auch hier der Fall ... so weit, so gut.

Zwar kann man das durch die explizite Angabe des Shell-Interpreters auch ohne Änderungen am Skript aufrufen, aber auch die (durch nichts bewiesene) Annahme, daß /bin/sh unbedingt eine dash-Shell wäre, ist wohl nur durch die rosarote Brille mit dem Blick auf die eigene Distribution "zu rechtfertigen". Das hat auch mit "modern" oder "nicht modern" überhaupt nichts zu tun ... wer weiß, daß seine eigene Distribution "KDE neon" im Kern auf Ubuntu basiert, der sollte auch in der Lage sein, entsprechende Kommentare (in den hier existierenden Beiträgen, die man ja spätestens beim Auftreten von Fehlern beim eigenen Aufruf über eine Suchmaschine findet, wenn man mit der Fehlernachricht und dem Skript-Namen auf die Suche geht) zu Unterschieden zwischen verschiedenen "Linien" in den Linux-Distributionen richtig zu interpretieren.

Die Tatsache, daß andere Distros (u.a. auch das von mir persönlich verwendete openSUSE) schon deutlich "älter" sind als Ubuntu (erstes Erscheinen: Slackware 1993, SuSE 1994, Ubuntu 2004 - siehe https://de.wikipedia.org/wiki/Liste_von_Linux-Distributionen), sagt am Ende in Wirklichkeit nur etwas über die Erfahrungen (und die Dauer der Nutzung) derjenigen, die solche Distributionen zusammenstellen und benutzen - mit "modern" hat das praktisch gar nichts zu tun. Aber auch das sollte sich (für den meisten jedenfalls) von selbst verstehen.

Was sage ich also zu dem oben zitierten Satz? Das darfst Du ja gerne so sehen und es ist Dir unbenommen, das Repo zu klonen und darin dann die vorgeschlagene Änderung vorzunehmen. Bei mir wird das dennoch nicht passieren - die Gründe dafür (ash auf "embedded devices", wo es auch nur r/o-Dateisysteme gibt und KEINE Symlinks für /bin/bash oder /bin/dash oder /bin/ash usw. und wo es u.U. nicht mal den passenden Editor gibt, um das dann noch entsprechend anzupassen - was auf einem "Desktop-Linux" nun wirklich kein Problem sein sollte - dabei habe ich den "POSIX-Mode" der bash, der beim Aufruf als /bin/sh automatisch verwendet wird, noch gar nicht erwähnt: https://www.gnu.org/software/bash/manual/html_node/Bash-POSIX-Mode.html und auch das macht natürlich noch einen Unterschied) habe ich mehr als einmal ausführlich dargelegt und praktisch JEDER (relevante) Thread zur Benutzung dieser Dateien enthält auch den Hinweis bzgl. der benötigten Shell - jetzt ja auch dieser hier wieder.

Wer also VOR der Benutzung der Skript-Dateien etwas genauer liest oder das spätestens dann nachholt, wenn beim ihm ein Fehler auftritt, der sollte das üblicherweise auch finden ... und selbst wenn ihm/ihr das nicht gelingen sollte, wären immer noch die (nicht von mir erdachten) Hinweise zu berücksichtigen, wie man Fehler (auch wenn es nur "vermeintliche" sein sollten) am besten meldet: https://www.chiark.greenend.org.uk/~sgtatham/bugs-de.html (oder wenn man es lieber in Englisch mag: https://www.chiark.greenend.org.uk/~sgtatham/bugs.html).

Wenn die eigene Umgebung zur Benutzung die falsche ist, dann mag die eigene Erklärung:
Das Script ist zwar auf einem aktuellen Linux etwas buggy (steigt beim Parsen der Parameter für HOLD= oder BLIP= aus sowie bei der Auswertung der Antwort der Fritzbox)
aus dem eigenen Blickwinkel "passen", aber sie zeigt eben auch, daß man sich ein paar grundlegende Fragen (u.a. auch die, warum es andere dann überhaupt benutzen) gar nicht erst gestellt hat (oder auch diese mit eher "komischen" Antworten beiseite schob), BEVOR man diese Erklärung (die ja auch irgendwie "ausschließt", daß man selbst das Problem sein könnte) in die Welt gesetzt hat.

EDIT: Wer will, kann auch mein "modern" durch das tatsächlich verwendete "aktuell" ersetzen - das macht es dann noch weniger plausibel, weil natürlich ein durch Updates auf dem laufenden Stand gehaltenes System (bei mir ist es auch noch ein "openSUSE Tumbleweed" - also ein System mit rollendem Release) auch "aktuell" ist.
 
Zuletzt bearbeitet:
Außer der konfigurierten IP (im Werks-Fall 192.168.178.1, ansonsten je nach Art der Anbindung oder Konfiguration eine andere) gibt's noch die fest verdrahtete Notfall-IP 169.254.1.1. Diese gibt's bei allen FritzBoxen (evtl. inkl. AVM-Repeater), also muß der Rechner alleine und direkt mit der betreffenden FritzBox verbunden sein, wenn es mehrere AVM-Geräte im Netzwerk gibt.
Ggfs. muß der Rechner eine feste IP aus diesem Adreßbereich (169.254.1.2 aufwärts) haben (nicht meckern, nur informieren wenn ich hiermit falsch liege).

Ob diese Notfall-IP auch im Bootloader angesprochen werden kann weiß ich nicht. Bislang ist mir keine FritzBox untergekommen, die gar nicht mehr wollte.
 
Diese Aussage bezieht sich aber auf eine Fritzbox, auf der FritzOS bereits läuft, oder? Meine (funktionierende) Fritzbox hat übrigens auch auf 192.168.179.1 ein (ihr) Webinterface.
 
Ja, @H'Sishi hat hier wohl 2 verschiedene Dinge (Bootloader vs laufendes FRITZ!OS) verwechselt. Mit deinem Problem hat die "Notfall-IP" jedenfalls nichts zu tun.

---

... und mit dash tritt das Problem auf.
Ach so, hatte beinahe schon was "schlimmeres" vermutet. Hättest du gleich erwähnt, dass du eine Debian basierte Distribution verwendest, hätte man gleich/sofort erahnen können, dass man hier wieder mal "nur" über die dash-Problematik gestolpert ist…
 
Ah, das wußte ich bislang nicht, dass die Not-IP erst nach dem Hochfahren aktiv ist. Ich dachte an diese IP, damit @regex2 evtl. über diese IP die Box beim Hochfahren einfangen kann.

@regex2: Ich hab noch ältere Recoveries als 6.23:
- 5.05, 5.21, 5.22, 5.50, 5.51 (int.), 5.52, 5.53
- 6.00, 6.01, 6.03, 6.06 (int.), 6.20
Die älteste ist die 4.91 als Image-Datei.
 
Könnte ich von welche bekommen zum Ausprobieren? Am liebsten natürlich eher ältere.
(PS: PM funktioniert übrigens nicht; ich vermute es liegt an dem ' im Nutzernamen, der ja in die URL eingebaut wird)
 
Mh, das hab ich schonmal gehört, daß ne PM nicht gehen soll. Vielleicht kann hier ein Admin erklären was los ist oder Abhilfe schaffen.
 
Es wird die URL https://www.ip-phone-forum.de/conversations/add?to=H'Sishi aufgerufen. Diese ergibt 403 Forbidden
You don't have permission to access this resource.
Ich vermute stark, dass es mit dem ' aka %27 zusammenhängt, also vermutlich eine Folge des internen Parsings der URL, vielleicht ein Nebeneffekt eines mißglückten XSS-Schutzes oder ähnliches. Jedenfalls ein Bug in der Forensoftware scheint mir. Sie kann hier nicht mit Namen, die ' enthalten, umgehen.
 
Ich hab ne Konversation gestartet; vielleicht geht Antworten ohne Probleme.
 
Könnte ich von welche bekommen zum Ausprobieren?
Die erhält man doch schon hier:
Siehe dort das "Update #5", da stehen bereits ältere Recovery-Tools für die 7390 zur Verfügung, und zwar zum "selbstdownload" ganz ohne erst eine Anfrage erstellen zu müssen…



Mh, das hab ich schonmal gehört, daß ne PM nicht gehen soll.
-> https://www.ip-phone-forum.de/threa...-forensoftware-useability.308383/post-2458097

Leider wurde darauf bisher nicht reagiert (hatte den Beitrag damals auch schon selbst gemeldet).

Eine Notlösung bzw. Workaround wäre, wenn User mit Apostroph diesen (vorübergehend, bis das Problem gelöst ist) aus ihrem Username entfernen.



Edit:
Ah, das wußte ich bislang nicht, dass die Not-IP erst nach dem Hochfahren aktiv ist.
Eine "Notfall-IP" braucht der Bootloader nicht, da dieser per Broadcast eine passende IP zugewiesen bekommen kann. Daher gibt es diese "feste" Notfall-IP erst für das laufende FRITZ!OS.



Edit 23.06.2024: Link zum Thema "Suche Firmware & Recover-Images" korrigiert
 
Zuletzt bearbeitet:
Oder die Konversation geht von mir aus - das Antworten klappt dann.

Oh, den Teil mit den 'Recoveries zum Selbst-Download' kannte ich auch noch nicht.
 
Danke; leider scheinen für die 7390 nur 06.XX-Images vorhanden zu sein, nichts älteres mehr.
 
Würde mich jetzt durchaus mal interessieren (wir sind ja hier nicht im Firmware Suchthread wo Begründungen nicht erwünscht sind), was man mit einem solch alten Recovery-Tool (Ver. <6.03) erreichen möchte. Solch alte FRITZ!OS Versionen beinhalteten u.a. auch noch den (sehr kritischen) webcm-Bug was imo auch der Grund ist, das solch alte Firmware-Versionen in der im Update #5 (Firmware-Suchthema) genannten Quelle nicht vorzufinden sind.
 
Auch die 04.XX, die ich freundlicherweise nun bekommen habe, zeigt leider dasselbe Verhalten (Reset nach Boot).
Vielleicht ist es ja so ähnlich wie bei dem Bootlog, das hier aufgelistet ist?
 
Ich hätte das Environment über den Bootloader ausgelesen um zu schauen, ob das (noch) plausibel ist. Auf Basis dieses Environment baut ja das Recovery-Tool ein neues TFFS-Image zusammen. Ansonsten wird man wohl kaum ohne serielle Konsole weiterkommen um zu schauen wo der Fehler liegt. Oder alternativ baut man verschiedene Dinge aus dem Image aus (angefangen mit dem ISDN und POTS Telefonieteil basierend auf dem FPGA) um zu schauen, ob sie damit dann noch startet/funktioniert.

Uralte Firmware-Versionen werden wohl kaum an einem evtl. vorh. Defekt etwas ändern können. Einzige Ausnahme sind da lediglich FRITZ!OS-Versionen <6.50 wo defekte Ethernet-PHYs noch akzeptiert werden (wobei ich gar nicht weiß, ob das auf die 7390 überhaupt zutrifft) aber da hätte bspw. schon ein FRITZ!OS 6.30 zum testen genügt.
 
war ja nur ein einfacher Versuch mit begrenztem Aufwand. Ich habe die mir bekannten Environment-Variablen ausgelesen; alle waren plausibel. Gibt es eine Möglichkeit, alle Variablen aufzulisten? Wie baut man Funktionalitäten aus dem Image raus? Filesystem decodieren, darin rumfuhrwerken und wieder zusammenpacken? Also so ähnlich wie Freetz? Wenn die Funktionalitäten als Kernelmodule drin sind, statt direkt hart in den Kernel einkompiliert zu sein, könnte das ggfs. sogar machbar sein.
 
Ich hab Regex2 das älteste was ich für die 7390 habe zukommen lassen, mit der Intention "Wenn diese Version funktioniert, geht's weiter aufwärts, bis eine Version nicht mehr akzeptiert wird" und dann eingrenzen zu können, welche neue(n) Funktion(en) dann wegen möglichem Defekt die Box blockieren.
Aber wenn schon eine 4.91 nicht akzeptiert wird ...
 
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.