gethostbyname doesn't accept IPv6 addresses
trustee
the gethostbyname manpage says that you can pass an IPv6 address to
it.
"... Here name is either a host name, or an IPv4 address in standard
dot notation, or an IPv6 address in colon (and possibly dot) notation.
(See RFC 1884 for the description of IPv6 addresses.)"
But calls like this fail on my system (return value = NULL):
gethostbyname("::1");
gethostbyname("2001:200:0:8002:203:47ff:fea5:3085"); // www.kame.net
Alternative functions like getaddrinfo or gethostbyname*2* can handle
these addresses.
Is this an error in the manpage or what could be the problem?
Kernel version: 2.6.26-2
Bye.
Ersek, Laszlo
> But calls like this fail on my system (return value = NULL):
>
> gethostbyname("::1");
> gethostbyname("2001:200:0:8002:203:47ff:fea5:3085"); // www.kame.net
Two problems:
1) Those arguments are not names. They are addresses.
2) "The gethostbyname() function shall return an entry containing
addresses of address family AF_INET for the host with name name."
http://www.opengroup.org/onlinepubs/000095399/functions/gethostbyname.html
You are after AF_INET6.
Ulrich Drepper wrote a great tutorial.
http://people.redhat.com/drepper/userapi-ipv6.html
Cheers,
lacos
Barry Margolin
wrote:
> In article
> <e8e1cb1d-9693-4803...@j27g2000yqn.googlegroups.com>, trustee
> <tru...@arcor.de> writes:
>
> > But calls like this fail on my system (return value = NULL):
> >
> > gethostbyname("::1");
> > gethostbyname("2001:200:0:8002:203:47ff:fea5:3085"); // www.kame.net
>
> Two problems:
> 1) Those arguments are not names. They are addresses.
So? He quoted a sentence from the documentation that said that the
argument can be either a name, an IPv4 address, or an IPv6 address.
> 2) "The gethostbyname() function shall return an entry containing
> addresses of address family AF_INET for the host with name name."
>
> http://www.opengroup.org/onlinepubs/000095399/functions/gethostbyname.html
His question was about Linux, not POSIX. POSIX says that the behavior
is undefined if the argument is a numeric string, and Linux apparently
defines this to parse the address and return it.
>
> You are after AF_INET6.
He knows that, he said that gethostbyaddr2() does it right. But the man
page says that gethostbyaddr() should also work.
>
> Ulrich Drepper wrote a great tutorial.
>
> http://people.redhat.com/drepper/userapi-ipv6.html
>
> Cheers,
> lacos
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Ersek, Laszlo
Barry Margolin <bar...@alum.mit.edu> writes:
> In article <Njkdss1D7FSs@ludens>, la...@ludens.elte.hu (Ersek, Laszlo)
> wrote:
>
>> Two problems:
>> 1) Those arguments are not names. They are addresses.
>
> So? He quoted a sentence from the documentation that said that the
> argument can be either a name, an IPv4 address, or an IPv6 address.
>
>> 2) "The gethostbyname() function shall return an entry containing
>> addresses of address family AF_INET for the host with name name."
>>
>> http://www.opengroup.org/onlinepubs/000095399/functions/gethostbyname.html
>
> His question was about Linux, not POSIX. POSIX says that the behavior
> is undefined if the argument is a numeric string, and Linux apparently
> defines this to parse the address and return it.
In general, I don't trust Linux manual pages -- not even for Linux. For
example, on my Debian Lenny desktop, there is
Package: manpages-dev
Version: 3.05-1
Description: Manual pages about using GNU/Linux for development
These man pages describe the Linux programming interface, including
these two sections:
2 = Linux system calls.
(Many lines snipped for brevity.)
Then,
$ man 2 write
----v----
WRITE(2) Linux Programmer's Manual WRITE(2)
NAME
write - write to a file descriptor
[...]
Linux 2007-06-18 WRITE(2)
----^----
The manual page does not contain a single instance of the word
"SIGXFSZ", even though Linux *does* generate SIGXFSZ for the thread when
appropriate.
... Additionally, I just checked the glibc manual on this same system.
It bears no mention of SIGXFSZ in write()'s description either.
(Low-Level I/O | I/O Primitives.)
FreeBSD distributes (parts of) SUSv3.
http://www.opengroup.org/press/01jun04.htm
(I'm not bashing the people maintaining the glibc or the Linux
documentation. It's obvious that with limited resources, making the
implementation standards-conformant is more important than making the
decomentation implementation-conformant. I'm only saying, when one tries
to write portable code, it's more fruitful to check the POSIX docs for
Linux than to check the Linux docs themselves.)
Cheers,
lacos
Ersek, Laszlo
> In article <barmar-C06191....@news.eternal-september.org>,
> Barry Margolin <bar...@alum.mit.edu> writes:
>> In article <Njkdss1D7FSs@ludens>, la...@ludens.elte.hu (Ersek, Laszlo)
>> wrote:
>>
>>> Two problems:
>>> 1) Those arguments are not names. They are addresses.
>>
>> So? He quoted a sentence from the documentation that said that the
>> argument can be either a name, an IPv4 address, or an IPv6 address.
>>
>>> 2) "The gethostbyname() function shall return an entry containing
>>> addresses of address family AF_INET for the host with name name."
>>>
>>> http://www.opengroup.org/onlinepubs/000095399/functions/gethostbyname.html
>>
>> His question was about Linux, not POSIX. POSIX says that the behavior
>> is undefined
unspecified
>> if the argument is a numeric string, and Linux apparently
>> defines this to parse the address and return it.
>
> In general, I don't trust Linux manual pages -- not even for Linux.
>
> [snip]
>
> (I'm not bashing the people maintaining the glibc or the Linux
> documentation. It's obvious that with limited resources, making the
> implementation standards-conformant is more important than making the
> decomentation implementation-conformant. I'm only saying, when one tries
> to write portable code, it's more fruitful to check the POSIX docs for
> Linux than to check the Linux docs themselves.)
Case in point, a google search of
gethostbyname glibc IPv6
turned up, as second hit, Debian Bug report #455762, from two years ago:
"[libc6] gethostbyname fails on IPv6 addresses"
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=455762
----v----
Tags: ipv6, upstream, wontfix
Found in version glibc/2.7-4
Forwarded to http://sourceware.org/bugzilla/show_bug.cgi?id=5479
----^----
It's instructive what the upstream maintainer thinks of the issue.
----v----
This never worked, people hardly ever use mapped addresses, and
gethostby* should not *EVER* be used in the first place. Anything to
get people away from gethostby* is a good thing.
----^----
The implementation is POSIX conformant, and the manual page is borked.
Cheers,
lacos
Jens Thoms Toerring
> In general, I don't trust Linux manual pages -- not even for Linux. For
> example, on my Debian Lenny desktop, there is
> Package: manpages-dev
> Version: 3.05-1
> Description: Manual pages about using GNU/Linux for development
> These man pages describe the Linux programming interface, including
> these two sections:
> 2 = Linux system calls.
> (Many lines snipped for brevity.)
> Then,
> $ man 2 write
> ----v----
> WRITE(2) Linux Programmer's Manual WRITE(2)
> NAME
> write - write to a file descriptor
> [...]
> Linux 2007-06-18 WRITE(2)
> ----^----
> The manual page does not contain a single instance of the word
> "SIGXFSZ", even though Linux *does* generate SIGXFSZ for the thread when
> appropriate.
If you find such problems you shouldn't hesitate to send an email
to Michael Kerrisk, the Linux man page maintainer, see
http://www.kernel.org/doc/man-pages/reporting_bugs.html
When I reported a few minor issues I got an immediate reply from
him - and, after a pleasant discussion, in the next release of
the man pages they were gone.
But, of course, you should also consider downloading the newest
version of the man pages first as a man page from 2007 can be a
bit outdated - the current version is 3.24, 3.01 is more than
1.5 years old. You can get the current version from
http://www.kernel.org/pub/linux/docs/man-pages/
> (I'm not bashing the people maintaining the glibc or the Linux
> documentation. It's obvious that with limited resources, making the
> implementation standards-conformant is more important than making the
> decomentation implementation-conformant.
Also, unfortunately, the guys doing the documentation may not always
get informed of relevant changes (and going through the sources each
time a modification is made to find out if the documentation requires
an update could be quite a task, I guess...).
Best regards, Jens
--
\ Jens Thoms Toerring ___ j...@toerring.de
\__________________________ http://toerring.de
Ersek, Laszlo
> If you find such problems you shouldn't hesitate to send an email
> to Michael Kerrisk, the Linux man page maintainer, see
>
> http://www.kernel.org/doc/man-pages/reporting_bugs.html
Will do right away; thanks. Honestly, this is the constructive attitude,
not just bickering around :)
> But, of course, you should also consider downloading the newest
> version of the man pages first as a man page from 2007 can be a
> bit outdated - the current version is 3.24, 3.01 is more than
> 1.5 years old. You can get the current version from
>
> http://www.kernel.org/pub/linux/docs/man-pages/
The "reporting bugs" page you've linked to above has an anchor named
"online pages" -- I just checked write(2) from 2009-02-23 and
gethostbyname(3) from 2009-12-03, and they still have the problems in
question.
Thanks for the hint,
lacos
Ersek, Laszlo
> If you find such problems you shouldn't hesitate to send an email
> to Michael Kerrisk, the Linux man page maintainer
http://www.spinics.net/lists/linux-man/msg01242.html
http://www.spinics.net/lists/linux-man/msg01243.html
Thank you,
lacos
Rick Jones
portable across operating systems. I would strongly suggest you
convert your code to use getaddrinfo/getnodeinfo.
rick jones
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
trustee
thanks for your comments so far. :-)
I decided to take a look at the implementation of the gethostbyname
function.
And what I found really confused me: It is implemented exactly how the
manpage describes it.
glibc-2.7\resolv\gethnamaddr.c
struct hostent *
gethostbyname(name)
const char *name;
{
struct hostent *hp;
if (__res_maybe_init (&_res, 0) == -1) {
__set_h_errno (NETDB_INTERNAL);
return (NULL);
}
if (_res.options & RES_USE_INET6) {
hp = gethostbyname2(name, AF_INET6);
if (hp)
return (hp);
}
return (gethostbyname2(name, AF_INET));
}
Note: The RES_USE_INET6 flag is set when you add "options inet6" to /
etc/resolv.conf and was already set during my gethostbyname tests.
I will try to build glibc myself and add debug statements to see if
this is the function that really gets called.
trustee
called.
The real gethostbyname is automatically generated by the preprocessor
in the files inet/gethstbynm.c, nss/getXXbyYY.c and nss/getXXbyYY_r.c.
IP parsing is done in nss/digits_dots.c.
I could make it accept IPv6 addresses by changing AF_INET to AF_INET6
in the following code. But after that it won't accept IPv4
addresses. ;-)
nss/getXXbyYY.c
#ifdef HAVE_AF
# define AF_VAL af
#else
# define AF_VAL AF_INET
#endif
Bye.
Rick Jones
rick jones
--
a wide gulf separates "what if" from "if only"
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
trustee
I have written two classes, one with getaddrinfo and one with
gethostbyname.
I implemented the gethostbyname stuff only for fun, i know that it is
not recommended nowadays. :)