From owner-freebsd-net@FreeBSD.ORG Tue Feb 3 05:00:12 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A294D26E; Tue, 3 Feb 2015 05:00:12 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 73010DAA; Tue, 3 Feb 2015 05:00:12 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-238-204.lns20.per1.internode.on.net [121.45.238.204]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t13508Ix036775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 2 Feb 2015 21:00:10 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54D055D2.9010503@freebsd.org> Date: Tue, 03 Feb 2015 13:00:02 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org, Hiroki Sato Subject: Re: Does "setfib" in ipfw forces to re-route packet? References: <54CEA776.1040505@FreeBSD.org> <65FDDA6C-5910-4FBC-B43B-73BB72526AA5@jnielsen.net> <54D004A2.4010203@FreeBSD.org> In-Reply-To: <54D004A2.4010203@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 05:00:12 -0000 On 2/3/15 7:13 AM, Lev Serebryakov wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > And looks like, it is possible. > > Please, look at sys/netinet/ip_output.c, lines 493-535. > > It checks, did packet filter change (a) destination address or (b) > FIB, and if it does, it re-run routing decision. > > So, it will work "as expected" and only documentation need fix :) yes I see the change.. commit 272391 by hrs (CC'd) Hrs, can you fix the documentation? (man pages) ipfw(8) It is important that we always keep the documentation up to date with out source commits. this change of behaviour shoudlhave been accomanied byt a change to the documentation in the actual commit. It should note in hte man page that this is a sub-optimal path because each packet looks up a route twice, and much of ip_output( is run a second time which may be quite expensive if it redoes firewall work etc. (one reason I didn't do this in the first place). I would even consider the following around line 542 (head): if (inp != NULL) { /* switch the socket over so this is it's default FIB now */ np->inp_inc.inc_fibnum = M_GETFIB(m); } also now that we have a fibnum local variable, it should be used instead of all the later M_GETFIB() later in the function. eventually struct route should have a fibnum entry in it. (though some people have suggested it go right away.)