When I start tcpdump, the -w parameter is ignored (no file is written) and an absurdly large amount of dropped packages is displayed. If I omit -w, everything seems fine, except for there is no file written, of course. Recent stable tcpdump-3.9.8-r1 works, the problem only occurs with tcpdump-4.3.0 which is stable right now. # tcpdump -w xxx -s 0 -i eth1 tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes ^C 794 packets captured 794 packets received by filter 0 packets dropped by kernel 4294967289 packets dropped by interface
Created attachment 331630 [details] emerge --info tcpdump
What type of storage are you dumping that file on?
(In reply to comment #2) > What type of storage are you dumping that file on? Never mind.
The file is probably written to /var/lib/tcpdump - see bug #334329.
(In reply to comment #0) > When I start tcpdump, the -w parameter is ignored (no file is written) and > an absurdly large amount of dropped packages is displayed. If I omit -w, > everything seems fine, except for there is no file written, of course. > > Recent stable tcpdump-3.9.8-r1 works, the problem only occurs with > tcpdump-4.3.0 which is stable right now. > > # tcpdump -w xxx -s 0 -i eth1 > tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 > bytes > ^C > 794 packets captured > 794 packets received by filter > 0 packets dropped by kernel > 4294967289 packets dropped by interface 2^32 - 4294967289 = 7
(In reply to comment #4) > The file is probably written to /var/lib/tcpdump - see bug #334329. Correct.
tcpdump simply grabs the stats that libpcap provides, so the problem is actually there. But ISTR that some kernel interface recently changed wrt networking.
ifconfig output RX/TX -- dropped: seems useful, since that value matches the missing number from the "dropped by interface: ifconfig eth0: eth0 Link encap:Ethernet HWaddr 00:30:6e:2b:ba:cd inet addr:10.0.0.140 Bcast:10.0.0.255 Mask:255.255.255.0 inet6 addr: fe80::230:6eff:fe2b:bacd/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13170602 errors:1 dropped:11581 overruns:0 frame:0 TX packets:14899924 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3794962031 (3.5 GiB) TX bytes:9504483720 (8.8 GiB) tcpdump -i eth0 -c 10: 10 packets captured 200 packets received by filter 96 packets dropped by kernel 4294955715 packets dropped by interface dropped_by_interface = 2^32 - ifconfig_dropped 4294955715 = 2^32 - 11581 pcap-linux.c calls linux_if_drops() before going into promiscuous mode and after leaving it, and compares both numbers in pcap_stats_linux().
(In reply to comment #7) > tcpdump simply grabs the stats that libpcap provides, so the problem is > actually there. But ISTR that some kernel interface recently changed wrt > networking. Hmmm. # tcpdump --version tcpdump version 3.9.8 libpcap version 1.3.0 ... # tcpdump -w xxx -s 0 -i eth1 tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes ^C 1214 packets captured 1214 packets received by filter 0 packets dropped by kernel The same library, different results.
(In reply to comment #9) > (In reply to comment #7) > > tcpdump simply grabs the stats that libpcap provides, so the problem is > > actually there. But ISTR that some kernel interface recently changed wrt > > networking. > > Hmmm. > > # tcpdump --version > tcpdump version 3.9.8 > libpcap version 1.3.0 > ... > # tcpdump -w xxx -s 0 -i eth1 > tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 > bytes > ^C > 1214 packets captured > 1214 packets received by filter > 0 packets dropped by kernel > > The same library, different results. Yes, the "packets dropped by interface" is entirely absent from 3.9.*, and hence the problem completely goes away. :)
Please report this upstream if it still occurs.