Re: "pfctl: DIOCADDRULENV: File exists" after update to v14.3-RELEASE-p2 from v13.5-RELEASE-p3
Date: Sat, 13 Sep 2025 01:34:42 UTC
On 2025-09-12 12:45, Anubhav/FreeBSD wrote: > 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. I didn't get anything other than a message at boot. Not unlike yours. Knowing that the rules we were using hadn't changed in months. I felt inclined to check the table files for any potential problems. I just cobbled up a script to ensure all the addresses were properly formed and legitimate. A malformed address was the culprit: n.n.n.n/32/32. Striping the extra /32 cured the problem. However, unlike yours. The message didn't include DIOCADDRULENV. This smelled like a potential connection problem -- bad address, DNS. IOW couldn't resolve an address (possibly due to DNS, or one of your IF's wasn't up...). So I did a little investigation. Simply performing a search against DIOCADDRULENV. NetGate is the first that pops up. Several incidents. Then I found this pr(1) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262971 (pf: handle duplicate rules gracefully). Lastly I found this entry at unbound: https://github.com/opnsense/core/issues/7168 Which is IPv6 and OpenSense related. So it's definitely specific to FreeBSD. But that's as much as I've got w/o having a more intimate relation w/your box && setup. What happens when you crank up the verbosity in both boot && pf startup? Does it provide any more clues? HTH --Chris > > In any case, if there would be such a malformed entry, what would I > need to do to find it? > > > - Anubhav -- There is no such place as the internet