On Tue, Nov 07, 2023 at 01:30:56PM +0100, Andrzej Ostruszka wrote: > 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. This is expected behavior and there can actually be more than two entries with the same BSSID since it would be possible for the AP to support more than one hidden SSID. > 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. This is mostly specific to the D-Bus interface, but yes, I can see how this would look confusing to external components. > 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? This is actually applicable to all hidden SSID cases, not just OWE transition mode.. This search should use the actual SSID that was used for the association to cover these cases. > 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. This should have really updated just one BSS entry with the hidden SSID and then continue using that for all following association.. > 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. That BSS entry update for the SSID was needed in the initial OWE implementation. After that, there was a separate optimization to start scanning for the specific SSIDs learned from OWE transition mode elements and with that, it is almost safe to do what is proposed here. However, this would still in a regression to the amount of time it would take to be able to connect to the hidden SSID OWE BSS since the updated internal BSS entry allowed a single channel scan to be used for that while this proposed patch would result in a full scan of all enabled channels to be used (i.e., there would likely need to be two full scans to discover the network in the first place and then get connected). I added a separate change to optimize the OWE transition mode scanning cases even further by restricting the quick retries to the channels that were detected as candidates for the hidden SSID BSSs based on already received scan results (i.e., those BSS entries with zero length SSID and OWE transition mode information). The part about preferring non-empty SSIDs does not feel correct to me, so I implemented that part more accurately by comparing the actual SSID from the current association to the BSS entry instead of preferring any SSID value regardless of whether it would match the real SSID. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
