ifupdown: boot console says 'Failed to start Raise network interfaces' yet interface is up

[Rick Thomas]

Anybody else seen this? (Submitted as Bug#834376)

Updated to latest debian Sid

After boot is completed we see:

rbthomas@sheeva:~$ systemctl status networking.service
* networking.service - Raise network interfaces
Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
Drop-In: /run/systemd/generator/networking.service.d
`-50-insserv.conf-$network.conf
Active: failed (Result: exit-code) since Sun 2016-08-14 17:02:50 PDT; 39min ago
Docs: man:interfaces(5)
Main PID: 893 (code=exited, status=1/FAILURE)

Aug 14 17:02:41 sheeva systemd[1]: Starting Raise network interfaces...
Aug 14 17:02:46 sheeva ifup[893]: /sbin/ifup: waiting for lock on /run/network/ifstate.eth0
Aug 14 17:02:49 sheeva ifup[893]: RTNETLINK answers: File exists
Aug 14 17:02:49 sheeva ifup[893]: Failed to bring up eth0.
Aug 14 17:02:50 sheeva systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
Aug 14 17:02:50 sheeva systemd[1]: Failed to start Raise network interfaces.
Aug 14 17:02:50 sheeva systemd[1]: networking.service: Unit entered failed state.
Aug 14 17:02:50 sheeva systemd[1]: networking.service: Failed with result 'exit-code'.

However the interface *is* up:

rbthomas@sheeva:~$ /sbin/ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.3.111 netmask 255.255.240.0 broadcast 192.168.15.255
inet6 2001:1234:2d2:1:f2ad:4eff:fe00:3077 prefixlen 64 scopeid 0x0<global>
inet6 fe80::f2ad:4eff:fe00:3077 prefixlen 64 scopeid 0x20<link>
ether f0:ad:4e:00:30:77 txqueuelen 1000 (Ethernet)
RX packets 6897 bytes 738138 (720.8 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4556 bytes 427016 (417.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 85

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1 (Local Loopback)
RX packets 2 bytes 98 (98.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2 bytes 98 (98.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0


Here is a possibly relevant config file

--------- /etc/network/interfaces ------------
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo eth0
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 192.168.3.111
netmask 255.255.240.000
network 192.168.0.0
broadcast 192.168.15.255
gateway 192.168.1.1

iface eth0 inet6 static
address 2001:1234:2d2:1:f2ad:4eff:fe00:3077
netmask 64
--------- /etc/network/interfaces ------------

[Hans]

Hi Thomas,

yes, had this problem some time ago, but forgot about the reason. I believe,
it was something with my network settings and network-manager.
Your interfaces looks strange, is this correct? See my comments at your
configuration, but maybe I am wrong:

> Anybody else seen this? (Submitted as Bug#834376)

>

> --------- /etc/network/interfaces ------------
> # This file describes the network interfaces available on your system
> # and how to activate them. For more information, see interfaces(5).
>
> # The loopback network interface
> auto lo eth0
> iface lo inet loopback
>
> # The primary network interface
> allow-hotplug eth0
> iface eth0 inet static
> address 192.168.3.111
> netmask 255.255.240.000
> network 192.168.0.0
> broadcast 192.168.15.255
> gateway 192.168.1.1
>

Shouldn't it be so?
network 192.168.3.0
broadcast 192.168.3.255
gateway 192.168.3.1

Looks somehow weired for me, but on the other side I do not know your
environment, of course, and maybe your settings are correct.

Good luck!

Hans

[Pascal Hambourg]

Le 16/08/2016 à 09:03, Rick Thomas a écrit :
>
> Aug 14 17:02:41 sheeva systemd[1]: Starting Raise network interfaces...
> Aug 14 17:02:46 sheeva ifup[893]: /sbin/ifup: waiting for lock on /run/network/ifstate.eth0
> Aug 14 17:02:49 sheeva ifup[893]: RTNETLINK answers: File exists

"RTNETLINK answers: File exists" typically happens when you try to add
an address or a route which is already exists with "ip", which is the
tool used internally by ifup.

> However the interface *is* up:

Yes but the configuration may not be complete.

> --------- /etc/network/interfaces ------------
> # This file describes the network interfaces available on your system
> # and how to activate them. For more information, see interfaces(5).
>
> # The loopback network interface
> auto lo eth0
> iface lo inet loopback
>
> # The primary network interface
> allow-hotplug eth0
> iface eth0 inet static
> address 192.168.3.111
> netmask 255.255.240.000
> network 192.168.0.0
> broadcast 192.168.15.255
> gateway 192.168.1.1

Note that the network and broadcast options are not required. If
missing, they will be calculated from the address and netmask values.

> iface eth0 inet6 static
> address 2001:1234:2d2:1:f2ad:4eff:fe00:3077
> netmask 64

This IPv6 address looks like an autoconfigured address calculated from
the MAC address. You should not statically assign this kind of address.

If a router in your network sends IPv6 Router Advertisements (RA) with
the prefix 2001:1234:2d2:1::/64, then the kernel may autoconfigure the
same address, so this could be the duplicate.

"ip -6 addr" shows whether an IPv6 address was statically or dynamically
assigned.

Note for Hans : the network and broadcast addresses are consistent with
the netmask.

[Rick Thomas]

Thanks Pascal!

On Aug 16, 2016, at 12:59 AM, Pascal Hambourg <pas...@plouf.fr.eu.org> wrote:

> Le 16/08/2016 à 09:03, Rick Thomas a écrit :
>>
>> Aug 14 17:02:41 sheeva systemd[1]: Starting Raise network interfaces...
>> Aug 14 17:02:46 sheeva ifup[893]: /sbin/ifup: waiting for lock on /run/network/ifstate.eth0
>> Aug 14 17:02:49 sheeva ifup[893]: RTNETLINK answers: File exists
>
> "RTNETLINK answers: File exists" typically happens when you try to add an address or a route which is already exists with "ip", which is the tool used internally by ifup.
>
>> However the interface *is* up:
>
> Yes but the configuration may not be complete.

It happens that it is complete, but I understand that it might not be.

>
>> --------- /etc/network/interfaces ------------
>> # This file describes the network interfaces available on your system
>> # and how to activate them. For more information, see interfaces(5).
>>
>> # The loopback network interface
>> auto lo eth0
>> iface lo inet loopback
>>
>> # The primary network interface
>> allow-hotplug eth0
>> iface eth0 inet static
>> address 192.168.3.111
>> netmask 255.255.240.000
>> network 192.168.0.0
>> broadcast 192.168.15.255
>> gateway 192.168.1.1
>
> Note that the network and broadcast options are not required. If missing, they will be calculated from the address and net mask values.

Thanks. I’ll keep that in mind for next time. No harm in leaving them in though, right?

>
>> iface eth0 inet6 static
>> address 2001:1234:2d2:1:f2ad:4eff:fe00:3077
>> netmask 64
>
> This IPv6 address looks like an autoconfigured address calculated from the MAC address. You should not statically assign this kind of address.

You are correct. I assumed that when the IPv4 address needed to be static, the same was true for the IPv6 address as well. I further assumed that declaring it to be inet6 static would prevent it from getting any address from the RA. Apparently not.

Why do you say that I should not statically assign this kind of address? As long as it’s the same as it would be getting dynamically, is there any harm? (other than the one we’re observing here?)

>
> If a router in your network sends IPv6 Router Advertisements (RA) with the prefix 2001:1234:2d2:1::/64, then the kernel may autoconfigure the same address, so this could be the duplicate.
>
> “ip -6 addr" shows whether an IPv6 address was statically or dynamically assigned.

It seems that it is getting a dynamic address from the RA (Yes, it’s the same address as I am statically assigning.) Prior to the most recent Sid update, it did not get a dynamic address. Is that a bug? If so, is the bug in the previous behavior or the current behavior? can someone explain what the purpose of the change was?

In any case, I commented out the inet6 stanza and now it boots without error. Also, IPv6 gets configured OK (dynamically).

>
> Note for Hans : the network and broadcast addresses are consistent with the netmask.
>

Yes, for historical reasons I have machines on this LAN whose IPv4 addresses have 3rd octets in the range 0-15. The RFC1918 (192.168.xx.xx) address range is a true class B ( or “/16”, if you prefer cider notation) and it can be carved up any way you want. It’s often used as a bunch of class Cs ( or “/24”s) but that’s not mandatory.

Rick

PS: I’d like to leave this bug open until we can be sure we understand the reason that the behavior changed. This may be a hint that points to a timing glitch in the way systemd configures network interfaces that could cause more serious problems down the road.

[Pascal Hambourg]

Le 16/08/2016 à 22:07, Rick Thomas a écrit :
>
> On Aug 16, 2016, at 12:59 AM, Pascal Hambourg <pas...@plouf.fr.eu.org> wrote:
>>
>>> iface eth0 inet6 static
>>> address 2001:1234:2d2:1:f2ad:4eff:fe00:3077
>>> netmask 64
>>
>> This IPv6 address looks like an autoconfigured address calculated
> from the MAC address. You should not statically assign this kind of
> address.
>
> You are correct. I assumed that when the IPv4 address needed to be
> static, the same was true for the IPv6 address as well.

No, IPv4 and IPv6 configuration and operation are mostly independent.

> I further assumed that declaring it to be inet6 static would prevent it
> from getting any address from the RA. Apparently not.

Indeed. A single interface can have multiple addresses, each being
either static or dynamic.

> Why do you say that I should not statically assign this kind of address?

Because it does not provide any benefit. The interface identifier part
based on the MAC address is only useful to ensure the address uniqueness
with stateless autoconfiguration (unlike stateful configuration such as
DHCP where the server takes care of uniqueness).

But this kind of address is long and impossible to remember. With static
configuration, the uniqueness is ensured by the administrator who can
chose whatever convenient addresses they like such as <prefix>::n.

Also, if you change the MAC address (when replacing the hardware part
containing it), you must also manually change a static MAC-based
address. You don't have to do this with an arbitrary static address.

> It seems that it is getting a dynamic address from the RA (Yes, it’s
> the same address as I am statically assigning.) Prior to the most
> recent Sid update, it did not get a dynamic address. Is that a bug?

My Debian systems configured as hosts (not routers), which is the
default, have had SLAAC enabled since many Debian versions.

If you want to disable IPv6 stateless autoconfiguration, just add
"ipv6.autoconf=0" to the kernel parameters. Don't add it in a modprobe
file as IPv6 is not build as a module in Debian kernels, so it wouln't
have any effect.
See <https://www.kernel.org/doc/Documentation/networking/ipv6.txt> for
reference.
Methods based on sysctl are not reliable because the network
configuration may happen before sysctl setup.