Problem with BSS properties

[Marcel Holtmann]

Hi Witold,

> >> so I am heavily toying with the new D-Bus API right now and I found some
> >> weird behavior with within the BSS interface. So basically every BSS
> >> object contains one property with the name "Properties". That is just
> >> stupid and I hope it is just a bug.
> >>
> >> We should actually put the BSS properties as real properties of the BSS
> >> interface. Then the PropertiesChanged signal could be doing something
> >> meaningful and actually indicate signal strength changes etc.
> > 
> > I think that's what the spec from last summer originally had actually;
> > maybe the implementation just got mixed up.  I see that I perhaps didn't
> > make the spec completely clear:
> > 
> > O: /fi/w1.wpa_supplicant1/Interfaces/<interface_number>/BSSs/<BSSID>
> > I: fi.w1.wpa_supplicant1.Interface.BSS
> > 
> > P: <BSS properties - identical to old API BSSID properties> (read-only)
> > 
> > 
> > But yeah, each BSSID property should just be exposed as a property of
> > the object instead of a "Properties" property as a dict as you say.
> > 
> I misunderstood the spec and I agree that it doesn't make a lot of
> sense. I'll fix it soon. New issue appears now. When new scan results
> arrive we will need to have both the new and the previous results in
> order to compare properties (like signal level) and send appropriate
> PropertyChanged signals. The problem is that Jouni doesn't like having
> both the old and the new scan results at the same time because of risk
> of excessive memory usage. So we have three options now:
> 1) Don't send PropertyChanged signals when BSS properties changes.

we need that PropertiesChanged signal. Besides the signal strength,
someone could have changed the security settings and I do like to know
about that.

> 2) Keep both the new and the previous results  (and use memory for both)
> and compare all BSS properties.

Since we have the BSS object struct. We can just keep a copy of these
there.

> 3) Keep only these BSS properties which really can change (level and
> quality. anything else?).

Storing just the bare minimum might be enough. It depends a bit on how
the unique BSS identifier gets constructed in the future. If it includes
the SSID then we don't need to cache the BSSID and SSID.

I also would just get rid of quality and noise values. I don't see any
need for them. Just use level or signal like iw scan calls it should be
enough.

Potentially the capabilities, maxrate and frequency can change, too. And
all of them seem to be useful. Changes in WPAIE, RSNIE and WPSIE are
useful since they can change over time as well.

Regards

Marcel