telnet 'connection reset by peer'

[Donnal Walter]

On Windows XP I am able to connect to a remote telnet server from the
command prompt using:

telnet nnn.nnn.nnn.nnn 23

where nnn.nnn.nnn.nnn is the IP address of the host. But using
telnetlib, this code returns the traceback that follows:

import telnetlib
host = 'nnn.nnn.nnn.nnn'
tn = telnetlib.Telnet(host, 23)
tn.read_until("Enter device name?")


Traceback (most recent call last):
File "C:\Python23\Lib\site-packages\mindwrapper\test\telnet.py", line
4, in ?
tn.read_until("Enter device name?")
File "C:\Python23\lib\telnetlib.py", line 316, in read_until
self.fill_rawq()
File "C:\Python23\lib\telnetlib.py", line 521, in fill_rawq
buf = self.sock.recv(50)
socket.error: (10054, 'Connection reset by peer')

Is there some parameter that I need to set in order to connect using the
telnetlib client? Thanks.

Donnal Walter
Arkansas Children's Hospital

 

[Eddie Corns]

On Windows XP I am able to connect to a remote telnet server from the
command prompt using:

telnet nnn.nnn.nnn.nnn 23

where nnn.nnn.nnn.nnn is the IP address of the host. But using
telnetlib, this code returns the traceback that follows:

import telnetlib
host = 'nnn.nnn.nnn.nnn'
tn = telnetlib.Telnet(host, 23)
tn.read_until("Enter device name?")

Traceback (most recent call last):
File "C:\Python23\Lib\site-packages\mindwrapper\test\telnet.py", line
4, in ?
tn.read_until("Enter device name?")
File "C:\Python23\lib\telnetlib.py", line 316, in read_until
self.fill_rawq()
File "C:\Python23\lib\telnetlib.py", line 521, in fill_rawq
buf = self.sock.recv(50)
socket.error: (10054, 'Connection reset by peer')

Is there some parameter that I need to set in order to connect using the
telnetlib client? Thanks.

No, that should work, to a reasonably conforming telnet server. Try doing
tn.set_debuglevel(2) before the read_until() to see what's coming back.

Does it happen instantly or is something timing out?

Eddie

 

[Donnal Walter]

No, that should work, to a reasonably conforming telnet server. Try doing
tn.set_debuglevel(2) before the read_until() to see what's coming back.

Telnet(nnn.nn.nnn.nnn,23): recv
'\xff\xfb\x03\xff\xfd\x03\xff\xfb\x01\xff\xfd\x1
7\xff\xfb\x00\xff\xfd\x00'
Telnet(nnn.nn.nnn.nnn,23): IAC WILL 3
Telnet(nnn.nn.nnn.nnn,23): IAC DO 3
Telnet(nnn.nn.nnn.nnn,23): IAC WILL 1
Telnet(nnn.nn.nnn.nnn,23): IAC DO 23
Telnet(nnn.nn.nnn.nnn,23): IAC WILL 0
Telnet(nnn.nn.nnn.nnn,23): IAC DO 0
Traceback (most recent call last):
File "C:\Python23\Lib\site-packages\mindwrapper\test\telnet.py", line
5, in ?
tn.read_until("Enter device name?")
File "C:\Python23\lib\telnetlib.py", line 316, in read_until
self.fill_rawq()
File "C:\Python23\lib\telnetlib.py", line 521, in fill_rawq
buf = self.sock.recv(50)
socket.error: (10054, 'Connection reset by peer')

Thank you for the suggestion. Can you help me interpret the feedback?

Does it happen instantly or is something timing out?

No, it always happens instantly.

Thanks.

Donnal Walter
Arkansas Children's Hospital

 

[Eddie Corns]

Eddie Corns wrote:

Telnet(nnn.nn.nnn.nnn,23): recv
'\xff\xfb\x03\xff\xfd\x03\xff\xfb\x01\xff\xfd\x1
7\xff\xfb\x00\xff\xfd\x00'
Telnet(nnn.nn.nnn.nnn,23): IAC WILL 3
Telnet(nnn.nn.nnn.nnn,23): IAC DO 3
Telnet(nnn.nn.nnn.nnn,23): IAC WILL 1
Telnet(nnn.nn.nnn.nnn,23): IAC DO 23
Telnet(nnn.nn.nnn.nnn,23): IAC WILL 0
Telnet(nnn.nn.nnn.nnn,23): IAC DO 0
Traceback (most recent call last):
File "C:\Python23\Lib\site-packages\mindwrapper\test\telnet.py", line
5, in ?
tn.read_until("Enter device name?")
File "C:\Python23\lib\telnetlib.py", line 316, in read_until
self.fill_rawq()
File "C:\Python23\lib\telnetlib.py", line 521, in fill_rawq
buf = self.sock.recv(50)
socket.error: (10054, 'Connection reset by peer')

Thank you for the suggestion. Can you help me interpret the feedback?

The IACs are commands embedded in the data stream. This page:
http://www.scit.wlv.ac.uk/~jphb/comms/telnet.html looks like a decent overview
of how telnet works. The purpose here is to negotiate what the capabilities
of the telnet session (eg echo). Looking at the code in telnetlib, it seems
to always send back DONT or WONT for every option (ie refuses to support or
use any option requested). It's possible the server is deciding that on this
basis it cannot proceed. There doesn't seem to be a single place where all
the telnet options are described so I don't know what 0,1,3,23 actually are.
This page might help: http://home.swipnet.se/cfmd/rfc/dir/telnet.html
You might try using the tn.set_option_negotiation_callback() method to send
your own negotiation messages back if you think that what it is asking for is
harmless (you could snoop on your windows session, eg with ethereal, to see
what windows is sending back).

It seems a bit drastic to behave this way but I suppose it depends on what the
server is trying to do. I wouldn't rule out it being a completely different
problem but nothing springs to mind. It may be easier to experiment with
options using a raw socket, copy the code in telnetlib.

HTH,
Eddie

 

[Donnal Walter]

The IACs are commands embedded in the data stream. This page:
http://www.scit.wlv.ac.uk/~jphb/comms/telnet.html looks like a decent overview
of how telnet works. The purpose here is to negotiate what the capabilities
of the telnet session (eg echo). Looking at the code in telnetlib, it seems
to always send back DONT or WONT for every option (ie refuses to support or
use any option requested). It's possible the server is deciding that on this
basis it cannot proceed. There doesn't seem to be a single place where all
the telnet options are described so I don't know what 0,1,3,23 actually are.
This page might help: http://home.swipnet.se/cfmd/rfc/dir/telnet.html
You might try using the tn.set_option_negotiation_callback() method to send
your own negotiation messages back if you think that what it is asking for is
harmless (you could snoop on your windows session, eg with ethereal, to see
what windows is sending back).

Thank you. Dealing with telnet at this low level is all new to me, so
the urls and pointers were helpful. In particular, I downloaded ethereal
(also new to me) and filtered the packets by ip address. This way I
found that 0 is 'binary transmission', 1 is 'echo', 3 is 'suppress go
ahead' and 23 is 'send location' (plus I learned how to send location).

It seems a bit drastic to behave this way but I suppose it depends on what the
server is trying to do. I wouldn't rule out it being a completely different
problem but nothing springs to mind. It may be easier to experiment with
options using a raw socket, copy the code in telnetlib.

I still have not decided how I am going to tackle this. My first attempt
is likely to be an option_negotiation_callback function as you suggested
above. In any case, your suggestions have been most helpful. Thanks, again.

Donnal Walter