Joachim Schipper wrote:
On Sun, Nov 19, 2006 at 10:11:36AM +0800, Uwe Dippel wrote:
On Sat, 18 Nov 2006 21:07:57 +0100, Joachim Schipper wrote:
No clue, but upgrading is a good idea and this is what it looks like on
my box:
[...]
It doesn't look different on mine ... and the upgrade will happen
hopefully soon ...
On second thought, are you certain pflogd *should* be listening on bpf0?
No; but it never did before (despite of the reboots) and I didn't make it
to do so.
And not on, say, pflog0? It's a privilige separated daemon running as
`_pflogd', so that it can't open the above files does make sense...
How *would* I make it listen on /dev/xxxxx, by the way ? (Except by
changing the source, that is ?)
At least on my box, pflogd(8) documents the -i option to listen on
another interface. pflog0 would qualify.
I believe this is a post-4.0 addition, though.
pflog interface implementation changed to allow it to be cloned. This
would let multiple pflog interfaces on a system.
A couple of changes to system daemons made to make them aware of this.
All of this work is done after tree was tagged. So reflections can be
seen on snapshots or on a custom -current build.
http://www.openbsd.org/cgi-bin/cvsweb.cgi/src/sbin/pflogd/pflogd.c#rev1.36
http://www.openbsd.org/cgi-bin/cvsweb.cgi/src/libexec/spamlogd/spamlogd.c#rev1.12
This permission problem smells like a mixed kernel and userland match
or a version spaghetti to me.
Please try a recent snapshot if possible. In case you want to run
-stable, make a _clean_ build.
