Telnet Program

[paul.zorn]

I am having some issues writing a telnet program, using telnetlib. I
am not sure if it is the telnet on the connections end or it is my
program.

A little background, when I log in straight from the Linux Command
prompt. The only thing I get is a blinking cursor. Then I type in my
command 'FOO' enter then screen on the very next line returns 'OK',
Then automatically puts the blinking cursor on the next line. Then
when I want to quit the telnet session I hit CTRL+Z that takes me to
telnet> then i type quit.

My Program currently looks like it connects. Because the last string
that I get back that is not blank says: "Logged in successfully".

So my problem is that when I issue the command through tn.write("FOO
\n"). Then do a tn.read_until('OK\n', 10). It gets returned nothing. I
have also added tn.read_until('OK\n', 10).splitlines(). That is also
returned blank.

I have tried various different newlines \n \r \r\n. All the
documentation for telnet program that I am logging into says, use
Carriage Return after each command. Nothing seems to get back the
data. I am not sure if the Python telnet is looking for more of true
command line like telnet>.

Any help would be great.
Thank You Very Much,
Paul

 

[Rob Wolfe]

I am having some issues writing a telnet program, using telnetlib. I
am not sure if it is the telnet on the connections end or it is my
program.

A little background, when I log in straight from the Linux Command
prompt. The only thing I get is a blinking cursor. Then I type in my
command 'FOO' enter then screen on the very next line returns 'OK',
Then automatically puts the blinking cursor on the next line. Then
when I want to quit the telnet session I hit CTRL+Z that takes me to
telnet> then i type quit.

My Program currently looks like it connects. Because the last string
that I get back that is not blank says: "Logged in successfully".

So my problem is that when I issue the command through tn.write("FOO
\n"). Then do a tn.read_until('OK\n', 10). It gets returned nothing. I
have also added tn.read_until('OK\n', 10).splitlines(). That is also
returned blank.

I have tried various different newlines \n \r \r\n. All the
documentation for telnet program that I am logging into says, use
Carriage Return after each command. Nothing seems to get back the
data. I am not sure if the Python telnet is looking for more of true
command line like telnet>.

Have you tried: tn.set_debuglevel(1) ?

HTH,
Rob

 

[paul.zorn]

Have you tried: tn.set_debuglevel(1) ?

HTH,
Rob

Thank You for the response. I did set the debugging level. I get back
this.

Telnet(192.168.2.75,5000): recv 'Password: '
Telnet(192.168.2.75,5000): send '*****\n'
Telnet(192.168.2.75,5000): recv '\r\x00\r\nlogged in successfully\r\n'
Telnet(192.168.2.75,5000): send '\n\n'
Telnet(192.168.2.75,5000): Sending AT
Telnet(192.168.2.75,5000): send 'AT\r\n'
Telnet(192.168.2.75,5000): recv '\r\x00'

So I on this command I should be getting back a 'OK' or 'ERROR'. But I
am not seeing it. I feel like I am missing something. Not sure what
would be the or is it the telnet application itself.

Thanks,
Paul

 

[Dennis Lee Bieber]

Telnet(192.168.2.75,5000): send '\n\n'

Should that be "\r\n" (or, if two lines is intended, "\r\n\r\n")

From http://www.faqs.org/rfcs/rfc854.html

"""
The sequence "CR LF", as defined, will cause the NVT to be positioned at
the left margin of the next print line (as would, for example, the
sequence "LF CR"). However, many systems and terminals do not treat CR
and LF independently, and will have to go to some effort to simulate
their effect. (For example, some terminals do not have a CR independent
of the LF, but on such terminals it may be possible to simulate a CR by
backspacing.) Therefore, the sequence "CR LF" must be treated as a
single "new line" character and used whenever their combined action is
intended; the sequence "CR NUL" must be used where a carriage return
alone is actually desired; and the CR character must be avoided in other
contexts. This rule gives assurance to systems which must decide
whether to perform a "new line" function or a multiple-backspace that
the TELNET stream contains a character following a CR that will allow a
rational decision.
"""
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Tim Roberts]

Thank You for the response. I did set the debugging level. I get back
this.

Telnet(192.168.2.75,5000): recv 'Password: '
Telnet(192.168.2.75,5000): send '*****\n'
Telnet(192.168.2.75,5000): recv '\r\x00\r\nlogged in successfully\r\n'
Telnet(192.168.2.75,5000): send '\n\n'
Telnet(192.168.2.75,5000): Sending AT
Telnet(192.168.2.75,5000): send 'AT\r\n'
Telnet(192.168.2.75,5000): recv '\r\x00'

So I on this command I should be getting back a 'OK' or 'ERROR'. But I
am not seeing it. I feel like I am missing something. Not sure what
would be the or is it the telnet application itself.

Are you talking to a modem here? Are you sure you don't need +++ to get
its attention before sending AT commands?

 

[Tim Roberts]

Should that be "\r\n" (or, if two lines is intended, "\r\n\r\n")

I don't think so. The RFC quote you provided talks about the physical
manifestation of CR and LF on a terminal, and says that a Telnet server
must be prepared to handle various combinations, but if you think about a
real Telnet session, the user is going to press CR when its through with a
line. Thus, I would think he needs either \r\r or \n\n.

 

[Dennis Lee Bieber]

I don't think so. The RFC quote you provided talks about the physical
manifestation of CR and LF on a terminal, and says that a Telnet server
must be prepared to handle various combinations, but if you think about a
real Telnet session, the user is going to press CR when its through with a
line. Thus, I would think he needs either \r\r or \n\n.

Whilst it has been years since I used a telnet client for connection
(an Amiga terminal emulator to a shell account at Netcom -- prior to
starting TIA and passing the connection to a TCP/IP stack), they
typically /sent/ \r\n in response to a simple <cr> (<enter>) key. I
never had to double up a key stroke, nor send <cr>(<ctrl-m>)<ctrl-l>
explicitly.

Note, also, that the log shows a return of the <cr><nul> sequence
specified for the case of a return /without/ line feed.
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/