Re: Bug #14967: getaddrinfo(NULL) with AI_PASSIVE wrong AF order -is the proposed fix feasible?

["Ruslan N. Marchenko" <me at ruff dot mobi>]

On Wed, Mar 06, 2013 at 02:54:35PM -0500, Carlos O'Donell wrote:
> On 03/06/2013 02:21 PM, Ruslan N. Marchenko wrote:
> > Hi,
> > 
> > I've recently faced with the problem that getaddrinfo(NULL, srv, {
> > AI_PASSIVE | AI_V4MAPPED, AF_UNSPEC},ret) returns address families in
> > the wrong order - INET,INET6 instead of INET6,INET - on dualstack
> > host.
> > 
> > Googling further I've trapped on several existing bugs raised
> > different times and bug 14967 in particular (I've attached other
> > relevant from my point urls the the bug).
> > 
> > Debugging it with GDB revealed problem to be related to the way how
> > address validation is performed and the fact that this validation
> > (connect()-based) is not very suitable for AI_PASSIVE call (intended
> > for bind()).
> > 
> > I've written and tested patch (attached to the case) and implemented
> > ugly workaround in my code (simple reordering of the result). Now i
> > wonder - if this bug is on the radar, whether it has other known and
> > planned to implement solution, and if I can expect it to be fixed in
> > some nearest future (which will obsolete implemented workaround)  or
> > everyone is happy with the current state of art and each custome
> > workaround is a personal tragedy of anyyone impacted?
> 
> Fixing dualstack hosts in definately on our radar. We know that this
> is a serious issue for developers.
> 

Thanks Carlos for clarifying the bigger picture

> I am committed to making this considerably better in Fedora 19, which
> means we'll be working on this in the next 3-4 months.
> 
> You can see the proposal here:
> https://fedoraproject.org/wiki/Features/FixNetworkNameResolution?rd=Features/FixDualProtocolNameResolution
> 
> Please feel free to add BZ#'s to that wiki page that are important
> to you. We need user feedback.
>
I'll try to contribute to the wider problem solution.

Regards,
Ruslan