Re: No more IPv4 address after boot up since NM 0.9.10
On Wed, 04 Mar 2015 18:15:43 +0100 Frederik Himpe frede...@frehi.be wrote: I still think that NM's behaviour not to touch the interface when it's up already is counter-intuitive. If I start up NM with a configuration for eth0, then I _do_ want this configuration to be applied, just like the distro specific init networking scripts would do. If you don't want NM to touch an existing interface, then it makes more sense to me to completely disable NM, or to set this specific interface unmanaged in NM. Maybe this behaviour should be configurable? I am affected by exactly the same problem, and I completely agree with Frederik. Some improvement here would be highly appreciated. Regards Harri signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [review] backport th/uuid-duplicate-rh1171751 to nm-1-0
On Thu, 2015-03-05 at 12:36 +0100, Thomas Haller wrote: Hi all, master has commit commit 29eb46b126f111a68ae811aa69603f47b3a90c7a Author: Thomas Haller thal...@redhat.com Date: Tue Jan 13 16:58:24 2015 settings: merge branch 'th/uuid-duplicate-rh1171751' https://bugzilla.redhat.com/show_bug.cgi?id=1171751 I didn't backport it to nm-1-0 yet, because I wasn't entirely confident that it wouldn't cause problems. I didn't see any problems until now, but I think it has valuable improvements to logging and fixes a bug. I'd like to backport it to nm-1-0 branch. backported as http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=4da3c8e1fad54afd7b18d3565a66fec4c5fd134f Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: No more IPv4 address after boot up since NM 0.9.10
On Thu, 2015-03-12 at 10:32 +0100, Harald Dunkel wrote: On Wed, 04 Mar 2015 18:15:43 +0100 Frederik Himpe frede...@frehi.be wrote: I still think that NM's behaviour not to touch the interface when it's up already is counter-intuitive. If I start up NM with a configuration for eth0, then I _do_ want this configuration to be applied, just like the distro specific init networking scripts would do. If you don't want NM to touch an existing interface, then it makes more sense to me to completely disable NM, or to set this specific interface unmanaged in NM. Maybe this behaviour should be configurable? I am affected by exactly the same problem, and I completely agree with Frederik. Some improvement here would be highly appreciated. ok, but what is the concrete suggestion? How about adding a autoconnect-boot argument to a connection. When NM starts and an interface is unconfigured it would do the usual autoconnect behavior. If the interface is already configured, during startup only, NetworkManager would consider (autoconnect==TRUE autoconnect-boot==TRUE) connections and forcefully activate them. I remember some discussion about supporting splitting the meaning of autoconnect into a autoconnect and on-boot. I am unable to find the bug/email now (CC Pavel). Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: No more IPv4 address after boot up since NM 0.9.10
- Original Message - From: Thomas Haller thal...@redhat.com To: Harald Dunkel harald.dun...@aixigo.de Cc: networkmanager. networkmanager-list@gnome.org, Pavel Simerda psime...@redhat.com Sent: Thursday, March 12, 2015 11:54:49 AM Subject: Re: No more IPv4 address after boot up since NM 0.9.10 On Thu, 2015-03-12 at 10:32 +0100, Harald Dunkel wrote: On Wed, 04 Mar 2015 18:15:43 +0100 Frederik Himpe frede...@frehi.be wrote: I still think that NM's behaviour not to touch the interface when it's up already is counter-intuitive. If I start up NM with a configuration for eth0, then I _do_ want this configuration to be applied, just like the distro specific init networking scripts would do. If you don't want NM to touch an existing interface, then it makes more sense to me to completely disable NM, or to set this specific interface unmanaged in NM. Maybe this behaviour should be configurable? I am affected by exactly the same problem, and I completely agree with Frederik. Some improvement here would be highly appreciated. ok, but what is the concrete suggestion? How about adding a autoconnect-boot argument to a connection. What about my original suggestion of onboot as a separate option from auto[1] plus a new behavior that onboot connections would be enforced even if the device is already configured? [1] https://bugzilla.gnome.org/show_bug.cgi?id=700651 That would IMO make sense and would solve other issues like auto connections blocking the boot process when not desired. Ah, I see you mentioned it down in the e-mail. Chees, Pavel When NM starts and an interface is unconfigured it would do the usual autoconnect behavior. If the interface is already configured, during startup only, NetworkManager would consider (autoconnect==TRUE autoconnect-boot==TRUE) connections and forcefully activate them. I remember some discussion about supporting splitting the meaning of autoconnect into a autoconnect and on-boot. I am unable to find the bug/email now (CC Pavel). Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: No more IPv4 address after boot up since NM 0.9.10
On Thu, 2015-03-12 at 07:32 -0400, Pavel Simerda wrote: - Original Message - From: Thomas Haller thal...@redhat.com To: Harald Dunkel harald.dun...@aixigo.de Cc: networkmanager. networkmanager-list@gnome.org, Pavel Simerda psime...@redhat.com Sent: Thursday, March 12, 2015 11:54:49 AM Subject: Re: No more IPv4 address after boot up since NM 0.9.10 On Thu, 2015-03-12 at 10:32 +0100, Harald Dunkel wrote: On Wed, 04 Mar 2015 18:15:43 +0100 Frederik Himpe frede...@frehi.be wrote: I still think that NM's behaviour not to touch the interface when it's up already is counter-intuitive. If I start up NM with a configuration for eth0, then I _do_ want this configuration to be applied, just like the distro specific init networking scripts would do. If you don't want NM to touch an existing interface, then it makes more sense to me to completely disable NM, or to set this specific interface unmanaged in NM. Maybe this behaviour should be configurable? I am affected by exactly the same problem, and I completely agree with Frederik. Some improvement here would be highly appreciated. ok, but what is the concrete suggestion? How about adding a autoconnect-boot argument to a connection. What about my original suggestion of onboot as a separate option from auto[1] plus a new behavior that onboot connections would be enforced even if the device is already configured? [1] https://bugzilla.gnome.org/show_bug.cgi?id=700651 ah right. that was it. I reopened the bug and linked to this thread. Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: No more IPv4 address after boot up since NM 0.9.10
On Thu, 2015-03-12 at 13:30 +0100, Thomas Haller wrote: On Thu, 2015-03-12 at 07:32 -0400, Pavel Simerda wrote: - Original Message - From: Thomas Haller thal...@redhat.com To: Harald Dunkel harald.dun...@aixigo.de Cc: networkmanager. networkmanager-list@gnome.org, Pavel Simerda psime...@redhat.com Sent: Thursday, March 12, 2015 11:54:49 AM Subject: Re: No more IPv4 address after boot up since NM 0.9.10 On Thu, 2015-03-12 at 10:32 +0100, Harald Dunkel wrote: On Wed, 04 Mar 2015 18:15:43 +0100 Frederik Himpe frede...@frehi.be wrote: I still think that NM's behaviour not to touch the interface when it's up already is counter-intuitive. If I start up NM with a configuration for eth0, then I _do_ want this configuration to be applied, just like the distro specific init networking scripts would do. If you don't want NM to touch an existing interface, then it makes more sense to me to completely disable NM, or to set this specific interface unmanaged in NM. Maybe this behaviour should be configurable? I am affected by exactly the same problem, and I completely agree with Frederik. Some improvement here would be highly appreciated. ok, but what is the concrete suggestion? How about adding a autoconnect-boot argument to a connection. What about my original suggestion of onboot as a separate option from auto[1] plus a new behavior that onboot connections would be enforced even if the device is already configured? [1] https://bugzilla.gnome.org/show_bug.cgi?id=700651 ah right. that was it. ISTR the issue with that would be how to not break existing behavior that assumes that onboot is TRUE. Plus the original onboot stuff was about blocking startup, not forcefully starting the connection? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Maintaining connection
On Thu, 2015-03-12 at 09:04 -0500, Alex Ferm wrote: We use cellular modems for telemetry, and they disconnect every so often, and don't come back on-line on their own. I am using dbus via python to send Enable(False) followed by Enable(True) to reset network manager. This makes it reconnect to all the automatic connections that have been configured. What version of NetworkManager? I think 0.9.10 or later added WWAN autoconnect, which should handle this better. In any case, the Enable() mechanism is much better than I was thinking you were going to say :) If you're already using NM 0.9.10 or later and NM isn't attempting to reconnect, then it would be great to see some logs from the device so we can figure out what's going on. One more question: do you mind if the connection starts automatically when NM starts? If that's OK, then autoconnect=true + NM 0.9.10 should do what you want already unless there's a bug. Dan Alex Ferm PetroPower, LLC. 3003 E. 37th Street N. Suite 100 Wichita, KS 67219 Phone: (316) 361-0222 Toll Free: (877) 265-6581 Fax: (316) 361-0967 On 03/11/2015 07:49 PM, Stuart D. Gathman wrote: On Wed, 11 Mar 2015, Dan Williams wrote: On Wed, 2015-03-11 at 15:57 -0500, Alex Ferm wrote: Hello, I'm trying to write a python script that resets NetworkManager when the state is not NM_STATE_CONNECTED_GLOBAL. Does NetworkManager time out and retry automatically during the NM_STATE_CONNECTING state? Also, how is the NM_STATE_CONNECTED_GLOBAL determined(ie: is there a periodic ping or something?)? What's the reason to reset NM when it reports something isn't connected? Just to ensure always-on connectivity as hard as possible? Also, what do you mean by reset, what specific actions are you running to do so? In my case, wpa_supplicant hangs every so many megabytes, and I have to killall wpa_supplicant to restore the network connection. I've been wondering about a way to have NM do that automatically, since fixing wpa_supplicant seems to be difficult. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Maintaining connection
On Wed, 2015-03-11 at 20:49 -0400, Stuart D. Gathman wrote: On Wed, 11 Mar 2015, Dan Williams wrote: On Wed, 2015-03-11 at 15:57 -0500, Alex Ferm wrote: Hello, I'm trying to write a python script that resets NetworkManager when the state is not NM_STATE_CONNECTED_GLOBAL. Does NetworkManager time out and retry automatically during the NM_STATE_CONNECTING state? Also, how is the NM_STATE_CONNECTED_GLOBAL determined(ie: is there a periodic ping or something?)? What's the reason to reset NM when it reports something isn't connected? Just to ensure always-on connectivity as hard as possible? Also, what do you mean by reset, what specific actions are you running to do so? In my case, wpa_supplicant hangs every so many megabytes, and I have to killall wpa_supplicant to restore the network connection. I've been wondering about a way to have NM do that automatically, since fixing wpa_supplicant seems to be difficult. You can just kill -9 wpa_supplicant from a script somewhere and NM will restart the supplicant automatically via D-Bus activation. Does the hanging supplicant also block D-Bus communication? Can you gdb the supplicant and find out what function it's hung in? Or is it not actually hanging, but just not doing some requested operation? But obviously, fixing wpa_supplicant would be preferable... Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Maintaining connection
On 03/12/2015 10:31 AM, Dan Williams wrote: On Wed, 2015-03-11 at 20:49 -0400, Stuart D. Gathman wrote: On Wed, 11 Mar 2015, Dan Williams wrote: What's the reason to reset NM when it reports something isn't connected? Just to ensure always-on connectivity as hard as possible? Also, what do you mean by reset, what specific actions are you running to do so? In my case, wpa_supplicant hangs every so many megabytes, and I have to killall wpa_supplicant to restore the network connection. I've been wondering about a way to have NM do that automatically, since fixing wpa_supplicant seems to be difficult. You can just kill -9 wpa_supplicant from a script somewhere and NM will restart the supplicant automatically via D-Bus activation. Does the hanging supplicant also block D-Bus communication? Can you gdb the supplicant and find out what function it's hung in? Or is it not actually hanging, but just not doing some requested operation? But obviously, fixing wpa_supplicant would be preferable... This has some stacktraces. The problem persists on several different laptops, with different Wifi chipsets. https://bugzilla.redhat.com/show_bug.cgi?id=1119524 ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: No more IPv4 address after boot up since NM 0.9.10
On Thu, 2015-03-12 at 09:28 -0500, Dan Williams wrote: On Thu, 2015-03-12 at 13:30 +0100, Thomas Haller wrote: On Thu, 2015-03-12 at 07:32 -0400, Pavel Simerda wrote: - Original Message - What about my original suggestion of onboot as a separate option from auto[1] plus a new behavior that onboot connections would be enforced even if the device is already configured? [1] https://bugzilla.gnome.org/show_bug.cgi?id=700651 ah right. that was it. ISTR the issue with that would be how to not break existing behavior that assumes that onboot is TRUE. which existing behavior do you mean? Plus the original onboot stuff was about blocking startup, not forcefully starting the connection? yes it was. but IMO it's related: https://bugzilla.gnome.org/show_bug.cgi?id=700651#c23 Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Power management in NM
On Thu, 2015-03-12 at 14:27 +0200, Andrey Batyiev wrote: Hello I'm trying to figure out power management policies in NM. My app sometimes need to connect to Wi-Fi network even if user powered down Wi-Fi card (to save battery charge). Main problem here is an airplane/aircraft/flight mode, when user expects Wi-Fi to be offline at all times. My question is: am I correct, there is no way to distinguish between situation Wi-Fi is powered down for power savings and situation Wi-Fi is powered down because of airplane regulations? As far as I am understand right now, NM have only enable/disable switch for each device type, and there is no global airplane mode switch, right? What is your opinion on implementing such switch? From a kernel and userspace perspective, these are both the same thing. The mechanism to do this for both is setting airplane mode, because only with airplane mode does the device actually power down and save battery. There are two ways the user can set airplane mode. First is through a hardware switch on the laptop which cannot be reversed programmatically. The second is through a 'soft block' which *can* be reversed programmatically, which is typically what UI elements will do when you turn on airplane mode from the GUI or CLI. Unfortunately there's no good way to determine intent from either of these, and worse, some laptops don't have a hardware button but rely entirely on the software mechanisms to set airplane mode. My only thought is that if wifi is only soft-blocked, then perhaps the application could ask the user whether it should be allowed to connect or not, and if the user says yes then it can turn off the softblock and attempt to connect. Maybe that would work? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Maintaining connection
On 03/12/2015 11:58 AM, Dan Williams wrote: If the packets have an expired key, then that implies that key rotation has not happened. That's done on a timer that's negotiated during the EAP or WPA-PSK setup. If you had wpa_supplicant debug logs you could probably figure out what's going on in the supplicant. It stops logging while hung. This is from Fedora 19 (been reporting this problem for years): wlan0: Trying to associate with 00:1d:7e:2f:bd:0e (SSID='Gathman Home' freq=2462 MHz) wlan0: Associated with 00:1d:7e:2f:bd:0e wlan0: WPA: Key negotiation completed with 00:1d:7e:2f:bd:0e [PTK=CCMP GTK=CCMP] wlan0: CTRL-EVENT-CONNECTED - Connection to 00:1d:7e:2f:bd:0e completed [id=0 id_str=] working away*** dbus: wpas_dbus_bss_signal_prop_changed: Unknown Property value 7 dbus: wpas_dbus_bss_signal_prop_changed: Unknown Property value 7 dbus: wpas_dbus_bss_signal_prop_changed: Unknown Property value 7 repeat hundreds of times dbus: wpas_dbus_bss_signal_prop_changed: Unknown Property value 7 dbus: wpas_dbus_bss_signal_prop_changed: Unknown Property value 7 *hangs* killall wpa_supplicant* wlan0: CTRL-EVENT-DISCONNECTED bssid=00:1d:7e:2f:bd:0e reason=3 locally_generated=1 wlan0: CTRL-EVENT-TERMINATING Successfully initialized wpa_supplicant dbus: wpas_dbus_bss_signal_prop_changed: Unknown Property value 7 wlan0: SME: Trying to authenticate with 00:1d:7e:2f:bd:0e (SSID='Gathman Home' freq=2462 MHz) wlan0: Trying to associate with 00:1d:7e:2f:bd:0e (SSID='Gathman Home' freq=2462 MHz) wlan0: Associated with 00:1d:7e:2f:bd:0e wlan0: WPA: Key negotiation completed with 00:1d:7e:2f:bd:0e [PTK=CCMP GTK=CCMP] wlan0: CTRL-EVENT-CONNECTED - Connection to 00:1d:7e:2f:bd:0e completed [id=0 id_str=] dbus: wpas_dbus_bss_signal_prop_changed: Unknown Property value 7 dbus: wpas_dbus_bss_signal_prop_changed: Unknown Property value 7 dbus: wpas_dbus_bss_signal_prop_changed: Unknown Property value 7 working away again ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Maintaining connection
On Thu, 2015-03-12 at 11:54 -0400, Stuart Gathman wrote: On 03/11/2015 06:23 PM, Dan Williams wrote: On Wed, 2015-03-11 at 15:57 -0500, Alex Ferm wrote: Hello, I'm trying to write a python script that resets NetworkManager when the state is not NM_STATE_CONNECTED_GLOBAL. Does NetworkManager time out and retry automatically during the NM_STATE_CONNECTING state? Also, how is the NM_STATE_CONNECTED_GLOBAL determined(ie: is there a periodic ping or something?)? What's the reason to reset NM when it reports something isn't connected? Just to ensure always-on connectivity as hard as possible? Also, what do you mean by reset, what specific actions are you running to do so? In general, it would be useful if NM was able to detect that networking was hosed and reset things. How would it know, however? I generally ping the gateway manually to check the connection. Are gateways always pingable? Just checking for a connection is not sufficient - e.g. when wpa_supplicant hangs (radio is operational, but incoming and outgoing packets have expired key and are discarded). Microsoft used to ping one If the packets have an expired key, then that implies that key rotation has not happened. That's done on a timer that's negotiated during the EAP or WPA-PSK setup. If you had wpa_supplicant debug logs you could probably figure out what's going on in the supplicant. of their servers. But that could be a problem anywhere in between the PC and their server. NM does that with it's connectivity checking functionality, but of course since it's phone home functionality more or less, that must be enabled by the user/admin. NM does advertise the result via dbus/nmcli, but does not yet do anything with it internally. It's also not per-interface yet, so you couldn't use the result to determine whether a specific interface was hosted or not. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [review] backport th/memleaks-nm-1-0
On Wed, 2015-03-11 at 17:14 +0100, Thomas Haller wrote: On Thu, 2015-03-05 at 12:36 +0100, Thomas Haller wrote: Hi all, more backports ready, please see: th/memleaks-nm-1-0 Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Maintaining connection
On 03/11/2015 06:23 PM, Dan Williams wrote: On Wed, 2015-03-11 at 15:57 -0500, Alex Ferm wrote: Hello, I'm trying to write a python script that resets NetworkManager when the state is not NM_STATE_CONNECTED_GLOBAL. Does NetworkManager time out and retry automatically during the NM_STATE_CONNECTING state? Also, how is the NM_STATE_CONNECTED_GLOBAL determined(ie: is there a periodic ping or something?)? What's the reason to reset NM when it reports something isn't connected? Just to ensure always-on connectivity as hard as possible? Also, what do you mean by reset, what specific actions are you running to do so? In general, it would be useful if NM was able to detect that networking was hosed and reset things. How would it know, however? I generally ping the gateway manually to check the connection. Are gateways always pingable? Just checking for a connection is not sufficient - e.g. when wpa_supplicant hangs (radio is operational, but incoming and outgoing packets have expired key and are discarded). Microsoft used to ping one of their servers. But that could be a problem anywhere in between the PC and their server. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Maintaining connection
On Thu, 2015-03-12 at 10:39 -0400, Stuart Gathman wrote: On 03/12/2015 10:31 AM, Dan Williams wrote: On Wed, 2015-03-11 at 20:49 -0400, Stuart D. Gathman wrote: On Wed, 11 Mar 2015, Dan Williams wrote: What's the reason to reset NM when it reports something isn't connected? Just to ensure always-on connectivity as hard as possible? Also, what do you mean by reset, what specific actions are you running to do so? In my case, wpa_supplicant hangs every so many megabytes, and I have to killall wpa_supplicant to restore the network connection. I've been wondering about a way to have NM do that automatically, since fixing wpa_supplicant seems to be difficult. You can just kill -9 wpa_supplicant from a script somewhere and NM will restart the supplicant automatically via D-Bus activation. Does the hanging supplicant also block D-Bus communication? Can you gdb the supplicant and find out what function it's hung in? Or is it not actually hanging, but just not doing some requested operation? But obviously, fixing wpa_supplicant would be preferable... This has some stacktraces. The problem persists on several different laptops, with different Wifi chipsets. https://bugzilla.redhat.com/show_bug.cgi?id=1119524 Ok, we'll need debug logs then, since the stack traces show that the supplicant isn't really hung, it's just that the key change apparently didn't happen correctly... you can do this by: mv /usr/sbin/wpa_supplicant / killall -TERM wpa_supplicant /wpa_supplicant -dddtu (pipe to your favorite logfile) and then go until it hangs. Then send me the logfile since it might contain private information. Move the supplicant back to /usr/sbin/ when you're done to get back to normal. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Maintaining connection
On Thu, 2015-03-12 at 14:09 -0400, Stuart Gathman wrote: On 03/12/2015 12:40 PM, Dan Williams wrote: This has some stacktraces. The problem persists on several different laptops, with different Wifi chipsets. https://bugzilla.redhat.com/show_bug.cgi?id=1119524 Ok, we'll need debug logs then, since the stack traces show that the supplicant isn't really hung, it's just that the key change apparently didn't happen correctly... you can do this by: mv /usr/sbin/wpa_supplicant / killall -TERM wpa_supplicant /wpa_supplicant -dddtu (pipe to your favorite logfile) and then go until it hangs. Then send me the logfile since it might contain private information. Move the supplicant back to /usr/sbin/ when you're done to get back to normal. Already did that in f19 (see log in above bugzilla) - it doesn't log anything while hung (maybe I didn't have as many 'd's). But maybe F21 will be different. It takes a little over 3 days to hang with hardware crypto. So hang on ... :-) Yeah, but that log isn't a debug log, it's just the normal messages. -dddtu will add a ton of debug info from which we might be able to find out why rekeying isn't happening. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Maintaining connection
On 03/12/2015 12:40 PM, Dan Williams wrote: This has some stacktraces. The problem persists on several different laptops, with different Wifi chipsets. https://bugzilla.redhat.com/show_bug.cgi?id=1119524 Ok, we'll need debug logs then, since the stack traces show that the supplicant isn't really hung, it's just that the key change apparently didn't happen correctly... you can do this by: mv /usr/sbin/wpa_supplicant / killall -TERM wpa_supplicant /wpa_supplicant -dddtu (pipe to your favorite logfile) and then go until it hangs. Then send me the logfile since it might contain private information. Move the supplicant back to /usr/sbin/ when you're done to get back to normal. Already did that in f19 (see log in above bugzilla) - it doesn't log anything while hung (maybe I didn't have as many 'd's). But maybe F21 will be different. It takes a little over 3 days to hang with hardware crypto. So hang on ... :-) ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [review] backport th/memleaks-nm-1-0
On Thu, 2015-03-12 at 16:38 +0100, Thomas Haller wrote: On Wed, 2015-03-11 at 17:14 +0100, Thomas Haller wrote: On Thu, 2015-03-05 at 12:36 +0100, Thomas Haller wrote: Hi all, more backports ready, please see: th/memleaks-nm-1-0 Looks good to me, I pushed some cherry-picks from git master for a leak I found and some suppression updates for newer glib. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Power management in NM
Hello I'm trying to figure out power management policies in NM. My app sometimes need to connect to Wi-Fi network even if user powered down Wi-Fi card (to save battery charge). Main problem here is an airplane/aircraft/flight mode, when user expects Wi-Fi to be offline at all times. My question is: am I correct, there is no way to distinguish between situation Wi-Fi is powered down for power savings and situation Wi-Fi is powered down because of airplane regulations? As far as I am understand right now, NM have only enable/disable switch for each device type, and there is no global airplane mode switch, right? What is your opinion on implementing such switch? Thanks, Andrey ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
