conmand susceptible to telnet option negotiation loops

[GoogleCodeExporter]

What steps will reproduce the problem?

conmand was observed using ~15% of the CPU while its consoles were in a 
quiescent state.  conmand was configured with 16 consoles connecting to a new 
Appro GreenBlade via telnet.  Investigation of the network traffic revealed a 
telnet option negotiation loop between conmand and the GreenBlade.  (packet 
capture attached)

What is the expected output? What do you see instead?

After conmand responds to the DO BINARY command with WONT BINARY, it should 
consider that option state as disabled and ignore subsequent DONT BINARY 
commands that simply confirm this option state.  Instead, conmand replies with 
another WONT BINARY, which elicits another DONT BINARY ad infinitum.

What version of the software are you using? On what operating system?

conman-0.2.7
Linux 2.6.32-131.0.13.1chaos+2.gae8d65b.ch5.x86_64
Red Hat Enterprise Linux Server release 6.1 (Santiago)

Please provide any additional information below.

Selected output from running conmand in the foreground with debug enabled:

Connecting to <gb1:7001> for [foo].
Opened [foo] telnet: fd=8 host=gb1 port=7001 state=2.
INFO: Console [foo] connected to <gb1:7001>
Sent telnet cmd DO SUPPRESS GO AHEAD to console [foo].
Sent telnet cmd DO ECHO to console [foo].
Opened [foo] telnet: fd=8 host=gb1 port=7001 state=3.
Read 18 bytes from [foo].
Received telnet cmd WILL SUPPRESS GO AHEAD from console [foo].
Received telnet cmd WILL ECHO from console [foo].
Received telnet cmd DONT ECHO from console [foo].
Received telnet cmd DO BINARY from console [foo].
Sent telnet cmd WONT BINARY to console [foo].
Received telnet cmd WILL SUPPRESS GO AHEAD from console [foo].
Received telnet cmd WILL ECHO from console [foo].
Read 3 bytes from [foo].
Received telnet cmd DONT BINARY from console [foo].
Sent telnet cmd WONT BINARY to console [foo].
Read 3 bytes from [foo].
Received telnet cmd DONT BINARY from console [foo].
Sent telnet cmd WONT BINARY to console [foo].
Read 3 bytes from [foo].
Received telnet cmd DONT BINARY from console [foo].
Sent telnet cmd WONT BINARY to console [foo].
...

Original issue reported on code.google.com by chris.m.dunlap on 18 May 2011 at 1:38

Attachments:

• conmand.telnet.opt.loop.pcap

[GoogleCodeExporter]

This issue was updated by revision r1070.

Created issue-9 branch.

Original comment by chris.m.dunlap on 29 Sep 2011 at 7:05

• Changed state: Started

[GoogleCodeExporter]

Selected output from running conmand after r1071:

Connecting to <gb1:7001> for [foo].
Opened [foo] telnet: fd=10 host=gb1 port=7001 state=2.
INFO: Console [foo] connected to <gb1:7001>
Sent telnet cmd DO BINARY to console [foo].
Sent telnet cmd DO ECHO to console [foo].
Sent telnet cmd DO SUPPRESS GO AHEAD to console [foo].
Sent telnet cmd WILL BINARY to console [foo].
Sent telnet cmd WILL SUPPRESS GO AHEAD to console [foo].
Opened [foo] telnet: fd=10 host=gb1 port=7001 state=3.
Wrote 15 bytes to [foo].
Read 27 bytes from [foo].
Received telnet cmd WILL SUPPRESS GO AHEAD from console [foo].
Received telnet cmd WILL ECHO from console [foo].
Received telnet cmd DONT ECHO from console [foo].
Received telnet cmd DO BINARY from console [foo].
Received telnet cmd WILL BINARY from console [foo].
Received telnet cmd WILL ECHO from console [foo].
Received telnet cmd WILL SUPPRESS GO AHEAD from console [foo].
Received telnet cmd DO BINARY from console [foo].
Received telnet cmd DONT SUPPRESS GO AHEAD from console [foo].

Original comment by chris.m.dunlap on 30 Sep 2011 at 9:26

[GoogleCodeExporter]

This issue was closed by revision r1072.

Original comment by chris.m.dunlap on 30 Sep 2011 at 9:57

• Changed state: Fixed

[GoogleCodeExporter]

Just adding notes I made along the way in case I need to refer back to this.

The following packet numbers apply to the tcpdump capture file
attachment "conmand.telnet.opt.loop.pcap":

#4: sent by conmand

  Do Suppress Go Ahead

  Do Echo

#6: sent by GreenBlade

  Will Suppress Go Ahead

  Will Echo

  Don't Echo
  * The default state of the telnet "network virtual terminal" does
    not echo characters.  Parties may only request a change in option
    status (RFC 854 section 3A).  Consequently, this "Don't Echo"
    should not have been sent by the GreenBlade.

  Do Binary Transmission

  Will Suppress Go Ahead
  * The GreenBlade has already sent this acknowledgment earlier in
    packet #6.  Parties may only request a change in option status
    (RFC 854 section 3A).  Consequently, this additional "Will Suppress
    Go Ahead" should not have been sent by the GreenBlade.

  Will Echo
  * The GreenBlade has already sent this acknowledgment earlier in
    packet #6.  Parties may only request a change in option status
    (RFC 854 section 3A).  Consequently, this additional "Will Echo"
    should not have been sent by the GreenBlade.

#8: sent by conmand

  Won't Binary Transmission

#9: sent by GreenBlade

  Don't Binary Transmission
  * Strictly speaking, this first request is superfluous, but
    subsequent requests (eg, packet #11) perpetuate a nonterminating
    acknowledgment loop.  One must not initiate a Don't/Won't
    negotiation for a disabled option, or respond to the receipt of
    such a negotiation (RFC 1143 section 2).  That RFC goes on to
    note that many implementations improperly respond to rejections
    by confirming the rejection (section 2 discussion).  Upon receipt
    of the "Won't Binary Transmission", the GreenBlade should update
    its internal option state without sending the "Don't Binary
    Transmission" to confirm.

#10: sent by conmand

  Won't Binary Transmission
  * A party should not acknowledge a request to enter a mode it
    is already in (RFC 854 section 3B).  Since conmand denied this
    option in packet #8, it should ignore this request without sending
    further acknowledgements.

#11: sent by GreenBlade

  Don't Binary Transmission
  * The nonterminating acknowledgment loop has now run amok.

Original comment by chris.m.dunlap on 6 Oct 2011 at 8:12