Wireshark-dev: Re: [Wireshark-dev] Problems with capturing on multiple interfaces
From: "Jim Young" <[email protected]>
Date: Fri, 20 May 2011 12:49:23 -0400
>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/