On Fri, 2019-11-22 at 13:04 +0100, Johannes Berg wrote: > On Tue, 2019-11-19 at 14:15 -0800, James Prestwood wrote: > > These values are already tracked so for the software scan path > > we can set these into scan_info so NL80211 reports it in > > TRIGGER_SCAN. > > No. > > > + req->info.scan_start_tsf = req->scan_start; > > These are two very different things. Is this a jiffies vs TSF issue? Or are they really completely different things? Looking at iwlwifi I now see that I wrongly read the scan_start values they were using. I thought they were setting mvm->scan_start = jiffies, but that was in another structure. mvm->scan_start gets set to scan_start_tsf, and looks like it comes from a scan complete callback. So if this value is only obtainable in the driver, I'll drop this and maybe add support into mac80211_hwsim. I don't mean to hijack this patch thread (its related), but there is some confusion about these ext features in nl80211: NL80211_EXT_FEATURE_SCAN_START_TIME NL80211_EXT_FEATURE_BSS_PARENT_TSF They were only added into iwlwifi and its not clear why or whether these features should even be checked by userspace (wpa_supplicant does not check). We were planning on using these to enable support for beacon measurement requests (if set) but its looking like, for the majority of hardware, these values are not included in scan results, meaning they end up being zero/unset in the measurement report (as they do with wpa_supplicant). The spec is does not explicitly say these values are required for measurement reports, but it also doesn't say they are optional. Am I just looking too deeply into this? Maybe its the case that an AP which utilizes measurement requests/reports doesn't even care about these values? There is also a ext feature for RRM as a whole which further confuses me. It would seem like if RRM is supported both these other features also need to be supported. And maybe this is the case, and only iwlwifi 'technically' works with RRM (at least if you follow the spec and require inclusion of these two values). Thanks, James > > johannes >
