WAN DHCPv6 configuration set to configuration file override prevents start of dhcpd6 on startup

[DustinHarp]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• [x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• [x] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug When the configuration of WAN interface is set to use a custom configuration file for the DHCPv6 client and LAN is set to track interface with DHCPv6 server and RA enabled on LAN the DHCPv6 server on LAN does not start on boot.

The use case involves development of dhcp6c patches with custom configuration options due to ISP idiosyncrasies. However this issue has been reproduced with stock dhcp6c and copying the auto-generated configuration file to an arbitrary location.

To Reproduce

Steps to reproduce the behavior:

1. Create a custom configuration file in a location to use for configuration override. An example used for testing is below.
2. Configure DHCPv6 on WAN to request a prefix using the custom configuration file
3. Set LAN to track WAN interface
4. Enable Route Advertisements on LAN interface
5. Enable DHCPv6 server on LAN interface ensuring a proper range is configured.
6. Observe the DHCPv6 server does not start automatically on reboot and needs to be manually started.

Expected behavior

DHCPv6 server on LAN starts on startup

Additional context Configuration used for test override.

interface vtnet0 {
  send ia-pd 0;
  request domain-name-servers;
  request domain-name;
  script "/var/etc/dhcp6c_wan_script.sh";
};
id-assoc pd 0 {
  prefix ::/56 infinity;
  prefix-interface vtnet1 {
    sla-id 0;
    sla-len 8;
  };
};

Environment

Software version used and hardware type if relevant, e.g.:

OPNsense 23.7.9 (amd64) Native DHCPv6 tested using ISP WAN and synthetic test network involving locally assigned prefix delegation and multiple OPNSense emulating WAN and LAN routers.

[fichtner]

Hmm, is this with Allow manual adjustment of DHCPv6 and Router Advertisements on LAN checked or unchecked or in both cases? And DHCPv6 refuses to start at all or just on bootup?

[DustinHarp]

Hmm, is this with Allow manual adjustment of DHCPv6 and Router Advertisements on LAN checked or unchecked or in both cases?

Issue reproduced in both cases.

And DHCPv6 refuses to start at all or just on bootup?

Just an issue with bootup. Manual start after bootup operates normally.

Thank you.

[DustinHarp]

Did some investigation into this issue.

In src/etc/inc/plugins.inc.d/dhcpd.inc line 1617 is a check if the count of $dhcpdv6ifs variable is greater than zero. This variable is set by the function get_real_interface With the auto-generated configuration the value is greater than zero, but with the configuration override the value is zero for the initial run during boot. If the service is manually started afterwards it is normal value.

Thank you

[DustinHarp]

A small update: Adding a script to rc.syshook.d/start to restart dhcpd6, radvd and dpinger at the end of the boot process seems to workaround this issue. Considering what I wrote about the discrepancy with dhcpd.inc during boot in comparison with a manual restart what would be the best way to investigate this?

Thank you

[fichtner]

@DustinHarp sorry for the delay... well I don't think your problem is the manual file override or get_real_interface() because essentially it simply requires an address and your DHCP log should say something about "found no suitable IPv6 address" which would indicate a timing issue more than anything else given your workaround as well.

Cheers, Franco

[OPNsense-bot]

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository, please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue, just let us know, so we can reopen the issue and assign an owner to it.