I am starting this bug report to track dualstack networking problems, and especially getaddrinfo() usage in various packages. I'm also going to add several bug reports on getaddrinfo() itself that affect a lot of other packages. I've started up a Fedora Wiki page to cover this topic: https://fedoraproject.org/wiki/Networking/NameResolution
Fedora Feature (not submitted yet): https://fedoraproject.org/wiki/Features/DualstackNetworking
ping is not IPv6 compatible - instead IPv6 functions are outsourced to ping6. How to create a bug for that and "attach" this tracker bug?
(In reply to comment #2) > ping is not IPv6 compatible - instead IPv6 functions are outsourced to ping6. > > How to create a bug for that and "attach" this tracker bug? There is no need for a bug because it is not one. I would just delete the line that mentions ping from the feature page.
(In reply to comment #3) > There is no need for a bug because it is not one. I would just delete the > line that mentions ping from the feature page. It is a bug but it was decided two years ago that it won't be fixed because upstream is non-responsive: https://bugzilla.redhat.com/show_bug.cgi?id=617934#c2 Maybe it's time to revisit that decision but we certainly shouldn't flood this bug with specific package discussion any more.
> we certainly shouldn't flood this bug with specific package discussion any more. Agreed. Please continue to bug #617934.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
For those interested about various problems with dualstack networking and libc name resolution, there's a new project that has been announced on the libc-alpha mailing list: https://sourceware.org/ml/libc-alpha/2013-11/msg00219.html Updated README and TODO files can be always found at: https://sourceware.org/git/?p=netresolve.git;a=blob;f=README;hb=HEAD https://sourceware.org/git/?p=netresolve.git;a=blob;f=TODO;hb=HEAD The project aims to improve name resolution and dualstack via providing... * Testing tools for `getaddrinfo()` and similar * Alternative implementation of `getaddrinfo()` * Extended name resolution query API * Nonblocking API based on file descriptors * Socket API with happy eyeballs It's in alpha stage but it can already serve as a source of inspiration as well as for initial testing. https://sourceware.org/git/?p=netresolve.git;a=summary
Are you aware of http://www.vpnc.org/getdns-api/ It seems that is what the browser people are looking at for a new DNS API
(In reply to Paul Wouters from comment #8) > Are you aware of http://www.vpnc.org/getdns-api/ > > It seems that is what the browser people are looking at for a new DNS API I was not aware of this, but that looks like an interesting solution. We should try to use that in testing for glibc.
(In reply to Carlos O'Donell from comment #9) > (In reply to Paul Wouters from comment #8) > > Are you aware of http://www.vpnc.org/getdns-api/ > > > > It seems that is what the browser people are looking at for a new DNS API > > I was not aware of this, but that looks like an interesting solution. > > We should try to use that in testing for glibc. ... that is whenever they get a real implementation and not just an API draft.
(In reply to Carlos O'Donell from comment #10) > (In reply to Carlos O'Donell from comment #9) > > (In reply to Paul Wouters from comment #8) > > > Are you aware of http://www.vpnc.org/getdns-api/ > > > > > > It seems that is what the browser people are looking at for a new DNS API > > > > I was not aware of this, but that looks like an interesting solution. New for me as well, thanks! I'll certainly look at it an will implement it as one of the netresolve wrappers if it looks reasonable. > > We should try to use that in testing for glibc. > > ... that is whenever they get a real implementation and not just an API > draft. Actually we already have a real implementation with netresolve, we can just provide the API as one of the possibilities, as I'm already doing with traditional libc APIs and others.
*** Bug 1220694 has been marked as a duplicate of this bug. ***
This tracker bug has been combined with IPv6 sanity tracker. Thus this tracker will follow applications which are not IPv6-ready. The description of the IPv6 sanity tracker follows. "There are applications which are not IPv6 ready or provide IPv6 functionality through an external tool. That is a relic of the past, we still drag. IPv6 support should be transparent in programs, and programs should be modified to auto-detect IPv4 or IPv6 addresses and perform the expected actions."
(In reply to Nikos Mavrogiannopoulos from comment #13) > This tracker bug has been combined with IPv6 sanity tracker. Thus this > tracker will follow applications which are not IPv6-ready. The description > of the IPv6 sanity tracker follows. > > "There are applications which are not IPv6 ready or provide IPv6 > functionality through an external tool. That is a relic of the past, we > still drag. > > IPv6 support should be transparent in programs, and programs should be > modified to auto-detect IPv4 or IPv6 addresses and perform the expected > actions." Thanks! And the original links also don't apply any more. Everyone please refer to the following link: https://fedoraproject.org/wiki/QA/Networking