tshark filter options broken with NapaTech NIC

edit

If there are vlan tags, then assuming you don't care about arp or rarp packets, I'd recommend using -f "vlan and ip and host 10.239.81.123" instead, as it's more efficient. And if you only care about standard VLAN, then this can be made even more efficient, albeit at the cost of a more complex capture filter, using ether[12:2] == 0x8100 and ether[16:2] == 0x0800 and (ether[30:4] == 0x0aef517b or ether[34:4] == 0x0aef517b).

Q. Why does dumpcap -d and Wireshark -> Capture Options -> Compile BPFs produce different output for the same capture filter? It's almost as if dumpcap's output is non-optimized, but if that's the case ... why is that? NOTE: bpfexam can also be used as a comparision.

And since you can have multiple "Compiled Filter Output" windows, it'd also be nice if Wireshark's "Compiled Filter Output" window title included the capture filter expression, so you could actually tell which expression the generated BPF output originated from.

Q. Why does dumpcap -d and Wireshark -> Capture Options -> Compile BPFs produce different output for the same capture filter?

The only difference I'm seeing for "vlan and ip and host 10.239.81.123" between "Dumpcap (Wireshark) 4.4.8 (v4.4.8-0-g0d289c003bfb)." when I run tcpdump -d -f "vlan and ip and host 10.239.81.123" (defaults to en0 with a link-layer type of Ethernet) and "Wireshark 4.4.8 (v4.4.8-0-g0d289c003bfb)." when I use "Compile BPFs" with en0 selected is that the dumpcap version uses a snapshot length of 512KiB and the Wireshark version uses a snapshot length of 256 KiB, so the return value on a match is different. That's definitely not what should be happening, but it's not a question of optimized vs. non-optimized.

(and BPFExam produces the same output as Wireshark if I set the snapshot length to 262144)

dumpcap version uses a snapshot length of 512KiB

Because it's running on macOS, (dynamically) linked with the macOS version of libpcap, and Apple decided to "Keep [libpcap's MAXIMUM_SNAPLEN #define] in sync with BPF_MAXBUFSIZE", so that it's 512KiB, so that's libpcap's default if the snapshot length wasn't explicitly set, and dumpcap wasn't passed a -d flag so it defaulted to libpcap's default.

I.e., on most other OSes, even that difference probably wouldn't have happened.

You need to use the -f <capture filter=""> option.

Nope. tshark, like tcpdump, will (at least in the case of a live capture, for tshark) combine all non-flag-argument tokens (after the last flag argument) into a string, with spaces between them, and treat that as a capture filter, so -f isn't necessary.

Yeah, I realized that after Sake posted his answer. I guess I'm too used to using dumpcap, where this isn't supported.

Of course, other than in the Synopsis of the tshark man page, the [ <filter> ] isn't mentioned anywhere, so it's perhaps not completely obvious that it is a capture filter or how well it plays nicely with -f <capture filter> (Hint: It doesn't). Using this trailing filter means that you can't use a default capture filter specified with a -f <capture filter> option before the first -i option, nor can you use a per-interface capture filter specified with a -f <capture filter> option after a -i option if using this trailing filter.