LibtraceTeam / libtrace

C Library for working with network packet traces
GNU Lesser General Public License v3.0
158 stars 50 forks source link

tracepktdump got wrong Ethertype while using dpdk binds solarflare card #211

Closed Crazycuo closed 1 month ago

Crazycuo commented 1 month ago

i use dpdk to bind a SF card, meanwhile i have install libtrace by latest source code againest dpdk. when i use tracepktdump to capture pcaps from an interface which is bound to dpdk. i find the Ethertype is wrong.

(base) [root@EM-GBDF0H2 tracepktdump]# dpdk-devbind -s

Network devices using DPDK-compatible driver

0000:04:00.1 'XtremeScale SFC9250 10/25/40/50/100G Ethernet Controller 0b03' drv=vfio-pci unused=sfc,uio_pci_generic

Network devices using kernel driver

0000:02:00.0 'NetXtreme BCM5720 2-port Gigabit Ethernet PCIe 165f' if=com1 drv=tg3 unused=vfio-pci,uio_pci_generic Active 0000:02:00.1 'NetXtreme BCM5720 2-port Gigabit Ethernet PCIe 165f' if=com2 drv=tg3 unused=vfio-pci,uio_pci_generic 0000:03:00.0 'NetXtreme BCM5720 2-port Gigabit Ethernet PCIe 165f' if=com3 drv=tg3 unused=vfio-pci,uio_pci_generic 0000:03:00.1 'NetXtreme BCM5720 2-port Gigabit Ethernet PCIe 165f' if=com4 drv=tg3 unused=vfio-pci,uio_pci_generic 0000:04:00.0 'XtremeScale SFC9250 10/25/40/50/100G Ethernet Controller 0b03' if=enp4s0f0 drv=sfc unused=vfio-pci,uio_pci_generic Active 0000:05:00.0 'XtremeScale SFC9250 10/25/40/50/100G Ethernet Controller 0b03' if=enp5s0f0 drv=sfc unused=vfio-pci,uio_pci_generic Active 0000:05:00.1 'XtremeScale SFC9250 10/25/40/50/100G Ethernet Controller 0b03' if=enp5s0f1 drv=sfc unused=vfio-pci,uio_pci_generic Active

(base) [root@EM-GBDF0H2 tracepktdump]# tracepktdump -c 100 dpdk:0000:04:00.1 PMD: sfcefx 0000:04:00.1 #0: Rx checksum offloads cannot be disabled - always on (IPv4/TCP/UDP) Mon Oct 14 13:00:55 2024 Capture: Packet Length: 149/153 Direction Value: 0 Ethernet: Dest: 84:b5:4b:ed:00:00 Source: 07:00:95:00:82:9f Ethertype: 0xba45 unknown protocol eth/47685 Unknown Protocol: 47685 00 0f 53 aa 3a 91 c4 b2 39 41 eb a7 08 00 45 00 ..S.:...9A....E. 00 87 1f 4a 40 00 7e 06 57 c9 0a 05 65 3b 0a 05 ...J@.~.W...e;.. 0c 19 eb ec 20 1b 4b 04 71 e1 27 0d 82 8a 50 18 .... .K.q.'...P. 01 00 6c 4f 00 00 38 3d 46 49 58 54 2e 31 2e 31 ..lO..8=FIXT.1.1 01 39 3d 37 32 01 33 35 3d 30 01 33 34 3d 32 34 .9=72.35=0.34=24 30 01 34 39 3d 31 30 2e 35 2e 31 32 2e 32 35 5f 0.49=10.5.12.25 38 32 31 39 01 35 32 3d 32 30 32 34 30 39 32 33 8219.52=20240923 2d 30 39 3a 32 39 3a 32 32 2e 33 34 32 01 35 36 -09:29:22.342.56 3d 46 30 30 30 34 30 =F00040

as we can see, the pcap ether type is (0x0800), but tracepktdump gets 0xba45. it's libtracepktdump bug or dpdk bug PMD bug or sf driver bug?

salcock commented 1 month ago

From what I can tell, the Solarflare driver is placing its own 14 byte "prefix" header on the front of each captured packet, which is causing the issue here.

Libtrace does not have code to recognise or parse this prefix header, and it is not immediately obvious to me how libtrace would be able to detect the presence of such a header so that it can skip past it. From what I've read so far, it also appears that the prefix header may be different depending on the underlying linktype, which further complicates matters.

If there is a way for you to configure the NIC/driver to not add that prefix header, then tracepktdump will work as expected.

Longer term, I would like for libtrace to be able to handle this situation automatically but it is going to take some time for me to figure out how to do this. It is also going to be very difficult to test, as I don't have access to a SF NIC.

Crazycuo commented 1 month ago

Libtrace does not have code to recognise or parse this prefix header, and it is not immediately obvious to me how libtrace would be able to detect the presence of such a header so that it can skip past it. From what I've read so far, it also appears that the prefix header may be different depending on the underlying linktype, which further complicates matters.

i agree with you. i also think it's caused by SF driver. i had tried to use an Inter X710 NIC which doesn't have this issue.