Created attachment 252376 [details] Silence a bogus warning when starting up Silence a bogus warning when starting up: Anchor 'blacklistd' not found. The anchor is indeed there, and working correctly. To my untrained eye, it looks like a bug in pfctl.c (see the attached diff with the sample pf.conf): # pfctl -a blacklistd -sa | grep XXX pfctl: XXX DIOCGETETHRULES: No such file or directory pfctl: XXX DIOCGETRULES: Invalid argument pfctl: XXX DIOCGETRULES: Invalid argument pfctl: XXX DIOCGETRULES: Invalid argument The warning from blacklistd stems from: # pfctl -a blacklistd -sA XXX Anchor 'blacklistd' not found. Evidently the anchor is there, it's just "empty", and the warning seems misleading. # /usr/libexec/blacklistd-helper add blacklistd tcp 198.51.100.0 24 22 1 # pfctl -a blacklistd -sA blacklistd/22 It might be related to bug #262590.
Created attachment 252377 [details] Sample pf.conf
Created attachment 252378 [details] pfctl.c diff Illustrate the paths involved.
This seems ok to me, though not really ideal. I'm not sure I fully understand what's happening under the hood - how would one recreate this error using only pfctl?
(In reply to Mark Johnston from comment #3) There are two issues: 1. The main issue: blacklistd-helper should discard stderr when invoking the flush action (it already does for the add action). This has been submitted upstream (https://github.com/zoulasc/blocklist/pull/11). The attached patch has the proposed fix (just sweep the warnings under the rug). 2. The warnings in pf: 2.1. Use the attached sample pf.conf: it contains a "blacklistd/*" anchor, any anchor will do. 2.2. First test: After reloading the rules, issue: # pfctl -a blacklistd -sA Anchor 'blacklistd' not found. The anchor exists, and it works as it should. Seeing this message in the dmesg the first time threw me off a little, thinking blacklistd was not going to be able to add blocking rules (this can be silenced by applying step 1). I *think* this is one bug in pfctl. 2.3. Issue pfctl, specifying the anchor with all modifiers, just focusing on the warnings/errors: # pfctl -a blacklistd -sa 1> /dev/null pfctl: DIOCGETETHRULES: No such file or directory pfctl: DIOCGETRULES: Invalid argument pfctl: DIOCGETRULES: Invalid argument pfctl: DIOCGETRULES: Invalid argument I would guess this is another bug in pfctl. 2.4. Optionally, use the attached pfctl.c diff, that allready has "XXX" marks on the paths that trigger the warnings above. Note that pf works fine, the warnings just don't seem right (to the untrained eye).
Created attachment 252829 [details] Response to comment #3 Perhaps it is just easier to patch the anchor test: To me these two checks should pass.
The "fix" in blacklistd/blocklistd has been committed upstream. It should land on FreeBSD soon(TM). Retitling the bug to pfctl specific.
Created attachment 259593 [details] Rough patch to illustrate the bug The issue appears to be that "-A" calls pfctl_show_anchors() and then pfctl_show_eth_anchors(). If an anchor is *not* an ethernet anchor, for example, pfctl_show_eth_anchors() will throw an error. Attached is a draft patch that, unifies both functions. When enough time is found to polish it, it will be submitted for review. In the meantime, post it here, obsoleting all previous attachments. Thank you!