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: 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: 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: No more IPv4 address after boot up since NM 0.9.10
On ma, 2015-03-02 at 16:04 -0600, Dan Williams wrote: I am not sure whether this is a really satisfying solution though: what if I would want to debug potential kernel errors during boot, then NM will cause your these kind of troubles? Well, I don't think NM is causing any kind of troubles at all, it's just noticing that the interface is configured already when it starts, and tries very hard not to mess with the interface. So now a few days later, I can tell that disabling netconsole did not entirely fix my problem. In most cases, I'm still left without any IPv4, and I have no clue what might bring up the interface before NM becomes active. 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? -- Frederik Himpe frede...@frehi.be ___ 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 ma, 2015-03-02 at 14:22 -0600, Dan Williams wrote: I also have netconsole activated via this line in a file in /etc/modprobe.d: options netconsole netconsole=@192.168.5.205/eth0,@192.168.5.128/24:77:03:f0:16:64 Could this be related in some way? Yes, that might well bring the interface into IFF_UP state before NM starts, at which point the interface might already be assigned both IPv4 and IPv6 LL addresses before NM starts, leading to the behavior you see. OK, I removed all this netconsole stuff, rebuild my initrd and deleted the eth0 network connection in NM, and at the next reboot, everything was working. I am not sure whether this is a really satisfying solution though: what if I would want to debug potential kernel errors during boot, then NM will cause your these kind of troubles? In any case, thanks for helping me to find the culprit! -- Frederik Himpe frede...@frehi.be ___ 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 Mon, 2015-03-02 at 22:03 +0100, Frederik Himpe wrote: On ma, 2015-03-02 at 14:22 -0600, Dan Williams wrote: I also have netconsole activated via this line in a file in /etc/modprobe.d: options netconsole netconsole=@192.168.5.205/eth0,@192.168.5.128/24:77:03:f0:16:64 Could this be related in some way? Yes, that might well bring the interface into IFF_UP state before NM starts, at which point the interface might already be assigned both IPv4 and IPv6 LL addresses before NM starts, leading to the behavior you see. OK, I removed all this netconsole stuff, rebuild my initrd and deleted the eth0 network connection in NM, and at the next reboot, everything was working. I am not sure whether this is a really satisfying solution though: what if I would want to debug potential kernel errors during boot, then NM will cause your these kind of troubles? Well, I don't think NM is causing any kind of troubles at all, it's just noticing that the interface is configured already when it starts, and tries very hard not to mess with the interface. The kernel is setting the interface IFF_UP, and that causes the kernel to assign an IPv6LL address to the interface, and then start IPv6 SLAAC on it. That results in the interface receiving an global IPv6 address, and that's what NM is noticing and not touching, because the interface has already been configured... NetworkManager has no idea whether the administrator of the system expects the interface to remain configured that way or not, and NM reconfiguring the interface could (for example) badly break bootup when your filesystem is on the network. One option would be to put something like ip addr flush dev eth0 in your rc.local if you know you don't care about the kernel configuration after bootup... Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
No more IPv4 address after boot up since NM 0.9.10
Since Network Manager 0.9.10, up to current version 1.0, I have the problem that I don't get an IPv4 address on my Debian Jessie system. I only have an IPv6 address which I receive through SLAAC. Network Manager appears to create a broken connection eth0 every time I boot up my system, and selects this by default. I have to manually select Wired Connection 1 to get an IPv4 address. I can delete this broken eth0 connection, but at the next boot, it's back again and selected by default. Also enabling IPv4 in this eth0 connection does not work: it is disabled again at the next boot. Some other people are seeing this as well: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755202 This is what I see right after boot up: # nmcli c show NAMEUUID TYPE DEVICE eth007ecf73d-d060-48a0-8e71-c0838bdd02c5 802-3-ethernet eth0 Wired connection 1 0934013f-82d4-48e4-9f5e-7b75074ace83 802-3-ethernet -- # nmcli c show eth0 connection.id: eth0 connection.uuid:07ecf73d-d060-48a0-8e71-c0838bdd02c5 connection.interface-name: eth0 connection.type:802-3-ethernet connection.autoconnect: no connection.autoconnect-priority:0 connection.timestamp: 1425321997 connection.read-only: no connection.permissions: connection.zone:-- connection.master: -- connection.slave-type: -- connection.secondaries: connection.gateway-ping-timeout:0 802-3-ethernet.port:-- 802-3-ethernet.speed: 0 802-3-ethernet.duplex: -- 802-3-ethernet.auto-negotiate: yes 802-3-ethernet.mac-address: BC:5F:F4:38:BE:84 802-3-ethernet.cloned-mac-address: -- 802-3-ethernet.mac-address-blacklist: 802-3-ethernet.mtu: auto 802-3-ethernet.s390-subchannels: 802-3-ethernet.s390-nettype:-- 802-3-ethernet.s390-options: ipv4.method:disabled ipv4.dns: ipv4.dns-search: ipv4.addresses: ipv4.gateway: -- ipv4.routes: ipv4.route-metric: -1 ipv4.ignore-auto-routes:no ipv4.ignore-auto-dns: no ipv4.dhcp-client-id:-- ipv4.dhcp-send-hostname:yes ipv4.dhcp-hostname: -- ipv4.never-default: no ipv4.may-fail: yes ipv6.method:auto ipv6.dns: ipv6.dns-search: ipv6.addresses: ipv6.gateway: -- ipv6.routes: ipv6.route-metric: -1 ipv6.ignore-auto-routes:no ipv6.ignore-auto-dns: no ipv6.never-default: no ipv6.may-fail: yes ipv6.ip6-privacy: -1 (unknown) ipv6.dhcp-send-hostname:yes ipv6.dhcp-hostname: -- GENERAL.NAME: eth0 GENERAL.UUID: 07ecf73d-d060-48a0-8e71-c0838bdd02c5 GENERAL.DEVICES:eth0 GENERAL.STATE: activated GENERAL.DEFAULT:no GENERAL.DEFAULT6: yes GENERAL.VPN:no GENERAL.ZONE: -- GENERAL.DBUS-PATH: /org/freedesktop/NetworkManager/ActiveConnection/0 GENERAL.CON-PATH: /org/freedesktop/NetworkManager/Settings/1 GENERAL.SPEC-OBJECT:/ GENERAL.MASTER-PATH:-- IP4.GATEWAY: IP6.ADDRESS[1]: 2a02:1812:1710:b900:be5f:f4ff:fe38:be84/64 IP6.ADDRESS[2]: fe80::be5f:f4ff:fe38:be84/64 IP6.GATEWAY:fe80::5e35:3bff:fe9a:aad2 The logs contain this: Mar 2 19:46:37 piranha NetworkManager[9612]: info update_system_hostname Mar 2 19:46:37 piranha NetworkManager[9612]: infointerface-parser: parsing file /etc/network/interfaces Mar 2 19:46:37 piranha NetworkManager[9612]: infointerface-parser: finished parsing file /etc/network/interfaces Mar 2 19:46:37 piranha NetworkManager[9612]: info management mode: unmanaged Mar 2 19:46:37 piranha NetworkManager[9612]: info devices added (path: /sys/devices/pci:00/:00:1c.5/:05:00.0/net/eth0, iface: eth0) Mar 2 19:46:37 piranha NetworkManager[9612]: info device added (path: /sys/devices/pci:00/:00:1c.5/:05:00.0/net/eth0, iface: eth0): no ifupdown
Re: No more IPv4 address after boot up since NM 0.9.10
On Mon, 2015-03-02 at 20:22 +0100, Frederik Himpe wrote: Since Network Manager 0.9.10, up to current version 1.0, I have the problem that I don't get an IPv4 address on my Debian Jessie system. I only have an IPv6 address which I receive through SLAAC. Network Manager appears to create a broken connection eth0 every time I boot up my system, and selects this by default. I have to manually select Wired Connection 1 to get an IPv4 address. I can delete this broken eth0 connection, but at the next boot, it's back again and selected by default. Also enabling IPv4 in this eth0 connection does not work: it is disabled again at the next boot. at boot up, somebody else is configuring the interface. Hence, NM sees that something is already there and does no longer activate an available, matching, autoconnect=yes connection (as it would to otherwise). Instead, it generates an in-memory connection eth0 that looks like what is configured externally. In this case, it only pretends that such a connection is active, it does not actively manage the interface. If you happen to modify that connection, it will be saved to disk. Otherwise it is gone after restart. You can delete the connection, NM will then down the interface. You can also activate another connection, in which case it will delete the in-memory connection too (unless it was persisted because you modified it). The question is, who configures that interface? Don't do that if you don't want it. Maybe some script that ups the interface and enables SLAAC? Thomas Some other people are seeing this as well: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755202 This is what I see right after boot up: # nmcli c show NAMEUUID TYPE DEVICE eth007ecf73d-d060-48a0-8e71-c0838bdd02c5 802-3-ethernet eth0 Wired connection 1 0934013f-82d4-48e4-9f5e-7b75074ace83 802-3-ethernet -- # nmcli c show eth0 connection.id: eth0 connection.uuid:07ecf73d-d060-48a0-8e71-c0838bdd02c5 connection.interface-name: eth0 connection.type:802-3-ethernet connection.autoconnect: no connection.autoconnect-priority:0 connection.timestamp: 1425321997 connection.read-only: no connection.permissions: connection.zone:-- connection.master: -- connection.slave-type: -- connection.secondaries: connection.gateway-ping-timeout:0 802-3-ethernet.port:-- 802-3-ethernet.speed: 0 802-3-ethernet.duplex: -- 802-3-ethernet.auto-negotiate: yes 802-3-ethernet.mac-address: BC:5F:F4:38:BE:84 802-3-ethernet.cloned-mac-address: -- 802-3-ethernet.mac-address-blacklist: 802-3-ethernet.mtu: auto 802-3-ethernet.s390-subchannels: 802-3-ethernet.s390-nettype:-- 802-3-ethernet.s390-options: ipv4.method:disabled ipv4.dns: ipv4.dns-search: ipv4.addresses: ipv4.gateway: -- ipv4.routes: ipv4.route-metric: -1 ipv4.ignore-auto-routes:no ipv4.ignore-auto-dns: no ipv4.dhcp-client-id:-- ipv4.dhcp-send-hostname:yes ipv4.dhcp-hostname: -- ipv4.never-default: no ipv4.may-fail: yes ipv6.method:auto ipv6.dns: ipv6.dns-search: ipv6.addresses: ipv6.gateway: -- ipv6.routes: ipv6.route-metric: -1 ipv6.ignore-auto-routes:no ipv6.ignore-auto-dns: no ipv6.never-default: no ipv6.may-fail: yes ipv6.ip6-privacy: -1 (unknown) ipv6.dhcp-send-hostname:yes ipv6.dhcp-hostname: -- GENERAL.NAME: eth0 GENERAL.UUID: 07ecf73d-d060-48a0-8e71-c0838bdd02c5 GENERAL.DEVICES:eth0 GENERAL.STATE: activated GENERAL.DEFAULT:no GENERAL.DEFAULT6: yes GENERAL.VPN:no GENERAL.ZONE: -- GENERAL.DBUS-PATH: /org/freedesktop/NetworkManager/ActiveConnection/0 GENERAL.CON-PATH: /org/freedesktop/NetworkManager/Settings/1 GENERAL.SPEC-OBJECT:
Re: No more IPv4 address after boot up since NM 0.9.10
On Mon, 2015-03-02 at 20:54 +0100, Frederik Himpe wrote: On ma, 2015-03-02 at 20:43 +0100, Thomas Haller wrote: The question is, who configures that interface? Don't do that if you don't want it. Maybe some script that ups the interface and enables SLAAC? I have no idea. Does not the kernel automatically configure the IPv6 using SLAAC without any user space intervention? Or should I set /proc/sys/net/ipv6/conf/*/accept_ra to 0 in order to use NM? Yes, it might, if something is setting the interface IFF_UP before NM starts. I also have netconsole activated via this line in a file in /etc/modprobe.d: options netconsole netconsole=@192.168.5.205/eth0,@192.168.5.128/24:77:03:f0:16:64 Could this be related in some way? Yes, that might well bring the interface into IFF_UP state before NM starts, at which point the interface might already be assigned both IPv4 and IPv6 LL addresses before NM starts, leading to the behavior you see. 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 ma, 2015-03-02 at 20:43 +0100, Thomas Haller wrote: The question is, who configures that interface? Don't do that if you don't want it. Maybe some script that ups the interface and enables SLAAC? I have no idea. Does not the kernel automatically configure the IPv6 using SLAAC without any user space intervention? Or should I set /proc/sys/net/ipv6/conf/*/accept_ra to 0 in order to use NM? I also have netconsole activated via this line in a file in /etc/modprobe.d: options netconsole netconsole=@192.168.5.205/eth0,@192.168.5.128/24:77:03:f0:16:64 Could this be related in some way? -- Frederik Himpe frede...@frehi.be ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
