[OpenAFS] 1.7.3 Windows 7 client explorer window delay
John W. Sopko Jr.
Tue, 20 Dec 2011 12:04:06 -0500
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