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

Why some packets dropped by tshark without “-s” option ?

0

I use tshark to capture IPFIX packets on Ubuntu. When using the tshark commands without "-s" option, some expected packets are dropped incorrectly. But when the "-s 1500" option is added, it works well.

E.g: I run the tshark with different options on the same interface at almost same time.

[email protected]:/# tshark -i eth0 -w /tmp/tshark_tmp.cap -n -f "dst port 9999"
Running as user "root" and group "root". This could be dangerous.
Capturing on 'eth0'
890 ^C
90 packets dropped                    <== Why this info?

[email protected]:~#  tshark -i eth0 -w /tmp/tshark_tmp_1500.cap -s 1500 -n -f "dst port 9999"
Running as user "root" and group "root". This could be dangerous.
Capturing on 'eth0'
1022 ^C

And I find there are several packets are missing in the /tmp/tshark_tmp.cap. With the same filter, some packets in /tmp/tshark_tmp_1500.cap cannot be found in /tmp/tshark_tmp.cap.

[email protected]:/# tshark -r /tmp/tshark_tmp.cap -n -d udp.port==9999,cflow  -T fields -E header=y -e cflow.packets64 -e ip.src -e cflow.flowset_id -e cflow.direction -e udp.srcport -e cflow.enterprise_private_entry -R "cflow.srcaddr==192.168.110.46 && cflow.dstaddr==192.168.102.199" -2
Running as user "root" and group "root". This could be dangerous.
cflow.packets64 ip.src  cflow.flowset_id        cflow.direction udp.srcport     cflow.enterprise_private_entry
29      10.146.108.72   267     0       34193   ac:15:91:cb,ac:15:91:ca,06,ce:2c,1d:2f,04,00:b3:88:00:e9:80:00:00,00:00:00:00:00:00:0b:1a
29      10.146.108.72   266     1       34193   00:00:00:00:00:00:0b:1a


[email protected]:/# tshark -r /tmp/tshark_tmp_1500.cap -n -d udp.port==9999,cflow  -T fields -E header=y -e cflow.packets64 -e ip.src -e cflow.flowset_id -e cflow.direction -e udp.srcport -e cflow.enterprise_private_entry -R "cflow.srcaddr==192.168.110.46 && cflow.dstaddr==192.168.102.199" -2
Running as user "root" and group "root". This could be dangerous.
cflow.packets64 ip.src  cflow.flowset_id        cflow.direction udp.srcport     cflow.enterprise_private_entry
61      10.146.108.72   267     0       34193   ac:15:91:cb,ac:15:91:ca,06,ce:2c,1d:2f,04,00:b3:88:00:e9:80:00:00,00:00:00:00:00:00:17:5a
61      10.146.108.72   266     1       34193   00:00:00:00:00:00:17:5a
61      10.146.108.86   266     0       43549   00:00:00:00:00:00:17:5a
32      10.146.108.86   267     1       43549   ac:15:91:cb,ac:15:91:ca,06,a9:07,1d:2f,04,00:b3:88:00:e9:80:00:00,00:00:00:00:00:00:0c:40
29      10.146.108.86   267     1       43549   ac:15:91:cb,ac:15:91:ca,06,ce:2c,1d:2f,04,00:b3:88:00:e9:80:00:00,00:00:00:00:00:00:0b:1a
29      10.146.108.72   267     0       34193   ac:15:91:cb,ac:15:91:ca,06,ce:2c,1d:2f,04,00:b3:88:00:e9:80:00:00,00:00:00:00:00:00:0b:1a
29      10.146.108.72   266     1       34193   00:00:00:00:00:00:0b:1a
29      10.146.108.86   266     0       43549   00:00:00:00:00:00:0b:1a
14      10.146.108.86   267     1       43549   ac:15:91:cb,ac:15:91:ca,06,a9:07,1d:2f,04,00:b3:88:00:e9:80:00:00,00:00:00:00:00:00:05:5c
15      10.146.108.86   267     1       43549   ac:15:91:cb,ac:15:91:ca,06,ce:2c,1d:2f,04,00:b3:88:00:e9:80:00:00,00:00:00:00:00:00:05:be

It confused me very much.

What is the default capture snaplen when without “-s” option?

All the packets I expected is less than 1500 bytes. But the dropped packets seems not related to packet length: only part of the packets with the same length are dropped. Why the packets are dropped?

asked 06 May ‘15, 02:56

Cathy's gravatar image

Cathy
5●1●1●2
accept rate: 0%

edited 06 May ‘15, 03:49

grahamb's gravatar image

grahamb ♦
19.8k●3●30●206

The tshark version info is: [email protected]:~# tshark -v TShark 1.12.2 (Git Rev Unknown from unknown)

Copyright 1998-2014 Gerald Combs [email protected] and contributors. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (32-bit) with GLib 2.34.0, with libpcap, with libz 1.2.3, without POSIX capabilities, without libnl, without SMI, without c-ares, without ADNS, without Lua, without Python, without GnuTLS, with Gcrypt 1.4.6, with MIT Kerberos, without GeoIP.

Running on Linux 2.6.32-5-686, with locale en_US.UTF-8, with libpcap version 1.5.3, with libz 1.2.7.

Built using gcc 4.1.2 20080704 (Red Hat 4.1.2-55).

(06 May ‘15, 20:16) Cathy

Why the packets are dropped?

Is this a virtual machine or real hardware?

(06 May ‘15, 22:01) Kurt Knochner ♦

A virtual machine on KVM.

(06 May ‘15, 22:03) Cathy

well, could that be the problem?

Do you see packet drops if you run both tcpdump commands separately? If so, is the packet drop rate the same, higher or lower if you run both captures at the same time?

What happens if you run both tcpdump commands with -s 1500? Still missing packets? If so, what is the number of dropped frames for each tcpdump command? Try to start them “almost” at the same time (through a script) or start sending traffic only after you’ve successfully started both capture commands.

(06 May ‘15, 22:13) Kurt Knochner ♦

I haven’t run tcpdump, but only run tshark.

In fact, I met the packet dropped issue when one of the tshark command is running. When I run the tshark command without “-s” option, I can see packet drops. And when the “-s 1500” option is added, the results are always OK in several runs. And then I run the two tshark commands, with “-s 1500” and without the option, at the same time to check what is the difference between the two results. The packet dropped issue only happens in the result of tshark without “-s 1500”.

About the packet drop rate, it varies in several runs without “-s” option.

(06 May ‘15, 23:21) Cathy

I haven’t run tcpdump, but only run tshark.

can you please try tcpdump or dumpcap instead of tshark for the capturing process?

(07 May ‘15, 01:20) Kurt Knochner ♦
showing 5 of 6 show 1 more comments

One Answer:

1

You are not specifying which version of Ubuntu you are using, 14.04 with libpcap >=1.5.3 performs better when it comes to packet drops. I think the difference you are seeing is that without -s the packet size is estimated at 65535 which allows fewer packets per capture buffer, by specifying -s 1500 more packets fits in the buffer and there is less packet drops. This may have been a bug in some libpcap version.

answered 06 May '15, 04:01

Anders's gravatar image

Anders ♦
4.6k●9●52
accept rate: 17%

Is this really true? I find it highly doubtful that there would be packets bigger than 1500 bytes (well OK, 1514 bytes), even if the snaplen was set to 65535. Could this simply be due to higher packet rates/bursts at the time the capturing was done and have nothing really to do with the snaplen? I suppose one could run 2 simultaneous captures, one with the default snaplen and one with a smaller snaplen to compare apples-to-apples.

(06 May '15, 07:02) cmaynard ♦♦

OK, but the maximum number of packets that would fit into the same buffer size would only be reduced if there were packets that were bigger than 1500 bytes, as compared to limiting the packets to that size, correct? If you set a snaplen of 1514 bytes, there really shouldn't be any difference as compared to leaving the snaplen at 65535 when capturing on standard Ethernet (assuming no jumbo frames) ... should there?

(06 May '15, 07:21) cmaynard ♦♦

If I remember correctly the lengt is reserved before the packet is seen.

(06 May '15, 07:51) Anders ♦

OH! If that's the case, maybe the default snaplen should be set much lower!?

(06 May '15, 08:00) cmaynard ♦♦

I think libpcap was patched to use MTU if that was possible to determine or something like that.

(06 May '15, 08:24) Anders ♦

Guy provides more details here (and probably other places too): http://stackoverflow.com/questions/9351664/optimal-snaplen-for-pcap-live-capture.

I guess I'll have to read up more on the differences between TPACKET_V1, V2, and V3. Seems like https://www.kernel.org/doc/Documentation/networking/packet_mmap.txt is the place to do that.

(06 May '15, 08:39) cmaynard ♦♦

Thanks for your help. It sounds reasonable and helpful.

But the count of the packets that match the filter "dst port 9999" is not very big, only about 1000 pkts in 3 minutes, and the burst is not more than 100 pkts/sec. Is it so easy to make the capture buffer full?

(06 May '15, 20:23) Cathy

Just out of curiosity, what version of libpcap and tshark are you using?

(06 May '15, 20:35) Anders ♦

[email protected]:~# tshark -v

TShark 1.12.2 (Git Rev Unknown from unknown)

Copyright 1998-2014 Gerald Combs [email protected] and contributors. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (32-bit) with GLib 2.34.0, with libpcap, with libz 1.2.3, without POSIX capabilities, without libnl, without SMI, without c-ares, without ADNS, without Lua, without Python, without GnuTLS, with Gcrypt 1.4.6, with MIT Kerberos, without GeoIP.

Running on Linux 2.6.32-5-686, with locale en_US.UTF-8, with libpcap version 1.5.3, with libz 1.2.7.

Built using gcc 4.1.2 20080704 (Red Hat 4.1.2-55).

(06 May '15, 23:22) Cathy
showing 5 of 10 show 5 more comments