This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 135125 - telnet: 0: Name or service not known
telnet: 0: Name or service not known
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: glibc (Show other bugs)
3.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-08 16:34 EDT by Mike Batchelor
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-18 09:59:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Mike Batchelor 2004-10-08 16:34:36 EDT
Description of problem: "telnet 0 25" does not connect to
localhost:25. Instead it throws an error "0: Name or service no known".

Version-Release number of selected component (if applicable):
telnet-0.17-26.i386.rpm

How reproducible: fails every time


Steps to Reproduce:
1. telnet 0 25
2. weep
3. weep some more
  
Actual results:
telnet: 0: Name or service not known

Expected results:
Trying 0.0.0.0...
Connected to 0.0.0.0.
Escape character is '^]'.
220 hostname ESMTP Sendmail 8.12.10/8.12.10; Fri, 8 Oct 2004 13:36:17
-0700

Additional info:
For the past - Oh, I don't know, two decades? - 0 resolves to
127.0.0.1, and so "telnet 0 25" would connect to the local machine's
smtp server, or "telnet 0 80" connects to the local HTTP server.  Not
so in RHEL3.  WTF?
Comment 1 Harald Hoyer 2004-10-11 04:31:27 EDT
please provide:
$ which telnet
and do you have ipv6 enabled?
Comment 2 Mike Batchelor 2004-10-11 12:42:25 EDT
ipv6 is not enabled.  Turns out the telnet in my path was
/usr/kerberos/bin/telnet, but /usr/bin/telnet returns the same error.
I believe this is not a bug in telnet after all, but glibc's
gethostbyname().  In fact, it looks like this was broken intentionally
in the glibc 2.3 series, for some reason.  gethostbyname() no longer
resolves undotted decimal addresses, or hexadecimal or octal
addresses.  It used to, but not anymore. "telnet 0 25" is one of the
casualties.
Comment 4 Jakub Jelinek 2005-01-20 06:30:41 EST
Both gethostname ("0") and getaddrinfo ("0", NULL, NULL, &res);
return the same thing as they used to.
So the change is not in glibc.
Comment 5 Harald Hoyer 2005-01-20 06:36:31 EST
well, nothing change in the source code of telnet
Comment 6 Harald Hoyer 2005-01-20 07:41:59 EST
Retested. Works for me on a RHEL3-U3...
Comment 7 Harald Hoyer 2005-01-20 07:44:07 EST
doh... fell in the trap... tested with /usr/kerberos/bin/telnet (which works)
/usr/bin/telnet failed like described in the bug report.
Comment 8 Harald Hoyer 2005-01-20 07:57:49 EST
With a RHEL3-U4 glibc:

getaddrinfo("0", "25", 0xbfffe250, 0xbfffd9e4)   = -2
gai_strerror(-2)                                 = "Name or service not known"
Comment 9 Jakub Jelinek 2005-01-20 11:38:31 EST
Ok, this seems to be http://sources.redhat.com/bugzilla/show_bug.cgi?id=296
Comment 10 Jakub Jelinek 2005-02-15 01:49:36 EST
Should be fixed in glibc-2.3.2-95.32.
Comment 11 Tim Powers 2005-05-18 09:59:56 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2005-256.html

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