[PATCH] bss: enable discovery of SSID for known OWE BSS

[David Bauer]

Hi Jouni,

I was out this week and was using OWE TM networks extensively.

I encountered two issues with the current implementation in
wpa_supplicant:

1. 5GHz OWE Transition Networks take a long time to connect

Due to 5GHz channels being flagged as NO_IR / passive scan, no
active probing is performed on these SSIDs. In case the a
multi-band network is scanned with the Open SSID, the OWE-TM
network scan is dispatched by wpa-supplicant. On 5GHz, due
to passive scanning, the TM SSID is not discovered (or only
discovered coincidentally from a third party scan). This can
lead to a fallback to the 2.4 GHz network, being unable to ever
connect on 5GHz.

This also affects roaming in such multi-band scenarios on any
non-2.4GHz band.

2. OWE-SSIDs creating multiple entries in scan-results

This issue is the one initially addressed by this patch.

wpa_supplicant does not match the SSID for the OWE network to a
previous scan of a hidden beaon. This leads to the creation of
two networks in the scan-result list.

When deciding to roam, the first scan is matched. Due to the passive
nature of a regular passive scan, this creates a additional entry
everytime the scanned BSS does not match the last saved scan result.

This breaks roaming behavior, as a better BSS is not selected once the
last scan result does not match the saved ESSID.

An example for such a scan result list:

<ADD HERE>

On 12/26/24 18:42, Jouni Malinen wrote:
> Would you be able to share a debug log showing a case which does not
> work without this patch but works with the patch?
> 
> I'm not exactly fond of this type of changes as an OWE specific change
> since none of the changes here are really using any information that
> would be different for OWE transition mode than any other use of hidden
> SSIDs. Furthermore, I do not think it is really correct to modify an
> already adding BSS entry (i.e., replacing the zero length SSID with a
> specific SSID) since those modified entries could result in unexpected
> behavior for external programs.

I understand you are reluctant to change the behavior at this point here.

I had this patch applied for over a year and did not occur such issues with
NetworkManager. Granted, I don't tried any other external integration.

> What is that ssid[2] != 0 about? SSID is an arbitrary octet string of
> 1..32 octets and even 0x00 is a valid octet.. Sure, it is not commonly
> used, but still, it is valid as far as the IEEE 802.11 standard is
> concerned.

Yes, this is wrong. Will fix this.

> This is something I would prefer not to do, i.e., I would rather
> maintain two BSS entries for any BSS that uses hidden SSIDs (regardless
> of whether it is for OWE transition mode).

How to address this behavior in a roaming case then? Shall we modify
the function to take the SSID in order to skip the BSSID entries
with incorrect SSID?

> None of this really seems to be specific to OWE transition mode.. The
> best approach for handling new scan results for entries that have no
> SSID might be to iterate over all wpa_supplicant BSS entries and update
> them if they have the same BSSID regardless of their SSID. Even better
> would be to do that only for the entries that do not have a matching
> SSID entry in the same scan update round (i.e., update the local BSS
> entry with the same BSSID if that entry has ssid_len == 0 or if the
> current set of scan results did not have an entry for the BSSID,SSID
> tuple that is in in the current BSS but BSSID matches).

I tried your proposal and while the result fixes Issue 1 perfectly, it
is only a partial fix, as Issue 2 is still present with this approach
due to the passive scanning nature on 5GHz.

I'm unsure if this might be related to the behavior of the Client WiFi
NIC. I was using Intel wireless for the past years, but now with a
Qualcomm QCNFA765 this issue seems to be more pronounced
(subjective impression)

Do you have another idea or shall i resend a version of this patch with
sour requested fixes?

Best
David