On Thu, Sep 29, 2011 at 8:02 PM, Jeff Trawick <traw...@gmail.com> wrote: > 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.
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...
