Problem with BSS properties

[Dan Williams]

On Fri, 2009-12-25 at 16:23 -0800, Marcel Holtmann wrote:
> 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.
> > > 
> > > 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.

Dan