I've been using Bro on my computer on different purposes for a few months and till now, it always worked well
Unfortunately, I'm experiencing a problem for a few days.
In fact, when running Bro (with http.bro script) on some other computers, I have series of "bad_tcp_checksum" (with Linux) or
"bad_ip_checksum" (with FreeBSD), and only a few packets seems to be read correctly.
To sum up, here is the current situation :
->Bro still works on my computer (Linux Debian, Kernel 2.4.26 - Bro 0.8a87)
->I have "bad_tcp_checksum" or "bad_ip_checksum" in these (tested) cases (on 3 other computers) :
1.Bro 0.8a87, 0.8a88, 0.9a7 on Linux Debian Kernel 2.6.8 and 2.4.26,
installed with the same mirrors (same versions of libpcap in particular)
2.Bro 0.8a37 (package) on FreeBSD 5.3
(Experiments were done on an operational network, but also directly between two computers with a crossover cable)
If it can be of interest (I don't really know why, but...), my computer has an
AMD PCnet32 ethernet controller. Bad checksums where obtained with Intel and
Hum... Any ideas are welcome...
Thanks by advance,
it looks like we should make sure it is actually a Bro problem first.
When you run tcpdump on the link with -vvv and capturing entire packets,
do you also see bad checksum warnings? Try to make sure the tcpdump is
using the same libpcap as Bro before trying.
Here are the last results of my investigation :
-I confirm the bad tcp checksums when capturing with tcpdump, and I confirm that there is no bad tcp checksum with the computer on which Bro works correctly (using in both cases libpcap-0.8.3-5, which is the same as Bro),
-Bro works offline for all the tested computers with a correct dump,
-Considering It “could” be due to the ethernet controller (strange, but…), I tried another one. In fact, my old computer had a PCnet32, so I tried this one on the other computer.
Result : it works !!! So, it first seems to confirm the problem isn’t due to a conflict between software versions.
Hum…In fact, I remember that I had Bro work very well with 3Com and Realtek chips, and also Intel e100…
…and suddenly, I come to the fact that the 2 computers on which I have bad tcp checksums have gigabit ethernet controllers…
Note that one is really used in a gigabit network, but the other one is on a 100Mbps network, so it is automatically restricted at 100Mbps.
So, my question is : Can the problem be due to the gigabit interfaces (even if one is used at a 100Mbps speed) ??? (Initialization problem ??? …)
Christian Kreibich 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.
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 options :
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: