Aha. You have hit on something when you said "possible culprit
applications to determine the system calls they are making (and hence
trigger the network traffic you see)." What system trace tools do you
suggest to help perform the analysis for these system calls?
Currently I am using multiple tools that provide some sort of
visibility and then cross-referencing the results. I am also reducing
the number of apps as a process of elimination. Or, to maybe put it
another way, does anyone have suggestions for ethical apps (OS, Word
processing, spreadsheet, browser, etc) ? I have had way too many
experiences with apps acting otherwise in the background.
Thanks for any insight.
On 4/6/10, Martin Visser <
martinvisser99@xxxxxxxxx>
wrote:
Also remember in troubleshooting these
issue, that what is seen on the
network (via Wireshark) is only part of the
picture. You should try to marry
network traffic with activity or events
seen on the workstation. Sometime
this will be invisible to you, however you
might need to workthrough the
scripts or startup applications, as well
look at logs (or on windows
machines,the event viewer). Sometimes you
might have opportunity to increase
the log verbosity (to a debug level) or
even use system trace tools on
possible culprit applications to determine
the system calls they are making
(and hence trigger the network traffic you
see).
As has been stated the client is choosing
to wait between server requests.
The server always responds promptly, with
what it believes to be the right
answer. The client seems not to be
satisfied and hence tries again. Not
knowing what the client is making visible
to the user at this time (or its
effect on the start process or
applications) makes further diagnosis on our
part pretty much speculative.
Regards, Martin
MartinVisser99@xxxxxxxxx
On Wed, Apr 7, 2010 at 12:54 AM, Kevin
Cullimore <kcullimo@xxxxxxxxxx>wrote:
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
___________________________________________________________________________
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
--
All that is necessary for evil to succeed is that good men do nothing.
~Edmund Burke
___________________________________________________________________________
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