[PATCH 0/1] wpa_supplicant: Fixes for transitional mode OWE

[Andrzej Ostruszka]

Hello all

I've asked previously about handling of hidden BSSes (in the context of
transitional mode OWE):
http://lists.infradead.org/pipermail/hostap/2023-August/041728.html
but haven't received any feedback.

Since then I think my understanding has improved and I'd like to present
the problem once again and offer a possible solution.

Let's start with a simple hidden BSS.  In the scan report initially it
will be reported with null-SSID and the entry for it will be created.
Later during association we add direct probe for its SSID and the report
will contain both:
- report for null-SSID (beacon)
- report for "hidden" SSID (probe response)

These two will not be merged since currently matching is strict by both
BSSID and SSID.  This does not constitute a problem since:
- both BSSes will be announced over DBus (with corresponding SSIDs)
- during association the search for BSSID/SSID will find the entry with
  both and that will be set as CurrentBSS and signaled over DBus.

The case for transitional OWE is a bit different.  Before association
the behaviour is identical: two entries with the same BSSID and one
having valid SSID and the other null-SSID (both announced over DBus).
During (and after) association however situation changes because we
start overwriting of the SSID in the entry initially created with
(and announced with) null-SSID.

There are three problems with this approach:
1. SSID of an BSS is not provisioned to be a changing property (so it is
  not even attempted in owe_trans_ssid() function).  The outside world
  has no idea what the SSID this BSS belongs to and might ignore it.
2. When handling association event we search for given BSSID (and SSID).
  In case of transitional OWE current SSID is the SSID of the publicly
  visible BSS, so the search for "public" SSID and associated BSSID will
  fail (since there is no such entry) and we fall back to search by only
  BSSID.  This however may select the entry that was reported over DBus
  as the one with null-SSID.  This in turn, when combined with #1, might
  cause problems to the outer world - what SSID is currently active?
3. During and after association the entries corresponding to the hidden
  BSS keep proliferating.  The sequence is:
  - we start with "null" SSID
  - during association we add direct probe so reports will be coming
    with both "hidden" and "null" SSID and we'll have two BSS entries
  - during (and after) association when we try to select network from
    last scan report we overwrite SSID of the "null" entry (and we have
    now two entries for BSSID/"hidden" SSID)
  - on each new report there will be no match for "null" SSID so each
    time new entry will be added (and later overwritten) and they will
    keep accumulating.
  Eventually the older entries will start to be removed but still there
  will be many entries for the same BSSID/"hidden" SSID pair.

The proposal is to remove part of the owe_trans_ssid() function
overwriting the SSID (since there will be an entry with a valid "hidden"
SSID from the direct probe that we add), and in addition to that during
update of CurrentBSS property when searching for entries based on BSSID
prefer entries with non-empty SSID - so the outside world will have no
problems figuring out the SSID of the currently selected network.

The next patch contains the implementation.

With regards
Andrzej Ostruszka

Andrzej Ostruszka (1):
  wpa_supplicant: Fixes for transitional mode OWE

 wpa_supplicant/bss.c    | 27 +++++++++++++++++++++
 wpa_supplicant/bss.h    |  2 ++
 wpa_supplicant/events.c | 52 +++++++----------------------------------
 3 files changed, 37 insertions(+), 44 deletions(-)

-- 
2.42.0.869.gea05f2083d-goog