Wireshark · Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 20049: /trunk/ /trunk/epan/dissectors/: Makefile.nmake p

[Guy Harris <guy@xxxxxxxxxxxx>]

Loris Degioanni wrote:

> Yes, this would be the optimal option, but it would require adding to 
> libpcap features that are not strictly "capture oriented", like setting 
> a channel or configuring a set of decryption keys.

I'd consideer setting a channel capture-oriented, as a capture 
application might want to have a UI that lets you set the channel or 
that does scanning.

Configuring decryption keys is another matter; I suspect that, for most 
"normal" 802.11 adapters (as opposed to capture-only adapters such as 
AirPcap), that's done as part of setting the machine up to connect to a 
given protected network.  If you're capturing in non-promiscuous or 
promiscuous mode, you're capturing only on the network you're on, as far 
as I know; only in monitor mode do you capture everything the radio 
picks up, and I don't know whether any adapters will do decryption in 
monitor mode.  (The channel is also configured if you're on a given 
network, but, in monitor mode, you're probably able to change the 
channel arbitrarily.)

> I'd like to hear what people think about extending libpcap in that 
> direction (Guy?); if it's considered interesting, I could give it a try.

I think some option for setting the 802.11 channel should be offered by 
libpcap, to hide the OS-dependent details.  My inclination would be to have:

	an extensible list of device settings, including monitor mode, channel, 
and anything else that a particular network type might have;

	a way to inquire what settings are available for a particular adapter 
(so that an analyzer can, for example, decide what to offer in the UI);

	a way to get the current value of a setting and to change the value of 
a setting;

	perhaps a way to set the initial value when you open the device, 
although I suspect that wouldn't have an advantage over opening the 
device and then changing the setting.