* hostapd and 11h support @ 2014-12-24 9:32 Arend van Spriel 2014-12-24 17:32 ` Jouni Malinen 0 siblings, 1 reply; 6+ messages in thread From: Arend van Spriel @ 2014-12-24 9:32 UTC (permalink / raw) To: Jouni Malinen; +Cc: hostap, linux-wireless 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: hostapd and 11h support 2014-12-24 9:32 hostapd and 11h support Arend van Spriel @ 2014-12-24 17:32 ` Jouni Malinen 2014-12-24 18:29 ` Arend van Spriel 0 siblings, 1 reply; 6+ messages in thread From: Jouni Malinen @ 2014-12-24 17:32 UTC (permalink / raw) To: Arend van Spriel; +Cc: hostap, linux-wireless 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: hostapd and 11h support 2014-12-24 17:32 ` Jouni Malinen @ 2014-12-24 18:29 ` Arend van Spriel 2014-12-24 19:04 ` Jouni Malinen 0 siblings, 1 reply; 6+ messages in thread From: Arend van Spriel @ 2014-12-24 18:29 UTC (permalink / raw) To: Jouni Malinen; +Cc: hostap, linux-wireless, Kalle Valo 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: hostapd and 11h support 2014-12-24 18:29 ` Arend van Spriel @ 2014-12-24 19:04 ` Jouni Malinen 2014-12-24 20:40 ` Arend van Spriel 0 siblings, 1 reply; 6+ messages in thread From: Jouni Malinen @ 2014-12-24 19:04 UTC (permalink / raw) To: Arend van Spriel; +Cc: hostap, linux-wireless, Kalle Valo 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: hostapd and 11h support 2014-12-24 19:04 ` Jouni Malinen @ 2014-12-24 20:40 ` Arend van Spriel 2014-12-25 9:10 ` Jouni Malinen 0 siblings, 1 reply; 6+ messages in thread From: Arend van Spriel @ 2014-12-24 20:40 UTC (permalink / raw) To: Jouni Malinen Cc: hostap, linux-wireless, Kalle Valo, Gautam (Gautam Kumar) Shukla 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: hostapd and 11h support 2014-12-24 20:40 ` Arend van Spriel @ 2014-12-25 9:10 ` Jouni Malinen 0 siblings, 0 replies; 6+ messages in thread From: Jouni Malinen @ 2014-12-25 9:10 UTC (permalink / raw) To: Arend van Spriel Cc: hostap, linux-wireless, Kalle Valo, Gautam (Gautam Kumar) Shukla 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-12-25 9:11 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-12-24 9:32 hostapd and 11h support Arend van Spriel 2014-12-24 17:32 ` Jouni Malinen 2014-12-24 18:29 ` Arend van Spriel 2014-12-24 19:04 ` Jouni Malinen 2014-12-24 20:40 ` Arend van Spriel 2014-12-25 9:10 ` Jouni Malinen
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.