On Fri, Nov 22, 2013 at 4:21 AM, olli hauer <oha...@gmx.de> wrote:
> On 2013-11-22 00:08, Jeff Trawick wrote:
> > On Thu, Nov 21, 2013 at 5:48 PM, olli hauer <oha...@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
>
>
> - apache24 build with '--disable-v4-mapped'
> - Listen 80 -> broken
>
Broken for IPv4 connections I suppose but working for IPv6 connections
(e.g., "telnet ::1")?
If v4-mapped is disabled, then httpd should be getting both an IPv4
listener and an IPv6 listener.
- 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.
>
Note that httpd doesn't use apr_sockaddr_is_wildcard(). apr doesn't use it
except in a regression test.
>
> --- 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;
> +}
>
Is the concern just that there is "V4MAPPED"-related code here, or is there
some specific scenario where it wouldn't classify the address properly?
>
>
> Haven't tested on OpenBSD/NetBSD but I suspect the issue is also present
> on this platforms.
>
I might have time in the next few days to test on FreeBSD 9. I dunno.
I understand that apr 1.4.8 vs. 1.5.0 is the trigger, but I think this is
going to have to be debugged from the problem symptom in httpd backwards to
find the root cause and the difference between 1.4.8 vs. 1.5.0 that
triggered it (which might be two different things).
> --
> olli
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
