Re: "pfctl: DIOCADDRULENV: File exists" after update to v14.3-RELEASE-p2 from v13.5-RELEASE-p3

From: Anubhav/FreeBSD <anubhav+freebsd_at_hawaii.edu>
Date: Fri, 12 Sep 2025 19:45:40 UTC
On Fri, Sep 12, 2025 at 9:37 AM Chris   wrote:
> On 2025-09-12 00:04, Anubhav/FreeBSD wrote:
> > On Thu, Sep 11, 2025 at 8:29 PM Anubhav/FreeBSD   wrote:
...
> >> After direct OS update from v13.5-RELEASE-p2 to v14.3-REELASE-p2 via
> >> freebsd-update(8), I got a message during booting into v14.3 (from "dmesg
> >> -a"; same is also  in /var/log/console.log):
...
> >> [105.666161] Enabling pfrules cleared
> >> [105.671398] nat cleared
> >> [105.671407] 0 tables deleted.
> >> [105.672823] 0 states cleared
> >> [105.674735] source tracking entries cleared
> >> [105.674816] pf: statistics cleared
> >> [105.674819] pf: interface flags reset
> >> [105.679224] pfctl: DIOCADDRULENV: File exists
> >> [105.680156] /etc/rc: WARNING: Unable to load /etc/pf.conf.custom
> >> ...
> >>
> >> /etc/rc.conf has:
> >>
> >> pf_enable="YES"
> >> # Flush all
> >> pf_flags="-F all"
> >> pf_fallback_rules='pass all'
> >> pf_rules='/etc/pf.conf.custom'
...
> >> After I saw that message, verified via "pfctl -v -v -s rules" that
> >> indeed no rules had been loaded.
> >>
> >> A dry run, "pfctl -n -v -v -f /etc/pf.conf.custom", did not  produce
> >> any issue that could be due to the rules; without "-n" option,
> >> rules were loaded without issues.
> >>
> >> Same thing had happened on another machine with same enough hardware (CPU,
> >> motherboard, (at least amount of) RAM, & use of SSD to boot OS) with same
> >> 14.3-RELEASE-p2.
> >
> > I rebooted the "another machine" -- call it "2nd machine" -- to check
> > if the issue would happen again on warm reboot. It did not.
> >
> > Does that mean some kernel state persisted enough during booting
> > into v14.3 from v13.5 that loading of pf rules had failed?
...
> FWIW I seem to recall a similar message. The cause of which was a bad
> (malformed) entry in one of our tables.

I had not seen any log message from "pf" machinery about malformed
entry; neither "pfctl" had complained about that when manually loading
the rules.

In any case, if there would be such a malformed entry, what would I
need to do to find it?


- Anubhav