Windows 7 is a completely different story. I have never seen a
delay from the explorer shell on Windows 7 and no one else here has
complained about it. As I asked before, file a bug report at
[email protected]. Discussions that take place here get
lost and forgotten.
On 12/20/2011 12:04 PM, John W. Sopko Jr. wrote:
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
|
signature.asc
Description: OpenPGP digital signature
