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