Hi,
You are aware that it's libpcap that does the actual capturing?
See the keynote given by Steve McCanne, 'the guy who made it', at
SharkFest'11:
http://sharkfest.wireshark.org/sharkfest.11/
Dive into that stuff to see what intricate details come into play here.
Thanks,
Jaap
On Wed, 16 Nov 2011 14:51:42 +0000, Eric Ewanco wrote:
I'm seeing a very strange problem and I'm curious to see if anyone
has run across it.
We're trying to do a simple loopback test: Generate 1000 UDP packets
using pacgen at 50 pps, loop them back, and count them with tshark
(1.4.2-1.1-1).
The problem is under most circumstances tshark ignores about 379
packets, that is to say, it counts 621 packets and stops, even though
the packets are received at the interface. Often it will work one
time, and then have trouble on subsequent runs.
The problem appears to be timing related (see below). My version of
tshark can't seem to handle bursts of tightly-spaced packets under
some circumstances. Is there a known bug with a source patch that
doesn't require upgrading our Linux distribution (OpenSuSE 11.1)?
The "lost" packets are counted by ifconfig and not accounted for by
any of the dropped counters in /proc/net/snmp or other places in
/proc/net, but tshark doesn't recognize them. The capture file
corresponds to the printed counts; the lost packets do not show up
there. I can even do a capture on the transmit side and find more
packets received on the receive side than are counted by tshark on
the
transmit side. However, if I monitor both transmit and receive, the
dynamics change and it almost works; I lose only about a dozen
packets.
If I use tcpdump instead of tshark, everything is copacetic. It also
works fine when I transmit an identical packet to tshark using a
different program (hping3). Dumpcap works better but still loses
packets on several runs (drops of 28, 12, 70 out of five runs of 1000
packets).
Command line:
tshark -i eth5 udp -c 1000 -w /tmp/eth5.cap
It seems to be there has to be some sort of timing issue. According
to the capture log, the first 50 packets are received over the course
of 470 us about 5-15 us apart. Then the pacgen transmitter waits
about
one second 100 us and transmits another 50. When I do a flood ping
(which works fine), the rate is much lower, every 200 ms or so. If I
do a flood ping with hping3 (which works, at least until I get to
hundreds of thousands of packets, and then it loses only 0.05%), it
sometimes has a similar gap to pacgen, but it doesn't sustain it and
leaves large gaps pacgen does not leave. I did notice that if I slow
pacgen down to 25 or 10 pps, it works more reliably, although even at
ten pps I've occasionally seen a loss.
Platform is a customized OpenSuSE 11.1 on Intel. I verified this
using stock Wireshark on a stock OpenSuSE 11.3 laptop with similar
results.
We've tested 0.10.13, 1.2.4, 1.2.8, and 1.4.4-0.2-1 in addition to
1.4.2-1.1-1. Because of its dependencies we can't use a later
wireshark; but if we can cherry-pick a fix we may do that. Using
0.10.13 and 1.2.4 seems to work fine; the other two fail.
I checked the bug database for bugs in any state with summary or
comment with search terms "burst", "drops", "dropped", "overrun",
"loses", and "lost". If you can suggest any others (I find this is a
difficult bug to come up with keywords for) feel free to do so.
Thanks for any help.
bl-s1r1-24:~/hardware_test # tshark -v
TShark 1.4.2
Copyright 1998-2010 Gerald Combs 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 (64-bit) with GLib 2.18.2, with libpcap 0.9-PRE-CVS, with
libz 1.2.3,
with POSIX capabilities (Linux), with libpcre (version unknown),
without SMI,
without c-ares, with ADNS, with Lua 5.1, without Python, with GnuTLS
2.4.1, with
Gcrypt 1.4.1, with MIT Kerberos, without GeoIP.
Running on Linux 2.6.34.4-gb05, with libpcap version 0.9-PRE-CVS,
with libz
1.2.3.
Built using gcc 4.3.2 [gcc-4_3-branch revision 141291].
