kea-dhcp6 crashes
-
Hmm, I would have sworn that was the kea2unbound function.
You see the same error with no dhcp lease registration set?
Is it only that client that triggers it?
Can you upload that core file for us to check? It should be in /root. https://nc.netgate.com/nextcloud/s/4FNpZJZfHQtoHia
Steve
-
Good Morning @stephenw10, thanks for getting back to me.
I disabled DNS Registration and Early DNS Registration, yes.
And just a few minutes ago switched on my Macbook Air M2 from the Automatic location to IPv6 Only. And it crashed again.
The kea-dhcp6.core dump is uploaded to the nextcloud.
It also happens with my older Macbook Pro 2018 model which does have the same locations. And it is connected to the same Wifi AP (ASUS RT-AC88U).
On one of the wired Linux boxes I couldn't replicate it yet, but there I have to disable/enable the interface to disable or enable IPv4 or IPv6.
-
Great I see that. Let me see what we can get from it...
-
If you can easily replicate this can you get a packet capture of the request that triggers it?
-
@stephenw10 it happens every time I change to a location including a IPv4 address, so yes it's easily replicated.
Is a package capture for UPD and port 67 sufficent?
-
dhcpv6 uses 546/547 so I'd capture on 67,68,546 and 547. Or maybe just filter by the client MAC. Since this appears to require switching between v4 and v6 we probably need to see both to be sure.
-
Forgot about DHCPv6, you are right of course.
I uploaded pfSense-Plus_pcap_kea-dhcp6-crash__20241002_001.tar.gz containing the core file, pcap captured for udp and client mac and one for udp and ports 67 68 546 547.
The relevant network infos are:
- client MAC is 34:b1:eb:f3:ba:76
- client IPv4 192.168.169.52 (static DHCP)
- client IPv6 2a02:169:31e2:1969::f:52 (static DHCPv6)
- server IPv4 192.168.169.1
- server IPv6 2a02:169:31e2:1969::1
In general:
- LANv4: 192.168.169.0/24
- LANv6: 2a02:169:31e2:1969::/64
- IPv6 addresses ending in ::c:xxxx are static IPs assigned on the node itself
- IPv6 addresses ending in ::f:xxxx are static DHCPv6 mappings
- IPv6 addresses ending in ::d:xxxx are from the DHCPv6 address pool
-
That's great thanks!
-
I fixed a segfault in kea-dhcp6 a few days ago. Likely is the same issue.
-
@cmcdonald Any chance of getting a binary to test?
-
New image should be available 'real soon now'. Like actually soon!
-
@stephenw10 said in kea-dhcp6 crashes:
New image should be available 'real soon now'. Like actually soon!
We sha’ll see, lol…
-
I mean soon is a relative term.
(but it really should be, new bugs aside) -
Well, the Redmine roadmap page changed. It's no longer showing 24.08 release. It seems something really is happening
https://redmine.pfsense.org/projects/pfsense-plus/roadmap
-
@juanzelli said in kea-dhcp6 crashes:
https://redmine.pfsense.org/projects/pfsense-plus/roadmap
Ah yes. Well, by looking at the open bugs (which are the same as they were in the 24.8 release) obviously the 24.08 has been merged into 24.11 which is due in ~20 days from now
So an rc version can be expected really soon, followed by the official 24.11 within November. -
Like I said above, we’ll see.
24.08 was being tested back in frickin May, and now its not even being released and now its 24.11.
Heck, this could get pushed and become 25.03.
Until I see a release, I’m not holding my breath. I dont know why you would just completely drop a release and roll it into another release.
Just release something, and then work on the next one.
-
Well releasing something broken would be the worst thing we could do IMO!
By new image I mean a new public snapshot for testing.
-
@behemyth said in kea-dhcp6 crashes:
Until I see a release, I’m not holding my breath. I dont know why you would just completely drop a release and roll it into another release.
Just release something, and then work on the next one.
Releases don't really mean a lot, especially when they are not bound to a specific feature set.
So as long as the product is secure, and released features work as expected, date bound releases aren't that critical.
I could say that working towards a 3 or 4 per year releases as a target is nice, but setting dates becomes unrealistic, especially when new great features come into the pipeline (in this case, cloud management of multiple devices).Perhaps naming the release as "next", and renaming it into the month it is finally released is better.
-
@stephenw10 said in kea-dhcp6 crashes:
Well releasing something broken would be the worst thing we could do IMO!
I'm not saying release broken images, that is bad.
We were told there would be 4 releases a year, this (if it happens) will only be the second.
-
3 a year is the target but when the changes are as significant as they are for this release it can take longer.
