>Chris Maynard <> 5/20/2011 10:25 AM
> To me, if it doesn't work without -n and -t, then it makes it that much more
> user-friendly to automatically use pcapng and threads whenever multiple
> interfaces are specified.
+1 to automagically do -n -t when more than one
interface is specified.
Here's some additional observations:
Last night I managed to play around a little bit with using dumpcap
and the multiple interface feature on my MacBook Pro.
(NOTE: My testing was done using a self-built Wireshark suite
using the jhbuild environment. [1][2][3]. I will re-test later
today with a buildbot version.)
dumpcap -D listed four interfaces on my MacBook Pro:
en0
fw0
en1
lo0
When I used the command:
./dumpcap -I -i en1 -i fw0 -t -n -w iftest.pcapng
I got the message:
"The capture session could not be initiated (That device doesn't support
monitor mode)."
If I remove the -I option then dumpcap starts (although there were
no packets captured on the fw0 interface (or the lo0 when tested)
which was expected. Changing the order that the options were specified
did not seem to resolve the issue with the -I option.
I did successfully use the -I with multiple interfaces by entering the same
interface "en1" twice as in the following command:
./dumpcap -i en1 -I -i en1 -t -n -w iftest2.pcapng
After entering ^C the I believed I had captured 3650 packets on
the "en1" interface and 191 packets on the "en1" interface with
no packets dropped on either interface! So I expected to see
3841 packets in the trace file.
But when I opened the file in Wireshark I actually had 3828 packets.
The number 3838 just happened to be the last "Packets:" report
generated by dumpcap before the ^C was processed. So it looks
like I lost 204. A display filter of "eth" lists 191 packets. A
display filter of "radiotap" lists 3637 packets. So it appears
that some of the "radiotap" packets were lost during the close
capture processing.
Some further testing with just a single interface with and without
threading shows that actual packets written to the capture file
is the last "Packets: " value and not the value reported in the
interface summary message. e.g.:
Packets: 3543 ^CPackets captured/dropped on interface en1: 3547/0
In the example above only 3543 packets were seen in the capture,
not 3547.
Another observation when using multiple interfaces is that time stamps
associated with about every 40th frame (+/- 1 or so) is earlier than the
preceding frame. These packets can be displayed with the display
filter:
frame.time_delta < 0
In the iftest2.pcapng trace file used earlier I had 84 frames that were
not in strict chronological order.
I hope you find this information useful in enhancing this great new
feature.
Jim Y.
[1] http://live.gnome.org/GTK%2B/OSX/BuildInstructions
[2] http://sourceforge.net/apps/trac/gtk-osx/wiki/Build
[3] http://gtk-osx.sourceforge.net/