From owner-freebsd-current@FreeBSD.ORG Wed Jun 22 12:09:00 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF49D1065673 for ; Wed, 22 Jun 2011 12:09:00 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 5E4488FC0A for ; Wed, 22 Jun 2011 12:09:00 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QZMEt-0006kI-7a for freebsd-current@freebsd.org; Wed, 22 Jun 2011 14:08:59 +0200 Received: from nuclight.avtf.net ([82.117.70.99]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 22 Jun 2011 14:08:59 +0200 Received: from vadim_nuclight by nuclight.avtf.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 22 Jun 2011 14:08:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Vadim Goncharov Date: Wed, 22 Jun 2011 12:08:46 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 57 Message-ID: References: <20110621111427.GA24786@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: nuclight.avtf.net X-Comment-To: Luigi Rizzo User-Agent: slrn/0.9.9p1 (FreeBSD) Cc: freebsd-ipfw@freebsd.org Subject: Re: [PATCH] ipfw call/return rule actions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 12:09:01 -0000 Hi Luigi Rizzo! On Tue, 21 Jun 2011 13:14:27 +0200; Luigi Rizzo wrote about 'Re: [PATCH] ipfw call/return rule actions': >> I have made a patch http://nuclight.avtf.net/vadim/ipfw_call_20110620.diff >> which adds a "call" and "return" rule actions to make it possible to >> organize "subroutines" with rules - "skipto" is like "goto" and only >> allows jumps forward, not backward. >> >> This could be useful to help doing somewaht like per-interface ACL, >> something similar to pf anchors or iptables chains. >> >> Please test, hope to see this committed soon and released in 9.0 ! > nice function and nice implementation. > It does not affect any existing ruleset etc. so it should really > be an easy addition, even if we don't make it for 9.0 there are > no ABI issues to be worried about. Yes, could you commit this? The newer version of patch is at http://nuclight.avtf.net/vadim/ipfw_call_20110621.diff - I have fixed a panic on incorrectly given ruleset (listing below is after fix) and another caveat to BUGS section. # ipfw zero && ping -c 2 10.0.0.5 && ipfw show 00500 2 168 call 2000 ip from 10.0.0.5 to any 00600 2 168 count log ip from 10.0.0.5 to any 00700 10 1144 skipto 3999 ip from any to any 00999 0 0 allow ip from any to any 02000 2 168 count ip from any to any // entry of subr 02100 2 168 count log ip from any to any 02999 2 168 return log ip from any to any // leave subr 03600 0 0 count log ip from 10.0.0.5 to any 04000 34 2856 call 4000 ip from any to any src-ip 10.0.0.5 05000 34 2856 return ip from any to any src-ip 10.0.0.5 65534 10 1144 allow ip from any to any 65535 0 0 deny ip from any to any Would be very well to have this feature in 9.0R and later MFCed to 8-STABLE, the analogue of iptables' chains is long-awaited by some users and will make FreeBSD more competitive with other network OSes. > By chance have you tried to measure the cost of a call/return pair ? No, the test was inside VirtualBox, I have no lab to do full performance testing. But in fact this is "ipfw tag" plus "ipfw skipto", and the former has relatively low impact on performance, while not so low, though. Performance of entire mbuf tags alloc could be improved, I have ideas, but this is definitely not a task for 9.0 already. Also, call/return has absolutely no impact for those who do not use them, and those who do use usually have already too complex ruleset for any sych performance costs to be justified. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]