Re: NM 0.6.5 unable to reconnect to WPA2 network (first connection fine) - take 2
Tomáš Hnyk wrote:
So out of interest, what fields do you use in the configuration
dialog? I am using identity, private key file, and private key
password.
Regards,
Jon.
The config windows should look like this:
http://eduroam.fjfi.cvut.cz/images/eduroam_linux2.png
i.e. identity, password and CA Certificate File
Regards,
Tomas
Ok, I'm thinking that the trigger to obtain the password from the
keyring might be the presence of a private key file value in the
gconf
data?
Regards,
Jon.
Attaching a new version of my patch, this checks whether a private key file is
configured for the connection before attempting to read a password from the
keyring. I believe this should suit both of the above 802.1X configuration
types..
Regards,
Jon.
diff -urN NetworkManager-0.6.5.original/nm-applet-0.6.5/src/applet-dbus-info.c NetworkManager-0.6.5/nm-applet-0.6.5/src/applet-dbus-info.c
--- NetworkManager-0.6.5.original/nm-applet-0.6.5/src/applet-dbus-info.c 2007-04-19 19:01:13.0 +0100
+++ NetworkManager-0.6.5/nm-applet-0.6.5/src/applet-dbus-info.c 2007-06-07 12:12:41.0 +0100
@@ -152,6 +152,7 @@
char * temp = NULL;
char * escaped_network;
int we_cipher = -1;
+ char * private_key_file = NULL;
g_return_val_if_fail (applet != NULL, NULL);
g_return_val_if_fail (message != NULL, NULL);
@@ -182,9 +183,14 @@
|| !temp)
new_key = TRUE;
+ nm_gconf_get_string_helper (applet-gconf_client,
+ GCONF_PATH_WIRELESS_NETWORKS,
+ wpa_eap_private_key_file, escaped_network, private_key_file);
+
/* Hack: 802.1x passwords are not stored in the keyring */
if (!new_key
- (we_cipher == NM_AUTH_TYPE_WPA_EAP || we_cipher == NM_AUTH_TYPE_LEAP))
+ ((we_cipher == NM_AUTH_TYPE_WPA_EAP !private_key_file) ||
+ we_cipher == NM_AUTH_TYPE_LEAP))
{
NMGConfWSO *gconf_wso;
gconf_wso = nm_gconf_wso_new_deserialize_gconf (applet-gconf_client,
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM 0.6.5 unable to reconnect to WPA2 network (first connection fine) - take 2
On Thu, 2007-06-07 at 12:42 +0100, Jon Escombe wrote: Tomáš Hnyk wrote: So out of interest, what fields do you use in the configuration dialog? I am using identity, private key file, and private key password. Regards, Jon. The config windows should look like this: http://eduroam.fjfi.cvut.cz/images/eduroam_linux2.png i.e. identity, password and CA Certificate File Regards, Tomas Ok, I'm thinking that the trigger to obtain the password from the keyring might be the presence of a private key file value in the gconf data? Regards, Jon. Attaching a new version of my patch, this checks whether a private key file is configured for the connection before attempting to read a password from the keyring. I believe this should suit both of the above 802.1X configuration types.. Wouldn't this not change the behavior for Tomas? Since his config doesn't show a private key file, it seems like your patch won't change behvior for him. I guess we should get him to test the patch first and see :) In any case, I've committed your fix since it's obviously correct. I added a bit to make sure we free the private_key_file variable since that's actually allocated memory. Dan Regards, Jon. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM 0.6.5 unable to reconnect to WPA2 network (first connection fine) - take 2
- Dan Williams [EMAIL PROTECTED] wrote: Attaching a new version of my patch, this checks whether a private key file is configured for the connection before attempting to read a password from the keyring. I believe this should suit both of the above 802.1X configuration types.. Wouldn't this not change the behavior for Tomas? Since his config doesn't show a private key file, it seems like your patch won't change behvior for him. I guess we should get him to test the patch first and see :) In any case, I've committed your fix since it's obviously correct. I added a bit to make sure we free the private_key_file variable since that's actually allocated memory. Dan Thanks, I believe Tomas is using 6.4, which doesn't work (for him) because it always tries to get a password from the keyring. 6.5 includes a patch to never get a password from the keyring (which I'm assuming would work for Tomas - but breaks the private key password scenario). This *should* now be the best of both worlds ;) Regards, Jon. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM 0.6.5 unable to reconnect to WPA2 network (first connection fine) - take 2
On Thu, 2007-06-07 at 16:08 +0100, Jon Escombe wrote: - Dan Williams [EMAIL PROTECTED] wrote: Attaching a new version of my patch, this checks whether a private key file is configured for the connection before attempting to read a password from the keyring. I believe this should suit both of the above 802.1X configuration types.. Wouldn't this not change the behavior for Tomas? Since his config doesn't show a private key file, it seems like your patch won't change behvior for him. I guess we should get him to test the patch first and see :) In any case, I've committed your fix since it's obviously correct. I added a bit to make sure we free the private_key_file variable since that's actually allocated memory. Dan Thanks, I believe Tomas is using 6.4, which doesn't work (for him) because it always tries to get a password from the keyring. 6.5 includes a patch to never get a password from the keyring (which I'm assuming would work for Tomas - but breaks the private key password scenario). This *should* now be the best of both worlds ;) Ah, ok. Can you test out latest SVN for 0.6.x and confirm that I didn't break anything when modifying your patch? Thanks, Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM 0.6.5 unable to reconnect to WPA2 network (first connection fine) - take 2
- Dan Williams [EMAIL PROTECTED] wrote: I believe Tomas is using 6.4, which doesn't work (for him) because it always tries to get a password from the keyring. 6.5 includes a patch to never get a password from the keyring (which I'm assuming would work for Tomas - but breaks the private key password scenario). This *should* now be the best of both worlds ;) Ah, ok. Can you test out latest SVN for 0.6.x and confirm that I didn't break anything when modifying your patch? Thanks, Dan Yep, the patch from SVN works fine here, thanks. Any thoughts on applying the device-link-race patch to 0.6.x? Regards, Jon. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM 0.6.5 unable to reconnect to WPA2 network (first connection fine) - take 2
On Thu, 2007-06-07 at 16:42 +0100, Jon Escombe wrote:
- Dan Williams [EMAIL PROTECTED] wrote:
I believe Tomas is using 6.4, which doesn't work (for him) because
it always tries to get a password from the keyring. 6.5 includes a
patch to never get a password from the keyring (which I'm assuming
would work for Tomas - but breaks the private key password scenario).
This *should* now be the best of both worlds ;)
Ah, ok. Can you test out latest SVN for 0.6.x and confirm that I didn't
break anything when modifying your patch?
Thanks,
Dan
Yep, the patch from SVN works fine here, thanks.
Any thoughts on applying the device-link-race patch to 0.6.x?
Working on that now; I'd rather figure out why nm_device_is_up doesn't
return the correct value though... In any case, it's also better to
move the sleep(1) to real_act_stage2_config() in
nm-device-802-11-wireless.c after the ap_need_key() call since only
wireless devices appear to need this. Can you try the attached patch
and see if that works for you _instead_ of device-link-race.patch?
Dan
Index: src/nm-device-802-11-wireless.c
===
--- src/nm-device-802-11-wireless.c (revision 2577)
+++ src/nm-device-802-11-wireless.c (working copy)
@@ -2981,6 +2981,9 @@
return NM_ACT_STAGE_RETURN_POSTPONE;
}
+ /* Some cards are dumb. Wait a second */
+ sleep (1);
+
iface = nm_device_get_iface (dev);
if (!supplicant_exec (self))
{
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
NetworkManager static-routes support patch
Hi,
i wrote patch for NetworkManager for support static-routes from DHCP
(033).
With regards
Blondak
diff -ru NetworkManager-0.6.5/src/dhcp-manager/nm-dhcp-manager.c NetworkManager-0.6.5-blondak/src/dhcp-manager/nm-dhcp-manager.c
--- NetworkManager-0.6.5/src/dhcp-manager/nm-dhcp-manager.c 2007-04-18 20:13:04.0 +0200
+++ NetworkManager-0.6.5-blondak/src/dhcp-manager/nm-dhcp-manager.c 2007-06-07 14:48:43.0 +0200
@@ -468,13 +468,17 @@
guint32 * ip4_broadcast = NULL;
guint32 * ip4_nameservers = NULL;
guint32 * ip4_gateway = NULL;
+ guint32 num_ip4_static_routes = 0;
guint32 num_ip4_nameservers = 0;
guint32 num_ip4_nis_servers = 0;
char * hostname = NULL;
char * domain_names = NULL;
char * nis_domain = NULL;
guint32 * ip4_nis_servers = NULL;
+ guint32 * ip4_static_routes = NULL;
+ char * test = NULL;
struct in_addr temp_addr;
+ struct NMIP4Route * temp_route;
nm_completion_args args;
g_return_val_if_fail (manager != NULL, NULL);
@@ -520,6 +524,7 @@
get_ip4_string (manager, dev, domain_name, domain_names, TRUE);
get_ip4_string (manager, dev, nis_domain, nis_domain, TRUE);
get_ip4_uint32s (manager, dev, nis_servers, ip4_nis_servers, num_ip4_nis_servers, TRUE);
+ get_ip4_uint32s (manager, dev, static_routes, ip4_static_routes, num_ip4_static_routes, TRUE);
nm_info (Retrieved the following IP4 configuration from the DHCP daemon:);
@@ -579,6 +584,16 @@
nm_info ( nis server %s, inet_ntoa (temp_addr));
}
+ for (i = 0; i num_ip4_static_routes / 2;i++)
+ {
+ temp_route = g_malloc0 (sizeof (NMIP4Route));
+ (*temp_route).host.s_addr = ip4_static_routes[(i*2)];
+ (*temp_route).gw.s_addr = ip4_static_routes[((i*2)+1)];
+ (*temp_route).mask.s_addr = 0x0;
+ nm_ip4_config_add_static_route (ip4_config, temp_route);
+ nm_info ( static route %s gw %s, inet_ntoa((*temp_route).host), inet_ntoa((*temp_route).gw));
+ }
+
/*
* Grab the MTU from the backend. If DHCP servers can send recommended MTU's,
* should set that here if the backend returns zero.
diff -ru NetworkManager-0.6.5/src/NetworkManagerSystem.c NetworkManager-0.6.5-blondak/src/NetworkManagerSystem.c
--- NetworkManager-0.6.5/src/NetworkManagerSystem.c 2007-04-18 20:13:06.0 +0200
+++ NetworkManager-0.6.5-blondak/src/NetworkManagerSystem.c 2007-06-07 13:42:41.0 +0200
@@ -294,6 +294,8 @@
struct nl_handle * nlh = NULL;
struct rtnl_addr * addr = NULL;
interr;
+ int i,len;
+ struct NMIP4Route * static_route;
g_return_val_if_fail (dev != NULL, FALSE);
@@ -326,6 +328,14 @@
sleep (1);
nm_system_device_set_ip4_route (dev, nm_ip4_config_get_gateway (config), 0, 0, nm_ip4_config_get_mss (config));
+ len = nm_ip4_config_get_num_static_routes (config);
+ for (i =0; i len; i++)
+ {
+ static_route = nm_ip4_config_get_static_route (config, i);
+ if (static_route != NULL)
+ nm_system_device_set_ip4_route (dev, (*static_route).gw.s_addr, (*static_route).host.s_addr, (*static_route).mask.s_addr, nm_ip4_config_get_mss (config));
+ }
+
nm_named_manager_add_ip4_config (app_data-named_manager, config);
return TRUE;
diff -ru NetworkManager-0.6.5/src/nm-ip4-config.c NetworkManager-0.6.5-blondak/src/nm-ip4-config.c
--- NetworkManager-0.6.5/src/nm-ip4-config.c 2007-04-18 20:13:06.0 +0200
+++ NetworkManager-0.6.5-blondak/src/nm-ip4-config.c 2007-06-07 13:41:12.0 +0200
@@ -50,6 +50,7 @@
gchar * hostname;
gchar * nis_domain;
GSList * nis_servers;
+ GSList * static_routes;
/* If this is a VPN/etc config that requires
* another device (like Ethernet) to already have
@@ -99,6 +100,10 @@
for (i = 0; i len; i++)
nm_ip4_config_add_nis_server (dst_config, nm_ip4_config_get_nis_server (src_config, i));
+ len = nm_ip4_config_get_num_static_routes (src_config);
+ for (i =0; i len; i++)
+ nm_ip4_config_add_static_route (dst_config, nm_ip4_config_get_static_route (src_config, i));
+
return dst_config;
}
@@ -264,6 +269,33 @@
return (g_slist_length (config-nis_servers));
}
+void nm_ip4_config_add_static_route (NMIP4Config *config, NMIP4Route *static_route)
+{
+g_return_if_fail ( config != NULL);
+g_return_if_fail ( static_route != NULL);
+
+config-static_routes = g_slist_append (config-static_routes, static_route );
+}
+
+NMIP4Route * nm_ip4_config_get_static_route (NMIP4Config *config, guint32 i)
+{
+NMIP4Route* static_route;
+
+g_return_val_if_fail (config != NULL, NULL);
+g_return_val_if_fail (i g_slist_length (config-static_routes), NULL);
+
+static_route = g_slist_nth_data (config-static_routes,i);
+
+return static_route;
+}
+
+guint32 nm_ip4_config_get_num_static_routes (NMIP4Config *config)
+{
+g_return_val_if_fail (config != NULL, 0);
+
+return (g_slist_length (config-static_routes));
+}
+
void nm_ip4_config_add_domain (NMIP4Config *config, const char *domain)
{
g_return_if_fail (config != NULL);
diff -ru
Re: NM 0.6.5 unable to reconnect to WPA2 network (first connection fine) - take 2
On Thu, 2007-06-07 at 12:08 -0400, Dan Williams wrote: On Thu, 2007-06-07 at 16:42 +0100, Jon Escombe wrote: - Dan Williams [EMAIL PROTECTED] wrote: I believe Tomas is using 6.4, which doesn't work (for him) because it always tries to get a password from the keyring. 6.5 includes a patch to never get a password from the keyring (which I'm assuming would work for Tomas - but breaks the private key password scenario). This *should* now be the best of both worlds ;) Ah, ok. Can you test out latest SVN for 0.6.x and confirm that I didn't break anything when modifying your patch? Thanks, Dan Yep, the patch from SVN works fine here, thanks. Any thoughts on applying the device-link-race patch to 0.6.x? Working on that now; I'd rather figure out why nm_device_is_up doesn't return the correct value though... In any case, it's also better to move the sleep(1) to real_act_stage2_config() in nm-device-802-11-wireless.c after the ap_need_key() call since only wireless devices appear to need this. Can you try the attached patch and see if that works for you _instead_ of device-link-race.patch? Dan, your patch works for me. I have also found that this problem exists on a couple of mac80211 stack drivers, as well as my prism54 fullmac card. Jon ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager static-routes support patch
On Thu, 2007-06-07 at 15:12 +0200, Blonďák wrote: Hi, i wrote patch for NetworkManager for support static-routes from DHCP (033). Nice! A few comments... - instead of doing (*temp_route).host, just use temp_route-host. That shows up in a few places. - do static routes -always- have a netmask of 0x? - I'd prefer to have the nm_ip4_config_add_static_route() function _copy_ the NMIP4Route structure and append it to the list. The NMIP4Config should also free any NMIP4Route structures that it has references to when it is destroyed. Once you've done this don't forget to free the malloc-ed NMIP4Route structure too. Also please check for a NULL return value after the malloc and print out a warning and break out of the for() loop. Should also check for NULL return from the g_malloc0 when you add that to nm_ip4_config_add_static_route and return. - There are some spaces after the ( in nm_ip4_config_add_static_route(): +g_return_if_fail ( config != NULL); Thanks! Dan With regards Blondak ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager static-routes support patch
On Thu, 2007-06-07 at 13:13 -0400, Derek Atkins wrote: Quoting Dan Williams [EMAIL PROTECTED]: On Thu, 2007-06-07 at 15:12 +0200, Blonďák wrote: Hi, i wrote patch for NetworkManager for support static-routes from DHCP (033). Nice! A few comments... - instead of doing (*temp_route).host, just use temp_route-host. That shows up in a few places. - do static routes -always- have a netmask of 0x? -host routes do. -net routes do not. So would the patch need to do additional checking for the routes returned by the DHCP server to determine whether the last bit is 0 or something? If so, what netmask would be used instead? Dan -derek ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM 0.6.5 unable to reconnect to WPA2 network (first connection fine) - take 2
On Thu, 2007-06-07 at 12:37 -0400, Jon Nettleton wrote: On Thu, 2007-06-07 at 12:08 -0400, Dan Williams wrote: On Thu, 2007-06-07 at 16:42 +0100, Jon Escombe wrote: - Dan Williams [EMAIL PROTECTED] wrote: I believe Tomas is using 6.4, which doesn't work (for him) because it always tries to get a password from the keyring. 6.5 includes a patch to never get a password from the keyring (which I'm assuming would work for Tomas - but breaks the private key password scenario). This *should* now be the best of both worlds ;) Ah, ok. Can you test out latest SVN for 0.6.x and confirm that I didn't break anything when modifying your patch? Thanks, Dan Yep, the patch from SVN works fine here, thanks. Any thoughts on applying the device-link-race patch to 0.6.x? Working on that now; I'd rather figure out why nm_device_is_up doesn't return the correct value though... In any case, it's also better to move the sleep(1) to real_act_stage2_config() in nm-device-802-11-wireless.c after the ap_need_key() call since only wireless devices appear to need this. Can you try the attached patch and see if that works for you _instead_ of device-link-race.patch? Dan, your patch works for me. I have also found that this problem exists on a couple of mac80211 stack drivers, as well as my prism54 fullmac card. I just tried running a quick test program on 2.6.20 with prism54 with inconclusive results... It just runs system(/sbin/ip link set dev eth1 [up/down]) and then uses the nm_device_is_up() function to print out status. Seems to work OK there. Grr. dev-link-wait.patch committed in revision 2579 just because. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager static-routes support patch
Quoting Dan Williams [EMAIL PROTECTED]: - do static routes -always- have a netmask of 0x? -host routes do. -net routes do not. So would the patch need to do additional checking for the routes returned by the DHCP server to determine whether the last bit is 0 or something? If so, what netmask would be used instead? I'm afraid I didn't look at the patch, but how does a static route have anything to do with DHCP? (Maybe I'd understand if I looked at the patch).. Generally when I think of static routes I think I know how to get to host X or net Y/Z -- so if it's a static host route I only need to know the host address, and if it's a static network route I need the network and netmask. These numbers would need to be part of the static route configuration. Dan -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager static-routes support patch
On Thu, 2007-06-07 at 13:23 -0400, Derek Atkins wrote: Quoting Dan Williams [EMAIL PROTECTED]: - do static routes -always- have a netmask of 0x? -host routes do. -net routes do not. So would the patch need to do additional checking for the routes returned by the DHCP server to determine whether the last bit is 0 or something? If so, what netmask would be used instead? I'm afraid I didn't look at the patch, but how does a static route have anything to do with DHCP? (Maybe I'd understand if I looked The DHCP server can push static routes out the client just like it can push DNS servers or YP servers, I think. Dan at the patch).. Generally when I think of static routes I think I know how to get to host X or net Y/Z -- so if it's a static host route I only need to know the host address, and if it's a static network route I need the network and netmask. These numbers would need to be part of the static route configuration. Dan -derek ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
NM insists on connecting to a non-existent wired connection.
Hi All, I am seeing a very strange behavior on my Dell D810 laptop. Everytime I start up the system, NM chooses to connect to a non-existent wired network. I see the following in the log files: Jun 8 00:53:17 Xymnotune NetworkManager: info starting... Jun 8 00:53:17 Xymnotune NetworkManager: info eth1: Device is fully-supported using driver 'ipw2200'. Jun 8 00:53:17 Xymnotune NetworkManager: info nm_device_init(): waiting for device's worker thread to start Jun 8 00:53:18 Xymnotune NetworkManager: info nm_device_init(): device's worker thread started, continuing. Jun 8 00:53:18 Xymnotune NetworkManager: info Now managing wireless (802.11) device 'eth1'. Jun 8 00:53:18 Xymnotune NetworkManager: info Deactivating device eth1. Jun 8 00:53:18 Xymnotune kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready Jun 8 00:53:18 Xymnotune NetworkManager: info eth0: Device is fully-supported using driver 'tg3'. Jun 8 00:53:18 Xymnotune NetworkManager: info nm_device_init(): waiting for device's worker thread to start Jun 8 00:53:18 Xymnotune NetworkManager: info nm_device_init(): device's worker thread started, continuing. Jun 8 00:53:18 Xymnotune NetworkManager: info Now managing wired Ethernet (802.3) device 'eth0'. Jun 8 00:53:18 Xymnotune NetworkManager: info Deactivating device eth0. Jun 8 00:53:18 Xymnotune NetworkManager: info Will activate wired connection 'eth0' because it now has a link. Jun 8 00:53:18 Xymnotune NetworkManager: info SWITCH: no current connection, found better connection 'eth0'. Jun 8 00:53:18 Xymnotune dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth0 for sub-path eth0.dbus.get.reason Jun 8 00:53:18 Xymnotune NetworkManager: info Will activate connection 'eth0'. Jun 8 00:53:18 Xymnotune NetworkManager: info Device eth0 activation scheduled... Jun 8 00:53:18 Xymnotune NetworkManager: info Activation (eth0) started... This has started occurring after I installed Fedora 7 on my laptop. Now I am wondering if this is a Fedora bug of a NM bug. Any pointers on how to fix this issue are welcome. thanks, Rogue Fedora 7 / NM Applet 0.6.5 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM insists on connecting to a non-existent wired connection.
On Fri, 2007-06-08 at 01:16 +0530, Rogue wrote: Hi All, I am seeing a very strange behavior on my Dell D810 laptop. Everytime I start up the system, NM chooses to connect to a non-existent wired network. I see the following in the log files: Jun 8 00:53:17 Xymnotune NetworkManager: info starting... Jun 8 00:53:17 Xymnotune NetworkManager: info eth1: Device is fully-supported using driver 'ipw2200'. Jun 8 00:53:17 Xymnotune NetworkManager: info nm_device_init(): waiting for device's worker thread to start Jun 8 00:53:18 Xymnotune NetworkManager: info nm_device_init(): device's worker thread started, continuing. Jun 8 00:53:18 Xymnotune NetworkManager: info Now managing wireless (802.11) device 'eth1'. Jun 8 00:53:18 Xymnotune NetworkManager: info Deactivating device eth1. Jun 8 00:53:18 Xymnotune kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready Jun 8 00:53:18 Xymnotune NetworkManager: info eth0: Device is fully-supported using driver 'tg3'. Jun 8 00:53:18 Xymnotune NetworkManager: info nm_device_init(): waiting for device's worker thread to start Jun 8 00:53:18 Xymnotune NetworkManager: info nm_device_init(): device's worker thread started, continuing. Jun 8 00:53:18 Xymnotune NetworkManager: info Now managing wired Ethernet (802.3) device 'eth0'. Jun 8 00:53:18 Xymnotune NetworkManager: info Deactivating device eth0. Jun 8 00:53:18 Xymnotune NetworkManager: info Will activate wired connection 'eth0' because it now has a link. Jun 8 00:53:18 Xymnotune NetworkManager: info SWITCH: no current connection, found better connection 'eth0'. Jun 8 00:53:18 Xymnotune dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth0 for sub-path eth0.dbus.get.reason Jun 8 00:53:18 Xymnotune NetworkManager: info Will activate connection 'eth0'. Jun 8 00:53:18 Xymnotune NetworkManager: info Device eth0 activation scheduled... Jun 8 00:53:18 Xymnotune NetworkManager: info Activation (eth0) started... This has started occurring after I installed Fedora 7 on my laptop. Now I am wondering if this is a Fedora bug of a NM bug. Any pointers on how to fix this issue are welcome. It's been fixed in SVN and built as an NM update for F7. See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194124 Should hit the mirrors in the next few days. Out of curiosity though, what does /sbin/lspci say? Dan thanks, Rogue Fedora 7 / NM Applet 0.6.5 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Question regarding Madwifi signal strength
I was considering a new Macbook Pro but the madwifi signal strength issue causes problems for me and while Robert's patch for NM helps the connection strength is still reported less than an Intel card at the same location. So I was looking on the Madwifi page to see if there had ever been any proposed patches to the madwifi code that resolve the issue but were never checked into the core when I found this page: http://madwifi.org/wiki/UserDocs/RSSI It says: As of MadWiFi version 0.9.3, the noise floor is no longer assumed to be a constant -95 dBm. The noise floor is now updated on each receive interrupt by calling out to the HAL, which returns the absolute noise level in dBm. However, because each interrupt can service several packets we cannot get a noise reading for each and every packet. MadWiFi simply takes the measured noise level at each interrupt and assumes all packets serviced during the interrupt were received with this noise level. The measured noise is not used during scanning at present, so all scan results return with a noise level of -95 dBm. Do the above changes seem like they resolved these issues or maybe not affect it at all? I can dig out my atheros card (it's in the attic!) and find out if nobody knows but I figured it would save me the hassle of climbing up there if someone already has checked. Thanks! ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM insists on connecting to a non-existent wired connection.
Rogue wrote: Hi All, I am seeing a very strange behavior on my Dell D810 laptop. Everytime I start up the system, NM chooses to connect to a non-existent wired network. I see the following in the log files: FWIW I experience the same bug. I have my ethernet nic on eth0 (8139cp) and the wireless nic on wlan0 (ipw2100). On startup NM always tries to establish a connection via eth0 although no cable is plugged in (and it receives a LL IP address via avahi-autoipd, so the actual connection via wlan0 is not established because NM thinks it has a connection). The problem seems to be, that NM does not correctly init the eth0 device and so mistakenly thinks it has a link. cat /sys/devices/pci:00/:00:1e.0/:02:01.0/net/eth0/carrier yields: Invalid argument directly after loading the module. If I run ip link set eth0 up the above correctly returns 0 for carrier. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM insists on connecting to a non-existent wired connection.
Dan Williams wrote: On Fri, 2007-06-08 at 01:16 +0530, Rogue wrote: Hi All, I am seeing a very strange behavior on my Dell D810 laptop. Everytime I start up the system, NM chooses to connect to a non-existent wired network. I see the following in the log files: Jun 8 00:53:17 Xymnotune NetworkManager: info starting... Jun 8 00:53:17 Xymnotune NetworkManager: info eth1: Device is fully-supported using driver 'ipw2200'. Jun 8 00:53:17 Xymnotune NetworkManager: info nm_device_init(): waiting for device's worker thread to start Jun 8 00:53:18 Xymnotune NetworkManager: info nm_device_init(): device's worker thread started, continuing. Jun 8 00:53:18 Xymnotune NetworkManager: info Now managing wireless (802.11) device 'eth1'. Jun 8 00:53:18 Xymnotune NetworkManager: info Deactivating device eth1. Jun 8 00:53:18 Xymnotune kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready Jun 8 00:53:18 Xymnotune NetworkManager: info eth0: Device is fully-supported using driver 'tg3'. Jun 8 00:53:18 Xymnotune NetworkManager: info nm_device_init(): waiting for device's worker thread to start Jun 8 00:53:18 Xymnotune NetworkManager: info nm_device_init(): device's worker thread started, continuing. Jun 8 00:53:18 Xymnotune NetworkManager: info Now managing wired Ethernet (802.3) device 'eth0'. Jun 8 00:53:18 Xymnotune NetworkManager: info Deactivating device eth0. Jun 8 00:53:18 Xymnotune NetworkManager: info Will activate wired connection 'eth0' because it now has a link. Jun 8 00:53:18 Xymnotune NetworkManager: info SWITCH: no current connection, found better connection 'eth0'. Jun 8 00:53:18 Xymnotune dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth0 for sub-path eth0.dbus.get.reason Jun 8 00:53:18 Xymnotune NetworkManager: info Will activate connection 'eth0'. Jun 8 00:53:18 Xymnotune NetworkManager: info Device eth0 activation scheduled... Jun 8 00:53:18 Xymnotune NetworkManager: info Activation (eth0) started... This has started occurring after I installed Fedora 7 on my laptop. Now I am wondering if this is a Fedora bug of a NM bug. Any pointers on how to fix this issue are welcome. It's been fixed in SVN and built as an NM update for F7. See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194124 Should hit the mirrors in the next few days. Out of curiosity though, what does /sbin/lspci say? Dan Hi Dan, First up, glad to hear that this issue has been fixed and pushed. Secondly to satiate your curiosity, lspci on my machine gives the following information: 00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 03) 00:01.0 PCI bridge: Intel Corporation Mobile 915GM/PM Express PCI Express Root Port (rev 03) 00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03) 00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03) 00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03) 00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 03) 00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d3) 00:1e.2 Multimedia audio controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 03) 00:1e.3 Modem: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Modem Controller (rev 03) 00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge (rev 03) 00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 03) 01:00.0 VGA compatible controller: ATI Technologies Inc M22 [Mobility Radeon X300] 02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5751 Gigabit Ethernet PCI Express (rev 01) 03:01.0 CardBus bridge: Texas Instruments PCI6515 Cardbus Controller 03:01.5 Communication controller: Texas Instruments PCI6515 SmartCard Controller 03:03.0 Network controller: Intel Corporation PRO/Wireless 2200BG Network Connection (rev 05) hope that info helps you... Another bit of info, earlier I used to download the ipw2200 driver separately, but this time I noticed that NM was picking up my device well and nice, so I did not install that driver. Do you think that could be an issue? later, Rogue ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM 0.6.5 unable to reconnect to WPA2 network (first connection fine) - take 2
On Thu, 07 Jun 2007 17:08:41 +0200, Jon Escombe [EMAIL PROTECTED] wrote: - Dan Williams [EMAIL PROTECTED] wrote: Attaching a new version of my patch, this checks whether a private key file is configured for the connection before attempting to read a password from the keyring. I believe this should suit both of the above 802.1X configuration types.. Wouldn't this not change the behavior for Tomas? Since his config doesn't show a private key file, it seems like your patch won't change behvior for him. I guess we should get him to test the patch first and see :) In any case, I've committed your fix since it's obviously correct. I added a bit to make sure we free the private_key_file variable since that's actually allocated memory. Dan Thanks, I believe Tomas is using 6.4, which doesn't work (for him) because it always tries to get a password from the keyring. 6.5 includes a patch to never get a password from the keyring (which I'm assuming would work for Tomas - but breaks the private key password scenario). This *should* now be the best of both worlds ;) Regards, Jon. I think you are right, I was about to test the former patch (the one that you linked to) but I screwed something up and now netwrok manager wont come up at all. As soon as I somehow fix this I will try your latest patch. Tomas ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM insists on connecting to a non-existent wired connection.
On Thu, 2007-06-07 at 22:42 +0200, Michael Biebl wrote: Rogue wrote: Hi All, I am seeing a very strange behavior on my Dell D810 laptop. Everytime I start up the system, NM chooses to connect to a non-existent wired network. I see the following in the log files: FWIW I experience the same bug. I have my ethernet nic on eth0 (8139cp) and the wireless nic on wlan0 (ipw2100). On startup NM always tries to establish a connection via eth0 although no cable is plugged in (and it receives a LL IP address via avahi-autoipd, so the actual connection via wlan0 is not established because NM thinks it has a connection). The problem seems to be, that NM does not correctly init the eth0 device and so mistakenly thinks it has a link. cat /sys/devices/pci:00/:00:1e.0/:02:01.0/net/eth0/carrier yields: Invalid argument directly after loading the module. Hmm, are you using 0.6.4? 0.6.5 relies on netlink exclusively for asynchronous carrier detection and only checks /sys/class/net/ethX/carrier after a successful activation. Do you have a /sys/class/net/eth0/carrier? Does what's in SVN head for NETWORKMANAGER_0_6_0_RELEASE work for you? Dan If I run ip link set eth0 up the above correctly returns 0 for carrier. Cheers, Michael ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
OpenVPN plugin and resolv.conf
When I establish an OpenVPN connection, my resolv.conf file is overwritten by NM. It would be very useful an option to *append* the VPN-side nameserver to the list of pre-existent nameservers! Bye, G.L. -- www.aldu.net/~heruan [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: OpenVPN plugin and resolv.conf
On Fri, 08 Jun 2007 00:20:03 +0200, Giovanni Lovato [EMAIL PROTECTED] wrote: When I establish an OpenVPN connection, my resolv.conf file is overwritten by NM. It would be very useful an option to *append* the VPN-side nameserver to the list of pre-existent nameservers! Bye, G.L. Hello, Look here for a solution (there is a patch attached): https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/96260 Regards, Tomas P.S.:Has this patch been forwarded to NetworkManager? If not, could someone please have a look at it. It worked at least for two people in that link (including me) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
