* Jason McIntyre <j...@kerhand.co.uk> [2011-02-01 01:14]: > On Mon, Jan 31, 2011 at 11:27:18PM +0100, Henning Brauer wrote: > > > > i don't understand the confusion. we have a state table (let me > > nitpick: it's a tree). a packet comes in. we do a lookup in the table, > > looking for an entry where the key fields match the packet. keys are: > > > > protocol > > address family > > src addr > > dst addr > > src port > > dst port > > rdomain > > > > if there is a match we found a state key, not a state yet. so we start > > to walk the list of states that hangs off the state key to find the > > right one - there can be multiple with interface bound states. > > > > now we have a state. that doesn't imply passing the packet yet, but at > > this point we decided for that state and against ruleset evaluation. > > > > now some more checks - there is a bit of timeout handling and for tcp > > the sequence number checks, and the flags etc. if these all go ok we pass > > the packet (and apply actions if requested, like NAT, routing etc). if > > not, we block it. > > > > ok, got it. the confusion is this: when pf.conf.5 talks about "any > state" in this context, it means there is a match in the state tree (as > you say). the confusion is that being in "any state" in english can mean > something else. consider that two paragraphs previous we say (of > match rules): "the pass/block state of a packet remains unchanged". thus > you can very easily think of a packet as being in a "block state". and > wahay, let's now talk about how pf works by saying "for subsequent > packets the filter checks whether the packet matches any state".
indeed, the use of 'any state' there is a bit weird. > so that abbreviation (just saying "state") is ambiguous. i suggest the > diff below. note it may not be technically correct... > > Index: pf.conf.5 > =================================================================== > RCS file: /cvs/src/share/man/man5/pf.conf.5,v > retrieving revision 1.488 > diff -u -r1.488 pf.conf.5 > --- pf.conf.5 23 Jan 2011 23:34:18 -0000 1.488 > +++ pf.conf.5 1 Feb 2011 00:01:05 -0000 > @@ -127,7 +127,7 @@ > the first time a packet matches a > .Ar pass > rule, a state entry is created; for subsequent packets the filter checks > -whether the packet matches any state. > +whether the packet matches that state entry. hmm. if we get into nitpicking, it must be sth like "subsequent packets of that connection". et voila, the next confusion - what is "that connection"? it's onbvious for tcp, not for the others. but then that is somewhere else in the page already. hmm. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
