Bug 138404

This is because gnome-keyring is not running.  It needs to be running.

By and by, gnome-keyring should be started automatically by something, and the library should start it automatically as a last resort if it is not.

If these are not happening (I am sure that GNOME itself starts it ...) then perhaps there is a bug, but not in NM.

While I would prefer the old behavior of simply being able to enter the passphrase even if the keyring is not running, I accept that a running keyring is a requirement.
But in the error case when we don't have the keyring, nm-applet should say so (a message on the console would be fine) instead of appearing broken. Aren't you able to detect such a situation?

BTW, which library should start the keyring automatically?

I don't think it is appearing broken, it sounds as if it is disabling keyring-requiring features by greying them out.

libgnome-keyring should start gnome-keyring, I guess.  It seems silly to push this behavior into the clients.

If you aren't using GNOME, why not use KNM?

It gets more interesting. I have tried to start a regular GNOME session (WINDOWMANAGER=gnome startx). gnome-session and gnome-keyring are running. Yet I cannot enter the passphrase. I suspect a library incompatibility between the 10.0 GNOME libraries and the recent NM.

Created attachment 61000 [details]
nm-applet-nokey.png

This is how it looks like. I don't think it is an intentional disabling of a feature.

Okay, but I don't think this is an NM bug.  gnome-keyring needs to be running ...

I just verified that disabling the 'Connect' button is an intentional feature in the code whenever the security subsystem reports a failure (e.g., gnome-keyring fails).

I consider this NOTABUG ...

Marking resolved.

So now I have retried on SL 10.1 Alpha4 (aka Preview2) and get the same problem. But this time there should be no incompatibility (comment 5). Also, I have started the GNOME session from GDM, GNOME_KEYRING_SOCKET is set and has good permissions, the keyring daemon is running.

Even if the applet disables the widgets intentionally, it should print a diagnostic message.
But now I believe the keyring should really work. How can I debug it?

Hi, Martin.  Can you retest, whenever you get a chance, with 0.5.1cvs20060112, once it pops out of autobuild?  There is some new code wrt the security dialog.

Also, can you run "nm-applet --sm-disable" from the command line, so we can get the output from the applet when you pop up the dialog?  Please attach the output to this bug.

Danke, sir!

*** Bug 144268 has been marked as a duplicate of this bug. ***

Bart: Can you run nm-applet from the console and see if any warnings/errors/spew show up when you instantiate the dialog?

Also, does selecting an encrypted network from the scanlist work?

Here is the output from nm-applet.  Following the output below I see this: 
https://bugzilla.novell.com/attachment.cgi?id=64101&action=view


> nm-applet

** (nm-applet:6542): WARNING **: <WARNING>       hal_info_vendor_cb (): hal_info_vendor_cb(): dbus returned an error.
  (org.freedesktop.Hal.NoSuchProperty) No property info.vendor on device with id /org/freedesktop/Hal/devices/pcmcia__1__1



** (nm-applet:6542): WARNING **: <WARNING>       hal_info_vendor_cb (): hal_info_vendor_cb(): dbus returned an error.
  (org.freedesktop.Hal.NoSuchProperty) No property info.vendor on device with id /org/freedesktop/Hal/devices/pcmcia__1__1



** (nm-applet:6542): WARNING **: <WARNING>       hal_info_vendor_cb (): hal_info_vendor_cb(): dbus returned an error.
  (org.freedesktop.Hal.NoSuchProperty) No property info.vendor on device with id /org/freedesktop/Hal/devices/pcmcia__1__1

Ah, useful.  Thanks, Bart.

Hrm, that does not seem to be related.  Bummer.

That was my thought as well. 

Bart: I just submitted 0.5.1cvs20060127 (not yet build).  Whenever it pops out the other end and you get the chance, can you please retest?

This version has a debugging check that will emit one or two lines from nm-applet.  Can you paste the output from nm-applet with this version, please?

Also, it has a hack that may or may not fix the problem.  Even if not, it should help narrow down the issue.

Martin: Feel free to test, too.

Thank you!

with 0.5.1cvs20060127 the output is identical to #14.  There is no additional output, and it still does not work.  Or perhaps I'm not invoking nm-applet quite like you want me to.  I simply run it from an xterm.  Note that this causes two NM tray icons to be present. 

Kill all instances of the applet, so that there are only one running.  Session management may restart it; you need to kill it quickly or remove it from the session.

Running it from an xterm is fine.

Are you still seeing this dialog:

https://bugzilla.novell.com/attachment.cgi?id=64101&action=view

?

There is definitely a printf sitting there.

Here we go. 
> killall nm-applet; nm-applet

** (nm-applet:5578): WARNING **: <WARNING>       hal_info_vendor_cb (): hal_info_vendor_cb(): dbus returned an error.
  (org.freedesktop.Hal.NoSuchProperty) No property info.vendor on device with id /org/freedesktop/Hal/devices/pcmcia__1__1



** (nm-applet:5578): WARNING **: <WARNING>       hal_info_vendor_cb (): hal_info_vendor_cb(): dbus returned an error.
  (org.freedesktop.Hal.NoSuchProperty) No property info.vendor on device with id /org/freedesktop/Hal/devices/pcmcia__1__1



** (nm-applet:5578): WARNING **: <WARNING>       hal_info_vendor_cb (): hal_info_vendor_cb(): dbus returned an error.
  (org.freedesktop.Hal.NoSuchProperty) No property info.vendor on device with id /org/freedesktop/Hal/devices/pcmcia__1__1


** Message: <information>       nmi_passphrase_dialog_new(): Found caps '1' for network 'abcdefghijk'


** (nm-applet:5578): WARNING **: <WARNING>       nmi_dbus_return_user_key (): nmi_dbus_return_user_key(): couldn't serialize gconf_wso

'abcdefghijk' is a valid non-broadcasting AP with WEP?

Yes.  It works with "Traditional method with ifup", and has worked with various versions of NM. 

Alright.  Bart, whenever you get a chance, can you test 0.5.1cvs20060130?  It should pop up an error dialog.

Martin, I would like to know if you are still seeing this problem, too.

With the Beta2 release (20060123) I get asked for the passphrase and it works with the keyring too.
I guess it obviously depends on the net I connect to, but how about the card driver? I am using a different one now (hostap), my Ralink has other problems.

Martin: Great.

It depends on the overlap between the wireless network's reported required security methods and your card's.  There is now a dialog in place to explain the error, instead of the broken dialog.  And some debugging info is printed.

I think this bug is fixed (waiting to see what Bart says), but your wireless drivers probably _do_ support the wireless security and they just lie.  So we need to fix those.

Bart confirms fixed.