Re: [PATCH] cfg80211: merge in beacon ies of hidden bss.

[Johannes Berg <johannes@sipsolutions.net>]

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