All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Denis Kenzior <denkenz@gmail.com>
Cc: Tim Kourt <tim.a.kourt@linux.intel.com>, linux-wireless@vger.kernel.org
Subject: Re: [PATCH] cfg80211: Fix support for flushing old scan results
Date: Tue, 22 May 2018 23:11:18 +0200	[thread overview]
Message-ID: <1527023478.6787.60.camel@sipsolutions.net> (raw)
In-Reply-To: <D2E91785-58E3-46FA-94B9-879E621D5049@gmail.com> (sfid-20180522_230705_275847_981AACBF)

On Tue, 2018-05-22 at 16:00 -0500, Denis Kenzior wrote:

> > > So what's the practical use of the flush flag?  Or is that something 
> > > that was meant to be 'for-testing-only'?
> > 
> > I think you misunderstand? The value is that it ensures that nothing is
> > present in the list that was received *before* the scan.
> > 
> 
> We misunderstood how it was supposed to work, but no, I get how things
> work now. 

FWIW, even what I said above was slightly lying I think (though I'd have
to go check the code). That's actually what I thought had happened
before, though the timestamps should've allowed you to realize this, and
it wasn't the case here afaict.

But in theory, I think you could've received the beacon with hidden SSID
*before* the scan, yet it might be present in the scan results if the
new scan caused the probe response to be associated with that scan.

> I’m just curious what other potential uses this flag might have.

Well, basically, ensure that your scan data is up-to-date?

I think mostly it's because there are scenarios where the AP is expected
to vary the probe response data, so you need to know if you
 * have a new probe response, or
 * didn't receive a new probe response, or
 * the AP erroneously didn't change the new probe response.

johannes

  reply	other threads:[~2018-05-22 21:11 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-11 16:48 [PATCH] cfg80211: Fix support for flushing old scan results Tim Kourt
2018-05-18  8:13 ` Johannes Berg
2018-05-18 16:47   ` Denis Kenzior
2018-05-18 18:54     ` Arend van Spriel
2018-05-18 19:00       ` Denis Kenzior
2018-05-22  7:24         ` Arend van Spriel
2018-05-22 14:48           ` Denis Kenzior
2018-05-22 14:50             ` Johannes Berg
2018-05-22 14:51               ` Johannes Berg
2018-05-22 15:03                 ` Denis Kenzior
2018-05-22  8:12     ` Johannes Berg
2018-05-22 14:50       ` Denis Kenzior
2018-05-22 20:12     ` Johannes Berg
2018-05-22 20:37       ` Denis Kenzior
2018-05-22 20:40         ` Johannes Berg
2018-05-22 20:49           ` Denis Kenzior
2018-05-22 20:52             ` Johannes Berg
2018-05-22 21:00               ` Denis Kenzior
2018-05-22 21:11                 ` Johannes Berg [this message]
2018-05-22 21:25                   ` Denis Kenzior
2018-05-22 21:28                     ` Johannes Berg
2018-05-22 21:45                       ` Denis Kenzior
2018-05-23  7:08                         ` Johannes Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1527023478.6787.60.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=denkenz@gmail.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=tim.a.kourt@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.