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.
> > 
> So in the best case we would like to be notified about changes in any
> property.

normally all of them that we do export should have change notifications.
Only the ones we are not using and are guaranteed to not change can be
omitted.

> Jouni was worried of excessive memory usage on embedded devices, but
> these doesn't use DBus interface. Am I right? I would assume that a
> system which use wpa_supplicant with DBus interface has quite a lof of
> RAM and a few additional KBs (even more than 100kB in worst case)
> shouldn't be a problem. We would copy whole previous scan results but
> keep in in DBus code (i.e. within #ifdef CONFIG_CTRL_IFACE_DBUS_NEW).
> That would make code a bit less clean, but we would be able to compare
> all BSS properties, and Jouni would be happy having limited memory usage.

I can see the point of the extra memory usage, but what can we do. For
every device with any kind of visual user interface, we have to keep the
values somewhere. And I prefer to have these change notification inside
wpa_supplicant instead of complicating the client code.

Regards

Marcel