Bug #13473
closedNo IPv6 address acquired after reboot/dhcp6c not starting
0%
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