Re: [OpenAFS] 1.7.3 Windows 7 client explorer window delay

[Jeffrey Altman]

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

signature.asc
Description: OpenPGP digital signature