Bug in telnetlib?

[jens]

Experimentiere gerade mit [mod]telnetlib[/mod] unter Windows. Ich verbinde mich auch mit dem Windowsrechner (localhost)...

Wenn ich debug mit tn.set_debuglevel(999) einschalte, kann ich sehen, das Daten die gesendet werden nur mit "\n" abgeschlossen sind. Das scheint aber mit Windows nicht zu funktionieren, weil "\n\r" erwartet wird!

Kann jeder unter Windows ja mal selber Testen mit dem hier:

Code: Alles auswählen

import sys
import telnetlib

HOST = "localhost"

print "connect '%s'..." % HOST,
tn = telnetlib.Telnet(HOST)
print "OK"

tn.set_debuglevel(1)

tn.mt_interact()

Man muß den "telnet" Dienst anhaben und den User in die Gruppe "TelnetClients" packen.

Es sieht so aus:

connect 'localhost'... OK
...
Telnet(localhost,23): recv 'Welcome to Microsoft Telnet Service \r\n'
Welcome to Microsoft Telnet Service
Telnet(localhost,23): recv '\n\rlogin: '


login: jens
Telnet(localhost,23): send 'jens\n'
Telnet(localhost,23): recv 'jens'
jens

Es wird also nur mit "\n" gesendet und man kommt nicht weiter...

Mit "\n\r" geht's aber, siehe:

Code: Alles auswählen

import sys
import telnetlib

HOST = "localhost"

print "connect '%s'..." % HOST,
tn = telnetlib.Telnet(HOST)
print "OK"

tn.set_debuglevel(1)

tn.read_until('login: ')
tn.write("jens\r\n")

tn.mt_interact()

Ausgabe:

connect 'localhost'... OK
...
Telnet(localhost,23): recv 'Welcome to Microsoft Telnet Service \r\n'
Telnet(localhost,23): recv '\n\rlogin: '
Telnet(localhost,23): send 'jens\n\r'
Telnet(localhost,23): recv 'jens\n\rpassword: '
jens

password:

Nun wurde der Username akzeptiert und man kommt zur Passwort abfrage...

hab in den Quellen von telnetlib.py gesucht, aber nichts gefunden, wie man das Problem ändern könnte.

(Getestet mit Python 2.5.2 unter Vista.)

Lustig ist, das es egal ist ob "\n\r" oder "\r\n" gesendet wurde

[Fabian Kochem]

Und wo liegt das Problem, \r ebenfalls noch mitzusenden?
Kannst ja eine Wrapper-Methode bauen, die das automatisch für dich erledigt (vllt noch überprüft, ob der zu sendene String bereits mit \n oder \r endet).

[jens]

Das Problem ist, das man so ohne weiteres nicht einfach nur tn.mt_interact() nutzten kann. Ein Wrapper bauen könnte man zwar tun, aber ist doch nur ein work-a-round. IMHO sollte es einfach so funktionieren...

[HWK]

Das scheint aber nichts mit der telnetlib zu tun zu haben. Ich habe dasselbe Phänomen auch bei 2 über die serielle Schnittstelle verbundenen Rechnern beobachtet. Eingaben vom Windows- an den Linuxrechner wurden nur akzeptiert, wenn diese mit '\r\n' abgeschlossen wurden.
MfG
HWK

[Y0Gi]

Hast du vielleicht mal die Telnet-RFC gelesen? Ich glaube auch, dass man sich hier nach den Delimitern richten sollte, die das Protokoll vorschreibt und nicht nach denen, die das Betriebssystem in Dateien verwendet. HTTP klappt auch nicht nur mit einem Newline.

[BlackJack]

Ein wirklich ganz kurzer Blick in RFC854 lässt mich vermuten, dass das Telnet-Protokoll einfach CR LF oder LF CR erwartet bzw. vorschreibt.

edit: Ups da war ich wohl auch mit dem ganz kurzen Blick zu langsam.

[Y0Gi]

Keine Sorge, kurz reingeblickt hab' ich da auch

[jens]

Naja, egal was die RFC854 nun vorschreibt, fakt ist, das es bei mir ertmal nur dann funktioniert, wenn \r\n oder \n\r gesendet wird und nicht nur ein \n...

Somit sollte entweder os.linesep genommen werden, oder zumindest die Möglichkeit die zeilenenden einfach zu ändern. z.B.:

Code: Alles auswählen

tn = telnetlib.Telnet(HOST, linesep=os.linesep)

oder so...

[Y0Gi]

Äh nee, es ist *nicht* egal, was die RFC vorschreibt - dafür ist ein Standard ja da. Und wenn der das festlegt, dann braucht man eine Library auch nicht konfigurierbar machen.

Und wie kommst du überhaupt auf die Idee, einen "file separator" mit einem Telnet-Kommando-Delimiter gleichsetzen zu wollen? Und wieso sollte der überhaupt uneinheitlich sein? Wie soll man gegen so eine (fehlende) Konvention denn etwas implementieren?

[jens]

Verwechselst du os.linesep mit os.sep?
http://docs.python.org/dev/library/os.html#os.linesep
http://docs.python.org/dev/library/os.html#os.sep

In einer guten, schönen Welt sollte man sich auf RFC und Co. verlassen können. In der bösen M$ Welt aber nicht. Gefällt mir auch nicht, aber so ist es halt.

Die Aufforderung "dann nimm doch ein gescheites Betriebsystem" hilft da auch nicht weiter...

[Leonidas]

In einer guten, schönen Welt sollte man sich auf RFC und Co. verlassen können. In der bösen M$ Welt aber nicht. Gefällt mir auch nicht, aber so ist es halt.

Die Aufforderung "dann nimm doch ein gescheites Betriebsystem" hilft da auch nicht weiter...

Es hilft insefern weiter, dass man kaputte Implementationen vermeidet. Die richtige Lösung wäre entweder ein anderes OS zu verwenden, einen anderen Telnet-Server oder gleich SSH. ``telnetlib`` empfinde ich als überflüssig, ist ähnlich nüzlich wie eine ``gopherlib``, selbst wenn Windows einen Gopher-Server mitliefern würde.

[Y0Gi]

Verwechselst du os.linesep mit os.sep?

Tatsache. Ich sehe allerdings nicht ein, wieso sich ein plattformübergreifendes/-unabhängiges Protokoll an den Eigenheiten einzelner Betriebssysteme orientieren sollte, solange sie ein bisschen mit ASCII hantieren können.