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.