Home Original page

Problems with telnetlib

Bengt Richter bokr at oz.net
Wed Feb 20 16:49:18 EST 2002 
On Tue, 19 Feb 2002 08:05:27 -0800, John Baxter <jwbaxter at spamcop.net> wrote:

>In article <a4t9fr$500$1 at odysseus.uci.kun.nl>,
> "Patrick Vrijlandt" <p.vrijlandt at aig.azn.nl> wrote:
>
>> Although telnetlib seems rather buggy, there is not much request for
>> improvement on c.l.py, so I think it is barely used, or
>> it works fine with most servers.
>
>Well, telnetlib works for the limited purposes we use it for here.  Or 
>does it?  I found the cause (in my code) of fairly frequent false alarms 
>in a monitor I wrote using it, but we still have infrequent false alarms 
>which I haven't yet understood.
>
>  --John
Looking at the rfc, I wonder if the following should be implemented.
It seems to be required for the base level NVT mode with no options:

"""...
         Note that "CR LF" or "CR NUL" is required in both directions
Postel & Reynolds                                              [Page 11]
RFC 854                                                         May 1983
         (in the default ASCII mode), to preserve the symmetry of the
         NVT model.  Even though it may be known in some situations
         (e.g., with remote echo and suppress go ahead options in
         effect) that characters are not being sent to an actual
         printer, nonetheless, for the sake of consistency, the protocol
         requires that a NUL be inserted following a CR not followed by
         a LF in the data stream.  The converse of this is that a NUL
         received in the data stream after a CR (in the absence of
         options negotiations which explicitly specify otherwise) should
         be stripped out prior to applying the NVT to local character
         set mapping.
..."""

On the receive side, dropping nulls in effect does implement it, but the
write side in telnelib.py only doubles IACs.

Also, I didn't see any rfc policy for throwing away ^Q ("\021").
Is that possibly a forgotten expedient test hack?

Regards,
Bengt Richter
More information about the Python-list mailing list