Problem with BSS properties

[Marcel Holtmann]

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.
> > > > 
> > > I think that instead "Mode" (string), "Adhoc" (boolean) would be better,
> > > but thats fine for me to remove capabilities property.
> > 
> > using "Mode" would be more appropriate since we do the same for the
> > capabilities in the interface object.
> > 
> > > > 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
> > > > translation?
> > > > 
> > > That would be a kind of redundancy since we still need SSID property. I
> > > would left translation for clients like NM.
> > 
> > I am fully aware that it would be duplication. However in case of magic
> > for Chinese SSID for example, it could be nice if we do this only once.
> > It is just an idea.
> 
> I'd prefer not.  It's really, really icky.  I don't think the supplicant
> should be in the business of doing that.
> 
> Here's the problem: you have *no* idea what encoding the user's browser
> was in when they submitted the SSID (or the WPA passphrase for that
> matter, but that's a whole different problem).  You also have no idea
> what encoding the AP's software decided to use when converting the
> string to an actual SSID.  It could be UTF-16, UTF-8, ISO-8859-1,
> ISO-8859-15, etc.  There's just no way to figure it out.
> 
> So seriously; the client is the thing that needs to represent the SSID
> because the client is closest to the user.  What we do in nm-applet is a
> combination of fallbacks including trying converting to UTF-8 based on
> LANG.  That's obviously not perfect but this problem is not solvable as
> long as the SSID is a byte string.  I really don't think the supplicant
> should be in the business of trying to fuzz out a readable SSID.

I could see the supplicant together with the IE country details being
able to make a really good guess. By all means fair enough. Just export
the binary SSID byte array.

Regards

Marcel