On 2013-11-22 00:08, Jeff Trawick wrote: > On Thu, Nov 21, 2013 at 5:48 PM, olli hauer <[email protected]> wrote: > >> Hi, >> >> sorry for late response to apr-1.5.0 ... >> >> I've done some tests with apr-1.5.0 on FreeBSD 10 (amd64) >> and it seems there is an issue that breaks apache24. >> >> With apr-1.5.0 apache22 works but apache24 is broken. >> apache starts fine, nothing special in the logs or during >> start with -X but no response is coming back. >> >> apr/apr-util test: >> ======================================== >> apr-1.5.0: all tests passed [1] >> apr-util-1.5.3: all tests passed >> >> >> working configurations (FreeBSD beta3 [1] >> ========================================= >> apache22-2.2.26 apr-1.4.8 apr-util-1.5.3 >> apache22-2.2.26 apr-1.5.0 apr-util-1.5.3 >> apache24-2.4.6 apr-1.4.8 apr-util-1.5.2 >> apache24-2.4.7 apr-1.4.8 apr-util-1.5.2 >> apache24-2.4.6 apr-1.4.8 apr-util-1.5.3 >> apache24-2.4.7 apr-1.4.8 apr-util-1.5.3 >> >> broken combinations: >> ========================================= >> apache24-2.4.6 apr-1.5.0 apr-util-1.5.3 >> apache24-2.4.7 apr-1.5.0 apr-util-1.5.3 >> >> All tests where done with MPM worker. >> >> >> FreeBSD 8.4 (amd64) seems OK in all combinations >> FreeBSD 9.2 (amd64) seems OK in all combinations >> >> [1] FreeBSD 10 beta3 with iconv UTF7 patch r258316 >> (head/lib/libiconv_modules/UTF7/citrus_utf7.c) >> >> Any hints where to start? >> > > Set LogLevel trace8 and compare good vs. bad. > Start with -X then attach with dtruss and compare good vs. bad. > Get open fds displayed by lsof and compare good vs. bad. > Is connection to client held open? Get backtraces. > > I just compared 1.4.8 vs. 1.5.0 and didn't see anything that looked > remotely likely. >
Small update, The issue is only present if apache24 is build with '--disable-v4-mapped' which should be the default for FreeBSD >= 5.x. Long time ago I've opened a PR since the httpd configure script contains an error https://issues.apache.org/bugzilla/show_bug.cgi?id=53824 - apache24 build with '--disable-v4-mapped' - Listen 80 -> broken - Listen IPv4.addr:80 -> OK - apache24 build with '--enable-v4-mapped' - Listen 80 -> OK - Listen IPv4.addr:80 -> OK I think the issue comes from a wrong assumption in sockaddr.c. --- apr-1.4.8/network_io/unix/sockaddr.c 2013-05-03 20:39:44.000000000 +0200 +++ apr-1.5.0/network_io/unix/sockaddr.c 2013-11-12 15:26:22.000000000 +0100 @@ -839,6 +839,35 @@ return 0; /* not equal */ } +APR_DECLARE(int) apr_sockaddr_is_wildcard(const apr_sockaddr_t *addr) +{ + static const char inaddr_any[ +#if APR_HAVE_IPV6 + sizeof(struct in6_addr) +#else + sizeof(struct in_addr) +#endif + ] = {0}; + + if (addr->ipaddr_ptr /* IP address initialized */ + && addr->ipaddr_len <= sizeof inaddr_any) { /* else bug elsewhere? */ + if (!memcmp(inaddr_any, addr->ipaddr_ptr, addr->ipaddr_len)) { + return 1; + } +#if APR_HAVE_IPV6 + if (addr->family == AF_INET6 + && IN6_IS_ADDR_V4MAPPED((struct in6_addr *)addr->ipaddr_ptr)) { + struct in_addr *v4 = (struct in_addr *)&((apr_uint32_t *)addr->ipaddr_ptr)[3]; + + if (!memcmp(inaddr_any, v4, sizeof *v4)) { + return 1; + } + } +#endif + } + return 0; +} Haven't tested on OpenBSD/NetBSD but I suspect the issue is also present on this platforms. -- olli
