pfSense

What depends on this?

It's trivial to fix this, but it deviates from upstream. In upstream the rule output always looks like '@4 block ...'. So there's no '(0)' there. The '(0)' in our tree is a remnant of our tracker patch that I failed to remove.

So the question is: do we change pfctl to print the ridentifier in '4@(ridentifier)', or do we change whatever depends on this to parse the tracker id from the ridentifier keyword (which I thought I'd done everywhere), and more closely align with upstream.

If it's just a leftover remnant then I agree we should remove it. The ridentifier is already visible on the line and appears to be used by things in the GUI already (e.g. looking up rules in the firewall logs). So I don't think it's necessary, just stands out that it is there without a valid value and potentially confusing to users inspecting the raw log.

There are a few regex patterns that expect that part of the output to be there but those can be updated as needed. There are a couple that will need updated to account for the change in output, like source:src/etc/inc/syslog.inc#L1212 and source:src/etc/inc/syslog.inc#L1246 at least. I don't see any others when looking/searching in the source but it's possible there may be some in packages like pfBlocker.

There are some users who are experiencing issues with pfSense recording the Tracker ID as "4294967295" which according to conversations with Jim Pingle

I'm not sure why that number would be in the log, but it's 2^32-1 so probably the variable is empty/uninitialized or being overrun (value is
higher than can be expressed in that size of a variable).

For pfBlockerNG, I have code that fixes this syntax change in the pfctl -vvsr output, and for most users it has fixed the logging issues. However, there are some who are still experiencing issues. I have contacted a few and they all seem to be on AMD64 hardware. I have also as per the request of Jim Pingle define the Tracker ID as an integer and also ensure that the ID is limited to a max of 10 characters, but this didn't resolve their issues.

See here:
https://www.reddit.com/r/pfBlockerNG/comments/svpx5m/no_logs_for_ip_blocks/

That is unlikely to be related to this. The code that parses the rules for the GUI already catches the proper rtracker value. Their ID is wrong in the raw log, which would be a different problem. This specific issue is only cosmetic in the raw pfctl output at this point.

https://gitlab.netgate.com/pfSense/FreeBSD-src/-/merge_requests/55
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/640

These two should be merged together.