DragonFlyBSD

I cannot reproduce this on 1.9-DEVEL. Does this problem persist?

On Thu, 19 Apr 2007 12:20:22 -0000
"Simon 'corecode' Schubert" <bugs@crater.dragonflybsd.org> wrote:

Don't know, is DEVEL stable enough for me to try? Just asking because I can only try this on aproduction machine. If yes, then I'll post feedback on this next week.

Ah, don't worry. Does it persist on 1.8-RELEASE?

cheers
simon

On Thu, 19 Apr 2007 14:15:01 -0000
Simon 'corecode' Schubert <bugs@lists.dragonflybsd.org> wrote:

Yes.

-------------------------------------------------
szg@fw:/home/szg# pfctl F all
rules cleared
nat cleared
1 tables deleted.
altq cleared
130 states cleared
source tracking entries cleared
pf: statistics cleared
------------------------------------------------
After a few minutes (NB: this is a bridge filtering 70 hosts which are doing soooo much P2P:
-------------------------------------------------
szg@fw:/home/szg# pfctl -si
Status: Enabled for 0 days 23:06:11 Debug: Urgent

Hostid: 0xbaafed3e

Interface Stats for sk1 IPv4 IPv6
Bytes In 72602328 0
Bytes Out 272202489 0
Packets In
Passed 203338 0
Blocked 22 0
Packets Out
Passed 292272 0
Blocked 0 0

State Table Total Rate
current entries 0
searches 1983044 23.8/s
inserts 0 0.0/s
removals 0 0.0/s
Counters
match 1983044 23.8/s
bad-offset 0 0.0/s
fragment 0 0.0/s
short 36 0.0/s
normalize 0 0.0/s
memory 0 0.0/s
szg@fw:/home/szg# uname a
DragonFly fw.jancso.szote.u-szeged.hu 1.8.1-RELEASE DragonFly 1.8.1-RELEASE #5: Tue Mar 27 23:27:44 CEST 2007 szg@fw.jancso.szote.u-szeged.hu:/usr/obj/usr/src/sys/BRIDGE i386
------------------------------------------------

Since the number of matches keep increasing on each information query, I suspect that this is actually an error in query/response to it, maybe there are actual states (any way to check that?)

As this bug has been marked as a blocker for 1.10, and I am the
reporter, I would like to rephrase my last question:

Is there an actual way to get whether new states are actually created?
You can supply me a patch that e. g. writes a log entry after having
created a state or does a notification in a different way, it just has
to be kernel-level, since the only problem may be that PF fails to
report state info back to userland if a flush has been done.

If states get created just pfctl and pftop cannot retrieve this
information, I consider the issue a minor annoyance (and not a release
blocker in any way), since it does not impair PF's actual work.

anyone still experiences this issue?
Should be long solved since it used to be a blocker for 1.10-RELEASE ;)

Cheers,
Alex Hornung

pf was recently updated in master, does it fix this issue?