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
