Cool. You shouldn't see them again. Obviously shout if you do!

@stephenw10 Thanks again. ️

This looks like a duplicate of this? https://forum.netgate.com/topic/197983/pfsense-25-03-latest-beta-crash-report

Hmm Ok. Are you able to replicate it though? Like if you resave it now does it panic again?

DHCPv6 over PPPoE. The usual PPPoE setup.

@stephenw10 I pulled out an spare SG 2440 loaded it with the latest beta and restore config without an issue. Thanks for your help.

@marcosm @stephenw10 Apologies for the delay in acknowledging, I've been away for a while but thanks for giving this your attention. Fixed for me as of 25.03-beta 10th June. Cheers!

@stephenw10 said in [solved] 25.03.b.20250610.1659 re-enabling limiters leads to syslog kernel messages "update_fs ...": So pass - quick - outbound on WAN only? yes, here's the rule: [25.03-BETA][admin@felicity.local.lan]/root: pfctl -sr | grep -i buffer pass out quick on igb0 route-to (igb0 xxx.xxx.xxx.xx1) inet from xxx.xxx.xxx.xx3 to any flags S/SA keep state (if-bound) label "USER_RULE: From bufferbloat recipe" label "id:1750159398" label "gw:WAN_DHCP" ridentifier 1750159398 dnqueue(2, 1) [image: 1750601881854-screenshot-2025-06-22-at-16-07-44-firewall-rules-floating-edit-felicity.local.lan-resized.jpg] Are you using pppoe at all? Or dhcp WAN? no pppoe, only dhcp v4/v6 on WAN I should mention that I disabled IPv6 during the testing as to not interfere. Redmine #16201 mentions that the IPv6 rule needs to look slightly different as there is no NAT involved, so the source will not be WAN but rather the client's LAN address (so I skipped IPv6 for now)

If you mouse over the rule you can check the actual rule number and tracker ID and then compare that with the output from pfctl -vsr: [image: 1750247940302-screenshot-from-2025-06-18-12-56-07.jpg]

Huh that's weird. Which BE was causing that? Do you have the name that was used?

Problem solved by backup and pfsense plus installer clean install for beta 20251006 25.03

@cmcdonald said in Failed boot enviroment: I've got a fix, it will land in next beta. Thank you, it is appreciated

I've struggled with this same issue, and this solution sounds promising.

@stephenw10 and to close the matter of "loop detected" on the gif interface that I saw earlier. I have not had one sighting since 16 May. I must have made a setup change (I do too many!) that "made it go away..." as I didn't install a new version of pfSense around that time. I have tried to force the issue several times, using the same techniques as earlier but to no avail. I can't trigger a scenario where "ICMP6 Unreachable Desination, Unreachable Address" is sent from the gif interface (and it was sooooo easy at one point )

@pst said in KEA DHCPv6: bug (?) with early DNS registration for Tracked Interfaces: I think it is caused by the introduction of the "early DNS registration" (which btw is also causing me some issues on IPv4, but I add a separate thread for that...) The issue I had noted wrt IPv4 (that static mappings were sometimes ignored and pool addresses used instead) was in the previous beta, and I have now tried to reproduce those in the current beta but failed, so we can put that to bed: there are no issues with KEA DCHP IPv4

@stephenw10 I will see if I have any logs available but never seen it before and only happened once I enabled kea and my external ip address changed, reverting and it all kicked in and worked

@stephenw10 Ok. Will try later

since disabling trackv6 all good. I now put a static address in Wireguard interface and all is working. But i guess that interface with NOARP needs a special treatment !

@stephenw10 Done and resolved the issue. Thanks Ted

@marcosm I have tested the fix, and it works (not that I ever doubed it wouldn't) Thanks guys!