From owner-freebsd-ipfw@FreeBSD.ORG Mon Jul 28 11:06:58 2008 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA278106566B for ; Mon, 28 Jul 2008 11:06:58 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B1DC68FC27 for ; Mon, 28 Jul 2008 11:06:58 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m6SB6wLP078942 for ; Mon, 28 Jul 2008 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m6SB6wus078938 for freebsd-ipfw@FreeBSD.org; Mon, 28 Jul 2008 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 28 Jul 2008 11:06:58 GMT Message-Id: <200807281106.m6SB6wus078938@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org 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, 28 Jul 2008 11:06:58 -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 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 kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v 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 o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 15 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] [request] ipfw dynamic rules lifetime f o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags 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 bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou 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/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets p kern/113388 ipfw [ipfw][patch] Addition actions with rules within speci o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form p kern/115755 ipfw [ipfw][patch] unify message and add a rule number wher o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit 30 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Tue Jul 29 16:01:14 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B4E81065675 for ; Tue, 29 Jul 2008 16:01:14 +0000 (UTC) (envelope-from jeff+freebsd@wagsky.com) Received: from mail.wagsky.com (wildside.wagsky.com [64.220.148.97]) by mx1.freebsd.org (Postfix) with ESMTP id 5D1028FC08 for ; Tue, 29 Jul 2008 16:01:14 +0000 (UTC) (envelope-from jeff+freebsd@wagsky.com) Received: from port5.pn.wagsky.com (port5.pn.wagsky.com [192.168.6.5]) by mail.wagsky.com (Postfix) with ESMTPSA id 63FAE28421; Tue, 29 Jul 2008 08:41:23 -0700 (PDT) Message-ID: <488F3A23.7070203@wagsky.com> Date: Tue, 29 Jul 2008 08:41:23 -0700 From: Jeff Kletsky User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: ipfw "bug" - recv any = not recv any 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: Tue, 29 Jul 2008 16:01:14 -0000 The "recv any" = "not recv any" = noop behavior got me this weekend, even after careful reading of the man page. My situation is attempting to use "not recv any" to discriminate between packets generated by the host from those being routed through the host. It is reasonably easy to confirm that, at least in 7.0-RELEASE-p3, "recv any" and "not recv any" are both behaving as no-ops in the ipfw syntax. This was discussed to some extent in the post and related thread: Luigi Rizzo wrote: > ok, so the problem is the following: when i implemented ipfw2 > i thought that 'recv any' or 'xmit any' were effectively NOPs > so the parser erroneously removes them, together with any 'not' prefix > (which is processed before). > > To fix this one should > - patch the function ipfw2.c:fill_iface() > so that an argument of 'any' puts some special pattern > in the ipfw_insn_if (e.g. an * in the first char of name[] > should suffice as i doubt it is a legal interface name). > > [...] While there are ways to do this (e.g., tagging, or "[not] recv *"), I would suggest at least clarification of the documentation. At this point, I suspect that there are enough "overly cautious" rule writers that have included "recv any" in their now-deployed rules that (properly for them) match both externally and internally generated packets that changing "recv any" to only match packets that were received would break more things than it fixes. Changing the parsing of "not recv any" to produce the code behind "not recv *" would be "less dangerous" and might be considered at some time. Let me preface this by saying that I don't know the internals of ipfw2 well enough to confirm that a doc change like this matches the operation of the code, but something along the lines of: recv | xmit | via {ifX | if* | ipno | * } Matches packets received, transmitted or going through, respec- tively, the interface specified by exact name (ifX), by device name (if*), by IP address, or through some interface (*). The via keyword causes the interface to always be checked. If recv or xmit is used instead of via, then only the receive or transmit interface (respectively) is checked. By specifying both, it is possible to match packets based on both receive and transmit interface, e.g.: ipfw add deny ip from any to any out recv ed0 xmit ed1 The recv interface can be tested on either incoming or outgoing packets, while the xmit interface can only be tested on outgoing packets. So out is required (and in is invalid) whenever xmit is used. A packet may not have a receive or transmit interface: packets originating from the local host have no receive interface, while packets destined for the local host have no transmit interface. To match packets that have no receive interface, the construct "not recv *" may be used. The constructs "recv any" and "not recv any" are presently both treated equivalently as a match-all condition and both are stripped during parsing. This behavior, especially of the latter, is subject to change in future releases, and is not suggested for new rule sets. I hope this post at least helps the next person who trips across this. I'm very open to ideas on how to clarify and/or improve the behavior. I haven't looked into the other "any" matches to see if they have similar behavior that would benefit from additional documentation Jeff P.S. Thanks to Julian Elischer for suggesting "not recv *" as an approach. From owner-freebsd-ipfw@FreeBSD.ORG Fri Aug 1 02:02:45 2008 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CFB11065673 for ; Fri, 1 Aug 2008 02:02:45 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outV.internet-mail-service.net (outv.internet-mail-service.net [216.240.47.245]) by mx1.freebsd.org (Postfix) with ESMTP id E65548FC13 for ; Fri, 1 Aug 2008 02:02:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id E3DB424AF; Thu, 31 Jul 2008 18:50:41 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 8EA492D601B; Thu, 31 Jul 2008 18:50:41 -0700 (PDT) Message-ID: <48926C02.6030308@elischer.org> Date: Thu, 31 Jul 2008 18:50:58 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: FreeBSD Net , ipfw@freebsd.org Content-Type: multipart/mixed; boundary="------------080502070707020107000209" Cc: Subject: ipfw add skipto tablearg.... 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, 01 Aug 2008 02:02:45 -0000 This is a multi-part message in MIME format. --------------080502070707020107000209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit looking int he code I noticed that the following command gave no error but didn't work.. ipfw add 1000 skipto tablearg ip from any to table(31) and as I have a use for that, I implemented it.. see attached patch... (hopefully not stripped) Of course it is hoped that the rules you are skipping to are nearby as it iterates through the rules following the skipto to find the target, but.... if you had a thousand table entries and wanted to sort them into 20 buckets, it could save you puting them into 20 different tables and doing 20 table lookups on them. here I sort into two categories.. possibly already a win.. julian@trafmon2:cat ipfw-test.sh #!/bin/sh ipfw add 100 skipto 10000 ip from any to not 1.1.1.0/24 ipfw add 1000 skipto tablearg ip from any to "table(31)" ipfw add 2000 drop ip from any to any ipfw add 2001 drop ip from any to any ipfw add 3000 drop ip from any to any ipfw add 3001 drop ip from any to any ipfw add 10000 count ip from any to any ipfw table 31 add 1.1.1.1 2000 ipfw table 31 add 1.1.1.2 3000 julian@trafmon2: ping 1.1.1.1 [...] (2 packets bounced) julian@trafmon2: ping 1.1.1.2 [...] (12 packets bounced) julian@trafmon2: ipfw show 00100 220 19633 skipto 10000 ip from any to not 1.1.1.0/24 01000 14 1176 skipto tablearg ip from any to table(31) 02000 2 168 deny ip from any to any 02001 0 0 deny ip from any to any 03000 12 1008 deny ip from any to any 03001 0 0 deny ip from any to any 10000 209 18549 count ip from any to any 65535 1751 153792 allow ip from any to any comments? --------------080502070707020107000209 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="ipfw-skipto-current.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ipfw-skipto-current.diff" Index: ip_fw2.c =================================================================== RCS file: /usr/local/cvsroot/freebsd/src/sys/netinet/ip_fw2.c,v retrieving revision 1.186 diff -u -r1.186 ip_fw2.c --- ip_fw2.c 9 May 2008 23:02:57 -0000 1.186 +++ ip_fw2.c 1 Aug 2008 01:15:06 -0000 @@ -1738,10 +1738,11 @@ */ static struct ip_fw * -lookup_next_rule(struct ip_fw *me) +lookup_next_rule(struct ip_fw *me, u_int32_t tablearg) { struct ip_fw *rule = NULL; ipfw_insn *cmd; + u_int16_t rulenum; /* look for action, in case it is a skipto */ cmd = ACTION_PTR(me); @@ -1751,10 +1752,18 @@ cmd += F_LEN(cmd); if (cmd->opcode == O_TAG) cmd += F_LEN(cmd); - if ( cmd->opcode == O_SKIPTO ) - for (rule = me->next; rule ; rule = rule->next) - if (rule->rulenum >= cmd->arg1) + if (cmd->opcode == O_SKIPTO ) { + if (tablearg != 0) { + rulenum = (u_int16_t)tablearg; + } else { + rulenum = cmd->arg1; + } + for (rule = me->next; rule ; rule = rule->next) { + if (rule->rulenum >= rulenum) { break; + } + } + } if (rule == NULL) /* failure or not a skipto */ rule = me->next; me->next_rule = rule; @@ -2475,7 +2484,7 @@ f = args->rule->next_rule; if (f == NULL) - f = lookup_next_rule(args->rule); + f = lookup_next_rule(args->rule, 0); } else { /* * Find the starting rule. It can be either the first @@ -3226,9 +3235,13 @@ if (cmd->opcode == O_COUNT) goto next_rule; /* handle skipto */ - if (f->next_rule == NULL) - lookup_next_rule(f); - f = f->next_rule; + if (cmd->arg1 == IP_FW_TABLEARG) { + f = lookup_next_rule(f, tablearg); + } else { + if (f->next_rule == NULL) + lookup_next_rule(f, 0); + f = f->next_rule; + } goto again; case O_REJECT: --------------080502070707020107000209--