Bug 1118723 - RFE: NSS module entry points for gethostbyname() that take an address family, and can return a scopeid
Summary: RFE: NSS module entry points for gethostbyname() that take an address family,...
Status: CLOSED DUPLICATE of bug 843054
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Carlos O'Donell
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2014-07-11 11:11 UTC by Lennart Poettering
Modified: 2016-02-04 16:02 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2016-02-04 16:02:22 UTC

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Sourceware 19565 None None None 2016-02-04 08:00:25 UTC

Description Lennart Poettering 2014-07-11 11:11:15 UTC
It's currently impossible for NSS modules to return useful IPv6 link-local addresses. To be useful they would have to be accompanied by a scope ID, which the gethostbyname4_r() entry point actually allows to pass back to glibc. However, this entry point is used by glibc only if no protocol is specified (more precisely AF_UNSPEC) when looking up the name via getaddinfo(). If a protocol is specified, then gethostbyname3_r() is invoked instead, which however doesn't allow the module to report a scopeid back.

This is a problem for all NSS modules that want to return Ipv6 link-local addresses, such as nss-mdns, and the new nss-mycontainers module that we recently added to systemd (which makes the names of all locally running OS containers resolvable via NSS).

THe problem manifests itself when these modules are used in combination with the "ping6" command. "ping6" uses getaddrinfo, bus rightly specifies AF_INET6 as protocol, which means glibc dispatches it to gethostbyname3_r, and thus no scopeid is available.

I figure what is needed is a gethostbyname5_r() entry point that takes an address family as input parameter, and allows returning a scopeid back. It would thus be a combination of the specific benefits of both gethostbyname3_r() and gethostbyname4_r().

Comment 1 Carlos O'Donell 2014-07-11 14:55:05 UTC

Thanks for the bug. Could you please provide a small test case for us so we have something concerte to use when we look at implementing this? It sound slike you already have a system semi-configured like this, and it would be nice if we could just crib your config notes.

Comment 2 Lennart Poettering 2014-07-17 18:00:38 UTC
A good test case for this is nss-myhostname, as shipped with current systemd.

The modules' purpose is to resolve the localhost name to all local addresses, including link local ones, with appropriate ifindex. With this module enabled in /etc/nsswitch.conf, I get this behaviour:

lennart@delta $ telnet delta
Trying fe80::2ed0:5aff:fe32:d0ea%wlp0s26u1u4i2...
telnet: connect to address fe80::2ed0:5aff:fe32:d0ea%wlp0s26u1u4i2: Connection refused
telnet: connect to address Connection refused

Here, "delta" is my own hostname. We see that it finds the IPv6 address of the local host, with the correct ifindex. That's because telnet does not specify a protocol when resolving the name, and hence the NSS module's gethostbyname4_r() is called, which can return the ifindex just fine. All is good. (of course the connection fails, because i have no telnet server running, but that's besides the point).

lennart@delta $ ping6 delta
connect: Invalid argument

This fails though, since ping6 actually specifies a protocol family when resolving the name (AF_INET6, of course), which means the NSS modules' gethostbyname3_r() is called instead, which cannot return the ifindex. ping6 tries to connect to the returned link-local Ipv6 address, which lacks an ifindex, which the kernel then refuses on connect() with EINVAL...

The current sources of nss-myhostname you find here:


(note that the version of this currently available in fedora is considerably different, but exposes the same behaviour here, so you can use that to test...)

Comment 3 Florian Weimer 2016-02-04 16:02:22 UTC

*** This bug has been marked as a duplicate of bug 843054 ***

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