@dennypage Out of curiosity are you getting any hits for qat in vmstat? I'm configured in a nearly identical way and it must be that I must either not be using the right ciphers or IPsec-MB is so efficient it absolutely makes QAT useless.

@stephenw10 Finally found the availability to go through this one again and for good. Old Kingston was no good, bought a new Sandisk and no joy. Eventually got it working with a very old usb flash drive. "efi_load_pe: Invalid DOS Signature" was gone. Reinstalled it but got into a new problem where ada0 was not recognized. Boot loop where only usb would work. Support was GREAT! They helped me and did a remote session and they nailed it with a "setenv pfsenseboot" command. At some point I believe we were even tricked by " being different from ' not sure to be honest, we did it a lot of times. But we got it! Reinstall to 25.07.1 worked well at the end. Did a new environment and tested my restore. All good and no surprises! Restored and rebooted and halted a couple of times to test if ada0 would kick in every time, which did ever since. People in the forum say the support is great, I can confirm! Thank you to those in forum.netgate and those at portal.netgate. Thanks! P.S. I will now try to fight again with unbound that insists to be delayed by either openvpn or pfblockerng :)

Yes this needs to be addressed. But I would argue that if you can set the pppoe password you already have a high level access and could break things far more easily.

For reference that's an ugly error but it's only cosmetic. It's safe to upgrade still if you see that after rolling back.

Thanks that worked!! Much appreciated.

@luckman212 The final release 25.07 stable is live and running on my system. ️

Hover over the red X and it will show a nice new popup window with a lot more detail about the entry. You can use the info from that popup to dig deeper in the rules and maybe see what it was.

@bigsy Nice! Thank you for the update.

@stephenw10 said in 25.07.r.20250709.2036 First Boot WireGuard Service not running: Are you using failover or loadbalance with those WG gateways? If not you might try disabling the monitoring action on them. Not with them but with others. Disabling the monitoring action only on them didn't make a difference. Edit: Disabling it on all but WAN also made no difference.

@Bob-Dig said in The if_pppoe backend does not support all advanced features of the MPD implementation: It isn't. ISP does a reset after 24 hours... I've never had an ISP do that to me and have no idea why an ISP do so as it isn't a recognised implementation of any standard. So yes, a bit odd that your provider does that to you. Glad the Cron countermeasure works but it should not come down to the end user. Your ISP needs a kicking and/or you need a better ISP. ️

Hmm, I thought we'd fixed that. Let me see... Ah, maybe not: https://redmine.pfsense.org/issues/16207

I would agree. 18 hours in and everything continues to run smoothly. The issue related to image availability I believe is the valid answer and we can close this out as solved. Thanks everyone. -JD

Good to hear.

@pst said in 25.07.r.20250709.2036: still issues with limiters: I have yet to test limiters in combination with floating firewall rule for buffer boat mitigation, which was an issue in earlier betas. Still an issue in the RC. UL/DL limiters on LAN work as long as I haven't configured UL/DL limiters for WAN. Once there are WAN limiters no limits on LAN are adhered to (which I think is a regression from the beta where at least one direction worked as configured). Time to shelve those ideas of using limiters I guess.

Yes, those are the correct versions in 25.07-RC. The newer pkgs are currently only in head, what will be 25.11. They may be pulled back into 25.07 at some point if necessary though.

@stephenw10 said in Gateway monitoring still not OK: I would still expect to have seen dpinger try to ping and show loss rather than pending. /etc/inc/gwlb.inc: // dpinger returns '<gwname> 0 0 0' when queried directly after it starts. // while a latency of 0 and a loss of 0 would be perfect, in a real world it doesnt happen. // or does it, anyone? if so we must 'detect' the initialization period differently..

Ok, I had created a block rule to the firewall before and because I actually don't use UPnP, I didn't noticed that this was blocking UPnP now. So everything works like expected, at least with IPv4. *** 15.07.2025 *** [11:27:00] starting Tixati v3.29 [11:27:00] loading settings [11:27:00] loading transfers [11:27:00] loading DHT [11:27:00] loading RSS [11:27:00] loading scheduler [11:27:00] loading throttle [11:27:00] loading channels [11:27:00] loading interface [11:27:01] startup complete [11:27:01] listening on tcp:0.0.0.0:19703 [11:27:01] listening on tcp:[::]:19703 [11:27:01] DHT started [11:27:01] listening on udp:0.0.0.0:19703 [11:27:01] listening on udp:[::]:19703 [11:27:04] NAT-PMP mapped TCP port 19703 on gateway 192.168.1.1 [11:27:04] NAT-PMP mapped UDP port 19703 on gateway 192.168.1.1 Would be nice to have that UPnP Port 5351 as a port-template. [image: 1752572782881-screenshot-2025-07-15-114613.png]

Most commonly new sensors appeared because an update had new drivers that exposed them. The chipset PCH sensor was pulled into base for 23.09 (I think!) for example.

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