Problem with BSS properties

[Jouni Malinen]

On Sat, Dec 26, 2009 at 04:47:23AM -0800, Marcel Holtmann wrote:
> The downside is that we would send signals for every BSS result now, but
> in the end we would be doing that anyway to some level since the signal
> strength is changing almost on every scan. The few BSS results where it
> stays the same can be probably ignored.

It might be useful to have different signal for signal level changes and
allow clients to decide whether they want to track changes in the Beacon
or Probe Response frame payload or also signal levels.

> Problem now is that the client doesn't know what changed and has to do
> the comparison. It would be great to avoid that.

That can be handled inside wpa_supplicant (with the build time option to
disable things that require duplicating memory needs for scan results).

> Since we really only handle like four IEs anyway, it might be better to
> just hold a copy of these. If I count correctly we have SSID, WPA, RSN
> and WPA elements we export. So if we just copy these, then we should be
> good.

There will be more IEs in the future and we should really expose the
full set of IEs over the D-Bus interface, too, for scan results/BSS
data. Having a full copy will make things easier, so that's likely a
good starting point and only do optimizations by limiting copied data or
hashing if needed.

> Alternatively we could just hash them and only store the hash value. So
> we can do a comparison via hash values.

If we need to optimize, I would consider this as the first choice for
figuring out whether a BSS has had any changes. However, if we need to
indicate each separate change in the BSS data, it will likely be simpler
to just use full data.

-- 
Jouni Malinen                                            PGP id EFC895FA