Answering own posting: The problem is that 'pfctl -si' returns: "DIOCGETSTATUS: Permission denied" so when rc.d/pflogd uses that command to see if pf is running, it doesn't get a nice answer, woofs its cookies, and doesn't start.
Issue apparently is a bug in the current 5.3 snapshot, see: http://openbsd.7691.n7.nabble.com/pf-query-query-counters-failed-td225607.html (I'm running GENERIC#68 from 3/22). I'll hack the pflogd script for now until full 5.3 is released, when things presumably will work better. This is why you download snapshots, so things can break and you can report them. Or, conversely, why you don't run snapshots. :) -d- On Sun, Mar 24, 2013 at 10:13 AM, David Ruggiero <thatseattle...@gmail.com> wrote: > I'm playing with the latest 5.3 snapshot and I'm getting an > always-empty /var/log/pflog. I'm wondering if there's a problem with > the snapshot (unlikely) or something I did wrong in my configuration > (much more likely). > > ps -aux shows "pflogd" is not running, which I assume is the source of > the problem. In rc.conf (which I did not change of course) the pf > lines are: > > pf=YES # Packet filter / NAT > pf_rules=/etc/pf.conf # Packet filter rules file > pflogd_flags= # add more flags, e.g. "-s 256" > > And here's my rc.conf.local: > > ntpd_flags="" > hotplugd_flags="" > named_flags="" > check_quotas=NO > > That's it. Is there something I should be doing in rc.conf.local or > elsewhere to get pflogd running? (I could do pflogd_flags=YES, maybe, > but I thought that wasn't necessary, that pflogd would start > automagically if pf was enabled.)
