Project

General

Profile

Actions

Bug #13473

closed

No IPv6 address acquired after reboot/dhcp6c not starting

Added by Flole Systems about 2 years ago. Updated 11 months ago.

Status:
Duplicate
Priority:
Normal
Assignee:
-
Category:
DHCP (IPv6)
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Default
Affected Version:
Affected Architecture:

Description

Upon boot I often see something like this:

Sep 7 00:33:14    dhcp6c    58536    failed to initialize lagg0.YYY
Sep 7 00:33:14    dhcp6c    58536    invalid interface(lagg0.YYY): Device not configured
Sep 7 00:33:14    dhcp6c    58536    failed to open /usr/local/etc/dhcp6cctlkey: No such file or directory

The result is, that dhcp6c is not running and no IPv6 addresses are acquired.

This was reported in #9914 aswell but the cause was never identified.

I checked the system.log and found this:

Sep  7 00:33:09 firewall kernel: vlanXXX: changing name to 'lagg0.XXX'
Sep  7 00:33:10 firewall php-fpm[371]: /rc.newwanip: rc.newwanip: Info: starting on lagg0.ZZZ.
Sep  7 00:33:10 firewall php-fpm[371]: /rc.newwanip: rc.newwanip: on (IP address: XXXXXXXXXXXXXX) (interface: XXXXX) (real interface: lagg0.ZZZ).
Sep  7 00:33:14 firewall check_reload_status[408]: rc.newwanip starting lagg0.XXX
Sep  7 00:33:14 firewall php[430]: rc.bootup: calling interface_dhcpv6_configure.
Sep  7 00:33:14 firewall php[430]: rc.bootup: Accept router advertisements on interface lagg0.XXX
Sep  7 00:33:14 firewall php[430]: rc.bootup: Accept router advertisements on interface lagg0.YYY
Sep  7 00:33:14 firewall php[430]: rc.bootup: The command '/sbin/ifconfig lagg0.YYY inet6 accept_rtadv' returned exit code '1', the output was 'ifconfig: interface lagg0.YYY does not exist'
Sep  7 00:33:14 firewall php[430]: rc.bootup: The command '/usr/local/sbin/dhcp6c  -n -c /var/etc/dhcp6c.conf -p /var/run/dhcp6c.pid lagg0.XXX lagg0.YYY' returned exit code '1', the output was ''
Sep  7 00:33:14 firewall php[430]: rc.bootup: Starting DHCP6 client for interfaces lagg0.XXX,lagg0.YYY in DHCP6 without RA mode
Sep  7 00:33:14 firewall php[430]: rc.bootup: Starting rtsold process on wan(lagg0.XXX)
Sep  7 00:33:15 firewall php-fpm[370]: /rc.newwanip: rc.newwanip: Info: starting on lagg0.XXX.
Sep  7 00:33:15 firewall php-fpm[370]: /rc.newwanip: route_add_or_change: Invalid gateway  and/or network interface lagg0.YYY
Sep  7 00:33:15 firewall kernel: gif0: link state changed to UP
Sep  7 00:33:15 firewall php-fpm[370]: /rc.newwanip: Gateway, switch to: WAN_DHCP6
Sep  7 00:33:16 firewall rtsold[82782]: <rtsock_input_ifannounce> interface vlanY removed
Sep  7 00:33:16 firewall kernel: vlanYYY: changing name to 'lagg0.YYY'

So apparently it tries to run the client already when the first interface is configured while it should wait for the last one to be configured. Later on the router advertisement accepting is retried, but the dhcp6c start is apparently never retried, probably due to a created lock. I suggest to remove the lockfile when the exit code is unexpected so we assume that it is no longer running.

Also during bootup I saw this logged:

Loading configuration......done.
Configuring WireGuard tunnels...
wg0: changing name to 'tun_wg0'
tun_wg0: link state changed to UP
route: writing to routing socket: Network is unreachable
route: fe80::1%lagg0.XXXX: Name does not resolve
route: writing to routing socket: Network is unreachable
route: writing to routing socket: Network is unreachable
route: writing to routing socket: Network is unreachable
route: writing to routing socket: Network is unreachable
done.
Updating configuration...done.
[...]
Configuring loopback interface...done.
Configuring LAGG interfaces...
lagg0: IPv6 addresses on XXX have been removed before adding it as a member to prevent IPv6 address scope violation.
lagg0: link state changed to DOWN
lagg0: IPv6 addresses on YYY have been removed before adding it as a member to prevent IPv6 address scope violation.

So there was an attempt to use a lagg by wireguard when it wasn't even configured yet. So in general the order at which services are starting during bootup is messed up.

This has been tested on the latest pfSense plus release.


Related issues

Is duplicate of Bug #9453: Reconfiguring a parent LAGG interface breaks its VLANsResolvedMarcos M04/04/2019

Actions
Actions

Also available in: Atom PDF