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/>
I would try this first on 24.7.3:
# opnsense-revert -r 24.7.1 dhcp6c
(needs reboot)
Cheers,
Franco
same
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
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 (https://github.com/opnsense/core/blob/9f4331424699cce931418d7cb97e4e60f9afc51d/src/etc/inc/filter.lib.inc#L360-L369) has prio=1, while the bogonsv6 rule (https://github.com/opnsense/core/blob/9f4331424699cce931418d7cb97e4e60f9afc51d/src/etc/inc/filter.lib.inc#L320-L327) 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.
Unless the DHCPv6 rule is not in place or not matching, but LL to LL looks normal to me. And since it's UDP ICMP patches wouldn't really matter.
Here is the ultimate revert kernel
https://github.com/opnsense/src/issues/218#issuecomment-2321096627
to test your theory. Otherwise this is a configuration issue perhaps.
Cheers,
Franco
Now, I spotted this line...
https://github.com/opnsense/src/commit/164bfe67604#diff-efb487014794d10f6658bf2252b545ad5d64469bd0bc9dbde25dfab3a9b0ab9cR6488
Not so entirely sure about UDP being unrelated to ICMP any more. :o ???
(My brain is dead, someone else please read the surrounding code.)
TGIF.
For more amusement, try git blame on that line. ;D
IPv6 Prefix delegation is working fine for me. Standard configuration using track interface. Send prefix hit only. Comcast is my ISP for home and business.
Opnsense screenshot: https://imgur.com/a/UswlxyF
2 delegated prefixes. IPv6 connectivity (LAN and WAN) works as well. OP's issue might be related to his configuration or ISP. My setup isn't fancy at all. It's a standard configuration.
Quote
That said, I'd disable it altogether and never look at that checkbox again.
Ok. Will do. As you said, the rules created automatically look good and this should not happen logically.
Quote
2 delegated prefixes. IPv6 connectivity (LAN and WAN) works as well. OP's issue might be related to his configuration or ISP. My setup isn't fancy at all. It's a standard configuration.
As mentioned in my first post the config is equal to before the upgrad and working since years with the same ISP. This is definitly no ISP problem and related to the update.
Quote
Here is the ultimate revert kernel
https://github.com/opnsense/src/issues/218#issuecomment-2321096627
to test your theory. Otherwise this is a configuration issue perhaps.
Cheers,
Franco
Was this comment targeting my problem? How can I test / help tracking down the problem further (reverting dhcp6c didn't work).
On small difference in my configuration to standard: I am not using the default WAN interface but a custom created one (vlan) and it's parent (physical) interface is not assigned.
May there be hard coded things IPv6 related things nailed to the name "WAN" somewhere?
Best regards
Robert
As mentioned in another post (to which I received no answer), I have the same problem. IPv6 prefix delegation working for years. After upgrade to 24.7 the delgation only works for WAN and LAN, not for the further interfaces (all track WAN interface). Differently to imk82, I am using the default physical WAN interface, so it shouldn't be a WAN issue...
As I further mentioned in another post, I ticked "Allow manual adjustment of DHCPv6 and Router Advertisements" which before 24.7. allowed me to select a virtual Source Address for Router Advertisements. This option disappeared after the update and now only "automatic" is selectable.
UPDATE: It works, don't know why. After a while it worked again with 24.7.3_1. Further, as a change I had to modify my previously used CARP Address to fe80::192.168.2.1/64 reverting from fd00:: ... used previously. Now I can select the CARP interface for HA.
I must be missing all the wonderful use cases, using such boring tactics like having one track interface and setting up all the rest to be static.
QuoteI must be missing all the wonderful use cases, using such boring tactics like having one track interface and setting up all the rest to be static.
Just to keep topic of this thread focussed and for clarification:
- my problem starts already with the delegation of the prefix from my ISP to my "wan" (it is a custom one, not the on existing by default) interface
- I have one interface configured as tracking one, but since the prefix of the ISP is not delegated correctly, this is also no longer working
- my config and ISP has not changed since before 24.7.1
- since 24.7.1 my "wan" interface is not consuming a prefix from my ISP anymore
- reverting dhcp6c to pre 24.7 version is not fixing the problem
- if I get requirements how to I will help to track this down
Best regards
Robert
Hi all,
has someone maybe a good source or (simple) documentation for for the packets involved in which order when a prefix delegation is done between DHCP client and server?
To bring things forward, I want to try to capture packets on my "WAN" interface and have a look where things stop. But I need a reference what is the "correct" flow
Thanks and best regards
Robert
What's odd here is the claim that 24.7.1 is the bad version, when in reality only 24.7.2 changed dhcp6c and there is something weird going on there (see other thread). Sure, 24.7.1 introduced other problems, but the triage here just doesn't feel consistent.
As far as packet captures go that's pretty useless since we need to know what dhcp6c does. Enable debug under System: Interfaces: Settings and reboot. The dhcp6c logs tell us about all the communication that is being done (and why) and in most cases where a prefix is missing the server will likely not have sent it in the first place.
Cheers,
Franco
Quote from: franco on September 05, 2024, 09:15:44 AM
What's odd here is the claim that 24.7.1 is the bad version, when in reality only 24.7.2 changed dhcp6c and there is something weird going on there (see other thread). Sure, 24.7.1 introduced other problems, but the triage here just doesn't feel consistent.
As far as packet captures go that's pretty useless since we need to know what dhcp6c does. Enable debug under System: Interfaces: Settings and reboot. The dhcp6c logs tell us about all the communication that is being done (and why) and in most cases where a prefix is missing the server will likely not have sent it in the first place.
Cheers,
Franco
Hi Franco,
please find the requested log attached. As far as I can see there is a /56 prefix (I removed some parts of it, wasn't sure about privacy) occurring in the log, but later it says contains no prefix. Weird.
Do you have an idea how to go on?
Thanks and best regards
Robert
Hi Robert,
As I see it it's asking multiple times, also interrupted due to SIGHUP reconnect, getting multiple answers but eventually refusing to give out another prefix and that's where it stops as expected.
Seeing that PPPoE is involved I'd like to ask you to try the following:
https://forum.opnsense.org/index.php?topic=42081.msg211107#msg211107
I'm working on this at the moment anyway...
Cheers,
Franco
QuoteAs I see it it's asking multiple times, also interrupted due to SIGHUP reconnect, getting multiple answers but eventually refusing to give out another prefix and that's where it stops as expected.
Do you have a idea or at least a speculation what causes this? I mean, as written in the OP, ISP is the same and it worked before. As well with PPPoE and IPv6 together.
Maybe really some hidden magic which is bound to the interface name "wan"? Thats the only config change I've done as far as I can see.
QuoteSeeing that PPPoE is involved I'd like to ask you to try the following:
Ok, will check tomorrow if this is applicable.
A simple "opnsense-patch 6b28dae2" should be enough?
How likely is this to break stuff or being irreversible?
Best regards
Robert
> Do you have a idea or at least a speculation what causes this? I mean, as written in the OP, ISP is the same and it worked before. As well with PPPoE and IPv6 together.
Most of this revolves around timing issues: PPP being a bit less reliable due to extra software in between (mpd5), dhcp6c code changes causing IPv4 and IPv6 sequence mismatches, additional use of Netmap (suricata and zenarmor) or modem interaction on the plugged WAN link.
6b28dae2 tries to address some of these issues by moving IPv6 setup to PPP linkup time, not generic IPv4 renewal time (which is called much more often).
6b28dae2 should be safe enough, you can run the patch command again and it will be removed. the patch is also cached so it's easy to recover from no connectivity due to patches. But this patch has been extensively tested so I don't think it would be worse than before.
Cheers,
Franco
Quote from: franco on September 05, 2024, 10:02:16 PM
> Do you have a idea or at least a speculation what causes this? I mean, as written in the OP, ISP is the same and it worked before. As well with PPPoE and IPv6 together.
Most of this revolves around timing issues: PPP being a bit less reliable due to extra software in between (mpd5), dhcp6c code changes causing IPv4 and IPv6 sequence mismatches, additional use of Netmap (suricata and zenarmor) or modem interaction on the plugged WAN link.
6b28dae2 tries to address some of these issues by moving IPv6 setup to PPP linkup time, not generic IPv4 renewal time (which is called much more often).
6b28dae2 should be safe enough, you can run the patch command again and it will be removed. the patch is also cached so it's easy to recover from no connectivity due to patches. But this patch has been extensively tested so I don't think it would be worse than before.
Cheers,
Franco
Hi Franco,
unfortunatley a "opnsense-patch 6b28dae2" did not fix the problem. See attached dhcp6c log.
Not sure if it is worth mentioning, but my "wan" interface is getting a IPv6 address, just the PD part is broken.
Best regards
Robert
Hi Franco,
really stupid question and asked if at another point this thread already, but all I try to do should work with a which is not the original wan (mine is a custom created new interface, not ootb wan), right?
Just asking because I scrolled a little bit through the changed files in your commit and e.g. here:
https://github.com/opnsense/core/blob/6b28dae26cbadb9d25708685f590ee9af0506678/src/etc/inc/interfaces.inc#L2238
is a hard coded reference to "wan" and later this is used via "$wancfg".
But really didn't looked trough the whole code flow but stumbled over it and the question came up again for me.
Best regards
Robert
Hi Robert,
This is only the default value, but in all honestly it's a historic artefact and not even used anymore. The interface name is always passed.
I think we figured out the mix of commits that caused dhcp6c to regress the way it did in 24.7.2:
# pkg add -f https://pkg.opnsense.org/FreeBSD:14:amd64/snapshots/misc/dhcp6c-20240907.pkg
This will be in 24.7.4. Worth a test, but needs a reboot to activate.
Cheers,
Franco
Hi Franco,
QuoteThis is only the default value, but in all honestly it's a historic artefact and not even used anymore. The interface name is always passed.
This is purely a interpreted languange without compiling or poat processing build steps to check method calls against the existing signatures, right? So no chance to just remove the default without risk of breaking stuff.
QuoteI think we figured out the mix of commits that caused dhcp6c to regress the way it did in 24.7.2:
# pkg add -f https://pkg.opnsense.org/FreeBSD:14:amd64/snapshots/misc/dhcp6c-20240907.pkg
This will be in 24.7.4. Worth a test, but needs a reboot to activate.
Can I apply this with opnsense-patch somehow and is this different from the previous opnsense-patch 6b28dae2 82ea39b04c?
Or makes it just sense to wait for 24.7.4?
Thanks again and best regards
Robert
Quote from: imk82 on September 09, 2024, 06:53:02 PM
Can I apply this with opnsense-patch somehow
Nah. You can apply it with the command already posted:
# pkg add -f https://pkg.opnsense.org/FreeBSD:14:amd64/snapshots/misc/dhcp6c-20240907.pkg
> This is purely a interpreted languange without compiling or poat processing build steps to check method calls against the existing signatures, right? So no chance to just remove the default without risk of breaking stuff.
The default argument could and will be removed, but better done in batch while working on nothing related, which is currently not possible.
Cheers,
Franco
Quote
Can I apply this with opnsense-patch somehow
Nah. You can apply it with the command already posted:
# pkg add -f https://pkg.opnsense.org/FreeBSD:14:amd64/snapshots/misc/dhcp6c-20240907.pkg
Hi all,
how can I revert this to the production version? Is a
opnsense-revert dhcp6cenough to do so?
Sorry, havn't that much experience in that direction and it is a quite productive system.:-)
Best regards
Robert
Yes:
# opnsense-revert dhcp6c
This reverts the dhcp6c package to the last know release version (24.7.3 today).
Cheers,
Franco
PS: The version you tested is going to be tomorrow's release version in 24.7.4 anyway.
Quote from: franco on September 11, 2024, 10:01:01 AM
PS: The version you tested is going to be tomorrow's release version in 24.7.4 anyway.
Hi Franco,
tried again with 24.7.4. Unfortunately I still get no prefix delegated on my "wan" interface. I send a /56 prefix hint and use the IPv4 connectivity on the interface tagged with vlan 7. As all the years before.
I've attached the log again. Still no specialist in that topic, but I think the pattern of the log changed somewhat since 24.7.3. It repeats steps and contains multiple times a clear
create a prefix 2003:c3:xxxx:xxxx::/56But later stopping with it and then a
advertise contains no address/prefixDo you have another idea what to check?
Thanks and best regards
Robert
Hi Robert,
I think here is what could be the problem:
2024-09-18T13:39:22 Notice dhcp6c Sending Solicit
2024-09-18T13:39:22 Notice dhcp6c got an expected reply, sleeping.
2024-09-18T13:39:22 Notice dhcp6c script "/var/etc/dhcp6c_opt8_script.sh" terminated
2024-09-18T13:39:22 Notice dhcp6c dhcp6c_script: REQUEST on pppoe1 renewal
2024-09-18T13:39:22 Notice dhcp6c dhcp6c_script: REQUEST on pppoe1 executing
2024-09-18T13:39:22 Notice dhcp6c executes /var/etc/dhcp6c_opt8_script.sh
2024-09-18T13:39:22 Notice dhcp6c removing server (ID: 00:02:00:00:05:83:32:38:3a:38:61:3a:31:63:3a:36:35:3a:39:66:3a:63:30:00:00:00)
2024-09-18T13:39:22 Notice dhcp6c removing an event on pppoe1, state=REQUEST
2024-09-18T13:39:22 Notice dhcp6c reset a timer on pppoe1, state=INIT, timeo=0, retrans=557
2024-09-18T13:39:22 Notice dhcp6c remove an IA: NA-9
2024-09-18T13:39:22 Notice dhcp6c IA NA-9 is invalidated
2024-09-18T13:39:22 Notice dhcp6c status code for NA-9: no addresses
2024-09-18T13:39:22 Notice dhcp6c make an IA: NA-9
2024-09-18T13:39:22 Notice dhcp6c create a prefix 2003:c3:xxxx:xxxx::/56 pltime=86400, vltime=86400
2024-09-18T13:39:22 Notice dhcp6c make an IA: PD-9
2024-09-18T13:39:22 Notice dhcp6c nameserver[1] 2003:180:2::53
2024-09-18T13:39:22 Notice dhcp6c nameserver[0] 2003:180:2:6000::53
2024-09-18T13:39:22 Notice dhcp6c Received REPLY for REQUEST
2024-09-18T13:39:22 Notice dhcp6c get DHCP option DNS, len 32
2024-09-18T13:39:22 Notice dhcp6c IA_PD prefix: 2003:c3:xxxx:xxxx::/56 pltime=86400 vltime=86400
2024-09-18T13:39:22 Notice dhcp6c get DHCP option IA_PD prefix, len 25
2024-09-18T13:39:22 Notice dhcp6c IA_PD: ID=9, T1=43200, T2=69120
2024-09-18T13:39:22 Notice dhcp6c get DHCP option IA_PD, len 41
2024-09-18T13:39:22 Notice dhcp6c status code: no addresses
2024-09-18T13:39:22 Notice dhcp6c get DHCP option status code, len 43
2024-09-18T13:39:22 Notice dhcp6c IA_NA: ID=9, T1=0, T2=0
2024-09-18T13:39:22 Notice dhcp6c get DHCP option identity association, len 59
2024-09-18T13:39:22 Notice dhcp6c DUID: 00:02:00:00:05:83:32:38:3a:38:61:3a:31:63:3a:36:35:3a:39:66:3a:63:30:00:00:00
2024-09-18T13:39:22 Notice dhcp6c get DHCP option server ID, len 26
2024-09-18T13:39:22 Notice dhcp6c DUID: 00:01:00:01:2d:a2:0e:6f:00:d0:b4:02:1d:fa
2024-09-18T13:39:22 Notice dhcp6c get DHCP option client ID, len 14
2024-09-18T13:39:22 Notice dhcp6c receive reply from fe80::2a8a:1cff:fe65:99f6%pppoe1 on pppoe1
So you can see you get a prefix, but the zero lifetime NA causes the client to time out and discard everything at the same time.
Do you have "Request only a prefix" unset? It would be better to set this option if that's the case. If it's already set we need to try and ignore this zero lifetime NA that doesn't even provide an address.
To me it looks like a server quirk to be honest.
Cheers,
Franco
Hi Franco,
QuoteDo you have "Request only a prefix" unset? It would be better to set this option if that's the case. If it's already set we need to try and ignore this zero lifetime NA that doesn't even provide an address.
Yes, this was unchecked. Never checked this the years before and it always worked. Nevertheless, gave it a try but without success (see attached log).
QuoteTo me it looks like a server quirk to be honest.
If we follow this theory, then something must have triggered this server problem on the OPNsense side since 24.7.x. Before I always had IPv6 in use and no problems.
For mit it looks like all is fine, but it just isn't working and getting a prefix. Weird.
One small thing I changed with the migration to 24.7.x is, that OPNsense is now setting the Vlan ID (7) instead of the modem internally (that was the case before). But I cannot imagine how this can lead to the problem, IPv4 is working fine and I even get a IPv6 address for the "wan interface", just the prefix is not delegated.
Best regards
Robert
Robert,
As per my earlier comments I wrote this patch to try https://github.com/opnsense/dhcp6c/commit/d2e5fb474f
# pkg add -f https://pkg.opnsense.org/FreeBSD:14:amd64/snapshots/misc/dhcp6c-20240907_3.pkg
Reboot to see if it helps.
Thanks,
Franco
Quote from: franco on September 19, 2024, 06:25:33 PM
Do you have "Request only a prefix" unset? It would be better to set this option if that's the case. If it's already set we need to try and ignore this zero lifetime NA that doesn't even provide an address.
I don't know how similar this issue is to mine but setting this does actually give me a prefix. I will play around with this some more, but it seems promising so far. I will also try the new dhcp6c patch. I am available to test theories if you want.
Quote from: franco on September 22, 2024, 12:32:22 AM
Robert,
As per my earlier comments I wrote this patch to try https://github.com/opnsense/dhcp6c/commit/d2e5fb474f
# pkg add -f https://pkg.opnsense.org/FreeBSD:14:amd64/snapshots/misc/dhcp6c-20240907_3.pkg
Reboot to see if it helps.
Thanks,
Franco
It seems to have completely fixed my case. A prefix, (with an address for the interface itself) is picked up immediately, similar to pre 24.7.4. If you want anything else tested, I will probably be available.
Quote from: imk82 on September 18, 2024, 01:50:41 PM
Still no specialist in that topic, but I think the pattern of the log changed somewhat since 24.7.3.
To be frank more than enough people report such very particular issue we've never had before specifically at this time in the way the protocol works during the request itself that I doubt this is something a firewall would interfere with on such a fine-grained specific level... which leads me to believe some specific server software for DHCPv6 got updated and now exhibits this behaviour (no clue if intentionally or due to a bug).
I mean we can fix the bug in the client, but we also have to consider the client was able to handle this for a very long time already.
Quote from: REB00T on September 22, 2024, 02:22:24 AM
It seems to have completely fixed my case. A prefix, (with an address for the interface itself) is picked up immediately, similar to pre 24.7.4. If you want anything else tested, I will probably be available.
That sounds interesting. While at this and your topic in particular I also think that it may be practical to move the PPP log to the system log because we do seem to miss correlation between the two an it's hard to infer what PPP(oE) did while we look for clues in the main log file doing things that we don't know why and when triggered.
The dhcp6c patch will not be in 24.7.5. I've made that mistake before adding too many things in one release before. But we can definitely make 25.7.6 with good feedback on Robert's side. Otherwise we may have to tweak it more.
Cheers,
Franco
Quote
Robert,
As per my earlier comments I wrote this patch to try https://github.com/opnsense/dhcp6c/commit/d2e5fb474f
# pkg add -f https://pkg.opnsense.org/FreeBSD:14:amd64/snapshots/misc/dhcp6c-20240907_3.pkg
Reboot to see if it helps.
Thanks,
Franco
Hi Franco,
is this still true for 24.7.5 or will things break if I apply the patch/install the package? Or in the other direction, needa the patch/package a adaption for 24.7.5 before trying it?
And should I install one by one and check the effect or both together?
Can do this now, my box has not that much critical traffic this weekend.
Best regards
Robert
Hi Robert,
Sorry for the response delay. It's still true but the package moved to a new rebuild (but holds the same source code as discussed):
# pkg add -f https://pkg.opnsense.org/FreeBSD:14:amd64/snapshots/misc/dhcp6c-20240919_1.pkg
Just update to 24.7.5 and see how that goes as a separate data point. Then install the updated client and reboot again to see if that changes things.
Cheers,
Franco
Quote from: franco on September 30, 2024, 08:02:58 AM
Hi Robert,
Sorry for the response delay. It's still true but the package moved to a new rebuild (but holds the same source code as discussed):
# pkg add -f https://pkg.opnsense.org/FreeBSD:14:amd64/snapshots/misc/dhcp6c-20240919_1.pkg
Just update to 24.7.5 and see how that goes as a separate data point. Then install the updated client and reboot again to see if that changes things.
Cheers,
Franco
Hi Franco,
good and bad news.
Did another series of tests to track this down further. Just as a recap, my setup is:
* OPNSense setting vlan7 (necessary for my provider Deutsche Telekom) and doing PPPoE dialing
* Modem directly connected to the OPNSense Box not setting a vlan7
1. installed 24.7.5 -> not working (see attached log)
2. installed patched dhcp6c client on top of 24.7.5 -> not working (see attached log)
3. connected a OpenWRT box in the exact way to the modem as the OPNSense box and let it set vlan 7 -> working
4. reconfigured OPNSense to NOT set the vlan (using the underlying interface directly) and let the modem set the vlan -> working (can provide log if needed, forgot to collect)
Based on this there are three new data points:
* it is no longer sure, that the problem was introduced with 24.x.x (I doubt so). But I reconfigured the vlan thing at the same time (mentioned it in earlier posts already)
* it is no provider side issue
* there is a problem with OPNSense and IPv6 PD when it is based on a vlan instead directly at the physical interface
What do you think how we should go on here, is there anything I can test for you?
I think a bug in the dhcp6 client is not longer likely, more one deeper in the network stack?
Best regards
Robert
Could my problem be related to this topic? One of my opnsense boxes has erratic behavior since 24.7.x . Managed radvd stopped working but when I switch to Assisted, only hosts that don't have a static reservation are getting an IP (slaac i think).
Another opnsense box in a different location but on the same ISP and with almost the same settings doesn't have this issue.
i am on 24.7.6 and the ipv6 doesn't seem to work correctly after a while (after the WAN connect is reset)
everytime i see the following logs , the ipv6 connection on the network stop working.
2024-10-10T10:00:13 Notice dhcp6c XID mismatch
2024-10-10T10:00:13 Notice dhcp6c get DHCP option domain search list, len 15
2024-10-10T10:00:13 Notice dhcp6c get DHCP option DNS, len 32
2024-10-10T10:00:13 Notice dhcp6c IA_PD prefix: 2406:3400:410:9d80::/60 pltime=604800 vltime=604800
2024-10-10T10:00:13 Notice dhcp6c get DHCP option IA_PD prefix, len 25
2024-10-10T10:00:13 Notice dhcp6c IA_PD: ID=0, T1=302400, T2=483840
2024-10-10T10:00:13 Notice dhcp6c get DHCP option IA_PD, len 41
2024-10-10T10:00:13 Notice dhcp6c DUID: 00:01:00:01:2b:80:15:fe:28:b1:33:00:8c:89
2024-10-10T10:00:13 Notice dhcp6c get DHCP option client ID, len 14
2024-10-10T10:00:13 Notice dhcp6c DUID: 00:03:00:01:88:1d:fc:68:3a:00
2024-10-10T10:00:13 Notice dhcp6c get DHCP option server ID, len 10
2024-10-10T10:00:13 Notice dhcp6c receive advertise from fe80::8a1d:fcff:fe68:3a00%pppoe0 on pppoe0
2024-10-10T10:00:13 Notice dhcp6c reset a timer on pppoe0, state=SOLICIT, timeo=13, retrans=3712916
2024-10-10T10:00:13 Notice dhcp6c send solicit to ff02::1:2%pppoe0
2024-10-10T10:00:13 Notice dhcp6c set IA_PD
2024-10-10T10:00:13 Notice dhcp6c set option request (len 4)
2024-10-10T10:00:13 Notice dhcp6c set elapsed time (len 2)
2024-10-10T10:00:13 Notice dhcp6c set client ID (len 14)
2024-10-10T10:00:13 Notice dhcp6c Sending Solicit
I have the 'get prefix only' option checked and i am using NPTv6 as well
I reverted dhcp6c back to v20240919 and everything is working flawlessly again... :|
Hi,
I also encounter weird behavior with IPv6 since september
Unfortunately my technical knowledge's very limited and english not my primary language but i will try to report the problem.
I connect to my ISP with fiber link and PPPoE. He give me /48 and everything's good since 1,5+ years.
My settings in WAN interface:
type DHCPv6
Configuration mode basic
Use IPv4 connectivity check
Request prefix only check
Send prefix hint check
no optional ID or interface ID
(it has always worked with those settings)
The problem is the same with the 2 OPNsense boxes that I have (both connected to the same ISP, same settings, but different location)
WAN is getting IPv6 with gateway monitoring OK. But it seems PD broken because LAN (track interface mode) doesn't get IPv6 and so are the devices behind.
Tried various settings / multiple reboots / PPPoE reload nothing really seems to correct the problem and sometimes with no warning PD work LAN get it's delegation and everything work as intented and can stay for days like that (but since i'm always tinkering with my homelab i often reboot the OPNsense box and thus loose IPv6).
I do not like IPv4 and really prefer to use IPv6 everywhere I can.
Updated today to 24.7.6 same problem happen unfortunately
Please excuse my english
Regards
The same for me.
After a restart, DHCPv6 is stopped, no prefix delegation. At some point, out of nowhere, DHCPv6 and prefix delegation are running and all devices have IPv6 addresses. But this only lasts for a limited time, after a few hours the IPv6 disappears again. Restarting only leads to DHCPv6 being stopped again. Unfortunately, 24.7.6 has not changed this.
Same to me.
I ve updatet opnsense from 24.7.4_1 to 24.7.6.
Now Im getting the problem no ipv6 Prefix.
It took me hours, now I see this post.
I will try to get to 24.7.4 back or is there a bugfix??
Greets
Byte
Checking in, updated to 24.7.6 on Friday 10/18 and my prefix doesn't 'stick' longer than an hour or so after renewing my lease. Re-renewing my lease on WAN fixes it briefly, but it will inevitably go back down. ISP says my lease is not getting claimed. XID Mismatch is present in the logs and seems to correlate with IPv6 going down.
Reverting kernel and opnsense to 24.7.4. Will update if that does not fix my issue. Looking forward to a fix.
Hi,
is the prefix delegatoin issue fixed on 24.7.7?
Has someone test it?
Greets
Hi,
the error still exists!
I get no ipv6 over delegation from my fritzbox!
Whe I downgrade, it works fine!
@franco: Is there a chance that the error will be repaired soon?
My last working OPNSense ist V 24.7.5_3
Greets
Issue persist with 24.7.8 with erratic IPv6 prefix avaibility
Not sure if this is 100% related but I'm also such with 24.7.5_3 because this is the last version that works with IPv6 for me. Somehow I never get a correct IPv6 gateway with > 24.7.5_3. I suspect it is related to some changes in dhcp6c since a newer version was released with 24.7.6. I didn't have time to look closer at the issue so far unfortunately.
I am very certain the breakage is introduced by this code.
https://github.com/opnsense/dhcp6c/compare/v20240919...v20241008
I gonna do this revert (back to 0919 release) as long as there is no newer release (newer than 1008)from the dhcp6c.
opnsense-revert -r 24.7.5 dhcp6c # take you back to dhcp6c 0919 version
Well if you see any of those messages in the log and then it stops then maybe. If you don't see the log messages code that isn't executed is likely not the issue. Every change was confirmed by the respective reporter, too. It feels like playing whac-a-mole: fix one provider break another, but then again it has always been this way.
I still think the random number changes are the culprit (from "random" static to actually random as per RFC), but for the right reasons and not the wrong ones. If anyone wants to poke at this be my guest. Most I have seen is ISPs not repying meaning that they probably don't like the timings which is unfortunate but impossible to debug from the client side.
Cheers,
Franco
Quote from: lostcontrol on November 07, 2024, 10:18:10 PM
Not sure if this is 100% related but I'm also such with 24.7.5_3 because this is the last version that works with IPv6 for me. Somehow I never get a correct IPv6 gateway with > 24.7.5_3. I suspect it is related to some changes in dhcp6c since a newer version was released with 24.7.6. I didn't have time to look closer at the issue so far unfortunately.
I took some time to look into my issue. I reverted dhcp6c as proposed but this didn't change the problem for me. Doing some googling, I realized that the default gateway setting is not propagated via DHCPv6 but RA. I checked for RA using
tcpdump and noticed that I got some from
fe80::c28c:8802:a581:8b62 which was the gateway OPNsense used when my IPv6 connectivity was broken. Looking at the NDP I noticed that the corresponding MAC address was the one of... my Draytek DSL modem :o The modem is configured in bridge mode and somehow sent RA to the router!? RA from my ISP somehow didn't make it through with > 24.7.5_3!? Long story short, I disabled IPv6 on the Draytek modem, reverted to my 24.7.8 snapshot and tada... IPv6 works :)
I will be migrated to FTTH next month so this would have solved itself eventually but I learned a lot by debugging this.