Bug #16590
closed
Uncaught TypeError in /etc/inc/filter.inc:5828
Added by znerol znerol 5 days ago.
Updated 1 day ago.
Description
I get this when attempting to Upgrade to pfSense Plus 25.11:
PHP ERROR: Type: 1, File: /etc/inc/filter.inc, Line: 5828, Message: Uncaught TypeError: Cannot access offset of type string on string in /etc/inc/filter.inc:5828
Stack trace:
#0 /etc/inc/filter.inc(1007): filter_rules_generate()
#1 /etc/rc.bootup(327): filter_configure_sync()
#2 {main}
thrown @ 2025-12-17 07:58:27
Boot verification failed for default. Netgate pfSense Plus was automatically rebooted back into default_20251217075256. @ 2025-12-17 08:00:50
Is there a way to retrieve the affected boot environment from that device for local inspection?
I found the following rule in config.xml:
<rule>
<type>pass</type>
<max-src-nodes></max-src-nodes>
<max-src-states></max-src-states>
<statetimeout></statetimeout>
<statetype><![CDATA[keep state]]></statetype>
<os></os>
<source>
<network>optXXXX</network>
</source>
<destination>
<any></any>
</destination>
<descr></descr>
<tracker>1423079562</tracker>
</rule>
This rule doesn't have any <interface> tag. I assume that this might cause Problems due to array_set_path in get_filter_rules_map().
This rule has been there since my earliest available backup of the affected system dating back to August 2017.
I assume this is a bug in my config. The thing that changed between 25.07 and 25.11 in this regard is the big config rule order refactoring This probably just surfaced the bug in my config.
- Category changed from PHP Interpreter to Rules / NAT
- Assignee set to Marcos M
It's unusual to have a rule without an interface tag entirely, even floating rules that act on any interface have one set to any.
Even if it is due to that unexpected configuration content, it would be good to handle that case more smoothly. Or possibly remove such invalid rules on upgrade.
- Status changed from New to Rejected
Some number of versions ago floating rules did not require the interface element. There's already upgrade code for config revisions 223_to_224 which handles this. We could potentially also handle this in the upgrade function that always runs. However that may not actually help depending on how the config ended up in that state; the upgrade code won't run if the config file is manually modified (rather than e.g. using the config restore in the GUI).
I think that kind of issue should be dealt with in an individual basis since there are potentially other config upgrade steps that were never applied. Given this I don't think there's anything for us to do. However if it's shown that this issue can be reproduced without manual config modification then we can revisit it.
My suggestion is to take the old config with that rule and set the revision to 22.3 then run it through the config upgrade playback script - and double-check that any changes made look OK.
- Assignee deleted (
Marcos M)
This error does not appear to be related to the rules. I was able to reproduce the same error and tried the following: 1. Disable the pfBlockerNG and delete ALL Rules on the Box (25.07.1). Then I created a complete backup and install a fresh version (25.11). After that, I restored the backup, without the firewall rules. As a result, just like a normal upgrade with firewall rules, it runs into this error and seems to be independent of the firewall rules.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by