Problems with telnetlib

[Bengt Richter]

On 19 Feb 2002 00:00:50 +0100, Jan-Fredrik Braseth <janfbr at sex.ifi.uio.no> wrote:

>"Patrick Vrijlandt" <p.vrijlandt at aig.azn.nl> writes:
>
>> Hi,
>> 
>> Previous discussions have narrowed down the line in telnetlib that is buggy.
>> The problem is probably that the server is sending you a special (Telnet)
>> command.
>
>Even though I haven't looked very closely it looks like they just forgot
>to initiate the 'opt' variable in one part of the if-else branch
>
It's not that the opt variable was not initialized, it's that opt is the
wrong variable. It has no legitimate value to bind to at that point. If it had
happened to be initialized, there would be the same error, but it would have been
silent, or would have indicated the wrong value if you turned on the program's
debug messages.

The fix is not to do anything with opt in that path. The
fix is to use the right variable in its place (i.e., c).

But I think Patrick is trying to point out that you could be receiving any of

      NAME               CODE              MEANING

      SE                  240    End of subnegotiation parameters.
      NOP                 241    No operation.
      Data Mark           242    The data stream portion of a Synch.
                                 This should always be accompanied
                                 by a TCP Urgent notification.
      Break               243    NVT character BRK.
      Interrupt Process   244    The function IP.
      Abort output        245    The function AO.
      Are You There       246    The function AYT.
      Erase character     247    The function EC.
      Erase Line          248    The function EL.
      Go ahead            249    The GA signal.
      SB                  250    Indicates that what follows is
                                 subnegotiation of the indicated
                                 option.

and, other than ignoring nulls and ^Q, the telnetlib.py code appears only to be
looking looking for IAC followed by

      WILL (option code)  251    Indicates the desire to begin
                                 performing, or confirmation that
                                 you are now performing, the
                                 indicated option.
      WON'T (option code) 252    Indicates the refusal to perform,
                                 or continue performing, the
                                 indicated option.
      DO (option code)    253    Indicates the request that the
                                 other party perform, or
                                 confirmation that you are expecting
                                 the other party to perform, the
                                 indicated option.
      DON'T (option code) 254    Indicates the demand that the
                                 other party stop performing,
                                 or confirmation that you are no
                                 longer expecting the other party
                                 to perform, the indicated option.

followed by an option that it rejects with proper protocol, or IAC followed by

      IAC                 255    Data Byte 255.
which when following itself is passed as a plain single character
with that value.

Have you tried enabling the debug print?
It looks like after
    tn = telnetlib.Telnet(server,port)
you should be able to turn on the debug messages by
    tn.debuglevel = 1
or
    tn.set_debuglevel(1)

Then you can see if any of the above are arriving.
Make the the opt => c change first.

It's not clear to me that it's generally advisable to ignore
all the command codes telnetlib.py ignores (which is the apparent
effect of the self.msg() call), but that will depend on what
you are communicating with, and what you're doing with it, I suppose.

Where is the mystery telnetlib.py author? ;-)

Regards,
Bengt Richter