Created attachment 124773 [details] [review]
This patch fixes the issue for me.

I came up with this patch because I noticed from the log file that it was setting values for "psk", "wep_key0", "wep_key1", "wep_key2", and "wep_key3" even though wep_key0 is the only one that actually has a value.  The rest are empty and it appears that trying to set these to empty in the supplicant config messes things up.

I'm not sure if this is the most correct fix, because I don't know if perhaps the right fix is that nm_setting_wireless_security_get_psk and nm_setting_wireless_security_get_wep_key should be returning NULL.

I can confirm this. Without the patch I can not associate with a WEP network using a global WEP key in /etc/NetworkManager/nm-system-settings.conf/ config. I get the same error "set_network_cb(): Couldn't set network config: Did not receive correct message". With the patch I can now connect.

https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/288963

Phillip's patch solves the problem for me as well.

(In reply to comment #1)
> Created an attachment (id=124773) [edit]
> This patch fixes the issue for me.
> 
> I came up with this patch because I noticed from the log file that it was
> setting values for "psk", "wep_key0", "wep_key1", "wep_key2", and "wep_key3"
> even though wep_key0 is the only one that actually has a value.  The rest are
> empty and it appears that trying to set these to empty in the supplicant config
> messes things up.
> 
> I'm not sure if this is the most correct fix, because I don't know if perhaps
> the right fix is that nm_setting_wireless_security_get_psk and
> nm_setting_wireless_security_get_wep_key should be returning NULL.

The real question is why those are getting set with a zero-length string in the first place...  they shouldn't be.  If they are !NULL and zero-length, they are actually invalid.

libnm-util wasn't properly validating the PSK property, but it *was* validating wep_key0 - wep_key3.  Any chance that somebody who has this problem could try to track down where they get set incorrectly?  You'll probably want to look into src/nm-activation-request.c around update_one_setting()... the setting_hash variable is the GHashTable mapping char*::GValue, and we need to find out if any of those GValues contain zero-length strings.  See the attached patch, if anyone can try that out and run NM as root in a terminal (ie, with --no-daemon), that would be great.

Created attachment 126284 [details] [review]
debugging patch to show if settings service returns !NULL zero-length secrets

Hi Dan, I ran it with your debug patch and here are the relevant lines:

lt-NetworkManager: ***** print_secrets: settings service returned non-NULL zero-length string for 802-11-wireless-security / wep-key1
lt-NetworkManager: ***** print_secrets: settings service returned non-NULL zero-length string for 802-11-wireless-security / wep-key2
lt-NetworkManager: ***** print_secrets: settings service returned non-NULL zero-length string for 802-11-wireless-security / wep-key3
lt-NetworkManager: ***** print_secrets: settings service returned non-NULL zero-length string for 802-11-wireless-security / psk
lt-NetworkManager: ***** print_secrets: settings service returned non-NULL zero-length string for 802-11-wireless-security / leap-password

Would it help more if I pasted the entire output?

Nope, that should be OK.  I'll poke around some more.

Not sure if this helps, but I ran dbus-send (which was fun to learn about) to
further confirm what we're seeing (non-null zero-length secrets):

dbus-send --system --print-reply
--dest=org.freedesktop.NetworkManagerSystemSettings --type=method_call
/org/freedesktop/NetworkManagerSettings/0
org.freedesktop.NetworkManagerSettings.Connection.Secrets.GetSecrets
string:'802-11-wireless-security' array:string: boolean:false
method return sender=:1.1795 -> dest=:1.2227 reply_serial=2
   array [
      dict entry(
         string "802-11-wireless-security"
         array [
            dict entry(
               string "wep-key0"
               variant                   string "**************************"
            )
            dict entry(
               string "wep-key1"
               variant                   string ""
            )
            dict entry(
               string "wep-key2"
               variant                   string ""
            )
            dict entry(
               string "wep-key3"
               variant                   string ""
            )
            dict entry(
               string "psk"
               variant                   string ""
            )
            dict entry(
               string "leap-password"
               variant                   string ""
            )
         ]
      )
   ]

(FYI, I starred out wep-key0)

In case the question should arise, no those secrets are not mentioned in my connection file (except wep-key0):

[802-11-wireless-security]
key-mgmt=none
wep-tx-keyidx=0
auth-alg=open
wep-key0=**************************

So if I understand correctly, the real bug is in nm-system-settings, right?

I just realized that the nm-system-settings being run is the one installed by my distro (in /usr/sbin/), not the one I just built with NetworkManager from the latest svn source.

So now I'm trying to run the right one, but I get several Glib-CRITICAL errors followed by a warning, and then a seg fault:

(nm-system-settings:4036): GLib-CRITICAL **: g_key_file_set_value: assertion `g_key_file_is_group_name (group_name)' failed

(repeated 11 times)

** (nm-system-settings:4036): WARNING **: Error parsing file '/etc/NetworkManager/system-connections/connection': File is empty

The seg fault occurs in main.c inside have_connection_for_device on line 312:
   if (   strcmp (connection_type, NM_SETTING_WIRED_SETTING_NAME)

If you know what I can do to get past this seg fault, I'll continue helping track down this bug.

Thanks,
Phillip

Oops, sorry everyone for the noise.  Please ignore that last comment; it was totally bogus because I had it running with the wrong shared libraries for the plugins.

Ok, now for the good news.  The bug is totally GONE when I run the latest nm-system-settings.  Not only was I able to connect to my network (without the original patch I submitted), but I verified nm-system-settings is behaving appropriately with dbus-send.  (It only responds with wep-key0 and no other secrets.)

So I'm not sure when nm-system-settings was fixed, but it is definitely working appropriately with the latest svn code.  (The version used by my distro that is broken is 0.7~~svn20081018t105859-0ubuntu1.8.10.1.)

I tracked down the fix using git bisect (though I had to reverse the good/bad logic in my brain since git bisect only works one direction).

The commit was e4ae149b37f2a25e3b4e6e545884d504921ea817 made on 2008-Nov-12 by Tambet Ingo.  As I suspected, the fix was to the keyfile plugin.

The changelog comment is very appropriate "(add_secrets): Don't add empty secrets to the secrets hash table."

The change was pretty small, but I won't post it here because I'm sure you can run "git diff e4ae149~ e4ae149" as easily as I can.

Ok, closing since NetworkManager has already fixed this bug (for the 0.7 release even) and Ubuntu ships an older version.  Thanks for finding the cause!