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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
