hostapd and 11h support
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
Quoted 7 lines · Arend van Spriel
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.
Quoted 5 lines
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.
Signature · 1 line
Jouni Malinen PGP id EFC895FA
Quoted 14 lines · Jouni Malinen
Quoted 7 lines · Arend van Spriel
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.Quoted 5 lines
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.
Quoted 5 lines
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_OFFLOADto 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.
Quoted 7 lines
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
Quoted 6 lines · Arend van Spriel
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.
Signature · 1 line
Jouni Malinen PGP id EFC895FA
Quoted 8 lines · Jouni Malinen
Quoted 6 lines · Arend van Spriel
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 ;-)
Quoted 4 lines
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
Quoted 5 lines · Arend van Spriel
Quoted 2 lines · Jouni Malinen
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.
Quoted 8 lines
Anyway, I was
looking at the code indriver_nl80211_capa.cand stumbled uponWPA_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.
Signature · 1 line
Jouni Malinen PGP id EFC895FA