Hello good people,
Mandatory disclaimer, english is not my first language, apologies for any mistakes I might make.
After updating to 24.1.9 (and subsequent hotfixes) and rebooting the system, I've been experiencing this bug(?)
On initial reload of the interface, it normally receives an address from the isp dhcpv6 server, but subsequent renew requests do not seem to renew the address on the interface. Prefix delegation from the isp dhcpv6 server works perfectly fine without issues just like before the update.
The isp dhcpv4 server gave me a different ipv4 address after the reboot, but everything regarding that seems to be working as usual. Pointing this out in case it could possibly have something to do with the problem I'm having.
Never had similar issues before, everything has been working perfectly before this. I'm at a loss on how to investigate the issue.
Apologies for not posting logs or other debug information as I'm not sure which would be useful in this context. Willing to provide any that might help when asked. Thank you for your patience
All help appreciated, thank you beforehand!
Hi,
We did incorporate a couple of Debian patches for dhcp6c into 24.1.9's version. One of those are actually supposed to fix this from stopping to work, but maybe you are experiencing the reverse?
https://github.com/opnsense/dhcp6c/commit/2e44fd3051
Maybe that patch is wrong ... or maybe we can start to see if dhcp6c in the older version is better again:
# opnsense-revert -r 24.1.8 dhcp6c
Best to reboot to avoid the newer dhcp6c from remaining the running process binary (it's mostly operated by SIGHUP).
Cheers,
Franco
Quote from: franco on June 20, 2024, 09:28:49 PM
Hi,
We did incorporate a couple of Debian patches for dhcp6c into 24.1.9's version. One of those are actually supposed to fix this from stopping to work, but maybe you are experiencing the reverse?
https://github.com/opnsense/dhcp6c/commit/2e44fd3051
Maybe that patch is wrong ... or maybe we can start to see if dhcp6c in the older version is better again:
# opnsense-revert -r 24.1.8 dhcp6c
Best to reboot to avoid the newer dhcp6c from remaining the running process binary (it's mostly operated by SIGHUP).
Cheers,
Franco
I see, very interesting. I wonder if it has something to do with the specific configuration on the isp's end or mine.
I'll try reverting, see if it fixes the issue. Should I report back when I know?
Thank you very much!
> I see, very interesting. I wonder if it has something to do with the specific configuration on the isp's end or mine.
Likely with the ISP, but that's just inherent with IPv6 delivery.
> I'll try reverting, see if it fixes the issue. Should I report back when I know?
Yes please in either case. Improving IPv6 is my hobby. ;)
Cheers,
Franco
Quote from: franco on June 20, 2024, 09:45:42 PM
> I see, very interesting. I wonder if it has something to do with the specific configuration on the isp's end or mine.
Likely with the ISP, but that's just inherent with IPv6 delivery.
> I'll try reverting, see if it fixes the issue. Should I report back when I know?
Yes please in either case. Improving IPv6 is my hobby. ;)
Cheers,
Franco
Hello again,
Okay, reverting seemed to go through successfully?
# opnsense-revert -r 24.1.8 dhcp6c
Fetching dhcp6c.pkg: ... done
Verifying signature with trusted certificate pkg.opnsense.org.20240105... done
dhcp6c-20240607: already unlocked
Installing dhcp6c-20230530...
package dhcp6c is already installed, forced install
Extracting dhcp6c-20230530: 100%After rebooting, the wan interface receives an address and a prefix normally. However unlike before, I'm getting a different address/prefix on every interface reload. However also other interfaces which are set to track the wan interface are not receiving ipv6 addresses now.
Trying to reload all services from opnsense-shell gets stuck on
setup <wan-interface> [egress only]Interesting turn of events. What to do?
Sounds like it is stuck initializing NetFlow on the interface? Maybe turning that off is already better...
You can always revert back to the latest version:
# opnsense-revert dhcp6c
But the problem description and change of problem description isn't very consistent here so something else might interfere.
Cheers,
Franco
I'm on 24.1.9_3 and am also seeing this behavior for my WAN IPv6, it loses its IPv6 lease a few hours after a reboot.
The LAN still maintains its IPv6 address and is still handing out working IPv6 leases to my LAN clients. Prior to 24.1.9 I used WAN Track interface and had solid IPv6 for years on my LAN and the WAN interface always had its own IPv6 assigned from the ISP. I'm happy to also provide logs but I'm not sure which ones?
Screenshot attached showing the lack of a WAN IPv6 address but LAN still has it.
Same here... enable dhcp6c logging and post the log... it will tell us everything... why it renewed and why it couldn't. Also try the revert.
Cheers,
Franco
I'm still a newbie here on 24.1.8, but I haven't upgraded to 24.1.9 yet in fear of this issue. Can the anyone with this particular DHCP6 symptom reply what their settings are for:
System / Gateways / Configuration / WAN1_DHCP6:
Upstream Gateway [mine is checked]
Disable Gateway Monitoring [mine is unchecked]
On 24.1.8, I experienced something similar when the 'Upstream Gateway' was [unchecked] and my LAN was set to tack interface.
After years of correctly working with Comcast to get a /60 delegation, I can't seem to get delegated addresses to work now. Dowgrading dhcp6c with opnsense-revert -r 24.1.8 dhcp6c and rebooting both OPNsense and the modem does NOT seem to resolve the issue.
If it's not dhcp6c then try to see if it's the core package changes:
# opnsense-revert -r 24.1.8 opnsense
Cheers,
Franco
Hello,
Back again with some dhcp6c logs.
Initial solicit on boot:
Sending Solicit
a new XID (b1ac54) is generated
set client ID (len 14)
set identity association
set elapsed time (len 2)
set option request (len 4)
set IA_PD prefix
set IA_PD
send solicit to ff02::1:2%bge2
reset a timer on bge2, state=SOLICIT, timeo=0, retrans=1009
receive advertise from fe80::bb%bge2 on bge2
get DHCP option server ID, len 10
DUID: xx:xx:xx:xx:xx:xx:xx:xx:23:d8
get DHCP option client ID, len 14
DUID: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:e9:88
get DHCP option identity association, len 40
IA_NA: ID=0, T1=1800, T2=2880
get DHCP option IA address, len 24
IA_NA address: 2001:db8::1 pltime=3600 vltime=3600
get DHCP option IA_PD, len 41
IA_PD: ID=0, T1=1800, T2=2880
get DHCP option IA_PD prefix, len 25
IA_PD prefix: 2001:db8:3::/56 pltime=3600 vltime=34359741968
get DHCP option DNS, len 32
server ID: xx:xx:xx:xx:xx:xx:xx:xx:23:d8, pref=-1
reset timer for bge2 to 0.992103
picked a server (ID: xx:xx:xx:xx:xx:xx:xx:xx:23:d8)
Sending Request
a new XID (216327) is generated
set client ID (len 14)
set server ID (len 10)
set IA address
set identity association
set elapsed time (len 2)
set option request (len 4)
set IA_PD prefix
set IA_PD
send request to ff02::1:2%bge2
reset a timer on bge2, state=REQUEST, timeo=0, retrans=911
receive reply from fe80::bb%bge2 on bge2
get DHCP option server ID, len 10
DUID: xx:xx:xx:xx:xx:xx:xx:xx:23:d8
get DHCP option client ID, len 14
DUID: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:e9:88
get DHCP option identity association, len 40
IA_NA: ID=0, T1=1800, T2=2880
get DHCP option IA address, len 24
IA_NA address: 2001:db8::1 pltime=3600 vltime=3600
get DHCP option IA_PD, len 41
IA_PD: ID=0, T1=1800, T2=2880
get DHCP option IA_PD prefix, len 25
IA_PD prefix: 2001:db8:3::/56 pltime=3600 vltime=34359741968
get DHCP option DNS, len 32
Received REPLY for REQUEST
nameserver[0] 2001:db8::a
nameserver[1] 2001:db8::b
make an IA: PD-0
create a prefix 2001:db8:3::/56 pltime=3600, vltime=3600
add an address 2001:db8:3:1:xxxx:xxxx:xxxx:e10d/64 on bge1
make an IA: NA-0
create an address 2001:db8::1 pltime=3600, vltime=34359741968
add an address 2001:db8::1/128 on bge2
removing an event on bge2, state=REQUEST
removing server (ID: xx:xx:xx:xx:xx:xx:xx:xx:23:d8)
executes /var/etc/dhcp6c_wan_script.sh
dhcp6c_script: REQUEST on bge2 executing
dhcp6c_script: REQUEST on bge2 renewal
script "/var/etc/dhcp6c_wan_script.sh" terminated
got an expected reply, sleeping.
Subsequent renew:
IA timeout for NA-0, state=ACTIVE
reset a timer on bge2, state=RENEW, timeo=0, retrans=10256
Sending Renew
a new XID (b4a5d5) is generated
set client ID (len 14)
set server ID (len 10)
set IA address
set identity association
set elapsed time (len 2)
set option request (len 4)
send renew to ff02::1:2%bge2
IA timeout for PD-0, state=ACTIVE
reset a timer on bge2, state=RENEW, timeo=0, retrans=10244
Sending Renew
a new XID (b3a2c0) is generated
set client ID (len 14)
set server ID (len 10)
set elapsed time (len 2)
set option request (len 4)
set IA_PD prefix
set IA_PD
send renew to ff02::1:2%bge2
receive reply from fe80::bb%bge2 on bge2
get DHCP option server ID, len 10
DUID: xx:xx:xx:xx:xx:xx:xx:xx:23:d8
get DHCP option client ID, len 14
DUID: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx::e9:88
get DHCP option identity association, len 40
IA_NA: ID=0, T1=1800, T2=2880
get DHCP option IA address, len 24
IA_NA address: 2001:db8::1 pltime=3600 vltime=3600
get DHCP option DNS, len 32
Received REPLY for RENEW
nameserver[0] 2001:db8::a
nameserver[1] 2001:db8::b
update an IA: NA-0
update an address 2001:db8::1 pltime=3600, vltime=34359741968
removing an event on bge2, state=RENEW
executes /var/etc/dhcp6c_wan_script.sh
dhcp6c_script: RENEW on bge2 executing
script "/var/etc/dhcp6c_wan_script.sh" terminated
got an expected reply, sleeping.
receive reply from fe80::bb%bge2 on bge2
get DHCP option server ID, len 10
DUID: xx:xx:xx:xx:xx:xx:xx:xx:23:d8
get DHCP option client ID, len 14
DUID: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx::e9:88
get DHCP option IA_PD, len 41
IA_PD: ID=0, T1=1800, T2=2880
get DHCP option IA_PD prefix, len 25
IA_PD prefix: 2001:db8:3::/56 pltime=3600 vltime=3600
get DHCP option DNS, len 32
Received REPLY for RENEW
nameserver[0] 2001:db8::a
nameserver[1] 2001:db8::b
update an IA: PD-0
update a prefix 2001:db8:3::/56 pltime=3600, vltime=3600
removing an event on bge2, state=RENEW
executes /var/etc/dhcp6c_wan_script.sh
dhcp6c_script: RENEW on bge2 executing
script "/var/etc/dhcp6c_wan_script.sh" terminated
got an expected reply, sleeping.
Hopefully there's some useful information in these logs.
If not, would there be any other way for me to try and provide some useful debug information?
Edit: this is on OPNsense 24.1.9_4-amd64, no reverts
Quote from: joezeppy on June 22, 2024, 11:43:50 AM
I'm still a newbie here on 24.1.8, but I haven't upgraded to 24.1.9 yet in fear of this issue. Can the anyone with this particular DHCP6 symptom reply what their settings are for:
System / Gateways / Configuration / WAN1_DHCP6:
Upstream Gateway [mine is checked]
Disable Gateway Monitoring [mine is unchecked]
On 24.1.8, I experienced something similar when the 'Upstream Gateway' was [unchecked] and my LAN was set to tack interface.
Here's mine.
This is a bit weird:
vltime=34359741968
Otherwise it looks rather normal. Do you use the "prevent release" option?
Quote from: franco on June 23, 2024, 11:41:08 AM
This is a bit weird:
vltime=34359741968
Otherwise it looks rather normal. Do you use the "prevent release" option?
Prevent release is unchecked. I've tried both enabled and disabled, the issue persists.
Here are mine, it appears to grab an address and then almost immediately release it for WAN. It does hold on to the prefix delegation and that doesn't change even though the WAN IP6 doesn't seem to stick.
The logs are too large to paste here in the thread so I'm just attaching them for review. I've segmented them in to the initial bootup log, and the first renewal attempt.
After Upgrade to 23.1.9 IPv6 only works for a short time on the WAN interface on my OPNsense.
If IPv6 connectivity has been lost, the only way to get the IPv6 connection working again is to reload the interface. After a short time, however, it is gone again.
A downgrade of the dhcp6c package with "opnsense-revert -r 24.1.8 dhcp6c" fixes the problem for me after a reboot. The connection has currently been stable for 10 hours.
I too can confirm, reverting dhcp6c with
# opnsense-revert -r 24.1.8 dhcp6c
and rebooting fixed the issue for me as well. The earlier issue I had after downgrading the package was due to a misconfiguration on my end. My apologies for any confusion.
Thank you all for your help
Ok this sounds workable... our best candidate for revert is https://github.com/opnsense/dhcp6c/commit/5676e78d87
# pkg add -f https://pkg.opnsense.org/FreeBSD:13:amd64/snapshots/misc/dhcp6c-20240607_1.pkg
Reboot and try again.
I was a bit suspicious of the patch but it's been in Debian too many years to give it a second thought. I don't know the code well enough but maybe the logic condition is wrong (|| vs. &&).
Cheers,
Franco
I have now applied the patch. Let's see if the IPv6 connection remains.
Quote from: franco on June 23, 2024, 10:29:30 PM
Ok this sounds workable... our best candidate for revert is https://github.com/opnsense/dhcp6c/commit/5676e78d87
# pkg add -f https://pkg.opnsense.org/FreeBSD:13:amd64/snapshots/misc/dhcp6c-20240607_1.pkg
Reboot and try again.
I was a bit suspicious of the patch but it's been in Debian too many years to give it a second thought. I don't know the code well enough but maybe the logic condition is wrong (|| vs. &&).
Cheers,
Franco
Seems to be working!
With the original 24.1.9 version the address kept dropping after an hour. Current system uptime 1h45min with no issues so far.
I had the same issue since 24.1.9 and fixed it by disabling Crowdsec (when the package is installed, it is enabled by default). I did not revert dhcp6c to an older version.
Crowdsec has a cron job running every hour so it could explain why it stops after exactly 1 hour (my DHCP leases are 8h - renewed every 4h).
I did not spend time to check why it is causing WAN IPv6 to be lost. It looks unrelated but practically it works.
Quote from: franco on June 23, 2024, 10:29:30 PM
Ok this sounds workable... our best candidate for revert is https://github.com/opnsense/dhcp6c/commit/5676e78d87
# pkg add -f https://pkg.opnsense.org/FreeBSD:13:amd64/snapshots/misc/dhcp6c-20240607_1.pkg
Reboot and try again.
I was a bit suspicious of the patch but it's been in Debian too many years to give it a second thought. I don't know the code well enough but maybe the logic condition is wrong (|| vs. &&).
Cheers,
Franco
Will today come an official Hotfix or will it worth to do this manual?
Not going to hotfix this.
Quote from: franco on June 23, 2024, 10:29:30 PM
Ok this sounds workable... our best candidate for revert is https://github.com/opnsense/dhcp6c/commit/5676e78d87
# pkg add -f https://pkg.opnsense.org/FreeBSD:13:amd64/snapshots/misc/dhcp6c-20240607_1.pkg
Reboot and try again.
After 14 hours, the IPv6 connection is still up. That was probably the culprit.
Want to add I was experiencing this issue due the to 24.1.9 update as well. It broke unbound resolving at first because I use the WAN interface IPv6 to perform my upstream lookups.
I was losing my IPv6 on the wan interface in a matter of minutes every time I reapplied the WAN interface configuration. Since applying this patch, it appears to be working correctly now. I will update if that changes.
Quote from: franco on June 23, 2024, 10:29:30 PM
# pkg add -f https://pkg.opnsense.org/FreeBSD:13:amd64/snapshots/misc/dhcp6c-20240607_1.pkg
Reboot and try again.
Cheers,
Franco
24hrs uptime here and still keeping the WAN IP6 lease after applying the fix to 24.1.9_4. Thanks @franco and team!
Can confirm as well.
After having incredibly stable IPV6 for the last couple years, I began noticing ipv6 drop-outs after the upgrade to 24.1.9
Tried with and without crowdsec after another user mentioned that to be a potential cause to no avail.
The only thing that restored my IPV6 connectivity is rolling back with pkg add -f https://pkg.opnsense.org/FreeBSD:13:amd64/snapshots/misc/dhcp6c-20240607_1.pkg
After a long-time forum lurker, felt it a good time to share my experience with the issue.
Thanks for the solution
To potentially add a data point here, I have a few opnsense systems on Comcast in my area.
My home opnsense has this problem - it acts like it loses the ipv6 address on the WAN but ipv6 still works EXCEPT for tunnels. I have multiple inside interfaces tracking WAN. I get about 24-30 hours before it happens.
Another opnsense in the same area also on Comcast only has one internal interface tracking WAN and it has worked perfectly since being upgraded four days ago.
After installing 24.1.9_4 and a reboot my OPNsense lost the IPv6 address on the WAN interface. This worked for several years without a problem.
I applied pkg add -f https://pkg.opnsense.org/FreeBSD:13:amd64/snapshots/misc/dhcp6c-20240607_1.pkg and rebooted, but nothing changed. Still no IPv6 on the WAN interface.
My ISP is DTAG if that helps.
How can I provide logs for dhcp6?
Any other suggestions to get the problem solved? Should I try opnsense-revert -r 24.1.8 dhcp6c?
Since nobody had any other suggestions, I did
pkg add -f https://pkg.opnsense.org/FreeBSD:13:amd64/snapshots/misc/dhcp6c-20240607_1.pkg and rebooted
==> nothing changed
# opnsense-revert -r 24.1.8 dhcp6c
==> nothing changed
# opnsense-revert -r 24.1.8 opnsense
==> I got IPv6 back working
So I will stay on 24.1.8 till there is a solution for that problem.
For the extended dhcp6c logging, you can enable that under Interfaces/Settings/IPv6 DHCP and select "debug" level logging from the dropdown menu. You can also set a DHCPv6 UID there, which can be handy for some ISPs.
The next step would be to verify the settings that worked for years. I presume you're using WAN DHCPv6 and LAN is set to track interface? Do you use any manual LAN DHCPv6 assignments or prefix IDs?
Experiencing the same issue everybody mentions here. ISP is Vodafone Cable (Germany, bridge-mode enabled at Vodafone Station).
None of the previous potential fixes worked for me. Did a reinstallation of 24.1 , locked version to 24.1.8, ran the update and imported my config. Its all fine again.
@WhoopWhoop
You run the update to 24.1.9_4 after the new install and then imported your config?
Quote from: tokade on June 28, 2024, 02:20:16 PM
@WhoopWhoop
You run the update to 24.1.9_4 after the new install and then imported your config?
No,
He said he locked it to 24.1.8.
Quote from: Taunt9930 on June 28, 2024, 07:46:06 PM
Quote from: tokade on June 28, 2024, 02:20:16 PM
@WhoopWhoop
You run the update to 24.1.9_4 after the new install and then imported your config?
No,
He said he locked it to 24.1.8.
Correct. Right now im on 24.1.8 and the IPv6 situation is fine.
For the sake of testing, and also to rule out any errors coming from my backed up config, I also tested a clean installation, added some basic WAN configuration and upgraded to 24.1.9. The results were the same: the IPv6 address did not renew.
I have the same problem on routers on two different sites with two different ISP, Telia AB and Obe Networks.
Upgraded from 24.1.8 to 24.1.9_4 last saturday and both routers now lose the WAN IPv6 address a while after first request upon boot. Looking in the log and there seem to be periodic requests from the DHCP6 client to the DHCP6 server after about half lease time, but no IPv6 IP-address show up in the dashboard and the VPN-tunnels fails as expected without peers.
This looks almost epidemic now and maybe it requires a hotfix?
Or is a complete revert back to 24.1.8 best practice?
Quote from: Skreabengt on July 02, 2024, 05:49:44 PM
I have the same problem on routers on two different sites with two different ISP, Telia AB and Obe Networks.
Upgraded from 24.1.8 to 24.1.9_4 last saturday and both routers now lose the WAN IPv6 address a while after first request upon boot. Looking in the log and there seem to be periodic requests from the DHCP6 client to the DHCP6 server after about half lease time, but no IPv6 IP-address show up in the dashboard and the VPN-tunnels fails as expected without peers.
This looks almost epidemic now and maybe it requires a hotfix?
Or is a complete revert back to 24.1.8 best practice?
And the posted fix/ workaround doesn't work?
I have not tried using the commands below yet; I am fairly new with OPNsesnse, but I guess they can''t be used in the GUI, perhaps from SSH, or else you need to hook up screen and keyboard directly to the router and use them in a UNIX shell, right?
# opnsense-revert -r 24.1.8 dhcp6c
# opnsense-revert -r 24.1.8 opnsense
My impression is that none of the hotfixes shown below are for correcting a "WAN IPv6 address not renewing after initial dhcp request", so it won't help. I updated directly to 24.1.9 hotfix 4 from 24.1.8.
"A hotfix release was issued as 24.1.9_1:
o firewall: "natreflection" rule attribute missed in MVC/API migration
A hotfix release was issued as 24.1.9_3:
o firewall: typo in "destination" migration for one-to-one NAT
o firewall: one-to-one NAT default reflection setting was ignored
A hotfix release was issued as 24.1.9_4:
o system: proper HA sync for new one-to-one NAT section"
I'm having the same problem with my UK ISP, Andrews and Arnold (A&A).
Because A&A provide static routing I'm not requesting a prefix at all - just a non-temporary address, and options 23 and 24.
I've got a virtualized router, so I've rolled back to 24.1.8 for now.
/var/etc/dhcp6c.conf looks like this:-
interface pppoe0 {
send ia-na 0; # request stateful address
request domain-name-servers;
request domain-name;
script "/var/etc/dhcp6c_wan_script.sh"; # we'd like some nameservers please
};
id-assoc na 0 { };
I'm running this command on the console to capture the DHCP negotiations:-
tcpdump -w dhcp.pcap -i pppoe0 udp portrange 546-547
I've also sent a HUP to dhcp6c to release and re-request the address.
Tomorrow I'll repeat the exercise on 24.1.9 and look for obvious changes.
I'm not looking at logging yet, but I thought a report of what's going on on-the-wire might be useful.
Packet capture from DHCPv6 over 4 hours on 24.1.8 following SIGHUP to dhcp6c
There are a few RELEASE messages (packets 1, 5, 7, 8, 9) with an XID of 0x3f4706 which I think are related to the initial HUP I sent dhcp6c. Other than that, it's pretty much as expected.
I've installed 24.1.9 and rebooted. /var/etc/dhcp6c.conf is identical. I've restarted the capture. Currently I have a pingable WAN address.
I reverted all 3 routers back to 24.1.8. I started with just opnsense, which didn't help alone, but after reverting dhcp6c as well, the WAN IPv6 address remains. I used an SSH client and did all three remotely from one site. Both Telia and Obe Network is working now.
# opnsense-revert -r 24.1.8 opnsense
# opnsense-revert -r 24.1.8 dhcp6c
Attached is my packet capture from 24.1.9
As I write this, system uptime is 2:56, and it's 17:56 BST here. So the capture started at around 15:00 BST. This isn't an exact time. I note 'who -b' doesn't seem to work on my system.
I ran a IPv6 ping test of my WAN address in parallel at a rate of one a minute. The ping test dropped out at 17:03 BST approx.
The initial lease from 15:00 BST (approx.) has a valid lifetime of 7200 secs (packet 6). A renew request is made at 16:00 BST and answered (packets 10 and 11), and another one is made at 17:00 BST (packets 12 and 13). Round about this point the IP address is dropped.
So it looks to me as though the DHCP REPLY packets are not being acted on, or when they are received the valid lifetime is not being updated.
I really hope this is of use. I'm happy to reproduce this if required to get more information, (e.g. logging), or to try something else, but I'll wait to be guided by someone who knows more about this than I do! I'm going to roll back to 24.1.8 here for now.
Quote from: tokade on June 27, 2024, 04:13:45 PM
Since nobody had any other suggestions, I did
pkg add -f https://pkg.opnsense.org/FreeBSD:13:amd64/snapshots/misc/dhcp6c-20240607_1.pkg and rebooted
==> nothing changed
# opnsense-revert -r 24.1.8 dhcp6c
==> nothing changed
# opnsense-revert -r 24.1.8 opnsense
==> I got IPv6 back working
So I will stay on 24.1.8 till there is a solution for that problem.
I can confirm this workaround to be successful for Vodafone Cable Germany!
Thank you for putting it in the respective order.
Something to note on the opensense-revert command is that if somehow you got unreacheable v6 default as a result of not having working WAN IPv6 address due to the dhcp6c issue, you may be unable to also revert.
The Github issue I made is this one for this: https://github.com/opnsense/core/issues/7595
I had to do the following:
- Disable IPv6 on WAN
- Run the revert
- Reboot
- See that it did not fix it so another revert, this time to 24.1.0
- Reboot
- Re-enable IPv6
- Use the pkg install that's in this thread.
- Now I have working IPv6 WAN dhcp6 again
opnsense-revert -r 24.1.8 dhcp6c
pkg add -f https://pkg.opnsense.org/FreeBSD:13:amd64/snapshots/misc/dhcp6c-20240607_1.pkg
Quote from: franco on June 23, 2024, 10:29:30 PM
Ok this sounds workable... our best candidate for revert is https://github.com/opnsense/dhcp6c/commit/5676e78d87
# pkg add -f https://pkg.opnsense.org/FreeBSD:13:amd64/snapshots/misc/dhcp6c-20240607_1.pkg
Reboot and try again.
I was a bit suspicious of the patch but it's been in Debian too many years to give it a second thought. I don't know the code well enough but maybe the logic condition is wrong (|| vs. &&).
Cheers,
Franco
This fixed the issue for me as well. I'm on Comcast's DOCSIS network.
Quote from: franco on June 23, 2024, 11:41:08 AM
This is a bit weird:
vltime=34359741968
Otherwise it looks rather normal. Do you use the "prevent release" option?
A note on vltime (for Comcast not sure on others) Comcast states that IPv6 addresses received from DHCPv6 on their network are effectively static. Might be why they set the vltime to max.
I know it doesn't help anyone with an issue, but a useful data point for Franco perhaps- no issues here. Straight upgrade and no issues with IPv6 on a Zen PPPoE UK FTTP connection.
Been up 24 hours now since a reboot after upgrade, and not an issue at all.
Just another +1 for being affected by this issue. I was seeing IPv6 GAs being assigned initially, eventually falling off from the interface. In my case, packet sniffing demonstrated two separate renew packets, the first responding with the GA, and the second responding with my delegated prefix.
Quote from: franco on June 23, 2024, 10:29:30 PM
Ok this sounds workable... our best candidate for revert is https://github.com/opnsense/dhcp6c/commit/5676e78d87
# pkg add -f https://pkg.opnsense.org/FreeBSD:13:amd64/snapshots/misc/dhcp6c-20240607_1.pkg
Reboot and try again.
This is what solved the problem for me.
+1 for the issue
+1 for the "solution" (pkg add -f https://pkg.opnsense.org/FreeBSD:13:amd64/snapshots/misc/dhcp6c-20240607_1.pkg)
WAN IPV6 up again for 14h now.
I've tracked down what is happening on my simple setup (address only, no prefix) and created a PR for discussion:-
https://github.com/opnsense/dhcp6c/pull/36
Quote from: matt335672 on July 08, 2024, 04:48:32 PM
I've tracked down what is happening on my simple setup (address only, no prefix) and created a PR for discussion:-
https://github.com/opnsense/dhcp6c/pull/36
Wondering if my situation over the past couple of weeks could be related, this was working before:
1. WAN pulls IPv6 fine via DHCPv6 client.
2. LAN has a static IPv6 address. Clients pull an IPv6 address via routing advertisement (managed mode) and DHCPv6 server (so I can control the address they receive). This stopped working though I noticed one day on my phone when I saw it didn't pull an IPv6 address.
3. So I dropped back versions of dhcpv6c and opnsense proper ( 24.1.8 ) as stated in the thread. This only allowed me to serve out clients via unmanaged routing advertisements and not via the DHCPv6 server I have running.
So with that background, the question is does anyone think this issue would affect the ability to use the DHCPv6 server to serve out static-mapped addresses with routing advertisements set to managed (not working) instead of unmanaged (working) as it is now?
Since you've quoted me dfw3xam1n3r, I'll reply as best I can.
On the face of it I can't see a reason for this to be related, but I'm just a random software developer off the internet. This is my first PR for opnsense. I'm best described as an enthusiastic user of opnsense, so my product knowledge level is at best patchy. For example, I don't know how the dataflows for the 'track interface' feature are implemented.
That's the disclaimer. However, you can investigate this yourself as follows, if you're on 24.1.9:-
1) Restart the WAN connection
2) Get up a terminal and investigate the WAN connection with ifconfig -L pppoe0 (assuming you're on PPPoE).
You should see your IPv6 GUA there. After the text vltime there will be a value. This is the number of seconds remaining before your GUA disappears. Your ISP will still believe your GUA is active, as it will be getting regular RENEW requests from you.
When your GUA does disappear, a range of things can happen from 'hardly anything' to 'no IPv6'. This is ISP-dependent to a large extent. However, you have a precise time when this happens, and so with a bit of detective work you should be able to figure out if there is a dependency between events on your network and the GUA disappearing.
BTW, I believe a release which addresses this issue is imminent so this may be moot.