Problem with BSS properties

Marcel Holtmann marcel
Fri Dec 25 15:13:34 PST 2009

Hi Dan,

> > 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.

this is how I remember and also understood the specification. I am
almost done with a patch to fix this. However I will be off for the rest
of the day so I will not be able to finish it until later tomorrow.

I am planning to add "Mode" (string) and "Privacy" (boolean) properties
that can be used instead of manually decoding the capabilities. Actually
exposing the raw capabilities of a BSS is pretty much pointless from my
point of view.

The other thing are the quality and noise properties. Do you still want
these? Or can we just go for a signal property showing the dBm value
like iw scan does. I don't see any extra value in keeping deprecated
values in the new API.

Do you think a "Display" or "Name" property showing the SSID in
converted UTF-8 would be useful. Or should the clients do that



More information about the Hostap mailing list