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.
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?
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);
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.
> 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?
Anway, I'll update the bug (399292) I logged for this to reflect what
this discussion, to put a bit of detail in.
Simon.
Attachment:
signature.asc
Description: This is a digitally signed message part