PHP error report on opening pfBlockerNG page in GUI

infomml

Hi,
i recently had to reinstall pfsense due to a hardware error. System before crash was 2.5.2. After installing 2.7.2, restoring the backup and reinstalling the packages i get an error opening the pfBlockerNG page in the GUI, pfsense shows an error as follows:

******Crash report begins. Anonymous machine information:
amd64
14.0-CURRENT
FreeBSD 14.0-CURRENT amd64 1400094 #1 RELENG_2_7_2-n255948-8d2b56da39c: Wed Dec 6 20:45:47 UTC 2023 root@freebsd:/var/jenkins/workspace/pfSense-CE-snapshots-2_7_2-main/obj/amd64/StdASW5b/var/jenkins/workspace/pfSense-CE-snapshots-2_7_2-main/sources/F

Crash report details:
PHP Errors:
[13-Dec-2023 08:30:42 Europe/Berlin] PHP Fatal error: Uncaught TypeError: Cannot access offset of type string on string in /usr/local/www/pkg_edit.php:675
Stack trace:
#0 {main}
thrown in /usr/local/www/pkg_edit.php on line 675
[13-Dec-2023 09:07:32 Europe/Berlin] PHP Fatal error: Uncaught TypeError: Cannot access offset of type string on string in /usr/local/www/pkg_edit.php:675

No FreeBSD crash data found.******

Does anyone know this behaviour and a way around the problem?

Best regards,
Michael.

shabsta

Similar issues after upgrading to latest version of pfsense yesterday.

jrey

@infomml

Specifically which page are you trying to open ?

the error line referenced is more generic in nature.

edit:
what do you get navigating to this page directly?

https://your_pfsense_ip/pfblockerng/pfblockerng_general.php

jrey

@shabsta

Similar issues

similar could imply not exactly the same.
is the error exactly the same as OP?

What version did you upgrade from ?

shabsta

@jrey - upgrade was from 2.6 to current 2.7.2

jrey

@shabsta

and is the error exactly the same as OP ?

What happens when you do the test I suggest?

Edit: your case could be different than OP because you did an upgrade. whereas OP was a fresh system install, restoring a backup and reinstalling packages - completely different path to an error.
If the end result (error) is exactly the same in both cases that's one thing, if the results is different that's a different thing.

Thanks

Gertjan

@infomml said in PHP error report on opening pfBlockerNG page in GUI:

/usr/local/www/pkg_edit.php:675

Strange.

pfBlockerng, when accessed :

(see browser bar at the bottom, left)
accesses :
https://pfsense.tld/pfblockerng/pfblockerng_general.php

Not something like https://pfsense.tld/pkg_edit.php

Maybe it did, way in the past, in the pfBlockerng baby years.

What is the installed version ?

Did you retrieve a very ancient config.xml ?

edit : you did.

Try this : remove the pfgSense pfBlockerng package.
I would advise you to check "Keep settings" first :

but I'm not sure if you can access that option.

Then re install pfBlockerng.

jrey

@Gertjan said in PHP error report on opening pfBlockerNG page in GUI:

Then re install pfBlockerng.

Won't tell us what part of the config is a problem.

In the OPs case it was a fresh install, restore backup and reinstalling packages.

In the other case - it was an upgrade

so the path they arrived at the destination is completely different.

Note: the only change in the _7 release was one line related to config settings. So it might be better long term to determine if that is part of the problem when restoring or upgrading from "older versions"

Gertjan

@jrey said in PHP error report on opening pfBlockerNG page in GUI:

Won't tell us what part of the config is a problem.

That's the easy part ^^

Look at your own config.xml file :

This menu entry is present in my config.conf file. Note the difference.

When I saw .../pkg_edit.php .... I knew this was a trace of a very old pfBlockerng install.

For example, when I visit right now my pfSense FreeRadius package main setup page, it still uses the .../pkg_edit.php page.
Less far away in the past, the pfBlockerng package updated all these menu access entries for the newer ones.
Somehow, I guess, @infomml never installed this upgrade. so his config.xml was still using the old info. And install the package 'from scratch' using the current package didn't update these parts in the config file.
And that will pop up the PHP errors.

jrey

@Gertjan said in PHP error report on opening pfBlockerNG page in GUI:

That's the easy part ^^

Then there will be more (and it will/may impact not only pfB but other pkgs as well.

However "reinstalling packages" as noted by the OP or "upgraded" as noted by the second poster, should have already fixed the menu entry. So the question will be why not?

They are different cases. In order to fix long term, we need to see if we can say "Why?"

It the case of the first poster it is likely an order of doing things. We don't have any idea which order the steps were done.

We actually don't even know if both posters have exactly the same issue. they clearly took a different path getting where they are.

Similar is not necessarily exactly the same.

I'm not disagreeing with you just trying to get more details.

I'm trying to look with a wider scope for the cause, you're trying to fix a 1 off which is fine.. But then it happens over and over for anyone else in the same situation.

Both parties having an issue are entirely welcome to take whichever path they want of course.

Carry on.

Gertjan

@jrey said in PHP error report on opening pfBlockerNG page in GUI:

However "reinstalling packages" as noted by the OP or "upgraded" as noted by the second poster, should have already fixed the menu entry. So the question will be why not?

The 'default' GUI menu bar is populated with what is found in some core GUI file /look in /etc/inc/ or in the root webserver folder).
Packages can use .... at least two methods, as far as I know it.
I've sited two of them : the recent pfBlockerng uses a method, and FreeRadius still uses the old method.

What happened :
A new pfSEnse 2.7.2 was installed.
Then : the config.xml file was imported, this file was created with a 2.5.2 version. That file contains the .../pkg_edit.... menu entries.
During the import of this config.xml file, a list with packages was found, one of them was pfBlockerng.
t that moment, the most recent pfBlockerng gets installed.

The issue : this new pfBlockerng install didn't update the 'menu part' (shown above) of the pfBlockerng config.
So the pfBlockerng menu 'points' to a php file that doesn't exist (doesn't have an entry) => fail.

Btw : True , I don't have an 2.5.2 to play with, neither a very ancient version of pfBlockerng to test drive my words.

jrey

@Gertjan

easy enough for me try this,

but the order the OP said he did things in is

After installing 2.7.2, restoring the backup and reinstalling the packages

you're just for clarity in those steps your suggesting that

OPs steps as we know them:

After install 2.7.2
restoring the backup, would have restored the config and completed this step at which point you said "During the import of this config.xml file, a list with packages was found, one of them was pfBlockerng.
in that moment, the most recent pfBlockerng gets installed."
then OP said reinstalled the packages

So that being the case. wouldn't number step 3 be the reinstall you are asking about now. have already been done.

again I was't disagreeing with you when I said:

It the case of the first poster it is likely an order of doing things. We don't have any idea which order the steps were done.

~~I should know in a few minutes if the "pkg" is broken and doesn't adjust the menu on a reinstall.~~

so I purposely broke the menu and confirmed it was broke by pointing it to the same page pkg_edit.php. Yup broken

Then reinstalled the pkg
(the same as what should have happened in both OP steps 2 and 3 as listed)

2 MiB to be downloaded.
[1/1] Fetching pfSense-pkg-pfBlockerNG-3.2.0_7.pkg: ...... done
Checking integrity... done (0 conflicting)
[1/1] Reinstalling pfSense-pkg-pfBlockerNG-3.2.0_7...
[1/1] Extracting pfSense-pkg-pfBlockerNG-3.2.0_7: .......... done
Removing pfBlockerNG components...
Menu items... done.
Services... done.
Loading package instructions...
Removing pfBlockerNG... All customizations/data will be retained... done.
Saving updated package information...
overwrite!
Loading package configuration... done.

The menu most certainly got updated by the pkg.
right at this step Menu items... done. and it works.
so not likely an issue with the pkg.
so in the OPs step 2 where the restore was done (as you suggest automatically) and then again in step 3 subsequent reinstall

should have properly adjusted the menu.

Works for me.

Then I took the menu completely out, and reinstalled the pkg.
the menu
still got corrected.

Removing pfBlockerNG components...
Menu items... done.
Services... done.

so doesn't appear to be a pkg not "fixing" the menu type issue in this case.

Gertjan

@jrey said in PHP error report on opening pfBlockerNG page in GUI:

Works for me.

Thanks for doing the test.

Now I do presume the OP installed pfBlockerng ( pfSense-pkg-pfBlockerNG-3.2.0_7. ).
This part "Menu items... done." is /should update menu settings.

The thing is : when going to the main pfBlockerng page, this (his) "../pkg_edit.... menu" shouldn't exist. The error shouldn't happen.
What makes me saying : the actual loaded ?! config isn't correct. And thus : installing didn't update his menu entrie(s).
So, OP, what's in your config.xml : export it, and look up what I've showed above (the image fragment of the config.xml) ?
Maybe a reboot will straiten things out ?

jrey

@Gertjan said in PHP error report on opening pfBlockerNG page in GUI:

pfSense-pkg-pfBlockerNG-3.2.0_7.

Not a bad question, but also the way the packages work now on the new structures - also the only choice.
At 2 points in the cycle we have agreed the package was updated (Step 2 and again at Step 3)

"../pkg_edit.... menu" shouldn't exist.

But it does! Other packages still use it!! I have one such package installed.. and thus was able to recreate the exact observation. That is not the issue.

Again there is no disagreement from me that the menu option is wrong in the config, and yes we see the effect of the issue because of it.

Running this directly - may tell us more

https://your_pfsense_ip/pfblockerng/pfblockerng_general.php

Yes if a reboot post upgrade has not been completed, OR if the op has not simply logged out, closed the browser and then logged back in the current running dashboard might be using the old menu.
Two possible items here.
1st the system then didn't update at the step 2 (reload of config),
and
2nd the OP either hasn't rebooted or logged out since the update (fair question)

a post upgrade reboot is always recommended, HOWEVER depending on the hardware you should not do that for at least 15 minutes. I always wait an hour (for no good reason, just the way it works out here). Even with that longer delay, I have never noticed a problem with accessing the menu before completing that post update reboot.

For all we know, the OP has done something else at this point and it is working or not.