24.03.r.20240416.0005 : all ok.
-
Upgraded to 24.03.r.20240416.0005 (version of today).
All seems
( the GIMP firewall log spammer is still there )No "help me" PM's please. Use the forum, the community will thank you.
Edit : and where are the logs ?? -
@Gertjan said in 24.03.r.20240416.0005 : all ok.:
( the GIMP firewall log spammer is still there )
And everything else I reported in this forum, which are no major things to begin with.
-
@Gertjan said in 24.03.r.20240416.0005 : all ok.:
( the GIMP firewall log spammer is still there )
You mean IGMP?
-
Euh, yes, that one.
-
I've not seen that, what are you seeing?
-
The upper 4 ones ....
In the beginning, I had only 3 LAN firewall rules.
The latter two are the obvious pass all rules. No thrills, bells and whistles.
I had to create the first "IGMP" rule : a simple pass rule with this option set :
so now I have :
and no more IGMP log activity.Take note : my non logging main pass rule 1712736749 rules had not the log option checked, it was still logging ...
See also : [Multiple users] 24.03.r.20240410.1729 IGMP block gets logged
-
Ah, interesting. I would expect to need IP Options set there to pass IGMP traffic. But it shouldn't be blocked by an pass rule, it should hit the default block rule. Hmm
-
Oh OK I see this has been discussed in a ticket already: https://redmine.pfsense.org/issues/15400
-
@stephenw10 said in 24.03.r.20240416.0005 : all ok.:
ticket already: https://redmine.pfsense.org/issues/15400
Yeah, just found it : Had to look in the regression list.
And the issue is already solved, as this should be seen as a feature.A potential issue still stands : a non logging pass rules starts to log firewall 'drop' lines : that one will get questions ...
Also : filling up a log with potential "no so easy to explain" drop log lines can hide quickly other, more useful info. -
Yup I agree. It confuses me!
-
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.
