"
Hi all (esp. @franco),
After migrating a working DS-Lite setup (M-net München, PPPoEv4 + DHCPv6-PD + GIF to AFTR `2001:a60:0:1::ffff`) from pfSense 2.8.1 to OPNsense 26.1.2_5 on identical hardware and WAN link, I hit a silent failure: PPPoE comes up fine, link-local IPv6 is reachable on `pppoe0`, dpinger reports the WAN IPv6 gateway as Online — but `/var/etc/dhcp6c.conf` stays at 0 bytes, no `IA_PD` request ever leaves, no global IPv6 ever appears on LAN (no track6 prefix), and the gif tunnel never gets a tunnel source.
This is distinct from the race fixed in commit `315153a07` ([thread 35876]) — that one addresses gif-reload after `newwanipv6` and assumes `dhcp6c` was started. Here `dhcp6c` is never started in the first place.
I traced the three code paths that could initialize `dhcp6c` on the PPPoE interface — `interface_configure()` in `interfaces.inc`, `ppp-ipv6.php`, and `rc.newwanipv6` — and all three skip it when `<ipaddr>pppoe</ipaddr>` + `<ipaddrv6>dhcp6</ipaddrv6>` are configured on the same WAN. The guard `interface_ppps_bound()` evaluates the v6 branch as `!ipv4_mode && ipv6_mode` = `false` for this combination, so the PPP layer says "DHCPv6 is not mine" while `interface_configure()` says "PPP owns v6, skip" — and `dhcp6c.conf` ends up empty.
Full reproducer, root-cause walkthrough with `file:line` references, and a small workaround script (`/usr/local/etc/rc.syshook.d/start/99-dslite-gif-rebuild`, ~20 lines of `sh`) that reliably gets us boot-to-Internet in ~10–60 s on M-net — https://gist.github.com/tobinger/89b3f4d7cdddf98571e20876792eb081.
Happy to test patches on this DS-Lite link. Also happy to file as a GitHub issue if you'd prefer that as the formal venue.
— Tobi
After migrating a working DS-Lite setup (M-net München, PPPoEv4 + DHCPv6-PD + GIF to AFTR `2001:a60:0:1::ffff`) from pfSense 2.8.1 to OPNsense 26.1.2_5 on identical hardware and WAN link, I hit a silent failure: PPPoE comes up fine, link-local IPv6 is reachable on `pppoe0`, dpinger reports the WAN IPv6 gateway as Online — but `/var/etc/dhcp6c.conf` stays at 0 bytes, no `IA_PD` request ever leaves, no global IPv6 ever appears on LAN (no track6 prefix), and the gif tunnel never gets a tunnel source.
This is distinct from the race fixed in commit `315153a07` ([thread 35876]) — that one addresses gif-reload after `newwanipv6` and assumes `dhcp6c` was started. Here `dhcp6c` is never started in the first place.
I traced the three code paths that could initialize `dhcp6c` on the PPPoE interface — `interface_configure()` in `interfaces.inc`, `ppp-ipv6.php`, and `rc.newwanipv6` — and all three skip it when `<ipaddr>pppoe</ipaddr>` + `<ipaddrv6>dhcp6</ipaddrv6>` are configured on the same WAN. The guard `interface_ppps_bound()` evaluates the v6 branch as `!ipv4_mode && ipv6_mode` = `false` for this combination, so the PPP layer says "DHCPv6 is not mine" while `interface_configure()` says "PPP owns v6, skip" — and `dhcp6c.conf` ends up empty.
Full reproducer, root-cause walkthrough with `file:line` references, and a small workaround script (`/usr/local/etc/rc.syshook.d/start/99-dslite-gif-rebuild`, ~20 lines of `sh`) that reliably gets us boot-to-Internet in ~10–60 s on M-net — https://gist.github.com/tobinger/89b3f4d7cdddf98571e20876792eb081.
Happy to test patches on this DS-Lite link. Also happy to file as a GitHub issue if you'd prefer that as the formal venue.
— Tobi
