On Thu, Sep 29, 2011 at 5:00 PM, William A. Rowe Jr.
<wr...@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.
>> <wr...@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.
>
> 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...
