GNOME Bugzilla – Bug 399292
NM fails to deal with ESSID's that aren't valid strings
Last modified: 2008-04-27 21:46:50 UTC
Steps to reproduce: The problem occurs simply when starting nm-applet, either through logging in or starting from terminal. The applet crashes a second or two later, reporting the following error to the terminal: process 29312: arguments to dbus_message_new_method_call() were incorrect, assertion "_dbus_check_is_valid_path (path)" failed in file dbus-message.c line 1079. This is normally a bug in some application using the D-Bus library. D-Bus not built with -rdynamic so unable to print a backtrace Some tracing indicates that the code is attempting to invoke the method org.freedesktop.NetworkManager.Devices.getProperties() using a path of /org/freedesktop/NetworkManager/Devices/ath0/Networks/. From what I can see of the code, this should be including the essid at the end, and probably is occurring in nm_dbus_get_object_path_for_network(). I've not had a chance to read through the code thoroughly to find out why the essid is missing, but assume the nm_ap_get(ap) call is returning an empty string. Please let me know promptly if there is any more information you need. I'm running on SVN revision 2242, so I've got all the latest code. Stack trace: Other information:
Been investigating the issue since raising the bug, and some discussions on the mailing list have turned up an explanation. My neighbourhood apparently contains an access point with an SSID consisting of eight zero-bytes, which according to Volker Braun is a perfectly valid SSID under the spec. However, NM treats SSIDs as zero-terminated strings rather than byte arrays, and therefore breaks in a few places when it sees this access point. The visible problem is that when constructing D-Bus paths, nothing gets rendered for the SSID, causing libdbus to fail asserting on an invalid path. Previous NM versions didn't crash on this, since they appear to simply discard this access point. Several elements come to mind in needing fixing: * The struct NMAccessPoint needs to be changed to store an ssid length alongside what is currently treated as a string. Functions should be added to get/set the length, and should be called wherever nm_ap_get_essid and nm_ap_set_essid are called. * The D-Bus interfaces have the same problem, and presumably need to be altered to pass values as byte arrays/lengths instead of strings. * The D-Bus paths for networks need to allow for invalid values like this one, since it currently produces an invalid path and crashes libdbus. It should be sufficient to encode the SSID with nm_dbus_escape_object_path before creating the path, instead of after (i.e _0__0__0__0__0__0__0__0_). * The unprintable value needs to be handled somehow in the UI. One option is to simply render any non-printable SSID as a hexadecimal string, as done by wlanconfig (and allow it to be entered in the same format?). Another (from Volker) is to substitute '.' for unprintable characters, and allow them to be entered with backslash escape sequences. So, comments please?
*** Bug 389574 has been marked as a duplicate of this bug. ***
NM 0.6.x shouldn't be letting hidden SSIDs through the D-Bus interface, they should be getting filtered out before being added to the device's network list when GetProperties() is called on a device. Beyond that, I've committed fixes for the case where an AP includes a '/' character which would cause NM and the applet to be kicked off the bus in certain instances. I think that should fix the remaining issues with bad characters in SSIDs. Unfortunately, NM 0.6.x won't ever be able to deal with SSIDs that contain embedded NULLs properly. NM 0.7.x handles this just fine though. r3307
*** Bug 474543 has been marked as a duplicate of this bug. ***
*** Bug 517254 has been marked as a duplicate of this bug. ***
*** Bug 436553 has been marked as a duplicate of this bug. ***
*** Bug 517255 has been marked as a duplicate of this bug. ***
*** Bug 517256 has been marked as a duplicate of this bug. ***
*** Bug 517593 has been marked as a duplicate of this bug. ***
*** Bug 517594 has been marked as a duplicate of this bug. ***
*** Bug 517853 has been marked as a duplicate of this bug. ***
*** Bug 517932 has been marked as a duplicate of this bug. ***
Fixed in 0.6.6 and trunk.