Discussion:
A way to see how many diffrent files are acessed using SMB/CIFS
Hime Marko
2010-12-10 15:00:01 UTC
Permalink
Hi.

I have 30m capture from a NetApp CIFS server.
I'm looking for a way to know how many dffrent files are accessed each second to
one of the CIFS shares on this server.


Can someone did it/know how to do it ?

Thnaks !!!



___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe
Martin Visser
2010-12-12 03:33:28 UTC
Permalink
Hime,

You can certainly do this, but you may need to be a little more specific on
what you mean by "access". As you can see from the snippet below, there are
different stages that may or may not be important. (I just filtered on "smb"
after connecting to my fileserver).

No. Time Source Destination Protocol
Info
4984 59.832941 192.168.0.210 192.168.0.14 SMB
Open AndX Request, FID: 0x453e, Path: \marty\conficker\confick_domains.txt
4985 59.835820 192.168.0.14 192.168.0.210 SMB
Open AndX Response, FID: 0x453e
4987 59.836968 192.168.0.210 192.168.0.14 SMB
Trans2 Request, QUERY_PATH_INFO, Query File All Info, Path:
\marty\conficker\confick_domains.txt
4988 59.839303 192.168.0.14 192.168.0.210 SMB
Trans2 Response, QUERY_PATH_INFO
4989 59.840647 192.168.0.210 192.168.0.14 SMB
Read AndX Request, FID: 0x453e, 16384 bytes at offset 0
5006 59.868510 192.168.0.14 192.168.0.210 SMB
Read AndX Response, FID: 0x453e, 16384 bytes


The first two frames show the open request/response sequence. In my case I
had permission to access the file, however if I was denied access (and hence
obtained a different response), in your case do you count this or not.

The next two frames, show the client getting the basic attributes of the
file, but not reading the contents. Again, is this an "access"

Finally the last two frames show a read request of the contents. In some
case I may only be partially reading a file, so what constitutes an
"access".

The data is all available for your interpretation.

You can use appropriate filters in Statistics:IO Graphs to get something
useful.For instance maybe you should just count successful file open
responses.
To do this you enter "(smb.cmd == 0x2d ) && (smb.nt_status == 0x00000000)"
in the Filter field. You would then display at the appropriate sample
interval the number of Packets/Tick. (This assumes one response per packet).
Of course this shows all of the Open responses - even if they are used for
enumerating directories to display file information in a window. You may
need to investigate Read or Write Reponses (the issue there though is there
will be usually many response for each files. So in this case you would need
to a little extra processing, possibly associating file paths with File IDs,
and then making a decision on the Read/Writes as to what you are interested
in.

Hopefully this will give you an idea of where to further explore your
request.



Regards, Martin
Post by Hime Marko
Hi.
I have 30m capture from a NetApp CIFS server.
I'm looking for a way to know how many dffrent files are accessed each second to
one of the CIFS shares on this server.
Can someone did it/know how to do it ?
Thnaks !!!
___________________________________________________________________________
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
?subject=unsubscribe
vincent paul
2010-12-14 08:23:43 UTC
Permalink
Hi All,

Is there any rationale ( security "protocol" or something...) to use MSS= 1212,
1260 or 1262?

Regards,
Vincent
Sake Blok
2010-12-14 09:15:18 UTC
Permalink
Is there any rationale ( security "protocol" or something...) to use MSS= 1212, 1260 or 1262?
Using a lower MSS happens when a link in the path has a smaller MTU than 1500. This can be a physical link or can be a virtual link which causes encapsulation (GRE, IPsec, MPLS, etc). The initial MSS in the SYN packet is then lowered by intermediate devices so that fragmentation at the IP layer is not needed along the way. A system might also configure a lower MTU size itself to prevent fragmentation along the way. This can be useful if the routers along the path do not change the MSS in the SYN packets.

The values 1212, 1260 and 1262 do seem low to me and would suggest either a link with a very low MTU or many encapsulations. Or fragmentation-paranoia on the side of the system administrator :-)

Cheers,


Sake

PS Please do not create a new topic by responding to another message, this messes up threading in mailreaders that support threads and might make your message go unnoticed.
Hansang Bae
2010-12-21 03:09:35 UTC
Permalink
Post by vincent paul
Hi All,
Is there any rationale ( security "protocol" or something...) to use
MSS= 1212, 1260 or 1262?
Regards,
Vincent
Like Sake said, it could be folks who are worried about MTU issues.
There should be a law passed to force everyone to get path mtu discovery
to work!

Between IPSec, GRE, IPSEC+GRE, etc., it's not unusual to see MSS in the
1300 range.

Loading...