pfSense » pfSense Packages

• Note: A similar crash was reported last Feb, but this crash has a different cause

Crash report begins. Anonymous machine information:

arm64
16.0-CURRENT
FreeBSD 16.0-CURRENT #31 plus-RELENG_26_03-n256531-4923e82e59d1: Fri Mar 20 18:23:20 UTC 2026 root@pfsense-build-release-aarch64-2.eng.atx.netgate.com:/var/jenkins/workspace/pfSense-Plus-snapshots-26_03-main/obj/aarch64/MQoBNSRa/var/jenkins/workspace/

Crash report details:

PHP Errors:
[26-Apr-2026 11:12:48 Canada/Eastern] PHP Fatal error: Uncaught ValueError: ip2long(): Argument #1 ($ip) must not contain any null bytes in /etc/inc/util.inc:1443
Stack trace:
#0 /etc/inc/util.inc(1443): ip2long()
#1 /etc/inc/util.inc(1386): is_ipaddrv4()
#2 /usr/local/www/suricata/suricata_blocked.php(399): is_ipaddr()
#3 {main}
thrown in /etc/inc/util.inc on line 1443

No FreeBSD crash data found.

Additional info:

Netgate 2100 pfSense+
26.03-RELEASE (arm64)
built on Wed Apr 1 13:20:00 EDT 2026
FreeBSD 16.0-CURRENT
Suricata 7.0.8_13

General sequence of events:

I have 2 suricata interfaces, only 1 has blocking (legacy mode) turned on.
They each have unique rule catagories selected (i.e. the same rule catagory is never selected in both interfaces).
After updating to 26.03 (including an update to suricata), only the interface that didn't have blocking turned on would start and run, the other would not start anymore.
I found that if I disabled the "Feodo Tracker Botnet C2 IP Rules" and the "ABUSE.ch SSL Blacklist Rules", that interface would now start and remain running again - I never experimented further to determine if it was one or both of those that was involved.
I'm pretty sure I was able to view the "Blocks" tab normally after doing this, but I'm not certain of that.
I went in a few days later to browse alerts, blocks, and this is when the crash on "Blocks" tab occurred. This happens 100% of the time since then, with the same/identical crash report each time.

AI's 2 cents worth:

Thought I'd try AI, very helpful actually... with all things below tried, it says the older version of pfSense was not as strict in parsing, and the newer PHP functions like ip2long() throws a fatal error rather than ignoring certain issues like they did before. If says the problem (and fix needed) is in suricata, it suggests code changes for suricata_blocked.php related to the handling/parsing of data from blocked.log and/or eve.json.
AI suggested specific suricata code changes but I did not touch the code, I shall leave all this info in the hope it will be corrected properly and... quickly ;)

The following has been checked/tried/confirmed:

- block.log files all checked for corruption, oversize - no issues found
- block.log files - all (there was 1) were deleted, suricata restarted
- eve.json and fast.log - files not found (wildcard delete was run)
- Rules - force update, suricata restarted
- IP Reputation - has always been disabled
- EVE JSON log - has always been disabled
- Reinstall suricata (and the suricata rules were disabled in one of the interfaces, as they always get turned on in all interfaces after install/updates rather than remembering the config - another minor bug or change request)
- Browser cookie and cache cleared
- PF table snort2c checked for corruption - no issues found
- Block offenders turned off, suricata restarted - problem still exists
- Netgate 2100 rebooted