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
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: 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 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: 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: [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: 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 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: 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: 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" > > > To: "Harald Dunkel" > > > Cc: "networkmanager." , "Pavel Simerda" > > > > > > 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 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
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
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" > > To: "Harald Dunkel" > > Cc: "networkmanager." , "Pavel Simerda" > > > > 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 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
- Original Message - > From: "Thomas Haller" > To: "Harald Dunkel" > Cc: "networkmanager." , "Pavel Simerda" > > 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 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 10:32 +0100, Harald Dunkel wrote: > On Wed, 04 Mar 2015 18:15:43 +0100 > Frederik Himpe 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
On Wed, 04 Mar 2015 18:15:43 +0100 Frederik Himpe 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 > 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
