# nfs analysis **URL:** \ **Category:** Zeek\ **Created:** [September 22, 2007, 12:25am UTC](https://community.zeek.org/t/nfs-analysis/1227 "2007-09-22T00:25:40Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Mike\_Wood](https://avatars.discourse-cdn.com/v4/letter/m/47e85d/32.png) [@Mike\_Wood](https://community.zeek.org/u/Mike_Wood)\ **Post date:** [September 22, 2007, 12:25am UTC](https://community.zeek.org/t/nfs-analysis/1227/1 "2007-09-22T00:25:40Z")
Quick question: is the documentation regarding NFS on the Bro-wiki accurate? "Deficiency: Bro's notion of NFS is currently confined to just knowledge of the existence of these services. It does not analyze the particulars of different NFS operations." I am trying to extract some NFS file access events from a trace and cannot seem to get the nfs\_request\_\* nfs\_attempt\_\* event handlers to trigger. Should I be able to? Thanks, Mike ---
**Author:** ![Christian\_Kreibich3](https://avatars.discourse-cdn.com/v4/letter/c/4af34b/32.png) [@Christian\_Kreibich3](https://community.zeek.org/u/Christian_Kreibich3)\ **Post date:** [September 22, 2007, 9:50pm UTC](https://community.zeek.org/t/nfs-analysis/1227/2 "2007-09-22T21:50:02Z")
Hey Mike! I believe the documentation is once again misleading. ☹ Do you get nothing at all when you load nfs.bro? Cheers, Christian ---
**Author:** ![Mike\_Wood](https://avatars.discourse-cdn.com/v4/letter/m/47e85d/32.png) [@Mike\_Wood](https://community.zeek.org/u/Mike_Wood)\ **Post date:** [September 24, 2007, 5:39pm UTC](https://community.zeek.org/t/nfs-analysis/1227/3 "2007-09-24T17:39:20Z")
Sadly, yes I do not get any output from nfs.bro. The tcpdump output for my trace looks like: 16:01:13.467628 IP client.host.name.4160508447 \> server.host.name.nfs: 132 getattr [|nfs] 16:01:13.467879 IP server.host.name.nfs \> client.host.name.4160508447: reply ok 96 getattr DIR 40755 ids 10013/6007 sz 1024 16:01:13.467940 IP client.host.name.4177285663 \> server.host.name.nfs: 148 lookup [|nfs] 16:01:13.468130 IP server.host.name.nfs \> client.host.name.4177285663: reply ok 128 lookup [|nfs] ... So I would assume I have some valid NFS traffic there... but when I run bro -r mytrace.pcap nfs.bro I just get plenty of weird messages: 1190415715.190522 weird: bad\_RPC 1190415715.190781 weird: unpaired\_RPC\_response So, perhaps this is all the NFS traffic not getting recognized. Have you seen this before? I am running Bro 1.2.9... if that helps at all. Thanks, Mike ---
**Author:** ![Christian\_Kreibich3](https://avatars.discourse-cdn.com/v4/letter/c/4af34b/32.png) [@Christian\_Kreibich3](https://community.zeek.org/u/Christian_Kreibich3)\ **Post date:** [September 27, 2007, 12:04am UTC](https://community.zeek.org/t/nfs-analysis/1227/4 "2007-09-27T00:04:29Z")
(I feel I won't be able to give the definitive answer to this one, so others are very welcome to jump in.) I wonder whether it could be that Bro doesn't read all of the traffic -- check whether the resulting filter looks decent by adding print-filter.bro at the end of your invocation? Also, I'm wondering how the source port can be 4160508447 in your tcpdump!? Cheers, Christian ---
**Author:** ![Mike\_Wood](https://avatars.discourse-cdn.com/v4/letter/m/47e85d/32.png) [@Mike\_Wood](https://community.zeek.org/u/Mike_Wood)\ **Post date:** [October 5, 2007, 12:14am UTC](https://community.zeek.org/t/nfs-analysis/1227/5 "2007-10-05T00:14:19Z")
Hi Christian, > \> Sadly, yes I do not get any output from nfs.bro. > \> > \> The tcpdump output for my trace looks like: > \> > \> 16:01:13.467628 IP client.host.name.4160508447 \> server.host.name.nfs: > \> 132 getattr [|nfs] > > Also, I'm wondering how the source port can be 4160508447 in your > tcpdump!? Turns out this looks like a tcpdump bug that has an appropriate fix (see [bin/105334: Error in output of tcpdump](http://lists.freebsd.org/pipermail/freebsd-bugs/2006-November/021159.html)). So, I think my trace is actually fine. I ran bro in gdb to trace out the execution. It seems the UDP.cc analyzer gets called, but the analysis goes no further than that -- i.e. I get to UDP\_Analyzer::DeliverPacket, but I never get to RPC\_UDP\_Analyzer\_binpac::DeliverPacket. I have tried running with the --use-binpac option, but get the same result. Any further ideas? - Mike ---
**Author:** ![Vern](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/vern/32/630_2.png) [@Vern](https://community.zeek.org/u/Vern)\ **Post date:** [October 11, 2007, 6:59pm UTC](https://community.zeek.org/t/nfs-analysis/1227/6 "2007-10-11T18:59:47Z")
Sorry for the delay on following up on this. > 16:01:13.467628 IP client.host.name.4160508447 \> server.host.name.nfs: > 132 getattr [|nfs] Whenever tcpdump displays "|xxx", it means that the packet was truncated due to a snapshot limitation. Bro can't analyze such packets at the application level. So you need to capture traffic using tcpdump -s 0 to turn off the limited snapshot. Note, the funky port number its showing is the NFS file handle (or maybe it's the RPC transaction ID - I forget which) - a tcpdump feature. So I'm not sure what to make about your later comment that this was a tcpdump bug ... > 1190415715.190522 weird: bad\_RPC > 1190415715.190781 weird: unpaired\_RPC\_response These arise because Bro can't fully parse the RPC.     Vern ---
**Author:** ![system](https://canada1.discourse-cdn.com/flex011/uploads/zeek/original/1X/f09d732bc2cc7c7cc7e35db67cf4e1d5233ce7a7.png) [@system](https://community.zeek.org/u/system)\ **Post date:** [May 6, 2022, 3:38pm UTC](https://community.zeek.org/t/nfs-analysis/1227/7 "2022-05-06T15:38:21Z")