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

[Arik Nemtsov]

On Sat, Oct 22, 2011 at 15:35, Jouni Malinen <j at w1.fi> wrote:
> On Sat, Oct 22, 2011 at 03:08:45PM +0200, Guy Eilam wrote:
>> +     unsigned int probe_resp_offload_supp_protocols;
>>  };
>
> How is this value used? The second patch in the series did not seem to
> verify in any way that the driver is capable of handling any specific
> offloading case.. In addition to the WPS and P2P ones, Interworking
> (IEEE 802.11u) is another example where special filtering of Probe
> Request frames is needed. hostapd (and wpa_supplicant AP mode) needs to
> be able to figure out whether the current configuration can be offloaded
> for this to work correctly.

Thanks for pointing this one out. We'll add a capability bit for
interworking. Can you think of other scenarios like this?

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?)

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.
So we're really talking about 802.11u only, making option 3 less
horrible than it sounds.

Other thoughts?

Arik