[PATCH 1/3] nl80211: Add support for probe response offloading

[Jouni Malinen]

On Sat, Oct 22, 2011 at 11:44:02PM +0200, Arik Nemtsov wrote:
> Thanks for pointing this one out. We'll add a capability bit for
> interworking. Can you think of other scenarios like this?

Some.. In the published IEEE 802.11 amendments, there is a requirement
on being able to use DSSS Parameter Set element (Current Channel) to
filter out probes in 2.4 GHz is radio measurements are enabled
(802.11k).

There is additional work happening outside IEEE for some new protocols
that affect the Probe Request processing rules, so some cases similar to
WPS/P2P is likely to show up, but I'm not aware of published
specification doing this at this point.

> I guess we have several ways to handle these:
> 1. Don't allow AP mode to initialize if the FW is offloading but a
> compiled-in "feature" is unsupported. Here this will mean #ifdef
> CONFIG_INTERWORKING code on AP init that checks for the capability
> bit.
> 2. Only fail if the feature is dynamically enabled. In this example if
> the config file of hostapd contains "interworking=1" the AP init
> should fail.
> 3. Always allow the offload (maybe print a warning?)

1 doesn't sound reasonable. Selection between 2 and 3 will depend on the
particular functionality. In the case of Interworking, I would be fine
with 3 (and yes, with the warning).

> Either way we can automatically fail any FW that supports offload but
> not p2p + wps/wps2 exclusions. Currently no such FWs exists (that we
> know of), and new ones will probably be written with offloading
> support for these protocols.

There is such a firmware (Prism 3/Host AP mode), but I think we have
stopped caring about that one years ago..

-- 
Jouni Malinen                                            PGP id EFC895FA