yohann.thomas at rd.francetelecom.com
Tue Jan 18 08:59:41 PST 2005
The problem finally comes from the "checksum offloading" functionality
on the NICs, since when disabled, we don't have any more bad checksums.
In fact, checksum offloading is due to eliminate host-side checksumming
overheads by performing checksum computation with hardware assist in the
NIC, but apparently, it doesn't work perfectly.
This functionality was not implemented on our 100Mbps cards, but it is
on gig-capable ones.
So, the problem is solved on FreeBSD by disabling rxcsum and txcsum
*ifconfig /iface/ -rxcsum -txcsum*
(depending on the NICs...In fact, some controllers have only txcsum
functionality and others have both)
With Linux, ethtool solves the problem :
*ethtool -K /iface/ rx off tx off*
Kevin Schmidt wrote:
>On Monday 17 January 2005 10:05 am, you wrote:
>>-I confirm the bad tcp checksums when capturing with tcpdump
>>>> 2.Bro 0.8a37 (package) on FreeBSD 5.3
>Just FWIW, I'm running a FreeBSD 5.3 GENERIC kernel on a Dell and have bad
>checksums with tcpdump using an nge interface. I don't have a solution
>(haven't really looked), but I thought I'd send a "me too" note to confirm
>you're not the only one who has seen this behavior. I'm not running bro on
>the 5.3 box so the checksum problem hasn't bothered me too much. The nge
>interface is gig-capable but runs at 100Mb as you describe. I've also
>noticed an apparent correlation between tcpdumps and panic reboots. Since it
>appears the problem exists across interface types (i.e. drivers), I wonder if
>it's a problem between libpcap and the drivers.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bro