Bug #12868
closed
Output from ``pfctl -vvsr`` does not include ``ridentifier`` value in the expected location
0%
Description
On 22.01/2.6.0 when looking at the ruleset with pfctl -vvsr the tracker/ridentifier ID should be in parenthesis after the pf rule number. On current versions it's outputting 0 there instead of the ridentifier value.
On 22.01/2.6.0:
@4(0) block drop in log inet all label "Default deny rule IPv4" ridentifier 1000000103
On previous versions it looked like this:
@5(1000000103) block drop in log inet all label "Default deny rule IPv4"
The only difference in the generated ruleset is the change from tracker to ridentifier:
22.01/2.6.0:
block in log inet all ridentifier 1000000103 label "Default deny rule IPv4"
Previous versions:
block in log inet all tracker 1000000103 label "Default deny rule IPv4"
Updated by Kristof Provost almost 3 years ago
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.
Updated by Jim Pingle almost 3 years ago
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.
Updated by BBcan177 . almost 3 years ago
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/
Updated by Jim Pingle almost 3 years ago
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.
Updated by Kristof Provost almost 3 years ago
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.
Updated by Jim Pingle almost 3 years ago
- Status changed from New to Resolved
This was merged a while ago and has been working fine.
The (0) bit after the pf rule number is no longer present, which is the intended current behavior.