Date: Wed, 30 Dec 2009 15:55:07 -0800 From: Julian Elischer <julian@elischer.org> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: Ian Smith <smithi@nimnet.asn.au>, net@freebsd.org Subject: Re: RFC: documented and actual behaviour of "ipfw tee" Message-ID: <4B3BE85B.6080309@elischer.org> In-Reply-To: <20091230225705.GC64766@onelab2.iet.unipi.it> References: <20091230002447.GA55727@onelab2.iet.unipi.it> <4B3AA290.8000508@elischer.org> <20091230221119.L81420@sola.nimnet.asn.au> <4B3BC659.7010707@elischer.org> <20091230225705.GC64766@onelab2.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo wrote: > On Wed, Dec 30, 2009 at 01:30:01PM -0800, Julian Elischer wrote: >> Ian Smith wrote: >>> On Tue, 29 Dec 2009, Julian Elischer wrote: >>>> Luigi Rizzo wrote: >>>>> There a difference between the documented and actual behaviour of >>>>> "ipfw tee" which occurs when there are multiple rules with the same >>>>> number, e.g. >>>>> >>>>> rule_id number body >>>>> r1 500 tee port1 dst-ip 1.2.3.0/24 >>>>> r2 500 tee port2 dst-ip 1.2.4.0/24 >>>>> r3 500 accept ip from any to any >>>>> r4 510 count ip from any to any >>>>> >>>>> + the manpage says "processing continues with the NEXT RULE" >>>>> (so after r1 we have r2, then r3, ...); >>>>> + the implementation behaves as "processing continues with the >>>>> NEXT NUMBERED RULE" (ie. after 500 continues with 510). >>>>> >>>> TEE should go to the next RULE with the original packet, but if >>>> you reinject the tee'd copy of the packet it should go to the >>>> next rule NUMBER. >>> Which is what happens now, right? Same behaviour on tee reinjection as >>> divert does seem consistent. So if there is a problem, it's only with >>> the original packet continuing with the next rule if same-numbered? >> from Luigi's description I'm not sure what happens now.. :-) > > fair enough, let me explain again: > A. with "divert" the packet is passed to the divert > socket, and when/if reinjected processing continues no earlier > than the the NEXT NUMBERED rule. This is a restriction due to the > current divert socket API that I have no intention to change. > > B. with "tee", the copy of the packet that goes to the socket > behaves the same as above. The original, which remains in > the kernel, continues processing from the NEXT NUMBERED RULE. This is unexpected. It should continue at the next rule are you sure? > > C. with "netgraph", the packet is passed to the netgraph node, > and when/if reinjected processing continues with the NEXT RULE. > This is different from #A AHHHHH now I understand. to me this does make some sense. Think of the RULE as a netgraph node. it has a hook to the outside netgraph graph through which packets may come and go. they are coming to that RULE and the only place they can go thereafter is the next rule. (I have not looked at the code nor have I ever used a netgraph rule in ipfw, I didn't write it but I can see how this may come about.) (goes off to read netgraph/ipfw interface code) > > D. with "ngtee", the copy of the packet that goes to the netgraph > node behaves as in #C. The original packet, continues processing > with the NEXT RULE (again, different from "tee" processing in #B) This I would expect > > E. For the records, packets going through dummynet and reinjected > because net.inet.ip.fw.one_pass=0, continue from the NEXT RULE. what if someone rewrites the firewall while they are 'away'? > > I think there is some agreement that "tee" and "ngtee" should do > the same thing for the original packet (the one that continues > processing), and i believe the correct approach is #D (i.e. continue > from the NEXT RULE). The point of my original question was to correct > what is done in case #B above. > > I am less clear on what to do for the packets passed to the divert > socket or netgraph node (cases #A and #B above), but i would vote > for keeping things unchanged because it is the best we can do. > (Ideally, I think that all forms of > diversion should continue by default from the NEXT RULE -- this is > what currently happens with netgraph #B and dummynet #E. > But we cannot change "divert" #A because of API limitations, > and I think we cannot change dummynet #E to continue with the next > numbered rule because it breaks existing configurations. the golden standard is ot continue at the next rule, but in divert's case the best it can do is the next "identifiable" rule. The design goal on divert sockets was that if the application gets a sockaddr from a divert socket and use it unchanged to pass the packet back it will do as close to the right thing as possible. The sockaddr gives you the rule number that sent the packet to you. sending hte packet back to THAT number would casue a loop, so the best we can do is the NEXT number, (whatever that is). the problem comes because numbers may not be unique, but I had to "live with that" as we have no other way to identify a rule from user land. > > cheers > luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B3BE85B.6080309>