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