Closed Crazycuo closed 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.
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.
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?