Date: Mon, 4 Aug 2008 04:04:55 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Mike Makonnen <mtm@wubethiopia.com> Cc: Patrick Tracanelli <eksffa@freebsdbrasil.com.br>, freebsd-net@freebsd.org Subject: Re: Application layer classifier for ipfw Message-ID: <Pine.BSF.3.96.1080804024416.13190D-100000@gaia.nimnet.asn.au> In-Reply-To: <4895B799.6070508@wubethiopia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 3 Aug 2008, Mike Makonnen wrote:
> Ian Smith wrote:
> > On Fri, 1 Aug 2008, Mike Makonnen wrote:
> > > Patrick Tracanelli wrote:
> > > > Mike Makonnen escreveu:
[..]
> > /*
> > * Inform divert(4) what rule to send it to by
> > * modifying the port number of the associated sockaddr_in
> > * structure. Note: we subtract one from the ipfw(4) rule
> > * number because processing in ipfw(4) will start with
> > * the next rule *after* the supplied rule number.
> > */
> > if (flow->if_fwrule != 0) {
> > pkt->fp_saddr.sin_port = flow->if_fwrule;
> > goto enqueue;
> > }
> >
> > and noticed that we weren't subtracting one ..
> >
>
> The comment is wrong. It was for a prior version of the code. Initially,
> I had the configuration file specify the rule number that passes the
> diverted packets to dummynet(4). The code (as the comment says) would
> subtract 1 from the number when it wrote the packet back, but I wasn't
> sure how ipfw(4) would react to a possibly non-existant rule so changed
>From my reading, that shouldn't be a problem. But I'm reading 5-STABLE
sources and haven't access to my 7.0 system this week to try it out, and
I could be entirely mistaken anyway!
I guess it might be worth checking that the target rule number isn't
less than the divert rule number that got us here, to guard against
loops that $anyone might try to configure?
> it to its current form. However, after thinking about it some more I
> think it is more intuitive and easier to understand if the configuration
> file specified the rule that passes the diverted packet to the pipe or
> queue.
Yes, the rule to skipto on a match, anyway. I can see doing plenty of
other stuff with this than necessarily (immediately) queueing packets;
depending on protocols detected you might count, log, pipe, queue with
some weight, just pass, deny, test against various src/dst, whatever.
> > I thought at first that this behaviour is fine, and just needed a bit
> > better describing. But I'm starting to wonder if subtracting one isn't
> > really a better idea?
> >
>
> I'm leaning in the same direction.
Worth a try? One thing you might test is whether it still works with
net.inet.ip.fw.one_pass=1 ? That's only supposed to affect dummynet
pipe diversion, but there's a bit of XXX code in after_ip_checks in
ip_fw2.c (in 5-STABLE anyway) that makes me wonder about that ..
> Glad to hear people are finding it useful :-)
Only conceptually so far, but that's fun enough for now, while I'm
really supposed to be relocating a server by sometime last week :)
cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.1080804024416.13190D-100000>