[gutsy] segfault retrieving passphrase for WiFi network

Bug #121228 reported by Peter Clifton on 2007-06-19
124
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GNOME Keyring
Fix Released
Low
gnome-keyring (Ubuntu)
Medium
Unassigned
network-manager (Ubuntu)
High
Unassigned

Bug Description

Binary package hint: network-manager-gnome

After upgrading to nm-applet 0.6.5, nm-applet would segfault upon trying to retrieve the passphrase for my network.

(Ok, not a released Ubuntu package, but pre-empting the release a tiny bit by rolling my own from a vanilla gnome-network-monitor tarball and the ./debian dir from the old network-manager (modified))

Crash is:

Starting program: /home/pcjc2/source/nm-applet-0.6.5/src/nm-applet --sm-disable
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread -1214376256 (LWP 32363)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1214376256 (LWP 32363)]
0x0805fa9c in nmi_dbus_get_network_key_callback (
    result=GNOME_KEYRING_RESULT_OK, found_list=0x0, data=0x83cd710)
    at applet-dbus-info.c:117
warning: Source file is more recent than executable.
117 nm_gconf_wso_set_key (gconf_wso, found->secret, strlen (found->secret));
(gdb) bt
#0 0x0805fa9c in nmi_dbus_get_network_key_callback (
    result=GNOME_KEYRING_RESULT_OK, found_list=0x0, data=0x83cd710)
    at applet-dbus-info.c:117
#1 0xb7fa0a28 in ?? () from /usr/lib/libgnome-keyring.so.0
#2 0x00000000 in ?? ()

Patch is attached which fixed the issue for me - I just had to re-enter the passphrase afterwards, and all was ok.

It seems like gnome-keyring didn't find any matching keys (when network-manager expected to find one for a network it already knew).
nm-applet gets passed a GNOME_KEYRING_RESULT_OK status, as there is no error per-se (I think), but a NULL (empty) glist. It then proceeds
to use that glist without checking its length.

Reverting the patch, nm-applet doesn't crash again (presumably as it now finds the key which the patched version successfully stored)

Quitting nm-applet, deleting the key in gnome-keyring-manager and reloading nm-applet causes the crash to recur.

Probably ought to get pushed upstream - but I'm keen that Ubuntu gets a heads-up on this since there have already been issues with the
 network-manager-gnome binary being dropped out of network-manager.

Regards,

Peter Clifton

Peter Clifton (pcjc2) wrote :

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?)

Martey Dodoo (martey) wrote :

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

Peter Clifton (pcjc2) wrote :

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

Joel Stanley (shenki) wrote :

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.

Peter Clifton (pcjc2) wrote :

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.

vlowther (victor-lowther) wrote :

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

Gabriel Wicke (bugs-wikidev) wrote :

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.

Martey Dodoo (martey) wrote :

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

Changed in network-manager:
status: New → Confirmed
elijah wright (elijahwright) wrote :

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

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

Stephen Cradock (s-cradock) wrote :

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?

Stephen Cradock (s-cradock) wrote :

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......

Sergey (hvmptydvmpty) wrote :

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).

Stephen Cradock (s-cradock) wrote :

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.

Justin Dugger (jldugger) wrote :

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

Stephen Cradock (s-cradock) wrote :

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.

Martin Pitt (pitti) on 2007-06-26
Changed in network-manager:
importance: Undecided → High
Alexander Sack (asac) wrote :

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

Peter Clifton (pcjc2) wrote :

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.

Martin Pitt (pitti) wrote :

  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

Changed in network-manager:
status: Confirmed → Fix Released
Martin Pitt (pitti) wrote :

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.

Changed in gnome-keyring:
importance: Undecided → Medium
status: New → Triaged
Jürg Billeter (j-bitron) wrote :

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

Jürg Billeter (j-bitron) wrote :

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

Changed in gnome-keyring:
status: Unknown → Fix Released
Daniel Holbach (dholbach) wrote :

Fixed Upstream.

Changed in gnome-keyring:
status: Triaged → Fix Committed
Sebastien Bacher (seb128) wrote :

 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

Changed in gnome-keyring:
status: Fix Committed → Fix Released
Richard Harding (rharding) wrote :

I can verify this seems to be corrected today.

chantra (chantra) wrote :

I can confirm the fix here too

Changed in gnome-keyring:
importance: Unknown → Low
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.