Re: [Madwifi-users] .11 Control Frames monitoring

[Sam L. <sa...@er...>]

> I use madwifi in monitor mode and I notice that I don't see any
> .11 control frames (ACK,RTS,CTS,PS-POLL). A little digging in
> the code reveals that control frames are not included in the
> mask while calling ath_hal_setrxfilter() in ath_mode_init()
> and in ath_newstate(). I added HAL_RX_FILTER_CONTROL to the mask
> when in monitor mode, yet I do NOT see control frames.
>

Monitor mode is orthogonal to setting the interface into promiscuous mode. 
That is, if you enter monitor mode and you want all frames then you also 
need to enable promiscuous filtering.  At least that's what the original 
intent was; don't recall exactly how it got added to the madwifi driver.

HAL_RX_FILTER_CONTROL is only meaningful to 5212-based cards.  You don't 
indicate what hardware you are using.  5210 and 5212 cards do not support 
this filter mask; the only way to get control frames is to enable 
promiscuous mode.

> I believe that the HAL is not processing the receive filter mask
> correctly. Greg/Sam can you check if this is the case ? Thanks.
>

The HAL basically passes the filter mask directly to the hardware so you 
have control at the driver level.  There are transformations done in the 
HAL to covert "pseudo-masks" to the equivalent hardware operations (e.g. 
enable PHY or radar errors), but otherwise WYSIWYG, but otherwise it's a 
"straight thru path".

The real problem is that the HAL API defines a set of masks that is the 
union of each hardware's capabilties but there is no way to tell what 
hardware supports what masks.  I'd prefer not to fail if a mask is set and 
not supported as that pushes chip-specific knowledge back up into the 
driver.  Otherwise it might be good to do something like not return 
unsupported filter bits when reading back the current filter mask; then you 
could query for support by setting all bits and then reading back the mask 
to find out which are supported.

> Eventually, we will have to get PS-Polls up to the WLAN layer
> so this is something that needs to be done anyway.

I think this has been answered already.  The hardware magically passes 
these up always (apparently there's no way to disable them) but the driver 
strips them.  When the wlan layer is ready to do something with them then 
we can remove that.  If this isn't happening then please contact me 
directly.

	Sam