[OpenAFS] 1.7.3 Windows 7 client explorer window delay

[John W. Sopko Jr.]

I am running Windows 7 with the latest patches. It will
be some time before I can troubleshoot this further on my end with wireshark.
Got lots of year end projects to finish. Thanks for the pointers.

Jeffrey Altman wrote, On 12/20/2011 11:55 AM:
> With a non-\\AFS network share, the server actually exists and responds to the
> request.  Therefore there is no delay.  The core issue here is a design
> difference between XP and Vista.
>
> In XP, when a \\server\share search is performed, all of the network providers
> installed on the machine are queried and the answer is delivered when all of
> the network providers have responded.  If the AFS network provider responds
> immediately and the SMB (LanMan) network provider doesn't return for 30
> seconds, the answer provided by the AFS network provider is not delivered to
> the application (e.g., explorer shell) for 30 seconds.
>
> In Vista, when a \\server\share search is performed, all of the network
> providers installed on the machine are queried but the first response is the
> one that is used and the request of the outstanding queries are ignored.
>
> If the 10.254.254.253 entry in LMHOSTS is not preventing the delays, it means
> that the system believes that the net is accessible and the LanMan network
> provider is timing out trying to receive a response.   You can watch this
> using WireShark or Microsoft Network Monitor both of which are free to
> download and install.
>
> There are no delays when accessing \\AFS UNC paths from the command line
> because the afsredir.sys driver has already registered all paths beginning
> with \\AFS with the Multiple UNC Provider (UNC) interface in the kernel.  This
> is strictly an issue with the network provider interface and applications that
> use the WNet APIs to browse.  This is not a problem on Vista, Server 2008 or
> Windows 7.
>
> There are no changes in 1.7.4 to address this because at the moment I'm not
> sure what can be done.
>
> Jeffrey Altman
>
>
> On 12/20/2011 8:02 AM, John W. Sopko Jr. wrote:
>> I have been out of town, thus the reply delay. I had openafs 1.5.x
>> installed, my lmhosts file looks like this:
>>
>> 10.254.254.253    AFS    #PRE
>>
>> Note I had removed the loopback interface in Device Manger after I did
>> the upgrade to 1.7.3 . Also I have 2 additional 10.x.x.x IP aliases on the
>> interface that I use to manage various devices. I get no timeout in other
>> network shares.
>>
>> When we get a chance we will try another machine with a single IP address.
>>
>>
>>
>> Jeffrey Altman wrote, On 12/16/2011 10:57 AM:
>>> If you install WireShark and watch the network traffic on the machine I
>>> suspect that you will find that the delay is being caused by the Microsoft Lan
>>> Manager (SMB) network provider.  It issues an NBNS Name query for "AFS <20>"
>>> and then a DNS query for "afs.<search-domain>".  If it gets a response to
>>> either it then attempts an ICMP ping to the resulting address and an NBNS
>>> NBSTAT query.  Only after the LanMan provider times out does it report failure
>>> and it retries this sequence for every request.
>>>
>>> Adding a fake "AFS" entry to the %windir%\system32\drivers\etc\LMHOSTS file
>>> prevents the NBNS Name queries for "AFS <20>" from being sent.   At the
>>> present time, the OpenAFS installer only creates such an entry as part of
>>> installing the Microsoft Loopback Adapter which is not installed by default
>>> now that the afs redirector driver is available.
>>>
>>> Jeffrey Altman
>>>
>>>
>>>
>>
>

-- 
John W. Sopko Jr.               University of North Carolina
email: sopko AT cs.unc.edu      Computer Science Dept., CB 3175
Phone: 919-962-1844             Fred Brooks Building; Room 140
Fax:   919-962-1799             Chapel Hill, NC 27599-3175