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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
