httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Carlson <>
Subject Re: [PATCH] IPV6 enabled check on Solaris
Date Wed, 23 Apr 2003 23:30:40 GMT
Thanks for the feedback on this one.  I'm not sure what the right change to the 
patch is... see my comments below yours.

Jeff Trawick wrote:
>> +            apr_bind(tmp_sock, sa) == APR_SUCCESS &&
>> +            apr_socket_listen(tmp_sock, 1) == APR_SUCCESS &&
>> +            apr_socket_addr_get(&sa, APR_LOCAL, tmp_sock) == 
>> +            apr_sockaddr_info_get(&sa, "localhost", APR_INET6, 
>> sa->port, 0, p)
> instead of building a sockaddr for "localhost", you need to build a 
> sockaddr just like the pod code will use later, or perhaps use "::"
> it is not our concern whether or not the system has an IPv6 mapping for 
> "localhost"
> I think this is the code that creates the sockaddr we'll use later for 
> connecting, but it may be sufficient to use "::".
> AP_DECLARE(apr_status_t) ap_mpm_pod_open(apr_pool_t *p, ap_pod_t **pod)
> {
> ...
>     apr_sockaddr_info_get(&(*pod)->sa,
>                           ap_listeners->bind_addr->hostname,
>                           APR_UNSPEC, ap_listeners->bind_addr->port, 0,
>                           p);
> ...
> }

The problem with using the ap_listeners list is that it isn't set up at this 
point -- find_default_family() (which I am patching) is called by 
ap_set_listener(), which is the configuration directive that creates the list. 
Also, find_default_family() is only called in the case where the Listen 
directive omits the host name -- that's why we're trying to choose between 
"" and "::".

Second, I was dubious about using "::", since Windows complains when I attempt 
to connect to "" (something about "Address is not valid in this context", 
apparently you can only bind to that address).  I don't know about "::", and I 
don't think Unix has this limitation.  But that's why I decided to use 
localhost.  Although it's not technically correct, I think it will always work. 
  The first socket uses "::" for bind/listen, so it's listening on every 
interface.  Connecting to localhost should therefore succeed (I think).  And 
although this doesn't technically ensure that IPv6 is up on the external 
interface, it does catch the Solaris case that I was originally concerned about, 
and it provides a more rigorous test than the original code.

I guess the only problem would be if my patch introduced false negatives -- b/c 
the connect to localhost failed for an IPv6 enabled machine.  I doubt that this 
would occur, since it seems like IPv6 is probably enabled for the loopback if 
it's enabled anywhere.  I'm just guessing though... somebody with an IPv6 
machine should vet this.

Anyhow, I think my original test should stand, unless it fails on some IPv6 
machine, or unless connecting to "::" will work on Windows (and other) boxes.
When I have some time, I'll try to IPv6-enable a Windows and a Solaris box, and 
test these cases.  But, um, I encourage somebody else to do this for me.


View raw message