IPv6 prefix delegation not working with 24.7.1-.3

Started by imk82, August 30, 2024, 10:23:00 AM

Previous topic - Next topic
Hi all,

since I upgraded to 24.7.1, .2 and yesterday .3 I am no longer able to get a IPv6 prefix delegated by my ISP.

Background is, that the former worked with earlier versions (except 24.7.0, never tried that). My configuration didn't change nor did the ISP or the used line. I use PPPoE to connect.

I compared the XML configurations of my 23.x.x backups with the the current ones, and it looks the same for me (see below). I check use IPv4 connectivity, prefix length of 56 and send prefix hint. Exactly what worked before.

IPv4 PPPoE connection is working flawless, only IPv6 is weird.

Side note: the interface itself seems to get a IPv6 address from my ISP (2003:c3:.../64 ), but the prefix delegation is broken on since 24.7.1

Can someone help me here, did I miss some mandatory config migration or similar?

Thanks and best regards
Robert

23.x.x:

<if>pppoe0</if>
<descr>TELEKOM_PPPOE</descr>
<enable>1</enable>
<lock>1</lock>
<spoofmac/>
<blockbogons>1</blockbogons>
<ipaddr>pppoe</ipaddr>
<ipaddrv6>dhcp6</ipaddrv6>
<dhcp6-ia-pd-len>8</dhcp6-ia-pd-len>
<dhcp6-ia-pd-send-hint>1</dhcp6-ia-pd-send-hint>
<dhcp6usev4iface>1</dhcp6usev4iface>
<adv_dhcp6_interface_statement_send_options/>
<adv_dhcp6_interface_statement_request_options/>
<adv_dhcp6_interface_statement_information_only_enable/>
<adv_dhcp6_interface_statement_script/>
<adv_dhcp6_id_assoc_statement_address_enable/>
<adv_dhcp6_id_assoc_statement_address/>
<adv_dhcp6_id_assoc_statement_address_id/>
<adv_dhcp6_id_assoc_statement_address_pltime/>
<adv_dhcp6_id_assoc_statement_address_vltime/>
<adv_dhcp6_id_assoc_statement_prefix_enable/>
<adv_dhcp6_id_assoc_statement_prefix/>
<adv_dhcp6_id_assoc_statement_prefix_id/>
<adv_dhcp6_id_assoc_statement_prefix_pltime/>
<adv_dhcp6_id_assoc_statement_prefix_vltime/>
<adv_dhcp6_prefix_interface_statement_sla_len/>
<adv_dhcp6_authentication_statement_authname/>
<adv_dhcp6_authentication_statement_protocol/>
<adv_dhcp6_authentication_statement_algorithm/>
<adv_dhcp6_authentication_statement_rdm/>
<adv_dhcp6_key_info_statement_keyname/>
<adv_dhcp6_key_info_statement_realm/>
<adv_dhcp6_key_info_statement_keyid/>
<adv_dhcp6_key_info_statement_secret/>
<adv_dhcp6_key_info_statement_expire/>
<adv_dhcp6_config_advanced/>
<adv_dhcp6_config_file_override/>
<adv_dhcp6_config_file_override_path/>


24.7.3:

<if>pppoe0</if>
<descr>TELEKOM_PPPOE</descr>
<enable>1</enable>
<lock>1</lock>
<spoofmac/>
<blockbogons>1</blockbogons>
<ipaddr>pppoe</ipaddr>
<ipaddrv6>dhcp6</ipaddrv6>
<dhcp6-ia-pd-len>8</dhcp6-ia-pd-len>
<dhcp6-ia-pd-send-hint>1</dhcp6-ia-pd-send-hint>
<dhcp6usev4iface>1</dhcp6usev4iface>
<adv_dhcp6_interface_statement_send_options/>
<adv_dhcp6_interface_statement_request_options/>
<adv_dhcp6_interface_statement_information_only_enable/>
<adv_dhcp6_interface_statement_script/>
<adv_dhcp6_id_assoc_statement_address_enable/>
<adv_dhcp6_id_assoc_statement_address/>
<adv_dhcp6_id_assoc_statement_address_id/>
<adv_dhcp6_id_assoc_statement_address_pltime/>
<adv_dhcp6_id_assoc_statement_address_vltime/>
<adv_dhcp6_id_assoc_statement_prefix_enable/>
<adv_dhcp6_id_assoc_statement_prefix/>
<adv_dhcp6_id_assoc_statement_prefix_id/>
<adv_dhcp6_id_assoc_statement_prefix_pltime/>
<adv_dhcp6_id_assoc_statement_prefix_vltime/>
<adv_dhcp6_prefix_interface_statement_sla_len/>
<adv_dhcp6_authentication_statement_authname/>
<adv_dhcp6_authentication_statement_protocol/>
<adv_dhcp6_authentication_statement_algorithm/>
<adv_dhcp6_authentication_statement_rdm/>
<adv_dhcp6_key_info_statement_keyname/>
<adv_dhcp6_key_info_statement_realm/>
<adv_dhcp6_key_info_statement_keyid/>
<adv_dhcp6_key_info_statement_secret/>
<adv_dhcp6_key_info_statement_expire/>
<adv_dhcp6_config_advanced/>
<adv_dhcp6_config_file_override/>
<adv_dhcp6_config_file_override_path/>

August 30, 2024, 10:27:39 AM #1 Last Edit: August 30, 2024, 12:51:13 PM by franco
I would try this first on 24.7.3:

# opnsense-revert -r 24.7.1 dhcp6c

(needs reboot)


Cheers,
Franco


Quote from: franco on August 30, 2024, 10:27:39 AM
I would try this first on 24.7.3:

# opnsense-revert -r 23.7.1 dhcp6c

(needs reboot)

Cheers,
Franco

Quotesame

Hi,

ok. But, some questions:
* as far as I understand this resets dhcp6c package version to 23.7.1, is this correct?
* how "safe" is this in terms of breaking other dependencies (e.g. UI settings not existing in the backend application and so on)?
* how can I revert back to current release, just with a simple opnsense-revert 24.7.3?
* is there a upcoming fix planned if this is a know issue? No hurry, just asking if it makes sense to just wait some days / weeks?

Best regards
Robert

Hi Robert,

> * as far as I understand this resets dhcp6c package version to 23.7.1, is this correct?

Yes.

> * how "safe" is this in terms of breaking other dependencies (e.g. UI settings not existing in the backend application and so on)?

Very safe.

>  how can I revert back to current release, just with a simple opnsense-revert 24.7.3?

# man opnsense-revert

> * is there a upcoming fix planned if this is a know issue? No hurry, just asking if it makes sense to just wait some days / weeks?

I have no idea what the problem is. Since 24.7.1 and the FreeBSD SA patch all bets are off on baselining anything related to IPv6. What this needs is a bit of calming down first in 24.7.x. The smallest scope would be the fixes in dhcp6c causing other issues, but I doubt a bit that is a but that wasn't there before, just easier to trigger now.


Cheers,
Franco

Quote# man opnsense-revert
Done and understood.

Quoteroot@jupiter:~ # opnsense-revert -r 23.7.1 dhcp6c
Fetching dhcp6c.pkg: ....pgrep: Cannot open pidfile `/tmp/opnsense-fetch.pid.lowWZ6': No such file or directory
[fetch: https://pkg.opnsense.org/FreeBSD:14:amd64/24.7/MINT/23.7.1/latest/Latest/dhcp6c.pkg.sig: Not Found] failed

Is it necessary to select a special mirror for reverting to older version?

Sorry my brain needs a break from all of this... obviously:

# opnsense-revert -r 24.7.1 dhcp6c

August 30, 2024, 12:58:48 PM #7 Last Edit: August 30, 2024, 01:00:58 PM by imk82
Quote from: franco on August 30, 2024, 12:51:41 PM
Sorry my brain needs a break from all of this... obviously:

# opnsense-revert -r 24.7.1 dhcp6c

Ok. Will try.

But, logically, if this works there must be another bug beside dhcp6c in 24.7.1 preventing PD from working (because I used 24.7.1 without success) fixed in .2 or .3. And another one introduced in dhcp6c after .1 breaking PD from this side as well. Right? :-D

I am doing such stuff at work (software and system architecture / release management, development, branching, merging such stuff) and can really feel you pain in tracking such things down.

Best regards
Robert

Quote from: imk82 on August 30, 2024, 12:58:48 PM
there must be another bug beside dhcp6c in 24.7.1 preventing PD from working (because I used 24.7.1 without success) fixed in .2 or .3.

Yes, sure. This one: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701

Tens of mandays wasted on that nonsense with "stateful" ICMPv6 already.

Quote from: doktornotor on August 30, 2024, 01:04:07 PM
Quote from: imk82 on August 30, 2024, 12:58:48 PM
there must be another bug beside dhcp6c in 24.7.1 preventing PD from working (because I used 24.7.1 without success) fixed in .2 or .3.

Yes, sure. This one: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701

Tens of mandays wasted on that nonsense with "stateful" ICMPv6 already.

Ah, ok.

Reverted dhcp6c 24.7.1 without success. Still no PD working.

What I can tell, a little unsharp:
* when I capture packets on the PPPoE Interface for port 546, there are packets and they look like my ISP is sending a /56 prefix offer
* one or two times when trying to find out what goes wrong, I saw blocked packet in the firewall log (live view) with dst port 546. Weird here was, that there was no label (describing which rule caused the block) and it was not stable reproducable in terms of always visible wenn enabling / disabling IPv6 on the PPPoE interface

Best regards
Robert

Quote from: imk82 on August 30, 2024, 01:08:18 PM
* one or two times when trying to find out what goes wrong, I saw blocked packet in the firewall log (live view) with dst port 546. Weird here was, that there was no label (describing which rule caused the block) and it was not stable reproducable

Hmmm, sounds very much like the kernel mess to me. (Also considering 24.7.1 being completely broken for you and working much better in .[23])

Quote from: doktornotor on August 30, 2024, 01:13:28 PM
Quote from: imk82 on August 30, 2024, 01:08:18 PM
* one or two times when trying to find out what goes wrong, I saw blocked packet in the firewall log (live view) with dst port 546. Weird here was, that there was no label (describing which rule caused the block) and it was not stable reproducable

Hmmm, sounds very much like the kernel mess to me. (Also considering 24.7.1 being completely broken for you and working much better in .[23])

What is a fact is, that I never had problems with IPv6 PD before 24.7. Right.

I can provide further things if needed, after weekend. And with "this is a production system and my neighbors kill me when its down" in mind. :-)

Best regards
Robert

Yeah, I suggest you read https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701 in full to understand the level of issues we've had with this already ever since 24.7.1 came out. Structurally, technically and socially.

I'm even willing to back all of t his out again for 24.7.4 since I have now seen at least three independent reports of persistent problems introduced in 24.7.1 not fixed by 24.7.3. We don't know until we try. We tried. This is the reality of it apparently.


Cheers,
Franco

Tried to get a screenshot of the blocked DHCPv6 traffic, looks like the attached one.

Further, but I think not directly related and maybe a timing issue, I saw DHCPv6 traffic being blocked when bogon network blocking is enabled. See the other screenshots.

The thing is, it shouldn't be blocked even with that horrible bogonsv6 stuff enabled, because the DHCPv6 rule has prio=1, while the bogonsv6 rule has prio=5, the packets will normally get matched with the higher rule and the latter will not apply (quick rule).

That said, I'd disable it altogether and never look at that checkbox again.