Bug 52224 - telnet-0.17-18 broken vs. telnet-0.17-10 telnetting to HP switch (possibly others)
telnet-0.17-18 broken vs. telnet-0.17-10 telnetting to HP switch (possibly ot...
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: telnet (Show other bugs)
7.1
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
David Lawrence
:
: 52817 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-08-21 15:42 EDT by jon
Modified: 2007-04-18 12:36 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-09-01 06:11:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
several small fixes to telnet client (1.11 KB, patch)
2001-09-01 06:11 EDT, Pekka Savola
no flags Details | Diff

  None (edit)
Description jon 2001-08-21 15:42:49 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:
Comment 1 Pekka Savola 2001-08-30 07:12:43 EDT
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.
Comment 2 Pekka Savola 2001-08-30 07:31:18 EDT
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/ ]

Comment 3 Harald Hoyer 2001-08-30 10:57:32 EDT
*** Bug 52817 has been marked as a duplicate of this bug. ***
Comment 4 jon 2001-08-30 11:46:52 EDT
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.
Comment 5 Pekka Savola 2001-08-31 02:54:31 EDT
I hope I have time to look at it at some point (perhaps this weekend) -- please
send the 
info by email.
Comment 6 Pekka Savola 2001-09-01 04:22:05 EDT
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...
Comment 7 Pekka Savola 2001-09-01 06:10:45 EDT
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.
Comment 8 Pekka Savola 2001-09-01 06:11:27 EDT
Created attachment 30498 [details]
several small fixes to telnet client
Comment 9 Harald Hoyer 2001-09-06 03:35:44 EDT
integrated in telnet-0.17-20

Note You need to log in before you can comment on or make changes to this bug.