OpenBSD 4.4 gnutls-serv IPv6 Only Bug

[Simon Josefsson]

Peter Hendrickson <pdh at wiredyne.com> writes:

>> > Yes, but it's somewhat complicated, you have to create a socket for each 
>> > returned addrinfo structure, bind them all, set them non-blocking, and 
>> > then poll across them to wait for a connection, and cope with the edge 
>> > cases with v6-mapped IPv4 addresses which make it not that simple.
>> 
>> I tried to implement that:
>> 
>> http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=6ccb2ccaf7d0e8a5391433a6654eef08059f686c
>> 
>> Peter, can you test the latest daily snapshot?
>> http://daily.josefsson.org/gnutls/gnutls-20090424.tar.gz
>
> I tested the 20090424 snapshot under OpenBSD 4.4 and gnutls-serv emits
> a bind error for the IPv4 socket and only listens on the IPv6 socket.
>
> When bind() is called in listen_socket(), it is given two "res->"
> arguments, but it should be two "ptr->" arguments.  Otherwise it
> doesn't move to ptr->ai_next the second time through the for loop.
>
> Like this:
>> diff serv.c.orig serv.c
>> 685c685
>> <       if (bind (s, res->ai_addr, res->ai_addrlen) < 0)
>> ---
>> >       if (bind (s, ptr->ai_addr, ptr->ai_addrlen) < 0)

Oops.  Thanks, committed, please try the next daily snapshot.

> And I suspect this problem has the same cause:
>> There seems to be a cosmetic problem, though, on my normal debian
>> machine:
>> 
>> jas at mocca:~/src/gnutls/src master$ ./gnutls-serv 
>> Set static Diffie Hellman parameters, consider --dhparams.
>> Echo Server listening to 0.0.0.0:5556 (family 2)...done
>> Echo Server listening to :::5556 (family 10)...bind() failed: Invalid argument
>> ^CExiting via signal 2
>> jas at mocca:~/src/gnutls/src master$ 
>>
>> It seems bind fail on my IPv6 interface, which is probably right because
>> I haven't setup IPv6 here.  Is ignoring bind failures the right thing?
>> I'm not sure why getaddrinfo returns the IPv6 interface at all.
>
> My guess is that you actually have an IPv6 address assigned to an
> interface.  It's probably a "link-local" default address, but an
> address nontheless.  It is proper that getaddrinfo returns an entry
> for it -- and when it does you get hit by the bad call to bind().

Yes, this is the case.  I'm wondering what the best way to handle this
is though.  Should we just display the error above?  It seems confusing
to users.  How are servers in general expected to handle such errors?

/Simon