On 2025-09-12 12:45, Anubhav/FreeBSD wrote:
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: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.
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
0xE512722F.asc
Description: application/pgp-keys
