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.

The actual behaviour is an artifact of how "divert" is implemented:
diverted packet only carry the rule number so we cannot tell, on a
reinject, which of the rules numbered "500" matched, and we restart
from the next one. Tee was implemented as an extension of divert.

Skipping rules in my opinion is very unintuitive, but there is
no way to fix it (unless we extend the API) as the rule_id is only
known within the kernel.

For 'tee', however, packets  the situation is different because the
copy of the packet that remains in the kernel does not lose knowledge
of the matching rule so we can easily continue from the very next
rule, same as it happens for dummynet packets with one_pass=0 (and
tee'd netgraph packets, which I think already do "the right thing").

Since I am doing some work in this are of the code, I'd like to ask
opinions on how to proceed:

    A. preserve the current behaviour and fix the manpage;
    B. fix the code to behave as the manpage says;
    C. introduce a sysctl to choose between A and B.
        Of course this moves the problem on which default
        to choose :)

Because it is a very special case that I doubt many people have hit,
I'd be inclined to do B and consider the old behaviour a bug.

        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"

_______________________________________________
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"

Reply via email to