Search Linux Wireless

Re: further plan wrt. monitor interfaces

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux