Problem with update pfBlockerNG-devel 3.2.0_18 to 3.2.0_20

alan_touring

After up the update I get a pfsense crash report

PHP ERROR: Type: 1, File: /usr/local/pkg/pfblockerng/pfblockerng.inc, Line: 5347, Message: Uncaught TypeError: Cannot access offset of type string on string in /usr/local/pkg/pfblockerng/pfblockerng.inc:5347
Stack trace:
#0 /usr/local/www/pfblockerng/pfblockerng_alerts.php(1736): pfb_collect_localhosts()
#1 {main}
  thrown

I've tried reinstalling the package, but same error message. I have all "Recommended System Patches for Netgate pfSense software version 2.7.2" applied. Any suggestions?

Gertjan

@alan_touring

At line 5347, do you see this :

Can't see how that fails.
Do you have any static DHCP leases ?

alan_touring

@Gertjan
I have static DHCP leases but it seems everyrhing is configured correctly. I haven't change anything on my pfsense besides updating pfblockerNG. Besides the crash report message, pfblockerNG is working fine, its just the crash report messages that are bugging me.

alan_touring

I identified the cause of the error. After backing up the running configuration, I compared the XML files from previous backups. It turned out that, for some reason, my pfSense configuration contained an extra "<opt3></opt3>" line. Once I removed that line and restored the corrected config file, the issue was resolved. No more crash reports.

Gertjan

@alan_touring

Ok, that explains.
The function "pfb_collect_localhost()" checks all known interfaces for DHCP and other settings to collect local IP addresses used.
If an interface is declared, but empty (no settings what so ever), then the error you've shown is totally understandable.

Btw : this is not a pfBlockerNG bug : the <OPT3> shouldn't be there.

Seeking Sense

This post is deleted!

Seeking Sense

@Gertjan said in Problem with update pfBlockerNG-devel 3.2.0_18 to 3.2.0_20:

If an interface is declared, but empty (no settings what so ever), then the error you've shown is totally understandable.

Can you elaborate (simply if possible ).

I have multiple interfaces. (WAN, LAN, VLANs, WireGuard)

Running:

FreeBSD 14.0-CURRENT amd64 1400094 #1 RELENG_2_7_2-n255948-8d2b56da39c: Wed Dec  6 20:45:47 UTC 2023

pfBlockerNG-devel 3.2.0_20

I am experiencing the following PHP Error:

PHP Errors:
[14-Jan-2025 13:49:22 America/New_York] PHP Fatal error:  Uncaught TypeError: Cannot access offset of type string on string in /usr/local/pkg/pfblockerng/pfblockerng.inc:5347
Stack trace:
#0 /usr/local/pkg/pfblockerng/pfblockerng.inc(5571): pfb_collect_localhosts()
#1 /usr/local/pkg/pfblockerng/pfblockerng.inc(1036): pfb_daemon_filterlog()
#2 {main}
  thrown in /usr/local/pkg/pfblockerng/pfblockerng.inc on line 5347

pfBlocker Filter Service then stops running.

alan_touring

@Seeking-Sense said in Problem with update pfBlockerNG-devel 3.2.0_18 to 3.2.0_20:

Can you elaborate (simply if possible ).

Exemple:

<opt7>
</opt7>

instead of:

<opt7>
<descr>
<![CDATA[ SWITCHS ]]>
</descr>
<if>igb1</if>
<enable/>
<ipaddr>192.168.1.1</ipaddr>
<subnet>24</subnet>
<spoofmac/>
</opt7>

If you declare an interface but leave it empty, like in the first example, I was getting the PHP ERROR. I just open the XML and deleted the

<opt7>
</opt7>

and problem solved. I don't know if your problem is the same as mine, but worth a shot.

Seeking Sense

@alan_touring Hi!

Thank you for the clarification. That did not seem to be the issue that I was dealing with.

However the follow seemed to resolve the issue.

@jazzl0ver said in Error on pfblockerng.inc:5310 pfBlockerNG-devel 3.2.0_5:

@octopilami I was able to fix it by adding this extra check:
if (isset($dhcp['staticmap']) && is_array($dhcp['staticmap'])) {

See the following post for file and line location:

@Seeking-Sense said in Problem with update pfBlockerNG-devel 3.2.0_18 to 3.2.0_20:

Gertjan

@Seeking-Sense

Can you add the file, and line number ?

Seeking Sense

@Gertjan

The file is:

/usr/local/pkg/pfblockerng/pfblockerng.inc

The line number (which is subject to change ) is

Changed

 if (is_array($dhcp['staticmap'])) {

To

if (isset($dhcp['staticmap']) && is_array($dhcp['staticmap'])) {

Gertjan

@Seeking-Sense said in Problem with update pfBlockerNG-devel 3.2.0_18 to 3.2.0_20:

if (is_array($dhcp['staticmap'])) {

Ok, thanks.

Still, for my own curiosity, I still cant see why it failed.

The line above states :

	// Collect static DHCP hostnames/IPs
	foreach (config_get_path('dhcpd', []) as $dhcp) {
		if (is_array($dhcp['staticmap'])) {

The foreach asks for the list of array() in <dhcpd>
It should return a list with <staticmap> </staticmap>, as these are your static lease entries.

So, no need to test inside the foreach loop if arrays exist, as if there were none, the inner loop couldn't be reached in the first place.

My question : do you have an invalid entry somewhere inside the <dhcpd> .. </dhcpd> section ?

This is what I have ( I removed some info ) :

	<dhcpd>
		<lan>
			<range>
				<from>192.168.1.70</from>
				<to>192.168.1.200</to>
			</range>
			<defaultleasetime>21600</defaultleasetime>
..... babla
			<numberoptions></numberoptions>
			<staticmap>
				<mac>00:4e:01:ac:ca:9c</mac>
				<cid>bureau2</cid>
				<ipaddr>192.168.1.2</ipaddr>
				<hostname>bureau2</hostname>
.... more blabla
				<uefihttpboot></uefihttpboot>
				<numberoptions></numberoptions>
			</staticmap>
			<staticmap>
				<mac>ac:15:a2:02:d0:0b</mac>
				<cid>TL-SG108E</cid>
				<ipaddr>192.168.1.3</ipaddr>
				<hostname>TL-SG108E</hostname>
.... bla goes on

				<nextserver></nextserver>
				<filename32></filename32>
				<filename64></filename64>
				<filename32arm></filename32arm>
				<filename64arm></filename64arm>
				<uefihttpboot></uefihttpboot>
				<numberoptions></numberoptions>
			</staticmap>
			<mac_allow></mac_allow>
			<mac_deny></mac_deny>
			<nextserver></nextserver>
			<ddnsdomainprimary></ddnsdomainprimary>
			<ddnsdomainkeyname></ddnsdomainkeyname>
.. more dhcp general setting
			<ddnsdomainsecondaryport></ddnsdomainsecondaryport>
			<dnsregpolicy>default</dnsregpolicy>
			<earlydnsregpolicy>default</earlydnsregpolicy>
			<ntpserver>192.168.1.1</ntpserver>
		</lan>
		<opt1>
.... and here we go again, for the second interface (if it exists)
.....
		</opt1>
	<dhcpd>

Btw : I now also see that the original issue, some error in the dhcpd IPv4 list of static leases was not the same as I had.
My errors came from the <dhcpdv6> section, which comes just after line 5347.
The array list with static lease info was correct, but the indic=vidual IPv6 address were plain wrong, like "::c6" instead of a complete, real IPv6 : example

			<staticmap>
				<duid>00:01:00:01:1e:6a:44:de:64:00:6a:8b:f1:b3</duid>
				<ipaddrv6>::c9</ipaddrv6>
				<hostname>bureau</hostname>
				<descr><![CDATA[Bureau]]></descr>
				<filename></filename>
				<rootpath></rootpath>
			</staticmap>