Wireshark-users: Re: [Wireshark-users] Slowdown after mounting DFS network drives
Thanks Kevin
Yes, I do use the sysinternals utilities all of the time. And like them alot.
No, I am not stuck on Windows but some clients request some
Windows-related docs, etc. Therefore, I have to keep it around. I
use Linux also and prefer the command prompt over having things hidden
by some GUI.
Thanks for responding.
On 4/7/10, Kevin Cullimore <kcullimo@xxxxxxxxxx> wrote:
> On 4/7/2010 11:26 AM, János Löbb wrote:
>> Folks,
>>
>> Thanks a lot for all your comments. Now I see more clearly :-)
>>
>> For system trace tool - on Windows - I was suggested to use FileMon:
>>
>> <snip>
>> The Sysinternals FileMon utility (Filemon.exe) monitors and displays
>> file system activity on the computer in real time. When this problem
>> occurs, multiple error messages that resemble the following are logged
>> in the FileMon log file:
>> 589 2:54:14 PM wscript.exe:2212 QUERY INFORMATION
>> C:\WINNT\System32\*wshENU.DLL* NOT FOUND Attributes: Error
>> </snip>
>>
>> Thanks again,
>
> If you're stuck with windows, utilities written by Mark Russinovich
> generally provide you with more visibility than competing alternatives.
> Separately, do keep in mind that Network Monitor allows you to filter by
> process ID.
>>
>> János
>> On Apr 7, 2010, at 10:35 AM, M K wrote:
>>
>>> 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
>>> <mailto: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 <mailto:MartinVisser99@xxxxxxxxx>
>>>>
>>>>
>>>> On Wed, Apr 7, 2010 at 12:54 AM, Kevin Cullimore
>>>> <kcullimo@xxxxxxxxxx <mailto: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 <mailto: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
>>>>>> <mailto: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 <mailto: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 <mailto: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
