hostapd and 11h support

hostapd and 11h support

[Arend van Spriel]

Hi Jouni,

I am looking at 11h support in hostapd. The supplicant uses 
.start_dfs_cac() driver callback (resulting in NL08211_CMD_RADAR_DETECT) 
and basically the CAC logic is done in the supplicant. Now for our 
devices the entire radar detection and CAC state machine is built in 
firmware. So hostapd would just need to enable 11h in the driver/firmware.

I am considering a new offload feature flag, but not sure whether we 
would need to introduce a new nl80211 command. I am thinking we could 
just reuse .start_dfc_cac(). Because of the feature flag it would have a 
different meaning in the driver. Wanted to know your opinion on this 
approach before starting the work.

Regards,
Arend

Re: hostapd and 11h support

[Jouni Malinen]

On Wed, Dec 24, 2014 at 10:32:23AM +0100, Arend van Spriel wrote:
> I am looking at 11h support in hostapd. The supplicant uses
> .start_dfs_cac() driver callback (resulting in
> NL08211_CMD_RADAR_DETECT) and basically the CAC logic is done in the
> supplicant. Now for our devices the entire radar detection and CAC
> state machine is built in firmware. So hostapd would just need to
> enable 11h in the driver/firmware.
> 
> I am considering a new offload feature flag, but not sure whether we
> would need to introduce a new nl80211 command. I am thinking we
> could just reuse .start_dfc_cac(). Because of the feature flag it
> would have a different meaning in the driver. Wanted to know your
> opinion on this approach before starting the work.

There's already one vendor-specific mechanism for supporting such
offloading.. Could you please check whether that would work for your
driver as well? Search for WPA_DRIVER_FLAGS_DFS_OFFLOAD to see how the
hostapd-based operations are skipped. This driver flag is currently set
based on a QCA vendor specific driver capability indication.

I'm not sure I understood why we would use .start_dfs_cac() for a driver
that takes care of CAC logic completely (i.e., I'd assume the driver
would be capable of handling this automatically without additional input
from user space). I don't really want to get N+1 different ways of doing
DFS offloading, so if you can either use as-is or build on top of the
existing design (without breaking it for other, obviously), that would
be preferred.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: hostapd and 11h support

[Arend van Spriel]

On 12/24/14 18:32, Jouni Malinen wrote:
> On Wed, Dec 24, 2014 at 10:32:23AM +0100, Arend van Spriel wrote:
>> I am looking at 11h support in hostapd. The supplicant uses
>> .start_dfs_cac() driver callback (resulting in
>> NL08211_CMD_RADAR_DETECT) and basically the CAC logic is done in the
>> supplicant. Now for our devices the entire radar detection and CAC
>> state machine is built in firmware. So hostapd would just need to
>> enable 11h in the driver/firmware.
>>
>> I am considering a new offload feature flag, but not sure whether we
>> would need to introduce a new nl80211 command. I am thinking we
>> could just reuse .start_dfc_cac(). Because of the feature flag it
>> would have a different meaning in the driver. Wanted to know your
>> opinion on this approach before starting the work.
>
> There's already one vendor-specific mechanism for supporting such
> offloading.. Could you please check whether that would work for your
> driver as well? Search for WPA_DRIVER_FLAGS_DFS_OFFLOAD to see how the
> hostapd-based operations are skipped. This driver flag is currently set
> based on a QCA vendor specific driver capability indication.

Thanks for the info.

> I'm not sure I understood why we would use .start_dfs_cac() for a driver
> that takes care of CAC logic completely (i.e., I'd assume the driver
> would be capable of handling this automatically without additional input
> from user space). I don't really want to get N+1 different ways of doing
> DFS offloading, so if you can either use as-is or build on top of the
> existing design (without breaking it for other, obviously), that would
> be preferred.

The firmware on the device *can* have CAC logic built-in. When it *is* 
built-in it is however disabled by default. Based on your feedback I 
will just detect firmware support, enable dfs in firmware, and signal 
DFS offload to hostapd. I would suggest introducing a new common 
capability flag for this instead of using a QCA vendor specific one. 
That would be odd ;-)

Regards,
Arend

Re: hostapd and 11h support

[Jouni Malinen]

On Wed, Dec 24, 2014 at 07:29:04PM +0100, Arend van Spriel wrote:
> The firmware on the device *can* have CAC logic built-in. When it
> *is* built-in it is however disabled by default. Based on your
> feedback I will just detect firmware support, enable dfs in
> firmware, and signal DFS offload to hostapd. I would suggest
> introducing a new common capability flag for this instead of using a
> QCA vendor specific one. That would be odd ;-)

I see nothing odd in other drivers using the already defined QCA vendor
specific nl80211 command. Anyway, I have no issues with a new nl80211
capability flag added for this purpose. You'll probably have better
chances of getting that accepted with an upstream driver using it.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: hostapd and 11h support

[Arend van Spriel]

On 12/24/14 20:04, Jouni Malinen wrote:
> On Wed, Dec 24, 2014 at 07:29:04PM +0100, Arend van Spriel wrote:
>> The firmware on the device *can* have CAC logic built-in. When it
>> *is* built-in it is however disabled by default. Based on your
>> feedback I will just detect firmware support, enable dfs in
>> firmware, and signal DFS offload to hostapd. I would suggest
>> introducing a new common capability flag for this instead of using a
>> QCA vendor specific one. That would be odd ;-)
>
> I see nothing odd in other drivers using the already defined QCA vendor
> specific nl80211 command. Anyway, I have no issues with a new nl80211
> capability flag added for this purpose. You'll probably have better
> chances of getting that accepted with an upstream driver using it.

Maybe not odd but counter-intuitive to some people. Anyway, I was 
looking at the code in driver_nl80211_capa.c and stumbled upon 
WPA_DRIVER_FLAGS_KEY_MGMT_OFFLOAD. I introduced entensible feature flags 
upstream just yesterday to accomodate this type of offload. Just curious 
but are those QCA vendor specific nl80211 commands used by the upstream 
QCA drivers or is this for supporting QCA proprietary drivers. I guess 
the latter as that would be the only reason I can think of to have 
vendor specific commands.

Regards,
Arend

Re: hostapd and 11h support

[Jouni Malinen]

On Wed, Dec 24, 2014 at 09:40:09PM +0100, Arend van Spriel wrote:
> On 12/24/14 20:04, Jouni Malinen wrote:
> >I see nothing odd in other drivers using the already defined QCA vendor
> >specific nl80211 command.
> 
> Maybe not odd but counter-intuitive to some people.

Maybe so, but certainly not on purpose. It has to be a specific OUI and
as such, assigned to someone.. This one happens to be coordinated in a
way that all (non-MAC address) assignments get done by upstream
hostap.git commits. In other words, there is no intent of trying to
limit it to a single vendor, but to have something that is easily usable
for hostapd/wpa_supplicant extensions in cases where upstream nl80211
extensions for needed functionality are not acceptable for some reason
at the time.

> Anyway, I was
> looking at the code in driver_nl80211_capa.c and stumbled upon
> WPA_DRIVER_FLAGS_KEY_MGMT_OFFLOAD. I introduced entensible feature
> flags upstream just yesterday to accomodate this type of offload.
> Just curious but are those QCA vendor specific nl80211 commands used
> by the upstream QCA drivers or is this for supporting QCA
> proprietary drivers. I guess the latter as that would be the only
> reason I can think of to have vendor specific commands.

This is currently used by an open source, but not upstream, driver.
There was actually an attempt to get this done in standard nl80211
commands/events, but the response was not exactly encouraging with no
existing upstream driver to show as a user for the new functionality.
I'd still like to get this done cleanly in nl80211 at some point in
time, though, since extensions to Connect command/event are not possible
using the vendor specific commands/events, i.e., you end up having to
fully override these commands/events which gets ugly pretty quickly.

-- 
Jouni Malinen                                            PGP id EFC895FA