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. ️

I enabled my iimb by hand. Seems to work fine on my 6100. FWIW, the current documentation indicates that the default value of kern.crypto.iimb.enable_aescbc is 1 (enabled), although it has a warning that iimb can be slower than qat for cbc. I don't use cbc, so it doesn't matter in my case. I think the documentation is incorrect or outdated (at least for the 6100), as the code in /etc/inc/config.console.inc explicitly sets kern.crypto.iimb.enable_aescbc to 0. FWIW, there is also an interesting note on the qat/iimb trade-off earlier here. YMMV

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

@stephenw10 Thanks again. Well it is full of passwords and pre-shared keys and very detailed stuff but I guess we should find the culprit of it somehow. I did find leftovers of lcdproc before, which I cleaned at some point. That means that part of the config I am using was migrated from a modified WatchGuard I have used in the past. Let me have a look tomorrow. It's kind of late now in my timezone. Thanks!

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!