New messages after update to 2.4.1

Gertjan

Humm.

Not using pfBlockerNG - using 2.4.1-RELEASE (amd64) on a :

Intel(R) Pentium(R) 4 CPU 3.20GHz
Current: 2800 MHz, Max: 3200 MHz
2 CPUs: 1 package(s) x 2 hardware threads 
(from 2005 .....)

Applied the patch https://github.com/pfsense/pfsense/pull/3857

My pfSense still sings on boot :

PF was wedged/busy and has been reset.....
There were error(s) loading the rules: pfctl: DIOCXCOMMIT: Device busy - The line in question reads [0]....

PiBa

Can you try increasing the 'while ($pfctl_try < 10) {' to maybe 100 ? That would give it 20 seconds to settle its current activity..

Do you use any other packages like maybe ntop? Or anything else 'special' configured like aliases with url lists?

Gertjan

@PiBa:

Can you try increasing the 'while ($pfctl_try < 10) {' to maybe 100 ? That would give it 20 seconds to settle its current activity..

Will try that tomorrow.
@PiBa:

Do you use any other packages like maybe ntop? Or anything else 'special' configured like aliases with url lists?

Noop.
Avahi - NUT - Cron (but nothing added to the cron list) - ACME.

edit : Wait : I installed "munin-node" years ago. Runs every 5 minutes some perl and shell scripts (but nothing that touches pf I guess).
I'll ditch it by doing a complete clean re-install (switch to ZFS while doing so). Will report back.

esquire1968

@PiBa:

Do you mean 'while ($pfctl_try < 10) {' set to 100 in the original filter.inc or in the modified one?

I've the following packages installed:

bandwidthd
Cron
freeradius3
nut
openvpn-client-export
pfBlockerNG
RRD_Summary	
Service_Watchdog
snort

Thomas

PiBa

@esquire1968, In the 'patched' one, the original doesnt have the 'try loop'.

esquire1968

No changes! The same errors after setting '> 100'. :(

PiBa

'< 100' right? you shouldn't change the <> sign. or did you mean you tried bigger numbers as well? just checking.. if so then we should try and figure out what is keeping pf busy / wedging it.. not really sure what path to investigate yet though..

Can you 'trigger' the problem while pfSense is running? Can you run "lsof /dev/pf" while its in that process? what processes have the pf device open?

Gertjan

@PiBa :
The filter reload (mine - as the others here) return :
" …. pfctl: DIOCXCOMMIT ..." as a part of the notification.

Your patch is trying 10 times IF it detected a return 'error' lines that contains

strstr($_grbg, "DIOCADDALTQ: Device busy")

because it returns "…DIOCXCOMMIT " -> also known as "something else" ;)
So, the "try 10 times" is never executed, the flow will break out right away.

When I changed

if (strstr($_grbg, "DIOCADDALTQ: Device busy")) {

for

if (strstr($_grbg, "DIOCXCOMMIT : Device busy")) {

is were no more notifications for me.

@IpBa : Thanks !!

Edit : when I added <developerspew>to the config.xml - below <pfsense><system>- , I actually saw that a second try was needed to put the rules in place :

pf was busy but succeeded after 2 tries @ 2017-10-31 11:51:44

This means (to me) that some race conditions exists ones during boot - and that the problem isn't actually a real one</system></pfsense></developerspew>

PiBa

Thanks Gertjan,
In my reproduction i'm sure it said 'DIOCADDALTQ' when i managed to reproduce 'something similar' and i guess i didn't look close enough at the actual message provided, i have changed my pull-request to include 'DIOCXCOMMIT'. Should be working for both cases now.

p.s. its without the space character before the colon right.?.

Gertjan

@PiBa:

p.s. its without the space character before the colon right.?.

"strstr" to "DIOCXCOMMIT" will do ^^

esquire1968

@Gertjan

Fantastic! Changing DIOCADDALTQ to DIOCXCOMMIT works!

Cheers
Thomas