Expressions for upper layer protocols return nothing when 802.1Q header is present in saved files

[garrymar]

Hi everyone,

I noticed that tcpdump returns nothing when I apply upper layer protocols filtering expressions while reading (-r) previously saved files that contain 802.1Q headers. However, if I start an expression with vlan and or vlan n and it works. For example:

$ tcpdump -ner tagged.pcap icmp
reading from file tagged.pcap, link-type EN10MB (Ethernet), snapshot length 262144

$ tcpdump -ner tagged.pcap vlan and icmp
reading from file tagged.pcap, link-type EN10MB (Ethernet), snapshot length 262144
19:36:45.480739 5e:7f:f5:03:3b:75 > fa:3a:f0:69:27:d2, ethertype 802.1Q (0x8100), length 102: vlan 2, p 0, ethertype IPv4 (0x0800), 192.168.2.2 > 192.168.2.1: ICMP echo request, id 11444, seq 1, length 64

$ tcpdump -ner tagged.pcap vlan 2 and icmp
reading from file tagged.pcap, link-type EN10MB (Ethernet), snapshot length 262144
19:36:45.480739 5e:7f:f5:03:3b:75 > fa:3a:f0:69:27:d2, ethertype 802.1Q (0x8100), length 102: vlan 2, p 0, ethertype IPv4 (0x0800), 192.168.2.2 > 192.168.2.1: ICMP echo request, id 11444, seq 1, length 64

Version info:

]$ tcpdump --version
tcpdump version 4.99.5
libpcap version 1.10.5 (with TPACKET_V3)
OpenSSL 3.3.2 3 Sep 2024
64-bit build, 64-bit time_t

Sample file:
tagged.pcap.gz

• This is not a security issue.

[infrastation]

This is exactly the documented behaviour, please see FAQ 13.

[garrymar]

This is exactly the documented behaviour, please see FAQ 13.

Hmm, interesting ... Thank you for sharing the answer.

However, @infrastation, it is not the same when I read exactly the same packets directly from the network:

# tcpdump -nei veth0 icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on veth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes

20:35:11.767115 5e:7f:f5:03:3b:75 > fa:3a:f0:69:27:d2, ethertype 802.1Q (0x8100), length 102: vlan 2, p 0, ethertype IPv4 (0x0800), 192.168.2.2 > 192.168.2.1: ICMP echo request, id 12846, seq 1, length 64
20:35:11.767197 fa:3a:f0:69:27:d2 > 5e:7f:f5:03:3b:75, ethertype 802.1Q (0x8100), length 102: vlan 2, p 0, ethertype IPv4 (0x0800), 192.168.2.1 > 192.168.2.2: ICMP echo reply, id 12846, seq 1, length 64

[garrymar]

Also, @infrastation, it is quite the opposite from what is explained in the FAQ: in my case, I get problems when I do not specify vlan.

[infrastation]

Capturing from live network on Linux has its peculiarities that can complicate VLAN processing more than it already is. I do not immediately remember all the details, unfortunately. Reading from the file is a case discussed in the FAQ, although it may take time to understand.

[garrymar]

Seeing different behaviour for the same filter expression for live and saved packets is quite unexpected. When I first faced it, I started checking the man page section for the -r argument and examples but could not find anything related. Then I decided it is a bug and created this issue.

I wonder what you think about updating the man page saying that filter expressions might work differently depending on whether they are read from network or a saved file.

[infrastation]

The behaviour of -r matches the documented definition of vlan in pcap-filter(7). The problem here is that the documented behaviour is not what users often imply, as the FAQ explains.

The behaviour of -i being different from that of -r looks like a duplicate of a known Linux VLAN bug (for example, #1169 and possibly others), in which case it needs to be fixed, not documented. This requires some work.

[garrymar]

Hmm, indeed: on macOS, the -i and -r behaviours matches.

The behaviour of -i being different from that of -r looks like a duplicate of a known Linux VLAN bug

Now everything is crystal clear and makes total sense.

Thank you so much for your support, Denis!

[guyharris]

Linux is, at least at present, the only OS in which VLAN tags are extracted from received packets in the network data path and put into metadata attached to the packet and are not re-inserted into the packet data before it's handed to the packet capture mechanism. (In most other OSes, they're not extracted the first place; I'm not sure what happens on Windows.)

This means that capture filtering requires special handling on Linux, and getting that correct has turned out to be difficult.