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
Updated by Jim Pingle about 2 years ago
- Plus Target Version changed from 22.11 to 23.01
Updated by Jim Pingle about 2 years ago
- Status changed from New to Incomplete
- Target version deleted (
2.7.0) - Plus Target Version deleted (
23.01)
I can't reproduce anything like this with LAGG and DHCP6 on current snapshots, it's all working happily here and none of those errors are present in the logs across multiple reboots. My LAGG-based WANs obtain DHCP addresses as expected and LAGG-based LANs get their tracked delegated prefixes OK as well.
If there is a problem here we're going to need more info about how to reproduce it. It's possible it was corrected already in dev snapshots and that's why it's working for me, or it may be specific to your DHCP6 settings/environment.
Updated by Flole Systems about 2 years ago
Have you tested with multiple client interfaces? As described the issue happens due to the new "single dhcpv6 client for all interfaces"-function which attempts to configure all interfaces when only the first interface is ready. So are you really using a single lagg with multiple vlans that are running dhcpv6 clients?
Updated by Flole Systems almost 2 years ago
Further information was provided, so this is not incomplete.