On 4/6/2010 7:14 AM, Ian Schorr wrote:
On Tue, Apr 6, 2010 at 5:19 PM, Kevin Cullimore<kcullimo@xxxxxxxxxx> wrote:
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.
As several people have mentioned, there doesn't appear to be anything
to take back to the CIFS server admin. The client appears to be 100%
behind the search for the DLLs and the timeout inbetween each attempt.
The CIFS server isn't doing anything to trigger this (except existing
as a system serving a mapped drive) and so can't be considered
responsible for the problem. The problem exists on the 10.84.10.173
PC and needs to be resolved there.
This may well be the best summary of the actual problem. Often, one
needs total buy-in and affirmation from the sever admin in order to
inspire those responsible for the client software to take appropriate
action (the "no other choice but to stop practicing denial and fix the
problem" scenario).
-Ian
___________________________________________________________________________
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
