Re: [RFC PATCH v2 4/4] mac80211: add beacon filtering support

[Kalle Valo <kalle.valo@nokia.com>]

"Luis R. Rodriguez" <lrodriguez@atheros.com> writes:

> Last we reviewed this it seemed we were set on only allowing this for
> hardware which supports beacon filtering with support for checksumming
> of the beacons. Reason checksumming is important is for considerations
> of DFS with the channel switch announcements, HT with with channel width
> changes. In fact I'm curious why checksumming would be required for 2.4 GHz
> single band devices. Kalle, do you happen to know?

In my opinion also 2.4 GHz band needs checksum support. At least ERP
protection changes come to my mind, but maybe there are also others.

> Considering that power saving features are important I think its
> worth to revisit this position in detail.
>
> An alternative to this above position is that if the devices do not
> support checksumming of the beacons to let the driver figure when
> this should be enabled dynamically. For example if devices do not
> support checksumming but are single 2.4 GHz band non-HT capable
> devices we should let drivers enable this feature.
>
> Other devices which do not support checksumming should only enable this only
> when associating to an AP on non-DFS channels and when not using HT.

I'm not fully convinced about this.

> In practice this would mean allowing both ath5k and ath9k to take advantage
> of this feature.

Do you mean that they have beacon filter support but do not do any
checksumming in hardware?

Other option is that the hardware which does not support checksumming
would just pass beacons periodically to the stack, for example every 5
seconds. Even though beacon filter is enabled in mac80211 it does not
prevent hardware from sending beacons. This is not the most optimal
solution, but there's not much choices if the hardware doesn't support
checksumming.

> Technically we could move the conditional logic check when this
> should be enabled to mac80211 as well. When we reviewed this it was
> seen as unnecessary complexity, I actually don't see it as too
> complex and think the the advantage is worth to consider.
>
> Thoughts?

I think this is future stuff, I would like to get the basic (and the
simplest) implementation to the tree first and then we can start
improving and extending it.

-- 
Kalle Valo