[pf4freebsd] Re: pf errors meaning

[Max Laier]

Hello Bruno,

Thursday, October 2, 2003, 5:16:50 PM, you wrote:
BA> I'm sorry to disturb the ML silence ;) but I am gettin' some odd panics with a
BA> machine since I upgraded to 1.66. They may be totally unrelated, but it has
BA> been two in two days! First crash was due to dnscache, then, last night I
BA> disabled and replace it with bind. Today morning, it crashed again. So, it's
BA> either hardware, pf or god playing with me :>

Well ... what do you mean by "due to dnscache"? Any traces, dumps or
anything that might help to really debug?

BA> I must say that the machine has been routing ~1megbyte/sec for 24h+. Can this
BA> be too much of a stress ? :>

Should not ... obviously.

BA> btw, Fbsd 5.1, pf 1.66, no altq.

BA> Here are some pf errors while booting the machine with pf enabled on boot.

BA> Oct  2 10:34:09 deq kernel: pflog: $Name: VERSION_1_66 $
BA> Oct  2 10:34:09 deq kernel: pfsync: $Name: VERSION_1_66 $
BA> Oct  2 10:34:09 deq kernel: in6_ifattach: pflog0 is not multicast capable, IPv6
BA> not enabled
BA> Oct  2 10:34:09 deq kernel: in6_ifattach: pfsync0 is not multicast capable,
BA> IPv6 not enabled
BA> Oct  2 10:34:09 deq kernel: pflog0: promiscuous mode enabled
BA> Oct  2 10:34:09 deq kernel: pf: $Name: VERSION_1_66 $

Okay, the above are the normal boot messages. The two from in6_ifattach
are meaningless (can't be fixed without touching the kernel).

BA> Oct  2 10:34:34 deq kernel: Zone pfrktable was not empty (18 items).  Lost 2
BA> pages of memory.
BA> Oct  2 10:34:34 deq kernel: Zone pfrkentry was not empty (34 items).  Lost 4
BA> pages of memory.

These are strange (and should not exist). First of all such should only
show up when you remove the pf module and even then, they should not.
The meaning of it, is that some tables could not be freed as expected.
In the long run that's bad. Check the output of "vmstat -z | grep ^pf"
after some time of operation. If the "USED" value increases steadily
that'd be a sign of memory leakage (which could lead to a crash).

However, I am running pf as well, check "vmstat -z" regularly and did
not see any hints for a memory leak. So this might be a problem only for
module unload. I'll look into it.

BA> Oct  2 10:34:34 deq kernel: pflog0: promiscuous mode disabled
BA> Oct  2 10:34:34 deq pflogd[481]: read: Device not configured
BA> Oct  2 10:34:34 deq pflogd[481]: Exiting due to signal
BA> Oct  2 10:34:34 deq pflogd[481]: 0 packets received, 0 dropped

These are the normal messages from the stop phase of the pf.sh script.

BA> thoughts?

Hmmm ... for some reason your seem to remove/stop pf right after (23sec)
you loaded/started it. That might come from old pf.sh scripts lurking
around in /usr/local/etc/rc.d from a previous ports installation. Please
check kdlstat output once the box booted to make sure that you really
have pf in place. Additionally you'd make sure that you only have the
up2date modules and not old ones in /usr/local/modules from a previous
port installation.

If you keep getting panics it'd be quite interesting to see at least a
trace of those. Without it, it's impossible to tell what's the reason
for it.

-- 
Best regards,
 Max                            mailto:max at love2party.net