From owner-freebsd-ipfw@FreeBSD.ORG Mon Aug 21 19:56:33 2006 Return-Path: X-Original-To: freebsd-ipfw@FreeBSD.org Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F088116A4E6 for ; Mon, 21 Aug 2006 19:56:33 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id F20A643E17 for ; Mon, 21 Aug 2006 19:55:57 +0000 (GMT) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k7LJtNCi062520 for ; Mon, 21 Aug 2006 19:55:23 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k7LJtLum062516 for freebsd-ipfw@FreeBSD.org; Mon, 21 Aug 2006 19:55:21 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 21 Aug 2006 19:55:21 GMT Message-Id: <200608211955.k7LJtLum062516@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2006 19:56:34 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent f kern/51341 ipfw [ipfw] [patch] ipfw rule 'deny icmp from any to any ic o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o conf/78762 ipfw [ipfw] [patch] /etc/rc.d/ipfw should excecute $firewal o bin/80913 ipfw [patch] /sbin/ipfw2 silently discards MAC addr arg wit o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/93300 ipfw ipfw pipe lost packets o kern/95084 ipfw [ipfw] [patch] IPFW2 ignores "recv/xmit/via any" (IPFW o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/98831 ipfw [ipfw] ipfw has UDP hickups 12 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau o kern/46159 ipfw [ipfw] [patch] ipfw dynamic rules lifetime feature o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/49086 ipfw [ipfw] [patch] Make ipfw2 log to different syslog prio o bin/50749 ipfw [ipfw] [patch] ipfw2 incorrectly parses ports and port o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/73276 ipfw [ipfw] [patch] ipfw2 vulnerability (parser error) o bin/78785 ipfw [ipfw] [patch] ipfw verbosity locks machine if /etc/rc o kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o kern/82724 ipfw [ipfw] [patch] Add setnexthop and defaultroute feature o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/93422 ipfw ipfw divert rule no longer works in 6.0 (regression) o bin/95146 ipfw [ipfw][patch]ipfw -p option handler is bogus 19 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Thu Aug 24 07:39:51 2006 Return-Path: X-Original-To: freebsd-ipfw@hub.freebsd.org Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1725F16A4FC; Thu, 24 Aug 2006 07:39:51 +0000 (UTC) (envelope-from novel@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC12F43D53; Thu, 24 Aug 2006 07:39:50 +0000 (GMT) (envelope-from novel@FreeBSD.org) Received: from freefall.freebsd.org (novel@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k7O7dof1029604; Thu, 24 Aug 2006 07:39:50 GMT (envelope-from novel@freefall.freebsd.org) Received: (from novel@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k7O7doi6029600; Thu, 24 Aug 2006 07:39:50 GMT (envelope-from novel) Date: Thu, 24 Aug 2006 07:39:50 GMT From: Roman Bogorodskiy Message-Id: <200608240739.k7O7doi6029600@freefall.freebsd.org> To: novel@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-ipfw@FreeBSD.org Cc: Subject: Re: kern/102471: [ipfw] [patch] add tos and dscp support X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 07:39:51 -0000 Synopsis: [ipfw] [patch] add tos and dscp support Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: novel Responsible-Changed-When: Thu Aug 24 07:39:28 UTC 2006 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=102471 From owner-freebsd-ipfw@FreeBSD.ORG Thu Aug 24 12:32:07 2006 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3E2A16A4DE for ; Thu, 24 Aug 2006 12:32:06 +0000 (UTC) (envelope-from if@hetzner.co.za) Received: from hetzner.co.za (office.cpt2.your-server.co.za [196.7.147.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E19643D4C for ; Thu, 24 Aug 2006 12:32:05 +0000 (GMT) (envelope-from if@hetzner.co.za) Received: from localhost ([127.0.0.1] helo=ian.hetzner.africa) by hetzner.co.za with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1GGENQ-0008mi-2A; Thu, 24 Aug 2006 14:32:04 +0200 To: Luigi Rizzo , freebsd-ipfw@freebsd.org From: Ian FREISLICH In-Reply-To: Message from Ian FREISLICH of "Tue, 15 Aug 2006 15:21:32 +0200." X-Attribution: BOFH Date: Thu, 24 Aug 2006 14:32:04 +0200 Message-Id: Cc: Subject: Re: ipfw performance and random musings. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 12:32:07 -0000 Ian FREISLICH wrote: > Luigi Rizzo wrote: > > On Wed, Aug 02, 2006 at 01:42:51PM +0200, Ian FREISLICH wrote: > > > You're thinking somewhere on the lines of: > > > > > > skipto base hash-if from to delta [offset ] This is the syntax I've pretty much settled upon: skipto 1000 ip from any to any ifhash vlan[1000-1264] offset -1000 delta 100 Which for matching interfaces calculates the skipto target as: 1000 + (iface# + offset) * delta If you're happy with this format, I'll update the ipfw manual page and submit a patch for review and commit. I'm now getting ~440kpps forwarded at about 35% interrupt CPU utilisation. I'm going to have a bash at giving ifconfig a new option so that packets can be injected into the firewall at the right point. I have something like the following in mind: ifconfig em1 ipfw_rule 1000 foo% ifconfig em1 em1: flags=8843 mtu 1500 options=9b inet 10.0.1.1 netmask 0xffffff00 broadcast 10.0.1.255 ether 00:04:23:ce:ca:a0 media: Ethernet autoselect (1000baseTX ) status: active ipfw_rule: 1000 I expect this to reduce interrupt CPU overhead to about 8% at ~440kpps. Ian -- Ian Freislich From owner-freebsd-ipfw@FreeBSD.ORG Thu Aug 24 17:22:50 2006 Return-Path: X-Original-To: freebsd-ipfw@hub.freebsd.org Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E735716A4DA; Thu, 24 Aug 2006 17:22:50 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9922143D49; Thu, 24 Aug 2006 17:22:50 +0000 (GMT) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k7OHMow2079603; Thu, 24 Aug 2006 17:22:50 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k7OHMoPf079599; Thu, 24 Aug 2006 17:22:50 GMT (envelope-from linimon) Date: Thu, 24 Aug 2006 17:22:50 GMT From: Mark Linimon Message-Id: <200608241722.k7OHMoPf079599@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-ipfw@FreeBSD.org Cc: Subject: Re: bin/102422: [patch] ipfw & kernel problems where firewall rules aren't interpreted correctly X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2006 17:22:51 -0000 Synopsis: [patch] ipfw & kernel problems where firewall rules aren't interpreted correctly Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Thu Aug 24 17:22:29 UTC 2006 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=102422 From owner-freebsd-ipfw@FreeBSD.ORG Fri Aug 25 00:35:49 2006 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B0C816A4DE for ; Fri, 25 Aug 2006 00:35:49 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFEFC43D46 for ; Fri, 25 Aug 2006 00:35:48 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id k7P0Zlda096030; Thu, 24 Aug 2006 17:35:47 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id k7P0Zg13096029; Thu, 24 Aug 2006 17:35:42 -0700 (PDT) (envelope-from rizzo) Date: Thu, 24 Aug 2006 17:35:42 -0700 From: Luigi Rizzo To: Ian FREISLICH Message-ID: <20060824173542.A95870@xorpc.icir.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from if@hetzner.co.za on Thu, Aug 24, 2006 at 02:32:04PM +0200 Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw performance and random musings. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 00:35:49 -0000 On Thu, Aug 24, 2006 at 02:32:04PM +0200, Ian FREISLICH wrote: > Ian FREISLICH wrote: > > Luigi Rizzo wrote: > > > On Wed, Aug 02, 2006 at 01:42:51PM +0200, Ian FREISLICH wrote: > > > > You're thinking somewhere on the lines of: > > > > > > > > skipto base hash-if from to delta > [offset ] > > This is the syntax I've pretty much settled upon: > > skipto 1000 ip from any to any ifhash vlan[1000-1264] offset -1000 delta 100 > > Which for matching interfaces calculates the skipto target as: > > 1000 + (iface# + offset) * delta > > If you're happy with this format, I'll update the ipfw manual page > and submit a patch for review and commit. I would suggest a modification to the syntax as follows: skipto @ ... recv|xmit|via foo[A-B] base X delta D where @ is a keyword (meaning "the jump target is computed elsewhere") and "foo[A-B] base X delta D" is an extension of the interface-name option already available in ipfw. The motivations are the following: 1. "ifhash" is misleading, as it isn't really hashing anything. The real hashing, if you implemented it, is in the rule_number --> rule_ptr lookup table, which is a general mechanism and not a specific one. 2. the "foo[A-B]" in your example as a double purpose: match interface names within a range, and compute the jump target. - The former part is just an extension of the interface name syntax, so it is nicer if you implement it in a way that can be used wherever the 'foo' or 'fooN' can be. Also this part can be useful even if you add a 'starting rule' to interface descriptors. The "base X delta D" part could be optional, and if not specified it means that @ cannot be used as a jump target (or it just defaults to the next rule, or some other documented behaviour e.g. use D=1 and X = current_rule+1) - For the latter part (computing "X + (iface# - A) * D"), the 'offset' parameter that you propose is completely redundant, and i think the whole rule is a lot more readable if you put all the arguments in one place, rather than spreading them between the 'skipto' and the interface specifier. I have no idea how you wrote your current implementation but i believe that by using the above syntax even the internal implementation could be quite straightforward. cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Fri Aug 25 09:59:18 2006 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5B5316A4E2 for ; Fri, 25 Aug 2006 09:59:18 +0000 (UTC) (envelope-from if@hetzner.co.za) Received: from hetzner.co.za (office.cpt2.your-server.co.za [196.7.147.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5B2443D4C for ; Fri, 25 Aug 2006 09:59:17 +0000 (GMT) (envelope-from if@hetzner.co.za) Received: from localhost ([127.0.0.1] helo=ian.hetzner.africa) by hetzner.co.za with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1GGYT4-000CXO-H7; Fri, 25 Aug 2006 11:59:14 +0200 To: Luigi Rizzo From: Ian FREISLICH In-Reply-To: Message from Luigi Rizzo of "Thu, 24 Aug 2006 17:35:42 MST." <20060824173542.A95870@xorpc.icir.org> X-Attribution: BOFH Date: Fri, 25 Aug 2006 11:59:14 +0200 Message-Id: Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw performance and random musings. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 09:59:18 -0000 Luigi Rizzo wrote: > On Thu, Aug 24, 2006 at 02:32:04PM +0200, Ian FREISLICH wrote: > > skipto 1000 ip from any to any ifhash vlan[1000-1264] offset -1000 delta 100 > > > > Which for matching interfaces calculates the skipto target as: > > > > 1000 + (iface# + offset) * delta > > > > If you're happy with this format, I'll update the ipfw manual page > > and submit a patch for review and commit. > > I would suggest a modification to the syntax as follows: > > skipto @ ... recv|xmit|via foo[A-B] base X delta D .................................................^^^^^ This will then conflict with: ip_fw2.c iface_match(): if (cmd->name[0] != '\0') { /* match by name */ /* Check name */ if (cmd->p.glob) { if (fnmatch(cmd->name, ifp->if_xname, 0) == 0) return(1); cmd->p.glob as set up by ipfw2.c fill_iface(): else if (!isdigit(*arg)) { strlcpy(cmd->name, arg, sizeof(cmd->name)); cmd->p.glob = strpbrk(arg, "*?[") != NULL ? 1 : 0; > where @ is a keyword (meaning "the jump target is computed elsewhere") > and "foo[A-B] base X delta D" is an extension of the interface-name > option already available in ipfw. I also don't like 'skipto @' because that complicates the skipto syntax. I'd prefer to keep skipto the same and use a rule option to modify the skipto target. I'm also not overly enthused with putting this data into the ipfw_insn_if type. I'm happy to compromise since I think what's confusing the issue is this feature is really both a rule action and body and not just a rule body. Perhaps this is better: skipto 1000 delta 100 ip from any to any via vlan1002-vlan1264 This then extends the recv|xmit|via syntax to allow "ranges" of like interfaces and the skipto syntax to calculate offsets. "delta" being optional and defaulting to zero and implying a value based on the interface number. > The motivations are the following: > 1. "ifhash" is misleading, as it isn't really hashing anything. That occured to me. You suggested "ifhash" though :) > The real hashing, if you implemented it, is in the > rule_number --> rule_ptr lookup table, which is a general mechanism > and not a specific one. I did. But reading my thread in -CURRENT about vlan performance it appears there might heavy objection to this since it costs 256k of memory, ond they're fighting over 16k to get a ~8% performance boost with CPU utilisation down from 75% to 3%. > I have no idea how you wrote your current implementation but i > believe that by using the above syntax even the internal implementation > could be quite straightforward. Are you a context or unified diff man? Ian -- Ian Freislich From owner-freebsd-ipfw@FreeBSD.ORG Fri Aug 25 10:32:43 2006 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBF5B16A4E1 for ; Fri, 25 Aug 2006 10:32:43 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93E0543D49 for ; Fri, 25 Aug 2006 10:32:43 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id k7PAWh68003925; Fri, 25 Aug 2006 03:32:43 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id k7PAWg51003924; Fri, 25 Aug 2006 03:32:42 -0700 (PDT) (envelope-from rizzo) Date: Fri, 25 Aug 2006 03:32:42 -0700 From: Luigi Rizzo To: Ian FREISLICH Message-ID: <20060825033242.B3245@xorpc.icir.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from if@hetzner.co.za on Fri, Aug 25, 2006 at 11:59:14AM +0200 Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw performance and random musings. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 10:32:43 -0000 On Fri, Aug 25, 2006 at 11:59:14AM +0200, Ian FREISLICH wrote: > Luigi Rizzo wrote: > > On Thu, Aug 24, 2006 at 02:32:04PM +0200, Ian FREISLICH wrote: > > > skipto 1000 ip from any to any ifhash vlan[1000-1264] offset -1000 delta 100 > > > > > > Which for matching interfaces calculates the skipto target as: > > > > > > 1000 + (iface# + offset) * delta > > > > > > If you're happy with this format, I'll update the ipfw manual page > > > and submit a patch for review and commit. > > > > I would suggest a modification to the syntax as follows: > > > > skipto @ ... recv|xmit|via foo[A-B] base X delta D > .................................................^^^^^ > > This will then conflict with: > > ip_fw2.c iface_match(): > > if (cmd->name[0] != '\0') { /* match by name */ > /* Check name */ > if (cmd->p.glob) { > if (fnmatch(cmd->name, ifp->if_xname, 0) == 0) > return(1); > > cmd->p.glob as set up by ipfw2.c fill_iface(): > > else if (!isdigit(*arg)) { > strlcpy(cmd->name, arg, sizeof(cmd->name)); > cmd->p.glob = strpbrk(arg, "*?[") != NULL ? 1 : 0; hmmm... i did not know of the regexp support in interface name; too bad it is not reported on the manpage! How about compromising to vlanA-B (i.e. do not repeat the basename) ? This way it does not interfere with the regexp code. > > where @ is a keyword (meaning "the jump target is computed elsewhere") > > and "foo[A-B] base X delta D" is an extension of the interface-name > > option already available in ipfw. > > I also don't like 'skipto @' because that complicates the skipto > syntax. I'd prefer to keep skipto the same and use a rule option > to modify the skipto target. I'm also not overly enthused with > putting this data into the ipfw_insn_if type. but it really belongs there. You have no reason to use the 'delta' otherwise, and you don't have to complicate the skipto syntax - if you don't like @, just use '0' and then you know that a jump target of 0 means an indirect jump. > I'm happy to compromise since I think what's confusing the issue > is this feature is really both a rule action and body and not just > a rule body. Perhaps this is better: > > skipto 1000 delta 100 ip from any to any via vlan1002-vlan1264 > This then extends the recv|xmit|via syntax to allow "ranges" of > like interfaces and the skipto syntax to calculate offsets. "delta" > being optional and defaulting to zero and implying a value based > on the interface number. the problem i see above is that the 'delta' is really an attribute of the 'vlanA-B' instruction. Say you have this rule: skipto 1000 recv vlan1002-vlan1264 does it mean 'skip to 1000 plus the interface number' or 'skip to 1000 unconditionally' (i suppose the former because otherwise the 'skipto' would have two different meanings depending on whether or not there is a subsequent vlanA-B specifier) ? In order to figure out, you need to know a lot more info from the manpage (if it gets updated :) because the syntax is not telling you. With the other syntax it is obvious what you do: skipto 1000 recv vlan1002-vlan1264 -> direct jump skipto @ recv vlan1002-vlan1264 base 1000 -> indirect jump > > > The motivations are the following: > > 1. "ifhash" is misleading, as it isn't really hashing anything. > > That occured to me. You suggested "ifhash" though :) i never said i never make mistakes :) > > The real hashing, if you implemented it, is in the > > rule_number --> rule_ptr lookup table, which is a general mechanism > > and not a specific one. > > I did. But reading my thread in -CURRENT about vlan performance > it appears there might heavy objection to this since it costs 256k > of memory, ond they're fighting over 16k to get a ~8% performance > boost with CPU utilisation down from 75% to 3%. if you make it a hash table you don't have to worry about static sizes, and it also removes the multiple number -> pointer entries that are embedded in the rules (mostly important from an update-cost point of view). > > I have no idea how you wrote your current implementation but i > > believe that by using the above syntax even the internal implementation > > could be quite straightforward. > > Are you a context or unified diff man? diff -u cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Fri Aug 25 11:41:10 2006 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 745AF16A4DA for ; Fri, 25 Aug 2006 11:41:10 +0000 (UTC) (envelope-from if@hetzner.co.za) Received: from hetzner.co.za (office.cpt2.your-server.co.za [196.7.147.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB04A43D45 for ; Fri, 25 Aug 2006 11:41:09 +0000 (GMT) (envelope-from if@hetzner.co.za) Received: from localhost ([127.0.0.1] helo=ian.hetzner.africa) by hetzner.co.za with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1GGa3b-000CtT-OW; Fri, 25 Aug 2006 13:41:03 +0200 To: Luigi Rizzo From: Ian FREISLICH In-Reply-To: Message from Luigi Rizzo of "Fri, 25 Aug 2006 03:32:42 MST." <20060825033242.B3245@xorpc.icir.org> X-Attribution: BOFH Date: Fri, 25 Aug 2006 13:41:03 +0200 Message-Id: Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw performance and random musings. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 11:41:10 -0000 Luigi Rizzo wrote: > On Fri, Aug 25, 2006 at 11:59:14AM +0200, Ian FREISLICH wrote: > > Luigi Rizzo wrote: > > > On Thu, Aug 24, 2006 at 02:32:04PM +0200, Ian FREISLICH wrote: > > > > skipto 1000 ip from any to any ifhash vlan[1000-1264] offset -1000 delt a 100 > > > > > > > > Which for matching interfaces calculates the skipto target as: > > > > > > > > 1000 + (iface# + offset) * delta > > > > > > > > If you're happy with this format, I'll update the ipfw manual page > > > > and submit a patch for review and commit. > > > > > > I would suggest a modification to the syntax as follows: > > > > > > skipto @ ... recv|xmit|via foo[A-B] base X delta D > > .................................................^^^^^ > > > > This will then conflict with: > > > > ip_fw2.c iface_match(): > > > > if (cmd->name[0] != '\0') { /* match by name */ > > /* Check name */ > > if (cmd->p.glob) { > > if (fnmatch(cmd->name, ifp->if_xname, 0) == 0) > > return(1); > > > > cmd->p.glob as set up by ipfw2.c fill_iface(): > > > > else if (!isdigit(*arg)) { > > strlcpy(cmd->name, arg, sizeof(cmd->name)); > > cmd->p.glob = strpbrk(arg, "*?[") != NULL ? 1 : 0; > > hmmm... i did not know of the regexp support in interface name; > too bad it is not reported on the manpage! > How about compromising to vlanA-B (i.e. do not repeat the basename) ? > This way it does not interfere with the regexp code. > > > > where @ is a keyword (meaning "the jump target is computed elsewhere") > > > and "foo[A-B] base X delta D" is an extension of the interface-name > > > option already available in ipfw. > > > > I also don't like 'skipto @' because that complicates the skipto > > syntax. I'd prefer to keep skipto the same and use a rule option > > to modify the skipto target. I'm also not overly enthused with > > putting this data into the ipfw_insn_if type. > > but it really belongs there. You have no reason to use the 'delta' > otherwise, and you don't have to complicate the skipto syntax - if you > don't like @, just use '0' and then you know that a jump target > of 0 means an indirect jump. > > > I'm happy to compromise since I think what's confusing the issue > > is this feature is really both a rule action and body and not just > > a rule body. Perhaps this is better: > > > > skipto 1000 delta 100 ip from any to any via vlan1002-vlan1264 > > This then extends the recv|xmit|via syntax to allow "ranges" of > > like interfaces and the skipto syntax to calculate offsets. "delta" > > being optional and defaulting to zero and implying a value based > > on the interface number. > > the problem i see above is that the 'delta' is really an attribute > of the 'vlanA-B' instruction. > Say you have this rule: > > skipto 1000 recv vlan1002-vlan1264 > > does it mean 'skip to 1000 plus the interface number' or > 'skip to 1000 unconditionally' (i suppose the former because This means skipto 1000 if the interface is in the range since delta defaults to zero. > otherwise the 'skipto' would have two different meanings > depending on whether or not there is a subsequent vlanA-B specifier) ? No, it is the delta option to skipto that determines whether the target is calculated or not. Actually it's always calculated from the interface's position in the range. When the list is only one interface long or when there is no delta the indirection offset is zero. > In order to figure out, you need to know a lot more info from the > manpage (if it gets updated :) because the syntax is not telling you. > > With the other syntax it is obvious what you do: > > skipto 1000 recv vlan1002-vlan1264 -> direct jump > skipto @ recv vlan1002-vlan1264 base 1000 -> indirect jump So my current thinking is to extend the recv,xmit,via syntax to use a range, so that you can do: deny udp from any to any via re0-re5 fwd 127.0.0.1:3182 tcp from any to any 80 in recv fxp3-fxp7 etc. This is distinct from the indirect skipto: skipto base delta delta .... Currently support is only proposed for interface ranges, but there is no reason that this can't be extended to port ranges networks etc. So perhaps the "delta" option needs to be renamed to if-delta or if-indirection-factor or something: skipto 100 if-indirection-factor 10 ... via vlan1-vlan100 So the following is possible, except I can't off hand think of when I'd want to do something like this: skipto 100 src-port-delta 20 tcp from any 1-1024 to me or skipto 100 src-delta 20 tcp from 10.0.0.0/24 to any etc. To my mind, the indirection is very strongly coupled to the skipto, and its provider is currently recv|xmit|via > > > The real hashing, if you implemented it, is in the > > > rule_number --> rule_ptr lookup table, which is a general mechanism > > > and not a specific one. > > > > I did. But reading my thread in -CURRENT about vlan performance > > it appears there might heavy objection to this since it costs 256k > > of memory, ond they're fighting over 16k to get a ~8% performance > > boost with CPU utilisation down from 75% to 3%. > > if you make it a hash table you don't have to worry about static sizes, > and it also removes the multiple number -> pointer entries that are > embedded in the rules (mostly important from an update-cost point of view). Except that you see how badly the hash affects CPU utilisation in the case of the vlan driver: hash - 75% CPU, lookup table - 3% CPU at 440kpps. It turns out that this is what was killing my performance, not ipfw, but now that I've started down this road, I'd rather have 1 rule that 500. > > > I have no idea how you wrote your current implementation but i > > > believe that by using the above syntax even the internal implementation > > > could be quite straightforward. > > > > Are you a context or unified diff man? > > diff -u In private mail. Ian -- Ian Freislich From owner-freebsd-ipfw@FreeBSD.ORG Fri Aug 25 11:52:08 2006 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E16716A4DD for ; Fri, 25 Aug 2006 11:52:08 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB6F143D45 for ; Fri, 25 Aug 2006 11:52:07 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id k7PBq7SS004887; Fri, 25 Aug 2006 04:52:07 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id k7PBq7U8004886; Fri, 25 Aug 2006 04:52:07 -0700 (PDT) (envelope-from rizzo) Date: Fri, 25 Aug 2006 04:52:07 -0700 From: Luigi Rizzo To: Ian FREISLICH Message-ID: <20060825045207.A4746@xorpc.icir.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from if@hetzner.co.za on Fri, Aug 25, 2006 at 01:41:03PM +0200 Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw performance and random musings. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 11:52:08 -0000 trimming the thing... On Fri, Aug 25, 2006 at 01:41:03PM +0200, Ian FREISLICH wrote: ... > > the problem i see above is that the 'delta' is really an attribute > > of the 'vlanA-B' instruction. > > Say you have this rule: > > > > skipto 1000 recv vlan1002-vlan1264 > > > > does it mean 'skip to 1000 plus the interface number' or > > 'skip to 1000 unconditionally' (i suppose the former because > > This means skipto 1000 if the interface is in the range since delta > defaults to zero. which proves my point - this is hidden information which you happen to know but it is not obvious, whereas an explicit difference in the syntax makes it clear. > > otherwise the 'skipto' would have two different meanings > > depending on whether or not there is a subsequent vlanA-B specifier) ? > > No, it is the delta option to skipto that determines whether the > target is calculated or not. Actually it's always calculated from again: the target is calculated using the start-of-range which is in the ifname* option. If you don't pack all the info (base+delta) in the if_name instruction, you have to lookup the 'skipto' instruction in order to do the computation. Conversely, if you just support a generic 'indirect skipto', you do the computation in the if_name (or other instruction), store the result in a well-known place (basically a variable in the function) and then when/if you find the skipto you use the value from there. > So my current thinking is to extend the recv,xmit,via syntax to use > a range, so that you can do: > > deny udp from any to any via re0-re5 > fwd 127.0.0.1:3182 tcp from any to any 80 in recv fxp3-fxp7 i am basically ok with this except, as i said, that there is no point in replicating the interface name i.e. why re0-re5 instead of just re0-5 ? you just open up to possible mistakes and the need for extra code to check what happens when the user types re2-de5 (by mistake or intentionally). > > if you make it a hash table you don't have to worry about static sizes, > > and it also removes the multiple number -> pointer entries that are > > embedded in the rules (mostly important from an update-cost point of view). > > Except that you see how badly the hash affects CPU utilisation in the > case of the vlan driver: hash - 75% CPU, lookup table - 3% CPU at that might depend on a poor match between the hash table size and the actual data set, or an expensive hash function. That's a huge difference that cannot be explained otherwise. > In private mail. ok thanks. luigi From owner-freebsd-ipfw@FreeBSD.ORG Fri Aug 25 13:27:21 2006 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3AD916A4DA for ; Fri, 25 Aug 2006 13:27:21 +0000 (UTC) (envelope-from if@hetzner.co.za) Received: from hetzner.co.za (office.cpt2.your-server.co.za [196.7.147.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1067D43D60 for ; Fri, 25 Aug 2006 13:27:20 +0000 (GMT) (envelope-from if@hetzner.co.za) Received: from localhost ([127.0.0.1] helo=ian.hetzner.africa) by hetzner.co.za with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1GGbiP-000DFG-1B; Fri, 25 Aug 2006 15:27:17 +0200 To: Luigi Rizzo From: Ian FREISLICH In-Reply-To: Message from Luigi Rizzo of "Fri, 25 Aug 2006 04:52:07 MST." <20060825045207.A4746@xorpc.icir.org> X-Attribution: BOFH Date: Fri, 25 Aug 2006 15:27:17 +0200 Message-Id: Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw performance and random musings. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 13:27:21 -0000 Luigi Rizzo wrote: > i am basically ok with this except, as i said, that there is > no point in replicating the interface name i.e. why re0-re5 > instead of just re0-5 ? you just open up to possible mistakes > and the need for extra code to check what happens when the user > types re2-de5 (by mistake or intentionally). Ok, it's just syntactic sugar anyway which doesn't really affect implimentation anyway. So, to recap. You will be fine with although I'm now leaning toward "factor" in stead of "delta" but that will be a trivial change and I'd like to change "@" to "indirect". skipto @ via vlan2-264 base 100 delta 100 or as I'd prefer skipto indirect via vlan2-264 base 100 factor 100 Only thing is that this slightly complicates displaying the rules since the indirection is stored in the ipfw_insn_if structure so at this time it's not known whether this is an indirection or not. /* * first print actions */ for (l = rule->cmd_len - rule->act_ofs, cmd = ACTION_PTR(rule); l > 0 ; l -= F_LEN(cmd), cmd += F_LEN(cmd)) { switch(cmd->opcode) { ... case O_SKIPTO: PRINT_UINT_ARG("skipto ", cmd->arg1); break; I guess cmd->arg1 == 0 could be abused to flag this state. Are you happy with that? Ian -- Ian Freislich From owner-freebsd-ipfw@FreeBSD.ORG Fri Aug 25 13:46:33 2006 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 61D9116A4E1 for ; Fri, 25 Aug 2006 13:46:33 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED7AF43D6B for ; Fri, 25 Aug 2006 13:46:27 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id k7PDkRni006300; Fri, 25 Aug 2006 06:46:27 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id k7PDkRZR006299; Fri, 25 Aug 2006 06:46:27 -0700 (PDT) (envelope-from rizzo) Date: Fri, 25 Aug 2006 06:46:27 -0700 From: Luigi Rizzo To: Ian FREISLICH Message-ID: <20060825064627.D6023@xorpc.icir.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from if@hetzner.co.za on Fri, Aug 25, 2006 at 03:27:17PM +0200 Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw performance and random musings. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 13:46:33 -0000 On Fri, Aug 25, 2006 at 03:27:17PM +0200, Ian FREISLICH wrote: > Luigi Rizzo wrote: > > i am basically ok with this except, as i said, that there is > > no point in replicating the interface name i.e. why re0-re5 > > instead of just re0-5 ? you just open up to possible mistakes > > and the need for extra code to check what happens when the user > > types re2-de5 (by mistake or intentionally). > > Ok, it's just syntactic sugar anyway which doesn't really affect > implimentation anyway. > > So, to recap. You will be fine with although I'm now leaning toward > "factor" in stead of "delta" but that will be a trivial change and > I'd like to change "@" to "indirect". > > skipto @ via vlan2-264 base 100 delta 100 > > or as I'd prefer > > skipto indirect via vlan2-264 base 100 factor 100 either way is fine with me. > Only thing is that this slightly complicates displaying the rules > since the indirection is stored in the ipfw_insn_if structure so > at this time it's not known whether this is an indirection or not. actually not, what i had in mind is exactly what you mention below - to record the type of jump (direct/indirect) in the skipto instruction (going one step further, one could think of several "indirect" registers to be used as jump target, possibly filled by previous instructions (e.g. from the content of an ipfw "table", etc.) You still implement these as local variables in the ip_fw_check() function. cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Sat Aug 26 09:00:52 2006 Return-Path: X-Original-To: freebsd-ipfw@hub.freebsd.org Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31FF416A4DA for ; Sat, 26 Aug 2006 09:00:52 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38E6D43D70 for ; Sat, 26 Aug 2006 09:00:43 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k7Q90hNp006358 for ; Sat, 26 Aug 2006 09:00:43 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k7Q90h9j006357; Sat, 26 Aug 2006 09:00:43 GMT (envelope-from gnats) Date: Sat, 26 Aug 2006 09:00:43 GMT Message-Id: <200608260900.k7Q90h9j006357@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: "Stephen E. Halpin" Cc: Subject: Re: bin/102422: ipfw & kernel problems where firewall rules aren't interpreted correctly X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Stephen E. Halpin" List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2006 09:00:52 -0000 The following reply was made to PR bin/102422; it has been noted by GNATS. From: "Stephen E. Halpin" To: Andrey V. Elsukov Cc: bug-followup@FreeBSD.org, Oleg Bulyzhin , Gleb Smirnoff , Luigi Rizzo Subject: Re: bin/102422: ipfw & kernel problems where firewall rules aren't interpreted correctly Date: Sat, 26 Aug 2006 05:01:39 -0400 Sorry for taking so long to get back to you. The changes look good. I've tested the changes for ip_fw2.c for both source and destination processing, and it worked fine. I still have a question about PR 91245, as when I went to the following page: http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/ipfw/ and it looks like the last version of ipfw2.c is 1.96 on the MAIN branch, and the changes in PR 91245 are not there. It would be awesome if all three fixes could make it into the 6.2 release! -Steve On Aug 24, 2006, at 6:09 AM, Andrey V. Elsukov wrote: > Stephen Halpin wrote: > > The rule is accepted with icmp6types 1,2,32,33,34,...94,95,128,129. > > The problem is the data structure in > > /usr/src/sbin/ipfw/ipfw2.c:fill_icmp6types() is not properly > > initialized. > > Yes, you are right. A data buffer is previously zeroed, but > fill_ip6() function can modified some data while parsing ipv6 > destination addresses. Quick fix is simple: > > --- ipfw2.c 23 Aug 2006 14:29:18 -0000 1.96 > +++ ipfw2.c 24 Aug 2006 09:08:06 -0000 > @@ -1206,7 +1206,7 @@ > { > uint8_t type; > > - cmd->d[0] = 0; > + bzero(cmd, sizeof(*cmd)); > while (*av) { > if (*av == ',') > av++; > > > But i think that here can be another similar issues. > > > addressed with bug number 91245, which the query interface won't > > bring up for anything. I was able to find it using the global > > Google. I found a set of diffs at: > > PR 91245 was closed. > http://www.freebsd.org/cgi/query-pr.cgi?pr=91245 > > > Problem 3: > > > > ipfw add allow ip6 from any to 2000::/16,2002::/16 > > Can you try the attached patch? > > -- > WBR, Andrey V. Elsukov > Index: ip_fw2.c > =================================================================== > RCS file: /mnt/cvs/ncvs/src/sys/netinet/ip_fw2.c,v > retrieving revision 1.144 > diff -u -r1.144 ip_fw2.c > --- ip_fw2.c 18 Aug 2006 22:36:04 -0000 1.144 > +++ ip_fw2.c 24 Aug 2006 09:55:38 -0000 > @@ -2869,22 +2869,20 @@ > &((ipfw_insn_ip6 *)cmd)->addr6); > break; > case O_IP6_SRC_MASK: > - if (is_ipv6) { > - ipfw_insn_ip6 *te = (ipfw_insn_ip6 *)cmd; > - struct in6_addr p = args->f_id.src_ip6; > - > - APPLY_MASK(&p, &te->mask6); > - match = IN6_ARE_ADDR_EQUAL(&te->addr6, &p); > - } > - break; > - > case O_IP6_DST_MASK: > if (is_ipv6) { > - ipfw_insn_ip6 *te = (ipfw_insn_ip6 *)cmd; > - struct in6_addr p = args->f_id.dst_ip6; > + int i = cmdlen - 1; > + struct in6_addr p; > + struct in6_addr *d = &((ipfw_insn_ip6 *)cmd)->addr6; > > - APPLY_MASK(&p, &te->mask6); > - match = IN6_ARE_ADDR_EQUAL(&te->addr6, &p); > + for (; !match && i > 0; d += 2, > + i -= F_INSN_SIZE(struct in6_addr) * 2) > + { > + p = (cmd->opcode == O_IP6_SRC_MASK) ? > + args->f_id.src_ip6: args->f_id.dst_ip6; > + APPLY_MASK(&p, &d[1]); > + match = IN6_ARE_ADDR_EQUAL(&d[0], &p); > + } > } > break; >