Luigi Rizzo wrote:
On Wed, Dec 30, 2009 at 03:55:07PM -0800, Julian Elischer wrote:
Luigi Rizzo wrote:
...
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?
yes. this happens because the original has the same mtag as the
reinjected 'diverted' packet. I can fix it easily now that we
have rule_id. In the past it cold be fixed too, but needed more
restructuring of code.
I had code somewhere where tee didn't leave firewall, but just sent
the other packet out, so it could just continue on.
at Ironport I had to hack on divert/tee a bit to make it work well
with L2 packets.
so that got rewritten a bit.
_______________________________________________
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"
