tcpdump (-i any) with vlan

Question

I have a question regarding tcpdump (capturing all interfaces) and a strange capture I see.

Environment:

2 Linux devices connected and configured with VLAN TAG (802.1q). I am pinging between the 2 device vlan interfaces, network wise everything works well. When using tcpdump to capture all interfaces tcpdump –i any –n –e.

I am seeing this:

The first 3 packets looks fine

Received on the main interface (tagged):

-6:-45:-40.2216 In 00:11:22:33:44:56 ethertype 802.1Q (0x8100), length 104: vlan 10, p 0, ethertype IPv4, 10.0.0.10 > 10.0.0.1: ICMP echo request, id 2452, seq 487, length 64

Received on the vlan interface (untagged):

-6:-45:-40.2217 In 00:11:22:33:44:56 ethertype IPv4 (0x0800), length 100: 10.0.0.10 > 10.0.0.1: ICMP echo request, id 2452, seq 487, length 64

Sent from the vlan interface (untagged):

-6:-45:-40.2221 Out 00:11:22:33:44:55 ethertype IPv4 (0x0800), length 100: 10.0.0.1 > 10.0.0.10: ICMP echo reply, id 2452, seq 487, length 64

But the fourth sent from the main interface looks erroneous:

-6:-45:-40.2223 Out 00:11:22:33:44:55 ethertype 802.1Q (0x8100), length 100: vlan 1280, p 2, ethertype Unknown, LLC, dsap SNA (0x04) Group, ssap Unknown (0x3e) Response, ctrl 0x0000: Information, send seq 0, rcv seq 0, Flags [Response], length 80

When defining the specific interface (eth0 or eth0.10) to tcpdump it looks well:

"tcpdump -i usb0 -n -e"

-6:-13:00.40042 00:11:22:33:44:56 > 00:11:22:33:44:55, ethertype 802.1Q (0x8100), length 102: vlan 10, p 0, ethertype IPv4, 10.0.0.10 > 10.0.0.1: ICMP echo request, id 2452, seq 2442, length 64 -6:-13:00.40100 00:11:22:33:44:55 > 00:11:22:33:44:56, ethertype 802.1Q (0x8100), length 102: vlan 10, p 0, ethertype IPv4, 10.0.0.1 > 10.0.0.10: ICMP echo reply, id 2452, seq 2442, length 64

"tcpdump -i usb0.10 -n –e"

-6:-52:-14.5791 00:11:22:33:44:56 > 00:11:22:33:44:55, ethertype IPv4 (0x0800), length 98: 10.0.0.10 > 10.0.0.1: ICMP echo request, id 2452, seq 94, length 64 -6:-52:-14.5795 00:11:22:33:44:55 > 00:11:22:33:44:56, ethertype IPv4 (0x0800), length 98: 10.0.0.1 > 10.0.0.10: ICMP echo reply, id 2452, seq 94, length 64

Currently, I work with an usb network interface but the same goes for Ethernet (eth0 / eth0.10).

The extra 2 bytes when using –i any are because Linux adds its Linux cooked 2 bytes.

Any idea, why does tcpdump shows this line when using –i any ?

Since traffic is working well, I guess it is just a parsing issue with tcpdump ???

-6:-45:-40.2223 Out 00:11:22:33:44:55 ethertype 802.1Q (0x8100), length 100: vlan 1280, p 2, ethertype Unknown, LLC, dsap SNA (0x04) Group, ssap Unknown (0x3e) Response, ctrl 0x0000: Information, send seq 0, rcv seq 0, Flags [Response], length 80

Answer 1

I think tshark can cope with cooked capture today, I rarely if ever use tcpdump anymore.

Back when tshark couldn't cope with this (when I was capturing ERSPAN) I wrote script which can pop N bytes out of each frame, quite useful also if you're tunneling over something which is not recognized.

Answer 2

A couple of years later.... :D

I have run into the same problem.

With hours of tcpdump and wireshark, I have figured out what the problem is, or what I have done wrong.

After the VLAN tagged (from this point of view, tag value is not important) packet is received and sent towards, I (the switch program I have written) accidentally forgot to add the respective VLAN header to the packet header, however Ethernet.etherType was still 0x8100 (VLAN's ETHERTYPE). This means that after the Ethertype, application (in our case tcpdump/wireshark) was expecting a 4-byte VLAN header but the IPv4 header was coming. Since IPv4 starts with 4 bits of version (set to 4), 4 bits of header length (which if normal IPv4 packets are considered, e.g., 20bytes, is set to 5), then comes 8 bits of diffserv, etc., e.g., IPv4 header starts with 0x4500...

This means that the first 4 bits are considered as a 3-bit wide VLAN PCP, and a 1-bit wide VLAN DEI (this is 0x4 in our simple IP packet), then the remaining 12-bits will be the VLAN VID, which is 0x500 from the simple IP packet resulting in a mistaken 1280 VLAN VID (int('0x500',16) = 1280).

I hope it helps.