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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
