From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 16 04:09:35 2008 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80E301065670; Sun, 16 Mar 2008 04:09:35 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 669F58FC19; Sun, 16 Mar 2008 04:09:35 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2G49ZIN006102; Sun, 16 Mar 2008 04:09:35 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2G49ZQ1006098; Sun, 16 Mar 2008 04:09:35 GMT (envelope-from linimon) Date: Sun, 16 Mar 2008 04:09:35 GMT Message-Id: <200803160409.m2G49ZQ1006098@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/121743: [netinet] [patch] ipfw in-kernel nat loses fragmented packets 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: Sun, 16 Mar 2008 04:09:35 -0000 Old Synopsis: ipfw in-kernel nat loses fragmented packets New Synopsis: [netinet] [patch] ipfw in-kernel nat loses fragmented packets Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Sun Mar 16 04:09:11 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=121743 From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 17 09:30:04 2008 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE1AE1065683 for ; Mon, 17 Mar 2008 09:30:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8EDCF8FC17 for ; Mon, 17 Mar 2008 09:30:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2H9U4Zi047053 for ; Mon, 17 Mar 2008 09:30:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2H9U49r047045; Mon, 17 Mar 2008 09:30:04 GMT (envelope-from gnats) Date: Mon, 17 Mar 2008 09:30:04 GMT Message-Id: <200803170930.m2H9U49r047045@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: Vadim Goncharov Cc: Subject: Re: kern/121743: ipfw in-kernel nat loses fragmented packets X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vadim Goncharov List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 09:30:04 -0000 The following reply was made to PR kern/121743; it has been noted by GNATS. From: Vadim Goncharov To: Alexander Zagrebin Cc: bug-followup@freebsd.org Subject: Re: kern/121743: ipfw in-kernel nat loses fragmented packets Date: Mon, 17 Mar 2008 15:19:38 +0600 Hi Alexander Zagrebin! On Sat, 15 Mar 2008 18:47:03 GMT; Alexander Zagrebin wrote: >>Fix: > --- sys/netinet/ip_fw2.c.orig 2008-02-28 11:28:09.000000000 +0300 > +++ sys/netinet/ip_fw2.c 2008-03-15 18:41:52.000000000 +0300 > @@ -3568,7 +3568,8 @@ > else > retval = LibAliasOut(t->lib, c, > MCLBYTES); > - if (retval != PKT_ALIAS_OK) { > + if (retval != PKT_ALIAS_OK && > + retval != PKT_ALIAS_FOUND_HEADER_FRAGMENT) { > /* XXX - should i add some logging? */ > m_free(mcl); > badnat: This is not so simple to fix as LibAlias API requires caller to save packet fragments somewhere and then at some time to feed them all back. And kernel infrastructure currently is not so suitable for that packet storage. As a workaround you can currently send packets with some ipfw rule before NAT to a divert socket on wich ng_ksocket listens and returns packets back with ng_echo (thus packets won't leave kernel), as divert sockets do packet reassembly. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 17 11:07:05 2008 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE92D106566B for ; Mon, 17 Mar 2008 11:07:05 +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 D59F48FC31 for ; Mon, 17 Mar 2008 11:07:05 +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 m2HB750v055127 for ; Mon, 17 Mar 2008 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2HB75aj055123 for freebsd-ipfw@FreeBSD.org; Mon, 17 Mar 2008 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Mar 2008 11:07:05 GMT Message-Id: <200803171107.m2HB75aj055123@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, 17 Mar 2008 11:07:06 -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] [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 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/106534 ipfw [ipfw] [panic] ipfw + dummynet 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 kern/121743 ipfw [netinet] [patch] ipfw in-kernel nat loses fragmented 16 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 [ipfw] [patch] ipfw verbosity locks machine if /etc/rc 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/111713 ipfw [dummynet] [request] Too few dummynet queue slots 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 28 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 17 12:10:03 2008 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1803D1065678 for ; Mon, 17 Mar 2008 12:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 072E18FC29 for ; Mon, 17 Mar 2008 12:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2HCA25i062893 for ; Mon, 17 Mar 2008 12:10:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2HCA2YZ062880; Mon, 17 Mar 2008 12:10:02 GMT (envelope-from gnats) Date: Mon, 17 Mar 2008 12:10:02 GMT Message-Id: <200803171210.m2HCA2YZ062880@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: "Alexander Zagrebin" Cc: Subject: RE: kern/121743: ipfw in-kernel nat loses fragmented packets X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexander Zagrebin List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 12:10:03 -0000 The following reply was made to PR kern/121743; it has been noted by GNATS. From: "Alexander Zagrebin" To: Cc: Subject: RE: kern/121743: ipfw in-kernel nat loses fragmented packets Date: Mon, 17 Mar 2008 14:32:23 +0300 > On Sat, 15 Mar 2008 18:47:03 GMT; Alexander Zagrebin > wrote: > > >>Fix: > > --- sys/netinet/ip_fw2.c.orig 2008-02-28 11:28:09.000000000 +0300 > > +++ sys/netinet/ip_fw2.c 2008-03-15 18:41:52.000000000 +0300 > > @@ -3568,7 +3568,8 @@ > > else > > retval = > LibAliasOut(t->lib, c, > > MCLBYTES); > > - if (retval != PKT_ALIAS_OK) { > > + if (retval != PKT_ALIAS_OK && > > + retval != > PKT_ALIAS_FOUND_HEADER_FRAGMENT) { > > /* XXX - should i > add some logging? */ > > m_free(mcl); > > badnat: > > This is not so simple to fix as LibAlias API requires caller > to save packet > fragments somewhere and then at some time to feed them all > back. And kernel > infrastructure currently is not so suitable for that packet storage. /sbin/natd doesn't use this method too. But it is in source tree and works. This patch will work at most cases. It is better to work with a bad patch, than to not work absolutely. > As a workaround you can currently send packets with some ipfw > rule before NAT > to a divert socket on wich ng_ksocket listens and returns > packets back with > ng_echo (thus packets won't leave kernel), as divert sockets do packet > reassembly. So ng_ksocket has kernel memory for fragmented packet's buffer, but libalias not? :) From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 17 12:30:04 2008 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BFA1106566B for ; Mon, 17 Mar 2008 12:30:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3919C8FC19 for ; Mon, 17 Mar 2008 12:30:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2HCU35F065043 for ; Mon, 17 Mar 2008 12:30:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2HCU3ST065036; Mon, 17 Mar 2008 12:30:03 GMT (envelope-from gnats) Date: Mon, 17 Mar 2008 12:30:03 GMT Message-Id: <200803171230.m2HCU3ST065036@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: Vadim Goncharov Cc: Subject: Re: kern/121743: ipfw in-kernel nat loses fragmented packets X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vadim Goncharov List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 12:30:04 -0000 The following reply was made to PR kern/121743; it has been noted by GNATS. From: Vadim Goncharov To: Alexander Zagrebin Cc: bug-followup@freebsd.org Subject: Re: kern/121743: ipfw in-kernel nat loses fragmented packets Date: Mon, 17 Mar 2008 18:23:02 +0600 Hi Alexander Zagrebin! On Mon, 17 Mar 2008 12:10:02 GMT; Alexander Zagrebin wrote: >>> --- sys/netinet/ip_fw2.c.orig 2008-02-28 11:28:09.000000000 +0300 >>> +++ sys/netinet/ip_fw2.c 2008-03-15 18:41:52.000000000 +0300 >>> @@ -3568,7 +3568,8 @@ >>> else >>> retval = >> LibAliasOut(t->lib, c, >>> MCLBYTES); >>> - if (retval != PKT_ALIAS_OK) { >>> + if (retval != PKT_ALIAS_OK && >>> + retval != >> PKT_ALIAS_FOUND_HEADER_FRAGMENT) { >>> /* XXX - should i >> add some logging? */ >>> m_free(mcl); >>> badnat: >> >> This is not so simple to fix as LibAlias API requires caller >> to save packet >> fragments somewhere and then at some time to feed them all >> back. And kernel >> infrastructure currently is not so suitable for that packet storage. > /sbin/natd doesn't use this method too. But it is in source tree and works. natd(8) relies on a divert(4) socket on doing reassembly, again in kernel - and ppp(8) actually use this method. > This patch will work at most cases. > It is better to work with a bad patch, than to not work absolutely. No, that's not FreeBSD way. Especially when you have workaround available. >> As a workaround you can currently send packets with some ipfw >> rule before NAT >> to a divert socket on wich ng_ksocket listens and returns >> packets back with >> ng_echo (thus packets won't leave kernel), as divert sockets do packet >> reassembly. > So ng_ksocket has kernel memory for fragmented packet's buffer, but libalias > not? :) Yes, because libalias(3) was developed more than 10 years for ppp(8), and was never ment to be ported to the kernel (it still has many-many quirks). Kernel sockets, and divert(4) as well, all use finite reassembly space for packets destined to this machine. This is not a problem with natd(8) as it is not so fast, but for more intensive solutions with in-kernel libalias a better solution should be found. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-ipfw@FreeBSD.ORG Tue Mar 18 06:53:13 2008 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E587C1065673; Tue, 18 Mar 2008 06:53:13 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A8F938FC25; Tue, 18 Mar 2008 06:53:13 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2I6rD7m011815; Tue, 18 Mar 2008 06:53:13 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2I6rDV9011811; Tue, 18 Mar 2008 06:53:13 GMT (envelope-from linimon) Date: Tue, 18 Mar 2008 06:53:13 GMT Message-Id: <200803180653.m2I6rDV9011811@freefall.freebsd.org> To: goffredo@gmail.com, linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/121807: [request] TCP and UDP port_table in ipfw 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, 18 Mar 2008 06:53:14 -0000 Old Synopsis: Sugestion: TCP and UDP port_table in ipfw New Synopsis: [request] TCP and UDP port_table in ipfw State-Changed-From-To: open->suspended State-Changed-By: linimon State-Changed-When: Tue Mar 18 06:52:41 UTC 2008 State-Changed-Why: Mark suspended awaiting patches. Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Tue Mar 18 06:52:41 UTC 2008 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=121807 From owner-freebsd-ipfw@FreeBSD.ORG Tue Mar 18 07:43:38 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 CBF5A106566B for ; Tue, 18 Mar 2008 07:43:38 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp10.yandex.ru (smtp10.yandex.ru [213.180.223.92]) by mx1.freebsd.org (Postfix) with ESMTP id 0CCF68FC2B for ; Tue, 18 Mar 2008 07:43:37 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from ns.kirov.so-cdu.ru ([77.72.136.145]:21231 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S5866902AbYCRHne (ORCPT ); Tue, 18 Mar 2008 10:43:34 +0300 X-Yandex-Spam: 1 X-Yandex-Front: smtp10 X-Yandex-TimeMark: 1205826214 X-MsgDayCount: 3 X-Comment: RFC 2476 MSA function at smtp10.yandex.ru logged sender identity as: bu7cher Message-ID: <47DF72A3.4030502@yandex.ru> Date: Tue, 18 Mar 2008 10:43:31 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Paolo Pisati References: <200803122100.m2CL0t7V088955@freefall.freebsd.org> <20080313094356.GA9219@tin.it> In-Reply-To: <20080313094356.GA9219@tin.it> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Vadim Goncharov , freebsd-ipfw@FreeBSD.org Subject: Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION 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, 18 Mar 2008 07:43:38 -0000 Paolo Pisati wrote: > On Thu, Mar 13, 2008 at 09:21:11AM +0000, Vadim Goncharov wrote: >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=80642 >> Yes, this is useful, but some minor changes are needed, I think. First, rename >> it to "bytelimit" or somewhat. Second, allow this to use tablearg and possibly >> ability to reference a counter to corresponding dynamic rule, to allow this to >> act for a specific IP or connection without need to write many rules. Third, >> add packet counter as well. That's all possible with one opcode, though... > > if anyone post an updated patch, i'll commit it. So, updated patch is here: http://butcher.heavennet.ru/patches/kernel/ipfw/ipfw_counterlimit.diff Now this option divided into two "counterlimit-bytes" and "counterlimit-packets". Rules example: add allow ip from any to 10.0.0.1 counterlimit-bytes 100M \ in recv external_if add allow ip from any to 10.0.0.1 counterlimit-pakets 50 \ in recv external_if About Vadim's prepositions: 1. tablearg: it's possible, but now we use u32 argument in tables, but counterlimits are 64-bits values. First of we should extend our current table argument to 64 bit. 2. dynamic rules: i think it should be implemented as extension to current O_LIMIT opcode or something similar. Also i have question about my current implementation. Does it needed to have ability of "humanized" printing of limits, which was implemented before? -- WBR, Andrey V. Elsukov From owner-freebsd-ipfw@FreeBSD.ORG Tue Mar 18 08:09:22 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 D7C641065675 for ; Tue, 18 Mar 2008 08:09:22 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outQ.internet-mail-service.net (outQ.internet-mail-service.net [216.240.47.240]) by mx1.freebsd.org (Postfix) with ESMTP id B53238FC17 for ; Tue, 18 Mar 2008 08:09:22 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 18 Mar 2008 01:09:22 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id C060E2D6011; Tue, 18 Mar 2008 01:09:20 -0700 (PDT) Message-ID: <47DF78AF.400@elischer.org> Date: Tue, 18 Mar 2008 01:09:19 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <200803122100.m2CL0t7V088955@freefall.freebsd.org> <20080313094356.GA9219@tin.it> <47DF72A3.4030502@yandex.ru> In-Reply-To: <47DF72A3.4030502@yandex.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Vadim Goncharov , freebsd-ipfw@FreeBSD.org Subject: Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION 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, 18 Mar 2008 08:09:22 -0000 Andrey V. Elsukov wrote: > Paolo Pisati wrote: >> On Thu, Mar 13, 2008 at 09:21:11AM +0000, Vadim Goncharov wrote: >>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=80642 >>> Yes, this is useful, but some minor changes are needed, I think. >>> First, rename >>> it to "bytelimit" or somewhat. Second, allow this to use tablearg and >>> possibly >>> ability to reference a counter to corresponding dynamic rule, to >>> allow this to >>> act for a specific IP or connection without need to write many rules. >>> Third, >>> add packet counter as well. That's all possible with one opcode, >>> though... >> >> if anyone post an updated patch, i'll commit it. > > So, updated patch is here: > http://butcher.heavennet.ru/patches/kernel/ipfw/ipfw_counterlimit.diff > > Now this option divided into two "counterlimit-bytes" and > "counterlimit-packets". > Rules example: > add allow ip from any to 10.0.0.1 counterlimit-bytes 100M \ > in recv external_if > add allow ip from any to 10.0.0.1 counterlimit-pakets 50 \ > in recv external_if > > About Vadim's prepositions: > 1. tablearg: it's possible, but now we use u32 argument in > tables, but counterlimits are 64-bits values. First of we > should extend our current table argument to 64 bit. tables should be expanded to have different types of values.. 32 but ints IP addresses (currently I'm overlaying it on 32 bit ints) IPV6 addresses. skipto locations byte limits.. > > 2. dynamic rules: i think it should be implemented as extension > to current O_LIMIT opcode or something similar. > > Also i have question about my current implementation. Does it > needed to have ability of "humanized" printing of limits, which > was implemented before? > From owner-freebsd-ipfw@FreeBSD.ORG Tue Mar 18 08:48:21 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 05459106566B for ; Tue, 18 Mar 2008 08:48:21 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp4.yandex.ru (smtp4.yandex.ru [213.180.223.136]) by mx1.freebsd.org (Postfix) with ESMTP id 424208FC16 for ; Tue, 18 Mar 2008 08:48:20 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from ns.kirov.so-cdu.ru ([77.72.136.145]:25336 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S737624AbYCRIsS (ORCPT ); Tue, 18 Mar 2008 11:48:18 +0300 X-Yandex-Spam: 1 X-Yandex-Front: smtp4 X-Yandex-TimeMark: 1205830098 X-MsgDayCount: 6 X-Comment: RFC 2476 MSA function at smtp4.yandex.ru logged sender identity as: bu7cher Message-ID: <47DF81CF.9040906@yandex.ru> Date: Tue, 18 Mar 2008 11:48:15 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Julian Elischer References: <200803122100.m2CL0t7V088955@freefall.freebsd.org> <20080313094356.GA9219@tin.it> <47DF72A3.4030502@yandex.ru> <47DF78AF.400@elischer.org> In-Reply-To: <47DF78AF.400@elischer.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Vadim Goncharov , freebsd-ipfw@FreeBSD.org Subject: Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION 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, 18 Mar 2008 08:48:21 -0000 Julian Elischer wrote: >> About Vadim's prepositions: >> 1. tablearg: it's possible, but now we use u32 argument in >> tables, but counterlimits are 64-bits values. First of we >> should extend our current table argument to 64 bit. > > tables should be expanded to have different types of values.. > 32 but ints > IP addresses (currently I'm overlaying it on 32 bit ints) > IPV6 addresses. > skipto locations > byte limits.. Yes, i agree. As I remember, we already talked about this some time ago. -- WBR, Andrey V. Elsukov From owner-freebsd-ipfw@FreeBSD.ORG Tue Mar 18 14:51:07 2008 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28AEC106564A; Tue, 18 Mar 2008 14:51:07 +0000 (UTC) (envelope-from piso@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 111328FC16; Tue, 18 Mar 2008 14:51:07 +0000 (UTC) (envelope-from piso@FreeBSD.org) Received: from freefall.freebsd.org (piso@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2IEp6g1082741; Tue, 18 Mar 2008 14:51:06 GMT (envelope-from piso@freefall.freebsd.org) Received: (from piso@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2IEp6MK082737; Tue, 18 Mar 2008 14:51:06 GMT (envelope-from piso) Date: Tue, 18 Mar 2008 14:51:06 GMT Message-Id: <200803181451.m2IEp6MK082737@freefall.freebsd.org> To: piso@FreeBSD.org, freebsd-ipfw@FreeBSD.org, piso@FreeBSD.org From: piso@FreeBSD.org Cc: Subject: Re: kern/121743: [netinet] [patch] ipfw in-kernel nat loses fragmented packets 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, 18 Mar 2008 14:51:07 -0000 Synopsis: [netinet] [patch] ipfw in-kernel nat loses fragmented packets Responsible-Changed-From-To: freebsd-ipfw->piso Responsible-Changed-By: piso Responsible-Changed-When: Tue Mar 18 14:49:49 UTC 2008 Responsible-Changed-Why: Assign it to me. http://www.freebsd.org/cgi/query-pr.cgi?pr=121743 From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 19 08:50:03 2008 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF1B01065684 for ; Wed, 19 Mar 2008 08:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8CCEB8FC17 for ; Wed, 19 Mar 2008 08:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2J8o3x0081588 for ; Wed, 19 Mar 2008 08:50:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2J8o3Pw081587; Wed, 19 Mar 2008 08:50:03 GMT (envelope-from gnats) Date: Wed, 19 Mar 2008 08:50:03 GMT Message-Id: <200803190850.m2J8o3Pw081587@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: Vadim Goncharov Cc: Subject: Re: kern/121807: Sugestion: TCP and UDP port_table in ipfw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vadim Goncharov List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2008 08:50:03 -0000 The following reply was made to PR kern/121807; it has been noted by GNATS. From: Vadim Goncharov To: Joao Rocha Braga Filho Cc: bug-followup@freebsd.org Subject: Re: kern/121807: Sugestion: TCP and UDP port_table in ipfw Date: Wed, 19 Mar 2008 14:47:01 +0600 Hi Joao Rocha Braga Filho! On Mon, 17 Mar 2008 20:15:12 GMT; Joao Rocha Braga Filho wrote: > Why not exist a TCP/UDP port_table for IPFW? It can solve 30 itens limit in ipfw rule. It is good to use in QoS. > Example > ipfw add allow { tcp or udp } from any port_table(10) to any > ipfw port_table 10 add 20,21,25,110,443,993,995,1025-65535 > # Deny bad ports > ipfw add deny { tcp or udp } from any to any port_table(11) > ipfw port_table 11 add 135,137-139,445 > ipfw add queue 100 udp from any port_table(20) to any > ipfw port_table(20) add 123,53 For what puprose should it _really_ serve? Limit-upping? Per-packet speed optimisation? More handy config preapring? Should that tables serve as a collection-only, or do have tableargs, and for what practical purpose that tableargs would be useful? If it is simply annoying to put long list in config several times, then it is correctly solved by shell vars: good_ports="20,21,25,110,443,993,995,1025-65535" ipfw add allow { tcp or udp } from any $good_ports to any ipfw add allow { tcp or udp } from ant to $my_server $good_ports If you care about both value-repeating, limit of 30 items and slightly about speed of packet processing, then you'd better classify your traffic with or-blocks on start of ruleset with tags: ipfw add 1 count tag 1 { src-port 20,21,25,110,443,993,995,1025-65535 \ or src-port 1,2,3,4,5,6,7,8,9,10,11,12,13,...long-list2...,29,30 \ or src-port ...list3... } // can have up to 8 full 30-port blocks per rule ipfw add 2 count tag 2 dst-port 135,137-139,445 // and so on Packet can have more than one tag at a time, so then you can write like: ipfw add queue 100 udp from any to any tagged 3 ipfw add allow { tcp or udp } from any to any tagged 1,2 And if your suggested port table is concerned on a per-packet performance, like our IP tables do, then how do you suggest it to be implemented in-kernel? Current tables for IP are radix trees, they consume a lot of kernel memory (which is a scarce resource) and process in term of mask - but it is not handy to specify ports in form like "128/8". And any form of tree will consume to a lot of memory per entry. It can be thought as a bit set, one bit for every port, very fast, but will consume 8K per one table - 1 meg for 128 such tables, unacceptable, again. So, I think it is best to use tags for your purposes. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 19 09:48:28 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 EABDB1065673 for ; Wed, 19 Mar 2008 09:48:27 +0000 (UTC) (envelope-from freebsd-ipfw@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6AAE28FC1B for ; Wed, 19 Mar 2008 09:48:26 +0000 (UTC) (envelope-from freebsd-ipfw@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JbuuB-0004TA-0Y for freebsd-ipfw@freebsd.org; Wed, 19 Mar 2008 09:48:19 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Mar 2008 09:48:19 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Mar 2008 09:48:19 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-ipfw@freebsd.org From: Vadim Goncharov Date: Wed, 19 Mar 2008 09:48:08 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 89 Message-ID: References: <200803122100.m2CL0t7V088955@freefall.freebsd.org> <20080313094356.GA9219@tin.it> <47DF72A3.4030502@yandex.ru> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: Andrey V. Elsukov User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Subject: Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2008 09:48:28 -0000 Hi Andrey V. Elsukov! On Tue, 18 Mar 2008 10:43:31 +0300; Andrey V. Elsukov wrote about 'Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION': >>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=80642 >>> Yes, this is useful, but some minor changes are needed, I think. First, rename >>> it to "bytelimit" or somewhat. Second, allow this to use tablearg and possibly >>> ability to reference a counter to corresponding dynamic rule, to allow this to >>> act for a specific IP or connection without need to write many rules. Third, >>> add packet counter as well. That's all possible with one opcode, though... >> >> if anyone post an updated patch, i'll commit it. > So, updated patch is here: > http://butcher.heavennet.ru/patches/kernel/ipfw/ipfw_counterlimit.diff > Now this option divided into two "counterlimit-bytes" and > "counterlimit-packets". > Rules example: > add allow ip from any to 10.0.0.1 counterlimit-bytes 100M \ > in recv external_if > add allow ip from any to 10.0.0.1 counterlimit-pakets 50 \ > in recv external_if > About Vadim's prepositions: > 1. tablearg: it's possible, but now we use u32 argument in > tables, but counterlimits are 64-bits values. First of we > should extend our current table argument to 64 bit. I think this should be done - limit of 4G bytes is still useful for many users (and 4G packets even more), and others could wait until table argument will be extended to u64, which will break ABI > 2. dynamic rules: i think it should be implemented as extension > to current O_LIMIT opcode or something similar. No, not there. Dynamic rules should be massively redone, with some other things, I'll write a big proposal (possibly a SoC candidate) in a day or two. What I'm trying to propose is generality - it allows more users to do different things, and if you do something specific, you're limiting some of them. For example, how do you propose toi change dynamic rules like O_LIMIT ? I suppose that will allow only one action per dynamic rule only, not telling about the ABI. And what I am proposing is a using several checks: remember that dynamic rule in fact jumps to action part of parent rule, which can be skipto. Imagine a server with two interfaces to different providers, which must route replies to requests to appropriate interface. In pf you would specify reply-to and nothing more, but in ipfw you can make a whole block of checks for each dynamic rule! Then, plain emulation of reply-to looks like this: ipfw add 1 check-state # ...some checks for outgoing and incoming firewalling here ipfw add 100 skipto 300 tag 1 in recv $ext_if1 keep-state ipfw add 200 skipto 300 tag 2 in recv $ext_if2 keep-state ipfw add 300 allow { recv $ext_if1 or recv $ext_if2 } # reqs from outside ipfw add 400 allow in recv $int_if # answers on internal pass ipfw add 500 fwd $gw1 tagged 1 # the only left are answers on ext iface, ipfw add 600 fwd $gw2 tagged 2 # send them to appropriate gateway Here every matched dynamic rule will jump to rule 300, and will be checked till rule 600. Now, assume that you want to limit bandwidth for "long-playing" downloads from your server? So you simply insert a pipe rule to that block: ipfw add 450 pipe 1 not counterlimit dyn-bytes 1000K and all outgoing short-lived connections will be unaffected, and those downloaded more than about 1 meg will be shaped. It is useful not only for shaping, but, for example, when you are sending packets to netgraph for L7 check with ng_bpf+ng_tag and know that check is expensive and you are interested only in first packets of connection, others are meaningless. So, that dynamic rule checking is assumed to be plain q = lookup_dyn_rule(...); if (q->bcnt) ... > Also i have question about my current implementation. Does it > needed to have ability of "humanized" printing of limits, which > was implemented before? It could be desirable to think about global ipfw option to print "humanized" values not only in this option, but several others too. Just like hostnames, IP addresses in tableargs, etc. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 19 10:22:40 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 A9712106566B for ; Wed, 19 Mar 2008 10:22:40 +0000 (UTC) (envelope-from freebsd-ipfw@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5B49A8FC23 for ; Wed, 19 Mar 2008 10:22:40 +0000 (UTC) (envelope-from freebsd-ipfw@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JbvRL-0006LW-9G for freebsd-ipfw@freebsd.org; Wed, 19 Mar 2008 10:22:35 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Mar 2008 10:22:35 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Mar 2008 10:22:35 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-ipfw@freebsd.org From: Vadim Goncharov Date: Wed, 19 Mar 2008 10:22:22 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 21 Message-ID: References: <200803122100.m2CL0t7V088955@freefall.freebsd.org> <20080313094356.GA9219@tin.it> <47DF72A3.4030502@yandex.ru> <47DF78AF.400@elischer.org> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: Julian Elischer User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Subject: Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2008 10:22:40 -0000 Hi Julian Elischer! On Tue, 18 Mar 2008 01:09:19 -0700; Julian Elischer wrote about 'Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION': >> About Vadim's prepositions: >> 1. tablearg: it's possible, but now we use u32 argument in >> tables, but counterlimits are 64-bits values. First of we >> should extend our current table argument to 64 bit. > tables should be expanded to have different types of values.. > 32 but ints > IP addresses (currently I'm overlaying it on 32 bit ints) > IPV6 addresses. > skipto locations > byte limits.. Are you talking about tablearg-values (data), or keys too? And does that count only IP addrs and integers of different sizes, or strings too? -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 19 10:30:05 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 9509A106566B for ; Wed, 19 Mar 2008 10:30:05 +0000 (UTC) (envelope-from freebsd-ipfw@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 470DE8FC19 for ; Wed, 19 Mar 2008 10:30:05 +0000 (UTC) (envelope-from freebsd-ipfw@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1JbvYZ-0006yL-1Z for freebsd-ipfw@freebsd.org; Wed, 19 Mar 2008 10:30:03 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Mar 2008 10:30:03 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Mar 2008 10:30:03 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-ipfw@freebsd.org From: Vadim Goncharov Date: Wed, 19 Mar 2008 10:25:54 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 21 Message-ID: References: <200803122100.m2CL0t7V088955@freefall.freebsd.org> <20080313094356.GA9219@tin.it> <47DF72A3.4030502@yandex.ru> <47DF78AF.400@elischer.org> <47DF81CF.9040906@yandex.ru> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: Andrey V. Elsukov User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Subject: Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2008 10:30:05 -0000 Hi Andrey V. Elsukov! On Tue, 18 Mar 2008 11:48:15 +0300; Andrey V. Elsukov wrote about 'Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION': >>> 1. tablearg: it's possible, but now we use u32 argument in >>> tables, but counterlimits are 64-bits values. First of we >>> should extend our current table argument to 64 bit. >> >> tables should be expanded to have different types of values.. >> 32 but ints >> IP addresses (currently I'm overlaying it on 32 bit ints) >> IPV6 addresses. >> skipto locations > Yes, i agree. As I remember, we already talked about this > some time ago. Can you please recall what else you've discussed? :) -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 19 13:01:29 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 7B45B1065670 for ; Wed, 19 Mar 2008 13:01:29 +0000 (UTC) (envelope-from vlad@prokk.net) Received: from smtp.prokk.net (smtp.prokk.net [195.16.77.5]) by mx1.freebsd.org (Postfix) with ESMTP id 664D68FC1E for ; Wed, 19 Mar 2008 13:01:21 +0000 (UTC) (envelope-from vlad@prokk.net) Received: from base (base.prokk.net [195.16.77.7]) by smtp.prokk.net (8.13.8/8.13.8) with ESMTP id m2JD1C3n071551 for ; Wed, 19 Mar 2008 15:01:17 +0200 (EET) (envelope-from vlad@prokk.net) From: "Vladimir V. Kobal" To: Date: Wed, 19 Mar 2008 15:01:12 +0200 Organization: ProKK SE Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00A2_01C889D2.15AB3B60" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4133 Thread-Index: AciJwU7PVsfAqnwzQf2A57EmldGxcA== X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp.prokk.net [195.16.77.5]); Wed, 19 Mar 2008 15:01:17 +0200 (EET) X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on smtp.prokk.net X-Virus-Status: Clean Subject: Dummynet causes kernel trap and system freeze 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: Wed, 19 Mar 2008 13:01:29 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00A2_01C889D2.15AB3B60 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 7bit Here is the backtraces for two sequential crashes for kernel compiled with options INVARIANTS options INVARIANT_SUPPORT ------=_NextPart_000_00A2_01C889D2.15AB3B60 Content-Type: text/plain; name="backtrace2.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="backtrace2.txt" [GDB will not be able to debug user-mode threads: = /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you = are welcome to change it and/or distribute copies of it under certain = conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for = details. This GDB was configured as "amd64-marcel-freebsd". Unread portion of the kernel message buffer: Fatal trap 9: general protection fault while in kernel mode cpuid =3D 1; apic id =3D 01 instruction pointer=3D 0x8:0xffffffff8034332c stack pointer =3D 0x10:0xffffffff9e727b00 frame pointer =3D 0x10:0xffffff00014e3031 code segment=3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags=3D interrupt enabled, resume, IOPL =3D 0 current process=3D 29 (dummynet) trap number=3D 9 panic: general protection fault cpuid =3D 1 Uptime: 1h7m47s Physical memory: 952 MB Dumping 84 MB: 69 53 37 21 5 #0 doadump () at pcpu.h:194 194pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:194 #1 0x8888888888888889 in ?? () #2 0xffffffff80246bc4 in boot (howto=3D260) at = ../../../kern/kern_shutdown.c:409 #3 0xffffffff80246fbd in panic (fmt=3D0x104
) at ../../../kern/kern_shutdown.c:563 #4 0xffffffff803d6eb4 in trap_fatal (frame=3D0xffffff0001213000,=20 eva=3D18446742974215792848) at ../../../amd64/amd64/trap.c:724 #5 0xffffffff803d7953 in trap (frame=3D0xffffffff9e727a50) at ../../../amd64/amd64/trap.c:526 #6 0xffffffff803bde7e in calltrap () at = ../../../amd64/amd64/exception.S:169 #7 0xffffffff8034332c in ip_input (m=3D0xffffff0006959300) at ../../../netinet/ip_input.c:520 #8 0xffffffff8033709d in dummynet_send (m=3D0xffffff0006959300) at ../../../netinet/ip_dummynet.c:858 #9 0xffffffff80337322 in dummynet_task (context=3DVariable "context" is = not available. ) at ../../../netinet/ip_dummynet.c:834 #10 0xffffffff802767a1 in taskqueue_run (queue=3D0xffffff0001231380) at ../../../kern/subr_taskqueue.c:255 #11 0xffffffff80276932 in taskqueue_thread_loop (arg=3DVariable "arg" is = not available. ) at ../../../kern/subr_taskqueue.c:374 #12 0xffffffff8022b03e in fork_exit ( callout=3D0xffffffff802768e0 ,=20 arg=3D0xffffffff805d3698, frame=3D0xffffffff9e727c80) at ../../../kern/kern_fork.c:781 #13 0xffffffff803be24e in fork_trampoline () at ../../../amd64/amd64/exception.S:415 #14 0x0000000000000000 in ?? () #15 0x0000000000000000 in ?? () #16 0x0000000000000001 in ?? () #17 0x0000000000000000 in ?? () #18 0x0000000000000000 in ?? () #19 0x0000000000000000 in ?? () #20 0x0000000000000000 in ?? () #21 0x0000000000000000 in ?? () #22 0x0000000000000000 in ?? () #23 0x0000000000000000 in ?? () #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000000 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000000 in ?? () #30 0x0000000000000000 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000000 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000000 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000000000 in ?? () #37 0x0000000000000000 in ?? () #38 0x00000000007a3000 in ?? () #39 0xffffffff9e727b80 in ?? () #40 0xffffff000110a8d0 in ?? () #41 0xffffffff805c5000 in facility_initialized () #42 0xffffff000110a8d0 in ?? () #43 0xffffff0001060000 in ?? () #44 0xffffffff9e727738 in ?? () #45 0xffffff0001213000 in ?? () #46 0xffffffff80263b8d in sched_switch (td=3D0xffffffff805d3698, = newtd=3D0x0,=20 flags=3DVariable "flags" is not available. ) at ../../../kern/sched_4bsd.c:905 #47 0x0000000000000000 in ?? () #48 0x0000000000000000 in ?? () #49 0x0000000000000000 in ?? () #50 0x0000000000000000 in ?? () #51 0x0000000000000000 in ?? () #52 0x0000000000000000 in ?? () #53 0x0000000000000000 in ?? () #54 0x0000000000000000 in ?? () #55 0x0000000000000000 in ?? () #56 0x0000000000000000 in ?? () #57 0x0000000000000000 in ?? () #58 0x0000000000000000 in ?? () #59 0x0000000000000000 in ?? () #60 0x0000000000000000 in ?? () #61 0x0000000000000000 in ?? () #62 0x0000000000000000 in ?? () #63 0x0000000000000000 in ?? () #64 0x0000000000000000 in ?? () #65 0x0000000000000000 in ?? () #66 0x0000000000000000 in ?? () #67 0x0000000000000000 in ?? () #68 0x0000000000000000 in ?? () #69 0x0000000000000000 in ?? () #70 0x0000000000000000 in ?? () #71 0x0000000000000000 in ?? () #72 0x0000000000000000 in ?? () #73 0x0000000000000000 in ?? () #74 0x0000000000000000 in ?? () #75 0x0000000000000000 in ?? () #76 0x0000000000000000 in ?? () #77 0x0000000000000000 in ?? () #78 0x0000000000000000 in ?? () #79 0x0000000000000000 in ?? () #80 0x0000000000000000 in ?? () #81 0x0000000000000000 in ?? () #82 0x0000000000000000 in ?? () #83 0x0000000000000000 in ?? () #84 0x0000000000000000 in ?? () #85 0x0000000000000000 in ?? () #86 0x0000000000000000 in ?? () #87 0x0000000000000000 in ?? () #88 0x0000000000000000 in ?? () #89 0x0000000000000000 in ?? () #90 0x0000000000000000 in ?? () #91 0x0000000000000000 in ?? () #92 0x0000000000000000 in ?? () #93 0x0000000000000000 in ?? () #94 0x0000000000000000 in ?? () #95 0x0000000000000000 in ?? () #96 0x0000000000000000 in ?? () #97 0x0000000000000000 in ?? () #98 0x0000000000000000 in ?? () #99 0x0000000000000000 in ?? () #100 0x0000000000000000 in ?? () #101 0x0000000000000000 in ?? () #102 0x0000000000000000 in ?? () #103 0x0000000000000000 in ?? () #104 0x0000000000000000 in ?? () #105 0x0000000000000000 in ?? () #106 0x0000000000000000 in ?? () #107 0x0000000000000000 in ?? () #108 0x0000000000000000 in ?? () #109 0x0000000000000000 in ?? () #110 0x0000000000000000 in ?? () #111 0x0000000000000000 in ?? () #112 0x0000000000000000 in ?? () #113 0x0000000000000000 in ?? () #114 0x0000000000000000 in ?? () #115 0x0000000000000000 in ?? () #116 0x0000000000000000 in ?? () #117 0x0000000000000000 in ?? () #118 0x0000000000000000 in ?? () Cannot access memory at address 0xffffffff9e728000 (kgdb) bt full #0 doadump () at pcpu.h:194 No locals. #1 0x8888888888888889 in ?? () No symbol table info available. #2 0xffffffff80246bc4 in boot (howto=3D260) at = ../../../kern/kern_shutdown.c:409 _ep =3D Variable "_ep" is not available. (kgdb) ------=_NextPart_000_00A2_01C889D2.15AB3B60 Content-Type: text/plain; name="backtrace3.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="backtrace3.txt" [GDB will not be able to debug user-mode threads: = /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you = are welcome to change it and/or distribute copies of it under certain = conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for = details. This GDB was configured as "amd64-marcel-freebsd". Unread portion of the kernel message buffer: Slab at 0xffffff0001648f50, freei 12 =3D 0. panic: Duplicate free of item 0xffffff0001648c00 from zone = 0xffffff003bfdce00(mbuf_packet) cpuid =3D 1 Uptime: 10s Physical memory: 952 MB Dumping 56 MB: 41 25 9 #0 doadump () at pcpu.h:194 194pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:194 #1 0xffffff000105a480 in ?? () #2 0xffffffff80246bc4 in boot (howto=3D260) at = ../../../kern/kern_shutdown.c:409 #3 0xffffffff80246fbd in panic (fmt=3D0x104
) at ../../../kern/kern_shutdown.c:563 #4 0xffffffff803a0f28 in uma_dbg_free (zone=3DVariable "zone" is not = available. ) at ../../../vm/uma_dbg.c:302 #5 0xffffffff8039fa54 in uma_zfree_arg (zone=3D0xffffff003bfdce00,=20 item=3D0xffffff0001648c00, udata=3D0x0) at = ../../../vm/uma_core.c:2261 #6 0xffffffff80291147 in m_freem (mb=3D0x0) at mbuf.h:510 #7 0xffffffff8033997b in ip_fastforward (m=3D0xffffff0001648c00) at ../../../netinet/ip_fastfwd.c:609 #8 0xffffffff802d4ddf in ether_demux (ifp=3D0xffffff000118a800,=20 m=3D0xffffff0001648c00) at ../../../net/if_ethersubr.c:770 #9 0xffffffff802d50a8 in ether_input (ifp=3D0xffffff000118a800,=20 m=3D0xffffff0001648c00) at ../../../net/if_ethersubr.c:692 #10 0xffffffff801a133a in em_handle_rxtx (context=3DVariable "context" = is not available. ) at ../../../dev/em/if_em.c:4542 #11 0xffffffff802767a1 in taskqueue_run (queue=3D0xffffff00011f0a80) at ../../../kern/subr_taskqueue.c:255 #12 0xffffffff80276932 in taskqueue_thread_loop (arg=3DVariable "arg" is = not available. ) at ../../../kern/subr_taskqueue.c:374 #13 0xffffffff8022b03e in fork_exit ( callout=3D0xffffffff802768e0 ,=20 arg=3D0xffffff00011a84d8, frame=3D0xffffffff9e6d3c80) at ../../../kern/kern_fork.c:781 #14 0xffffffff803be24e in fork_trampoline () at ../../../amd64/amd64/exception.S:415 #15 0x0000000000000000 in ?? () #16 0x0000000000000000 in ?? () #17 0x0000000000000001 in ?? () #18 0x0000000000000000 in ?? () #19 0x0000000000000000 in ?? () #20 0x0000000000000000 in ?? () #21 0x0000000000000000 in ?? () #22 0x0000000000000000 in ?? () #23 0x0000000000000000 in ?? () #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000000 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000000 in ?? () #30 0x0000000000000000 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000000 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000000 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000000000 in ?? () #37 0x0000000000000000 in ?? () #38 0x0000000000000000 in ?? () #39 0x00000000007a3000 in ?? () #40 0xffffff003bfddd20 in ?? () #41 0xffffff00011c3000 in ?? () #42 0xffffffff805c5000 in facility_initialized () #43 0xffffff00011c3000 in ?? () #44 0xffffff0001060680 in ?? () #45 0xffffffff9e6d37e8 in ?? () #46 0xffffff00011049c0 in ?? () #47 0xffffffff80263b8d in sched_switch (td=3D0xffffff00011a84d8, = newtd=3D0x0,=20 flags=3DVariable "flags" is not available. ) at ../../../kern/sched_4bsd.c:905 #48 0x0000000000000000 in ?? () #49 0x0000000000000000 in ?? () #50 0x0000000000000000 in ?? () #51 0x0000000000000000 in ?? () #52 0x0000000000000000 in ?? () #53 0x0000000000000000 in ?? () #54 0x0000000000000000 in ?? () #55 0x0000000000000000 in ?? () #56 0x0000000000000000 in ?? () #57 0x0000000000000000 in ?? () #58 0x0000000000000000 in ?? () #59 0x0000000000000000 in ?? () #60 0x0000000000000000 in ?? () #61 0x0000000000000000 in ?? () #62 0x0000000000000000 in ?? () #63 0x0000000000000000 in ?? () #64 0x0000000000000000 in ?? () #65 0x0000000000000000 in ?? () #66 0x0000000000000000 in ?? () #67 0x0000000000000000 in ?? () #68 0x0000000000000000 in ?? () #69 0x0000000000000000 in ?? () #70 0x0000000000000000 in ?? () #71 0x0000000000000000 in ?? () #72 0x0000000000000000 in ?? () #73 0x0000000000000000 in ?? () #74 0x0000000000000000 in ?? () #75 0x0000000000000000 in ?? () #76 0x0000000000000000 in ?? () #77 0x0000000000000000 in ?? () #78 0x0000000000000000 in ?? () #79 0x0000000000000000 in ?? () #80 0x0000000000000000 in ?? () #81 0x0000000000000000 in ?? () #82 0x0000000000000000 in ?? () #83 0x0000000000000000 in ?? () #84 0x0000000000000000 in ?? () #85 0x0000000000000000 in ?? () #86 0x0000000000000000 in ?? () #87 0x0000000000000000 in ?? () #88 0x0000000000000000 in ?? () #89 0x0000000000000000 in ?? () #90 0x0000000000000000 in ?? () #91 0x0000000000000000 in ?? () #92 0x0000000000000000 in ?? () #93 0x0000000000000000 in ?? () #94 0x0000000000000000 in ?? () #95 0x0000000000000000 in ?? () #96 0x0000000000000000 in ?? () #97 0x0000000000000000 in ?? () #98 0x0000000000000000 in ?? () #99 0x0000000000000000 in ?? () #100 0x0000000000000000 in ?? () #101 0x0000000000000000 in ?? () #102 0x0000000000000000 in ?? () #103 0x0000000000000000 in ?? () #104 0x0000000000000000 in ?? () #105 0x0000000000000000 in ?? () #106 0x0000000000000000 in ?? () #107 0x0000000000000000 in ?? () #108 0x0000000000000000 in ?? () #109 0x0000000000000000 in ?? () #110 0x0000000000000000 in ?? () #111 0x0000000000000000 in ?? () #112 0x0000000000000000 in ?? () #113 0x0000000000000000 in ?? () #114 0x0000000000000000 in ?? () #115 0x0000000000000000 in ?? () #116 0x0000000000000000 in ?? () #117 0x0000000000000000 in ?? () #118 0x0000000000000000 in ?? () #119 0x0000000000000000 in ?? () Cannot access memory at address 0xffffffff9e6d4000 (kgdb) bt full #0 doadump () at pcpu.h:194 No locals. #1 0xffffff000105a480 in ?? () No symbol table info available. #2 0xffffffff80246bc4 in boot (howto=3D260) at = ../../../kern/kern_shutdown.c:409 _ep =3D Variable "_ep" is not available. (kgdb) ------=_NextPart_000_00A2_01C889D2.15AB3B60-- From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 19 18:29: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 86B691065674 for ; Wed, 19 Mar 2008 18:29:14 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outZ.internet-mail-service.net (outZ.internet-mail-service.net [216.240.47.249]) by mx1.freebsd.org (Postfix) with ESMTP id 745228FC32 for ; Wed, 19 Mar 2008 18:29:14 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Wed, 19 Mar 2008 11:29:50 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id A321A2D6731; Wed, 19 Mar 2008 11:29:13 -0700 (PDT) Message-ID: <47E15B79.4060908@elischer.org> Date: Wed, 19 Mar 2008 11:29:13 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: vadim_nuclight@mail.ru References: <200803122100.m2CL0t7V088955@freefall.freebsd.org> <20080313094356.GA9219@tin.it> <47DF72A3.4030502@yandex.ru> <47DF78AF.400@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org Subject: Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION 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: Wed, 19 Mar 2008 18:29:14 -0000 Vadim Goncharov wrote: > Hi Julian Elischer! > > On Tue, 18 Mar 2008 01:09:19 -0700; Julian Elischer wrote about 'Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION': > >>> About Vadim's prepositions: >>> 1. tablearg: it's possible, but now we use u32 argument in >>> tables, but counterlimits are 64-bits values. First of we >>> should extend our current table argument to 64 bit. >> tables should be expanded to have different types of values.. >> 32 but ints >> IP addresses (currently I'm overlaying it on 32 bit ints) >> IPV6 addresses. >> skipto locations >> byte limits.. > > Are you talking about tablearg-values (data), or keys too? And does that count > only IP addrs and integers of different sizes, or strings too? In this case I'm talking about the args. table keys DO need to be expanded to handle ipv6 stuff and other such things, but that is not what we were discussing. > From owner-freebsd-ipfw@FreeBSD.ORG Thu Mar 20 16:50:02 2008 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 582D6106566B for ; Thu, 20 Mar 2008 16:50:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 331BE8FC12 for ; Thu, 20 Mar 2008 16:50:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2KGo2Nj009209 for ; Thu, 20 Mar 2008 16:50:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2KGo2gY009208; Thu, 20 Mar 2008 16:50:02 GMT (envelope-from gnats) Date: Thu, 20 Mar 2008 16:50:02 GMT Message-Id: <200803201650.m2KGo2gY009208@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: "Andrew Bliznak" Cc: Subject: Re: kern/121382: [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (corrupt stack?) after ~5d uptime X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrew Bliznak List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2008 16:50:02 -0000 The following reply was made to PR kern/121382; it has been noted by GNATS. From: "Andrew Bliznak" To: bug-followup@FreeBSD.org, andriko.b@gmail.com Cc: Subject: Re: kern/121382: [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (corrupt stack?) after ~5d uptime Date: Thu, 20 Mar 2008 18:17:00 +0200 hmm, Added to /etc/sysctl.conf one string: net.inet.ip.intr_queue_maxlen=512 And after last reboot now uptime > 10 days... From owner-freebsd-ipfw@FreeBSD.ORG Fri Mar 21 19:19:23 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 3337D106566B for ; Fri, 21 Mar 2008 19:19:23 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 014318FC20 for ; Fri, 21 Mar 2008 19:19:22 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1Jcmlu-0001LS-8c for freebsd-ipfw@freebsd.org; Fri, 21 Mar 2008 12:19:22 -0700 Message-ID: <16206009.post@talk.nabble.com> Date: Fri, 21 Mar 2008 12:19:22 -0700 (PDT) From: swamyg1 To: freebsd-ipfw@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: swamyg1@gmail.com Subject: Log is empty, have I been hacked? 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, 21 Mar 2008 19:19:23 -0000 My log is empty, need help troubleshooting....firewall rules deffinately have "log" in them....have I been hacked? -- View this message in context: http://www.nabble.com/Log-is-empty%2C-have-I-been-hacked--tp16206009p16206009.html Sent from the freebsd-ipfw mailing list archive at Nabble.com. From owner-freebsd-ipfw@FreeBSD.ORG Fri Mar 21 20:04:41 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 B1956106566C for ; Fri, 21 Mar 2008 20:04:41 +0000 (UTC) (envelope-from kagekonjou@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.186]) by mx1.freebsd.org (Postfix) with ESMTP id 7BD918FC29 for ; Fri, 21 Mar 2008 20:04:41 +0000 (UTC) (envelope-from kagekonjou@gmail.com) Received: by rv-out-0910.google.com with SMTP id g13so966988rvb.43 for ; Fri, 21 Mar 2008 13:04:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=BhcTLU9uHaltvrd5Ixdyp7PuRZTorwf9QkknZcvAoic=; b=ivbhYA80OvTWebExSTqFd/At8KRnjo23qIYQtBQI+cWK5ApUwx3Pmud35GTTM87fWpBCd+HhJW9Uv4PtnXbSokmurOjyzFoZd7wvmN4F4Wpv5SScLl7Mbikg8pQHM3KGbcSkSE62CRod+aaXPFKDpq622ZewVk2AxRyYYG+abbs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=dabEzUXByDd2z2Cg43dfXfnzb56gmtbdzD2wdCO7lzdlsfQ9YnSEvcv5OiJLYNiwyntYCFCVMWAhJqnTm6JF3Con5tRoOlsWpRsq/EhqTuqDWES5x3xiPZJspaSMwlUGSK0UFx/IzFfPUSIBgWW1zv40QkM2yESKEyI6CiAhWug= Received: by 10.141.76.21 with SMTP id d21mr1585925rvl.270.1206128359537; Fri, 21 Mar 2008 12:39:19 -0700 (PDT) Received: by 10.70.110.17 with HTTP; Fri, 21 Mar 2008 12:39:19 -0700 (PDT) Message-ID: Date: Fri, 21 Mar 2008 15:39:19 -0400 From: Kage To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-ipfw@freebsd.org Subject: natd port forward times out, tcpdump yields nothing 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, 21 Mar 2008 20:04:41 -0000 Hey guys, This is a fun one that's stumped people in Freenode ##freebsd. Basically, I have this layout: irc.domain.com -> DNS A -> IRC Jail When someone connects to irc.domain.com on IRC ports (6667, 8067, etc.), it round-robins them using natd, otherwise it sends all other port requests to the IRC jail as per normal (such as port 80, which is my primary concern). As for having it setup to have ipfw divert to natd, that's done and works, as shown by natd verbose mode: In {default}[TCP] [TCP] 72.65.73.23:2980 -> 207.210.114.45:6667 aliased to [TCP] 72.65.73.23:2980 -> 207.210.114.45:6667 (For reference) 207.210.114.45 = jail IP 72.20.28.202 = example target IP in the round-robin 72.65.73.23 = my IP Right now, my ipfw.rules file is as follows: [root@nub /etc]# cat ipfw.rules IPF="ipfw -q add" ipfw -f -q flush #loopback $IPF 10 allow all from any to any via lo0 $IPF 20 deny all from any to 127.0.0.0/8 $IPF 30 deny all from 127.0.0.0/8 to any $IPF 40 deny tcp from any to any frag # statefull $IPF 50 check-state $IPF 60 allow tcp from any to any established $IPF 70 allow all from any to any out keep-state $IPF 54999 allow icmp from any to any # Include the deny file . /etc/ipfw.deny [snip -- some allowed ports] # IRC (natd divert for IRC port-forwarding $IPF 50220 divert natd all from any to 207.210.114.45 6667 via rl0 $IPF 50230 divert natd all from any to 207.210.114.45 8067 via rl0 $IPF 50240 divert natd all from any to 207.210.114.45 8068 via rl0 $IPF 50250 divert natd all from any to 207.210.114.45 6697 via rl0 $IPF 50260 divert natd all from any to 207.210.114.45 7000 via rl0 # keep these two IRC ports normally open for BNC $IPF 50270 allow all from any to any 31337 in $IPF 50380 allow all from any to any 31337 out [snip -- more allowed ports] # deny and log everything $IPF 55000 deny log all from any to any ----- Here's a dump of ipfw show, with some stuff cut out for space purposes (they're just denied DDoS IPs) [root@nub /etc]# ipfw show 00010 61124 16056802 allow ip from any to any via lo0 00020 0 0 deny ip from any to 127.0.0.0/8 00030 0 0 deny ip from 127.0.0.0/8 to any 00040 0 0 deny tcp from any to any frag 00050 0 0 check-state 00060 670616 455926379 allow tcp from any to any established 00070 16213 14071853 allow ip from any to any out keep-state [snip] 50220 468 22464 divert 8668 ip from any to 207.210.114.45 dst-port 6667 via rl0 50230 0 0 divert 8668 ip from any to 207.210.114.45 dst-port 8067 via rl0 50240 0 0 divert 8668 ip from any to 207.210.114.45 dst-port 8068 via rl0 50250 0 0 divert 8668 ip from any to 207.210.114.45 dst-port 6697 via rl0 50260 0 0 divert 8668 ip from any to 207.210.114.45 dst-port 7000 via rl0 50270 1 60 allow ip from any to any dst-port 31337 in 54999 66 3991 allow icmp from any to any 55000 4364 343609 deny log logamount 100 ip from any to any 65535 29 4176 allow ip from any to any My natd.conf is as follows: [root@nub /etc]# cat natd.conf # Nub.Core NATd verbose alias_address 207.210.114.45 log log_denied log_ipfw_denied pid_file /var/run/natd.pid ### IRC Redirect Ports # 6667 redirect_port tcp 72.20.28.202:6667 207.210.114.45:6667 207.210.114.45:6667 [root@nub /etc]# And, as stated above, I am showing connection diverts to natd. When I run the following three tcpdumps: tcpdump -s 0 -w me_to_nat.pcap -vvv -i rl0 src host 72.65.73.23 and dst host 207.210.114.45 and dst port 6667 tcpdump -s 0 -w nat_to_jail.pcap -vvv -i rl0 src host 72.20.28.202 and dst host 207.210.114.45 and dst port 6667 tcpdump -s 0 -w jail_to_nat.pcap -vvv -i rl0 src host 207.210.114.45 and dst host 72.20.28.202 and src port 6667 Only the "me_to_nat.pcap" gets any data. The rest are 0 bytes. Example: -rw-r--r-- 1 root wheel 0 Mar 21 14:57 jail_to_nat.pcap -rw-r--r-- 1 root wheel 16384 Mar 21 15:24 me_to_nat.pcap -rw-r--r-- 1 root wheel 0 Mar 21 14:57 nat_to_jail.pcap So, can anyone diagnose and fix this? Thanks. (P.S.: I'm aware of the DNS methods of doing round-robin, but please keep that from this discussion. I need to port-forward round-robin, not whole DNS) -- ~ Kage http://vitund.com http://hackthissite.org From owner-freebsd-ipfw@FreeBSD.ORG Sat Mar 22 10:43:16 2008 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37FCA1065676; Sat, 22 Mar 2008 10:43:16 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 112218FC15; Sat, 22 Mar 2008 10:43:16 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2MAhFsF099233; Sat, 22 Mar 2008 10:43:15 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2MAhFpx099229; Sat, 22 Mar 2008 10:43:15 GMT (envelope-from remko) Date: Sat, 22 Mar 2008 10:43:15 GMT Message-Id: <200803221043.m2MAhFpx099229@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/121955: freebsd 7.0 panic with mpd 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: Sat, 22 Mar 2008 10:43:16 -0000 Synopsis: freebsd 7.0 panic with mpd Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: remko Responsible-Changed-When: Sat Mar 22 10:43:15 UTC 2008 Responsible-Changed-Why: Could be potentially something for ipfw (which is in the first gdb output). http://www.freebsd.org/cgi/query-pr.cgi?pr=121955 From owner-freebsd-ipfw@FreeBSD.ORG Sat Mar 22 10:49:48 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 2FE011065671; Sat, 22 Mar 2008 10:49:48 +0000 (UTC) (envelope-from kagekonjou@gmail.com) Received: from mgw-fb01.nokia.com (mgw-fb01.nokia.com [192.100.122.235]) by mx1.freebsd.org (Postfix) with ESMTP id 7EEAE8FC1F; Sat, 22 Mar 2008 10:49:47 +0000 (UTC) (envelope-from kagekonjou@gmail.com) Received: from mgw-mx03.nokia.com (mgw-mx03.nokia.com [192.100.122.230]) by mgw-fb01.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m2MAUroL026255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 22 Mar 2008 12:30:54 +0200 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m2MAUoSj001642; Sat, 22 Mar 2008 12:30:50 +0200 Received: from mail pickup service by esebh107.NOE.Nokia.com with Microsoft SMTPSVC; Sat, 22 Mar 2008 12:26:59 +0200 Received: from mgw-mx07.nokia.com ([192.100.105.132]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Mar 2008 22:06:46 +0200 Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mgw-mx07.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m2LK8CXW012486 for ; Fri, 21 Mar 2008 15:08:13 -0500 Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 9E822157198; Fri, 21 Mar 2008 20:06:36 +0000 (UTC) (envelope-from owner-freebsd-net@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 0CC7B10656EA; Fri, 21 Mar 2008 20:06:36 +0000 (UTC) (envelope-from owner-freebsd-net@freebsd.org) Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 656661065670 for ; Fri, 21 Mar 2008 20:06:30 +0000 (UTC) (envelope-from kagekonjou@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.187]) by mx1.freebsd.org (Postfix) with ESMTP id 9A7218FC14 for ; Fri, 21 Mar 2008 20:06:29 +0000 (UTC) (envelope-from kagekonjou@gmail.com) Received: by rv-out-0910.google.com with SMTP id g13so967456rvb.43 for ; Fri, 21 Mar 2008 13:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=BhcTLU9uHaltvrd5Ixdyp7PuRZTorwf9QkknZcvAoic=; b=ivbhYA80OvTWebExSTqFd/At8KRnjo23qIYQtBQI+cWK5ApUwx3Pmud35GTTM87fWpBCd+HhJW9Uv4PtnXbSokmurOjyzFoZd7wvmN4F4Wpv5SScLl7Mbikg8pQHM3KGbcSkSE62CRod+aaXPFKDpq622ZewVk2AxRyYYG+abbs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=dabEzUXByDd2z2Cg43dfXfnzb56gmtbdzD2wdCO7lzdlsfQ9YnSEvcv5OiJLYNiwyntYCFCVMWAhJqnTm6JF3Con5tRoOlsWpRsq/EhqTuqDWES5x3xiPZJspaSMwlUGSK0UFx/IzFfPUSIBgWW1zv40QkM2yESKEyI6CiAhWug= Received: by 10.141.76.21 with SMTP id d21mr1585925rvl.270.1206128359537; Fri, 21 Mar 2008 12:39:19 -0700 (PDT) Received: by 10.70.110.17 with HTTP; Fri, 21 Mar 2008 12:39:19 -0700 (PDT) Message-ID: Date: Fri, 21 Mar 2008 15:39:19 -0400 From: "ext Kage" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-net@freebsd.org Errors-To: owner-freebsd-net@freebsd.org X-Nokia-AV: Clean X-pstn-spam: N X-Spam-Score: 0.00% X-OriginalArrivalTime: 21 Mar 2008 20:06:47.0090 (UTC) FILETIME=[177FE120:01C88B8F] Cc: freebsd-ipfw@freebsd.org Subject: natd port forward times out, tcpdump yields nothing X-BeenThere: freebsd-ipfw@freebsd.org List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2008 10:49:48 -0000 Hey guys, This is a fun one that's stumped people in Freenode ##freebsd. Basically, I have this layout: irc.domain.com -> DNS A -> IRC Jail When someone connects to irc.domain.com on IRC ports (6667, 8067, etc.), it round-robins them using natd, otherwise it sends all other port requests to the IRC jail as per normal (such as port 80, which is my primary concern). As for having it setup to have ipfw divert to natd, that's done and works, as shown by natd verbose mode: In {default}[TCP] [TCP] 72.65.73.23:2980 -> 207.210.114.45:6667 aliased to [TCP] 72.65.73.23:2980 -> 207.210.114.45:6667 (For reference) 207.210.114.45 = jail IP 72.20.28.202 = example target IP in the round-robin 72.65.73.23 = my IP Right now, my ipfw.rules file is as follows: [root@nub /etc]# cat ipfw.rules IPF="ipfw -q add" ipfw -f -q flush #loopback $IPF 10 allow all from any to any via lo0 $IPF 20 deny all from any to 127.0.0.0/8 $IPF 30 deny all from 127.0.0.0/8 to any $IPF 40 deny tcp from any to any frag # statefull $IPF 50 check-state $IPF 60 allow tcp from any to any established $IPF 70 allow all from any to any out keep-state $IPF 54999 allow icmp from any to any # Include the deny file /etc/ipfw.deny [snip -- some allowed ports] # IRC (natd divert for IRC port-forwarding $IPF 50220 divert natd all from any to 207.210.114.45 6667 via rl0 $IPF 50230 divert natd all from any to 207.210.114.45 8067 via rl0 $IPF 50240 divert natd all from any to 207.210.114.45 8068 via rl0 $IPF 50250 divert natd all from any to 207.210.114.45 6697 via rl0 $IPF 50260 divert natd all from any to 207.210.114.45 7000 via rl0 # keep these two IRC ports normally open for BNC $IPF 50270 allow all from any to any 31337 in $IPF 50380 allow all from any to any 31337 out [snip -- more allowed ports] # deny and log everything $IPF 55000 deny log all from any to any ----- Here's a dump of ipfw show, with some stuff cut out for space purposes (they're just denied DDoS IPs) [root@nub /etc]# ipfw show 00010 61124 16056802 allow ip from any to any via lo0 00020 0 0 deny ip from any to 127.0.0.0/8 00030 0 0 deny ip from 127.0.0.0/8 to any 00040 0 0 deny tcp from any to any frag 00050 0 0 check-state 00060 670616 455926379 allow tcp from any to any established 00070 16213 14071853 allow ip from any to any out keep-state [snip] 50220 468 22464 divert 8668 ip from any to 207.210.114.45 dst-port 6667 via rl0 50230 0 0 divert 8668 ip from any to 207.210.114.45 dst-port 8067 via rl0 50240 0 0 divert 8668 ip from any to 207.210.114.45 dst-port 8068 via rl0 50250 0 0 divert 8668 ip from any to 207.210.114.45 dst-port 6697 via rl0 50260 0 0 divert 8668 ip from any to 207.210.114.45 dst-port 7000 via rl0 50270 1 60 allow ip from any to any dst-port 31337 in 54999 66 3991 allow icmp from any to any 55000 4364 343609 deny log logamount 100 ip from any to any 65535 29 4176 allow ip from any to any My natd.conf is as follows: [root@nub /etc]# cat natd.conf # Nub.Core NATd verbose alias_address 207.210.114.45 log log_denied log_ipfw_denied pid_file /var/run/natd.pid ### IRC Redirect Ports # 6667 redirect_port tcp 72.20.28.202:6667 207.210.114.45:6667 207.210.114.45:6667 [root@nub /etc]# And, as stated above, I am showing connection diverts to natd. When I run the following three tcpdumps: tcpdump -s 0 -w me_to_nat.pcap -vvv -i rl0 src host 72.65.73.23 and dst host 207.210.114.45 and dst port 6667 tcpdump -s 0 -w nat_to_jail.pcap -vvv -i rl0 src host 72.20.28.202 and dst host 207.210.114.45 and dst port 6667 tcpdump -s 0 -w jail_to_nat.pcap -vvv -i rl0 src host 207.210.114.45 and dst host 72.20.28.202 and src port 6667 Only the "me_to_nat.pcap" gets any data. The rest are 0 bytes. Example: -rw-r--r-- 1 root wheel 0 Mar 21 14:57 jail_to_nat.pcap -rw-r--r-- 1 root wheel 16384 Mar 21 15:24 me_to_nat.pcap -rw-r--r-- 1 root wheel 0 Mar 21 14:57 nat_to_jail.pcap So, can anyone diagnose and fix this? Thanks. (P.S.: I'm aware of the DNS methods of doing round-robin, but please keep that from this discussion. I need to port-forward round-robin, not whole DNS) -- ~ Kage http://vitund.com http://hackthissite.org _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"