From Newsgroup: muc.lists.freebsd.stable

Hi there,

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.

What am I missing here? Race condition?


- Anubhav


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable

On Thu, Sep 11, 2025 at 8:29rC>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.
- Anubhav

What am I missing here? Race condition?

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable

On Fri, Sep 12, 2025 at 9:37rC>AM Chris wrote:

On 2025-09-12 00:04, Anubhav/FreeBSD wrote:

On Thu, Sep 11, 2025 at 8:29rC>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
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2