PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,256
- Punkte für Reaktionen
- 1,747
- Punkte
- 113
Ich muß meine Aussage in #33 dahingehend korrigieren, daß die 3490 sehr wohl den telefon-Daemon verwendet (in Kombination mit dem voipd) und die Möglichkeit der IP-Telefonie bietet ... auch wenn das Handbuch das (Stand heute) Wort Telefon im Zusammenhang mit irgendwelchen Fähigkeiten der 3490 nicht enthält (7 Vorkommen von "telefon", keines mit VoIP-Bezug). Ich bin erst auf die Idee einer Suche in der AVM-KB gekommen, als ich in den Support-Daten einer 3490 den telefon-Daemon in der Prozessliste gesehen habe.
Damit sollte natürlich auch dort die Aktivierung des Telnet-Daemons per 'telefon'-Daemon (noch) funktionieren, wenn denn die Randbedingungen erfüllt sind. Die direkte Verarbeitung der Tastencodes funktioniert meines Wissens von einem IP-Telefon aus generell nicht, die Methode über den Eintrag im Telefonbuch und die Wählhilfe wird (vermutlich) ebenfalls nicht funktionieren, denn die Wählhilfe setzt auch ein "nicht-IP-Telefon" voraus.
Bleibt also noch die Möglichkeit der Aktivierung über die Änderung der fx_conf (oder auch hier und hier) in einer Export-Datei (das kann natürlich auch eine aus einer anderen Box exportierte Datei wie in #30 sein) oder über ein Pseudo-Image, wenn man den anstehenden Restart durch "firmwarecfg" abbricht (die PID des zu beendenden Prozesses steht in der Datei /var/run/delayed_reboot.pid) und anschließend die ganzen beendeten Dienste neu startet (was nicht ganz einfach ist, besonders wenn man wieder 100% erreichen will - von USB über Mediaserver/NAS bis WebDAV und das auch noch mit funktionierenden Watchdogs, damit bei Fehlern die Box nicht hängt).
Alles andere als die Pseudo-Image-Methode versagt aber bei neuer Firmware (ab 06.25) dann ebenfalls, wenn der Symlink für den Telnet-Daemon nicht mehr vorhanden ist. Nur bei der Pseudo-Image-Methode kann man ihn nachträglich wieder anlegen, indem man das Verzeichnis /usr/sbin mit einer beschreibbaren Kopie im tmpfs per bind-Mount überlagert. Das sähe dann in der install-Datei eines solchen Images etwa so aus:
und das Abbrechen des Neustarts sähe in etwa so aus in Shell-Code (Beispiel, es führen viele Wege zu den sieben Hügeln):
Das ist natürlich alles von der Existenz entsprechender Busybox-Applets abhängig, das variiert offenbar stark. Ich habe z.B. einen Screenshot von einer 3490-Shell, der die Vermutung nahelegt, daß dort kein Symlink für "reboot" im Pfad enthalten ist - was mich ziemlich schockiert hat, denn auch die AVM-Komponenten rufen an einigen Stellen intern "reboot" auf.
Anhang anzeigen 82374
Das eigentliche Problem des Telnet-Starts über ein Pseudo-Image bleibt es aber, daß die Box wie beschrieben einen teilweisen Shutdown ausführt beim Datei-Upload und es eben nicht trivial ist, den Ausgangszustand wiederherzustellen.
Ein "/etc/init.d/rc.net start" ist schon mal ein Anfang, aber es werden auch noch viele andere Dienste beendet (vom USB-Anschluß (hier hilft u.U. ein "udevadm trigger" mit anschließendem Warten) bis zur Home-Automatisierung in S78-aha und dem CAPIoTCP-Server), deren Wiederbelebung auch vom konkreten Modell abhängig ist, die Notwendigkeit ja sogar von den konkreten Einstellungen der jeweiligen Box.
Daher kann man dafür keine allgemeingültigen Vorlagen schaffen, ohne den kompletten AVM-Init-Prozess nachzubilden. Nach meinen Tests auf einer 7490 ist es auch nicht unbedingt eine gute Idee, einfach /etc/init.d/rc.S erneut aufzurufen (wie es 'init' beim Systemstart macht), um einfach noch einmal den gesamten Init-Prozess zu durchlaufen. Da dort erst mal einige Dateien auf Standardwerte gesetzt werden, bevor die tatsächlichen Einstellungen der Box angewendet werden, knallt das ziemlich schnell ... zumal ja auch noch einige Prozesse aktiv sind und auf die alten Dateiinhalte zugreifen - so jedenfalls meine Interpretation der anschließend auftretenden Crashes. Auch dürfte das mehrmalige Laden der binären Firmware-Dateien für den DSL-Prozessor und die DECT-/ISDN-Unterstützung nicht immer reibungslos verlaufen, wenn die nicht "in Grundstellung" sind.
Daher bleibt (zumindest in meinen Augen) die Pseudo-Image-Methode immer nur ein Provisorium für den ersten Zugriff, wenn andere Wege nicht funktionieren. Spätestens wenn man das erste Mal Zugriff auf die Shell hat (und diesen schon noch desöfteren benutzen möchte), sollte man sich Gedanken machen, wie man den Telnet-Daemon (natürlich noch besser einen sichereren Zugang zur Shell, z.B. SSH mit Dropbear oder ShellInABox mit TLS) dauerhaft aktiviert.
EDIT: Ganz merkwürdiges Phänomen ... der oben stehende Text wurde schon vor drei Tagen verfaßt, ist aber irgendwie beim Speichern unter die Räder gekommen, wie ich erst vorhin bemerkt habe, als ich ihn selbst suchte. Die Funktion "Gespeicherten Text wiederherstellen" hat ihn dann (ich hatte von diesem Laptop m.W. keinen weiteren Text danach mehr verfaßt) wieder zum Vorschein gebracht, aber im direkten Versuch des Speicherns klappte es wieder nicht. Erst mit C&P in eine neue Antwort wurde zumindest das "Original" akzeptiert, mal sehen, was jetzt aus dieser Änderung wird.
Damit sollte natürlich auch dort die Aktivierung des Telnet-Daemons per 'telefon'-Daemon (noch) funktionieren, wenn denn die Randbedingungen erfüllt sind. Die direkte Verarbeitung der Tastencodes funktioniert meines Wissens von einem IP-Telefon aus generell nicht, die Methode über den Eintrag im Telefonbuch und die Wählhilfe wird (vermutlich) ebenfalls nicht funktionieren, denn die Wählhilfe setzt auch ein "nicht-IP-Telefon" voraus.
Bleibt also noch die Möglichkeit der Aktivierung über die Änderung der fx_conf (oder auch hier und hier) in einer Export-Datei (das kann natürlich auch eine aus einer anderen Box exportierte Datei wie in #30 sein) oder über ein Pseudo-Image, wenn man den anstehenden Restart durch "firmwarecfg" abbricht (die PID des zu beendenden Prozesses steht in der Datei /var/run/delayed_reboot.pid) und anschließend die ganzen beendeten Dienste neu startet (was nicht ganz einfach ist, besonders wenn man wieder 100% erreichen will - von USB über Mediaserver/NAS bis WebDAV und das auch noch mit funktionierenden Watchdogs, damit bei Fehlern die Box nicht hängt).
Alles andere als die Pseudo-Image-Methode versagt aber bei neuer Firmware (ab 06.25) dann ebenfalls, wenn der Symlink für den Telnet-Daemon nicht mehr vorhanden ist. Nur bei der Pseudo-Image-Methode kann man ihn nachträglich wieder anlegen, indem man das Verzeichnis /usr/sbin mit einer beschreibbaren Kopie im tmpfs per bind-Mount überlagert. Das sähe dann in der install-Datei eines solchen Images etwa so aus:
Code:
mkdir /var/usrsbin
cp -a /usr/sbin/* /var/usrsbin/
ln -s /bin/busybox /var/usrsbin/telnetd
mount -o bind /var/usrsbin /usr/sbin
/usr/sbin/telnetd -l /sbin/ar7loginund das Abbrechen des Neustarts sähe in etwa so aus in Shell-Code (Beispiel, es führen viele Wege zu den sieben Hügeln):
Code:
rpid_name=/var/run/delayed_reboot.pid
if test -e $rpid_name; then
rpid=$(cat $rpid_name)
rm $rpid_name 2>/dev/null
[ ${#rpid} -gt 0 ] && kill -TERM $rpid
fiDas ist natürlich alles von der Existenz entsprechender Busybox-Applets abhängig, das variiert offenbar stark. Ich habe z.B. einen Screenshot von einer 3490-Shell, der die Vermutung nahelegt, daß dort kein Symlink für "reboot" im Pfad enthalten ist - was mich ziemlich schockiert hat, denn auch die AVM-Komponenten rufen an einigen Stellen intern "reboot" auf.
Anhang anzeigen 82374
Das eigentliche Problem des Telnet-Starts über ein Pseudo-Image bleibt es aber, daß die Box wie beschrieben einen teilweisen Shutdown ausführt beim Datei-Upload und es eben nicht trivial ist, den Ausgangszustand wiederherzustellen.
Ein "/etc/init.d/rc.net start" ist schon mal ein Anfang, aber es werden auch noch viele andere Dienste beendet (vom USB-Anschluß (hier hilft u.U. ein "udevadm trigger" mit anschließendem Warten) bis zur Home-Automatisierung in S78-aha und dem CAPIoTCP-Server), deren Wiederbelebung auch vom konkreten Modell abhängig ist, die Notwendigkeit ja sogar von den konkreten Einstellungen der jeweiligen Box.
Daher kann man dafür keine allgemeingültigen Vorlagen schaffen, ohne den kompletten AVM-Init-Prozess nachzubilden. Nach meinen Tests auf einer 7490 ist es auch nicht unbedingt eine gute Idee, einfach /etc/init.d/rc.S erneut aufzurufen (wie es 'init' beim Systemstart macht), um einfach noch einmal den gesamten Init-Prozess zu durchlaufen. Da dort erst mal einige Dateien auf Standardwerte gesetzt werden, bevor die tatsächlichen Einstellungen der Box angewendet werden, knallt das ziemlich schnell ... zumal ja auch noch einige Prozesse aktiv sind und auf die alten Dateiinhalte zugreifen - so jedenfalls meine Interpretation der anschließend auftretenden Crashes. Auch dürfte das mehrmalige Laden der binären Firmware-Dateien für den DSL-Prozessor und die DECT-/ISDN-Unterstützung nicht immer reibungslos verlaufen, wenn die nicht "in Grundstellung" sind.
Daher bleibt (zumindest in meinen Augen) die Pseudo-Image-Methode immer nur ein Provisorium für den ersten Zugriff, wenn andere Wege nicht funktionieren. Spätestens wenn man das erste Mal Zugriff auf die Shell hat (und diesen schon noch desöfteren benutzen möchte), sollte man sich Gedanken machen, wie man den Telnet-Daemon (natürlich noch besser einen sichereren Zugang zur Shell, z.B. SSH mit Dropbear oder ShellInABox mit TLS) dauerhaft aktiviert.
EDIT: Ganz merkwürdiges Phänomen ... der oben stehende Text wurde schon vor drei Tagen verfaßt, ist aber irgendwie beim Speichern unter die Räder gekommen, wie ich erst vorhin bemerkt habe, als ich ihn selbst suchte. Die Funktion "Gespeicherten Text wiederherstellen" hat ihn dann (ich hatte von diesem Laptop m.W. keinen weiteren Text danach mehr verfaßt) wieder zum Vorschein gebracht, aber im direkten Versuch des Speicherns klappte es wieder nicht. Erst mit C&P in eine neue Antwort wurde zumindest das "Original" akzeptiert, mal sehen, was jetzt aus dieser Änderung wird.
Zuletzt bearbeitet:
