On Fri, Dec 16, 2016 at 10:56:51AM +0100, Johannes Berg wrote: > On Thu, 2016-12-15 at 11:06 +0000, Malinen, Jouni wrote: > > Maybe the nl80211.h description was not clear enough, but the > > comments in cfg80211.h should be quite clear on how this was designed > > to work at the implementation level: > > > > "If the current connected BSS is in the 2.4 GHz band, other BSSs in > > the 2.4 GHz band to be reported should have better RSSI by > > @relative_rssi and other BSSs in the 5 GHz band to be reported should > > have better RSSI by (@relative_rssi - @relative_rssi_5g_pref). > > If the current connected BSS is in the 5 GHz band, other BSSs in the > > 2.4 GHz band to be reported should have better RSSI by > > (@relative_rssi + @relative_rssi_5g_pref) and other BSSs in the 5 GHz > > band to be reported should have better RSSI by by @relative_rssi." > > Oh, right. Should probably be in nl80211.h too, to set expectations > from userspace. Sure, we can update that in the next revision. > > At minimum, we would need to clearly document struct > > nl80211_bss_select_rssi_adjust, but even if we do, I'm not sure it > > really is ideal mechanism to move to now that I realized it is not an > > array, but a single band,delta pair. > > We can move to an array easily in the future by extending the attribute > length and advertising the number of array entries that are supported, > if that's your biggest concern? I don't see it as being very useful > right now since I don't think we'll see offloaded roaming between 2.4/5 > and 60 GHz anytime soon. This may change when we add more bands later, > I suppose. Hmm.. So do you want us to move to using this packed struct in the new attribute instead of using a signed 8-bit integer as the variable value? > > If we are talking only about roaming within an ESS (a single SSID), > > that would sound clear, but which relative RSSI rules would apply if > > there are match sets for both the currently connected SSID and > > another SSID that the candidate BSS is for? > > Right, I see how this might become a problem. I generally see no issue > with supporting multiple matchsets with different SSIDs but all having > the "relative to connected BSS RSSI filter" (which would disregard the > SSID specified in the matchset), but this then would become a problem > when multiple matchsets are specified with *different* such RSSI > filters, e.g. one matchset would specify that you want a 5G preference > of 10dB, but the other would specify a preference of only 5dB. > > Conceptually in this approach, that would be supported, but firmware > likely would not be able to express this, I suppose? That's certainly not at the level we were planning on implementing.. :) > > I think I'm missing something here.. Where would the threshold value > > (how much better new BSS needs to be) be stored? And do we really > > want something like the combination of > > NL80211_BSS_SELECT_ATTR_BAND_PREF and > > NL80211_BSS_SELECT_ATTR_RSSI_ADJUST which seems to be two different > > ways of doing band preference (the former without specifying delta > > and the latter with specific delta)? Or am I still not understanding > > how NL80211_BSS_SELECT_ATTR_* really works? > > No, you're right, I missed the "better by" threshold. > > I think between that (unless we add that, we could technically extend > flag attributes to allow them being an int as well, or add a new one) > and the fact that the device may not support different relative RSSI > matches in different matchsets, I'm almost convinced that adding new > attributes is better. I'm not completely sure how to interpret all this and also the last email from Arend in this thread. Could either (or both :) of you provide more detailed suggestion on what exactly you would like us to change, if anything, in the attribute design now so that we can try to close on this? -- Jouni Malinen PGP id EFC895FA
