On 4/5/2010 5:35 PM, J�nos L�bb wrote:
On Apr 5, 2010, at 4:18 PM, Bill Meier wrote:
J�nos L�bb wrote:
What do you think the problem is ??
It looks to me like the PC is trying several times to find a DLL on
the
server, getting a 'not found' return and then timing out for 4 or 10
secs and trying again.
I suggest you open the capture file, filter on one of the TCP
conversations (statistics ! conversations) and see for yourself. :)
___________________________________________________________________________
Hi Bill,
Yes, I saw that one, already three months ago in my wireshark
captures, and asked the DFS server admin if there is a timeout for
client access can it be set to a lower value and he said to me there
is no such thing.
That particular dll wshenu.dll - Windows Scripting Host English - does
not even exist on the client PC and it does not exist on the DFS
servers either. However Windows Exploder, IE and any script created
with Windows Scripting is looking for it.
http://forum.sysinternals.com/topic5696.html
Rephrasing my question, how can I use the capture file to show the DFS
admin that there is a problem here. I sent him similar captures 3
months ago.
That data would appear to be insufficient in isolation. To their
unlikely credit, Microsoft maintains decent documentation as far as
their protocol stacks are concerned. Conjoining both your capture and
knowledgebase articles referencing their networking client behavior
could result in an argument more difficult to deny/refute.
Thanks ahead,
J�nos
___________________________________________________________________________
Sent via: Wireshark-users mailing list<wireshark-users@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
