Handling of LINEMODE_* commands in twisted.conch.telnet.Telnet

[pwegrzyn]

The problem I encounter can even be reproduced with demo_manhole.tac.

Pressing the Ctrl-D combination on the client side sends 0xFF 0xEC sequence, which leads to the following exception on the server side:

  File "/usr/lib/python2.7/dist-packages/twisted/internet/selectreactor.py", line 146, in _doReadOrWrite
    why = getattr(selectable, method)()
  File "/usr/lib/python2.7/dist-packages/twisted/internet/tcp.py", line 460, in doRead
    return self.protocol.dataReceived(data)
  File "/usr/lib/python2.7/dist-packages/twisted/conch/telnet.py", line 512, in dataReceived
    raise ValueError("Stumped", b)
exceptions.ValueError: ('Stumped', '\xec')

Looking at the source of dataReceived(), I guess that the following code should be modified:

                        elif b in (NOP, DM, BRK, IP, AO, AYT, EC, EL, GA):
                            self.state = 'data'
                            if appDataBuffer:
                                self.applicationDataReceived(''.join(appDataBuffer))
                                del appDataBuffer[:]
                            self.commandReceived(b, None)

Shouldn't the condition in the first line also accept LINEMODE_EOF, LINEMODE_SUSP and LINEMODE_ABORT ?

[exarkun]

Can you link to the reference for this option? The linemode specs I have read all sounded like they were suboptions to be negotiated, not top-level features of telnet.

[pwegrzyn]

Those commands are listed together with all the others in Stevens' "TCP/IP Illustrated Vol1" table 26.8 - that's why I assumed the treatment should be the same (obviously that's only a hint, not a reference).

The RFC1116 lists them in section 2.5:  http://tools.ietf.org/html/rfc1116#section-2.5

I'm not sure however if the commands are to be used by default - I'm puzzled about how is SLC command supposed to work. But I believe that SLC just deals with mappings, and in fact every linemode-capable telnet implementation should be prepared for receiving the commands mentioned in section 2.5. I might be wrong, of course - let me dig into RFCs a bit.

[exarkun]

Okay, that sounds right. Looking at RFC 1116 and the traceback, it appears that EOF handling is the problem that's showing up in the traceback in the ticket description. For actual linemode negotiation, the standard patterns of IAC WILL/WONT/DO/DONT LINEMODE and IAC SB LINEMODE ... are followed. It's the EOF control character that causes the problem.

That's somewhat nasty. I hope that a client would only send one of the new control characters after successfully negotiating with the server to do LINEMODE - can you confirm that is the case you encountered?

Even so, it means that the set of supported control characters stops being constant and becomes variable depending on which options have been negotiated. That means that just adding to the literal tuple being checked in the escaped state isn't the right solution. There needs to be a set of extra commands that are valid given the current negotiations.

Or the ValueError case could just become the command case and even commands that aren't specifically recognized could be fobbed off onto application code to deal with.

I'm not really sure which one of these solutions is superior.