apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colm MacCarthaigh,,," <colmm...@stdlib.net>
Subject Re: [PATCH] Default Listen with IPv6 enabled incorrect
Date Wed, 13 Aug 2003 00:59:34 GMT

(Cc:ing dev@apr now, because of APR patch)

On Tue, Aug 12, 2003 at 10:12:45AM -0700, Justin Erenkrantz wrote:
> --On Tuesday, August 12, 2003 5:58 PM +0100 "Colm MacCarthaigh,,," 
> <colmmacc@stdlib.net> wrote:
> 
> >Even lo0 ? That's hard ;)
> 
> % ifconfig -a6
> %

As an asside I maintain that this is a broken system configuration, it's 
just as if you had IPv4 built in, but chose not to configure any IPv4 
addresses. What would have Apache do in such a situation ? Surely exiting 
is appropriate ...

But since you're less wrong than I am on this one, using AI_ADDRCONFIG
is best. This will weed out the problem.

But just to make clear I think "Listen 80" *really* needs to mean 
"Listen on port 80", not "Listen on port 80 in IPv4 only" :)

> >if getaddrinfo for PF_UNSPEC returns '::' in this situation
> >then it's really a lib(c|socket|nsl) bug, it does this on
> >Linux aswell, but the KAME implementation (and I believe windows)
> >have it fixed.
> 
> No, the OS is not returning '::'.  We're not using PF_UNSPEC, but 
> hard-coding PF_INET6.  (AF_INET6, AP_INET6, whatever the #define is.)

This is the real bug, Apache shouldnt be second-guessing getaddrinfo,
APR's call_resolver is an excellent example of how to do it properly,
AI_ADDRCONFIG is the key. Trouble is apr_sockaddr_info_get isnt 
calling it for us. This is an APR bug, see the attached patch.

> In alloc_listener, we're hardcoding '::' and PF_INET6 unconditionally if 
> the OS supports IPv6 (as determined by find_default_family).  (See the 
> !addr branch.)

It's not as broken as it seems, it does:

254   apr_sockaddr_info_get(&sa, NULL, APR_INET6, 0, 0, p) == APR_SUCCESS

So it *should* be valid. Problem is it *always* returns APR_SUCCESS
for a NULL hostname :(  Line 583 of apr/network_io/unix/sockaddr.c
is the real problem.

> I have a hunch that we may be able to create ephemeral ports (NULL address 
> passed in) without a configured IPv6 interface on Solaris.  Which strikes 
> me as not being totally wrong on Solaris's part.
> 
> I still maintain that my patch should be applied.  Let PF_UNSPEC figure it 
> out.

But your patch didnt do this, it just blindly returned 0.0.0.0. This
would break literally hundreds of peoples configs!

APR patch attached, it should fix your problem. I don't
have any systems I can configure easily into the state you
describe, so I can't test it properly just yet.

What should happen:
apr_sockaddr_info will call find_addresses, which will call
call_resolver which will have AI_ADDRCONFIG dutifuly set. So
if apply the patch , the problem should go away.

This all leaves listen.c bigger than it needs to be. So there's
changes in the patch for that too. The original find_default_family
didnt even compile for me anyway ;) The changes to listen.c create
one very slight logic problem in that:

 "Listen 80
  Listen 0.0.0.0 80"

will now result in a failure of apache to start because binding
to the socket twice will fail, wheras previously the dupe would
have been cought. I don't think this is a major problem.

Now, the extra cookie that we all deserve. This all shows up
a massive problem with apr_socket_create, it only creates
one socket. But apr_sockaddr_info_get returns a linked
list to many. It's allowable for AI_PASSIVE to return both
:: and 0.0.0.0, for example, or for round-robin DNS records
to return multiple addresses and this isnt handled properly.
My head hurts already.

There really needs to be an APR call that means: "walk this
linked list and creete/bind sockets for each node."

-- 
Colm MacCárthaigh                        Public Key: colm+pgp@stdlib.net
colm@stdlib.net					  http://www.stdlib.net/

Mime
View raw message