Project

General

Profile

Actions

Bug #13473

open

No IPv6 address acquired after reboot/dhcp6c not starting

Added by Flole Systems 3 months ago. Updated 10 days ago.

Status:
Incomplete
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.

Actions #1

Updated by Jim Pingle about 2 months ago

  • Plus Target Version changed from 22.11 to 23.01
Actions #2

Updated by Jim Pingle 15 days 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.

Actions #3

Updated by Flole Systems 10 days 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?

Actions #4

Updated by Flole Systems 10 days ago

Probably similar to #13671

Actions

Also available in: Atom PDF