Hi, > -1 means "lesser", which is not true if both of ies are absent. > 0 means "equal", which is correct (but logically impossible with the > current usage of the comparator). Now I think even WARN_ON is a bad > idea, the comparator can be reused for other purposes when both > SSID ies are missing. Fair enough. Maybe a comment along the lines of /* can't really happen, but they're the same then */ would be useful. > > Eliad pointed out another thing: It is possible to have multiple SSIDs > > hidden behind a single hidden SSID. Therefore, this should update all of > > those BSS structs. Also, I'm a tad confused about the matching code > > here, this code path executes for both received beacons and probe > > responses, but probe responses would typically have found the BSS > > already? But what if we only have a beacon and then receive a probe > > response? Or vice versa? Some comments would be good outlining how that > > works. > > > I will add some comments in the code. Is a word, the code searches for a beacon > of the hidden BSS and copies beacon IEs (with nullified SSID) into the probe > response bss entry (with real SSID). It works fine in case of multi-SSID hidden > BSS too. Right, that should work. > > Or vice versa? > It will not work. Update of beacon IEs of probe response is not implemented. > The code is not trying to update existing probe response bss entries when beacon > IEs are getting changed. Technically it's possible to update them, but > I think it's a bit > overkill, I'm addressing only PSM in this commit. I think that would actually be useful too since userspace may obtain this data from scan results at any point in time, and might expect up-to-date information? Could be a separate patch though. Anyway, comments indicating what happens and which case this handles would be great. Thanks! johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
