Telnet mit Freetz auf FB7490 mit OS 6.25 Beta1

Coolzero82

Mitglied
Mitglied seit
24 Sep 2013
Beiträge
345
Punkte für Reaktionen
2
Punkte
18
Hallo,
ist es mit Freetz möglich weiterhin Telnet auf der FB 7490 mit der aktuellen Fritz OS 6.25 zu nutzen obwohl AVM das deaktiviert hat?

Freetz Zeigt mir zwar an das Telnet gestartet sei, aber ich kann trotzdem mittels Putty und ähnlichem nicht drauf zugreifen, was vorher immer ging!?

Danke
 
Mit freetz geht es definitiv weiterhin, ich habe keine Probleme auf meiner 06.25er Box.

Hier auch ein Beitrag: http://freetz.org/ticket/2748
 
Zuletzt bearbeitet:
Freetz Zeigt mir zwar an das Telnet gestartet sei, aber ich kann trotzdem mittels Putty und ähnlichem nicht drauf zugreifen, was vorher immer ging!?
Etwas genauer wäre schön ... notfalls auch mal auf "automatisch" umstellen. Bisher (zumindest war es bisher so, wenn ich mich nicht "verlesen" habe) entscheidet Freetz anhand der Tatsache, ob ein telnetd-Prozess aktiv ist ohne daß seitens Freetz ein entsprechender Eintrag in der inetd.conf vorgenommen wurde, ob das "byphone" ist oder nicht.

Wenn Telnet seitens Freetz gestartet werden soll (weil es der AVM-Daemon "telefon" eben nicht macht, wenn es in der fx_conf nicht aktiviert ist), dann erfolgt ohnehin nur ein Eintrag in der inetd.conf, der dann eben beim ersten Verbindungsversuch den telnet-Daemon startet. Event. stimmt ja mit dem Eintrag in dieser Datei etwas nicht ... da wäre eine Angabe, wie die auf der Box tatsächlich aussieht (z.B. mit der Rudi-Shell ermitteln), hilfreich - genauso wie eine Prozessliste. Hat nicht sogar Freetz so etwas wie einen "Support"-Link zum Zusammenstellen aller möglichen Protokolle?

Ich bin mir z.B. nicht sicher, welches Login-Programm da aufgerufen wird in einem Freetz-Image, wenn der Start durch den "telefon"-Daemon erfolgt. Auch habe ich es schon erlebt, daß die nachträglichen Änderungen an der /etc/passwd durch Freetz (ggf. auch an der users.map, so genau habe ich da nicht gesucht) am Ende das ar7login von AVM so durcheinander bringen, daß dort nur noch das Login über den Linux-Benutzernamen (also root) möglich war. Die von AVM dafür entwickelten Funktionen zum Mapping zwischen AVM-GUI-Accounts und Linux-Benutzernamen sind ja alle jünger als die entsprechenden Stellen im Freetz.

Meines Wissens (ich benutze das aber auch nicht selbst, merke das also nur ab und an mal, wenn ich etwas mit einem Freetz-Image testen will, deshalb die Behauptung bitte mit entsprechender Skepsis betrachten) wurde da schon lange nichts mehr angepaßt, die richtig "ausführliche" Benutzerverwaltung mit differenzierten Rechten ist ja auch noch nicht sooo alt. Für mich war aber (kann auch mein Fehler gewesen sein) beim letzten Freetz-Image für eine 7390 beim Testen schon die erste Hürde, daß da vermutlich (es hat mich nicht weiter interessiert) ein anderes Login-Programm selbst dann zum Einsatz kommt (oder eben ar7login so verwirrt wird), daß ein Login mit einem administrativen User aus dem AVM-GUI nicht möglich war. Ob das nicht sogar "by design" ist, weiß ich aber eigentlich auch nicht richtig/sicher.

Vielleicht ist das neue System ab 06.35 bei AVM ja auch bei Freetz der Anlaß, die Benutzerverwaltung mal etwas zu überarbeiten und ggf. an die von AVM dazu inzwischen implementierten Funktionen anzupassen.
 
Moins

Das letzte freetz Image* mit telnetd auf 6.20er Basis au meiner 7360SL erlaubte mir kein root Login.
Ich musste mit der Rudi-Shell die /etc/passwd editieren, dem User nobody die GID 0 verpassen und ein Homeverzeichnis nebst Loginshell.
Danach mit modsave gespeichert.
Mit dem nobody konnte ich mich dann einloggen.

Kann sein, das in meiner freetz .config (securetty?, shells?) etwas für dieses Verhalten sorgt.
Denn normalerweise, so hab ich es in Erinnerung, forderte freetz beim ersten (root) Login zum Passwortändern auf.


* FRITZ.Box Fon WLAN 7360 SL 109.06.20-freetz-devel-13178
 
Zuletzt bearbeitet:
re

Also ich komme einfach mit putty und telnet nicht auf die Box,ab leider keine rudi shell installiert, so das das auch nicht klappt.
Das starten von Dropbear schlägt auch ohne erkennbaren grund fehl :
Starting dropbear SSH server ... failed.

Ein Neustart der Box bringt leider auch nichts...
 
Ich habe mir zwar fest vorgenommen, deutlich seltener auf unvollständige Fehlerbeschreibungen mit "Meckern" zu reagieren und solche Threads künftig eher zu ignorieren ... aber hier geht es mir eben wie Luther.

@Coolzero82:
Hältst Du das jetzt wirklich für eine "genauere Beschreibung"?

Wenn ja, ich habe hier ein ähnliches Problem. Mein Fernseher geht nämlich nicht an (um nicht schon wieder das Auto zu strapazieren) ... wenn ich bei der Fernbedienung auf den "Power"-Knopf drücke, passiert gar nichts. Auch habe ich mal den Netzstecker aus der Mehrfachsteckdose gezogen und in einen anderen Steckplatz (links daneben, um 180 Grad gedreht, es ist eine weiße dreifache Steckdosenleiste mit einem Ein-/Ausschalter mit Glimmlampe von Brennenstuhl) gesteckt. Das hat aber auch nichts geholfen ... jetzt kann ich nur noch auf Deine Hilfe bauen. Was soll ich tun? Brauche ich jetzt einen neuen Fernseher oder ist der alte vielleicht doch noch zu retten? Wenn nicht, sollte ich dann nicht lieber zu einem Buch greifen, anstatt das Leben mit dem Fernsehprogramm (ich bin leidenschaftlicher RTL-Nachmittags-Gucker) zu verschwenden? Das muß jetzt an Details auch erst einmal ausreichen, wenn Du noch weitere Angaben brauchst, um mir bei meinem Problem zu helfen, kannst Du ja ruhig selbst fragen. :mrgreen:
 
Ich gratuliere dir zu dem defekten Fernseher, denn dann brauchst du dir den RTL Nachmittagsschrott nicht mehr antun;)
So genug ironie.
Wenn ich wirklich wüsste welche Infos dir(allen anderen) das Leben leichter machen würde, würde ich dir die gerne geben!
Es ist ein eigenbau IMage, welches auf der 6.25 Labor bassiert, mit TBFlex 3.1 und externel
Code:
7490_06.25-rev30758_labor-freetz-devel-13218M.de_20150705-172227.img
 
Wenn ich wirklich wüsste welche Infos dir(allen anderen) das Leben leichter machen würde, würde ich dir die gerne geben!
Ich kann diese "Unbeholfenheit" aber auch nur in Grenzen verstehen.

Wenn man Freetz benutzt und Telnet/SSH/was auch immer benutzen will, sollte man zumindest schon mal etwas vom "syslogd" gehört haben und auch das Freetz-GUI beinhaltet ja nun auch genug Protokolle, die schon beim "Status" angezeigt werden, wenn ich mich recht erinnere (ich selbst nutze tatsächlich kein Freetz, was mich u.U. für eine erfolgreiche Hilfestellung bei Deinem Problem schon disqualifizieren könnte).

Und selbst wenn man das nicht hat, sollte man schon mal von der ".config"-Datei eines Freetz-Images gehört/gelesen haben.

Und das ist es am Ende auch, was ich klarmachen wollte ... wenn Du nicht selbst die Informationen bereitstellst (notfalls liest man die Beschreibungen anderer hier - dann aber auch den kompletten Thread und nicht nur #1 - um zu ergründen, wie so eine "Fehlermeldung" aussehen sollte) und Dich lieber darauf verlassen willst, daß schon irgendjemand die "richtigen Fragen" stellt, dann wird das wohl eher nichts werden.

Ich habe mich nach einiger (auch indirekter) Kritik an zu häufigen Nachfragen, die eigentlich nur das "da fehlen Fakten" zum Ausdruck bringen konnten (je nach Tagesform mal mehr, mal weniger freundlich/deutlich/zurückhaltend), jedenfalls dazu entschlossen, solche "Probleme" in Zukunft auch einfach zu ignorieren - es gibt einfach zuviele Leute, die aus so einer Nachfrage dann etwas herauslesen, was man dort gar nicht hineinschreiben wollte (das gilt hier nicht, damit Du das nicht auch "in den falschen Hals bekommst") und sich am Ende noch darüber aufregen, daß man ihnen nicht jeden Fakt einzeln aus der Nase zieht (O-Ton: Frag doch einfach, wenn Du etwas wissen willst.).
 
Um es vielleicht ganz einfach zu halten bzw die Ursache einzugrenzen: Hast Du mal ein recover gemacht, das Image neu eingespielt und gesehen ob es dann geht?
 
Um es vielleicht ganz einfach zu halten bzw die Ursache einzugrenzen: Hast Du mal ein recover gemacht, das Image neu eingespielt und gesehen ob es dann geht?

Hi,
ich hab mal recovert und dann ein neues Image auf Basis 6.29 hochgeflasht, aber gleiche probleme, weder telnet noch dropbear lassen sich aktivieren.

Ich kann diese "Unbeholfenheit" aber auch nur in Grenzen verstehen.

Wenn man Freetz benutzt und Telnet/SSH/was auch immer benutzen will, sollte man zumindest schon mal etwas vom "syslogd" gehört haben und auch das Freetz-GUI beinhaltet ja nun auch genug Protokolle, die schon beim "Status" angezeigt werden, wenn ich mich recht erinnere (ich selbst nutze tatsächlich kein Freetz, was mich u.U. für eine erfolgreiche Hilfestellung bei Deinem Problem schon disqualifizieren könnte).
syslogd gibt beim versuch telnet und dropbear zu starten diese meldungen aus
Code:
Jul  7 13:14:06 fritz kern.debug kernel: [ 1645.460000] pcp_handle_request: pid 1258 opcode 1
Jul  7 13:14:06 fritz kern.debug kernel: [ 1645.460000] pcp_handle_reply: pid 1258 opcode 1 ret 0
Jul  7 13:14:16 fritz kern.debug kernel: [ 1655.480000] pcp_handle_request: pid 1258 opcode 1
Jul  7 13:14:16 fritz kern.debug kernel: [ 1655.480000] pcp_handle_reply: pid 1258 opcode 1 ret 0
Jul  7 13:14:18 fritz kern.debug kernel: [ 1657.480000] pcp_handle_request: pid 1258 opcode 1
Jul  7 13:14:18 fritz kern.debug kernel: [ 1657.480000] pcp_handle_reply: pid 1258 opcode 1 ret 0
Jul  7 13:14:35 fritz kern.debug kernel: [ 1674.470000] pcp_handle_request: pid 1258 opcode 1
Jul  7 13:14:35 fritz kern.debug kernel: [ 1674.470000] pcp_handle_reply: pid 1258 opcode 1 ret 0
Jul  7 13:15:01 fritz kern.debug kernel: [ 1700.480000] pcp_handle_request: pid 1258 opcode 1
Jul  7 13:15:01 fritz kern.debug kernel: [ 1700.480000] pcp_handle_reply: pid 1258 opcode 1 ret 0
Jul  7 13:15:12 fritz kern.info kernel: [ 1711.820000] /proc/tffs: info request: success
Jul  7 13:15:15 fritz kern.debug kernel: [ 1714.460000] pcp_handle_request: pid 1258 opcode 1
Jul  7 13:15:15 fritz kern.debug kernel: [ 1714.460000] pcp_handle_reply: pid 1258 opcode 1 ret 0
Jul  7 13:15:23 fritz kern.debug kernel: [ 1722.480000] pcp_handle_request: pid 1258 opcode 1
Jul  7 13:15:23 fritz kern.debug kernel: [ 1722.480000] pcp_handle_reply: pid 1258 opcode 1 ret 0
Jul  7 13:15:25 fritz kern.debug kernel: [ 1724.480000] pcp_handle_request: pid 1258 opcode 1
Jul  7 13:15:25 fritz kern.debug kernel: [ 1724.480000] pcp_handle_reply: pid 1258 opcode 1 ret 0
Jul  7 13:15:42 fritz authpriv.warn dropbear[13058]: Failed loading /var/tmp/rsa_host_key
Jul  7 13:15:42 fritz authpriv.warn dropbear[13058]: Failed loading /var/tmp/dss_host_key
Jul  7 13:15:42 fritz authpriv.warn dropbear[13058]: Failed loading /var/tmp/ecdsa_host_key
Jul  7 13:15:42 fritz authpriv.info dropbear[13058]: Early exit: No hostkeys available

und beim versuch telnet übers telefon zu starten kommt
Code:
Jul  7 13:17:20 fritz kern.info kernel: [ 1839.460000] avm_pa: telephony active (reduce)
Jul  7 13:17:20 fritz kern.debug kernel: [ 1839.460000] avm_pa: sip telephony is active
Jul  7 13:17:20 fritz kern.info kernel: [ 1839.510000] avm_pa: avm_pa_telefon_state
Jul  7 13:17:20 fritz kern.info kernel: [ 1839.580000] avm_pa: avm_pa_telefon_state
Jul  7 13:17:20 fritz kern.info kernel: [ 1839.580000] avm_pa: telephony inactive
Jul  7 13:17:20 fritz kern.debug kernel: [ 1839.580000] avm_pa: sip telephony is not active
Jul  7 13:17:25 fritz kern.info kernel: [ 1844.730000] avm_pa: telephony active (reduce)
Jul  7 13:17:25 fritz kern.debug kernel: [ 1844.730000] avm_pa: sip telephony is active
Jul  7 13:17:25 fritz kern.info kernel: [ 1844.780000] avm_pa: avm_pa_telefon_state
Jul  7 13:17:25 fritz kern.info kernel: [ 1844.840000] avm_pa: telephony inactive
Jul  7 13:17:25 fritz kern.debug kernel: [ 1844.840000] avm_pa: sip telephony is not active
Jul  7 13:17:25 fritz kern.info kernel: [ 1844.850000] avm_pa: avm_pa_telefon_state
Jul  7 13:17:27 fritz kern.debug kernel: [ 1846.480000] pcp_handle_request: pid 1258 opcode 1
Jul  7 13:17:27 fritz kern.debug kernel: [ 1846.480000] pcp_handle_reply: pid 1258 opcode 1 ret 0

Und selbst wenn man das nicht hat, sollte man schon mal von der ".config"-Datei eines Freetz-Images gehört/gelesen haben.[\QUOTE]
Ist im Anhang
Und das ist es am Ende auch, was ich klarmachen wollte ... wenn Du nicht selbst die Informationen bereitstellst (notfalls liest man die Beschreibungen anderer hier - dann aber auch den kompletten Thread und nicht nur #1 - um zu ergründen, wie so eine "Fehlermeldung" aussehen sollte) und Dich lieber darauf verlassen willst, daß schon irgendjemand die "richtigen Fragen" stellt, dann wird das wohl eher nichts werden.

Ich habe mich nach einiger (auch indirekter) Kritik an zu häufigen Nachfragen, die eigentlich nur das "da fehlen Fakten" zum Ausdruck bringen konnten (je nach Tagesform mal mehr, mal weniger freundlich/deutlich/zurückhaltend), jedenfalls dazu entschlossen, solche "Probleme" in Zukunft auch einfach zu ignorieren - es gibt einfach zuviele Leute, die aus so einer Nachfrage dann etwas herauslesen, was man dort gar nicht hineinschreiben wollte (das gilt hier nicht, damit Du das nicht auch "in den falschen Hals bekommst") und sich am Ende noch darüber aufregen, daß man ihnen nicht jeden Fakt einzeln aus der Nase zieht (O-Ton: Frag doch einfach, wenn Du etwas wissen willst.).
Das kann ich nachvollziehen, und gelobe besserung, allerdings ist es natürlich auch nicht immer ganz einfach zu wissen welche informationen ihr genau braucht, denn nicht jeder hier ist so tief in der Thematik drin.

Anhang anzeigen config.txt
 
Hast Du nach Recovery auch mal eine gesicherte Freetz-Konfiguration wieder eingespielt?

Irgendwie sieht das alles im Log so aus, als wenn da gar keine Konfiguration für den dropbear vorliegt.

Nach dieser Stelle
Code:
        if [ ! -d "/mod/etc/ssh" ]; then
                mkdir -p /mod/etc/ssh
                for alg in rsa dss ecdsa; do
                        ln -sf /tmp/flash/dropbear/${alg}_host_key /mod/etc/ssh/${alg}_host_key
                done
        fi
sollte der dropbear-Server eigentlich so konfiguriert werden, daß die Key-Files in /mod/etc/ssh oder in /tmp/flash/dropbear erwartet werden. Andererseits schaut der lt. Syslog-Ausgabe
Code:
Jul  7 13:15:42 fritz authpriv.warn dropbear[13058]: Failed loading /var/tmp/rsa_host_key
Jul  7 13:15:42 fritz authpriv.warn dropbear[13058]: Failed loading /var/tmp/dss_host_key
Jul  7 13:15:42 fritz authpriv.warn dropbear[13058]: Failed loading /var/tmp/ecdsa_host_key
Jul  7 13:15:42 fritz authpriv.info dropbear[13058]: Early exit: No hostkeys available
an der falschen Stelle. Ich habe jetzt nicht in den Code geschaut (nach meiner Erinnerung wird der Standardpfad bei der Kompilierung festgelegt), aber selbst wenn das die "Fallback"-Pfade wären, sollte eigentlich bei korrekter Konfiguration irgendein Key-File am erwarteten Ort (/mod/etc/ssh) vorhanden sein (als Symlink). Nach dem rc-File verwendet der dropbear bei Freetz die Option -r zur Festlegung abweichender Key-Files nicht.

Zum Telnet-Daemon kann man in den Log-Auszügen nichts sehen, außer daß Du da offenbar mit einem IP-Client die Eingabe der Tastencodes versuchst:
Code:
Jul  7 13:17:25 fritz kern.info kernel: [ 1844.730000] avm_pa: telephony active (reduce)
Jul  7 13:17:25 fritz kern.debug kernel: [ 1844.730000] avm_pa: sip telephony is active
Jul  7 13:17:25 fritz kern.info kernel: [ 1844.780000] avm_pa: avm_pa_telefon_state
Jul  7 13:17:25 fritz kern.info kernel: [ 1844.840000] avm_pa: telephony inactive
Jul  7 13:17:25 fritz kern.debug kernel: [ 1844.840000] avm_pa: sip telephony is not active
Jul  7 13:17:25 fritz kern.info kernel: [ 1844.850000] avm_pa: avm_pa_telefon_state
was meines Wissens (ggf. bitte selbst überprüfen, auch korrigieren, wenn ich das Log falsch interpretiere, aber bei erkanntem Tastencode sollte das m.E. auch an einem IP-Anschluß nicht wie oben protokolliert werden, weil ja gar keine Verbindung stattfindet, die den AVM-PA tangieren sollte) mit einem IP-Telefon ohnehin nicht funktioniert.

tl;dr:
- dropbear vermutlich nicht konfiguriert
- telnetd vermutlich nicht aktiviert
- Prozessliste wäre hilfreich (gibt es die in der Freetz-Oberfläche nicht?)

PS: Gibt es eigentlich einen Grund, warum Du den dropbear als statisches Binary und mit der Möglichkeit, den auch außerhalb von Freetz einzusetzen (was m.W. nach den Quellen definitiv dann Auswirkungen auf die Pfade zu den Key-Files hat), übersetzen läßt? Ich mag mich ja irren, aber wenn Du diese Konfiguration auch schon früher verwendet hast (was ist denn mit der 7390 aus der Signatur?), dann sollte das auch früher schon nicht funktioniert haben. Die Freetz-Konfiguration (rc.dropbear) berücksichtigt jedenfalls (Stand 07.07.15, 14:35) nicht, daß die Key-Files beim "standalone"-Patch in /var/tmp gesucht werden.
 
Zuletzt bearbeitet:
So, hab jetzt nochmal recovert , und ein komplett neues 6.25 Image gebaut und geflasht. Damit lässt sich dann Dropbear und auch telnet wieder problemlos starten.

Danke für eure Hilfe
 

Neueste Beiträge

Statistik des Forums

Themen
244,858
Beiträge
2,219,650
Mitglieder
371,572
Neuestes Mitglied
#Kuddel#
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.

IPPF im Überblick

Neueste Beiträge