Re: Problems with capturing on multiple interfaces

[Michael Tüxen <Michael.Tuexen () lurchi franken de>]

On May 20, 2011, at 6:49 PM, Jim Young wrote:

> > 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.
Committed in r37343.
> 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
OK.
> 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)."
Since you are specifying -I option before any interface, you request
-I for all of them. Since the monitor mode is not supported on the fw0
interface, you get the error. I guess what you want is:
./dumpcap -i en1 -I -i fw0 -t -n -w iftest.pcapng
This should work. Let me know if it doesn't.
> 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.
I think the problem is related to which numbers are used:
When you ^C, the capturing is stopped and no packets are
processed anymore. However, there can be some packets buffered
by the libpcap. The numbers displayed are the numbers including
the ones buffered by the libpcap but not written.
This is not consistent. I'll try to fix that. Please note that
this is not specific to the support of multiple interfaces.
The same is inconsistency in the older version of dumpcap,
only the number was not displayed, but written in the pcapng
file and not displayed (unless you compiled in debug output).
> 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.
Yepp. It is the inconsistency I described above.
> 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
For each interface a thread is running to handle the packets of that
interface. All packets have the correct time stamp. All packets
from each interface have increasing time stamps. However, the libpcap
does some buffering. So dumpcap writes packets from interfaces in a
bulk. Between the bulk, the packets might not be in order.
This is OK, since the packet format does not require all packets to
be in order.
> 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.
Sure. Thanks for testing and reporting!

Best regards
Michael
> 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/
>
>
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe