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]: update_system_hostname Mar 2 19:46:37 piranha NetworkManager[9612]: interface-parser: parsing file /etc/network/interfaces Mar 2 19:46:37 piranha NetworkManager[9612]: interface-parser: finished parsing file /etc/network/interfaces Mar 2 19:46:37 piranha NetworkManager[9612]: management mode: unmanaged Mar 2 19:46:37 piranha NetworkManager[9612]: 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]: device added (path: /sys/devices/pci:00/:00:1c.5/:05:00.0/net/eth0, iface: eth0): no ifupdown configuration found. Mar
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:
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 ___ 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 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 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 ___ 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
