You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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].
...
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 withWONT BINARY
, it shouldconsider that option state as disabled and ignore subsequent
DONT BINARY
commands that simply confirm this option state. Instead, conmand replies with anotherWONT BINARY
, which elicits anotherDONT 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:
conmand.telnet.opt.loop.pcap.gz
Original issue reported on code.google.com by
chris.m.dunlap
on 18 May 2011 at 1:38The text was updated successfully, but these errors were encountered: