kernel-2.4.7-10 tcpdump-3.6.2-9 Packets printed/captured counts seem to be pretty screwed up. ]# tcpdump -n tcpdump: listening on eth0 15:07:51.312993 802.1d config 8000.00:00:a2:ed:60:16.8003 root 8000.00:00:a2:ec:65:df pathcost 10 age 0 max 20 hello 2 fdelay 15 15:07:53.312805 802.1d config 8000.00:00:a2:ed:60:16.8003 root 8000.00:00:a2:ec:65:df pathcost 10 age 0 max 20 hello 2 fdelay 15 ^C -2147349966 packets received by filter -1073744432 packets dropped by kernel # Any traffic that's printed seems to trigger the problem. Before that, counts are 0/0. 1073744432*2 == 2147488864 -2^31 == -2147483648 looks like an arithmetic overflow.
New patch51 from #52654 seems to have broken this; leaving it out fixes this problem. :-( The libpcap-filter patch seems huge. Is all this really necessary? There have been other changes in CVS, and if you missed some implications of the new code, the results might not be pretty (for any app using libpcap)..
*** Bug 57004 has been marked as a duplicate of this bug. ***
The bug is present in Rh 7.2 too, not only in rawhide as this bug seems to imply.
*** Bug 58000 has been marked as a duplicate of this bug. ***
should be fixed in 3.6.2-10 or newer