TCPDump VLAN – Analyzing TCPDump Length with VLAN

tcpdumpvlan

I run ping:

ping -c 15 -s 120 -D 192.5.15.22

The same time I watch tcpdump:

tcpdump -n -e -vv -ttt -i iavf0 vlan
tcpdump: listening on iavf0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:00:00.000000 52:54:00:d6:e6:62 > 3a:db:46:ce:e8:b7, ethertype 802.1Q (0x8100), length 166: vlan 11, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 148, bad cksum 0 (->9d33)!)
192.5.15.22 > 192.5.15.23: ICMP echo request, id 26245, seq 0, length 128
00:00:00.000161 3a:db:46:ce:e8:b7 > 52:54:00:d6:e6:62, ethertype 802.1Q (0x8100), length 166: vlan 11, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 148)
192.5.15.23 > 192.5.15.22: ICMP echo reply, id 26245, seq 0, length 128
00:00:01.040554 52:54:00:d6:e6:62 > 3a:db:46:ce:e8:b7, ethertype 802.1Q (0x8100), length 166: vlan 11, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 148, bad cksum 0 (->9d33)!)

  1. If I am correct I see 166 bytes lenghts (166-120=46 bytes) because Ethernet field (18 bytes) is not seen by User Space. It is cut-off by the Kernel Space, am I right?
  2. I do not know why I see 148 bytes? 148-120=28 bytes, where is the rest up to 64 bytes?
  3. What is the reason of bad checksum?

Best Answer

  • Sending an ICMP packet with a data payload of 120 bytes.

  • The ICMP (echo request) header is 8 bytes for a total ICMP size of 128 bytes.

  • The IPv4 header of the packet carrying this ICMP payload is 20 bytes (when not using any IP option) for a total IPv4 packet size of 148 bytes.

  • The Ethernet header with additional 802.1Q header of the frame carrying this IPv4 payload is 18 bytes (instead of 14 bytes for non VLAN-tagged frames), for a total size of 166 bytes. Those 18 bytes might be hidden from applications working at IP layer, but they aren't hidden from everything (eg: tcpdump did capture them), whatever possible special format they might be available as. (Note: in the previous Wikipedia link, the Preamble and CRC/FCS are usually not seen by the system but only by the NIC and not counted toward the usual frame length.)

Apparent bad checksum in output is because of hardware acceleration. Most NICs can do IPv4 checksum offload in hardware/firmware so the NIC's driver and/or the network stack know(s) there's no need to do any checksum and the IPv4 checksum field isn't computed (or recomputed when routing) by the OS. As tcpdump captures the emitted frame before it is actually processed by the NIC's hardware/firmware this IPv4 field has still an incorrect value yet to be computed on the fly by the NIC.

Related Topic