This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Are there conditions that can cause Wireshark to “drop” packets?

1

Hi,

I'm using Wireshark 1.8.9 on SLES11 SP1. The environment it is being used in is a lab with very low latencies (~3ms). I'm capturing sequences of packets that consist of sending a single ping to the outside world through 8 sequential collection points, expecting the result of the capture to always consist of 16 packets. Wireshark is reading directly from a single NIC which is supplying the traffic from the 8 collection points.

After a lot of testing, I've discovered that I don't always collect 16 packets in Wireshark. In a typical test run of 300 pings, I might only get ~450 packets instead of the expected 480. This seems to happen ~80% of the time.

However, if I switch to using "tcpdump -n -s 0 -i NIC -w File.pcap", I find that I consistently capture all 480 packets.

Can someone explain, or speculate, on what might cause this?

I've already tried turning promiscuous mode on/off as well as delaying the display of packets until the end of the capture.

Thanks!

asked 30 Sep '13, 08:26

mlampell's gravatar image

mlampell
21●2●2●6
accept rate: 0%

1

Do you lose packets if you use dumpcap directly to do the capture ?

Dumpcap is the 'capture' part of Wireshark. It just captures to a file w/o doing any dissection; The file can then be read by Wireshark.

See the dumpcap man page for all the details as to command-line options, etc.

"dumpcap -i NIC -P -w file.pcap"

will create a .pcap file. (-P forces pcap format instead of pcapng format).

Also: what is the speed of your network ?

(30 Sep '13, 08:45) Bill Meier ♦♦
1

I might only get ~450 packets instead of the expected 480.

those missing packets: Are they at the beginning, at the end or just randomly distributed in the capture file?

I'm using Wireshark 1.8.9 on SLES11 SP1.

Is that real hardware or a virtual machine?

(30 Sep '13, 14:56) Kurt Knochner ♦

Thanks for both comments. Here are some answers:

  • yes, I lose packets with dumpcap, both with -p and without -p. The pattern is similar to that which I get using wireshark directly. The only application that doesn't appear to lose any packets is tcpdump.

  • the network is running at 1 Gbps. The timing between the packets is very close, to within a few tens of microseconds, e.g:

1 2013-09-30 19:36:47.857667000

2 2013-09-30 19:36:47.857755000

3 2013-09-30 19:36:47.858032000

4 2013-09-30 19:36:47.858360000

5 2013-09-30 19:36:47.858409000

6 2013-09-30 19:36:47.858605000

7 2013-09-30 19:36:47.873108000

8 2013-09-30 19:36:47.873142000

9 2013-09-30 19:36:47.873452000

10 2013-09-30 19:36:47.873528000

  • the "missing" packets are occurring throughout the capture, they don't appear to occur in any pattern

  • this is real hardware, not a VM

And a question/theory:

Is it possible that the times are so close that some of the messages are being interpreted by Wireshark/dumpcap as occurring in the past and therefore being discarded by Wireshark?

If so, why would this behavior not happen with tcpdump?

Thanks for your help!

(30 Sep '13, 18:19) mlampell
2

yes, I lose packets with dumpcap,

does dumpcap print any message about dropped packets after you stopped it? Can you please post that message?

Is it possible that the times are so close that some of the messages are being interpreted by Wireshark/dumpcap as occurring in the past and therefore being discarded by Wireshark?

No, Wireshark will not throw away any packet due to that reason.

If so, why would this behavior not happen with tcpdump?

That's the key question here. Maybe your dumpcap is linked to a different libpcap.

Can you please post the output of the following commands?

ldd `which tcpdump`
ldd `which dumpcap`

(01 Oct '13, 03:15) Kurt Knochner ♦

@mlampell: Please add a dummy comment (just a few words). I will paste the ldd output you sent me into that comment.

O.K. I'm posting this on behalf of @mlampell as the system treats him as spammer right now (maybe to many tries to post a link !?!)

Output when I stop dumpcap:
>dumpcap -iVNIC3 -s0 -w 300dumpcap3.pcap Capturing on VNIC3
File: 300dumpcap3.pcap
Packets captured: 4662
Packets received/dropped on interface VNIC3: 4662/138 (97.1%)
Output from the ldd commands:
> ldd which tcpdump
        linux-vdso.so.1 =>  (0x00007fff2ddff000)
        libpcap.so.0 => /usr/lib64/libpcap.so.0 (0x00007fc8d8514000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fc8d81b6000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fc8d874a000) 
> ldd which dumpcap
        linux-vdso.so.1 =>  (0x00007fff8c1ff000)
        libwsutil.so.2 => /usr/local/lib/libwsutil.so.2 (0x00007f65afae5000)
        libgthread-2.0.so.0 => /usr/lib64/libgthread-2.0.so.0 (0x00007f65af8e0000)
        libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007f65af61a000)
        libpcap.so.0 => /usr/lib64/libpcap.so.0 (0x00007f65af3e4000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f65af1ce000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f65aefb1000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f65aec53000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f65aea4a000)
        libgmodule-2.0.so.0 => /usr/lib64/libgmodule-2.0.so.0 (0x00007f65ae846000)
        libpcre.so.0 => /usr/lib64/libpcre.so.0 (0x00007f65ae616000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f65afceb000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f65ae412000)
(01 Oct '13, 08:30) Kurt Knochner ♦

O.K. The path to libpcap is that same, so the difference between the behavior of tcpdump and dumpcap is probably not related to that.

As you can see, dumpcap indeed drops packets. Maybe there is simply too much traffic, so dumpcap was not able to write every frame to disk. Please use capture filters to reduce the amount a captured packets. The capture filter syntax is the same as with tcpdump.

dumpcap -ni VNIC3 -s0 -w 300dumpcap3.pcap -f "host x.x.x.x and port yyyy"

BTW: What is VNIC3? How is that interface defined on your system?

(01 Oct '13, 08:40) Kurt Knochner ♦

Re: Kurt\'s suggestion, I can\'t limit the traffic any further; the only traffic being captured is the 16 ping messages.

O.K. if I look at the output of dumpcap, there is no plausible reason why it drops 3% of the packets if there are only 4662 packtes !?!

Packets received/dropped on interface VNIC3: 4662/138 (97.1%)

(02 Oct '13, 07:18) Kurt Knochner ♦

The only reason I can imagine for the dropped packets: Some of those 4662 frames are hitting the sniffer interface in a very, very short period of time and thus flooding the capture buffer. If you look at the IO graphs, do you see a (large) spike somewhere?

(02 Oct '13, 07:44) Kurt Knochner ♦

Hello Kurt, thanks for the input. By the way, I created a new login, mlampell2, to allow me to continue posting...

I don't see any spikes, and I'm still confused about why now both tcpdump and dumpcap are capturing all the packets, yet some are lost during the "transfer" to the Wireshark GUI. Any ideas for how to troubleshoot this further?

(02 Oct '13, 07:52) mlampell2

I'll convert some comments to answers. Plesse accept the answer of Bill Meier. If you like, you can up vote my answer.

(02 Oct '13, 09:36) Kurt Knochner ♦
showing 5 of 10 show 5 more comments

2 Answers:

1

Do you get a better result with dumpcap if you use a larger 'kernel buffer size' ?

dumpcap ... -B 6 ...

The default size for dumpcap 1.8 is apparently 1MB (according to the help):

... -B <buffer size=""> size of kernel buffer (def: 1MB) ...

(The development dumpcap help says

-B <buffer size=""> size of kernel buffer in MB (def: 2MB)

Looking at the code, the buffer size is also specified in MB for dumpcap 1.8

answered 01 Oct '13, 09:26

Bill%20Meier's gravatar image

Bill Meier ♦♦
3.2k●1●8●50
accept rate: 17%

Thanks Kurt and Bill both.

Re: Kurt's suggestion, I can't limit the traffic any further; the only traffic being captured is the 16 ping messages.

The VNIC3 is a virtual NIC that is aggregating the traffic from one or more physical NICs. So far I have not considered the VNIC3 to be suspect since all the traffic is being captured with tcpdump.

It appears that Bill has found a partial answer (thanks Bill!) By increasing the size of the kernel buffer to 6 (from the default 1), I am now capturing all 4800 packets using dumpcap -B6. However, when I switched to wireshark, I did not get all the packets all the time, even with this option. I tried as high as -B30 but I still lost 148/4800 packets.

I also tried using the Wireshark option to not display packets in real time. In this mode Wireshark shows a blank screen until I stop the capture and then shows all the captured packets. Using this option I still lost 147 packets.

Any suggestions for how to get wireshark to display ALL packets now that dumpcap seems to be capturing all of them?

(02 Oct '13, 07:17) mlampell2

0

Did you change the buffer size in Wireshark as well?

Edit -> Preferences -> Capture -> Interfaces Edit [Button]

Select the interface then check the field: Default Buffer size

answered 02 Oct '13, 08:04

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k●10●39●237
accept rate: 15%

On my version of Wireshark, 1.8.9, on SLES 11 sp1, I don't see an option on that interface to change the default buffer size. Instead, I was using the option "-B 30" when invoking wireshark from the command line, and this is not solving the problem.

(02 Oct '13, 08:16) mlampell2

O.K. in 1.8.x the option is in a different menu.

Capture -> Options

Double click the interface and you'll see the buffer size.

(02 Oct '13, 08:31) Kurt Knochner ♦

Wow, that did the trick! Thanks very much. Don't know why passing the -B option on the command line isn't doing the same thing, but at least I have a usable workaround.

How do I turn this into the official answer for the question? Plus, if possible I would like to acknowledge both Kurt Knochner and Bill Meier, since Bill originally put me on the path to investigate the -B option.

Thanks again!

(02 Oct '13, 08:59) mlampell2