On Fri, Nov 22, 2013 at 4:21 AM, olli hauer <ohauer@gmx.de> wrote:
On 2013-11-22 00:08, Jeff Trawick wrote:
> On Thu, Nov 21, 2013 at 5:48 PM, olli hauer <ohauer@gmx.de> 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

As it turns out, the problem wasn't specific to --disable-v4-mapped.

This is fixed in httpd trunk r1551685.




- 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



--
Born in Roswell... married an alien...
http://emptyhammock.com/