24.7.2 IPv6 woes

[CruxtheNinth]

you reverted dhcp6c to 24.7.1 version (dhcp6c-20240710) and installed another newer one with pkg-add later.
Did you test in-between (and rebooted)?

Please test with dhcp6c-20240710 again as it seems you did some changes to the interfaces in between

Also please note that IPv6 DHCP on Deutsche Glasfaser takes 30-60 minutes depending on if you miss the Advertisement

Hi,

I still don't get an IPv6 from DG. Don't know if this is an DG issue or related to the problem discussed here.

I did the following:

opnsense-revert -r 24.7.1 dhcp6c
opnsense-update -zkr 24.7.2-nd

But nothing changed for hours so I reverted to to 24.7.2 original state.

I installed

# pkg add -f https://pkg.opnsense.org/FreeBSD:14:amd64/snapshots/misc/dhcp6c-20240820_1.pkg

and rebooted. But I don't see any 'dhcp6c.*event' messages (I enabled DHCPv6 logging on INFO).

I only see the following messages for dhcpv6:

<13>1 2024-08-29T09:56:59+02:00 fw.local.home dhcp6c 727 - [meta sequenceId="224"] RTSOLD script - Sending SIGHUP to dhcp6c
<29>1 2024-08-29T09:56:59+02:00 fw.local.home dhcp6c 44898 - [meta sequenceId="225"] restarting
<29>1 2024-08-29T09:56:59+02:00 fw.local.home dhcp6c 44898 - [meta sequenceId="226"] duplicated interface: igb0
<29>1 2024-08-29T09:56:59+02:00 fw.local.home dhcp6c 44898 - [meta sequenceId="240"] Sending Solicit
<29>1 2024-08-29T09:56:59+02:00 fw.local.home dhcp6c 44898 - [meta sequenceId="251"] Sending Solicit
<27>1 2024-08-29T09:56:59+02:00 fw.local.home dhcp6c 44898 - [meta sequenceId="252"] transmit failed: Network is down
<29>1 2024-08-29T09:57:00+02:00 fw.local.home dhcp6c 44898 - [meta sequenceId="256"] Sending Solicit
<29>1 2024-08-29T09:57:01+02:00 fw.local.home dhcp6c 44898 - [meta sequenceId="257"] Sending Solicit
<27>1 2024-08-29T09:57:01+02:00 fw.local.home dhcp6c 44898 - [meta sequenceId="258"] transmit failed: Network is down
<29>1 2024-08-29T09:57:03+02:00 fw.local.home dhcp6c 44898 - [meta sequenceId="270"] Sending Solicit
<29>1 2024-08-29T09:57:07+02:00 fw.local.home dhcp6c 44898 - [meta sequenceId="276"] Sending Solicit
<29>1 2024-08-29T10:01:06+02:00 fw.local.home dhcp6c 44898 - [meta sequenceId="4"] restarting
<29>1 2024-08-29T10:01:06+02:00 fw.local.home dhcp6c 44898 - [meta sequenceId="5"] duplicated interface: igb0
<29>1 2024-08-29T10:01:07+02:00 fw.local.home dhcp6c 44898 - [meta sequenceId="6"] Sending Solicit
<29>1 2024-08-29T10:01:07+02:00 fw.local.home dhcp6c 44898 - [meta sequenceId="7"] Sending Solicit
<27>1 2024-08-29T10:01:07+02:00 fw.local.home dhcp6c 44898 - [meta sequenceId="8"] transmit failed: Network is down
<29>1 2024-08-29T10:01:08+02:00 fw.local.home dhcp6c 44898 - [meta sequenceId="9"] Sending Solicit
<29>1 2024-08-29T10:01:08+02:00 fw.local.home dhcp6c 44898 - [meta sequenceId="10"] Sending Solicit
<27>1 2024-08-29T10:01:08+02:00 fw.local.home dhcp6c 44898 - [meta sequenceId="11"] transmit failed: Network is down
<29>1 2024-08-29T10:01:10+02:00 fw.local.home dhcp6c 44898 - [meta sequenceId="15"] Sending Solicit

[itn3rd77]

why do you need PPP for DG? That should not longer be necessary according to their own published specs.
Both IPv4 and IPv6 should do DHCP (via IPOE)

Are you mistaking DG with Deutsche GigaNetz? DG in this thread is Deutsche Glasfaser, not Deutsche Giganetz.

No no I have a LTE modem (PPP) that was also requesting a dhcpv6 address. I have disabled that to not mix up the logs.  I am a poor Deutsche Glasfaser customer 

[itn3rd77]

you reverted dhcp6c to 24.7.1 version (dhcp6c-20240710) and installed another newer one with pkg-add later.
Did you test in-between (and rebooted)?

Please test with dhcp6c-20240710 again as it seems you did some changes to the interfaces in between

Also please note that IPv6 DHCP on Deutsche Glasfaser takes 30-60 minutes depending on if you miss the Advertisement

Thanks for jumping in CruxtheNinth. I testet in between with a reboot. After that I  switched back to bare 24.7.2 and than added the newer one with pkg-add. So currently I am on 24.7.2 with the debug package from Franco.

[CruxtheNinth]

so with this constellation (and your disabled PPP interface, reboots etc)

opnsense-revert -r 24.7.1 dhcp6c
opnsense-update -zkr 24.7.2-nd

even after 1 hour+, you did not receive a Prefix? What about "Use IPv4 connectivity" - in my case that must be DISABLED otherwise it does not work at all for me.

curious how many different topologies Deutsche Glasfaser has and issues they seem to trigger

EDIT: the reason i am asking so specifically is that, while its fine and great that you want to provide logs with the debug version that Franco shared, if even the supposed to be working combination (24.7.1 dhcp6c + 24.7.2-nd kernel) fails in your case that it may be a totally different issue

[lp24db]

For more confusing: i actually have "Use IPv4 connectivity" enabled (since start of DGF) . For me it works fine with the special-kernel and the older dhcp6c

opnsense-revert -r 24.7.1 dhcp6c
opnsense-update -zkr 24.7.2-nd

even after 1 hour+, you did not receive a Prefix? What about "Use IPv4 connectivity" - in my case that must be DISABLED otherwise it does not work at all for me.

[CruxtheNinth]

i am wondering why this should even be activated. Maybe this is from when DG was using PPPoE at one point? did they even ever? in case native DHCP is supported it should not be needed at all

@Ip24db: did you ever test without it, just wondering what would happen if you disable it (just curious)

For more confusing: i actually have "Use IPv4 connectivity" enabled (since start of DGF) . For me it works fine with the special-kernel and the older dhcp6c

opnsense-revert -r 24.7.1 dhcp6c
opnsense-update -zkr 24.7.2-nd

even after 1 hour+, you did not receive a Prefix? What about "Use IPv4 connectivity" - in my case that must be DISABLED otherwise it does not work at all for me.

[franco]

When not using PPP(oE) the IPv4 connectivity toggle serialises the IPv6 after IPv4. But what that means in practice is that it likely just fixes a glitch in the dhcp6c by starting it a tiny bit later.

Well, it does the same in PPP(oE) but it wasn't meant to be operable without PPP(oE) but it hasn't been put in the GUI this way unfortunately.


Cheers,
Franco

[lp24db]

Just to complete the discussion:

Removing UseIPv4Connectivity causes a delay while retrieving the ipv6 addresses / prefixes on my setup. With this option set, the adresses appear in less time. Like <1min with and up to 3-4min without.

i am wondering why this should even be activated. Maybe this is from when DG was using PPPoE at one point? did they even ever? in case native DHCP is supported it should not be needed at all

@Ip24db: did you ever test without it, just wondering what would happen if you disable it (just curious)

For more confusing: i actually have "Use IPv4 connectivity" enabled (since start of DGF) . For me it works fine with the special-kernel and the older dhcp6c

opnsense-revert -r 24.7.1 dhcp6c
opnsense-update -zkr 24.7.2-nd

even after 1 hour+, you did not receive a Prefix? What about "Use IPv4 connectivity" - in my case that must be DISABLED otherwise it does not work at all for me.

[franco]

Yes, it seems a bit like the ISP expects this to happen (IPv6 after IPv4). I remember at least one case where the ISP never sent another RA as soon as DHCPv6 was up, too. It's so hard to get all of this under a shared code base without an array of advanced toggles. oO


Cheers,
Franco

[newsense]

Either toggles or a drop down menu allowing the user to select their particular ISP that needs a certain set of tweaks to work properly when the default options are not enough - wouldn't be such a bad idea ?

Should also improve the clarity in the reports:

a) I'm using ISP ABC with Default IPv6 settings - doesn't work - but choosing problematic ISP2 from the list fixes things for me

b) I'm using ISP DEF - doesn't work with any of the options


Just an idea, usnsure if feasible...

[CruxtheNinth]

on a global scale, for all possible ISP / Access combinations, not feasible.
A user/group maintained repo with config options, maybe.

The problem we see here already is that, e.g Deutsche Glasfaser, seems to have deviating configurations depending on the (*PON) Region you are in.

I would go so far and say that thankfully it is not the majority of ISPs that play against standard, like DG ignoring RA solicits or weird 6rd implementations. So its probably enough to keep track of the exotic variants and even for these its the minority of users that uses a 3rd party firewall / router instead of the ISP issued ones.

Either toggles or a drop down menu allowing the user to select their particular ISP that needs a certain set of tweaks to work properly when the default options are not enough - wouldn't be such a bad idea ?

Should also improve the clarity in the reports:

a) I'm using ISP ABC with Default IPv6 settings - doesn't work - but choosing problematic ISP2 from the list fixes things for me

b) I'm using ISP DEF - doesn't work with any of the options


Just an idea, usnsure if feasible...

[CruxtheNinth]

Quick reply for 24.7.3_1, all packages default, release kernel.

Updated System:

- Directly after reboot IA_NA almost instantly received; /128 shown on igc0 WAN
- few minutes later IA_PD received but no default route yet (as DG will not reply to RA Solicits) - /64 on igc1 LAN visible
- 10 minutes later, default route received but Prefix and Network Address are gone. tried restarting wan interface, no effect, same as above.
- > opnsense-revert -r 24.7.1 dhcp6c & reboot
- Directly after reboot  IA_NA & IA_PD visible, no gateway yet
- 10 minutes later, default route received, all green. Prefix and Network Address are still there.

i am staying with dhcp6c-20240710 for now



system latest.log attached. Upgrade reboot was approx 07:13 today, 2nd reboot was after downgrading
i took some pcaps during the problem, in case they are also needed.

[franco]

Given that all the other ICMPv6 shenanigans were ongoing for the last couple of weeks I couldn't look into it more yet.

I've had my IPv6 broken the last couple of days because the FritzBox insistent on NoPrefixAvail for a few times my main system tried to renew and it has been dead in the water since then as far as IPv6 was concerned. The whole protocol sucks IMO, because eventually attempts to recovery always seem to fail when something doesn't go right all the time, which is more often than not. Note this is completely unrelated to the problem at hand, but also a reason why have almost a week of missing log data to sift through.

Instead of guessing what made dhcp6c regress we should probably bisect to be sure. At this point to me it's a bit unclear what caused this change in behaviour and why it only manifests with DG.

I'll publish a new test version shortly.


Cheers,
Franco

[franco]

good: v20240710, bad v20240820

Bisecting: 7 revisions left to test after this (roughly 3 steps)
[ba9cddfcb6e568a5c83775ed0c917a316acb64db] dhcp6c: fix prototype

# pkg add -f https://pkg.opnsense.org/FreeBSD:14:amd64/snapshots/misc/dhcp6c-20240820_1.pkg

[meyergru]

@CruxtheNinth: It now seems obvious that DG has different PON setups in different areas. My 3 installations are all in Lower-Saxony and are based on Nokia equipment. Just for the fun of it: I have read that DG also uses Genexis ONTs, is that what you have?