You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,
We are running Intel i40e driver with Geneve TSO offload and collecting TX traffic using tcpdump. When enabling the GSO_PARTIAL, the Linux network stack sends a 64k byte packet to the driver, but the tcpdump reports packet length of 1500, even though the caplen is 64k.
The reason is due to tunnel encapsulation with GSO_PARTIAL. The outer header could be vxlan or geneve, and GSO_PARTIAL carries multiple inner frame, with each inner frame an 1500 MTU size. So this confuses the tcpdump, which parses only the first inner frame and report length of 1500, instead of the sum of all inner frames.
It shows only the first frame of length 1448, but the actual caplen is 64k because there are more frame behind the first.
I looked at the source code and don't have a good solution. One way is to pass the caplen all the way to ip_print, tcp_print, so we know that there are still bytes not processed yet. Another quick solution is to enable printing a warning when tcpdump processes bytes less than caplen, or in command line adds an option to print out caplen so when people see the output "length" != caplen, they have to check by themselves.
System Info
tcpdump --version
tcpdump version 4.10.0-PRE-GIT_2017_03_13
libpcap version 1.7.4
OpenSSL 1.0.2g 1 Mar 2016
OS: ubuntu 16.04, Linux kernel 4.8
Steps to reproduce: download the pcap file and tcpdump -r
The text was updated successfully, but these errors were encountered:
Hi,
We are running Intel i40e driver with Geneve TSO offload and collecting TX traffic using tcpdump. When enabling the GSO_PARTIAL, the Linux network stack sends a 64k byte packet to the driver, but the tcpdump reports packet length of 1500, even though the caplen is 64k.
The reason is due to tunnel encapsulation with GSO_PARTIAL. The outer header could be vxlan or geneve, and GSO_PARTIAL carries multiple inner frame, with each inner frame an 1500 MTU size. So this confuses the tcpdump, which parses only the first inner frame and report length of 1500, instead of the sum of all inner frames.
An pcap file is attached:
geneve_gso_partial-2.pcap.txt
It shows only the first frame of length 1448, but the actual caplen is 64k because there are more frame behind the first.
I looked at the source code and don't have a good solution. One way is to pass the caplen all the way to ip_print, tcp_print, so we know that there are still bytes not processed yet. Another quick solution is to enable printing a warning when tcpdump processes bytes less than caplen, or in command line adds an option to print out caplen so when people see the output "length" != caplen, they have to check by themselves.
About GSO partial
https://netdevconf.org/1.2/slides/oct5/09_LCO_GSO_Partial.pdf
System Info
tcpdump --version
tcpdump version 4.10.0-PRE-GIT_2017_03_13
libpcap version 1.7.4
OpenSSL 1.0.2g 1 Mar 2016
OS: ubuntu 16.04, Linux kernel 4.8
Steps to reproduce: download the pcap file and tcpdump -r
The text was updated successfully, but these errors were encountered: