0

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?
sqr
  • 15
  • 3

1 Answers1

1

  • 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.

A.B
  • 11,090
  • 2
  • 24
  • 45
  • Thanks A.B Additional qquestion to that: 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. Can we somehow fix it not to see these bad checksum? Nowadays all NIC have rather checksum offloads enabled so it might happen all the time. – sqr Jun 09 '22 at 10:47
  • 1
    You can disable hardware acceleration which will force the OS to compute the checksum but will lower performance. This is per OS specific and your question doesn't tell what OS could be used. On Linux this is done using `ethtool --offload ...`. Or you can tell tcpdump to not display this (eg: `tcpdump --dont-verify-checksums ...` ). – A.B Jun 09 '22 at 11:01
  • Now I am looking again in ping output and another question I need to bring up: ICMP (1), length 148, bad cksum 0 (->9d33)!) 192.5.15.22 > 192.5.15.23: ICMP echo request, id ICMP (1), length 148) 192.5.15.23 > 192.5.15.22: ICMP echo reply, id 26245, seq 0, length 128 I understand the second ICMP ... I mean when the reply is caught because then at least we can compare checksum. But referring to the first line of ICMP when we see request why does it trying to compute? We send only request but checksum is compare based on some algorithm when full ICMP take happen, request -> reply. – sqr Jun 10 '22 at 08:14