httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: Windows 2.3.13 :: Win32DisableAcceptEx
Date Fri, 30 Sep 2011 00:30:53 GMT
On Thu, Sep 29, 2011 at 8:02 PM, Jeff Trawick <trawick@gmail.com> wrote:
> On Thu, Sep 29, 2011 at 5:00 PM, William A. Rowe Jr.
> <wrowe@rowe-clan.net> wrote:
>> On 9/29/2011 2:22 PM, Jeff Trawick wrote:
>>> On Thu, Sep 29, 2011 at 2:58 PM, William A. Rowe Jr.
>>> <wrowe@rowe-clan.net> wrote:
>>>> On 7/7/2011 3:39 AM, Gregg L. Smith wrote:
>>>>> I have an error log full of these;
>>>>>
>>>>> [Thu Jul 07 00:15:58.010625 2011] [mpm_winnt:warn] [pid 2840:tid 1572]
(OS 64)The
>>>>> specified network name is no longer available.  : winnt_accept: Asynchronous
AcceptEx failed.
>>>>
>>>> This might be http://svn.apache.org/viewvc?view=revision&revision=1091826
>>>> confusing the issue if you build with Win32 IPv6 toggled on, depending on
>>>> your operating system and the SDK you used to build... it was introduced
>>>> in 1.4.3, you might want to try reverting this patch after first working
>>>> through the ticket below...
>>>
>>> That doesn't look hopeful, as that patch only modifies behavior for
>>> Windows < Vista; Greg reports the same problem with XP *and Vista*.
>>> (OS level detection would have to be broken?)
>>
>> It certainly contributes, maybe something similar is missing from
>> httpd-2.2/2.3-beta sources.  The old code certainly appeared to work.
>>
>>>>> The problem is, if I set
>>>>>
>>>>> AcceptFilter http none
>>>>>
>>>>> I lose all my vhosts and everything reverts to the main host. If I use
>>>>
>>>> Implies that the host headers are not queried for ***normal*** sockets,
>>>> and reviewing http://svn.apache.org/viewvc?view=revision&revision=1088569
>>>> it looks like this was "optimized" (read:bugged) away.
>>>
>>> Supposedly that commit means "hey, we just got the peername from
>>> accept(); don't call getpeername()".
>>>
>>> I don't follow the "host headers are not queried" connection to
>>> anything in APR...  (I guess we're talking about name-based vhosts.)
>>
>> Sorry, bad wording.  You can't getpeername() on an AcceptEx() socket.
>> You must getpeername() on non-AcceptEx() sockets.
>
> This patch affects only the accept() (apr_socket_accept()) path.  The
> WinNT MPM in trunk doesn't call apr_socket_accept().
>
> APR_DECLARE(apr_status_t) apr_socket_accept(apr_socket_t **new,
>                                            apr_socket_t *sock,
apr_pool_t *p)
> {
>   ...
>    s = accept(sock->socketdes, (struct sockaddr *)&sa, &salen);
>    (11 lines omitted)
>    ->>> (*new)->remote_addr_unknown = 0; <<<-
>
> Obviously this doesn't affect httpd trunk.  For 2.2, is the
> configuration with Win32DisableAcceptEx broken?  (I don't see an
> indication of that in this thread.
>
>>
>> These patch, I believe, broke both 2.3-beta as well as 2.2 when compiled
>> using IPV6 and older VC6/SDK's... my team was able to reproduce problems
>> on Vista/W2K8 that don't exist on W2K3 once your changes are introduced
>> to 2.2 compiled with APR_HAS_IPV6.
>
> Are any of these problems with 2.2 and Win32DisableAcceptEx enabled?
>
> Let's see...
>
> Windows >= Vista, old SDK:
>
> Before the patch: APR_IPV6_V6ONLY returns APR_ENOTIMPL
>
> After the patch: It actually calls setsockopt(); I'm suspicious that
> apr_socket_opt_get() never calls getsockopt() but I haven't checked
> that thoroughly
>
> From an httpd perspective:
>
> AP_ENABLE_V4_MAPPED is never defined for Windows.
>
> make_sock() thus calls apr_socket_opt_set(s, APR_IPV6_V6ONLY, 1).
> Before the patch (old SDK) this was APR_ENOTIMPL, after the patch it
> actually calls setsockopt()
>
> open_listeners() calls apr_socket_opt_get(s, APR_IPV6_V6ONLY, ?)
> Before the patch (old SDK) this always returned 0; after the patch it
> should return 1 (since the apr_socket_opt_set(APR_IPV6_V6ONLY = 1)
> worked).  IOW, before the patch an IPv6 socket was removed from the
> list because it was believed to overlap, now it is not removed from
> the list.

This is well past the point where one needs to know the Listen
configuration, exact problem symptom, etc. ;)  Either way it seems
that there were some oddities around the presence/absence of
IPV6_V6ONLY.  In its absence APR should have been returning
APR_ENOTIMPL instead of not-set for a query, then httpd would have
grown different logic.


>
>
>
>>
>> Also, the apparent splitting of IPV6_ONLY sockets from IPV4/6 sockets
>> causes IPV4 sockets to barf on recycling.  Still trying to pin this down.
>> Working on mitigating the damage to 2.2 and 2.3-beta now.
>>
>>
>
>
>
> --
> Born in Roswell... married an alien...
>



-- 
Born in Roswell... married an alien...

Mime
View raw message