Problem with telnetlib dropping receive bytes.

[Grant Edwards]

I'm writing an app that uses telnetlib, and I'm having problems
with bytes missing from the data stream received by my app. At
first I assumed it was a bug in either the server or my app.
When I couldn't find anything wrong with either, I finally
looked at telnetlib.py, and found this:

419 def process_rawq(self):
420 """Transfer from raw queue to cooked queue.
421
422 Set self.eof when connection is closed. Don't block unless in
423 the midst of an IAC sequence.
424
425 """
426 buf = ['', '']
427 try:
428 while self.rawq:
429 c = self.rawq_getchar()
430 if not self.iacseq:
431 if c == theNULL:
432 continue
433 if c == "\021":
434 continue
435 if c != IAC:
436 buf[self.sb] = buf[self.sb] + c
437 continue
438 else:
439 self.iacseq += c

Why are NUL and DC1 characters being deleted from the recieve
data stream at lines 431 and 433? They're both perfectly legal
characters. I can't find anywhere in RFC 854 where it says to
do that, and it's breaking my program. Some of the other
telnet features (e.g. RFC 2217) specifically use those two byte
values.

 

[Eddie Corns]

Why are NUL and DC1 characters being deleted from the recieve
data stream at lines 431 and 433? They're both perfectly legal
characters. I can't find anywhere in RFC 854 where it says to
do that, and it's breaking my program. Some of the other
telnet features (e.g. RFC 2217) specifically use those two byte
values.

Looks like a bug to me. Telnet requires that ALL 7 bit characters can be
used. Since it's all handled in Python I can't think of any reason why
those characters would be a problem.

Eddie

 

[Grant Edwards]

Looks like a bug to me. Telnet requires that ALL 7 bit
characters can be used. Since it's all handled in Python I
can't think of any reason why those characters would be a
problem.

That's what I thought, but since somebody went out of their way
to drop those two characters, I thought I'd better check. I'll
submit a patch once I've spent some more time with telnetlib.