Re: Errors running current SVN code

[Dan Williams <dcbw redhat com>]

On Wed, 2007-01-31 at 21:23 +1300, Simon Geard wrote:
> On Tue, 2007-01-30 at 12:13 -0500, Dan Williams wrote:
> > Yeah; there are bits of NM that assume a string SSID, and those are
> > going to get removed with 0.7 and the SSID will be a plain byte array.
> 
> More than just 'bits' of NM, so far as I can tell - pretty much every
> piece of code I've encountered has assumed it's a string, starting with
> the NMAccessPoint struct that gets passed around and accessed via
> nm_ap_get_essid(). Much of it also does stuff like "if (essid)" to test
> if one exists, all of that I guess broken. I guess the fix is to store
> ssid_len in the struct, and add get/set functions for it.

Which was pretty much par for the course in Linux wireless stuff a few
years ago when much of that code was written, which we all know is of
course wrong.

We can change the internal stuff in 0.6, but we cannot change the DBus
interface.

> Similar changes will be needed for the D-Bus interfaces, which
> consistently treat the SSID as a string, and will presumably need to
> treat it as a byte array instead?

Exactly, a byte-array with a length in the range of 0 - 32.

For the object paths, we will no longer use the SSID in the object path.
The object ID will simply be an unsigned integer that starts at 0 and
counts up to UINT_MAX (ie, 4 billion).  The SSID will be another
property of the object to which the object path refers.  Of course, this
requires a D-Bus API change which is why we can't do it on the stable
0.6.x branch.

The 0.7 D-Bus object model for a BSSID will be something like the
following.  Note that every BSSID should be split out both internally,
and externally.  This puts a bit more onus on the clients themselves to
coalesce the BSSIDs into something presentable for the user.  For
example, the nm-applet will with 0.7 be in charge of combining similar
BSSIDs into one menu item for each SSID.

|
|-/org/freedesktop/NetworkManager/Devices/0/BSSIDs/0
|    |- ssid:  0x0000000000000000 [byte array, max size 32]
|    |- freq:  2.432 [float]
|    `- bssid: 0x112233445566 [byte array, size ETH_ALEN]
|-/org/freedesktop/NetworkManager/Devices/0/BSSIDs/532
|    |- ssid:  'foobar' [byte array, max size 32]
|    |- freq:  2.462 [float]
|    `- bssid: 0x00ab7cdefe01 [byte array, size ETH_ALEN]
`-/org/freedesktop/NetworkManager/Devices/0/BSSIDs/44
     |- ssid:  '2WIRE95' [byte array, max size 32]
     |- freq:  2.417 [float]
     `- bssid: 0x12adbf3e0167 [byte array, size ETH_ALEN]
  
Note also that devices themselves are assigned a UID, because if you
change 'eth0' to something else on the fly (interface renaming is
obviously allowed) then NM shouldn't break here either.  Having human
readable names was somewhat more compelling in the early days of D-Bus
when there weren't as good API, tools, and documentation.  But that day
is long past.

> They also use printf to format the SSID into the D-Bus paths for
> invoking methods, which is what's causing my reported problem. E.g:
> 
> object_path = g_strdup_printf ("%s/%s/Networks/%s", 
> 	NM_DBUS_PATH_DEVICES, 
> 	nm_device_get_iface (dev), 
> 	nm_ap_get_essid (ap));
>   escaped_object_path = nm_dbus_escape_object_path (object_path);
>   g_free (object_path);

See above.  SSID will not and should not be part of the object path in
D-Bus, nor in GConf.

> I assume some sort of encoding will be needed for the SSID passed here?
> Would it be sufficient to use the same encoding as performed by
> nm_dbus_escape_object_path, so that we end up with a value something
> like /org/freedesktop/NetworkManager/Devices/ath0/Networks/_0__0__0__0__0__0__0__0_ ?
> 
> 
> Well, my C skills are a little rusty, but if nobody else has time to
> pick this up, I can have a try.

Sure!  I think the first step is to change NMAccessPoint so that the
'ssid' member is a u8[32].  I'd also like to change 'essid' to 'ssid'
for NMAccessPoint too.

Furthermore, I'd like to change the name of NMAccessPoint, but I'm not
yet sure what to.  NMBSSID is much more appropriate, but looks really
ugly.

> 
> > A blank SSID of all 0s is perfectly legal; we do need to figure out how
> > to deal with this in UI.  It's kind of an evil way of disguising your AP
> > as a lot of user tools won't work with it.  What does Windows and Mac OS
> > X do here in their GUI bits?  I don't mean the Linksys or DLink tools
> > that you can install 3rd party, but what does the Airport menu show for
> > this AP?  If it doesn't show it, how do you connect to it on OS X?
> 
> It's not pretty, but how about the approach taken by wlanconfig? The
> madwifi guys have basically declared that if the value is non printable
> (any ASCII characters less than 0x20 or more than 0x7e), the whole thing
> should just be rendered in hexadecimal. Is that practical for NM?

Only for debugging output; since we won't be passing a "printable" SSID
outside of NM (it will always be a 32 item byte array over D-Bus), we
won't need to do this.  Tools that interface with NM over D-Bus (the
applet) will of course need to figure out how to convert random SSIDs to
a printable string if only for a dropdown menu or entry of the SSID from
a CLI.

We also need to figure out where Tambet Ingo is with his changes so that
we don't create unnecessary merge conflicts, but that shouldn't be too
hard.

Thanks!
Dan

> 
> Anway, I'll update the bug (399292) I logged for this to reflect what
> this discussion, to put a bit of detail in.
> 
> Simon.
> _______________________________________________
> NetworkManager-list mailing list
> NetworkManager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list