| Message ID | 1634210331-9001-1-git-send-email-vjakkam@codeaurora.org (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Johannes Berg |
| Headers | show |
| Series | nl80211: Indicate SA Query procedures offload for AP SME device | expand |
On Thu, 2021-10-14 at 16:48 +0530, Veerendranath Jakkam wrote: > Add AP SME device feature flag to advertise that the SA Query procedures > are handled in driver. > > If this flag is advertised SA Query request or response frames from peers > are not reported to userspace. Thus userspace components shall skip SA > Query specific validations. > > Ex: When AP started with Operating Channel Validation(OCV) support and > channel switch occurs, hostapd starts SA Query timer for OCV enabled > STAs. Hostapd sends deauth to the STAs which didn't send SA Query > request before timeout, Hostapd can skip such validations when this flag > advertised. So how's that going to work with older hostapd? It'll be offloaded, and then hostapd doesn't know, so it's still going to disconnect them? So should be that hostapd also opts in to this driver behaviour? Also ... it _really_ would be good if there were upstream drivers with these things ... johannes
On 2021-10-21 21:02, Johannes Berg wrote: > On Thu, 2021-10-14 at 16:48 +0530, Veerendranath Jakkam wrote: >> Add AP SME device feature flag to advertise that the SA Query >> procedures >> are handled in driver. >> >> If this flag is advertised SA Query request or response frames from >> peers >> are not reported to userspace. Thus userspace components shall skip SA >> Query specific validations. >> >> Ex: When AP started with Operating Channel Validation(OCV) support and >> channel switch occurs, hostapd starts SA Query timer for OCV enabled >> STAs. Hostapd sends deauth to the STAs which didn't send SA Query >> request before timeout, Hostapd can skip such validations when this >> flag >> advertised. > > So how's that going to work with older hostapd? It'll be offloaded, and > then hostapd doesn't know, so it's still going to disconnect them? > > So should be that hostapd also opts in to this driver behaviour? yes, we have to update hostapd also with new implementation based on the feature flag. > > Also ... it _really_ would be good if there were upstream drivers with > these things ... I fully agree. But unfortunately none of the upstream drivers implemented OCV features within them.
On Fri, 2021-10-22 at 18:56 +0530, vjakkam@codeaurora.org wrote: > > > > So how's that going to work with older hostapd? It'll be offloaded, and > > then hostapd doesn't know, so it's still going to disconnect them? > > > > So should be that hostapd also opts in to this driver behaviour? > > yes, we have to update hostapd also with new implementation based on the > feature flag. That wasn't my question. My question was what happens if you have a hostapd that's *not* updated?> johannes
On 2021-10-22 18:59, Johannes Berg wrote: > On Fri, 2021-10-22 at 18:56 +0530, vjakkam@codeaurora.org wrote: >> > >> > So how's that going to work with older hostapd? It'll be offloaded, and >> > then hostapd doesn't know, so it's still going to disconnect them? >> > >> > So should be that hostapd also opts in to this driver behaviour? >> >> yes, we have to update hostapd also with new implementation based on >> the >> feature flag. > > That wasn't my question. My question was what happens if you have a > hostapd that's *not* updated?> > > johannes Apologies for not clear answer in my previous reply. Yes, If hostapd is not updated, it's going to disconnect the STAs. We should update hostapd also to opt in this driver behavior. Thanks, Veeru
On Mon, 2021-10-25 at 13:57 +0530, vjakkam@codeaurora.org wrote: > On 2021-10-22 18:59, Johannes Berg wrote: > > On Fri, 2021-10-22 at 18:56 +0530, vjakkam@codeaurora.org wrote: > > > > > > > > So how's that going to work with older hostapd? It'll be offloaded, and > > > > then hostapd doesn't know, so it's still going to disconnect them? > > > > > > > > So should be that hostapd also opts in to this driver behaviour? > > > > > > yes, we have to update hostapd also with new implementation based on > > > the > > > feature flag. > > > > That wasn't my question. My question was what happens if you have a > > hostapd that's *not* updated?> > > > > johannes > > Apologies for not clear answer in my previous reply. > Yes, If hostapd is not updated, it's going to disconnect the STAs. > > We should update hostapd also to opt in this driver behavior. That would also mean the driver opts in and asks the firmware to offload only if hostapd did, right? johannes
On 2021-10-25 13:58, Johannes Berg wrote: > On Mon, 2021-10-25 at 13:57 +0530, vjakkam@codeaurora.org wrote: >> On 2021-10-22 18:59, Johannes Berg wrote: >> > On Fri, 2021-10-22 at 18:56 +0530, vjakkam@codeaurora.org wrote: >> > > > >> > > > So how's that going to work with older hostapd? It'll be offloaded, and >> > > > then hostapd doesn't know, so it's still going to disconnect them? >> > > > >> > > > So should be that hostapd also opts in to this driver behaviour? >> > > >> > > yes, we have to update hostapd also with new implementation based on >> > > the >> > > feature flag. >> > >> > That wasn't my question. My question was what happens if you have a >> > hostapd that's *not* updated?> >> > >> > johannes >> >> Apologies for not clear answer in my previous reply. >> Yes, If hostapd is not updated, it's going to disconnect the STAs. >> >> We should update hostapd also to opt in this driver behavior. > > That would also mean the driver opts in and asks the firmware to > offload > only if hostapd did, right? > > johannes Yeah, Thanks for the comments. I will upload v2 patch with suggested changes.
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h index eda608b..99746aa 100644 --- a/include/uapi/linux/nl80211.h +++ b/include/uapi/linux/nl80211.h @@ -5735,13 +5735,17 @@ enum nl80211_tdls_operation { NL80211_TDLS_DISABLE_LINK, }; -/* +/** * enum nl80211_ap_sme_features - device-integrated AP features - * Reserved for future use, no bits are defined in - * NL80211_ATTR_DEVICE_AP_SME yet. + * @NL80211_DEVICE_AP_SME_SA_QUERY_OFFLOAD: Driver handles SA Query procedures. + * If this flag is advertised by the driver, SA Query request/response + * frames are handled within the driver and won't be reported to userspace. + * Userspace shall skip SA Query specific validations if the driver is + * advertizing this capability. + */ enum nl80211_ap_sme_features { + NL80211_DEVICE_AP_SME_SA_QUERY_OFFLOAD = 1 << 0, }; - */ /** * enum nl80211_feature_flags - device/driver features
Add AP SME device feature flag to advertise that the SA Query procedures are handled in driver. If this flag is advertised SA Query request or response frames from peers are not reported to userspace. Thus userspace components shall skip SA Query specific validations. Ex: When AP started with Operating Channel Validation(OCV) support and channel switch occurs, hostapd starts SA Query timer for OCV enabled STAs. Hostapd sends deauth to the STAs which didn't send SA Query request before timeout, Hostapd can skip such validations when this flag advertised. Signed-off-by: Veerendranath Jakkam <vjakkam@codeaurora.org> --- include/uapi/linux/nl80211.h | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)