Bug #16590
closed
Uncaught TypeError in /etc/inc/filter.inc:5828
0%
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?
Updated by znerol znerol 28 days ago
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().
Updated by znerol znerol 28 days ago
This rule has been there since my earliest available backup of the affected system dating back to August 2017.
Updated by znerol znerol 28 days ago
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.
Updated by Jim Pingle 28 days ago
- 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.
Updated by Marcos M 28 days ago
- 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.
Updated by Anonymous 24 days ago
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.
Updated by Marcos M 23 days ago
A config without any rules could not result in the reporter error. You may share the config (along with the full PHP error report) that produces the error after restore by uploading it to the following link and I can take a closer look:
https://nc.netgate.com/nextcloud/s/2b8XKM8tZgMXakB
Updated by Anonymous 22 days ago
Thank you very much. Do you mean the full configuration or just the firewall configuration? I have a backup without rules that can be used to reproduce the error. There are only two rules in this backup, namely the automatic rule via the “Block bogon networks” switch in the two WAN interfaces. Since I had to roll back the system, I don't have a full PHP log. The saved log shows the following:
PHP Fatal error:
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 in /etc/inc/filter.inc on line 5828
Translated with DeepL.com (free version)
Updated by Anonymous 21 days ago
The error was identified and fixed. Following your suggestion, I compared two backup files, one with firewall rules and one supposedly without firewall rules. It was clear that, although all rules had been deleted in the GUI, there were still rules in the backup file that had long since been removed from the GUI and were no longer visible there. It is not clear why these rules were not correctly removed from the configuration. Perhaps an error in an earlier version?
After all suspicious rules were manually removed from the backup file and this file was restored to the system (25.07.1), the upgrade to 25.11 could be carried out without any errors.
As can be seen above, suspicious rules can be identified by the following entry, among others:
<network>optXXXX</network>