Telnet starten - klar. Aber wie beenden? (Gelöst!)

meyergru

Neuer User
Mitglied seit
11 Sep 2005
Beiträge
163
Punkte für Reaktionen
3
Punkte
18
Ich weiß nicht, ob dies das richtige Unterforum für die Frage ist, aber:

Wenn man sich per Telnet auf einer Fritzbox einloggt und die Sitzung beenden will, kann man das mit "exit" tun. Die TCP-Verbindung wird dadurch aber nicht beendet, d.h. danach ist keine Eingabe mehr möglich. Ich meine mich zu erinnern, dass bei älteren Firmware-Versionen die Verbindung beendet wurde, so dass der Telnet-Client damit geschlossen wurde.

Mit meinem normalen Telnet-Client unter Linux ist standardmässig kein Escape-Char gesetzt, so dass man auch nicht mittels Telnet-Client-Kommandos die Sitzung beenden kann.

Unter Windows kann man natürlich einfach das Fenster schliessen.

Wieso geht das nicht mehr, bzw. gibt es dafür eine elegante Lösung?
 
Zuletzt bearbeitet:
Wenn man sich per Telnet auf einer Fritzbox einloggt und die Sitzung beenden will, kann man das mit "exit" tun. Die TCP-Verbindung wird dadurch aber nicht beendet, d.h. danach ist keine Eingabe mehr möglich.

Code:
killall telnetd

Telnet wird beendet und die TCP-Verbindung wird beendet.
 
Das ist aber nicht die genaue Antwort auf die Frage. Er wollte nur die aktuelle Session beenden und nicht den Telnet-Server komplett killen.

In verschiedenen Versionen der Busybox wird das Ende einer Verbindung verschieden gehandhabt. Wenn ich es richtig in Erinnerung habe, schließen die älteren Versionen die Verbindung, wenn der File-Deskriptor von allen Prozessen geschlossen wurde, während die neueren die Verbindung schließen, sobald die Shell beendet wird.

Wird bei Dir die Verbindung geschlossen, wenn Du Dich nur mit telnet anmeldest und sofort exit eingibst, also ohne vorher andere Programme zu starten? Wenn ja, hast DU vermutlich das Problem, daß gestartete Programme die Verbindung zum Terminal offen halten.

Ansonsten, gibt es einen besonderen Grund, warum Du bei Deinem telnet-Client den Escape-Char ausgeschaltet hast?
 
@RalfFriedl, mit der originalen busybox geht weder exit noch close, es hilft nur telenet mit dem x zu Schließen.
Bei den geänderten busyboxen geht exit sofort, ob das am esc-char von telnet liegt, hatte ich aber nicht probiert...
 
Das liegt nicht am esc-char, das ist eine Möglichkeit, von Seiten des Clients sofort die Verbindung zu schließen, unabhängig vom Server.

Bei den neueren Busyboxen ist einiges am telnet-Server geändert in der Handhabung, wie das Ende einer Verbindung erkannt wird. Ich wußte aber nicht, daß es auch welche gab, wo es gar nicht funktioniert hat.
 
Wenn der Server weiter lauschen soll, dann kann man auch nur den client killen.

Code:
killall telnet


Vor dem killen des client:
busybox 633 root 4u inet 30539 TCP 192.168.45.1:23->192.168.45.55:50940 (ESTABLISHED)

Nach dem killen des client, Server ist noch da und lauscht weiter. Wenn erforderlich könnte die Verbindung erneut aufgebaut werden:
busybox 633 root 3u inet 30319 TCP *:23 (LISTEN)

TCP-Verbindung ist nicht ESTABLISHED:
pfTop: Up State 1-1/1, View: default, Order: none, Cache: 10000 13:28:24

PR DIR SRC DEST STATE AGE EXP PKTS BYTES
tcp Out 192.168.45.55:50940 192.168.45.1:23 FIN_WAIT_2:FIN_WAIT_2 00:02:39 00:00:43 150 9892
 
Also "killall telnet" geht ja nur auf dem Client, das setzt aber erstmal ein offenes Fenster voraus. Es wäre schon gut, wenn ich die Verbindung im bestehenden Fenster beenden könnte.

Der ESC-Character des Clients ist per default unter Linux nicht gesetzt, sonst müsste man schon beim Telnet-Aufruf einen mitgeben:

-e escapechar
Sets the initial telnet escape character to escapechar. If
escapechar is omitted, then there will be no escape character.

"killall telnetd" würde tatsächlich den nächsten Login unmöglich machen.

Es ist unabhängig davon, was ich vorher gemacht habe, auch ein sofortiges "exit" beendet die Vebindung nicht.

Ich glaube nicht, dass der Shell-Teil der Busybox das Problem verursacht, denn wenn ich mit "kill -9" die betreffende Shell stoppe, geht es genauso wenig. Die Busybox wird schon beendet, aber danach müsste die TCP-Sitzung eben auch beendet werden. Eventuell ist das ein Problem im (Busybox-)telnetd oder dem vorgeschalteten /sbin/ar7login:

# ps w | fgrep telnet
854 root 1428 S telnetd -l /sbin/ar7login
 
... das setzt aber erstmal ein offenes Fenster voraus. Es wäre schon gut, wenn ich die Verbindung im bestehenden Fenster beenden könnte.

Wir reden doch von Linux. Da sollte ein Befehlsfenster der Konsole, doch kein Problem sein.;)
 
Einen Shell-Prozess "von aussen" stoppen zu müssen ist m.E. nach per se ein Problem...

Ich habe ja auch nicht gesagt, dass ich das nicht hinbekomme, zur Not kann ich ja auch das "umgebende" Fenster mit der SSH auf mein Linux-System schliessen und neu öffnen.

Trotzdem ist das lästig und unnötig. AVM wird aber mutmaßlich nichts ändern, da Telnet sowieso nicht supported wird.
 
Der ESC-Character des Clients ist per default unter Linux nicht gesetzt

Das wäre ungewöhnlich. Der ESC-Character ist normalerweise "^]". In Putty mit einer deutschen Tastatur kann dieses mit der Tastenkombination Strg+"+*~" erzeugt werden. Mit "+*~" meine ich die Taste, auf der Plus, Stern und Tilde drauf sind.

Der Ausschnitt aus dem Manual, den Du zitierst, soll wohl heißen, daß die Option -e ohne Angabe von escapechar den escapechar deaktiviert, aber nicht, daß das schon von Anfang an so ist. Vielmehr gäbe es dann keinen Grund, diese Möglichkeit zum Abschalten anzubieten, wenn escapechar sowieso nicht gesetzt wäre.
 
Das wäre ungewöhnlich. Der ESC-Character ist normalerweise "^]". In Putty mit einer deutschen Tastatur kann dieses mit der Tastenkombination Strg+"+*~" erzeugt werden. Mit "+*~" meine ich die Taste, auf der Plus, Stern und Tilde drauf sind.

Der Ausschnitt aus dem Manual, den Du zitierst, soll wohl heißen, daß die Option -e ohne Angabe von escapechar den escapechar deaktiviert, aber nicht, daß das schon von Anfang an so ist. Vielmehr gäbe es dann keinen Grund, diese Möglichkeit zum Abschalten anzubieten, wenn escapechar sowieso nicht gesetzt wäre.
Es lohnt sich doch immer wieder, dieses Forum zu befragen...

Danke, so geht es. Strg+"*+~", q und alles ist gut!
 
danke, das steuerung und plustaste hat mir auch den tag gerettet. lt. netlimiter schliesst sich die verbindung nach circa 30 sekunden und alles ist gut....
 
Den Konsolen-Output vorher von der Session zu nehmen scheint zu helfen.
Also: setconsole -r
und dann: exit
Dann schließt das Fenster bei mir sofort.

Kann jemand erklären warum das nicht automatisch passiert?
Bzw. warum der Konsolen-Output die Verbindung offen hält?
Ich peil es nicht ;)
 
Den Konsolen-Output vorher von der Session zu nehmen scheint zu helfen.
Also: setconsole -r
und dann: exit
Dann schließt das Fenster bei mir sofort.

Kann ich bestätigen. Ohne vorheriges setconsole -r wird die Verbindung nicht beendet!

Den Grund dafür würd ich aber auch gern erfahren. Bei mir könnte es eventuell auch daran liegen das ich eine Zeitlang FritzLoad auf meiner 7240 hatte. Vor der Installation von FritzLoad schloss die Verbindung automatisch.
 
Bei mir könnte es eventuell auch daran liegen das ich eine Zeitlang FritzLoad auf meiner 7240 hatte. Vor der Installation von FritzLoad schloss die Verbindung automatisch.

Ich habe das Problem obwohl die Box (7330) nagelneu ist ;)
 
Was für ein knackiger erster Beitrag nach sieben Jahren. :) Nur leider passt er nicht. :(
 
Abend

Naja.
Ich machs so: Strg^b c dann telnet irgendwohin und am End Strg^b x zur Bestätigung y




tmux

Aber meistens vergesse ich das, weil mit Srg^b p wieder auf vorherige Konsole.
Und dann kann es schoneinmal passieren, dass die Sitzung wochenlang läuft. :D
 
Zuletzt bearbeitet:

Zurzeit aktive Besucher

Statistik des Forums

Themen
246,300
Beiträge
2,249,713
Mitglieder
373,904
Neuestes Mitglied
Elemir
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.