Bugzilla – Bug 473297
Does not reliably capture packets using tcpdump due to libpcap
Last modified: 2010-01-04 17:35:22 UTC
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12 With the Suse 11.1 distribution, use tcpdump to capture packets for example on the local interface. Good chance that you are missing most of the packets. Reproducible: Always Steps to Reproduce: In one window run : # iperf -s -i 1 -u In a second window run : # tcpdump -i lo -w /tmp/mytrace.eth In a third window run : # iperf -c localhost -u -i 1 -b 1000k -t 100 After 100 seconds, iperf -c sent 8505 packets (udp) Now stop the tcpdump, and it will report the number of packets. Consider to use wireshark to further read the captured data file. This should be 8507 packets (two more that 8505 due to iperf reporting) Note that extra packets may be captured, so some filtering with tcpdump parameters may be needed to only see the iperf packets. Instead of this procedure, you can run ping for a few minutes, and draw the same conclusion. Actual Results: The captured file does not contain all the packets, while the communication path itself does not show any packet loss. Therefore the conclusion is that the capturing method seems to be unreliable. This test has been accomplished on a x86_64 pc. A former Suse release 10, does not show these problems. Expected Results: All the packets should have been captured. To solve this issue, you need to rebuild tcpdump and wireshark using libpcap-1.0.0 or higher. The Suse 11.1 distributed version of libpcap is 0.9.8. ( you can check that with `rpm -qa | grep libpcap`. Download libpcap-1.0.0, configure, make, make install, and rebuild tcpdump etc.. Retest the above procedure. By the way, libpcap-1.0.0 does not include the missing 'any' interface. Refer to Novell ticket 463182 for this..
This issue seems to be somehow hardware dependent. The issue is reported on the following hardware : Intel D945GCLF2 which is an integrated dual core Intel Atom Processor which acts as a 4 cpu processor engine. It's a very powerful 6.75" 64 Bits processor. After the positive news regarding the upgrade to the latest libpcap 10.0.0, i am not so sure anymore that this was really the 'fix'. The same configuration has been setup on another 100% equal computer (same hardware, mem, and Suse 11.1 distribution) and the same problem is seen. Does it have to do with the assignment of the process to a threaded CPU in particular to the local interface 'lo' ? I will further investigate the issue. - Dick Gooris
I can not reproduce this issue on 11.2 M8 (x86_64). Could you please try M8 with your HW? Thanks.
I can not reproduce myself, no response from reporter.