Re: further plan wrt. monitor interfaces

[Daniel Drake <dsd@gentoo.org>]

Johannes Berg wrote:
> 1)
> Define new filter flags
>  * FIF_PROMISC_IN_BSS	(BSS filters still on, but otherwise promisc)
>  * FIF_ALLMULTI		(all multicast frames are allowed through)
>  * FIF_BROADCAST	(broadcast frames are allowed through)
>  * FIF_FCSFAIL		(frames with bad FCS are allowed through)
>  * FIF_PLCPFAIL		(frames with bad PLCP checksum are allowed through)
>  * FIF_CONTROL		(control frames are shown)
>  * FIF_OTHER_BSS	(frames from other BSSes are shown, subject to the
> 			 other filters)
> [missing anything?]

Incase this wasn't clear to anyone else, the proposal is that we add a 
bitfield to the set_multicast_list parameters for the above flags. The 
stack would then 'fabricate' some calls to set_multicast_list.

I like the filter flags concept here, but I think this may be better as 
its own callback, or perhaps we should just rename set_multicast_list to 
configure_filter or something like that.

This also sounds nice to implement from a driver standpoint. After 
documenting how I feel the soft/hard monitor interfaces should behave 
should we have such a system, I'm not keen on the idea of actually 
implementing that.


As for the other problems mentioned in followup mails, how about 
something like the following:

A new configure_device callback with these parameters:
  - ieee80211_hw *hw
  - int state: possible values NOCHANGE, ON, OFF
  - int filter_flags: FIF_ flags from above
  - u8 *mac_addr

This would combine the ideas of add_interface, remove_interface and 
open/stop into one.

state: this would become ON when the first interface is brought up, and 
would become OFF when the last interface is brought down. For all other 
calls into this function, state is NOCHANGE

filter_flags: Johannes' proposal above

mac_addr: if NULL, do not do anything. Otherwise, change the device MAC 
address to the one provided. This may be provided as all-zeros in some 
situations.

During a fairly standard session, the callback would be called in the 
following ways:

Device gets plugged in, registers interface. Default managed wlan0 gets 
created.
User brings wlan0 up.
    -> callback called with (hw, ON, default FIF, device MAC)
    -> driver powers up device, sets mac address and filtering
User creates new additional monitor interface and brings it up
    -> callback called with (hw, NOCHANGE, new FIF, NULL)
    -> driver changes filtering params
User deletes managed interface (wlan0)
    -> callback called with(hw, NOCHANGE, maybe new FIF?, 0x000000000000)
    -> driver changes filtering params and writes zero mac addr
User deletes monitor interface
    -> callback called with (hw, OFF, dontcare, dontcare)
    -> driver powers down device

After thinking through the above, I wonder if we should also roll 
config_interface into this: also pass in a BSSID for RX filtering 
purposes (or NULL of no change required).

Also I was wanting to add communication from mac80211 to the driver 
about supported rates in the ESS (softmac does this, zd1211rw uses this 
info). This would also fall in the same category. And maybe we should 
add the multicast list above too.

I feel the above would make life fairly easy for drivers, or am I 
over-designing this? Perhaps I am also missing some considerations for 
IBSS/AP mode...

Daniel