[gutsy] segfault retrieving passphrase for WiFi network

Funny - even with patch applied, all is not 100% normal.

After loading patched nm-applet:

the network is found
when I click on it prompts for a passphrase
NM connects to the network
The passphrase is stored in the keyring
NM disconnects the network

I then have to re-select it before the network will stay connected. (Perhaps the disconnect is related to storing the passphrase in the keyring?)

Personally, I am unable to duplicate this with network-manager-gnome 0.6.5-0ubuntu1 (the Ubuntu version released earlier today).

I just installed the ubuntu released version, and can reproduce the crash again.

Its a WPA Personal secured WiFi network which I connect to.

First of all, I have to disable networking, and kill nm-applet. This hopefully means I loose association on my WiFi, and the pass-phrase is not cached anywhere in network-manager.

I then open up gnome-keyring-manager, find the key for that network, and delete it.

Now reload nm-applet:

gdb --args nm-applet --sm-disable

(--sm-disable avoids you getting lots of copies next time you log on).

Once you've got the list of WiFi networks again, (having re-enabled networking), I click my home network - which I no-longer have a gnome-keyring key for.

Segfault. (No stack trace, as I don't know where to get a dbg package from).

So - I fetched the Ubuntu source and built it, running the un-stripped binary from the build-tree...

As before,

0x0805fafc in nmi_dbus_get_network_key_callback (
    result=GNOME_KEYRING_RESULT_OK, found_list=0x0, data=0x83d3bc8)
    at applet-dbus-info.c:117
117 nm_gconf_wso_set_key (gconf_wso, found->secret, strlen (found->secret));
(gdb) bt
#0 0x0805fafc in nmi_dbus_get_network_key_callback (
    result=GNOME_KEYRING_RESULT_OK, found_list=0x0, data=0x83d3bc8)
    at applet-dbus-info.c:117
#1 0x4d25ba28 in ?? () from /usr/lib/libgnome-keyring.so.0
#2 0x00000000 in ?? ()
(gdb)

If you can point me at where to find a -dbg package for network-manager-gnome, and / or libgnome-keyring, I'll try and get a better stack trace.

Obviously clearing out the gnome-keyring keys isn't a common thing for a user to do, but in the first instance, I hit this after an upgrade - having never touched the keys.

What version of libgnome-keyring0 do you have installed?

Peter

I am also seeing nm-applet crash when trying to connect to my WPA-1 network.

libgnome-keyring0 is 2.19.4.1-0ubuntu1 on my system.

Joel, I found a workaround I think... if it helps you get going.

My network is called "newtonroad2", and network-manager stores some info about it in gconf..
Eg. /home/pcjc2/.gconf/system/networking/wireless/networks/newtonroad2/...

I killed off nm-applet:
killall nm-applet
(Or just let it crash)

Deleted the gconf entries with:
gconftool-2 --recursive-unset /system/networking/wireless/networks/newtonroad2

Then opened gnome-keyring-manager, and deleted the key for newtonroad2.

Upon restarting nm-applet, I was able to connect, enter the WPA Passphrase and get back on the network.

The workaround that Peter Clifton posted also resolves the issue I had connecting to my local WPA-PSK secured network.

The patch fixes the symptom for me (on top of 0.6.5-0ubuntu1), but i suspect the real bug would be libgnome-keyring0 forgetting the stored password.

After a restart, I *am* seeing the issue. I have changed the bug's status to confirmed.

i got hit with this one today, too, after doing a dist-upgrade.

the posted workaround also took care of the problem for me.

Same here - WEP-secured wireless working perfectly yesterday; accepted the 0.6.5 nm update and no wireless on reboot.

The workaround doesn't help me - none of the files mentioned exist in my /.gconf - not even ../system. Searching for folders called "networks" and even "wireless" doesn't turn up anything hopeful either.

Also, I don't see any keyring for the network in keyring-manager, so I can't delete it.

What would I do with the "patch" file Peter posted earlier - how do I apply it?

OK, it's fixed for me! I found that the new nm-applet works in ways I hadn't seen with the old one - and finally got it to accept the pass-key by switching networks in automatic (not manual) mode. At that point it asked me for a password to set up a keyring - the old one never did that, which is why I didn't have a keyring to delete!

I'm sure all this is detailed in "man nm-applet" - my bad for not looking before complaining......

I also thought originally that this is a network-manager issue, but it's actually gnome-keyring who's at fault here. gnome-keyring and libgnome-keyring0 were recently upgraded in gutsy to 2.19.4.1 from 0.8.1. The latest network-manager from gutsy works great with the old version, but breaks down completely for me with the new one. Even when I applied a workaround mentioned here, wireless connections only lasted a few seconds before breaking up, and network-manager was segfaulting constantly.

So, I went to packages.ubuntu.org, downloaded libgnome-keyring0 and gnome-keyring for feisty, and downgraded them. Everything is back to normal now.

Some of the symptoms of network-manager 0.6.5's differences in communication between keyring 0.8.1 and 2.19.4.1. When I login, I'm normally prompted for my keyring password only. With the latest gutsy version 2.19.4.1, I was instead prompted to "Deny, Allow once, Allow always" for nm-applet. network-manager would then crash. It only "worked" when I had keyring-manager application open at the same time, and even then it would try to connect unsuccessfully for a long time or connect and then crash or disconnect immediately. I'm using WPA2 PSK (AES) with Atheros non-GPL driver (madwifi).

You are probably right that there is something going wrong in keyring, Sergey.

But there is also a MAJOR change in the way nm-applet works, at least for me. As far as I can see, nm 0.6.4 never set up a keyring, either in Feisty or in Gutsy. The 0.6.5 version seems to do it whether I want it to or not. Why is this? Isn't a keyring supposed to be an optional additional convenience - in this case, so we don't have to keep searching for the bit of paper with the WEP or WAP passkey written on it? I would prefer to be asked if I want this new behavior, preferably AFTER the network connection has been established correctly without any hassle.

This is a significant blemish in the "It Just Works" for me - whether or not there are flaws in keyring.

It's always set up a keyring for me when connecting to secured networks. Last I knew, version .7 was slated to find some fix for this, and a few other annoyances. It's well known to be annoying and not "It just works". It's one of two features left on the TODO for .7, but I don't know if anyone's actually working on it.

Thanks for the insight - nice to know someone has noticed before.....

Hope someone gets around to making it optional.

Stephen Cradock

>From: Justin Dugger <email address hidden>
>Reply-To: Bug 121228 <email address hidden>
>To: <email address hidden>
>Subject: [Bug 121228] Re: [gutsy] segfault retrieving passphrase for
>WiFinetwork
>Date: Fri, 22 Jun 2007 22:38:46 -0000
>
>It's always set up a keyring for me when connecting to secured networks.
>Last I knew, version .7 was slated to find some fix for this, and a few
>other annoyances. It's well known to be annoying and not "It just
>works". It's one of two features left on the TODO for .7, but I don't
>know if anyone's actually working on it.
>
>--
>[gutsy] segfault retrieving passphrase for WiFi network
>https://bugs.launchpad.net/bugs/121228
>You received this bug notification because you are a direct subscriber
>of the bug.

_________________________________________________________________
Get a preview of Live Earth, the hottest event this summer - only on MSN
http://liveearth.msn.com?source=msntaglineliveearthhm

Sergey recommended downgrading gnome-keyring and libgnome-keyring0 to the version used in feisty - 0.8.1.

I did that, and at least I could get connected.

Then I found that the nm-applet asks for the passkey when connecting, and THEN still tries to set up a keyring. Talk about redundant.....

So I deleted the default keyring in Keyring Manager, and tried again. Same thing happens, time after time. Asks for passkey, then asks for a password to set up a keyring to store the passkey in. Deny allows connection, but doesn't stop the same thing happening next time. Setting password and then deleting keyring - it justs asks again next time I boot.

I want to be able to use nm-applet in automatic connect mode without setting a keyring! Why can't I do that?

And while I'm ranting - has anyone tried to use the help function in Keyring Manager? One section: Introduction. Content: "Welcome!". No explanation of functions, how to use it, what you can and can't do, how to turn it OFF.

I agree with Srgey that there is a major problem in the new version of gnome-keyring.

But I also think something is wrong with nm-applet - at least, it isn't "Just Work"ing.

TODO: investigate why gnome-keyring sends 0x0 as result list though
result is GNOME_KEYRING_RESULT_OK

0x0 (NULL) is of course a valid g_list, (The empty g_list).
an empty list of found
typedef enum {
 GNOME_KEYRING_RESULT_OK,
 GNOME_KEYRING_RESULT_DENIED,
 GNOME_KEYRING_RESULT_NO_KEYRING_DAEMON,
 GNOME_KEYRING_RESULT_ALREADY_UNLOCKED,
 GNOME_KEYRING_RESULT_NO_SUCH_KEYRING,
 GNOME_KEYRING_RESULT_BAD_ARGUMENTS,
 GNOME_KEYRING_RESULT_IO_ERROR,
 GNOME_KEYRING_RESULT_CANCELLED,
 GNOME_KEYRING_RESULT_ALREADY_EXISTS
} GnomeKeyringResult;

Possible options there... do any of these actually apply in the "couldn't find the key you asked for" case?

What should it return?

A cursory glance at the (poorly documented gnome keyring code / API) suggests that finding no keys is not special cased to return a different code.

The first time I ask to switch to my Wi-Fi network, gnome-keying-manager is asking permission for giving the passphrase to nm-applet:

Allow application access to keyring?
---------------------------------------------
The application 'nm-applet' (/usr/bin/nm-applet) wants to access the password for '' in (null).

I grant access and nm-applet crashes.

Notice the "null" reference in the dialog. It looks like an API/ABI mismatch.

  network-manager-applet (0.6.5-0ubuntu4) gutsy; urgency=low

  * debian/patches/01_static_network-admin.patch: fix by Peter
    Clifton; adding NULL check to stop nm-applet from crashing
    and make encrypted wifi work. (LP: #121228)

 -- Alexander Sack <email address hidden> Wed, 27 Jun 2007 12:34:03 +0200

Still, the n-m-applet only circumvented the actual bug in gnome-keyring: it should not return OK and deliver a NULL pointer as an answer.

The behavior has changed upstream: http://bugzilla.gnome.org/show_bug.cgi?id=447315

The underlying issue of not unlocking the keyring when trying to access a key - as mentioned in comment #15 - should be fixed now upstream in gnome-keyring http://bugzilla.gnome.org/show_bug.cgi?id=451710 . SVN trunk works fine here again

Fixed Upstream.

 gnome-keyring (2.19.5-0ubuntu1) gutsy; urgency=low
 .
   * New upstream version:
     * Allow passing NULL as a password to gnome_keyring_unlock()
     * Added strerror() like functionality for GnomeKeyringResult
     * Added support for async version of gnome_keyring_item_grant_access_rights_sync()
     * Handle unix signals properly, quit gracefully.
     * Fix memory leaks [Alexander Sack]
     * Make unit tests automatic when building a distribution tarball
     * Fix prompt messages [Juerg Billeter]
     * Fix problems prompting for access to items when the keyring is locked.
     * Non-pageable memory degrades gracefully on Solaris, FreeBSD
     * Build fixes [Theppitak Karoonboonyanan, Christian Kirbach]
     * API Documentation
   * debian/patches/error_handling.patch
     - removed (since this is fixed upstream)
   * bumped shlibs, new functions available

I can verify this seems to be corrected today.

I can confirm the fix here too