ifupdown-ng / ifupdown-ng

flexible ifup/ifdown implementation

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Failure in idetifying the address family of fe80::

marcsello opened this issue · comments

I have a server that runs on Alpine Linux 3.16.0. Using ifupdown-ng I have tried to assign the link-local address of fe80:: explicitly (this is a valid link-local address) to a bridge interface with the following configuration:

auto br100
iface br100 inet static
	bridge-ports none
	address 192.168.100.1
	netmask 255.255.255.0
	bridge-stp off
	mtu 1500

iface br100 inet6 static
	address fe80::
	netmask 64
	mtu 1500
	accept_ra 0
	autoconf 0
	scope local

But when I try to bring up the interface I receive the following error message:

alpine:~# ifup br100
Object "" is unknown, try "ip help".

And the address is not assigned to the interface.

Using -v I could track down the problem:

[*snip*]
/usr/libexec/ifupdown-ng/static
+ '[' -z  ]
+ IF_METRIC=1
+ '[' -n  ]
+ '[' -n  ]
+ '[' -n 1 ]
+ METRIC='metric 1'
+ configure_addresses add
+ addr_family 192.168.100.1/24
+ '[' 192.168.100.1/24 '!=' 68.100.1/24 ]
+ echo -4
+ addrfam=-4
+ '['  -a -4 '=' -4 ]
+ PEER=
+ ip -4 addr add 192.168.100.1/24 dev br100
+ addr_family fe80::/64
+ '[' fe80::/64 '!=' fe80::/64 ]
+ '[' fe80::/64 '!=' fe80::/64 ]
+ exit 1
+ addrfam=
+ '['  -a  '=' -4 ]
+ PEER=
+ ip  addr add fe80::/64 dev br100
Object "" is unknown, try "ip help".
[*snip*]

The problem seems to be with the executor-scripts/linux/static script in the addr_family() function. The matching pattern defined there does not match to fe80::, so the function exits 1 instead. Since this error isn't handled, the scripts proceeds to executing the following command:

ip "" addr add fe80::/64 dev br100

Which results in the above mentioned, little misleading error message produced by iproute2.

Changing the address to something else, like fe80::1 works without a problem.

I don't really understand this type of matching in shell. But it seems to me, that the address fe80:: does not match the pattern defined there.

Writing out fe80:0000:0000:0000:0000:0000:0000:0000 in the configuration file does not help either because by the time the address is evaluated it gets compacted along the way.

Using address fe80::/64 in the configuration causes the same problem.

I will take a look into this problem.
For VRRP I had to create a special function which is detecting the IPv4 and IPv6 addresses. Maybe I can adapt it a little bit and I will submit a patch.