Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of ohauer@gmx.de designates
 212.227.15.15 as permitted sender)
Message-ID: <528F7787.3070105@gmx.de>
Date: Fri, 22 Nov 2013 16:25:59 +0100
From: olli hauer <ohauer@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 5.1;
 rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Jeff Trawick <trawick@gmail.com>
CC: "dev@apr.apache.org" <dev@apr.apache.org>
Subject: Re: Issue with apr-1.5.0 on FreeBSD 10beta3
References: <528E8DB1.9040803@gmx.de>
	<CAKUrXK6FCsfddUaKd8WQyqYfm2z186TQDWSi2suJ=t8-3V_XNg@mail.gmail.com>
	<528F222B.5030908@gmx.de>
 <CAKUrXK5K5TDdX9Se8cDZoV-C29+Fb9jwwTHG2YZqcPL2YcDk8g@mail.gmail.com>
In-Reply-To: 
 <CAKUrXK5K5TDdX9Se8cDZoV-C29+Fb9jwwTHG2YZqcPL2YcDk8g@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 2013-11-22 15:09, Jeff Trawick wrote:
> 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
>>
>>
>> - 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.

Exact, this should be the default on this platforms, regarding my last
informations I received from the FreeBSD security team during apache24
porting (thats why I opened apache bug ID 53824).


> sockstat -P tcp -p80,22
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS
www      httpd      52415 3  tcp6   *:80                  *:*
www      httpd      52415 4  tcp4   *:80                  *:*
www      httpd      52414 3  tcp6   *:80                  *:*
www      httpd      52414 4  tcp4   *:80                  *:*
...
root     sshd       752   3  tcp6   *:22                  *:*
root     sshd       752   4  tcp4   *:22                  *:*


>  - 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.

OK, at last the diff was a hint for me to test if v4_mapped could be the issue


>> --- 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?

No concern from myself. My last information was IPv4 and IPv6 should be listening
in FreeBSD on dedicated sockets. Perhaps one of the reason is the rewrite of
the network stack.


>>
>> 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).
> 

This would be great, If you have patches or other parts to test give me a ping.

-- 
olli