[Wireshark-dev] buildbot failure in Wireshark (development) on OSX-10.5-x86

2011-05-20 Thread buildbot-no-reply
The Buildbot has detected a new failure of OSX-10.5-x86 on Wireshark 
(development).
Full details are available at:
 http://buildbot.wireshark.org/trunk/builders/OSX-10.5-x86/builds/3250

Buildbot URL: http://buildbot.wireshark.org/trunk/

Buildslave for this Build: osx-10.5-x86

Build Reason: 
Build Source Stamp: 37324
Blamelist: stig

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

___
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-requ...@wireshark.org?subject=unsubscribe


[Wireshark-dev] buildbot failure in Wireshark (development) on OSX-10.5-PowerPC

2011-05-20 Thread buildbot-no-reply
The Buildbot has detected a new failure of OSX-10.5-PowerPC on Wireshark 
(development).
Full details are available at:
 http://buildbot.wireshark.org/trunk/builders/OSX-10.5-PowerPC/builds/2795

Buildbot URL: http://buildbot.wireshark.org/trunk/

Buildslave for this Build: osx-10.5-ppc

Build Reason: 
Build Source Stamp: 37324
Blamelist: stig

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

___
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-requ...@wireshark.org?subject=unsubscribe


Re: [Wireshark-dev] Problems with capturing on multiple interfaces

2011-05-20 Thread Chris Maynard
Michael Tüxen Michael.Tuexen@... writes:

 You actually need:
 -n to use pcapng
 and
 -t to use threads.
 
 It is simple to add -n and -t if you are specifying more than one interface
 (actually this is what tshark and wireshark do). I wanted to be explicit
 since I consider it currently an experimental feature. But, if the groups
 prefers, we can add -n and -t if there is more than one interface specified.

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.

I understand this is still a work in progress, but something else I was thinking
about was the -i any interface.  What will happen if someone specifies
something like, -i eth0 -i any -i lo or variations thereof?  I assume it would
be treated as -i any only?

And speaking of -i any, obviously on Windows, that isn't supported ... but a
neat thing would be if it could be by internally scanning all interfaces and
treating it as if -i 1 -i 2 ... -i n were specified.

And while I'm at it ... another feature that I think would be nice to have would
be to be able to specify capturing on an interface that doesn't yet exist, such
as ppp0.  For my USB/PPP capturing, currently to get a capture of all traffic
over that interface, I either have to use usbmon or ppp's record option to
generate a pppdump file.  (OK, this last one isn't really specific to capturing
on multiple interfaces, but it's related to capturing so ...)

 Thanks for the feedback.
You're welcome ... thanks for the feature!
- Chris

___
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-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Problems with capturing on multiple interfaces

2011-05-20 Thread Tyson Key
Hmm, wouldn't using any was a means of nullifying other interfaces break
concurrent capturing on both the any interface and Bluetooth or USB
interfaces?

Still, I agree with Chris's suggestions, with regards to weak emulation of
an any interface under Windows; and speculative capturing (i.e. waiting
for a device to appear before capturing relevant traffic).

I'm liking the feature so far otherwise, though. (It means that I no longer
have to launch Wireshark or TShark *8* times, and dismiss a tonne of warning
dialogues just to do USB capturing).

Thanks, and keep up the good work!

Tyson.

On 20 May 2011 15:25, Chris Maynard chris.mayn...@gtech.com wrote:

 Michael Tüxen Michael.Tuexen@... writes:

  You actually need:
  -n to use pcapng
  and
  -t to use threads.
 
  It is simple to add -n and -t if you are specifying more than one
 interface
  (actually this is what tshark and wireshark do). I wanted to be explicit
  since I consider it currently an experimental feature. But, if the groups
  prefers, we can add -n and -t if there is more than one interface
 specified.

 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.

 I understand this is still a work in progress, but something else I was
 thinking
 about was the -i any interface.  What will happen if someone specifies
 something like, -i eth0 -i any -i lo or variations thereof?  I assume it
 would
 be treated as -i any only?

 And speaking of -i any, obviously on Windows, that isn't supported ...
 but a
 neat thing would be if it could be by internally scanning all interfaces
 and
 treating it as if -i 1 -i 2 ... -i n were specified.

 And while I'm at it ... another feature that I think would be nice to have
 would
 be to be able to specify capturing on an interface that doesn't yet exist,
 such
 as ppp0.  For my USB/PPP capturing, currently to get a capture of all
 traffic
 over that interface, I either have to use usbmon or ppp's record option to
 generate a pppdump file.  (OK, this last one isn't really specific to
 capturing
 on multiple interfaces, but it's related to capturing so ...)

  Thanks for the feedback.
 You're welcome ... thanks for the feature!
 - Chris

 ___
 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-requ...@wireshark.org?subject=unsubscribe




-- 
  Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___
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-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Problems with capturing on multiple interfaces

2011-05-20 Thread Jim Young
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/


___
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-requ...@wireshark.org?subject=unsubscribe


Re: [Wireshark-dev] Problems with capturing on multiple interfaces

2011-05-20 Thread Guy Harris

On May 20, 2011, at 9:49 AM, Jim Young wrote:

 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).

Presumably the -s option is per-interface, as the appropriate snapshot length 
might differ based on the link-layer and metadata headers provided.

If so, presumably the -I option should be per-interface as well, as it only 
applies to 802.11 devices.
___
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-requ...@wireshark.org?subject=unsubscribe


Re: [Wireshark-dev] Problems with capturing on multiple interfaces

2011-05-20 Thread Joerg Mayer
Hello Michael,

On Thu, May 19, 2011 at 10:50:25PM +0200, Michael T?xen wrote:
 it was a bug. I did not move the code for given up the permissions
 to a place where all interfaces were opened. I checked in a fix
 in r37311. Please retest and let me know if this fixes your issue.

Fixed of course :-)

Thanks!
   Joerg

-- 
Joerg Mayer   jma...@loplof.de
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
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-requ...@wireshark.org?subject=unsubscribe


Re: [Wireshark-dev] Problems with capturing on multiple interfaces

2011-05-20 Thread Joerg Mayer
On Fri, May 20, 2011 at 02:25:38PM +, Chris Maynard wrote:
 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.

Do we really need pcapng if multiple interfaces of the same type are specified
or is this only to make it possible to see which interface the packet was
captured on?

 And speaking of -i any, obviously on Windows, that isn't supported ... but a
 neat thing would be if it could be by internally scanning all interfaces and
 treating it as if -i 1 -i 2 ... -i n were specified.

I don't quite agree with this: any has a very specific meaning and will 
(normally)
create pcap output, while your proposal would create pcapng output. Also the 
linux
cooked capture type does not contain a L2 header. Maybe adding a new all 
pseudo
interface would be better.

Ciao
   Joerg
-- 
Joerg Mayer   jma...@loplof.de
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
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-requ...@wireshark.org?subject=unsubscribe


Re: [Wireshark-dev] Problems with capturing on multiple interfaces

2011-05-20 Thread Jakub Zawadzki
On Fri, May 20, 2011 at 02:25:38PM +, Chris Maynard wrote:
 And while I'm at it ... another feature that I think would be nice to have 
 would
 be to be able to specify capturing on an interface that doesn't yet exist, 
 such
 as ppp0.  For my USB/PPP capturing, currently to get a capture of all traffic
 over that interface, I either have to use usbmon or ppp's record option to
 generate a pppdump file.  (OK, this last one isn't really specific to 
 capturing
 on multiple interfaces, but it's related to capturing so ...)

I think it'd be nice feature to start, pause or stop captuing on any interface 
at any time.

But it'd be easier to implement if instead of running N-threads single dumpcap 
we run N dumpcaps...

Regards.
___
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-requ...@wireshark.org?subject=unsubscribe