Wireshark-dev: Re: [Wireshark-dev] Rev 38350 Capture Options Changes - Named Pipe?
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Thu, 11 Aug 2011 19:41:25 -0700
On Aug 11, 2011, at 6:00 AM, Joerg Mayer wrote:

> While everyone seems to be adding their wishes, now that someone is actually
> is working on that code: Would it make sense to add a button (or whatever)
> to scan for newly created/activated interfaces? When I'm running Wireshark
> and add a new interface (I'm on Linux and run e.g. "iw dev wlan0 interface add
> mon0 type monitor" + "ifconfig mon0 up"

Actually, in that case, if Wireshark is using libpcap 1.1.0 or later, selecting wlan0 and checking the monitor mode checkbox should cause Wireshark to tell libpcap to do all that for you (by telling it to capture in monitor mode).

> or just up an interface that was down,
> I need to restart Wireshark for the new interface to be detected.

That sounds like a bug - it shouldn't be caching the interface list in Wireshark forever; at least if you open a new "Capture Options" dialog, it should re-run dumpcap to get the interface list again.

It won't update the interface list on the welcome page...

> Checking
> for new interfaces at runtime

...but I'll see whether adding an API to libpcap to provide a way to be notified when new interfaces appear is possible.  (It's going to be platform-dependent - there's probably something in Linux to do it, maybe netlink, it'd probably be done in Mac OS X with the System Configuration framework, etc..)

> or be shown also interfaces that are admin down would be a nice to have :-)

If it's not showing them to you, it's probably not possible to capture on them; what happens if you try to run tcpdump or dumpcap on them?  On OS X Snow Leopard, at least:

	$ ifconfig -a
	lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
		inet6 ::1 prefixlen 128 
		inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
		inet 127.0.0.1 netmask 0xff000000 
	gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280

		...

	$ tcpdump -i gif0
	tcpdump: gif0: That device is not up 

BPF won't let you bind to a device that's not up; I'd have to look at other BPF implementations to see if they impose similar restrictions.  I also tried it on my Ubuntu 9.10 virtual machine, and, after configuring an interface down, I got the same error (ENETDOWN in both cases).