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

On 2025-09-12 00:04, Anubhav/FreeBSD wrote:
> On Thu, Sep 11, 2025 at 8:29 PM Anubhav/FreeBSD   wrote:
>> 
>> I did not find anything about changes related to pf(4) in src/UPDATING
>> for v14.3, also found nothing relevant via web search or in -stable@ list
>> from 202505 to now.
>> 
>> 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.659700] add net ::ffff:0.0.0.0: gateway ::1
>> [105.660183] add net ::0.0.0.0: gateway ::1
>> [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'
>> #
>> pflog_logfile="/var/log/pf.log"
>> pflog_enable="YES"
>> 
>> 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?
> 
> 
> Also, I have been using stable/14 on a 3rd machine where I had not
> seen the issue post-reboot which had been (re)booted multiple times
> (since it got stable/14). That gave me enough confidence/courage to
> try to reboot the above 2nd machine to test.

FWIW I seem to recall a similar message. The cause of which was a bad 
(malformed)
entry in one of our tables.

HTH

--Chris
> 
> 
> - Anubhav
> 
> 
>> What am I missing here? Race condition?

-- 
There is no such place as the internet