IBM Support

Why wireshark marks TCP checksum and IP checksum field as incorrect even though communication is working fine?

Question & Answer


Question

When iptrace and tcpdump collected on aix/vios host and read using wireshark, why it marks TCP checksum and IP checksum fields as incorrect even though communication is working fine?

Answer

When iptrace and tcpdump collected on aix/vios host is read using wireshark, it marks TCP checksum and IP checksum fields as incorrect even though communication is working fine. To understand the reason for this behavior, lets understand large_send, large_receive and which layer iptrace is capturing the packet.

What is large_send?


When large_send is enabled, TCP can send up to 64K bytes of data with one call down the stack, which reduces host processing and reduces CPU usage. The Ethernet adapter then does the TCP segmentation offload to segment the data into the MTU sized packets, calculates TCP and IP checksum. The large_send is a device driver attribute and it is enabled by default.

The large_send is also known as TCP Segmentation Offload (TSO).

What is large_receive?
When large_receive is enabled, Physical Layer calculates TCP and IP checksum, and receive packets into larger packets before passing them up the stack. The CPU has to process fewer packets then when large_receive is disabled, which reduces CPU usage. The large_receive is a device driver attribute and it is enabled by default.

The large_receive also known as Large Receive Offload (LRO).

Which layer TCP and IP checksum are calculated and where iptrace is capturing the packet?
Figure below shows the layer where TCP and IP checksum are calculated and where iptrace/tcpdump captures the packets.



Configuration:
Host - ipaddress 5.0.0.240 configured on 10 Gb physical adapter
large_send = yes
large_receive = yes
checksum_offload = yes

Test:
- ftp client was ran on 5.0.0.70 and ftp server was ran on 5.0.0.240.
- ftp "put" and "get" was done to send and receive data.
- Iptrace was collected on 5.0.0.240.

Effect of large_receive=yes:
Frame 453 is a large_receive packet received by 5.0.0.240.



Effect of large_send=yes:
Frame 5999 is a large_send packet transmitted by 5.0.0.240.


  • For large_receive receiving packet, the dummy values ffff and 0 are filled in IP checksum and TCP checksum fields respectively.
  • For large_send transmitting packet, the dummy value ffff and MTU size (e.g. 5a8 in hex for MTU 1500) are filled in IP checksum and TCP checksum fields respectively.
  • When iptrace (or tcpdump) is read using wireshark, it calculates the IP checksum and TCP checksum and compares with the value in the packets. Since values in the packets are dummy value so comparison fails and it marks IP checksum and TCP checksum as incorrect even though packet is valid.
  • The large_send and large_receive are not done for small data packets and control packets such as SYN, ACK, FIN, RST. Below are the example of ACK and SYN packets showing IP and TCP checksum are not marked incorrect because large_send and large_receive are not done.
  • ACK packet:
  • SYN packet:

[{"Product":{"code":"SWG10","label":"AIX"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Component":"Network communications","Platform":[{"code":"PF002","label":"AIX"}],"Version":"Version Independent","Edition":"","Line of Business":{"code":"LOB08","label":"Cognitive Systems"}}]

Document Information

Modified date:
17 June 2018

UID

isg3T1024463