On Thu, May 08, 2014 at 08:50:48PM +0200, Michael Tuexen wrote: > Dear all, > > while testing checksum offloading of UDP packets over IP with IP options, I > figured > out that my card > > dev.re.1.%desc: RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet > dev.re.1.%driver: re > dev.re.1.%location: slot=0 function=0 handle=\_SB_.PCI0.PE1F.LAN2 > dev.re.1.%pnpinfo: vendor=0x10ec device=0x8168 subvendor=0x1734 > subdevice=0x1159 class=0x020000 > dev.re.1.%parent: pci13 > dev.re.1.stats: -1 > dev.re.1.int_rx_mod: 65 > > computes the UDP checksum, but stores it in the packet at the place, where it > would be, > if there are no IP options. So it corrupts the options in the packet... > > I looked at sys/dev/re/if_re.c, but couldn't figure out how to fix it. Any > idea? >
re(4) has a very long history on its broken TX checksum offloading. So re(4) has many workarounds for known issues on several variants. re(4) controllers support TX IPv4/TCP/UDP checksum offloading. For 8168C/8168CP, TX IPv4 checksum offloading was disabled due to generation of corrupted frames. Could you show me the dmesg output(only re(4)/rgephy(4))? The vendor uses the same PCI id for its RTL8168/8111 family chips so dmesg output is necessary to know exact controller revision. _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
