New pfblockerNG install Database Sanity check Failed
-
@BBcan177 I am not a programmer. But a simple "sort -u" of the deny files entries bring them back to 81362. Just saying...
-
@marchand-guy Did you compare your
pfblocker.shto the appropriate branch version?What version of pfSense? What version of pfBlockerNG/-devel?
-
@tinfoilmatt
2.8.0-RELEASE (amd64)
built on Wed May 21 19:12:00 EDT 2025
FreeBSD 15.0-CURRENTThe system is on the latest version.
Version information updated at Sat May 31 15:09:52 EDTpfBlockerNG net 3.2.8
(yes I tried the -devel version prior to this one. no difference) -
I'm seeing the same off-by-one error on my system. I'm running the same versions as marchand.guy.
What is the impact of this error? Does it prevent any functionality?
-
@SteveITS Still seeing this error myself but have no further info. It does seem to function, just with the error being shown when it updates/reloads.
-
I was experiencing the same issue too.
After comparing /usr/local/pkg/pfblockerng/pfblockerng.sh from 3.2.0 to 3.2.8, there was only 1 line that changed and it happened to be related to this issue. After reverting that line (#1281) back to the way it was in 3.2.0, the "Sanity Check" works as expected.
Here are the lines as they exist in their respective versions.
#Line 1281 in 3.2.0 if [ "${s1} == ${s2}" ]; then #Line 1281 in 3.2.8 if [ "${s1}" == "${s2}" ]; thenEdit: Corrected my references to pfBlockerNG version numbers. Thanks @Maltz
-
@TheXman Wouldn't the 2.7.2 version always evaluate as true, since the string is non-null? It looks like the sanity check was fixed in 2.8.0, exposing some other issue that may have been there all along but was hidden by the broken sanity check.
(Edit: I guess the version numbers should be 3.2.0_8 and 3.2.8, respectively, since we're talking about pfBlockerNG and not pfSense itself.)
-
@Maltz That is an excellent hypothesis!
-
@marchand-guy Verified hypothesis. The code always reported true before 3.2.8.
Good catch -
Looks like dev (@BBcan177) is already reviewing. Good teamwork, y'all.
Responsible commit here. Remark indicates it was a cleanup commit. I don't have the coding skills to say for sure, but this
pfblocker.phpupdate and thispfblocker_alerts.phpupdate look odd for some reason, in addition to whatever thepfblockerng.shL1281 fix exposed. -
I think I found the last issue. The "masterfile" is a list of Filename/IPs. The "mastercat" file is just the IPs only. So it was trying to grep -v (exclude) any lines that start with the placeholder IP. So we need to change the masterfile to the mastercat in this line.
Try to change this line from:
From:
s1="$(grep -cv ^${ip_placeholder2}$ ${masterfile})"To:
s1="$(grep -cv ^${ip_placeholder2}$ ${mastercat})" -
@BBcan177 Thank you!
-
@BBcan177 Success!
Database Sanity check [ PASSED ]
-
@Maltz How?
No change on pfsense. -
@marchand-guy I manually made the change to the shell script that BBcan177 described.
-
@BBcan177 so next step is a new package for pfSense?
-
@Maltz said in New pfblockerNG install Database Sanity check Failed:
@marchand-guy I manually made the change to the shell script that BBcan177 described.
Ok, done as well.
Thanks -
Thanks, @BBcan177.
Some clear confusion ITT re pfSense system version and pfBlockerNG package version numbers. For posterity:
pfSense 2.7.2 CE - Database Sanity check issue not present, because
pfBlockerNGandpfBlockerNG-develpackages are both on "RELENG_2_7_2" branch ofpfSense / FreeBSD-PortspfSense 2.8 CE - Database Sanity check regression, possibly because branch updated to "devel" for both packages?
(
RELENG_2_7_2branch:pfBlockerNG/pfBlockerNG-devel)
(develbranch:pfBlockerNG/pfBlockerNG-devel)I think that's what's happened. Maybe someone can give me a sanity check.
The package version numbers appear to have been realigned in pfSense 2.8 CE however. The last package versions of
pfBlockerNGandpfBockerNG-develon pfSense 2.7.2 CE were3.2.8and3.2.0_20respectively.But under 2.8 CE, both packages are now currently on version
3.2.8(pfBlockerNGandpfBlockerNG-devel).Will both packages continue to be maintained separately and we should expect version numbers to potentially diverge again?
