Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-ID: <51080819b4018bb5fa694bb51e7d426ea7fd6659.camel@gmail.com>
Subject: Re: [PATCH] mac80211: set start_time_tsf/tsf_bssid for sw scans
From:   James Prestwood <prestwoj@gmail.com>
To:     Johannes Berg <johannes@sipsolutions.net>,
        linux-wireless@vger.kernel.org
Date:   Fri, 22 Nov 2019 09:37:29 -0800
In-Reply-To: <23be17c6cddca53a2f3b945248516d3e7801a75c.camel@sipsolutions.net>
References: <20191119221509.11370-1-prestwoj@gmail.com>
         (sfid-20191119_231813_756724_8FA90451) <23be17c6cddca53a2f3b945248516d3e7801a75c.camel@sipsolutions.net>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

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
>