I wonder if this is related to Joe's recent change to apr_sockaddr_info_get(), where IPv6 won't be returned if the system doesn't support it. Does reverting Joe's additional flag make any difference? (AI_ADDRCONFIG) It probably does, since ISTR we're specifying AF_UNSPEC for the family, and family=AF_UNSPEC is where AI_ADDRCONFIG works its magic.
If you back out the AI_ADDRCONFIG flag, is Apache able to get an IPv6 socket and handle incoming IPv4 connections when you have plain "listen ###"?
Nope. I looked at that code bit and it doesn't execute. When we enter that segment, we aren't AF_UNSPEC, but AF_INET6 because find_default_family thinks we have IPv6 available. So, the AI_ADDRCONFIG code doesn't execute at all.
I guess find_default_family() has to make use of the fact that
getaddrinfo("::", AF_UNSPEC, AI_ADDRCONFIG) will fail now in some scenarios
where everything was happy before.
Nope, it's getaddrinfo('::', AF_INET6, 0) that causes the failure. Are we sure that '::' is standard? I couldn't find any documentation to support that.
It isn't quite that simple. If there is a non-qualified address in the config, we try to figure out if the box supports IPv6, and if it does then we get an IPv6 listening socket for that port.
But, if the IPv6 fails, we should go back to IPv4. Instead, we just exit.
Somehow I don't see the badness :) The philosophy has been:
If your box is set up for IPv4+IPv6, Apache by default will handle connections over either; if your box is set up for just IPv4, Apache by default will notice that. Isn't that goodness?
No. Because it's broken. ;-)
If the current problem is that find_default_family() needs to be smarter since AI_ADDRCONFIG makes some of the IPv6 logic fail where it didn't fail before, then let's make it smarter.
Nope. find_default_family isn't really at fault. Specifically, it is that:
getaddrinfo(NULL, AF_INET6, 0)
works on Solaris, but:
getaddrinfo('::', AF_INET6, 0)
returns the EAI 8 code. find_default_family uses the first. When no address is specified, the listener is attempted with the second. And, when the second call fails, httpd just gives up rather than trying to fail back to IPv4.
I have no earthly idea why I'm only seeing this now. Perhaps I never enabled IPv6 before now on Solaris. -- justin
