Application layer classifier for ipfw

[Ian Smith]

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