Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 20049: /trunk/ /trunk/epan/dissector
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.