From owner-freebsd-net@FreeBSD.ORG Wed Dec 30 00:33:06 2009 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C88E1065698 for ; Wed, 30 Dec 2009 00:33:06 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 263448FC0C for ; Wed, 30 Dec 2009 00:33:06 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 950EA73098; Wed, 30 Dec 2009 01:24:47 +0100 (CET) Date: Wed, 30 Dec 2009 01:24:47 +0100 From: Luigi Rizzo To: net@freebsd.org Message-ID: <20091230002447.GA55727@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: RFC: documented and actual behaviour of "ipfw tee" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 00:33:06 -0000 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). 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