Clarification on the usage of NL80211_SCAN_FLAG_FLUSH

Clarification on the usage of NL80211_SCAN_FLAG_FLUSH

[Matthew Schwartz]

Hello,

I had a quick question about the proper usage of NL80211_SCAN_FLAG_FLUSH. I'm looking into a bug while using iwd where rapidly switching between a 2.4GHz network and a 5GHz network can have spurious connection failures. After debugging the issue, it looks like iwd is flushing all BSS entries by using NL80211_SCAN_FLAG_FLUSH for both full scans and partial-channel scans (i.e. only 2.4GHz, only 5GHz), and if this happens during the network connection process it causes the failures.

The observed behavior is:

1. iwd issues a 2.4GHz-only quick scan with FLUSH
2. User initiates connection to a 5GHz BSS from a previous scan
3. Scan completes, kernel flushes all BSS entries
4. Connection fails because the target BSS is no longer in cache

Is this intended behavior of NL80211_SCAN_FLAG_FLUSH where it clears all BSS entries regardless of which channels were scanned, or should NL80211_SCAN_FLAG_FLUSH be limited to channels that were scanned in the request which triggered them? The uAPI definition for it is simply "flush cache before scanning", but this seems open to interpretation as to whether it means the entire cache or just the cache on scanned channels.

If this is working as designed then I will look at submitting a fix to iwd, but if limiting the flush during partial scans is a viable option I could look at fixing that on the kernel side.

Thanks,
Matt

Re: Clarification on the usage of NL80211_SCAN_FLAG_FLUSH

[Johannes Berg]

Hi,

> Is this intended behavior of NL80211_SCAN_FLAG_FLUSH where it clears all BSS entries regardless of which channels were scanned, or should NL80211_SCAN_FLAG_FLUSH be limited to channels that were scanned in the request which triggered them? The uAPI definition for it is simply "flush cache before scanning", but this seems open to interpretation as to whether it means the entire cache or just the cache on scanned channels.

Well, AFAICT it has always done that, and so I think regardless of what
might have been the original intent, it simply is that behaviour now.
Changing it in the kernel would just end up having to fix two places,
unless you somehow don't care about running on older kernels without
fixes.

I also tend to think it makes sense since the scan could, at least in
theory, do e.g. colocated scanning, so networks on channels other than
the ones explicitly listed could be discovered. Trying to do anything
other than "flush all" would be far more complex.

johannes

Re: Clarification on the usage of NL80211_SCAN_FLAG_FLUSH

[Matthew Schwartz]

> On Jan 28, 2026, at 12:39 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> 
> Hi,
> 
>> Is this intended behavior of NL80211_SCAN_FLAG_FLUSH where it clears all BSS entries regardless of which channels were scanned, or should NL80211_SCAN_FLAG_FLUSH be limited to channels that were scanned in the request which triggered them? The uAPI definition for it is simply "flush cache before scanning", but this seems open to interpretation as to whether it means the entire cache or just the cache on scanned channels.
> 
> Well, AFAICT it has always done that, and so I think regardless of what
> might have been the original intent, it simply is that behaviour now.
> Changing it in the kernel would just end up having to fix two places,
> unless you somehow don't care about running on older kernels without
> fixes.
> 
> I also tend to think it makes sense since the scan could, at least in
> theory, do e.g. colocated scanning, so networks on channels other than
> the ones explicitly listed could be discovered. Trying to do anything
> other than "flush all" would be far more complex.

Okay, thanks for the clarification. I’ll try and take a look at how iwd is using the flush then because it seems like it’s overusing it, or maybe needs some other logic to prevent the connection issues.

Thanks,
Matt

> 
> johannes