Red Hat Bugzilla – Bug 52224
telnet-0.17-18 broken vs. telnet-0.17-10 telnetting to HP switch (possibly others)
Last modified: 2007-04-18 12:36:07 EDT
From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) Description of problem: telnet-0.17-10 worked fine when telnetting into my HP switches (ProCurve 4000M), which use a menu-driven interface where you use the arrow keys to select options (i.e. they're not just plain text, they are using vt100 emulation to display highlighting, etc.). telnet-0.17-18 does not work fine--when you log in, the menu is displayed, but the highlighted bar doesn't move when arrow keys are pressed and it's essentially worthless; you are typing blind. I build netkit-telnet-0.17 from the source on ftp.uk.linux.org and it is not broken in this way. Also I tried sequentially applying the patches, and it appears that the telnet-client-cvs.patch is the one that breaks it. The other patches have no effect regarding this issue. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Install telnet-0.17-18, or take the pristine source and apply telnet- client-cvs.patch 2. Telnet to a device heavily using vt100 controls, tested on an HP ProCurve 4000M (HP J4121A) 3. Try to use the management interface. Additional info:
I smell a problem in patched telnet.c ("setupterm") or possible sys_bsd.c. Too bad I can't reproduce the problem on my "visiually-enhanced" network switches. Have you tried setting TERM variable to e.g. vt100, vt102 or cons25l1 before telnetting? If you like to experiment, backing out some changed in telnet.c to be able to pinpoint the problem would help.
More specifically, I think: commits 1.9 and 1.10 of telnet.c and 1.8 of sys_bsd.c may have caused this; [ http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/telnet/ ]
*** Bug 52817 has been marked as a duplicate of this bug. ***
TERM is set to vt100. Setting to vt102 or cons2511 has no effect. I may find some time to play with telnet.c more, but if someone really wants to get in and fix it, I can set up a dummy switch with a globally accessable IP that you can work with.
I hope I have time to look at it at some point (perhaps this weekend) -- please send the info by email.
The problem appears to be that telnet options aren't negotiated properly. This is triggered by some change (nothing obvious) in commands.c (other cvs changes are ok). Working (no commands.c changes): 11:21:42.831268 193.94.160.1.1948 > 131.252.134.252.telnet: P [tcp sum ok] 1:25(24) ack 1 win 32696 [telnet DO SUPPRESS GO AHEAD, WILL TERMINAL TYPE, WILL NAWS, WILL TSPEED, WILL LFLOW, WILL LINEMODE, WILL NEW-ENVIRON, DO STATUS] (DF) (ttl 64, id 3502, len 64) 11:21:43.064089 131.252.134.252.telnet > 193.94.160.1.1948: P [tcp sum ok] 1:4(3) ack 1 win 4096 [telnet DO TERMINAL TYPE] (ttl 41, id 1384, len 43) 11:21:43.064171 193.94.160.1.1948 > 131.252.134.252.telnet: . [tcp sum ok] 25:25(0) ack 4 win 32696 (DF) (ttl 64, id 3504, len 40) 11:21:43.076228 131.252.134.252.telnet > 193.94.160.1.1948: . 4:516(512) ack 1 win 4096 [telnet WILL ECHO] (ttl 41, id 1386, len 552) Not working (commands.c changed -- note! triggered by the server): 11:20:38.389774 131.252.134.252.telnet > 193.94.160.1.1947: . 122:634(512) ack 1 win 4096 [telnet DO TERMINAL TYPE, WILL ECHO] (ttl 41, id 1372, len 552) 11:20:38.390323 193.94.160.1.1947 > 131.252.134.252.telnet: P [tcp sum ok] 1:7(6) ack 634 win 32696 [telnet WILL TERMINAL TYPE, DO ECHO] (DF) (ttl 64, id 3170, len 46) Still checking...
This is also a problem in upstream; will notify. The fix is: --- telnet/commands.c Sat Sep 1 12:55:18 2001 +++ telnet.new/commands.c Sat Sep 1 12:54:36 2001 @@ -2354,6 +2354,7 @@ hints.ai_flags = AI_CANONNAME; if (portp == NULL) { portp = "telnet"; + telnetport = 1; } else if (*portp == '-') { portp++; A couple of other fixes also in the attached.
Created attachment 30498 [details] several small fixes to telnet client
integrated in telnet-0.17-20