Bug 56679 - telnet-0.17-18 does not work correctly with some servers
telnet-0.17-18 does not work correctly with some servers
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: telnet (Show other bugs)
7.1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
Ben Levenson
:
: 53551 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-11-24 07:08 EST by Juan Jose Amor
Modified: 2007-04-18 12:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-02-15 06:11:41 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Juan Jose Amor 2001-11-24 07:08:07 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [es] (X11; U; Linux 2.2.19BS1 i586)

Description of problem:
When I telnet to a Efficient Speedstream 5660 router, I can't see the
characters
I type. That is, the remote echo appears to be unactivated. With
telnet-0.17-10
this test is ok, and also by using other clients (telnet under MS Windows,
telnet included with Debian GNU/Linux...).

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. telnet to the router with telnet-0.17-18 installed.
2. No other steps required
	

Actual Results:  Remote echo appears to be unactivated.

Additional info:
Comment 1 ted_rule 2002-02-11 11:24:51 EST
This is almost certainly the same bug as something I've found on some RedHat 6.2
servers with the latest RH6.2 telnet security patch for telnet applied.

The bug is that the "telnetport" variable is not set to "1" under the default
conditions of talking to port 23.

Having hunted down the broken bit of code, I've managed to
repair the source and hence provide a fresh RPM for my use locally.
The variable 
which was formally ( confusingly ) called "telnetport" is now called
"initiaiteoptionneg" to more accurately reflect its function.

The essential part of commands.c fixed is the bit of code below,
with the full diff from previous release shown below.


BEFORE:

        if (portp == NULL) {
                portp = "telnet";
        } else if (*portp == '-') {
                portp++;
                telnetport = 1;
        }
        h_errno = 0;
        error = getaddrinfo(hostp, portp, &hints, &res0);

AFTER:

        if (portp == NULL) {
                portp = "telnet";
                initiateoptionneg = 1;
        } else if (*portp == '-') {
                portp++;
                initiateoptionneg = 1;
        }
        h_errno = 0;
        error = getaddrinfo(hostp, portp, &hints, &res0);

with the full diff from previous release below.

$ cat telnet-0.17-optionneg.patch 
diff -uNr netkit-telnet-0.17.orig/telnet/commands.c netkit-telnet-
0.17/telnet/commands.c
--- netkit-telnet-0.17.orig/telnet/commands.c   Mon Feb 11 14:15:36 2002
+++ netkit-telnet-0.17/telnet/commands.c        Mon Feb 11 14:24:51 2002
@@ -2379,9 +2379,10 @@
        hints.ai_flags = AI_CANONNAME;
        if (portp == NULL) {
                portp = "telnet";
+               initiateoptionneg = 1;
        } else if (*portp == '-') {
                portp++;
-               telnetport = 1;
+               initiateoptionneg = 1;
        }
        h_errno = 0;
        error = getaddrinfo(hostp, portp, &hints, &res0);
diff -uNr netkit-telnet-0.17.orig/telnet/externs.h netkit-telnet-
0.17/telnet/externs.h
--- netkit-telnet-0.17.orig/telnet/externs.h    Mon Feb 11 14:13:44 2002
+++ netkit-telnet-0.17/telnet/externs.h Mon Feb 11 14:28:45 2002
@@ -61,7 +61,7 @@
     flushout,          /* flush output */
     connected,         /* Are we connected to the other side? */
     globalmode,                /* Mode tty should be in */
-    telnetport,                /* Are we connected to the telnet port? */
+    initiateoptionneg, /* Do we initiate option negotiation? */
     In3270,            /* Are we in 3270 mode? */
     localflow,         /* Flow control handled locally */
     restartany,                /* If flow control, restart output on any charac
ter */
diff -uNr netkit-telnet-0.17.orig/telnet/telnet.c netkit-telnet-
0.17/telnet/telnet.c
--- netkit-telnet-0.17.orig/telnet/telnet.c     Mon Feb 11 14:13:44 2002
+++ netkit-telnet-0.17/telnet/telnet.c  Mon Feb 11 14:29:45 2002
@@ -75,7 +75,15 @@
        noasynchnet = 0,/* User specified "-noasynch" on command line */
        askedSGA = 0,   /* We have talked about suppress go ahead */
 #endif /* defined(TN3270) */
-       telnetport,
+
+       initiateoptionneg = 0,
+                       /* Do we initiate option negotiation? - default no */
+                       /* If we are connected to the default telnet port, */
+                       /* we initiate option negotiation, else we only act */
+                       /* passively and allow the server end to initiate */
+                       /* option negotiation */
+                       /* CLI params determine current behaviour */
+
        SYNCHing,       /* we are in TELNET SYNCH mode */
        flushout,       /* flush output */
        autoflush = 0,  /* flush output when interrupting? */
@@ -2144,7 +2152,7 @@
     }
 #endif /* defined(AUTHENTICATION) || defined(ENCRYPTION) */
 #   if !defined(TN3270)
-    if (telnetport) {
+    if (initiateoptionneg) {
 #if    defined(AUTHENTICATION)
        if (autologin)
                send_will(TELOPT_AUTHENTICATION, 1);
$ 
Comment 2 ted_rule 2002-02-15 05:01:31 EST
Note that one may be able to work round the situation ( slightly knunkily )with:

bash$ telnet 
telnet> open hostname -23

where the "-" sign in command-mode telnet command mode forces the telnet options
to be neogiated correctly. ( See telnet man page for an explanation. )
It transpires that this bit of code:


        } else if (*portp == '-') {
                portp++;
                telnetport = 1;
        }
        
means that telnet command-mode open obeys "inititate option negotiation" under
these circs, whereas the command line doesn't work. You can't use -23 on the
command line to get the same effect, as the command-line parsing is 'broken'
and assumes "-23" is some sort of unknown option rather than " try port 23
with options enabled".


Comment 3 Ralf Ertzinger 2002-02-15 06:11:36 EST
You can workaround on this one using the command line, too.
Do this:

>telnet foo -- -23

Comment 4 Harald Hoyer 2002-02-28 05:58:01 EST
already fixed in 0.17-20
Comment 5 Harald Hoyer 2002-02-28 05:58:43 EST
*** Bug 53551 has been marked as a duplicate of this bug. ***
Comment 6 Juan Jose Amor 2002-02-28 06:24:09 EST
Please, note that telnet-0.17-20 is not available as a update of Redhat Linux
7.1.
Comment 7 Harald Hoyer 2002-02-28 06:33:59 EST
you may rpm --rebuild on your 7.1, but I consider making an update errata.. thx
Comment 8 Pekka Savola 2002-03-12 17:26:47 EST
This was basically a dup of #52224.

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