tshark

In trying to triage a NFSv3 READDIR lack of response, I had to figure out which interface a packet was arriving at and which one it was being sent back on. My typical way to invoke tshark is the very simple:

tshark -i any -w /tmp/f.scp

Everyone else uses a pcap extension and for some reason, I find “f” as a perfectly fine name for a temporary packet capture I don’t plan to keep.

If I used this approach, I could see the READDIR packet arriving and departing, but I couldn’t tell which interface was being used. If I did this instead,

tshark -i bond0 -w /tmp/f.scp

I could see the READDIR call, but not the reply. I then proceeded to cycle through each and every interface, but no joy at finding the reply. (To be honest, I probably went too fast in my iteration and just missed it.)

I read (somewhere via Google foo) that it would print the interface the pack either arrived or departed on. So, I went to back to using “any” and checked:

Frame 72359: 198 bytes on wire (1584 bits), 198 bytes captured (1584 bits) on interface 1
    Interface id: 1 (any)
        Interface name: any

Not what I wanted. Somehow I figured out that I could use -i multiple times to specify the interfaces I wanted:

tshark -i bond1.80 -i bond0 -i eno1 -i bond1 -i bond1.100 -i bond1.2080 -w /tmp/bonds.scp

And then when I looked at the two packets of interest:

Frame 72359: 198 bytes on wire (1584 bits), 198 bytes captured (1584 bits) on interface 1
    Interface id: 1 (bond0)
        Interface name: bond0
...
Frame 72366: 1614 bytes on wire (12912 bits), 1614 bytes captured (12912 bits) on interface 4
    Interface id: 4 (bond1.100)
        Interface name: bond1.100

So now I can in a multi-homed system, I can figure out the interfaces on which packets are captured.

I was asked to figure out why a NFSv3 server was not responding to READDIR requests. Note, I don’t know if this was READDIR or READDIRPLUS. I fired off tshark to capture packets:

tshark -i any -w /tmp/bonds.scp

Hmm, even when filtering on NFS, too many packets to examine (it is a very busy NFSv3 server):

NR_09-20:24:09 pixie ~ $ tshark -r /tmp/bonds.scp | wc -l
Running as user "root" and group "root". This could be dangerous.
140532
NR_09-20:29:13 pixie ~ $ tshark -r /tmp/bonds.scp -Y nfs | wc -l
Running as user "root" and group "root". This could be dangerous.
39350

I could use Wireshark, but nah!

I can use a better filter:

NR_09-20:31:46 pixie ~ $ tshark -r /tmp/bonds.scp -Y "nfs.procedure_v3  == 16 || nfs.procedure_v3  == 17" | wc -l
Running as user "root" and group "root". This could be dangerous.
21

This states to only filter if the NFSv3 procedure is either 16 or 17.

You can find the list of NFSv3 procedures at https://datatracker.ietf.org/doc/html/rfc1813#page-27.

Figuring out which device a packet went out on

Filtering on NFSv3 procedures