Hidden BSSes in transitional OWE

[Andrzej Ostruszka]

Hello all

I've got a question about how hidden BSSes are kept internally - to be
more specific: is this expected/desired to have multiple entries kept
for the same BSS (one with empty SSID and one with SSID filled)?

The context of the question is the transitional mode OWE.  I'm adding
support for it in ChromeOS and this is what I see (I've modified logging
of SSID to show the actual value instead of hash for easier reading):

First we are getting 2 BSSes 1 public 1 hidden (empty SSID) and they are
registered with ID0 and ID1 respectively:

wpa_supplicant[8917]: nl80211: Received scan results (2 BSSes)
wpa_supplicant[8917]: Sorted scan results
wpa_supplicant[8917]: 82:42:1a:42:c4:f8 ssid= freq=5745 qual=0 noise=-92~ level=-25 snr=67* flags=0xb age=2312 est=600502
wpa_supplicant[8917]: 04:42:1a:42:c4:f4 ssid=googleTest0 freq=5745 qual=0 noise=-92~ level=-25 snr=67* flags=0xb age=2303 est=600502
wpa_supplicant[8917]: wlan0: BSS: Start scan result update 1
wpa_supplicant[8917]: wlan0: BSS: Add new id 0 BSSID 82:42:1a:42:c4:f8 SSID '' freq 5745
wpa_supplicant[8917]: dbus: Register BSS object '/fi/w1/wpa_supplicant1/Interfaces/2/BSSs/0'
wpa_supplicant[8917]: wlan0: BSS: Add new id 1 BSSID 04:42:1a:42:c4:f4 SSID 'googleTest0' freq 5745
wpa_supplicant[8917]: dbus: Register BSS object '/fi/w1/wpa_supplicant1/Interfaces/2/BSSs/1'

Then we start association with ID0 (public BSS) during which supplicant
tries to find the matching pair (owe_trans_ssid() function) which will
find ID0 and ID1 and will fill the SSID [1] in ID1 (without any
notification over DBus!) and start association with ID1:

wpa_supplicant[8917]: wlan0: Scan results matching the currently selected network
wpa_supplicant[8917]: wlan0: OWE: transition mode BSSID: 04:42:1a:42:c4:f4 SSID: googleTest0
wpa_supplicant[8917]: wlan0: OWE: transition mode OWE SSID for active OWE profile
wpa_supplicant[8917]: wlan0: OWE: learned transition mode OWE SSID: ASUS_F0_5G_Guest4
wpa_supplicant[8917]: wlan0: 0: 82:42:1a:42:c4:f8 freq=5745 level=-25 snr=67 est_throughput=600502
wpa_supplicant[8917]: wlan0: 1: 04:42:1a:42:c4:f4 freq=5745 level=-25 snr=67 est_throughput=600502
wpa_supplicant[8917]: wlan0: Selecting BSS from priority group 0
wpa_supplicant[8917]: wlan0: 0: 82:42:1a:42:c4:f8 ssid='ASUS_F0_5G_Guest4' wpa_ie_len=0 rsn_ie_len=20 caps=0x1111 level=-25 freq=5745 
wpa_supplicant[8917]: wlan0: OWE: transition mode BSSID: 04:42:1a:42:c4:f4 SSID: googleTest0
wpa_supplicant[8917]: wlan0:    selected based on RSN IE
wpa_supplicant[8917]: wlan0:    selected BSS 82:42:1a:42:c4:f8 ssid='ASUS_F0_5G_Guest4'
wpa_supplicant[8917]: wlan0: Considering connect request: reassociate: 1  selected: 82:42:1a:42:c4:f8  bssid: 00:00:00:00:00:00  pending: 00:00:00:00:00:00  wpa_state: DISCONNECTED  ssid=0x566f5b6254b0  current_ssid=0x566f5b6254b0
wpa_supplicant[8917]: wlan0: Request association with 82:42:1a:42:c4:f8

Then another scan result comes:

wpa_supplicant[8917]: Sorted scan results
wpa_supplicant[8917]: 82:42:1a:42:c4:f8 ssid= freq=5745 qual=0 noise=-92~ level=-25 snr=67* flags=0xb age=2340 est=600502
wpa_supplicant[8917]: 04:42:1a:42:c4:f4 ssid=googleTest0 freq=5745 qual=0 noise=-92~ level=-25 snr=67* flags=0xb age=2330 est=600502
wpa_supplicant[8917]: wlan0: BSS: Start scan result update 2
wpa_supplicant[8917]: wlan0: BSS: Add new id 2 BSSID 82:42:1a:42:c4:f8 SSID '' freq 5745
wpa_supplicant[8917]: dbus: Register BSS object '/fi/w1/wpa_supplicant1/Interfaces/2/BSSs/2'

and since now there is no BSS entry with BSSID 82:42:1a:42:c4:f8 SSID ''
we are adding ID2.  Then supplicant completes association and starts
4-way handshake but repots current BSS as ID2:

shill[24800]: VERBOSE2 shill: [wifi.cc(483)] /device/wlan0 PropertiesChanged
shill[24800]: INFO shill: [wifi.cc(1081)] WiFi wlan0 CurrentBSS (unknown) -> /fi/w1/wpa_supplicant1/Interfaces/2/BSSs/2
shill[24800]: VERBOSE2 shill: [wifi.cc(3282)] /device/wlan0 WiFi Device wlan0: StopReconnectTimer
shill[24800]: VERBOSE2 shill: [wifi.cc(3991)] /device/wlan0 WiFi Device wlan0: StopRequestingStationInfo
shill[24800]: WARNING shill: [wifi.cc(1500)] WiFi wlan0 connected to unknown BSS /fi/w1/wpa_supplicant1/Interfaces/2/BSSs/2

The logs above are from ChromeOS "network manager" called shill.  So far
we were not interested in BSSes with empty SSID so this is kind of
problem for us (which I can work around) but it looks to me like this is
not how it supposed to work.  Let's see what happens next:

Since we are now associated I think supplicant adds direct probe for the
hidden BSS since now we get following scan report:

wpa_supplicant[8917]: nl80211: Received scan results (3 BSSes)
wpa_supplicant[8917]: nl80211: Scan results indicate BSS status with 82:42:1a:42:c4:f8 as associated
wpa_supplicant[8917]: Sorted scan results
wpa_supplicant[8917]: 82:42:1a:42:c4:f8 ssid= freq=5745 qual=0 noise=-92~ level=-25 snr=67* flags=0xb age=2547 est=600502
wpa_supplicant[8917]: 82:42:1a:42:c4:f8 ssid=ASUS_F0_5G_Guest4 freq=5745 qual=0 noise=-92~ level=-25 snr=67* flags=0x2b age=186 est=600502
wpa_supplicant[8917]: 04:42:1a:42:c4:f4 ssid=googleTest0 freq=5745 qual=0 noise=-92~ level=-25 snr=67* flags=0xb age=2538 est=600502
wpa_supplicant[8917]: wlan0: BSS: Start scan result update 3
wpa_supplicant[8917]: wlan0: BSS: Add new id 3 BSSID 82:42:1a:42:c4:f8 SSID '' freq 5745
wpa_supplicant[8917]: dbus: Register BSS object '/fi/w1/wpa_supplicant1/Interfaces/2/BSSs/3'

Note that we again add BSSID 82:42:1a:42:c4:f8 SSID '' this time as ID3.

So again, is that supposed to work like that?  Because at this point
I think we have ID0 (public 04:42:1a:42:c4:f4) + ID1 & ID2 & ID3 for
hidden BSS (82:42:1a:42:c4:f8).

If this is a correct behaviour, then I'll work around that in shill, but
could you explain the logic behind this?
If this is incorrect then I'd like your opinion which of the following
approaches would be preferred and I'll work in that direction:

1. Keep all entries but when notification about association comes from
  the driver then out of all BSSes matching given BSSID select one with
  non-empty SSID and report connection to this BSS entry/ID
  (wpa_supplicant_update_current_bss() + wpa_bss_get_bssid()).  This
  will have minimal changes to supplicant and will be easy to handle on
  shill side but we will still have multiple entries for the same BSS.

2. Keep only one entry for given BSS.  That means we would be
  merging/updating entries for the following two scenarios:
  - BSSID=Y SSID='' + BSSID=Y SSID=anything
  - BSSID=Y SSID=anything + BSSID=Y SSID=''
  that is whenever SSID reported is empty we will merge it with entry
  for the same BSSID (maybe we should also check frequency?).

Let me know what you think.  I would like to pursue the second option.

Regards
Andrzej Ostruszka

[1]: https://w1.fi/cgit/hostap/tree/wpa_supplicant/events.c#n1172