kea-dhcp6 crashes
-
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.
-
@behemyth said in kea-dhcp6 crashes:
We were told there would be 4 releases a year, this (if it happens) wi
And why is this important ? Keeping infrastructure at current version isn't exactly easy.
Two releases is already a lot for production.Firewalls are not meant to be rebooted or migrated often, since they are cornerstone to many other things.
-
@netblues said in kea-dhcp6 crashes:
And why is this important ? Keeping infrastructure at current version isn't exactly easy.
Two releases is already a lot for production.Firewalls are not meant to be rebooted or migrated often, since they are cornerstone to many other things.
This is not true. My team and I reboot hundreds of firewalls in my corporate environment monthly, sometimes weekly depending on vulnerabilities that are found.
I'm also sure I am not alone in this aspect. Firewalls are just another piece of network gear, and should be treated as such. They just serve a different role than a router/switch.
If your following good design, and building out HA, rebooting production equipment doesn't matter.
-
@behemyth said in kea-dhcp6 crashes:
sometimes weekly depending on vulnerabilities that are found.
Yes, of course. But vulnerabilities in pfsense are addressed as patches and NOT versions.
Testing out a patch is rather trivial.
Testing a new version with new functionality is another. And quite often, its not the bug, its the feature than makes things go flaky.No one professional enough, is running mission critical workloads without HA, BUT HA must also be tested.
Changing major versions sometimes incur new things, for example single cast for carp instead if multicast.
What I'm saying is that patching is something that a network team does and just needs small maintenance windows for that.
Changing versions and introducing new functionality is another story.So, again, why 4 (or) 3 versions per year is important for you?
