Date: Thu, 08 Oct 2009 09:18:23 -0700 From: Julian Elischer <julian@elischer.org> To: Oleg Bulyzhin <oleg@FreeBSD.org> Cc: rihad <rihad@mail.ru>, freebsd-net@freebsd.org Subject: Re: dummynet dropping too many packets Message-ID: <4ACE10CF.2030806@elischer.org> In-Reply-To: <20091008060608.GA23793@lath.rinet.ru> References: <4AC8A76B.3050502@mail.ru> <20091007085902.GA88982@lath.rinet.ru> <4ACC5E23.8090405@mail.ru> <20091007100503.GB88982@lath.rinet.ru> <4ACC6A7B.5050808@mail.ru> <20091007104525.GC88982@lath.rinet.ru> <4ACC7308.6070301@mail.ru> <4ACCC30E.7080504@elischer.org> <4ACCC4F3.3030302@mail.ru> <20091008060608.GA23793@lath.rinet.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Oleg Bulyzhin wrote: > On Wed, Oct 07, 2009 at 09:42:27PM +0500, rihad wrote: >> Julian Elischer wrote: >>> rihad wrote: >>>> Oleg Bulyzhin wrote: >>>> You probably have some special sources of documentation ;-) According >>>> to man ipfw, both "netgraph/ngtee" and "pipe" decide the fate of the >>>> packet unless one_pass=0. Or do you mean sprinkling smart skiptos here >>>> and there? ;-) >>>> >>> ngtee should not have any affect on the packet.. it takes a copy.. >>> >> That's a logical conclusion, although I prefer trusting the man at hand >> (pun intended) if I haven't tested it myself to see how it works: >> >> ngtee cookie >> A copy of packet is diverted into netgraph, original packet is >> either accepted or continues with the next rule, depending on >> net.inet.ip.fw.one_pass sysctl variable. See ng_ipfw(4) >> for more >> information on netgraph and ngtee actions. >> >> >> Although... I've a question to Mr. Oleg: >> >>> 2) use 'tee' rule with ng_ksocket & ng_netflow >> tee port >> Send a copy of packets matching this rule to the divert(4) >> socket >> bound to port port. The search continues with the next rule. >> >> how is it different from one_pass=0? Both tee and ngtee w/ one_pass=0 >> continue with the next rule. > > tee & ngtee are similar with one_pass=0 and different with one_pass=1 that seems like a bug to me.. neither tee should ever terminate a search. if you want to terminate it, add a specific rule to do so. Unfortunately I wasn't involved in writing it.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4ACE10CF.2030806>