@Bob-Dig said in 25.07.r.20250709.2036 First Boot WireGuard Service not running:

not only was the WireGuard Service down again, also none of the tunnels were up...

Correction: None of the gateways corresponding to the tunnels were up. Before, only one gateway wasn't up, now no gateway was up. Have to check with the tunnels next time, if they are partially up or not.

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.

No unlikely to be related. The dtb error would probably prevent boot entirely or have no effect. And since there are reports of it in 24.11 it's probably the latter.

I would just reinstall clean to 24.11 or 25.07-RC at this point to be honest.

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

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!

@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)

Screenshot 2025-06-22 at 16-07-44 Firewall Rules Floating Edit - felicity.local.lan.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:

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