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
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
