Re: [patch] first pass at gnome-keyring support, baby.
On Thu, 2005-06-23 at 12:34 -0400, Dan Williams wrote: > Netapplet doesn't have problems because it doesn't talk to the card > much, it just does a few iwconfigs and some scanning. NetworkManager is > touching the card quite a bit, in regular intervals, and probably > exposes more bugs in drivers because nobody's really automated wireless > stuff like this before in Linux. It seems to only happen with encrypted networks. > I hear you've got a little bit of kernel experience here and there, want > to take a look at the driver? :) I have this rule: No Drivers. But maybe I should take a look ... :) > When I was looking at it, what I described was more or less the sequence > of events. The card gets wedged for some reason, but the driver keeps > sending the card packets for a bit. Each packet that the kernel network > layer adds to the outgoing tx queue, it increments the module's > refcount. Since the card never can send those packets, the refcount > never gets decreased. I've seen the usage counts as high as 21 or 22 > before. > > I have no idea what gets the card into this state, it seems to be fairly > random how long it takes. See issuecommand() in airo.c where the error > comes from. The CLEARCOMMANDBUSY stuff doesn't seem to unwedge the > card. This is a great start! Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] first pass at gnome-keyring support, baby.
On Thu, 2005-06-23 at 12:22 -0400, Robert Love wrote: > #1 sounds like me. I have the right firmware. It works in Netapplet > but it could just be behavioral differences that induce it in > NetworkManager more readily. > > I'll get backtraces next time it happens. I got some last night (not > saved, sorry) and it was a lot of spinning in mutexes. > > But then I cannot "modprobe -r airo" so I suspect the card is to blame. > And NetworkManager won't shutdown (stalls on waiting to deactivate the > airo). And if I kill it and restart, scanning does not work. > > So...while there may be NM issues, sounds like my card sucks the ass of > a wolverine. But odd that Netapplet had no problems. Netapplet doesn't have problems because it doesn't talk to the card much, it just does a few iwconfigs and some scanning. NetworkManager is touching the card quite a bit, in regular intervals, and probably exposes more bugs in drivers because nobody's really automated wireless stuff like this before in Linux. I hear you've got a little bit of kernel experience here and there, want to take a look at the driver? :) When I was looking at it, what I described was more or less the sequence of events. The card gets wedged for some reason, but the driver keeps sending the card packets for a bit. Each packet that the kernel network layer adds to the outgoing tx queue, it increments the module's refcount. Since the card never can send those packets, the refcount never gets decreased. I've seen the usage counts as high as 21 or 22 before. I have no idea what gets the card into this state, it seems to be fairly random how long it takes. See issuecommand() in airo.c where the error comes from. The CLEARCOMMANDBUSY stuff doesn't seem to unwedge the card. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] first pass at gnome-keyring support, baby.
On Wed, 2005-06-22 at 22:19 -0400, Dan Williams wrote: > Quite right. At this time NM queries nm-applet for all networks when it gets > the NameOwnerChanged. What you propose sounds reasonable. We don't really > _need_ the key until we try to connect to the access point. Agreed. > [1] Actually, it seems to work perfect. But I am having a lot of > > problems with NetworkManager and encrypted essids (or maybe just > > switching between lots of essids in general) and my airo wireless card. > > Sometimes the daemon just starts sitting there. Sometimes it stops > > scanning. In either case, it won't exit. Quick debugging shows it is > > spinning on a mutex. Although I've also seen evidence it is waiting for > > something from the card. It is confusing to the point of tears. I'll > > debug it later. I should add that, ahem, Netapplet works fine with my > > card. ;-) > > Ok, can I get some backtraces here for all threads? Also, is the airo card > borked? ie, lots of messages in /var/log/messages about "command timed out". > > There are a number of historical problems with airo cards, including but not > limited to: > > 1) Card screws up and gets hung, driver can't talk to card because commands > time > out, can't unload airo.ko because no data can be sent (card's hung) and > therefore the module refcount isn't decreased > 2) Doesn't work with firmwares > 5.20.17 and WEP > 3) Card doesn't return non-broadcasting ESSIDs from scans #1 sounds like me. I have the right firmware. It works in Netapplet but it could just be behavioral differences that induce it in NetworkManager more readily. I'll get backtraces next time it happens. I got some last night (not saved, sorry) and it was a lot of spinning in mutexes. But then I cannot "modprobe -r airo" so I suspect the card is to blame. And NetworkManager won't shutdown (stalls on waiting to deactivate the airo). And if I kill it and restart, scanning does not work. So...while there may be NM issues, sounds like my card sucks the ass of a wolverine. But odd that Netapplet had no problems. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] first pass at gnome-keyring support, baby.
On Thu, 2005-06-23 at 09:46 -0400, Dan Williams wrote: > So if we do lazy passphrase requests we'll have to make passphrase > requests from NMI pretty much like the current "Enter a new WEP key" > thing. ie, we can't connect to the access point until we have the > passphrase/key, and so we need to wait for the user to unlock it. We'll > have to set up another condition in the activation stages code to deal > with this. I'll look into it when I get some time unless somebody else > does first. Its a fairly large architectural/behavioral assumption > change though, so we need to be careful. Hrm. I will add this to me TODO but _please_ feel free to beat me to it. > For the moment, feel free to go ahead and apply the patch to add the > keyring stuff. Are you sure? I think the code is right, but it sure is annoying with the decrypt-on-startup thing. I will happily commit it if you do not mind that.. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] first pass at gnome-keyring support, baby.
On Thu, 2005-06-23 at 10:33 -0400, Bill Peck wrote: > Is there a technical reason why the keyring can't be unlocked by the > login? (Obviously the passwords would have to be the same) I know I'm > thinking in fairy land where we might have single sign on one day.. but > I can dream can't I? Well, even if you do have that, you still would have to unlock it later in the case of gdm's auto-login and other such features. Also, although it terribly pertinent in the NM case, the keyring passphrase is almost always a matter of local, per-machine configuration, whereas the user's password is often a function of the network, via NIS or LDAP. So in general even though they're often the same string of characters, they're really not the same password. One might argue for somehow having pam try to unlock it with the password if user provides one to log in. That's both technically tricky, because most gnome isn't generally running by the time you're completely done with pam, but also it means that the user might have their keyring unlocked without realizing it, which isn't such a great situation. -- Peter ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] first pass at gnome-keyring support, baby.
On Thu, 2005-06-23 at 10:33 -0400, Bill Peck wrote: > Is there a technical reason why the keyring can't be unlocked by the > login? (Obviously the passwords would have to be the same) I know I'm > thinking in fairy land where we might have single sign on one day.. but > I can dream can't I? The hack with using your system password as the keyring password will work though you also want to hook into the password changing routines to change the keyring password whenever the system password changes. It'll break miserably once you start using other authentication methods (e.g. NIS password or smart card) so single sign-on is pretty much what you want since that is needed for a host of other interesting things as well (such as encrypted homedir to name one). David ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] first pass at gnome-keyring support, baby.
On Thu, 2005-06-23 at 09:46 -0400, Dan Williams wrote: > On Thu, 2005-06-23 at 00:11 -0400, Robert Love wrote: > > On Wed, 2005-06-22 at 23:49 -0400, David Zeuthen wrote: > > > > > So, I guess my point is that we shouldn't care too much about annoying > > > gnome-keyring dialogs at this point. Not that it doesn't matter, cause > > > it does, however all that work is elsewhere really. > > > > Nod. > > > > We can do a lot better, though. Right now we force an unlock on startup > > because we parse every password. Netapplet, for example, only required > > an unlock when you actually connected to an password-protected network. > > So if we do lazy passphrase requests we'll have to make passphrase > requests from NMI pretty much like the current "Enter a new WEP key" > thing. ie, we can't connect to the access point until we have the > passphrase/key, and so we need to wait for the user to unlock it. We'll > have to set up another condition in the activation stages code to deal > with this. I'll look into it when I get some time unless somebody else > does first. Its a fairly large architectural/behavioral assumption > change though, so we need to be careful. > Is there a technical reason why the keyring can't be unlocked by the login? (Obviously the passwords would have to be the same) I know I'm thinking in fairy land where we might have single sign on one day.. but I can dream can't I? > For the moment, feel free to go ahead and apply the patch to add the > keyring stuff. > > Dan > > ___ > NetworkManager-list mailing list > NetworkManager-list@gnome.org > http://mail.gnome.org/mailman/listinfo/networkmanager-list -- Bill Peck <[EMAIL PROTECTED]> ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] first pass at gnome-keyring support, baby.
On Thu, 2005-06-23 at 00:11 -0400, Robert Love wrote: > On Wed, 2005-06-22 at 23:49 -0400, David Zeuthen wrote: > > > So, I guess my point is that we shouldn't care too much about annoying > > gnome-keyring dialogs at this point. Not that it doesn't matter, cause > > it does, however all that work is elsewhere really. > > Nod. > > We can do a lot better, though. Right now we force an unlock on startup > because we parse every password. Netapplet, for example, only required > an unlock when you actually connected to an password-protected network. So if we do lazy passphrase requests we'll have to make passphrase requests from NMI pretty much like the current "Enter a new WEP key" thing. ie, we can't connect to the access point until we have the passphrase/key, and so we need to wait for the user to unlock it. We'll have to set up another condition in the activation stages code to deal with this. I'll look into it when I get some time unless somebody else does first. Its a fairly large architectural/behavioral assumption change though, so we need to be careful. For the moment, feel free to go ahead and apply the patch to add the keyring stuff. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] first pass at gnome-keyring support, baby.
On Wed, 2005-06-22 at 23:49 -0400, David Zeuthen wrote: > So, I guess my point is that we shouldn't care too much about annoying > gnome-keyring dialogs at this point. Not that it doesn't matter, cause > it does, however all that work is elsewhere really. Nod. We can do a lot better, though. Right now we force an unlock on startup because we parse every password. Netapplet, for example, only required an unlock when you actually connected to an password-protected network. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] first pass at gnome-keyring support, baby.
On Wed, 2005-06-22 at 22:20 -0400, Colin Walters wrote: > On Wed, 2005-06-22 at 22:02 -0400, Robert Love wrote: > > Attached patch adds support for gnome-keyring to nm-applet and stores > > the essid key encrypted in the keyring instead of cleartext in gconf. > > > > It is a first pass, but it seems to work well [1]. > > > > One issue is it causes the gnome-keyring "decrypt your keyring" dialog > > to pop up as soon as the applet loads (presuming that your keyring is > > not already decrypted, of course). > > Offtopic, but IMO we should just get rid of that dialog Which requires automatically unlocking the keyring when the user logs in which is non-trivial at best. It's also highly OS/distribution specific. > (and the whole > keyring access control). It is a pretty small barrier versus a > compromised application, confusing to users, and it's also annoying. I concur that the "allow application XYZ to access item ABC" dialog should be removed in gnome-keyring proper (maybe a setting but default to off). Apple does have this one but I really really doubt it is useful at all. However, I'm pretty sure we want someway to control that e.g. a compromised application which is not /usr/libexec/nm-applet cannot read your WEP pass phrases from your keyring, no? So, I guess my point is that we shouldn't care too much about annoying gnome-keyring dialogs at this point. Not that it doesn't matter, cause it does, however all that work is elsewhere really. David ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] first pass at gnome-keyring support, baby.
On Wed, 2005-06-22 at 22:20 -0400, Colin Walters wrote: > Offtopic, but IMO we should just get rid of that dialog (and the whole > keyring access control). It is a pretty small barrier versus a > compromised application, confusing to users, and it's also annoying. I'm not talking about the "Should I let nm-applet access the key? Always/Once/Never" dialog. That pops up, too, but you can select Always. I mean the one-per-session decryption of my keyring, in which I enter the passphrase physically used to perform the decryption. Or do you mean you want to get rid of that? Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] first pass at gnome-keyring support, baby.
On Wed, 2005-06-22 at 22:02 -0400, Robert Love wrote: > Attached patch adds support for gnome-keyring to nm-applet and stores > the essid key encrypted in the keyring instead of cleartext in gconf. > > It is a first pass, but it seems to work well [1]. > > One issue is it causes the gnome-keyring "decrypt your keyring" dialog > to pop up as soon as the applet loads (presuming that your keyring is > not already decrypted, of course). Offtopic, but IMO we should just get rid of that dialog (and the whole keyring access control). It is a pretty small barrier versus a compromised application, confusing to users, and it's also annoying. signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] first pass at gnome-keyring support, baby.
On Wed, 22 Jun 2005, Robert Love wrote: > Attached patch adds support for gnome-keyring to nm-applet and stores > the essid key encrypted in the keyring instead of cleartext in gconf. > > It is a first pass, but it seems to work well [1]. > > One issue is it causes the gnome-keyring "decrypt your keyring" dialog > to pop up as soon as the applet loads (presuming that your keyring is > not already decrypted, of course). It seems as if the information > (including the keys) is read for each wireless network on startup? > Maybe we could change that, or defer reading the key until it is > absolutely needed. Or only read the key if the auth_method specifies > such. Quite right. At this time NM queries nm-applet for all networks when it gets the NameOwnerChanged. What you propose sounds reasonable. We don't really _need_ the key until we try to connect to the access point. > > Thoughts? Comments? > > Robert Love > > [1] Actually, it seems to work perfect. But I am having a lot of > problems with NetworkManager and encrypted essids (or maybe just > switching between lots of essids in general) and my airo wireless card. > Sometimes the daemon just starts sitting there. Sometimes it stops > scanning. In either case, it won't exit. Quick debugging shows it is > spinning on a mutex. Although I've also seen evidence it is waiting for > something from the card. It is confusing to the point of tears. I'll > debug it later. I should add that, ahem, Netapplet works fine with my > card. ;-) Ok, can I get some backtraces here for all threads? Also, is the airo card borked? ie, lots of messages in /var/log/messages about "command timed out". There are a number of historical problems with airo cards, including but not limited to: 1) Card screws up and gets hung, driver can't talk to card because commands time out, can't unload airo.ko because no data can be sent (card's hung) and therefore the module refcount isn't decreased 2) Doesn't work with firmwares > 5.20.17 and WEP 3) Card doesn't return non-broadcasting ESSIDs from scans Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[patch] first pass at gnome-keyring support, baby.
Attached patch adds support for gnome-keyring to nm-applet and stores
the essid key encrypted in the keyring instead of cleartext in gconf.
It is a first pass, but it seems to work well [1].
One issue is it causes the gnome-keyring "decrypt your keyring" dialog
to pop up as soon as the applet loads (presuming that your keyring is
not already decrypted, of course). It seems as if the information
(including the keys) is read for each wireless network on startup?
Maybe we could change that, or defer reading the key until it is
absolutely needed. Or only read the key if the auth_method specifies
such.
Thoughts? Comments?
Robert Love
[1] Actually, it seems to work perfect. But I am having a lot of
problems with NetworkManager and encrypted essids (or maybe just
switching between lots of essids in general) and my airo wireless card.
Sometimes the daemon just starts sitting there. Sometimes it stops
scanning. In either case, it won't exit. Quick debugging shows it is
spinning on a mutex. Although I've also seen evidence it is waiting for
something from the card. It is confusing to the point of tears. I'll
debug it later. I should add that, ahem, Netapplet works fine with my
card. ;-)
Index: configure.in
===
RCS file: /cvs/gnome/NetworkManager/configure.in,v
retrieving revision 1.82
diff -u -u -r1.82 configure.in
--- configure.in 20 Jun 2005 17:16:51 - 1.82
+++ configure.in 23 Jun 2005 01:54:43 -
@@ -177,10 +177,6 @@
AC_SUBST(LIBGNOMEUI_CFLAGS) # is this even needed? it was typed incorrectly before
AC_SUBST(LIBGNOMEUI_LIBS)
-PKG_CHECK_MODULES(GNOMEKEYRING, gnome-keyring-1)
-AC_SUBST(GNOMEKEYRING_CFLAGS) # is this even needed? it was typed incorrectly before
-AC_SUBST(GNOMEKEYRING_LIBS)
-
AC_ARG_WITH(dbus-sys, AC_HELP_STRING([--with-dbus-sys=DIR], [where D-BUS system.d directory is]))
if ! test -z "$with_dbus_sys" ; then
Index: gnome/applet/Makefile.am
===
RCS file: /cvs/gnome/NetworkManager/gnome/applet/Makefile.am,v
retrieving revision 1.5
diff -u -u -r1.5 Makefile.am
--- gnome/applet/Makefile.am 16 Jun 2005 18:47:56 - 1.5
+++ gnome/applet/Makefile.am 23 Jun 2005 01:54:43 -
@@ -16,7 +16,7 @@
$(GCONF_CFLAGS) \
$(LIBGNOMEUI_CFLAGS) \
$(PANEL_APPLET_CFLAGS) \
- $(GNOMEKEYRING_CFLAGS) \
+ $(GNOME_KEYRING_CFLAGS) \
-DICONDIR=\""$(datadir)/pixmaps"\"\
-DGLADEDIR=\""$(gladedir)"\" \
-DBINDIR=\""$(bindir)"\" \
@@ -70,7 +70,7 @@
$(GTK_LIBS) \
$(GCONF_LIBS) \
$(LIBGNOMEUI_LIBS) \
- $(GNOMEKEYRING_LIBS)\
+ $(GNOME_KEYRING_LIBS)\
$(top_builddir)/utils/libnmutils.la \
$(NULL)
Index: gnome/applet/applet-dbus-info.c
===
RCS file: /cvs/gnome/NetworkManager/gnome/applet/applet-dbus-info.c,v
retrieving revision 1.8
diff -u -u -r1.8 applet-dbus-info.c
--- gnome/applet/applet-dbus-info.c 21 Jun 2005 15:07:00 - 1.8
+++ gnome/applet/applet-dbus-info.c 23 Jun 2005 01:54:43 -
@@ -29,6 +29,8 @@
#include
#include
#include
+#include
+
#include "NetworkManager.h"
#include "applet.h"
#include "applet-dbus.h"
@@ -293,13 +295,14 @@
DBusError error;
NMNetworkType type;
char*escaped_network;
-
char*essid = NULL;
gint timestamp = -1;
- gint32i;
+ gint32 i;
char*key = NULL;
NMEncKeyType key_type = -1;
gboolean trusted = FALSE;
+ GList *found_list;
+ GnomeKeyringResult ret;
NMDeviceAuthMethod auth_method = NM_DEVICE_AUTH_METHOD_UNKNOWN;
g_return_val_if_fail (applet != NULL, NULL);
@@ -335,16 +338,21 @@
}
g_free (gconf_key);
- /* Grab user-key key for our access point from GConf */
- gconf_key = g_strdup_printf ("%s/%s/key", GCONF_PATH_WIRELESS_NETWORKS, escaped_network);
- if ((value = gconf_client_get (applet->gconf_client, gconf_key, NULL)))
- {
- key = g_strdup (gconf_value_get_string (value));
- gconf_value_free (value);
+ /* Get the essid key, if any, from the keyring */
+ ret = gnome_keyring_find_itemsv_sync (GNOME_KEYRING_ITEM_GENERIC_SECRET,
+ &found_list,
+ "essid",
+ GNOME_KEYRING_ATTRIBUTE_TYPE_STRING,
+ essid,
+ NULL);
+ if (ret == GNOME_KEYRING_RESULT_OK)
+ {
+ GnomeKeyringFound *found = found_list->data;
+ key = g_strdup (found->secret);
+ gnome_keyring_found_list_free (found_list);
}
else
key = g_strdup ("");
- g_free (gconf_key);
gconf_key = g_strdup_printf ("%s/%s/key_type", GCONF_PATH_WIRELESS_NETWORKS, escaped_network);
if ((value = gconf_client_get (applet->gconf_client, gconf_key, NULL)))
Index: gnome/applet/applet.c
===
RCS file: /cvs/gnome/NetworkManager/gnome/applet/applet.c,v
retrieving revision 1.16
diff -u -u -r1.16 applet.c
--- gnome/applet/applet.c 21 Jun 2005 15:09:34 - 1.16
+++ gnom
