24.03.r.20240416.0005 : all ok.
-
I think that ultimately it's a non-issue.
The logging "quirk", from what I've seen, only applies when the rule specifies IGMP. It's safe to assume that a user seeing the logs must have been trying to do something with IGMP, and this new behavior makes it obvious they did something wrong (allow-opts). It's been suggested that something could be added to the GUI when IGMP is selected, but I'm not convinced we should be adding protocol-specific info. Maybe a good middle ground is to automatically expand advanced options and check the IP options checkbox. -
@marcosm said in 24.03.r.20240416.0005 : all ok.:
The logging "quirk", from what I've seen, only applies when the rule specifies IGMP.
No.
-
Where is this setting found?
-
@Bob-Dig Hah yeah I proved myself wrong right after posting.
-
@Uglybrian said in 24.03.r.20240416.0005 : all ok.:
Where is this setting found?
and see the pure pf power being unfolded for you
-
It prob took 30 minutes + for the update to 24.03.r.20240416.0005 yesteday and after that it wouldn't pass traffic or allocate DHCP addresses etc.
I had to console onto the unit originally to see what the console was saying.
Rebooted and then the system started working again. This is on "white box" hardware.
-
Hmm, what did you update from?
Then after the reboot it was running the new RC OK? Anything logged when it wasn't responding?
-
Previous 24.03 RC release
When I connected via a console cable it looked like DNS failures.
All appears to be working post 2nd reboot.
Is there a log file you wish me to attach?
-
The latest upgrade log in /conf might show something. But only if it has errors. Otherwise the system log should have recorded any failures at the first boot.
-
@mikey_s Check if you have the same error msg (unbound) in the system log as in the first post of this thread 24.03-BETA to 24.03-RC update hiccup. Unbound did not start => DNS not working.
I too had to reboot once more after the update reboot.
