From owner-freebsd-ipfw@FreeBSD.ORG Sun Jan 11 14:49:36 2004 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 17B8916A4CE; Sun, 11 Jan 2004 14:49:36 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BBA543D48; Sun, 11 Jan 2004 14:49:35 -0800 (PST) (envelope-from johan@FreeBSD.org) Received: from freefall.freebsd.org (johan@localhost [127.0.0.1]) i0BMnZFR086246; Sun, 11 Jan 2004 14:49:35 -0800 (PST) (envelope-from johan@freefall.freebsd.org) Received: (from johan@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i0BMnZBg086242; Sun, 11 Jan 2004 14:49:35 -0800 (PST) (envelope-from johan) Date: Sun, 11 Jan 2004 14:49:35 -0800 (PST) From: Johan Karlsson Message-Id: <200401112249.i0BMnZBg086242@freefall.freebsd.org> To: johan@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: kern/60719: ipfw: Headerless fragments generate cryptic error message X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2004 22:49:36 -0000 Synopsis: ipfw: Headerless fragments generate cryptic error message Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: johan Responsible-Changed-When: Sun Jan 11 14:48:46 PST 2004 Responsible-Changed-Why: Over to maintainer group. http://www.freebsd.org/cgi/query-pr.cgi?pr=60719 From owner-freebsd-ipfw@FreeBSD.ORG Mon Jan 12 00:13:21 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADC2016A4CE for ; Mon, 12 Jan 2004 00:13:21 -0800 (PST) Received: from t1.etype.net (relay1.koenig.su [195.135.213.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1439D43D7C for ; Mon, 12 Jan 2004 00:13:11 -0800 (PST) (envelope-from igor@garant.koenig.ru) Received: by t1.etype.net (Postfix, from userid 83) id 53A0E450C77; Mon, 12 Jan 2004 10:13:08 +0200 (EET) Received: from unix.garant.koenig.ru (unknown [195.135.212.64]) by t1.etype.net (Postfix) with ESMTP id 75946450B6F for ; Mon, 12 Jan 2004 10:12:46 +0200 (EET) Received: (qmail 37358 invoked from network); 12 Jan 2004 08:14:03 -0000 Received: from ns.garant.koenig.ru (HELO unix.garant.koenig.ru) (100.100.100.41) by 0 with SMTP; 12 Jan 2004 08:14:03 -0000 From: =?koi8-r?b?6cfP0tgg8M/Qz9c=?= Organization: =?koi8-r?b?7Pfz?= To: freebsd-ipfw@freebsd.org Date: Mon, 12 Jan 2004 10:14:01 +0200 User-Agent: KMail/1.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401121014.02713.igor@garant.koenig.ru> Subject: ipfw & ipnat X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 08:13:21 -0000 For long time I have used ipfw2 and natd to allow my network work with inetrnet via tun0, now I have faster inernet connection and I need something more than natd. Ipnat is what I need, but it is part of ipf and I don't know how it works with ipfw, and I can't use ipfilter becouse I have using billing system that uses ipdivert too. Can anybody explain me how I can do this? From owner-freebsd-ipfw@FreeBSD.ORG Mon Jan 12 11:02:24 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0688B16A4CE for ; Mon, 12 Jan 2004 11:02:24 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86FD243D7D for ; Mon, 12 Jan 2004 11:01:34 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.10/8.12.10) with ESMTP id i0CJ1XFR025295 for ; Mon, 12 Jan 2004 11:01:33 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i0CJ1Wfd025289 for freebsd-ipfw@freebsd.org; Mon, 12 Jan 2004 11:01:32 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 12 Jan 2004 11:01:32 -0800 (PST) Message-Id: <200401121901.i0CJ1Wfd025289@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 19:02:24 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/12/29] kern/60719 ipfw ipfw: Headerless fragments generate cryp 1 problem total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Jan 12 11:03:15 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D894816A4D0 for ; Mon, 12 Jan 2004 11:03:15 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9344043DA0 for ; Mon, 12 Jan 2004 11:02:01 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.10/8.12.10) with ESMTP id i0CJ1qFR025660 for ; Mon, 12 Jan 2004 11:01:52 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i0CJ1ppa025655 for ipfw@freebsd.org; Mon, 12 Jan 2004 11:01:51 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 12 Jan 2004 11:01:51 -0800 (PST) Message-Id: <200401121901.i0CJ1ppa025655@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: ipfw@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2004 19:03:16 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2002/12/27] kern/46557 ipfw ipfw pipe show fails with lots of queues o [2003/04/22] kern/51274 ipfw ipfw2 create dynamic rules with parent nu f [2003/04/24] kern/51341 ipfw ipfw rule 'deny icmp from any to any icmp 3 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- a [2001/04/13] kern/26534 ipfw Add an option to ipfw to log gid/uid of w o [2002/12/07] kern/46080 ipfw [PATCH] logamount in ipfw2 does not defau o [2002/12/10] kern/46159 ipfw ipfw dynamic rules lifetime feature o [2002/12/27] kern/46564 ipfw IPFilter and IPFW processing order is not o [2003/02/11] kern/48172 ipfw ipfw does not log size and flags o [2003/03/10] kern/49086 ipfw [patch] Make ipfw2 log to different syslo o [2003/03/12] bin/49959 ipfw ipfw tee port rule skips parsing next rul o [2003/04/09] bin/50749 ipfw ipfw2 incorrectly parses ports and port r o [2003/08/25] kern/55984 ipfw [patch] time based firewalling support fo 9 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Jan 12 22:48:53 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA00416A4CE for ; Mon, 12 Jan 2004 22:48:52 -0800 (PST) Received: from router7206.usww.net (router7206.usww.net [216.104.145.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E9FE43D39 for ; Mon, 12 Jan 2004 22:47:37 -0800 (PST) (envelope-from freebsd@usww.com) Received: from usww.com (local41.usww.net [10.0.1.41]) by sub250.usww.net (8.12.8/8.11.6) with ESMTP id i0D6FoNK006284 for ; Tue, 13 Jan 2004 01:15:52 -0500 (EST) (envelope-from freebsd@usww.com) X-HELO: |usww.com| XH-ClientName: |local41.usww.net| XH-ClientAddr: |10.0.1.41| XH-To: || XH-From: |freebsd@usww.com| XH-infoX: |HELO:usww.com|ClientName:local41.usww.net|ClientAddr:10.0.1.41|Email:|From:freebsd@usww.com| XH-info1: (HopCnt:0)(Cur-Ctime-Date:Tue Jan 13 01:15:52 2004)(Unk:) XH-info2: (from:freebsd@usww.com)(Ret:freebsd@usww.com)(DestHost:freebsd.org.)(QueueID:i0D6FoNK006284) XH-info3: (Loc:sub250.usww.net)(Loc:sub250.usww.net)(Unk:)(FQDN:usww.net)(MAILDA:MAILER-DAEMON)(Unk:) XH-info4: (PID:6284)(Unk:)(Proto:ESMTP)(SendHost:usww.com)(Date:200401130615) XH-info5: (To:)(Ver:8.12.8)(Host:sub250)(FNamesender:)(Unk::) XH-info7: (CD:)(SndrAddr:local41.usww.net [10.0.1.41])(CD:‘)(CD:’)(CD:“) XH-info8: (Bodyty:)(ClientAddr:10.0.1.41)(ClientName:local41.usww.net)(ClientPort:16138) XH-info9: (Envid:)(DelivMode:q)(SendFlag:d) Message-ID: <400390EE.385042D2@usww.com> Date: Tue, 13 Jan 2004 01:32:14 -0500 From: freebsd@usww.com Organization: USWW (United States Wide Web) X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org X-Priority: 2 (High) References: <200401121901.i0CJ1Wfd025289@freefall.freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: 4.9 Release ipfw2 - OUCH using limit - reboots X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2004 06:48:53 -0000 Has anyone seen a problem using 4.9 release with IPFW2 using limit causing crashes/reboots and 'OUCH! cannot remove rule, count 65535' in the logfile? Or, does anyone see a problem with my logic. Any help would be appreciated, Ben sysctl config settings: sysctl net.link.ether.bridge_cfg=xl0:0,xl1:0 sysctl net.link.ether.bridge_ipfw=1 sysctl net.link.ether.bridge=1 ---INTERNAL COMPUTERS---xl1--Gateway--xl0---WWW--- # xl0 goes to the WWW from the gateway # xl0: flags=8943 mtu 1500 # inet XX.XX.XX.XX netmask 0xffffff00 broadcast XX.XX.XX.255 # ether 00:60:97:XX:XX:XX # media: Ethernet autoselect (10baseT/UTP) status: active # xl1 goes to internal computers from the gateway # xl1: flags=8943 mtu 1500 # ether 00:a0:24:XX:XX:XX # media: Ethernet autoselect (100baseTX ) status: active The following 3 type lines have been working fine for some time. I have 9 pipes for 9 machines. The first two simple counts the packets/bytes to and from the ethernet card The third manages outgoing bandwidth from one of the several ip's. Dest Source ipfw -q add 100 count mac YY:YY:YY:YY:YY:YY XX:XX:XX:XX:XX:XX ipfw -q add 100 count mac XX:XX:XX:XX:XX:XX YY:YY:YY:YY:YY:YY ipfw -q add 155 pipe 3 tcp from 216.XX.XX.6 20,21,25,80,110 to any;ipfw pipe 3 config bw 512Kbit/s sample use of limit seeming to cause the problem: ipfw -q add 00182 allow log logamount 1000 tcp from any to 216.XX.XX.6 setup limit src-addr 3 in via xl1 Adding the above limit works fine until a large amount of traffic occurs then the gateway reboots If you try to ipfw delete 182 the following is put in /var/log/messages Jan 9 18:48:20 router7206 /kernel: Mounting root from ufs:/dev/ad0s1a Jan 9 18:48:20 router7206 /kernel: WARNING: / was not properly dismounted Jan 9 18:48:24 router7206 /kernel: xl0: promiscuous mode enabled Jan 9 18:48:24 router7206 /kernel: xl1: promiscuous mode enabled Jan 9 18:48:45 router7206 su: ben to root on /dev/ttyp0 ## The following error was put in the log when 'ipfw delete 182' was executed. Jan 9 18:48:46 router7206 /kernel: OUCH! cannot remove rule, count 65535 Jan 9 18:48:46 router7206 last message repeated 2 times Jan 9 18:48:49 router7206 /kernel: bad block -65536, ino 84588 Jan 9 18:48:49 router7206 /kernel: pid 6 (syncer), uid 0 on /var: bad block Jan 9 18:48:49 router7206 /kernel: handle_workitem_freeblocks: block count Jan 9 18:50:58 router7206 /kernel: Mounting root from ufs:/dev/ad0s1a Jan 9 18:50:58 router7206 /kernel: WARNING: / was not properly dismounted Jan 9 18:51:03 router7206 /kernel: xl0: promiscuous mode enabled Jan 9 18:51:03 router7206 /kernel: xl1: promiscuous mode enabled Jan 9 18:51:27 router7206 /kernel: bad block -65536, ino 21135 Jan 9 18:51:27 router7206 /kernel: pid 6 (syncer), uid 0 on /var: bad block Jan 9 18:51:27 router7206 /kernel: handle_workitem_freeblocks: block count Jan 9 18:51:27 router7206 /kernel: bad block -65536, ino 21131 Jan 9 18:51:27 router7206 /kernel: pid 6 (syncer), uid 0 on /var: bad block Jan 9 18:51:48 router7206 su: ben to root on /dev/ttyp0 ## The following error was put in the log when 'ipfw delete 182' was executed. Jan 9 18:52:54 router7206 /kernel: OUCH! cannot remove rule, count 65535 From owner-freebsd-ipfw@FreeBSD.ORG Tue Jan 13 00:39:38 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31A7216A4CE for ; Tue, 13 Jan 2004 00:39:38 -0800 (PST) Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49A7D43D5D for ; Tue, 13 Jan 2004 00:39:27 -0800 (PST) (envelope-from default@tom-mchugh.demon.co.uk) Received: from tom-mchugh.demon.co.uk ([80.176.158.246] helo=avgs) by anchor-post-31.mail.demon.net with esmtp (Exim 3.35 #1) id 1AgK56-0007es-0V for freebsd-ipfw@freebsd.org; Tue, 13 Jan 2004 08:39:24 +0000 From: "tom" To: Date: Tue, 13 Jan 2004 08:39:40 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcPZr6RCT9ky6uT2Th+BwmWpX/7smg== Message-Id: Subject: ipfw from C code X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2004 08:39:38 -0000 new how do I control ipfw from a proggy ? #include to start ? sorry, I know this might be a basic coding lesson, thanks, tom From owner-freebsd-ipfw@FreeBSD.ORG Tue Jan 13 01:11:19 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2297F16A4CF for ; Tue, 13 Jan 2004 01:11:19 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FA2F43D2F for ; Tue, 13 Jan 2004 01:11:18 -0800 (PST) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i0D9BGAF029642; Tue, 13 Jan 2004 01:11:16 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i0D9BGjx029641; Tue, 13 Jan 2004 01:11:16 -0800 (PST) (envelope-from rizzo) Date: Tue, 13 Jan 2004 01:11:15 -0800 From: Luigi Rizzo To: tom Message-ID: <20040113011115.A29198@xorpc.icir.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from default@tom-mchugh.demon.co.uk on Tue, Jan 13, 2004 at 08:39:40AM -0000 cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw from C code X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2004 09:11:19 -0000 On Tue, Jan 13, 2004 at 08:39:40AM -0000, tom wrote: > new > how do I control ipfw from a proggy ? > #include to start ? > sorry, I know this might be a basic coding lesson, i suggest using something like system("ipfw add 2345 allow tcp from foo to bar"); the ABI is way too awkward to use it from C (basically it is microcode if you are using ipfw2, and a large and overloaded rule descriptor if you are using ipfw1). In the long term we will have something like ipfw_compile(out_buffer, &len, "2345 allow tcp from foo to bar"); setsockopt(fd, IP_FW_ADD, out_buffer, len); and then you can the fork overhead. cheers luigi > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Wed Jan 14 08:06:44 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC9D116A4CE; Wed, 14 Jan 2004 08:06:44 -0800 (PST) Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB9C943D60; Wed, 14 Jan 2004 08:06:42 -0800 (PST) (envelope-from fbsd_user@a1poweruser.com) Received: from barbish ([67.20.101.103]) by mta9.adelphia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with SMTP id <20040114160642.VEED11313.mta9.adelphia.net@barbish>; Wed, 14 Jan 2004 11:06:42 -0500 From: "fbsd_user" To: "Dan Pelleg" Date: Wed, 14 Jan 2004 11:06:41 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal cc: freebsd-ipfw@freebsd.org cc: "freebsd-questions@FreeBSD. ORG" Subject: RE: IPFW 'keep state' & 'limit' X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: fbsd_user@a1poweruser.com List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 16:06:44 -0000 The FBSD 5.2 man IPFW does not say anything different that the 4.9 man IPFW. Are you saying the man doc in 5.2 is wrong? 5.2 is using the ipfw2 code for IPFIREWALL I believe. Documenting the fact that 'limit' performs the same function as 'keep state' in additional to 'limit' stated purpose is very important information. Also that 'limit' and 'keep state' can not be coded together is another very important piece information that need to be documented in the man IPFW data. Should this be submitted as an problem report? -----Original Message----- From: Dan Pelleg [mailto:daniel+bsd@pelleg.org] Sent: Wednesday, January 14, 2004 9:47 AM To: fbsd_user@a1poweruser.com Cc: freebsd-questions@FreeBSD. ORG Subject: Re: IPFW 'keep state' & 'limit' "fbsd_user" writes: > Reading the man page on IPFW rule syntax, I get the impression that > the 'limit' option uses the stateful dynamic rules table. But it's > unclear whether 'keep state' and limit can be used on the same rule, > or if the limit option performs the 'keep state' function in > addition to the limit function. > > So as an example > > $cmd 00390 allow tcp from any to any 22 in via dc0 setup keep-state > limit src-addr 3 > > will this work? > limit implies keep-state, and you should really specify one or the other. If you specify both, ipfw won't complain, but ipfw2 will. So it's best to not do that. -- Dan Pelleg From owner-freebsd-ipfw@FreeBSD.ORG Wed Jan 14 08:20:10 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C19C16A4CE for ; Wed, 14 Jan 2004 08:20:10 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5B7943D5D for ; Wed, 14 Jan 2004 08:20:04 -0800 (PST) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i0EGK4AF044887; Wed, 14 Jan 2004 08:20:04 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i0EGK4QH044886; Wed, 14 Jan 2004 08:20:04 -0800 (PST) (envelope-from rizzo) Date: Wed, 14 Jan 2004 08:20:04 -0800 From: Luigi Rizzo To: ipfw@freebsd.org Message-ID: <20040114082004.A43466@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Subject: semantics of 'not-applicable' options in ipfw ? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 16:20:10 -0000 As the subject says... what is people's opinion on the best semantics for 'not-applicable' options in ipfw rules ? As an example, if i say (using ipfw2 syntax, for simplicity) 100 count src-port 100 200 count not src-port 100 and i receive a fragment, or an ICMP packet (which does not have port information available), should it match rule 100, rule 200, none or both ? The current implementation in ipfw2 is to use binary logic, so the outcome of a 'not-applicable' option is FALSE, and its negation is TRUE (so in the above case rule 200 will succeed). Do other firewalls use ternary logic where not-applicable options and their negation will both fail ? (please do not complain on the example and the fact you could insert a "{ proto tcp or proto udp }" block to make the behaviour less ambiguous, my point is just to clarify and specify what is the actual behaviour). cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Wed Jan 14 09:04:51 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8B7F16A4CE for ; Wed, 14 Jan 2004 09:04:51 -0800 (PST) Received: from exchange.wan.no (exchange.wan.no [80.86.128.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59E1943D55 for ; Wed, 14 Jan 2004 09:04:47 -0800 (PST) (envelope-from sten.daniel.sorsdal@wan.no) Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 14 Jan 2004 18:04:45 +0100 Message-ID: <0AF1BBDF1218F14E9B4CCE414744E70F5D9779@exchange.wanglobal.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: semantics of 'not-applicable' options in ipfw ? Thread-Index: AcPaulN3I0OC6nBDTOCLSuWvivr8zQABHPKw From: =?iso-8859-1?Q?Sten_Daniel_S=F8rsdal?= To: "Luigi Rizzo" , Subject: RE: semantics of 'not-applicable' options in ipfw ? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 17:04:51 -0000 =20 > As the subject says... what is people's opinion on the best=20 > semantics for 'not-applicable' options in ipfw rules ? >=20 > As an example, if i say (using ipfw2 syntax, for simplicity) >=20 > 100 count src-port 100 > 200 count not src-port 100 >=20 It is in my opinion that people in general interpret this=20 example to count tcp/udp packets from (src-port=3D=3D100) and (src-port!=3D100), despite the man page. For example; 100 count src-port 100 200 count src-port not 100 I also believe that "via" option also causes the same kind of = confussion. By the way, do you have any plans to implement a tag/flag system? ( example: 100 flag 100 src-port 100 200 allow flag 100 ) _// Sten Daniel S=F8rsdal From owner-freebsd-ipfw@FreeBSD.ORG Wed Jan 14 09:21:56 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E68B16A4CE for ; Wed, 14 Jan 2004 09:21:56 -0800 (PST) Received: from exchange.wan.no (exchange.wan.no [80.86.128.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05ED743D2F for ; Wed, 14 Jan 2004 09:21:54 -0800 (PST) (envelope-from sten.daniel.sorsdal@wan.no) Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 14 Jan 2004 18:21:52 +0100 Message-ID: <0AF1BBDF1218F14E9B4CCE414744E70F5D977C@exchange.wanglobal.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: semantics of 'not-applicable' options in ipfw ? Thread-Index: AcPaulN3I0OC6nBDTOCLSuWvivr8zQACFbPg From: =?iso-8859-1?Q?Sten_Daniel_S=F8rsdal?= To: "Luigi Rizzo" , Subject: RE: semantics of 'not-applicable' options in ipfw ? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 17:21:56 -0000 > As the subject says... what is people's opinion on the best=20 > semantics for 'not-applicable' options in ipfw rules ? >=20 I think 'none'. _// Sten Daniel S=F8rsdal From owner-freebsd-ipfw@FreeBSD.ORG Wed Jan 14 10:51:13 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D305A16A4CE for ; Wed, 14 Jan 2004 10:51:13 -0800 (PST) Received: from privhosting.com (privhosting.com [216.17.101.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DBC143D66 for ; Wed, 14 Jan 2004 10:51:06 -0800 (PST) (envelope-from lists@khimich.com) Received: from localhost (privhosting.com [216.17.101.206]) by privhosting.com (8.12.8p2/8.12.8) with ESMTP id i0EIqTKJ094107 for ; Wed, 14 Jan 2004 18:52:30 GMT (envelope-from lists@khimich.com) Date: Wed, 14 Jan 2004 20:49:35 +0200 From: lists@khimich.com X-Mailer: The Bat! (v1.60) X-Priority: 3 (Normal) Message-ID: <2913864035.20040114204935@cardsgate.com> To: freebsd-ipfw@freebsd.org In-Reply-To: <400390EE.385042D2@usww.com> References: <200401121901.i0CJ1Wfd025289@freefall.freebsd.org> <400390EE.385042D2@usww.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: 4.9 Release ipfw2 - OUCH using limit - reboots X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 18:51:13 -0000 Hello freebsd, Tuesday, January 13, 2004, 8:32:14 AM, you wrote: fuc> Has anyone seen a problem using 4.9 release with IPFW2 using limit fuc> causing crashes/reboots and 'OUCH! cannot remove rule, count 65535' fuc> in the logfile? Or, does anyone see a problem with my logic. fuc> sample use of limit seeming to cause the problem: fuc> ipfw -q add 00182 allow log logamount 1000 tcp from any to 216.XX.XX.6 setup limit src-addr 3 in via xl1 I can confirm the same on 4.9 with FreeBSD 4.8-RELEASE. My sysctl settings with dyn_buckets was default. Machine reboots on high amount of traffic. -- Best regards, lists mailto:lists@khimich.com From owner-freebsd-ipfw@FreeBSD.ORG Wed Jan 14 12:48:21 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F18B16A4CE; Wed, 14 Jan 2004 12:48:21 -0800 (PST) Received: from gw.pelleg.org (gw.pelleg.org [205.201.13.235]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADE9C43D41; Wed, 14 Jan 2004 12:47:56 -0800 (PST) (envelope-from daniel@pelleg.org) Received: from lank.here (lank.wburn [192.168.3.41]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "gw.pelleg.org", Issuer "Dan Pelleg" (verified OK)) by gw.pelleg.org (Postfix) with ESMTP id C49635A53; Wed, 14 Jan 2004 15:47:54 -0500 (EST) Received: by lank.here (Postfix, from userid 7675) id D4E74AFF; Wed, 14 Jan 2004 15:47:48 -0500 (EST) To: References: From: Dan Pelleg Date: Wed, 14 Jan 2004 15:47:48 -0500 In-Reply-To: (fbsd user's message of "Wed, 14 Jan 2004 11:06:41 -0500") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.1 (Cuyahoga Valley, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-ipfw@freebsd.org cc: "freebsd-questions@FreeBSD. ORG" Subject: Re: IPFW 'keep state' & 'limit' X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 20:48:21 -0000 "fbsd_user" writes: > The FBSD 5.2 man IPFW does not say anything different that the 4.9 > man IPFW. > Are you saying the man doc in 5.2 is wrong? > > 5.2 is using the ipfw2 code for IPFIREWALL I believe. > > Documenting the fact that 'limit' performs the same function as > 'keep state' in additional to 'limit' stated purpose is very > important information. Also that 'limit' and 'keep state' can not be > coded together is another very important piece information that need > to be documented in the man IPFW data. > > Should this be submitted as an problem report? > > > > -----Original Message----- > From: Dan Pelleg [mailto:daniel+bsd@pelleg.org] > Sent: Wednesday, January 14, 2004 9:47 AM > To: fbsd_user@a1poweruser.com > Cc: freebsd-questions@FreeBSD. ORG > Subject: Re: IPFW 'keep state' & 'limit' > > "fbsd_user" writes: > >> Reading the man page on IPFW rule syntax, I get the impression > that >> the 'limit' option uses the stateful dynamic rules table. But it's >> unclear whether 'keep state' and limit can be used on the same > rule, >> or if the limit option performs the 'keep state' function in >> addition to the limit function. >> >> So as an example >> >> $cmd 00390 allow tcp from any to any 22 in via dc0 setup > keep-state >> limit src-addr 3 >> >> will this work? >> > > limit implies keep-state, and you should really specify one or the > other. If you specify both, ipfw won't complain, but ipfw2 will. So > it's > best to not do that. > > -- > > Dan Pelleg > > > Your rule, given to IPFW2 (on a 4.X system), yields: ipfw: only one of keep-state and limit is allowed I wouldn't say the man page hides the first fact; it is reasonably careful to say "keep-state or limit" in most places. It does, however, not mention that specifying both in the same rule is not accepted. In fact it says that "Zero or more" rule options are accepted, with both limit and keep-state listed as options (in the RULE OPTIONS section - this is on a man page from around 5.1). Given this might surprise people who move to 5.X and even lock them out, it might also be worth mentioning in one of migration guides. I suggest you bring this up to the doc@ list. -- Dan Pelleg From owner-freebsd-ipfw@FreeBSD.ORG Wed Jan 14 12:54:23 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8F9F16A4CE for ; Wed, 14 Jan 2004 12:54:23 -0800 (PST) Received: from smtpout.mac.com (A17-250-248-85.apple.com [17.250.248.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFA7243D55 for ; Wed, 14 Jan 2004 12:54:00 -0800 (PST) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i0EKs0mB011017; Wed, 14 Jan 2004 12:54:00 -0800 (PST) Received: from [10.1.1.193] (nfw2.codefab.com [66.234.138.66]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 3.0) with ESMTP id i0EKrxgj020506; Wed, 14 Jan 2004 12:54:00 -0800 (PST) In-Reply-To: <20040114082004.A43466@xorpc.icir.org> References: <20040114082004.A43466@xorpc.icir.org> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Wed, 14 Jan 2004 15:53:59 -0500 To: Luigi Rizzo X-Mailer: Apple Mail (2.609) cc: ipfw@freebsd.org Subject: Re: semantics of 'not-applicable' options in ipfw ? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 20:54:24 -0000 Hi, all-- On Jan 14, 2004, at 11:20 AM, Luigi Rizzo wrote: > As an example, if i say (using ipfw2 syntax, for simplicity) > > 100 count src-port 100 > 200 count not src-port 100 > > and i receive a fragment, or an ICMP packet (which does not have port > information available), should it match rule 100, rule 200, none > or both ? The current implementation in ipfw2 is to use binary > logic, so the outcome of a 'not-applicable' option is FALSE, > and its negation is TRUE (so in the above case rule 200 will succeed). The current behavior is reasonable, and matching none would also reasonable-- if it were documented as behaving that way, but the former is more intuitive. It seems unreasonable for an ICMP packet to match rule 100, thus disqualifying the "match both" case. > Do other firewalls use ternary logic where not-applicable > options and their negation will both fail ? I haven't seen another firewall use ternary logic, although I remember enough of EE to remember working with 0's, 1's, and X's for "don't care" or "not-applicable". If an output of a logic expression results in a don't-care, the behavior of that part of the system is undefined. We want the behavior of the firewall to be deterministic, right? (Most of the time, anyway-- I acknowledge the prob keyword is a counterexample, but that is a special case. :-) > (please do not complain on the example and the fact you could > insert a "{ proto tcp or proto udp }" block to make the > behaviour less ambiguous, my point is just to clarify and > specify what is the actual behaviour). It would be reasonable for IPFW to require that the use of src-port also require that a procotol which uses port numbers be specified, otherwise generate a warning to the user about the ambiguity. In other words, this would keep the current behavior. It would be reasonable for the use of src-port to imply a test of the form (if packet contains an identifiable port number) && (src-port matches the rule as written by the user). This corresponds to the "match none" case above. Perhaps it might even be reasonable for IPFW to decide that the port number of a packet for which no port number can be determined is 0, thereby removing the ambiguity in another fashion. Port 0 is reserved per IANA/RFC1700, so the primary real-world use for packets using port 0 is for TCP stack identification (used by NMAP et al). The reasoning for this last suggestion involves more of a notion of IPFW parsing a set of values from each packet it sees and falling back to sensible default values for information which is not present but is being tested by a rule anyway, either explicitly or by implication (such as asking for the port number of an ICMP packet). -- -Chuck From owner-freebsd-ipfw@FreeBSD.ORG Wed Jan 14 13:01:53 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E86B316A4CE for ; Wed, 14 Jan 2004 13:01:53 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id D33FA43D41 for ; Wed, 14 Jan 2004 13:01:23 -0800 (PST) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i0EL1NAF087145; Wed, 14 Jan 2004 13:01:23 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i0EL1N3d087144; Wed, 14 Jan 2004 13:01:23 -0800 (PST) (envelope-from rizzo) Date: Wed, 14 Jan 2004 13:01:22 -0800 From: Luigi Rizzo To: ipfw@freebsd.org Message-ID: <20040114130122.A86000@xorpc.icir.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Subject: Request for review: ipfw2 for IPV6 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 21:01:54 -0000 --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I am attaching some very experimental (and only partly functional) code to use ipfw2/dummynet with IPV6. THIS IS NOT RECOMMENDED FOR REGULAR USE, JUST FOR EVALUATION. The code has been developed by two students of mine, Mariano Tortoriello and Raffaele De Lorenzo, and I only revised it briefly. I think the overall architecture is reasonably close to the final one, although there are some optimizations and changes to improve compatibility with other kernel options. We would really appreciate testing by someone who is a kernel programmer who has access to ipv6 network and some knowledge of the ipv6 code, and thus can give advice on how to improve this code, and possibly suggest fixes for the trivial bugs that are there. Installation instructions: + the patch is based on 4.9_RELEASE + move just above your src/ directory and do a gzcat ipfw6.040114a.diff.gz | patch + install the patched copy of netinet/ip_dummynet.h and ip_fw2.h into /usr/include/netinet + add the IPFIREWALL and IPFW2 options in the kernel, together with the IPV6 options (no IPV6FIREWALL) + rebuild and reinstall the kernel and /sbin/ipfw, remember to use "make -DIPFW2" for the latter At this point you should be able to use ipv6 addresses in ipfw instruction, the new option "ipv6" which only matches ipv6 packets. The system _will_ panic if you are trying to use dummynet on output packets, the reasons of the panic are still to investigate. Dummynet on the input path seems to work, as well as on layer2. There might be other bugs, which I would be happy to hear about as i only did very limited testing. cheers luigi --ReaqsoxgOBHFXBhH Content-Type: application/octet-stream Content-Disposition: attachment; filename="ipfw6.040114a.diff.gz" Content-Transfer-Encoding: base64 H4sICA+YBUACA2lwZnc2LjA0MDExNGEuZGlmZgDEO2tX28iSn8Wv6GTOcCX8wC9kwIEMF8zE O7yGOJPM2bmjI6QW1sWWhCRDuJP8962q7tbDlg3J7NnNOTF2q6q6u15dj9YocPnnfZbEznby lGwHPPXh/7YfWe58NnuC701n4+Dv/9u4Pn7PPH/K99n2JJzx7cB5SLbXTlt/2Ih5Gvv8wQ9u WQx/Ej8MWLvZ6TU7zY654fqexxpz1oizMVZeeKPRWL81rdtiJ9xhnVary9qd/c7ufmuPNVrw T8snqtVqz5Bp99h/2QGS6bH2zn7H3O/1BZmNn35ijd2duslq8LnHfvppg/3gB8507nL2JqPm WTyd8Lg5OWTbW8wLY5ak8dxJmR1HTjhjW9sLaNs3se/eckDYYBu1CoqRCc80SQx+WX4QzdM6 fQ3nKXxnURymYfoU8QTpLxMxkYr1YOOyNmobsLINxrbYR87uOI+YDQT8BzvlDEB8+2bKaS7Y B0v82Xxqpyiv1J/xOruB6R45c8L51CUiMPcNoDyxecIZsI5/9pMUBR0GnOmvk9BLU9+5S14z P2DI+DseB/RhIUXYQdMxiLm9LnG3192tt03ir8bgHwiIdqzrkpOzm7nHtozoLjXYQALdxNy+ w18bNc2xYSUnF9b40hpdmdboYh8GBSVzHSkmwRSt2jKtyw9jRUx/CH3XyIVQQbPOLj6cnanP Vh0wNa04hJ9GNm+cWvMg5h7TAbdxCKTDKG3GoRXG+BnTdheXyIpL/OfJz9bpxxO2r1gHtF7h 4Nnl0cnwxGB/wQNUpQQs9yZ0QWjBNLRd7pKwhSayWejOp7zJTuIwYrAU1ClSfrNb7/ZB/ftm fbdFAgJ6NE+QMp8dsBYwEaiDfgQcaPqgDy67J2UK+COzp9PQIWUiPSVUyTQ3sLxp+Gjdz/mc s637OtuKwFPADjP6ifVgwhyj9ySJ07PLj9boRAcZoNSZ2i57pXtJ49Cb2reJ5SVsE1nz7ui3 ocA4P3r/i8EMYMM90ELI+P6/W/9CzcF/fAq8/GujQebmxwmI0A2JNzM7uUOthnU3NN9tHLpJ avkR2xRUaPEI05TjAwkG7qYSTI6jQFfNVccfAZvYyYTYlU0bhXFaPTE9GUhQnKIaNHuiQMmB LMOJYQVEPC1J2Q2Df6TMsWOw/BswA1iwn5DhE5sACHdQF1vw5oFDjkSwEAjpTM85aYCoWp89 +McM9idAkJEVIdjhIfjkdXCSqW/esPYLwJCcyaoBS6wW9P7MkXF0AViwykB5ohqStqK9CXs9 uro6+52UT9/MN2TW2WaV8pjGYAWeWPkynhzP8IS44KnvmstiVU+EiyN4lEaB1WbTsuamZbtu nH/rdsBScnYZf6I/ewlWu4TFXorW+a7JugtYL8UDJ7CgX9+ywWXcb9jm90/crcTNsaVerN5y 2VRKM6/HbVfgspcid/7GxN1K3G/cslnN7Bdt2Vwh5Rdt+bsm7lbiEvbL/JSClE6qMKJcAXmO r+r8y53Is6dcDvr8SVd0NmtcP67tWb+fA612+kswlR7/u9lILMOzEfbjsx9lNGEl/n84nZl0 rgcQ9DzVWeJAaIxnuzOPYw7hzBSiZAqMbDjuU0ee8Am3Y2fCE8hTkAI+1zEOOhDxYiFm8SFm gd8DJoI6CqUI2UpSHgGBgTyd6DTKeXlwwO4htnSVBDc3lVTUqSWGaGx0YVpH10Pr6OTk2hr+ +uHorHx8bRZJoXo+i6kOMImpzq0CZkkUpdWKWKYEmAUyGWAe9JQAhcgyKBnvlEBkeKNAxM9F EHmkFqCk/SCYjMpF4jeH0BeTsQJ7Xyn+svUCYdqiUZW2twS0nl3spexiz7OLrWcXxtWVXBCq SN4FGRH5Ebf458iHwBG4ARQm3HaRGOq5HHoviZ/W2qTkipNA9yIURtNkxxPu3CFNzEkp+ySi aGlgZfETiSATwHfNKzImQQ2iW9+dcsprgjDFlNYOnhhQiepqbj8VtqxVpzbh1LXQju8pW8W8 aq/dr0Natdfvwh/MqtRy79XKYBm47UBuuy7SKxCJzKhgQZRgZVsW6Y0Dkki5mBiyojrzDYrl ifQrSRpkQxIE+C34VB69PEZL+ir+xDydx4FY/1faQLvVbeEO2q1dU27hL6xyeGx0dfqxU5no JRzY5CXgpURm7oEZBQkkB84Mp40hA20c4vea/G47qRUiQq0S4eh4PLq8sK7G1zrCl5NCAGkc hpETuhxZegn58M+oq0T/gJ1aZ8MLBAIssZ+9PdpPe2enKBJw25j/JNHUn0W6MSgkv4mFujUo 7rp6Y96jDf67sLvCwMu3mCH9vX22+32suLQ73W69LTYK0FR9ADmBE1ELhq8D9USlgfSAfsgF f80N3PVjXECpcCKyoWJpA/5bcMKpObAKF9mxHEZFnPGZEz3pbHO5ImJADqSX8eQ4emI8g0Ov 8rlBnunTp0/CNRQJi6JBxYrUg8ECgj8zwyp4Ob4E7kVRJbgYXwIPqqEDBYycrtiiLBZJQ14J AAqUWjH3nCDFaKG2WrpF6yfnUfabVE1RQ1gwktrV6VM9r93tdZQVUfXT5RAWUcnq9Ho4tK5+ GaN4De0vTfsDY6DMUVDtKRA02QCf1rS8SMaCqhoZK8qX6JUx4lDBCYpMm1lezPlMD0jpZwYM 0zhOSip8Mfw01gOChwe0tb0uuexOq6UcRJLaqe8wLApuUPE6ANv1U1ElRH9I7iCKwVt4+uuT D+fnv18MxwxhfHsK6uoyvdUGT9o2/gheG9KkluAf/XQC/gWiiDJmD3B7EpPkBCcDuSSUJR1u hXHlgBefwXHhPll4mDUpiD0ojvApn8H5IgtAG6Pn+w2T/59+w2Rlv6Hdanaae6V2gxhi5WU/ 122YaO0uO7efRLehtbffbe+3zKzbIKd5rtlAVPJmw95+r73f3ik0G+AYIvtp7RUOodw6UCqW PPEhvcIgBcQF2QZW4e04hvWFHnuNknxNkYEv2gPgpwei1eCBJTLrl+H1xfAsawqUzc93AdP3 ENVmke3ccQp6ML5SG2EUX1BngAhAjGRPkxD7ARSjpPatxEzgb4KjN/CTHk1EyyGcJ8zl2DYQ 1WGx/e5OHTgE/sNUh1PBdeTVbq27+GA4fmedDM8/fNJ6VY/gLNJ2YP+lB6JToJlV44jQV+cs MOaOA2up6E8tjAEFiI9Yq8UNEdtgP3PRRXH51H/g8ZO2UPH2PeTdFvh+gQ+GzmPPdoCTotEj +wraImISOndYGAD/wrbkMT0oQcSAyeFTEKZfC0Sb7PzD+zE7vrz6PSOPcYzw/ujoMHrHHwuI TCfn89ZAtFphTkzjYDF2DPjCK5NGoh/2I8CAAZSsJrbzFfzbDzwAS0RnLVWQlDPTw0tgGmiz pD+HwBq0OdM5nRzhx9POrzVjf40z8h47/8d9T5pxpQsywTW0yy5IDLFssSu8Dz3UOt1ym7O7 v9PPHI8kvsLxCAKlBqe53+3v77QLPqdvosuBzxUNTuwkJtyhbqUQ4LquZeUTZyafvaB/iuqD +gdmO7we/341BHuUapLjzmxnAsjbfmA5d8l8JtulClcNqzZWp9urAxdqHTjD27u0TXFeYzwN 1mqhVZYGojSWJyXp9CQM79BawlwdM81tgOaOsQkCi4oxXYsSdMeQskchWbhAtNnUfuJxFzNH FwbVQ1BxbOOyMdjWFjvrvju5LtB46H0PlUvkp1hPwv49T7BhAx8YmLAtQQjdlh1Blg/xBmaT iF2O1jRaiz7GtrPBdH3Mtgxdn4MPSrsd5Jih44Mawz8Yl1mTqWFkzlQbH1/phCjdRepEEzdG tKgI9uGkDDZ3K8FGx+dlOFQqBcWyYMyC5U3RlcMqNxoIgxuzKIfOMCOUdj3Ptqx5t0MZF8y3 AoUmw89qNGogojclIRwIMRaR64JH8M1CEArlc3AcLz3FnEwm3TrBvDlgyAHr/OgT2gTWLUTq 52J9G36037xBQMPAIqVM0js7LTDqWmcHtL6VhRN6G8udRG38fnx0fmWwL8XB0fXw14Uh7EbR aJHVgsOJRcuGgCB+KjMYmVn5NOPlS/jGvo1xtZcwbjyu4hj7YR5gdDQeE/O6nV3kWq3bVZ7x 6+LmQaPhjEue0S6lWZXQyijg7zIKVaJwt4A3xabqjS+CcSz0LhNY5J94hJqHifzcciY2ABKc rn4ZOiLWWFuUiWCuz/gYBhuH6cQK4cwCJegYDA4okWCXiBuqoNXrUeDa2zHru21xkUOKoS2Y u1EDV4m+iUKDJOIOhJgOFXoScGYxbzab+BxCjCpTJrs0c8MEpyO1YIUdY+GhShHMKhNCgO1u RxkSIfzY7aBqUM3/K1YiC5KvYTpl+q6UJcVRWOWnNKtqQUyuiApHqMNU5vcPWgPm48pEFacJ oVR7wGo1n1Fxmeo7iiym3nK5/r/E8wKLs8221HLxysc8okIvToZB7ZZ1PmSiVpQUOU1bkq0E vN1CoSaFXEqnAzFI4hNf5YbKke3MdQbFQYEDo53iMBBTjzx3tvCExp0w8m3RPRofjc5+tU4v r4dHx+90IFVnmzQbsNmzQD/uiBXET5wItBf+gE/wiBT2XJrp/cSi6xYDptZCdZIcvoMItiWh OWz+cyqKV0IKr3IYuXl4oDkhJErBnJySgCuDNQ4T2/LsmQ8JGkjv6BTSjeHYVIQ12D0aWwVf jGydOAswA8sz7gxIC8qQrEteSSAsFWOBGPkw5TbFoAlgcguOfJm9YRYhxbgtsJCIA+Axgeqb NJUhSeJ+Kno6SgFADgJcMqOkjJr2FT+/VuhlUecg3ve9JwuCZSuy04m5rG8Q1NaX06dM+YhU MQUCszMxDcqVqpA7mZA8YVUT9UpUOvVKIGZs6qJoBFCGgJcXjZYZAjRwjZsACvJWKwe/IcV8 8x8eh7qLd32kB8VFGILLOZJSk0xLFp6D/8c6dIHCAgDx64A4Rk/ilDoFln8bZDGTyBK3jM04 rLPr8al1fHZ5Mbr4GU57/HV1LX/LPqfYtZ7Vz7LWxBeIDkAMxQF1RU4BU6kRYMgSfUzWsP1Q GhCaU9CPogoVdaV8EuDNIktUF3KFQY8rG3PYv5AKkger5HR97FQLj+o+BdbNXFQoGnT6ZbP7 BQ8K6Q6G1jKdzRxnHgfQDGYPZghCPMssJ5xjQE5Zg/wu02lY4TS81ZFhcNYZgg6eneYOdoFq fSx+9FQrpbx2pq5PFTvofxYb3dlP1QdcbmcLFlRdp2Nvlfhedh/oz5eDt78NvPNt4N0q8Ord q4Gsfcv2l+f5LqbSfYA1msUKmiUj835/F0W+a/brWQ+GuvGoJUjhoVhp126xF+uGASe1wi5k oc2KIi3YhE7VqEzYxSdYcl91xyCfWd0zeKUqxaolKvsACCTCb2o3jc5HY+sKfOLFWHZTSe1p 3WLheJiK/kB/d5cuU/f79Y7Yt0bXKYg09SKe6UIXp3+1OL10uCxrWiwoOm6/eKhXXVgQq1B3 FMT1XW1TL19dUHcXVl57EFTUHYkFKmq4RCWbdu3Vhhx0Tf8/Cy+oI8fOj8bH7zCA+nh0fSKP durXF87p72NH5Ua+mR2VTF3BjoUrIevYkSFXsuN6+Nvw+v2wkh25DmWXo5hWUNG19zPKS1p5 1+OlMqc72K0OGs1eW7XUVm6GFTbDlGyZauWRqaEt4lVxDc0fryQIw9wDf9TeoXb+Xr2zI6aR ycqybzIobV/jeLQ1t7eFE6ppK72TcE/P+aT7A+AWhemZdJ7zTRnj8aAW7MZvSyJZ5YMai3Kr 1oLG/7oWNF5m+UrTX+IkCgakCyMo3QSDJy92B6stWXu5N1h2KjKoxJW9WljaMwIoAFWz38j2 Lr7J803Dlra80XNA775YCYccD69soGIlE+Ac5IgepxaQQDkZ/lNXLVvU1302DcO7eUR6G9l0 8U8c1q3PP0Z/BK/r98ZA6KwKC+7VFZSdDlWp2+1+t96RVZSKCfwgwdgeUzyYpDH1Z35KOs1+ dHECdVhStQDWH1gEQtOS3WZqCCaWMU6WlbSilmTP5S8K0kVGw/ByX5bSQAwpIyEts5gDhp0h CLgsNTSQ84Ot0orosii+rvH7hfX++pi0xCBtLy6rQEWMDVYSOXk/LhPJ9lkgIsYGqsBSdk+w LT2HNUrxwpo1i4Q5M4GqVZuD1YTydStC0gyqVi4IFS7ufuPqqln6zWtbydQsoKtc0dXl9Vi6 7JJqLSwJRwcrCeGaBCFx62Rvr97ugOH0Ov36rnyNbAvLM8l8BhkbtWhFI/uGOza+teZjS2Q6 TVgCKZ4V839zJ9WNpkDENhJ1dOB4wp61M7GDWw7Kjm0TW2abzuRON+A8fcBOS+hSw1ygh1jA Kkx9M/c8HjfxRiTWzzQgnPizSHbtpz5Mgu0baoxP59T0nNXpvqFPbeU7HqWErNHrdIEjroTA Q72wMz/RqN4nW/DgIoCvCChQERKEJtpGcqPb+dUb8QbbLBPErFBiFhVtLJSloavP8noM9l9E fIANXNxdCOL6IknAd23kydfeFMuIpTecB8R+WGpItSnZ/e+0pRx7O/hFCpJNpjzQxrAB+HsL O5fcGl099OSGpOAQkB222IzbQYL3Qyf2A72hSKCCUWrrDZFhE3FybVREW0NBvRdXW0Qsc8Dz Ep7SasVXXK3NvNi+xbs0TTX6Cu/UiFlQp4SQsvkyeGarN6xyYgvbIUz5+KBMFas0At1PFvDo rljVjPgSX5QRr30L8Yw0ExonHqGoqPrKwDDCANQ+Y0amhXNxuKpdElflhZBWfQ8D016/V2/v SePOyoSi6iV8WJ1JJ0SCvLgcD/fBPNPHML7DCszMTjU5F0ivbWJhJcKy2kFLtT5AwPB7IFtS eIAXw+wPF79cXH68oMcqMKVTd+tetYpFnQbrwGBBlrxOzs6t97+MrqzT0fXw45G4fptXvXCt tuOAiQtOKD1aMbu4cyK6JvPAwavQ3K0LFE1AXlxeDAWYfJxdXaZuBd4dUws2BKZWyhFRTKXE goXYTn70wW0WLxFLM4LdCL6hg8Btw6+JGzcVJ4Ebwh/wSXbr+ssXkhG1sllXeTAySk1fpMIO DxZ6T/T6CIXFGOYEaThJsjngP66WsgADJyzeIzBEYCAt149k15paXKqzuFLstXViJ8GRgz8O wa/BIiH2s2c85XEiGu54a3uavW2dUFHQs5OUGvUpXme4FeaG72gnaYjXygM2n9K72rLLL/v2 4Obhh+AeBVZOOM0cIZEYiYo/3R+gl4WVMXI7eUIyLq5shjVVLw5nBCwI1AUBfOdblC0h8AYn MfNvJ6lwFfgiMQO78/F2j60mTlSXYea77pTLdeDyYVYSOmhCVrnKnTDqh5AHGD1EW6gXbkiQ t7F9gxPFPEkkw4IwaPj0hnIi1WVVrClcOhCb2Wj/og0C56svq2aiNGV7wAbwGRaZCl5Np6RZ XJTAxas7IEipku1SNE314kfxAlQubDo2ZFJMj2QsnfsiyGStiUvj4oUH6vU+gCaFooAMADyg K0Xy6ofnT2Fi+YJyTVuoVpfnlqX89W6pttIt1daYeO07RSCZNRK3DZ/EqtWlQfRYsL8p8Dzf SVOyURRiVngG08K2tEwD9VeZ6/nyZZ2jODgouonfsreTqiIechpUnzWL76jkkm2rFyoKDKHm kry0YKrnk1JTZ2ELCkixcmkpBCbXY1rB53RQfF8GlfAR++poTY94AmM8SQcee/v2LZuEj/IJ HriSn2+Lry9hv15Uj7bYFRjBhytTp1sIcNKODRDqHShXMqdXbyAaQPya2gs895McnRqlt/Nw nvxPdd/e1caV7Pu35lNsM8tYAiH0QoAwziVGjrmxgWNwZuZmsrQa1IBiIclqyZibeD77red+ tLolxZ6TOTdrxbZ6v1+1q2pX/Uoc3IF3JWPkMdIiOkLM6FimaQ2qQ/gIVwfRFuBSKwYuKXyk ajNfL6SRCRSw90idUD6O+XC7CugWM+PZYDAbJ6YoqBbMwItIQFTyIXosVWyxbWcdOj8JpLkg G/UCzOVvBe+3mleSOQWUKPmTcxBmw0e2+xIeLJzE5+ZzieuiHAVhyHEL4P9dHgFuhc9iuG5f n5mIuk5Q9UTouFD3JuoD0x02/yXdbTIQ0e0mZiJo5oWjcC1+ge0FlZliteTvuwsyI5ijViRH 0R7MoqKJ89mSSon2Wk8o8u8AWQbtPqiMfKOr7eT8/N0Zmu2+fAsnt62j0NW6o+WC+tzRQVMS e8bSJ1W9IQJDMz1rUI1YI7WsOZJD5+ADGPbq8uX5Cl2y1jSS09PAoBkdNzu96/ZYLpZcnvgc 5EqCXBljC3KrP8+Sgbw/XmUgbL2XORA09ONGZwsGEuQKB5Lbtddn52fnlxerLD2u5NWd659c u78Dn/j3S63IphKB3syk0H4lSqKLqRxuw4xbd0KhuYTHWiwd3buz95dI7lYb3WQazH84Pqlq hfGlqskcIeXxxzj56jG+enf0w9vO6eWKg0QBMm+MWlXOIE0xt57MQWIWf4w3wRitvFrLGrbe w8h6T+ESnExQMPhOzG8WTsjR6/bcNxTs5r92Ls5XnDV8LDnwLx370OFaZS1fOKNHr91UW3fe dFHoRlZZ+Dy3EMH8QnZ/emO6AjdFh4+kYX7VgnFkLtpcpX9gX8JlH80G07ZrgHXv5OHZNsgd mi3zfvhhOHoYmo69514zV1582iuREp6uX76sbDuWvcadAYzvY8ZWwJt1e0NuO3stfiHVwgJO W4RZUo5bPa98JJOgrYJT+vNnsoVKSehPAu9jvqXrji1H1J9EdHbmAR9KbA/nFd7LmVaxVUoV d7rvJcXZmCu7dZWwMuvOSXS+/iIrLGkf85cCrpu2OKn24MyrNxTK2lTaKt8S0iWT5R1SBthJ bh6dWnHT4XMslnn+sLgzpxdZSdxpOnCj1TTDm+GQ5vUtC4Sk5kGmIPKt2hXl6VPClTs9m5Yh mTtBm5ajmTtFDm/gm06SKVhdqyyfNAJfEcIExPWzV6/QGp/fRsZiFhjkRTadFBkhtItvzGAb cdUvqN3Vy/oRT+EneZ47AVK+tJ0y9S9boQDVvTwjUUKlji1fePonv9ylJSKWPcxvmsFtnCy5 SCUVlzclHXFCIVMy8grl7mzN9cX1ORCHhGRv6lP8ypOl+mNP4+4OXUaCyZCLTJYEIrpSstvI cB2gZYIUt0J3gTwfiim0vQqFfJcDQz4HmMfj/9WnQFh/6ojj+zU1cakZgovmEpllyxowrSZa FZbLVYXlQlVhRYnKeNY4c6tC4lTWqqj/E/y94qqIzCUzDr/Sq8IZslcF0nyBLLUqmuqtyrL5 9iXAwnLxr7BE9ls4iSjyt7OnqFki1SN7iBA6BuoUWc07u6+IEjhrKVfyQWL/35jfswgNEW+c prl6nMZJ22u2bNtUq/vFiolS7hYjDzingFBPsdT8WPbVBLZgQLXFvcnOlOi6HXeZxUPhzTIo 8s9KwqbtB2FeeyFyXv6Zk9dbbO+ffH15JrVz9UtG759cxpo+LeIDs8eQzxpmj8MZxCulFUTM ++iRH0aoZ8PZ/RVwJWV5woHb/T6TR1bOQwxjMnu/wkxljmKl2aI1T71/tMXUj+sjsBlFQyKj og1zzk91+IofDQgqgl/zp9HtbdyrmDfoKKtIwmieR2+V/Ja706ixd//uzl65VlO7ZznTZ90f To7b/u/3+HuLvVv4b34c4zNHKFD+y/T6urBzyH+XbQE04UC1Lohps0ksT9cp0wCbWV4iyb6C tcuTKXKYN6OK5mG64d3STw6rJecx4z3vlwTAidYA6zDRJ+AyCGxZPXB821NFEcVnhJLqDmA8 V6i9/wyyxCBCfpb5xFRRxl2VWcH556noo7HFgMULNTgUWzf7hj6+vqLObYz7YtOGeuuH/qAH dK0n7/CtOvko1Paae54Vqk94dNVQ/yLLxp56h/LA94LXyJ8g6bzm85IO8hs4OW3jcNdGs+ka DnCNUbnW1Nm7tlsl4/rafqPh+qqFz9F4CG2HeKvJzi44042MzUQPp8PR7PbObhRIuZ2BDDKc xnH2ltpcntO27G87u1sqmizrTUwxderw0OMiUNRLfQVmRCyjduti17u/01C73mA64E5BGVAm wy5Y1lS4+rGU2qUyZxo6TaMtRjHlBFlCt0yjK55RyF5vy8r6yhp/HC0eSLCj9FHO7TsZkutG xth+agU5Uq6nYi9bWOmBQM1bM4e0aJOjInrRMer7zsQ44cEcZRXxBuSXzRJwXG0LOvhT592i DpL1KTq04pSLCPlpef8KQbl8hcTivuHNwQeAXeBr+xbAv+CJhHPgaSfnbzqnYp1b+GxltgNX zKpjMspeXrJxjy1LXZ1OBzJq+po7JMoXtoNv54jecIUs78mxvXyookDoJ0z0zVRablN9u/e8 mRAjjJq1hnarFKzJZy2rc88T3dotN/cJH6tebu7OUxo4X52XnePO6cs5auNvAktTwkZ1nNNR QlCucbUUUpNU9vxZTlWwYBNdnl2s1FOGiuPTBL0oG9fXkt/FuXyLOlla1Dcg8K/eHP1wkT5/ c1p5yJhB+3J7LrsrB0XAybal9DleseH8qZiXn5eMnx/8vm34ISKDEtFvHVtYqw6M6148povO f33lkL6mw/b8FzMvJ4EWOTxcYVMk8UdLfkKlSfxx8ZCPXv74/+eQgWPLHjIkLB7y3zA6ybdt XJ/WrdDXh/7wWzd1QF2D8ULlC8bbubg8+t6y2oYN7a0W/OGuD70hZvjiH6cs2Cm7K/JPcodh ZzCuCALMOfnm8nUX9g4/pn7bZBaXkjvj5TZFaPndxaX5XbtA/4Duw30CwoL8+xunu5hBEI2X vlovFqzLm7MfhEPaqzfLe3hvI0rQvFAOXN67zk/nR5ev3Sqezaa3IzQ8tK8Zs+noHv3hCYsQ Ef+2LcJ5uDhF9BB4EsAGBHJHKtUdWN/ucHL9CfIdpmthX27h+L+TszkHMeH791TSrmyFuWZK pu16kaqsqIbn86XmKD3PdbOKrpz1KmKuVS07ur3hmVgr4rM9CLYKX945b6E3Ta60I8PJcr+b H70OHke47lNGfIRVyohasNZCEQy6BKL1N3ZJYeb/UJcyZoYgq9oZapXffDEoqHUaE8DCfFMe C5fGJxnneXq5In48F9gq69MYNkuUfGj5rKFOV9bsYAEaKhRW9bBo4RctxH9mBpyL2n94BmgP BOqAQBuQgXaUdTRW2PDf0oof+yenFfRLbKE4u/hYhYBUGTYNlsLNcT7CmOb2gAzjjt8t6QER X7H9Wff5K22B2YclE5rdSLqMcXo7wl5EG2by0xUPKUVqmcTjSZwQgvGziAJRJc/KWqxfiSuk M2VHiGiANgXirUX+HaPhdey5DgoKdLVOKNC1fd8bn/DP1W8k7bET8J3oM+I5CGND/o4ou6xm XWosZ3MP3y1g/MgmpM3Xo8IzWS7VJbAU7wwV5IOqRHGWXpHrMvQkuu9fc7CBspmNewgZiRA4 gtu732JwbIQadNMSqC590dnNh1WyBrpFuNEdwxWCCMLISsGmS6VbNSJnsy09CZ0fim+73788 urj8/W33Lf6dzn1y2n37/s3lCaYVsx6ESm6+fBdSXMqy45bLjMPYrDXp3t+tNhWJMYNDzua4 7OG46Lx01n9zRC6bKGUcYf+wKXKCaH+eYLyAk9OL0+7Fyf/puCOsW4XsJa6iHsW7CZ4eGW2y TqEF6nv1msWQcF7unZPTn47eKDCFSdGADL4mi6/I72zqXipt1mTjpzq9md1wQGZXmBKknSW1 UyzkiZOM6PeHOjLHv+Te6oJIJh1dR8Xd778b+fnC1Oq7KzScfjEOkQZEvfm0B2deDB75k8IM iLqWP0qIifruPoYE2Ww4FPMCLInQOoavRfTJ/hBR07jxrgtsUSDc4q6fgDTTK3ZAlpCun3Uf GL9seoi9PTVP4RyukXeSn7O4yUxQfgkY1RrF5riKEgbUe4gmPZR24iE+3WF+7hs+7WCZwej2 FtNxSgRh/eT8+ATO8SXVJuUgeTFo9Z8Inn+EAVptu/no+ZV6pRmC5+MXYzu8ALj6rlDbNf97 NhDE/Fa72mg3XHxernoBbvUcVj6UrwZY+fUWAbTi3w3rLI43jlDLMnt0R4hODgyCuevjm/wj w5HDzrCHrWyC/9D1jb0O6UUOg1wS9gC92fqEtxwWun/0vBXTmeHYlvNasBFANd0rDGe+7P/A ZsPfWDN9ERo2PxoyhsRX4H6PoPn71ju05ZzavUe0cqo8PWfpIyXZZ6Z8D+0Nk9G2zWndSec8 Gd1wy0SSzrpv4Nrtnp2/PDvuFBTyLFLi88QCyjMA96YwgXP1klkOtU9AA+h5Ti/jyBMCbzdL sFsRelqKoyVVRSsSkYqaHS8j1FGpd61Yjyoste9xUKh+roUp4k8CCfUwQRwxIKEZJhy9LsDH vfBj5+Icv9aqjEpIWPmX8f0Y7QEE75yvP+RwK5jMURksC67GyBR8bjAI8osSbhJ/nKEV6nAE sxxPomEvEealtcO3+m65LiGaHTQhkL7uIL6ZCkj6A+zi4aPBL4aMcm8NL5UnacLHA4YDNkdj BMGgPUG7fzTkHxajVA1HPQmSoEcxtxhyUkAC+gr3bW4ASETno0L5eQ7MSpXVVqistmpl9RUq q69aWWOFyhq/HAiy5YWNsWDPJc44nm68wFyIB18Z8Js6wdOuGmVB95KcnpVAEj9Ca4ZaB+3P e8UtEcxipjkuwPmCjlHOjK7NdJf2ft79Jd0yFjrwAqO/RldZtcwgtFw7QVaMJHIxpFpIROSj xmDhCDyz2Wjto7mFOyTo2l3w8Wzo6x58VEAk94WtRvEgqVvkloXJZrGFwUcke8Fay5M3SZMe nD81y6bF/2qVTe2QbP7V48iW7I6jXtYSqfJGsEsHPVa6syXb26OXtLhPuLJ0WQ/kyJEH/s/F Hmaa7TD954BIKTaqqPYskBtGWrTrdCyiaLgIbPnT2GtwNPm6roJt6bz76m8EGdS97GBc8COk vXXiJbIyHXdO/6G5mpwL0WhxyAU/7IkPgT1uoQoYn/7MhotnlgFOrKG8NPhKmBPruZfQKWbD CysWoiBveBHEfFMuKKLBwr74+/tocjvjYE543q8FP8xDMkLzWA1u0e2PiqUK2tqNKcJ3fE91 8NVBUSjc6VBEJfWdFtCiOEr6eAVDrfewfRgknpEMm61qOQXk4sP3oh6EtiDiP1zhrYUIFSfn cgenQFwKzLyTnEClhJm/Ho0+9OOClxt3JAqjn6IBi1zzYWwKGjSNHbRkNtjZR4LhBJxHPj8v MXf+3Dg02mguP7+/j1x3LeDo5ZvxO53D1ms6cuYX8Vg4+532Tr3ddCFptJEc3t5WUvfC2rTa O7U2sPmOu9/fp7A0+Jcy9yjzijvODF0+NMoLmlDcsdeLVS58oWBXpkbcIzDgFyenP5Kn3Yb5 HoE1GtVKpdZCbR+TVvLHYcBm67eFeh0EoEAEMEzYqkkNHvgJQqDHFr+LWWTG7iKcA0WINwxg XeEKyPYTfW7guubmKUqxC1JM2w+unUH/WjvFhcTCFMV7D+2WolSWsb8OpM/T1Qu2F7R/4NBN CWTzQOo6wIfIrS19GwgjXuIXQopBJxsY76PgdcKsv+0en51e/u3o5FLyQanPxUR+xJMJxTIs cmlVM35nOqdn379/dWHanup4Q6HBeX+UEF+8bLCkNaFLYbWbjRKhqk9GGOKvK2bNPEfcNNmY WhwEz1wWZ4oDIFpPHRext6g6QrwPGBIJIdHJ6C7yMTb7EeHx92+iCvZbH0PR1RjqP8jLRy4C mmsjA0/F9emLhszyt7EAkNOnd/H1aNJjMPIERPpEbK/7iQsupqJmRdSxqw2SLbZbhNdc29lv lutNPYXqcZTALbX1Av/swp3MpuLu6fgEfQzQJ5/PYXAM4QzdwlTBQkLhIucsqeDFIHjR1QgY MTwOVnqJcHQDuCWSNtexSaJbvUFYItvsTnkVAwfXH80mmB3uqf7wgynejmLxE8QCtR0ubggs B27L/vC6Av8rW6Q1J6Zer1T2iDbg6Q4PZJGqam5VM2phcDUkDo8S+A6t4ckzAD6C4BYL0lrC gE6EhTcxqGFja3UuTwiEwx7C5BEniK/rDKwk1uN6wpIRzCO21h/SqpTNOvwJE+m/o4ontSSE P/2YD1RpKcc8nbOjHv8zuiTKWyLwMnh4w0kwh17jtuALs+fROckhiYfmX/wvfeIjK0h7BlJH ICjoOkDWc+nX95yLehI9oEr/T7yltcX8aHFNjOi2F4aL42/GdjfrftbEAlxr/uXcbLR3XKBK rT7rcnY1pBRve2HAuAYpBBo7foRXLzjbGhIEChxXuVvzwsHxd+D08HM6O0eYm/uOeojRfZdM Vik5byVnvXF3lkwm8cc/czX9Vpes6H7Giu6boNtZq+pnKOy7hcVl2W/X66mFzY4EGFSSYrvq 7dq+v7b7JELhX7ALmODr+8GBxv8D7uQVKuhIy8rK1Gwif3IjBBdv1jR5QBhUZJaIYseOXHNR Ekf6CbqgBGCUigCWSXGQruzBUIh62W4bUSBKqFT4VOageFo/h2/PIzOKyPhyNExzIAwrCb9n E++e5ewX0xmsd5jEo4qmEYg29wTvlwDZV3xYDsZIh2t3t27nv+hHFivN+s6OeZ7sFVyca4Oe oMgYVPBvy54g27NkvRJT3ao1M641uglpzVjgg6FHclVFqdsRB4p2YOwAJwpnhn4C+kSNEFId sSErruwu3BgcF4uLIcbIktyINFBrHeSurV6gVi5BrtZWKVI4RpzSTxJZVXpA8JnEgEvyvS0C v0r5Nw/G1Gx15W3pT6RYqXZzaRYSk92AYtEXE/Y6g2ClGijUbexRuoxqtXZjx9IsbiWDYqVr SV1IdZAVA6JVpffGqr2QzMX7l6/N8dHbox86Fb2httJXTouvohVvKIrfvJZ7z+VdaKT32Gly cLym6j0KgnJxetx91zk+edd5eYksyxcvSDPhzeh5Jo4eA3wl1iGQ0JNBOmXKJd4iT6hUim6R zax9Z7rpT+IHIIQYb48fzKiLbMDRbNknW4l75sVxwZjpyGRyT7f0UHlNvYo+xBx2rOeewirm dDQVchF/AqEYg7ZtMWCHkMfRREBvOSA07sFrxMYGehGhNQtL16NJ/5bCRcNeHeK7NBFxlNKJ zCw8anAc/1R1TNBq/vsqvoKCOBK8sPI34/c696BJhsXHTFvJPWhaS+qYQS0B39dCjm+z5fi+ wv8q/rWEvJmU36vUTfH7ePIhHsSPJVPbbm7vN//zx69W2yd/0Nq+goo7jS8wMB5XYxxbYyxf Yw9jdtDjLvb3RU6ai/z+Qk5pToDllq1GIyzn5KO3gYTyilFxc4883HYaznz7L/zyygedghfz 4wGMZuiGw9Sc9L8cANn+Gk8nBy55OvCTpwNNHk41C1s4CAyau2o9avQXD0MJmRL9W02j662G WEiVdxou/MzwMzAbQCMk6qlJKcEl0DqForNQzKk1o3rwjmYl4YGmF6yNhv9iIdpkcogWLN7w PVtewTnfNvr0svO05R99TT7ODb0T4B8o1OLfFQTCtvhj9AXN3lOfxO4l+OapujM6pz0MFODM VlHpIVlnjjzwM0bg/QFhlmkQpGh/e9m9PPqBlIYJvpWPYVSsD2UH86g/rIiFAusQzT1qjUiP pS82XMcBA/NgghdPk7VHaI3XhQLRLTojcoqPvOaZ7Qh9apvZcAL3z+2wj8og6SaaM0jUk02x 33fV5hhZodNRh4p3j9+/ffuP045Yl/kTb7nu3rBLNhIlxCOiV4bltdK+8uoMFw5D15ZoWlDp d3/XRYkgpRNx1SOnXsVv22zlwHZMnlkScgYg3TxiDAhPtdSXx3RRFqX7CKeD1X5eN70dkhEY E6cg1emwr3b/k202R9L68ejiAuaieG9DN2HY3RQO9fmPl6+P35UEuAGrDNZ9ODKQvFbyInHa lUIYDm/ra3B2xaaw1h+zRDXoi4HlaEQBLrPJAmZmhqg/viNvr02nqMVeWKq36dmD0UVjGSXx aiIrnOEQkXA1PAmFDun3qNPRDB8Rpv3r70Tvwmxk1UEweKI5M4/cpfYc+wc9e4jNQzQkwwyM DPrATKVa9RBXCZfLNfJsgs9OIi/2hbCRKccVCu4E5M7yamN3h59cgW6LYevKfOccoYa5dpfJ +joldN+cHR13joVEEBScSKoP8bNPMaOPyGnQt0JiFvm5DrvPmNNSMPkAYrTfH9Q6sPU4RnWy DzT62hIcDNaK4n10WLPontc6wYqxr0CfWg1VQaTQxj3jq0GuWjYA532lEVgq9weuD0AxRFOf fp4mk897DymZTsFkNFYVMQGfiTIXjhxw8Pfw+8CLHn2gB3bp0cC6ieXuDzmowL1Exul5r1N9 CxqRIinaRT6p16P7+5FUI11lNLYoSWxoJqXOsgeIdKRn4h+nlzITTyxYGr+WxMOet7txyUGe gKmZ9NFsatwf25aRURt2+yNaDFQAWGJcNsen3Us2tjs5LRtvpVLTlzb8tNPxRKZjQc8Pw54f 8wWODzlx7AXHIECtgD/pH/gbMngxWrYeNozH/NTbQ8ZE4xbxfoAelf04SgpLgHsNpD3vXTO1 y9wsQdewibYwwo5BVHUSHNpBz51LEmI58KDPZBL2hc+piiG+hpBxocr4iezkhm1FkugxEd6o 7Ax9RqIJxCPjZpqNSegBurm3kykR67iM90iXZnlTpDC6jdDwzioDk/FoBGLI7TYSjBkpjioL hdg/3aggbDZfjG3Ma7jlmwn6nSvHWqOAljkdfbLa6eauNQoouGZy5VjfPiEQZFvtxu4qgqyt YK/SCCXZeu1/hihbJTUN/iXq4VBKxLzbH+JHEg+/Taz9FE3y5do/JvMSxcczjuebZou68VWC MK54d5T04rEnArf26Zl612K8zFldbUyAut9PZ05OJLkQbjY0dLAEg2TOOO6xwTjbUlhxkbmU XOFOO5xi+YIqp7NhSpKFj+PRoH/9aDYSJ5qxtzCJxOhp1lKReBnzuvqa54miWXLnvOT4bfLo 18udgdhJt9p9NVPwrOI8VXNEz+ofkD2ZJKwofFa/Rfrka7ew4V+zDx7OHkPsEXK0eiqi1pPL COeOhNkvgzHD2RyJQp3wfN5iLPGHYUWK/hAHcMqpeFCSa3sVAbkaSMhAvPKzwdRCesXZScKN ihzNOnK7C4uQ/aQpGTH2uW+NlrbiGVEWCnPxPTKLqGGmNnMzHi9vxllkkkXE8gJDl/+b9Qm0 2VfWJLAW4VWmFkFMsD0dwr9ThWD7uUR5QKLQPRCVQI/w5B4lnoUKBBMeXF97oPpPRxu9qicj ZYozqqCbBE46VyN9TSsjfMzvBUqJJHr4d+ojjJWXnCUcb8EIRYSbaDrqRy2XCH9N0RjNU2Tg G0p/2go0GYW0JkN8Md4e/dhBdx/0Or5DE72xRfKmEXuBkPAT+/6OS150JNL3VtlXdNdBNPoV k2UZartHXXwTAhFhHTYW3tYViudAH0tW6yH9b+tzWW8UC+on0DoKgoUhr5jnSOljSLwhFcBs 0p8+GrmMrRmdEwp4KMnIirIcnX2XID32G8CY/XcqQPDnk1AZoSoRI+JaTntcPbbK2TDwFUFm knRHhq8WyZX8tB56z0SRErlOB4qR+ZMNNAKZOwKdPchQeqxGHMLSrBUHqnrg7GVXU5wQ8HR2 K4hoEYrCQnSt1Hs21DgdCO5L0iHzIGx8CFPUlpxW8YL7fusFS5F0ewOpLxKzq0aY6DQKTM11 BGS1JMWLFnY/Q68zV90wfnDVaRW154dQyfNDofgh7wVVOGVEdntOBwGZyd6ZrPuVMSEtSW5p 9aQoUVPwy0dL4EK4DEAUcSrm/4NCsDUl/KBaoUpBaOzwsEohXQ8P08WhIMcmdMpACkopVths Ono/6lGU1Iic2qZkd4kQ/wb9jj2FIEbAI23ss6nVCbBKj/hO1OWBoD6kSxLVhGT5rXPinB9Y MU8G35PRgHYcXqWs5yX3Rb/Hs6G7ZCmYa6lM5/IqniLE73gQ4TVxw6DluA+knNoYqwYORtwb za6mvmE5awwX7a2UznCpolCtZDpHL192ODoW3xvIXq6uP/QN2FUpReeUNkgpLTcsUhG2FuoI F+3zUEvINtob1lSJjhoOTGVYcypMs8igtgCqD9mit4zRuslafTKiDeu5xMQJUVgtxVZouBNn wl5ZmGzsQUXzHQHVlnCFjjGnzUnqbqXXbBU97GkxtiZ+tFseGX7K8YguOBWj+fCKhPS4rZYV +IAKKwwcECF8UAW9eADt2ro5ukVEE0TW5XaOynqN4HCAT4K764mU2jYezyquNcLzI9zzWIzk 7+P76/FjkbWrLiNx+jyrEvAApPiSB5Dvslp2/dC4cHapPCIF4CUC/8rMwQw8XzrjzBxDzTDU e4NzqFThte7ZlgXaZd6d8/rls/eXIkf6Wub5cyZ61Na8IvXfojLNAFqTGLjOtpAYnz1GBK/W mg7yxeutYU8cz1CokGOgdHKjLzY+qhyRUlSYwqaDW3rr6nELWQf1jNNoxVRD3ymk488ROo1w 0Gv7nsWGR1eP7NnJRkdoQlQRP4cm+zm0dvcz0M2dTuXHo7cdk9Kp+AYVzvfhpxYSn6NjH9Fe vx533mR8ffXm/cXrtvO7wLndrVa9/iCLs3E/PrBI7l+Cfm75b5D+PKcgPhw5Pz0jzJ2z88vQ Xt6iqLcI8d3rA7X59fPxQ0dg19Mo9OKipE3Xm9x0gCYUXEu2M4U5GdLMqeFXmgBf8X7VH27j dU5/1P/bFe7p5haaZaZ8A8Q1QDtqNezpOgu1Hc96vNqu77bhH74lpu8VMF+6GWrU99pVX6O+ Q6rKHRXmluqFM3JMr8eplGgyjrb7VpM8Xyf6cLMWGDljwrIBATdORoNPjP3xN35ln1DIc06I jbwtMTATWx01m9ba+vLsx+7xO9gRRydvyvKbNon++Fvn5IfXSKmBFONv3Ntl+Td6Mp8c6y+L p3GhX0C6bSFKhvw8vrhkzAv6dfHuJf0S91L1Tk26n51fLrEDyc+/wOb9LUBnADlagaV+M2tw d0ePazAH1ErnzdE/zJcyJyHjoinnJ+cdm/BxFs9syn+977ynpE1MQs9cTeEhagpwO1uoIbJt 0Yg0FbZSkMoj/MIgH1haHWx5WJANc5FAJb1ibUzVfKEAFwzUhgHRxQuX3uka++yOUlPrPqya tO3aLlMoHej2Nn6nhJdnbxG4g5K4yxbr35a1i2inw+ZJFmQCnq4FV6jmkJVfPqP+fOHWcrMF HJsmnJ5hn2mLwzhnvZFci0zvIe+TtTKSwTi5joBPRdXHauVGEzs3Z+9ys9L1X6fn0T08OvtC pIEcfxFoDwp7iqrDhNwgkH8nRQWGkEHtukhM9i1ULntmiiPi/eECV7wV8m+8Np9GfeBHSTuP j25ppEoCEqd41WhDMzUbCcgznof+3SiZoovsxp3/woGdYf3aq+6bzmkGcqHZ4vCuaciDDdSv rQvwvIVHpQ5MJ1Hv5/rODsNt2AeFp8nTxKwJPtyowrhdr2hZvjNryJOvtc0aZEg8WyfJHIYa UAgigfzKysBgQSLraA/u49ZaxsP8goZSFdCqZlVBjzrsDCKRBJowVb0+qjzEted2gKxAmePS R4kZ9BP2A6mh9EEwAZviXz3ZJkSYcdRXyYfXqFgfbtYYmgAWmR6WMAHI+xDFnwepwfqnqO+2 74EJDaKY04+d44m+KnEj+Oe2aR4YgSzkf2wdmnoZBrIJf3tB+YbIvUAhDwcKew4lbqcSwLWw YA0XL2CJcYxr9T3TZmfyW6y9WBQsD9ii68Xo59ovpbKBTF7MTZLnryigAxRGSVuvRhLy6Qjc xlM8E1ePOOHFooR6j5y4FUG1R4h/17lslfwol3dO1y243nS3kqSMvsAybrfvYU/fxVsv7thT WKuywTS4p1WuLLJxcbU8fFkLC/0WqApgYeMJEIiTc1HSQU+A2Sel0AcMOg9L7iC8xMsIrtPh dDQu6gDLxsDQ8eTaCaBfpmRKTuebigrcIVYS60HCZUkTvhQczM2AVGd1FzDq5zjobSuSq4/a IL6NUFHsxQfWmtpYlTwxzQ9hHTdDahT4oyRysz/jz2nLpOvfftqDrt5f2fn+4q07H4h6yR9a eU2joxEVCGg1uql03X1ZTKP2eDR7I/ok5Fr3tsTaQ5qKB4Sx+RneQGJtYpkgPCZ8wKV6Vn5G XYw+sZc/hWVgjxsg4lPgCovRJ5ws+KMabGys4AlVgGdGf/2zyvWB4PC52Pl79/jo8qjz7l0Z ruvhp2jQ71FwPoYrWgvqo1ZfcHL37dHfkUnIqcpVgaIwbtkJGte5+mQWKMe2adR/IQc4IJ7P n0tDT+FrycaqS5EVP0zSgUvGJf09D+WSVgkrpKXNvoizVpdAMPHu5BUlV4Gy+dXej0k8hmk1 z8Lr0XicFY2CaHKfbQv6sF934a/NTZo/Svr1EBJ+hYRG/cBsbv7qKzPlPuv93P8FX5V5ln5F 3NZDCwtRUHyOg+Dd/+k1nQHoJMai2oCxbJpfVfEEXw1tEFXIfMmZGIFkLprcaZkJhg3OzaB/ T2YosiqIG+rPlm3Sny5sYavfS4Bn0OmC1g55sg65SpyXvsyLtQeklJI/HPMsJFe9p9fKp+AM 0mQExxxolsMAIi01Pw9q7L85MD7/LVlmyxdxhF8m4GaRb5hTnkS3wJP6OHuWx74bYaQVSRWs PZtIL7aSJnB7Ni26QzaX8fYcx56MJXvn4ly/kgBSKFSRCn5RrDKkaonyqPkjDkESUUJleihD 9TZGNh0kNnn0wW6DDVQwRp88ksgBOTRWOBHFYuIoIhJDnGRYu6JZR3RToNXGEsTRB1TXI9R2 F/4dD4v+GgCn88lSHkX8gGyudtLs+OvCcLW2X0BU/FTaX56VQ1CFLF52DZK4sAJZ4ewKJHFh BUevs8sevV5YDLZKdjlIyCro2xnRFWAyrxORtULITObbYGtFkzXjsXpf0jy8xmmpGo1FLQ+a VUf33aUg0J02KeNC8HYq7QmprqYXg0/2cna3kU3tE7Q5+p8+Qm2ma+HA1oNtZdyGdOQbiQa6 wUQ4i2uOeNFe9un3l5zalZhkVe5pob+maqVFWVUjzUJ68Q3VA0HLqtm6ktCUyPR+Tf1IG7Ma iIfX0TiZISRpz7OmiB4Ho6i3lnl/IM8bM3OeUhVY1LrkDjHhYCMVS9wWv9JdjXqPhNSfBmM0 33sPsnDLDHuI70C2ORSyFqXFKJkKor5ECGbYQ3rGgqKs3WiyBrrqVJriMvr66KcOq7kK1c/V arWZSnp79JIT9uYTkPOiRERyDRJJw9iitL1qqiBsxJOzUwSR3WMgwjAZOlIoukrM74Z+kK5N f1B/JSRodZ+H1qg2PWQ1C6jg8qdiSy8Fac9DLfcjcdB6jicxoc0m/SkwjeuMpGC8eSjb0LAh VpUbmEY1cKzQZHS/5hUqWlKGCpazd4Rs9WQ06V4NRtcf0qV/06JOt5QVBkWe58L+yPKUSIPD Gs81g1qckm9vqDMbLAuNdiESvALf54HA54QiWWmaf3cdWjjhvHnSUzYd/Q+YblY/L5hu2chp yPucYMDLpk0nKqgBJpBrYFfz6k651sTj1axZKNiMCPZnvAZtoKRb7hmMyBKpKDXKfEaC5+ps Vpx+Mz/9XugHV/L07DKdGXWSkl1Dltsr4YD6PhZVEiVfPbKSzd0b3i6xwT6aNav0IMqPUEAM cGahzZbXqiPI3B6pUVAt/rDHsZDD+p5A3NV3yvWGe+dMPy6a7Eg1WWrRVQL5pETEzKA8Nr5p uKdliH8gGvKcoJ4TjXjFEEApPm9OYT4fqXn+CdbO2882xgQpWZ/2flnzguB4vKpIo4zzSUuH HloNjCffwrBqfNZ+E48LDKXrhYngCFPJh7apfn5arX+mv/Y+b+Nfzc9oUBZ8IJP+LcbJxMg8 iEyLxSu0j7KTNBbc/Fc0r8guo5zH/Fcs454TECFKnxMsYDSpxbtsdFV1zwUpUOX14sefq79U +j0Md5tS5dtJoWHp3JQVsLktk1I2RjSO2dOR+qhwz6rotFpK46kpi1mTp3H4cLhOB4u/jAb7 dfpUb+3WyoaLZM/9H+iHBuT64/3ALZPZi2A1C96asbm1QBwWvmmrKqZr1l7NTFu2WTMLLd+t Yn2EGSYfuzFjESSicDOe06R3NL//8dKcQ1dNt9u9YMuck/NtrBE+dM2aHJw1/HUcJ9NKkHw5 mqKx0jaDqp7Dv76Hf5njyVhV8PRcIbMe6K2xYagC24aKuqJM667p4KlF95/t26eWbd79Z/KK 2T5nFvPLLR+KbBVf8Fo6e1D7V04dr2Vv1E3QPOyJriGIjmP8UvzIO8FbaAsquvER3ZSgnY9U Dz+tsRp3YJ6ni8HHzU0xSbNvrPzE2h9GB97nkD/CXQTHOpKQXFD/3XQ0HADBGyDBk03Ol749 r40ekgvKAhLhXTcZjKaSJZPj0MroK2dU/sGPl/R0q0kvu+N468VYH7kMv7eEGZsz2wGv2i0v R20n2X66tYMdxe/8ysjEKyrCeEuuuEfiFs8Fn92vbyikYsGZEp27rXW3Z5429m3NtopUJMLM 16vU2rnArAEpxh8lTcqYiqA7XldWaTi8AVZpOJyaL/I+KS90yzdn0Fl/RSx89PK1X9KWXfyv bis1xuBENT/OzNM9/KMO/8P2ftqYaXwwrJPqmDKxScruJ9GdMBcwd2X7L8nAv9EGPlHGb0+C MFb3LBKKkCoNVAjizxD+LURFu/rXv9rwEWR031ZCJxQqQpff6LpsBqQ5jz4BZYJvT5hwRdeM kI4yz2RICPT6mLgxwJdGdFIa9sbTSdnUVJ4eROSIslJ+lU02+Cs9ZG49E1FGKtIaOMtmbUkd JXG22iEhp95oNst1kXIce61PgPDXZu0gtOFBo4wMQ55LNqm7wbd1G7IH7XiuHsnMxtoAyEsP PX5I3EtMbxmxNsAf5bmgsgg2RrFu8ux3HLv7hLbsGPa7d5y5Vq3Ee/0qhnYP2M16kXNbO4fw sV94luKWCLJqqy6Vq1kDeRehPQsw245lTAcltE+zUmnVPq2iEUOdTBQQy9wMLUSqDQ3GZirB OyOXKM7NHn4tk2XK0M6gLgNC6vcxw8/7+sqGOwE1j2VCz8U/r+nPmP684T/36M9r+jOmP9FZ 8wsLJLSWcCkfOLg1wiZBL874PsFgAdSlqp2azJkhxzCpDURJLJP1Clxr0TMwXLb4Bxnm7Hlr PDQv3IfCBlaKveXzGDz4ktcKZbCTMvwleLXxFotXCkdGMbjQko3fAcnliEIfYawTXKqbfjzo JTbMmgu2RSDHHggNO9l9IjM3856jqorhUJizYoOcWSc0AR+W0BVs9NKmbPT0N3w0Nqwy2l/B bxALK+boejojExMeFaaY+H48ffT7WbH1wDE27gEpEV3jRvdtB7PYbNXGTa3dBvrSrtUb7Wqj WU87e1nzL6UVC8pu15t+UaEtZBG2uFR57mtjO9WPN3BG6emAK7WjuIj9z6YYJfpiXSLDHOev pd49Pt2jKihOwOO4f83zS9Dl6Ncjxo4ccRKhDW76n3mG38k7GkY+S2bX6KuA1q748hf1B7NJ 7ALO+YSUrWoWGUCGj8hs1VbNtGHsZdkwAjU6Zd8hPHv3s8G0Px54ANdkY0eorj0MiDYe8cvM KEXwjET9womFFjxjO98A8tD8iywvSat9YG26/m88GVHPpQgRe6h/eH0/JusdsgqjuwNywZcS 66i9t8nMUmgBGZYyvzFeFK8TudDjsCHnGr7EifP7cmsZ3yiSLUbZLFKf4Xsz7ELJs19S8yXn fHp0g/5/SlIoQGRMWLhkA/ls+5naVHLoQiKr6jI5IbMlP33ITmRalUTPCH15eb+MRUfCoS41 EAml3eMWQRMoD5GsOOYhja8mH4qG5nW7vOZUTAUqBLXizCY2pFqMht5iv22JM1Xt23e7sUML NsYksHGbmwdiINhjHDc6XH0Fx/oi7tDD0YMZe5uSjcg5wuCEve3YzU2nAMowb8KhzhLbPjol 9xSZvheb+OZGgd14HnyWhrZXbw6HDE9y3KuYV5MYbvIYGKpHGsDtSMeFXi26Mez+qR4EQ4oR CBVbwzdM5QkIGdlZS8rKUcSdHnGP28/wnQQBAIoU97tW33PGh5L7BRmIokuofHiu1lHzJmqI /vfQ78H19M+1p8k/nz1DidcZFlIpYUrMeo8sEaVWMVcoeJEcTa/MmegtgJYHQ+6GkVE91odn EzlOWsJwM9lRuYH/ZvO7rJYae9agBX8vj9lIxnuz0McriRf0he0KoYhzHBfPe8ILcDsrnGYP 440JnP4LTu4zWMNnhi9YsiQCHgXuEmQnNd7a6dl5xS/BAVGh1DD+FE/0midwGI6/NoGd9skD RPQKU72z4YB2OGUm9zuMj9qfxgSAL0FBSf3/4JedxOQsiEwDWr56fdr2gyjNG7gLNuGadHwt 7LgPV8gmnIoV6uYOSlMf56Y5a6dKM2Ersq5ByCf0kkCBvTfCa/6OyWZPYSJTLZHMlOIgQ/Lt +Byi2lcxkxSMpDgaxikvbW9viJF23tjtvlFPhfzA53aILnSP7WWax0QXyRGBCpDfvw0RyF3E tjYXN7ZRZ7QFMopnfTZOKOIN0Q3n0J4uR1NgfrDhO4UushZ01FymLLoZEMe02VHAhvvmeMSa iULXmeFR5qHFosce1KsUoISCI4t3AL5F8pKRJ0o0mURka2Ixoqma/vRZ4vGE1pNBGuWDyPw/ G3MSzgAF0tQwucwzulBy2l8Pp5W7zsCLQBuR/0tMTXhCz8Ka3hGzDE0dO6j2Vw7qmkOHelb0 L2eTSTwMZ4MDh2qwRTOkNMX6Spfpowult5rWYjsw1j/R0Ot41mRk6psh+yVt3l1I2XbL7Uq9 Ebpsbb2ZQi+29i4sN/VeYOttd5d0es3VKebe7Nx9k1eRP8Hzpt46dzQ6svEWQ/gco255WF7V pBu2Rsls8kp6ZcSUVD/7Rs3e++5fNmHDdpPJdSB95Ege+BKkkoqZM/AwVAZX2Npjy/l26ORY BXtlkR8Wu4gEHiIHmbmy2XMqSly9z9J71vHWWEkfW8x81cVF5BDmtcZSCLK9zuFpOCKGY2Gz 2iajJG37XlCIpLakyyg6OQoJ2ZatYS+Z/tE1zLTRWbSC/4H1YyuoP339oNmvXj816MpeP7lO QxWssQaSd/EAYyrdzIasYEJ8FAY9IFCrqRfhlBjhKSsW+Wpi5XBtr0ba9NYeGgb68JkIWoc4 J2OFxuzjP3iLQKfwMcnG2KZ3OrySQOqLJoGNkqgA18eeApDEBmoefbBr5MLc3PEsphS6IKyM 7I0qN0kl/SrN+o2MZLHxzEvWh42F5RdmUKuoqpiZod4CxhpksmrP8HNJFPa4wKFRl+oHrlGX WZNnDOLq7IRvjOGOd2imLpUu6o1xreU5uc6VrVfnUudUQ+NoQRURi+K+LGVsN+ZdC1Ie7GWi Ma7f+LZyYPgK513RarFfe2tXMV0la/4C/qt6kJvNW8ZF2XQx/yWrSXmsRFvM3Hot53u5tIR9 1kyXSOWzNjTZ3UWwmxuyCDs+7ZJRGJn7MBWxmQmMBfZWlxXpEmilvivIe3Dsa3vh1NKOWs/s s1dvYBFnvSGc+78X1pe3UP7MeTMQ2J0FtTJswFytuZO7UqXsde9XSkdiPWchsuo0GcN3xqRc KZ3C9Zw9Oz+nvEIYbbcOS7RXq5YbO/M2iSplA3l4DtTB1aKs5vuLox86qOskOyIOqHvfJ3jY NbYB8B0eiUtXpYl7Cs5I9L2bbQxWOr8Brw1l9GWSOe4tP18xwgqRC/0ONrdpi29eJH722jln GWUFdfX4Jo0Iv7SgQg+uPTSvsdoA7T1tE/8pb+U+bAZ9QDoXf8bohn1Wj5qitllaPAv+HPgL hwfNAvDb4kLRI5fX8jC4jxy4qJtP2gUgcLR2dho7pXD4kRVEpI1gi6g0wnUVCrJXFEaJgzRa g1ZIJ+pJo5/P4w2BNnxR76FSlJ5MHg6ctSch/lxGt2901eb67BZzTQ5o2DMW69d8SiBXXlEv sLyeRa0FPXtuqqgpjVhpukr34DYVQyaWHfX0rBm/c26nq/oU+gGstbdtrF3J3NrXd/JW/ivW fW9u2elGDGZ3b27Zc25RRSkoRQd5FEzsyiQEGHmmNGqthsZJzLb70hdnj/UymW89DKaS90Rk Uc3U9pwIudUfWTC11KvTYJCuEkZEwVEStHqIEmx3TeKL6r4qal9JGY/FcI104DtVHjhcyTzw DKnNWMl7gdBmVGjzxHSV0vyhk4BhCiLahZKdJ9ipEWAgthxaz4nuReeyxMJOohi5GSIOSaiQ Va63FkMWNWr7e0tGSzLqqqMVgfZPHq1gEDWrTQmbvG9xmArcIOolYetKx65tS/SKsIn2RvLr 2hMi0t5AigbE/ArXe9/jOkmKJNFKrxnf28Sa3f8/bxWtEy4IAQA= --ReaqsoxgOBHFXBhH-- From owner-freebsd-ipfw@FreeBSD.ORG Wed Jan 14 13:43:37 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A4CA16A4CE for ; Wed, 14 Jan 2004 13:43:37 -0800 (PST) Received: from exchange.wan.no (exchange.wan.no [80.86.128.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 112FD43D48 for ; Wed, 14 Jan 2004 13:43:35 -0800 (PST) (envelope-from sten.daniel.sorsdal@wan.no) Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 14 Jan 2004 22:43:16 +0100 Message-ID: <0AF1BBDF1218F14E9B4CCE414744E70F5D9781@exchange.wanglobal.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 4.9 Release ipfw2 - OUCH using limit - reboots Thread-Index: AcPaz3DIDeIh2xv1RqmvZdvsJKYxawAFyy1g From: =?iso-8859-1?Q?Sten_Daniel_S=F8rsdal?= To: Subject: RE: 4.9 Release ipfw2 - OUCH using limit - reboots X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 21:43:37 -0000 >=20 > fuc> Has anyone seen a problem using 4.9 release with IPFW2=20 > using limit=20 > fuc> causing crashes/reboots and 'OUCH! cannot remove rule,=20 > count 65535' > fuc> in the logfile? Or, does anyone see a problem with my logic. >=20 > fuc> sample use of limit seeming to cause the problem: > fuc> ipfw -q add 00182 allow log logamount 1000 tcp from any to=20 > fuc> 216.XX.XX.6 setup limit src-addr 3 in via xl1 >=20 > I can confirm the same on 4.9 with FreeBSD 4.8-RELEASE. My=20 > sysctl settings with dyn_buckets was default. Machine reboots=20 > on high amount of traffic. >=20 I had to remove all "limit" options after i noticed they get=20 created but not destroyed. Had to reboot (or in a few cases i=20 could reload module) to fix it. I dont know why this happens but i believe i read about a similar thing on 5.x so i chalked it up as another bug that will be fixed soon. I run FreeBSD 4.9-RELEASE and couple of 4.9-PRERELEASE. Both have this issue, as far as i remember. _// Sten Daniel S=F8rsdal From owner-freebsd-ipfw@FreeBSD.ORG Wed Jan 14 13:54:20 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5890916A4CE for ; Wed, 14 Jan 2004 13:54:20 -0800 (PST) Received: from shellma.zin.lublin.pl (shellma.zin.lublin.pl [212.182.126.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AC6343D53 for ; Wed, 14 Jan 2004 13:54:18 -0800 (PST) (envelope-from pawmal-posting@freebsd.lublin.pl) Received: by shellma.zin.lublin.pl (Postfix, from userid 1018) id 781675F103; Wed, 14 Jan 2004 23:05:39 +0100 (CET) Date: Wed, 14 Jan 2004 23:05:38 +0100 From: Pawel Malachowski To: Luigi Rizzo Message-ID: <20040114220538.GA72981@shellma.zin.lublin.pl> References: <20040114082004.A43466@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20040114082004.A43466@xorpc.icir.org> User-Agent: Mutt/1.4.1i cc: ipfw@freebsd.org Subject: Re: semantics of 'not-applicable' options in ipfw ? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 21:54:20 -0000 On Wed, Jan 14, 2004 at 08:20:04AM -0800, Luigi Rizzo wrote: > As the subject says... what is people's opinion on the > best semantics for 'not-applicable' options in ipfw rules ? > > As an example, if i say (using ipfw2 syntax, for simplicity) > > 100 count src-port 100 > 200 count not src-port 100 > > and i receive a fragment, or an ICMP packet (which does not have port > information available), should it match rule 100, rule 200, none > or both ? The current implementation in ipfw2 is to use binary > logic, so the outcome of a 'not-applicable' option is FALSE, > and its negation is TRUE (so in the above case rule 200 will succeed). Ports are meaningful for TCP or UDP packets. If one uses src-port in rule, he assumes such a rule is for TCP or UDP packets. That's why I think rule 200 shouldn't match ICMP datagram. I also think ambiguous rules should be forbidden. This will force users to work with well planned rules. ;) -- Paweł Małachowski From owner-freebsd-ipfw@FreeBSD.ORG Wed Jan 14 14:03:59 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA22716A4CE for ; Wed, 14 Jan 2004 14:03:59 -0800 (PST) Received: from holodoc.ip.se (ua-213-115-163-137.cust.bredbandsbolaget.se [213.115.163.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0EB743D64 for ; Wed, 14 Jan 2004 14:03:55 -0800 (PST) (envelope-from rd@tilde.se) Received: by holodoc.ip.se (Postfix, from userid 103) id D6984128454; Wed, 14 Jan 2004 23:01:35 +0100 (CET) Received: from nyalaptopen (c-f79572d5.02-85-73746f13.cust.bredbandsbolaget.se [213.114.149.247]) by holodoc.ip.se (Postfix) with ESMTP id 3259E12844E for ; Wed, 14 Jan 2004 23:01:33 +0100 (CET) Message-ID: <001b01c3daea$49b70740$7901010a@nyalaptopen> From: "Rickard Dahlstrand" To: Date: Wed, 14 Jan 2004 23:03:48 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Sanitizer: This message has been sanitized! Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Dummynet performance X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 22:04:00 -0000 Hi, I have a fresh FreeBSD 4.9 installation and have activated the ipfw and dum= mynet kernel modules and configured two ports as a bridge. Everything works= fine except one thing. When I add a pipe that does any kind of bw limiting= , I can't get thru more than 5 mbit/s TCP on my bridged interface. UDP and = packets with larger tcp windows size work better. One issue I found was the= RTT. It's <1ms in all cases except when I add bw limiting, then it's up to= 15-20ms. Does the bw limiting add this much RTT? Here is the config and ip= erf results. ipfw -q flush ipfw -q add allow ip from any to any via fxp0 ipfw -q add pipe 1 all from any to any via fxp1 in ipfw -q add pipe 2 all from any to any via fxp2 in ipfw -q pipe 1 config bw 20Mbit/s delay 0ms ipfw -q pipe 2 config bw 20Mbit/s delay 0ms >iperf -c 10.1.1.100 ------------------------------------------------------------ Client connecting to 10.1.1.100, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1952] local 10.1.1.121 port 3540 connected with 10.1.1.100 port 5001 [ ID] Interval Transfer Bandwidth [1952] 0.0-10.0 sec 6.70 MBytes 5.60 Mbits/sec >iperf -c 10.1.1.100 -w 100k ------------------------------------------------------------ Client connecting to 10.1.1.100, TCP port 5001 TCP window size: 100 KByte ------------------------------------------------------------ [1952] local 10.1.1.121 port 3518 connected with 10.1.1.100 port 5001 [ ID] Interval Transfer Bandwidth [1952] 0.0-10.0 sec 17.8 MBytes 14.9 Mbits/sec If I do this: ipfw -q flush ipfw -q add allow ip from any to any via fxp0 ipfw -q add pipe 1 all from any to any via fxp1 in ipfw -q add pipe 2 all from any to any via fxp2 in ipfw -q pipe 1 config =20 ipfw -q pipe 2 config =20 I get this: >iperf -c 10.1.1.100 ------------------------------------------------------------ Client connecting to 10.1.1.100, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1952] local 10.1.1.121 port 3541 connected with 10.1.1.100 port 5001 [ ID] Interval Transfer Bandwidth [1952] 0.0-10.0 sec 108 MBytes 90.8 Mbits/sec Another issue I have is the fact that the delay-function doesn't appear to = work. (Or am I doing something wrong) ipfw -q flush ipfw -q add allow ip from any to any via fxp0 ipfw -q add pipe 1 all from any to any via fxp1 in ipfw -q add pipe 2 all from any to any via fxp2 in ipfw -q pipe 1 config delay 10ms ipfw -q pipe 2 config delay 10ms Reply from 10.1.1.100: bytes=3D32 time=3D11ms TTL=3D128 Reply from 10.1.1.100: bytes=3D32 time=3D15ms TTL=3D128 Reply from 10.1.1.100: bytes=3D32 time=3D13ms TTL=3D128 Reply from 10.1.1.100: bytes=3D32 time=3D12ms TTL=3D128 Ping statistics for 10.1.1.100: Packets: Sent =3D 4, Received =3D 4, Lost =3D 0 (0% loss), Approximate round trip times in milli-seconds: Minimum =3D 11ms, Maximum =3D 15ms, Average =3D 12ms If I normally have <1ms to this host and according to the config I should h= ave 20ms. I would really like some help on these issues.=20 Regards, Rickard. From owner-freebsd-ipfw@FreeBSD.ORG Wed Jan 14 14:30:53 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB5D316A4CE for ; Wed, 14 Jan 2004 14:30:53 -0800 (PST) Received: from shellma.zin.lublin.pl (shellma.zin.lublin.pl [212.182.126.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3650543D62 for ; Wed, 14 Jan 2004 14:30:52 -0800 (PST) (envelope-from pawmal-posting@freebsd.lublin.pl) Received: by shellma.zin.lublin.pl (Postfix, from userid 1018) id 909975F103; Wed, 14 Jan 2004 23:42:14 +0100 (CET) Date: Wed, 14 Jan 2004 23:42:14 +0100 From: Pawel Malachowski To: Sten Daniel S?rsdal Message-ID: <20040114224214.GB72981@shellma.zin.lublin.pl> References: <0AF1BBDF1218F14E9B4CCE414744E70F5D9779@exchange.wanglobal.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0AF1BBDF1218F14E9B4CCE414744E70F5D9779@exchange.wanglobal.net> User-Agent: Mutt/1.4.1i cc: Luigi Rizzo cc: ipfw@freebsd.org Subject: Re: semantics of 'not-applicable' options in ipfw ? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 22:30:53 -0000 On Wed, Jan 14, 2004 at 06:04:45PM +0100, Sten Daniel S?rsdal wrote: > I also believe that "via" option also causes the same kind of confussion. Going offtopic, but... That's true, people have problems with `via', it is a common practice to construct not-to-specific rules and to send packets via dummynet pipe twice, for example. ;) It is explained in ipfw(8), but not so clear for newbies. I personally prefer `in recv' and `out xmit' only, to make rulesets clear. Also lots of howtos and natd(8) uses `via' in examples with divert/natd. That's not good cause when someone is trying to work with both natd and dummynet, classifying packets on per-private-IP basis on exteral interface, it is better to split divert rule in the following manner: ipfw add divert natd ip from any to PUBLIC-IP-FOR-NAT[1] in recv NIC //now we have access to PRIVATE IPs for incoming packets and we can shape traffic on per-local-user basis //we also have access to PRIVATE IPs for outgoing packets since they were not passed throug natd ipfw add (dummynet rules here) ipfw add divert natd ip from PRIVATE-NET[1] to any out xmit NIC [1] Using PUBLIC-IP-FOR-NAT explicitly rather than `all' is better, because we avoid sending to divert socket packets destinated for other, public IP addressess in our LAN. Using PRIVATE-NET explicitly is better, because we avoid sending to divert socket packets from public IP addresses from our LAN. While we are near confussions, I know `queue' keyword is problematic for newbie dummynet users, because it has two different meanings, pipe has its queue and queue has its queue, also bunch of queues can be assigned with pipe, etc. ;) I usually explain newbies pipe as pipe, queue as queue ;) and queue (KB/slots) as a `buffersize'. It is also not clear in ipfw(8) what are these `slots', guessing just `packets', and what are advanteges or disadvanteges of using `slots' or `KB' unit. > By the way, do you have any plans to implement a tag/flag system? > ( example: > 100 flag 100 src-port 100 > 200 allow flag 100 > ) Someone may find it useful, especially with some kind of `skipto 0' available. ;) -- Paweł Małachowski From owner-freebsd-ipfw@FreeBSD.ORG Wed Jan 14 14:37:32 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1734516A4CE for ; Wed, 14 Jan 2004 14:37:32 -0800 (PST) Received: from shellma.zin.lublin.pl (shellma.zin.lublin.pl [212.182.126.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C387143D72 for ; Wed, 14 Jan 2004 14:37:28 -0800 (PST) (envelope-from pawmal-posting@freebsd.lublin.pl) Received: by shellma.zin.lublin.pl (Postfix, from userid 1018) id 86BDF5F103; Wed, 14 Jan 2004 23:48:51 +0100 (CET) Date: Wed, 14 Jan 2004 23:48:51 +0100 From: Pawel Malachowski To: ipfw@freebsd.org Message-ID: <20040114224851.GC72981@shellma.zin.lublin.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.1i Subject: ipfw not not X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 22:37:32 -0000 This `not not' is confusing a bit. (I want to match all packets smaller than 300 or greater than 500 bytes.) 4.9-STABLE, IPFW2: % ipfw add 3 count ip from any to any not iplen 300-500 00003 count ip from any to any not not iplen 300-500 % ipfw show 3 00003 3181 1729676 count ip from any to any not not iplen 300-500 -- Paweł Małachowski From owner-freebsd-ipfw@FreeBSD.ORG Wed Jan 14 14:48:01 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F96C16A4CE for ; Wed, 14 Jan 2004 14:48:01 -0800 (PST) Received: from tenebras.com (laptop.tenebras.com [66.92.188.18]) by mx1.FreeBSD.org (Postfix) with SMTP id 6F05043D5C for ; Wed, 14 Jan 2004 14:48:00 -0800 (PST) (envelope-from kudzu@tenebras.com) Received: (qmail 39254 invoked from network); 14 Jan 2004 22:47:59 -0000 Received: from sapphire.tenebras.com (HELO tenebras.com) (192.168.188.241) by laptop.tenebras.com with SMTP; 14 Jan 2004 22:47:59 -0000 Message-ID: <4005C71A.3070506@tenebras.com> Date: Wed, 14 Jan 2004 14:47:54 -0800 From: Michael Sierchio User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, zh-tw, zh-cn, fr, en, de-de MIME-Version: 1.0 References: <20040114224851.GC72981@shellma.zin.lublin.pl> In-Reply-To: <20040114224851.GC72981@shellma.zin.lublin.pl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: ipfw@freebsd.org Subject: Re: ipfw not not X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 22:48:01 -0000 Pawel Malachowski wrote: > This `not not' is confusing a bit. (I want to match all packets smaller > than 300 or greater than 500 bytes.) and you have an aversion to writing 1-299,501-8192 ? (8192 was chosen as the loopback MTU size). From owner-freebsd-ipfw@FreeBSD.ORG Wed Jan 14 14:52:30 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02EF916A4CE for ; Wed, 14 Jan 2004 14:52:30 -0800 (PST) Received: from shellma.zin.lublin.pl (shellma.zin.lublin.pl [212.182.126.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EE6743D58 for ; Wed, 14 Jan 2004 14:52:29 -0800 (PST) (envelope-from pawmal-posting@freebsd.lublin.pl) Received: by shellma.zin.lublin.pl (Postfix, from userid 1018) id DFDF35F103; Thu, 15 Jan 2004 00:03:51 +0100 (CET) Date: Thu, 15 Jan 2004 00:03:51 +0100 From: Pawel Malachowski To: Michael Sierchio Message-ID: <20040114230351.GE72981@shellma.zin.lublin.pl> References: <20040114224851.GC72981@shellma.zin.lublin.pl> <4005C71A.3070506@tenebras.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4005C71A.3070506@tenebras.com> User-Agent: Mutt/1.4.1i cc: ipfw@freebsd.org Subject: Re: ipfw not not X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 22:52:30 -0000 On Wed, Jan 14, 2004 at 02:47:54PM -0800, Michael Sierchio wrote: > and you have an aversion to writing 1-299,501-8192 ? (8192 was chosen as > the loopback MTU size). I simply believe displaying `not not' is not intentional and I'm reporting this here without opening PR. -- Paweł Małachowski From owner-freebsd-ipfw@FreeBSD.ORG Wed Jan 14 15:00:12 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49BFC16A4CE for ; Wed, 14 Jan 2004 15:00:12 -0800 (PST) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 132E643D5D for ; Wed, 14 Jan 2004 15:00:11 -0800 (PST) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id D7E0B1FF91D; Thu, 15 Jan 2004 00:00:09 +0100 (CET) Received: by transport.cksoft.de (Postfix, from userid 66) id 3620E1FF90C; Thu, 15 Jan 2004 00:00:08 +0100 (CET) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 6447B155E3; Wed, 14 Jan 2004 22:52:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 5A162155AE; Wed, 14 Jan 2004 22:52:51 +0000 (UTC) Date: Wed, 14 Jan 2004 22:52:51 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Luigi Rizzo In-Reply-To: <20040114130122.A86000@xorpc.icir.org> Message-ID: References: <20040114130122.A86000@xorpc.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: ipfw@freebsd.org Subject: Re: Request for review: ipfw2 for IPV6 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 23:00:12 -0000 On Wed, 14 Jan 2004, Luigi Rizzo wrote: > We would really appreciate testing by someone who is a kernel programmer > who has access to ipv6 network and some knowledge of the ipv6 code, > and thus can give advice on how to improve this code, and possibly > suggest fixes for the trivial bugs that are there. Just skipped over it: - patch should also be easily ported to HEAD - have not seen any #ifdef INET6 - will this break INET only setups ? - why is a file from Attic in the diff ? - can someone also please update the manpage ? Will be happy to have a closer look at it once the IPSEC issue got sorted out and I will finally have v6 here. -- Greetings Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ From owner-freebsd-ipfw@FreeBSD.ORG Thu Jan 15 00:25:20 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB2D916A4CE for ; Thu, 15 Jan 2004 00:25:20 -0800 (PST) Received: from t1.etype.net (relay1.koenig.su [195.135.213.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 055B343D46 for ; Thu, 15 Jan 2004 00:25:16 -0800 (PST) (envelope-from igor@garant.koenig.ru) Received: by t1.etype.net (Postfix, from userid 83) id 753DE450339; Thu, 15 Jan 2004 10:25:13 +0200 (EET) Received: from unix.garant.koenig.ru (unknown [195.135.212.65]) by t1.etype.net (Postfix) with ESMTP id B48E64500F1 for ; Thu, 15 Jan 2004 10:25:06 +0200 (EET) Received: (qmail 3368 invoked from network); 15 Jan 2004 08:23:31 -0000 Received: from ns.garant.koenig.ru (HELO unix.garant.koenig.ru) (100.100.100.41) by 0 with SMTP; 15 Jan 2004 08:23:31 -0000 From: =?koi8-r?b?6cfP0tgg8M/Qz9c=?= Organization: =?koi8-r?b?7Pfz?= To: freebsd-ipfw@freebsd.org Date: Thu, 15 Jan 2004 10:23:31 +0200 User-Agent: KMail/1.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401151023.31347.igor@garant.koenig.ru> Subject: X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2004 08:25:21 -0000 Hi, up to now I have used freebsd with ipfw2 based on stateless rules. From freebsd article freebsd-dialup I have taken example of using nat and pure statefull ipfw. I have made some changes, but it does not work, I returned to example, but result the same. Somebody can advice me with statefull ipfw and natd. There are my not working rules: #!/bin/sh # # Define the firewall command (as in /etc/rc.firewall) for easy # reference. Helps to make it easier to read. fwcmd="/sbin/ipfw -q" # Force a flushing of the current rules before we reload. ${fwcmd} -f flush ${fwcmd} add 300 deny log ip from any to any not verrevpath in recv tun0 # Divert all packets through the tunnel interface. ${fwcmd} add divert natd ip from any to any via tun0 #${fwcmd} add count ip from any to any via tun0 # Allow all connections that have dynamic rules built for them, # but deny established connections that don't have a dynamic rule. # See ipfw(8) for details. ${fwcmd} add check-state ${fwcmd} add deny log tcp from any to any established # Allow all localhost connections ${fwcmd} add allow tcp from me to any out via lo0 setup keep-state ${fwcmd} add deny tcp from me to any out via lo0 ${fwcmd} add allow ip from me to any out via lo0 keep-state # Allow all connections from my network card that I initiate ${fwcmd} add allow tcp from me to any out xmit any setup keep-state ${fwcmd} add deny log tcp from me to any ${fwcmd} add allow ip from me to any out xmit any keep-state # Everyone on the localnet is allowed to connect to the following # services on the machine. This string specifically allows connections # to ftp, sshd, smtp, dns, http, pop3, proxy. ${fwcmd} add allow tcp from 100.100.100.0/24 to me dst-port 21,22,25,53,80,110,443,3128 in recv fxp0 setup keep-state ${fwcmd} add allow tcp from 192.168.1.0/24 to me dst-port 25,53,110,3128 in recv 192.168.1.1 setup keep-state # Allow all udp connections from my network ${fwcmd} add allow udp from any to any via fxp0 keep-state ${fwcmd} add allow udp from any to any via 192.168.1.1 keep-state # Enable ICMP # Deny and log all pings from inet and localnet ${fwcmd} add deny log icmp from any to me icmptypes 8,13 ${fwcmd} add allow icmp from me to any keep-state ${fwcmd} add allow icmp from 100.100.100.0/24 to any in recv fxp0 keep-state ${fwcmd} add allow icmp from 192.168.1.0/24 to any in recv 192.168.1.1 keep-state #Allow all for users that whill use some services via NAT #${fwcmd} add allow tcp from 100.100.100.0/24{1,11} to 80.253.4.0/24 via fxp0 setup keep-state ${fwcmd} add allow log tcp from 100.100.100.0/24 to 80.253.4.0/24 dst-port 80,1521,1526,3389 recv fxp0 xmit tun0 setup keep-state # This sends a RESET to all ident packets. ${fwcmd} add reset log tcp from any to me 113 in recv tun0 # Deny all the rest. ${fwcmd} add deny log ip from any to any From owner-freebsd-ipfw@FreeBSD.ORG Thu Jan 15 04:07:30 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 57E6D16A4CE for ; Thu, 15 Jan 2004 04:07:30 -0800 (PST) Received: from smart.eusc.inter.net (smart.eusc.inter.net [213.73.101.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBF9D43D64 for ; Thu, 15 Jan 2004 04:07:28 -0800 (PST) (envelope-from msch@snafu.de) Received: from mail.snafu.de ([10.12.0.4] helo=service.snafu.de) by smart.eusc.inter.net with smtp (Exim 3.36 #4) id 1Ah6HX-0003iy-00 for freebsd-ipfw@freebsd.org; Thu, 15 Jan 2004 13:07:27 +0100 To: freebsd-ipfw@freebsd.org From: Matthias Schuendehuette X-Sender: msch@snafu.de Date: Thu, 15 Jan 2004 12:07:27 GMT X-Mailer: Endymion MailMan Standard Edition v3.0.35 Message-Id: Subject: ipfw2 and bridging on 5.2-RELEASE X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2004 12:07:30 -0000 Hello, I have serious problems with ipfw2 and bridging on my FreeBSD 5.2-RELEASE machine. Fist of all: Is this the right list? Or should I go to 'net' or 'questions'? Anyway, here's the situation: My bridging machine has three interfaces, 'bge0' with an IP-Adress for ssh-access and 'fxp0'(outbound) and 'fxp1'(inbound) for bridging. All the network traffic is in a VLAN with VLAN-ID 112, just to mention, with 'vlan0' and 'vlan1' as the corresponding vlan-interfaces for 'fxp0' resp. 'fxp1'. My bridge configuration is: net.link.ether.bridge.config: fxp0:0,fxp1:0,vlan0:1,vlan1:1 and works with an 'open' firewall without problems. My ruleset for testing purposes is fairly straightforward: # setup 'lo0' 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 00400 check-state 00500 skipto 3000 ip from any to any layer2 # setup for ssh-access via 'bge0' 00600 allow tcp from any to me dst-port 22 in recv bge0 setup keep-state 00700 allow ip from me to any xmit bge0 keep-state # rules for the bridge 03000 allow ip from any to any layer2 mac-type 0x0806 # ARP 03100 allow tcp from any to any recv fxp1 setup keep-state 03200 allow udp from any to any recv fxp1 keep-state 03300 allow icmp from any to any recv fxp1 03400 allow ip from any to any recv fxp1 03500 deny log ip from any to any 65535 deny ip from any to any As usual, my first test is pinging from inside to an outside machine. Done that, I see, that the ping-requests come through the filtering bridge and the ping replies were blocked - so far, so good. But the ICMP-Packets use rule #3400 and not #3300, why? If I change rule #3300 to "allow icmp from any to any" it still doesn't work, only "allow ip from any to any" leeds to a working ping (of course). BTW, the same is true for TCP and/or UDP traffic - obviously the IP protocol type is not recognized. Is this a bug or a feature - or a limitation because of the bridging? Or is my understanding wrong in any way? I hope, someone can explain this behaviour a bit to me... TIA - Matthias -- Matthias Schuendehuette, Berlin, Germany From owner-freebsd-ipfw@FreeBSD.ORG Thu Jan 15 04:27:24 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE7AA16A4CE for ; Thu, 15 Jan 2004 04:27:24 -0800 (PST) Received: from exchange.wan.no (exchange.wan.no [80.86.128.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6949643D66 for ; Thu, 15 Jan 2004 04:27:23 -0800 (PST) (envelope-from sten.daniel.sorsdal@wan.no) Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 15 Jan 2004 13:27:21 +0100 Message-ID: <0AF1BBDF1218F14E9B4CCE414744E70F07DF7E@exchange.wanglobal.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ipfw2 and bridging on 5.2-RELEASE Thread-Index: AcPbYDPM/8VJXWb3QV+LOQnuUMrrAAAAicFX From: =?utf-8?Q?Sten_Daniel_S=C3=B8rsdal?= To: "Matthias Schuendehuette" , Subject: RE: ipfw2 and bridging on 5.2-RELEASE X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2004 12:27:25 -0000 DQo+IE15IGJyaWRnZSBjb25maWd1cmF0aW9uIGlzOg0KPiBuZXQubGluay5ldGhlci5icmlkZ2Uu Y29uZmlnOiBmeHAwOjAsZnhwMTowLHZsYW4wOjEsdmxhbjE6MQ0KPiBhbmQgd29ya3Mgd2l0aCBh biAnb3BlbicgZmlyZXdhbGwgd2l0aG91dCBwcm9ibGVtcy4NCi4uLg0KY2hhbmdlIHlvdXIgY2x1 c3Rlci1pZCdzLi4uDQogDQpfLy8gU3RlbiBEYW5pZWwgU8O4cnNkYWwNCg== From owner-freebsd-ipfw@FreeBSD.ORG Thu Jan 15 06:22:56 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7AE3116A4CE for ; Thu, 15 Jan 2004 06:22:56 -0800 (PST) Received: from hotmail.com (bay10-f68.bay10.hotmail.com [64.4.37.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07A3C43D54 for ; Thu, 15 Jan 2004 06:22:55 -0800 (PST) (envelope-from dementry@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 15 Jan 2004 06:22:51 -0800 Received: from 195.212.29.229 by by10fd.bay10.hotmail.msn.com with HTTP; Thu, 15 Jan 2004 14:22:51 GMT X-Originating-IP: [195.212.29.229] X-Originating-Email: [dementry@hotmail.com] X-Sender: dementry@hotmail.com From: "erox xcamp" To: freebsd-ipfw@freebsd.org Date: Thu, 15 Jan 2004 14:22:51 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 15 Jan 2004 14:22:51.0421 (UTC) FILETIME=[0EE66CD0:01C3DB73] Subject: Homepage for ipfw2 ? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2004 14:22:56 -0000 Hi. Where can I get access to ipfw2 homepage. Who have developt the software ipfw2 ? Its hard to get some information to set it up. Any one who have a clue ? Best Regards Michel _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 From owner-freebsd-ipfw@FreeBSD.ORG Thu Jan 15 06:53:56 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5743316A4CE for ; Thu, 15 Jan 2004 06:53:56 -0800 (PST) Received: from deliver.epitech.net (deliver.epitech.net [163.5.0.25]) by mx1.FreeBSD.org (Postfix) with SMTP id DAB6F43D3F for ; Thu, 15 Jan 2004 06:53:54 -0800 (PST) (envelope-from le-hen_j@epita.fr) Received: from epita.fr ([10.42.1.60]) by deliver.epitech.net (SAVSMTP 3.1.2.35) with SMTP id M2004011515522505097 ; Thu, 15 Jan 2004 15:52:25 +0100 Received: from carpediem (carpediem.epita.fr [10.42.42.5]) by epita.fr id i0FErpO27658 Thu, 15 Jan 2004 15:53:51 +0100 (CET) Date: Thu, 15 Jan 2004 15:53:50 +0100 From: jeremie le-hen To: erox xcamp Message-ID: <20040115145350.GD29162@carpediem.epita.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i cc: freebsd-ipfw@freebsd.org Subject: Re: Homepage for ipfw2 ? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2004 14:53:56 -0000 > Where can I get access to ipfw2 homepage. AFAIK, there is no homepage for ipfw. I only found some tutorials / HOWTOs. > Who have developt the software ipfw2 ? >From ipfw(8) manpage: AUTHORS Ugen J. S. Antsilevich, Poul-Henning Kamp, Alex Nash, Archie Cobbs, Luigi Rizzo. Current maintainer is known to be Luigi Rizzo. > Its hard to get some information to set it up. man 8 ipfw :-) http://www.freebsd-howto.com/HOWTO/Ipfw-HOWTO http://www.toad-one.org/howto/FreeBSD/Ipfw-Advanced-Supplement-HOWTO.txt Browsing or searching the archives of ipfw@ will also help you. http://www.freebsd.org/support.html#mailing-list Best regards, -- Jeremie LE HEN aka TtZ/TataZ jeremie.le-hen@epita.fr ttz@epita.fr Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! From owner-freebsd-ipfw@FreeBSD.ORG Thu Jan 15 07:12:21 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1D5216A4CE for ; Thu, 15 Jan 2004 07:12:21 -0800 (PST) Received: from smart.eusc.inter.net (smart.eusc.inter.net [213.73.101.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83D0E43D6E for ; Thu, 15 Jan 2004 07:12:15 -0800 (PST) (envelope-from msch@snafu.de) Received: from mail.snafu.de ([10.12.0.4] helo=service.snafu.de) by smart.eusc.inter.net with smtp (Exim 3.36 #4) id 1Ah9AM-00027D-00; Thu, 15 Jan 2004 16:12:14 +0100 To: sten.daniel.sorsdal@wan.no From: msch@snafu.de X-Sender: msch@snafu.de Date: Thu, 15 Jan 2004 15:12:14 GMT X-Mailer: Endymion MailMan Standard Edition v3.0.35 Message-Id: cc: freebsd-ipfw@freebsd.org Subject: RE: ipfw2 and bridging on 5.2-RELEASE X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2004 15:12:21 -0000 Hi, >> My bridge configuration is: >> >> net.link.ether.bridge.config: \ >> fxp0:0,fxp1:0,vlan0:1,vlan1:1 >> and works with an 'open' firewall without problems. > ...change your cluster-id's... Ahmm... "-v" please. :-) Do you mean that a cluster-ID of "0" is not defined in the man-page of bridge(4)? Changing "net.link.ether.bridge.config" to "fxp0:8,fxp1:8,vlan0:9,vlan1:9" doesn't change anything. If a cluster-ID of "0" is not working at all, the article on "Filtering Bridges" (http://www.freebsd.org/doc/en_US.ISO8859-1/articles/filtering-bridges/ index.html) should be corrected - there is a cluster-ID of "0" kind of recommended (see Chapter 4 "Enabling the Bridge"). Thanks so far - Matthias From owner-freebsd-ipfw@FreeBSD.ORG Thu Jan 15 09:08:17 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 386E916A4CE for ; Thu, 15 Jan 2004 09:08:17 -0800 (PST) Received: from mail.lphp.org (APastourelles-107-1-2-121.w193-251.abo.wanadoo.fr [193.251.52.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id D437443D72 for ; Thu, 15 Jan 2004 09:07:29 -0800 (PST) (envelope-from ajacoutot@lphp.org) Received: from srv01.lphp.local (localhost [127.0.0.1]) by mail.lphp.org (8.12.10/8.12.10) with ESMTP id i0FH6Fjk007078 for ; Thu, 15 Jan 2004 18:06:15 +0100 (CET) (envelope-from ajacoutot@lphp.org) Received: (from www@localhost) by srv01.lphp.local (8.12.10/8.12.10/Submit) id i0FH6FBD007077 for freebsd-ipfw@freebsd.org; Thu, 15 Jan 2004 18:06:15 +0100 (CET) (envelope-from ajacoutot@lphp.org) Received: from ATuileries-108-2-1-254.w217-128.abo.wanadoo.fr (ATuileries-108-2-1-254.w217-128.abo.wanadoo.fr [217.128.152.254]) by webmail.lphp.org (IMP) with HTTP for ; Thu, 15 Jan 2004 18:06:15 +0100 Message-ID: <1074186375.4006c887150e1@webmail.lphp.org> Date: Thu, 15 Jan 2004 18:06:15 +0100 From: Antoine Jacoutot To: freebsd-ipfw@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 / FreeBSD-5.1 Subject: source routing and dynamic @ip X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2004 17:08:17 -0000 Hi :) Allright, so, I've been trying to build a routing setup for some weeks now, and after looking everywhere and asking for help, I still cannot find the answer. Here is what I want to do: source routing to 2 internet connections. Basically, I want net1 to go on the Internet using gateway connection1 and net2 to go on the internet using gateway connection2. You have to know that both internet connections have dynamic IPs and I need NAT on both. So far, these are my not working config files (defaut gateway is ip1/connection1). em0 = inside interface tun0 = pppoe DSL connection1 (default route) tun1 = pppoe DSL connection2 --> /etc/ipfw.conf #!/bin/sh fwcmd="/sbin/ipfw -q" ip1=`/sbin/ifconfig tun0 | /usr/bin/awk '/inet / { print $2 }'` ip2=`/sbin/ifconfig tun1 | /usr/bin/awk '/inet / { print $2 }'` lan1=192.168.0.0/24 lan2=192.168.1.0/24 ${fwcmd} -f flush ${fwcmd} add 100 fwd $ip2 all from $lan2 to any out recv em0 xmit tun0 ${fwcmd} add 200 divert 8669 all from $lan2 to any via tun1 ${fwcmd} add 300 divert 8668 all from any to any via tun0 ${fwcmd} add 400 allow all from any to any --> /etc/natd_tun0.conf interface tun0 port 8668 log_denied yes log_facility security use_sockets yes same_ports yes unregistered_only yes punch_fw 10000:10000 dynamic yes --> /etc/natd_tun1.conf interface tun1 port 8669 log_denied yes log_facility security use_sockets yes same_ports yes unregistered_only yes punch_fw 10000:10000 dynamic yes I am really really looking for help here. If you know how to make such a setup working, I would appreciate a hand. Thanks in advance. Regards, Antoine From owner-freebsd-ipfw@FreeBSD.ORG Thu Jan 15 14:08:26 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6E1C16A4CE for ; Thu, 15 Jan 2004 14:08:26 -0800 (PST) Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A48B43D7E for ; Thu, 15 Jan 2004 14:08:22 -0800 (PST) (envelope-from mags@tom-mchugh.demon.co.uk) Received: from tom-mchugh.demon.co.uk ([80.176.158.246] helo=192.168.1.10) by anchor-post-31.mail.demon.net with esmtp (Exim 3.35 #1) id 1AhFf3-000Jli-0V for freebsd-ipfw@freebsd.org; Thu, 15 Jan 2004 22:08:21 +0000 From: tom To: freebsd-ipfw@freebsd.org Date: Thu, 15 Jan 2004 23:06:55 +0000 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401152306.55243.mags@tom-mchugh.demon.co.uk> Subject: control ipfw from inside a program X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2004 22:08:27 -0000 howto control ipfw from inside a program ? (sorry new): a) exec (or other) a shell command, or b) program a sysctl (or other) call of some kind. caveat: dunno much about these calls from a program - all kind help appreciated. thanks, tom From owner-freebsd-ipfw@FreeBSD.ORG Thu Jan 15 17:23:04 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58CC116A4CE for ; Thu, 15 Jan 2004 17:23:04 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 976C443D2D for ; Thu, 15 Jan 2004 17:23:03 -0800 (PST) (envelope-from billf@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1098) id 9166F5C784; Thu, 15 Jan 2004 17:23:03 -0800 (PST) Date: Thu, 15 Jan 2004 17:23:03 -0800 From: Bill Fumerola To: tom Message-ID: <20040116012303.GC40147@elvis.mu.org> References: <200401152306.55243.mags@tom-mchugh.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200401152306.55243.mags@tom-mchugh.demon.co.uk> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.9-MUORG-20031210 i386 cc: freebsd-ipfw@freebsd.org Subject: Re: control ipfw from inside a program X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2004 01:23:04 -0000 On Thu, Jan 15, 2004 at 11:06:55PM +0000, tom wrote: > howto control ipfw from inside a program ? (sorry new): > a) exec (or other) a shell command, or your best bet. > b) program a sysctl (or other) call of some kind. > caveat: dunno much about these calls from > a program - all kind help appreciated. the interfaces is a slowly moving target. i'd avoid this unless you were constantly tracking ipfw changes (i.e. you were writing something that heavily interacts with ipfw and not just trying to add a firewall rule as part of a much larger projects). 'libipfw' is something that should be written at some point, but until we have multiple consumers of the 'api' it isn't really a priority. -- - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org From owner-freebsd-ipfw@FreeBSD.ORG Fri Jan 16 01:51:13 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0C8316A4CE for ; Fri, 16 Jan 2004 01:51:12 -0800 (PST) Received: from holodoc.ip.se (ua-213-115-163-137.cust.bredbandsbolaget.se [213.115.163.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id A514043D69 for ; Fri, 16 Jan 2004 01:51:04 -0800 (PST) (envelope-from rd@tilde.se) Received: by holodoc.ip.se (Postfix, from userid 103) id 37235128454; Fri, 16 Jan 2004 10:48:41 +0100 (CET) Received: from nyalaptopen (c-f79572d5.02-85-73746f13.cust.bredbandsbolaget.se [213.114.149.247]) by holodoc.ip.se (Postfix) with ESMTP id 20F6812844E for ; Fri, 16 Jan 2004 10:48:36 +0100 (CET) Message-ID: <009f01c3dc16$3b9270f0$7901010a@nyalaptopen> From: "Rickard Dahlstrand" To: References: <001b01c3daea$49b70740$7901010a@nyalaptopen> Date: Fri, 16 Jan 2004 10:50:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Sanitizer: This message has been sanitized! Subject: Re: Dummynet performance X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2004 09:51:13 -0000 Hi, Never mind this. After recompiling the kernel and adding a bunch of new parameters I got less than or 1 ms delay and up to 65mbit/s TCP bandwidth. (Up to 93mbit/s with a larger window-size!!) For anybody trying the same, try doing a new kernel with this configuration: options BRIDGE options IPFIREWALL options IPDIVERT options IPFIREWALL_VERBOSE options IPFW2 options HZ=2000 options DUMMYNET options DEVICE_POLLING and add this to /boot/loader.conf kern.ipc.nmbclusters="32768" kern.ipc.nsfbufs="32768" and to /etc/sysctl.conf net.link.ether.bridge_cfg=fxp1:0,fxp2:0 net.link.ether.bridge_ipfw=1 net.link.ether.bridge=1 net.inet.tcp.delayed_ack=0 By the way, this is a 1Ghz Via machine and I get approx 20% cpu load getting thru 93% TCP traffic. Memory is contant at 91M free of 128M and no swap. FreeBSD rocks!! Rickard. ----- Original Message ----- From: "Rickard Dahlstrand" To: Sent: Wednesday, January 14, 2004 11:03 PM Subject: Dummynet performance Hi, I have a fresh FreeBSD 4.9 installation and have activated the ipfw and dummynet kernel modules and configured two ports as a bridge. Everything works fine except one thing. When I add a pipe that does any kind of bw limiting, I can't get thru more than 5 mbit/s TCP on my bridged interface. UDP and packets with larger tcp windows size work better. One issue I found was the RTT. It's <1ms in all cases except when I add bw limiting, then it's up to 15-20ms. Does the bw limiting add this much RTT? Here is the config and iperf results. ipfw -q flush ipfw -q add allow ip from any to any via fxp0 ipfw -q add pipe 1 all from any to any via fxp1 in ipfw -q add pipe 2 all from any to any via fxp2 in ipfw -q pipe 1 config bw 20Mbit/s delay 0ms ipfw -q pipe 2 config bw 20Mbit/s delay 0ms >iperf -c 10.1.1.100 ------------------------------------------------------------ Client connecting to 10.1.1.100, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1952] local 10.1.1.121 port 3540 connected with 10.1.1.100 port 5001 [ ID] Interval Transfer Bandwidth [1952] 0.0-10.0 sec 6.70 MBytes 5.60 Mbits/sec >iperf -c 10.1.1.100 -w 100k ------------------------------------------------------------ Client connecting to 10.1.1.100, TCP port 5001 TCP window size: 100 KByte ------------------------------------------------------------ [1952] local 10.1.1.121 port 3518 connected with 10.1.1.100 port 5001 [ ID] Interval Transfer Bandwidth [1952] 0.0-10.0 sec 17.8 MBytes 14.9 Mbits/sec If I do this: ipfw -q flush ipfw -q add allow ip from any to any via fxp0 ipfw -q add pipe 1 all from any to any via fxp1 in ipfw -q add pipe 2 all from any to any via fxp2 in ipfw -q pipe 1 config ipfw -q pipe 2 config I get this: >iperf -c 10.1.1.100 ------------------------------------------------------------ Client connecting to 10.1.1.100, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [1952] local 10.1.1.121 port 3541 connected with 10.1.1.100 port 5001 [ ID] Interval Transfer Bandwidth [1952] 0.0-10.0 sec 108 MBytes 90.8 Mbits/sec Another issue I have is the fact that the delay-function doesn't appear to work. (Or am I doing something wrong) ipfw -q flush ipfw -q add allow ip from any to any via fxp0 ipfw -q add pipe 1 all from any to any via fxp1 in ipfw -q add pipe 2 all from any to any via fxp2 in ipfw -q pipe 1 config delay 10ms ipfw -q pipe 2 config delay 10ms Reply from 10.1.1.100: bytes=32 time=11ms TTL=128 Reply from 10.1.1.100: bytes=32 time=15ms TTL=128 Reply from 10.1.1.100: bytes=32 time=13ms TTL=128 Reply from 10.1.1.100: bytes=32 time=12ms TTL=128 Ping statistics for 10.1.1.100: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 11ms, Maximum = 15ms, Average = 12ms If I normally have <1ms to this host and according to the config I should have 20ms. I would really like some help on these issues. Regards, Rickard. From owner-freebsd-ipfw@FreeBSD.ORG Fri Jan 16 02:13:27 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 267F116A4CE for ; Fri, 16 Jan 2004 02:13:27 -0800 (PST) Received: from holodoc.ip.se (ua-213-115-163-137.cust.bredbandsbolaget.se [213.115.163.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FBB843D5E for ; Fri, 16 Jan 2004 02:13:25 -0800 (PST) (envelope-from rd@tilde.se) Received: by holodoc.ip.se (Postfix, from userid 103) id C05BD128458; Fri, 16 Jan 2004 11:11:02 +0100 (CET) Received: from nyalaptopen (c-f79572d5.02-85-73746f13.cust.bredbandsbolaget.se [213.114.149.247]) by holodoc.ip.se (Postfix) with ESMTP id E5ACA12844E for ; Fri, 16 Jan 2004 11:11:01 +0100 (CET) Message-ID: <00c001c3dc19$5d033410$7901010a@nyalaptopen> From: "Rickard Dahlstrand" To: Date: Fri, 16 Jan 2004 11:13:18 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Sanitizer: This message has been sanitized! Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Arps when bridged. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2004 10:13:27 -0000 Hi, I'm getting these messages. I have three interfaces, one uses DHCP and the = other two are bridged. Here is the log I get: Jan 16 10:13:57 testburk /kernel: arp: 00:10:f3:03:44:69 is using my IP add= ress 10.1.1.69! Jan 16 10:13:57 testburk /kernel: arp: 00:10:f3:03:44:6a is using my IP add= ress 10.1.1.69! Jan 16 10:14:47 testburk /kernel: arp: 00:10:f3:03:44:69 is using my IP add= ress 10.1.1.69! Jan 16 10:14:47 testburk /kernel: arp: 00:10:f3:03:44:6a is using my IP add= ress 10.1.1.69! Jan 16 10:57:31 testburk /kernel: arp: 00:10:f3:03:44:69 is using my IP add= ress 10.1.1.69! Jan 16 10:57:31 testburk /kernel: arp: 00:10:f3:03:44:6a is using my IP add= ress 10.1.1.69! Jan 16 11:03:06 testburk /kernel: arp: 00:10:f3:03:44:69 is using my IP add= ress 10.1.1.69! Jan 16 11:03:06 testburk /kernel: arp: 00:10:f3:03:44:6a is using my IP add= ress 10.1.1.69! Jan 16 11:06:40 testburk /kernel: arp: 00:10:f3:03:44:69 is using my IP add= ress 10.1.1.69! Jan 16 11:06:40 testburk /kernel: arp: 00:10:f3:03:44:6a is using my IP add= ress 10.1.1.69! What is the problem and does anyone know if ifconfig fxp1 -arp should stop = this? Thanks, Rickard. From owner-freebsd-ipfw@FreeBSD.ORG Fri Jan 16 07:17:46 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9624216A4CE for ; Fri, 16 Jan 2004 07:17:46 -0800 (PST) Received: from mailbox.wingercom.dk (mailbox.easyspeedy.dk [81.19.240.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09A6243D39 for ; Fri, 16 Jan 2004 07:17:44 -0800 (PST) (envelope-from per@xterm.dk) Received: from mailbox.wingercom.dk (localhost [127.0.0.1]) by mailbox.wingercom.dk (Postfix) with SMTP id 01E0B931B3; Fri, 16 Jan 2004 16:20:46 +0100 (CET) Received: from 62.242.151.142 (SquirrelMail authenticated user per) by mailbox.wingercom.dk with HTTP; Fri, 16 Jan 2004 16:20:46 +0100 (CET) Message-ID: <36682.62.242.151.142.1074266446.squirrel@mailbox.wingercom.dk> Date: Fri, 16 Jan 2004 16:20:46 +0100 (CET) From: "Per Engelbrecht" To: In-Reply-To: <00c001c3dc19$5d033410$7901010a@nyalaptopen> References: <00c001c3dc19$5d033410$7901010a@nyalaptopen> X-Mailer: SquirrelMail (version 1.2.5) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: freebsd-ipfw@freebsd.org Subject: Re: Arps when bridged. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2004 15:17:46 -0000 Hi Rickard This is more of 'net' problem than 'ipfw' but anyway, don't disable 'arp'.When sending a piece of your log, please also include the (in this case) 'ifconfig' and 'sysctl.conf' ! I could be wrong, but it seems more likely that you're having a loop. Read 'man bridge(4)' the last paragraph above the 'examples' section. If your bridging from a performance point of view, then have a look at 'ngctl' aswell http://bsdvault.net/sections.php?op=viewarticle&artid=98 Only downfall is when it's used in conjunktion with HP Procurve switches -they don't like the idea "two identical" mac-addresses! Regards /per per@xterm.dk > Hi, > > I'm getting these messages. I have three interfaces, one uses DHCP > and the other two are bridged. > > Here is the log I get: > > Jan 16 10:13:57 testburk /kernel: arp: 00:10:f3:03:44:69 is using > my IP address 10.1.1.69! Jan 16 10:13:57 testburk /kernel: arp: > 00:10:f3:03:44:6a is using my IP address 10.1.1.69! Jan 16 10:14:47 > testburk /kernel: arp: 00:10:f3:03:44:69 is using my IP address > 10.1.1.69! Jan 16 10:14:47 testburk /kernel: arp: 00:10:f3:03:44:6a > is using my IP address 10.1.1.69! Jan 16 10:57:31 testburk /kernel: > arp: 00:10:f3:03:44:69 is using my IP address 10.1.1.69! Jan 16 > 10:57:31 testburk /kernel: arp: 00:10:f3:03:44:6a is using my IP > address 10.1.1.69! Jan 16 11:03:06 testburk /kernel: arp: > 00:10:f3:03:44:69 is using my IP address 10.1.1.69! Jan 16 11:03:06 > testburk /kernel: arp: 00:10:f3:03:44:6a is using my IP address > 10.1.1.69! Jan 16 11:06:40 testburk /kernel: arp: 00:10:f3:03:44:69 > is using my IP address 10.1.1.69! Jan 16 11:06:40 testburk /kernel: > arp: 00:10:f3:03:44:6a is using my IP address 10.1.1.69! > > What is the problem and does anyone know if ifconfig fxp1 -arp > should stop this? > > Thanks, Rickard. > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to > "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Sat Jan 17 10:47:38 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F57816A4CE for ; Sat, 17 Jan 2004 10:47:38 -0800 (PST) Received: from clever.eusc.inter.net (clever.eusc.inter.net [213.73.101.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36EE143D46 for ; Sat, 17 Jan 2004 10:47:37 -0800 (PST) (envelope-from msch@snafu.de) Received: from tc10-n67-010.de.inter.net ([213.73.67.10]) by clever.eusc.inter.net with esmtp (Exim 3.36 #4) id 1AhvTr-0004En-00; Sat, 17 Jan 2004 19:47:35 +0100 From: Matthias Schuendehuette Organization: Micro$oft-free Zone To: Sten Daniel =?iso-8859-1?q?S=F8rsdal?= Date: Sat, 17 Jan 2004 19:47:34 +0100 User-Agent: KMail/1.5.4 References: <0AF1BBDF1218F14E9B4CCE414744E70F5D97D8@exchange.wanglobal.net> In-Reply-To: <0AF1BBDF1218F14E9B4CCE414744E70F5D97D8@exchange.wanglobal.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401171947.35008.msch@snafu.de> cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw2 and bridging on 5.2-RELEASE X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: msch@snafu.de List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2004 18:47:38 -0000 Hi, On Friday 16 January 2004 13:46, you wrote: > The man pages says one and up last time i checked, using and > id of 0 has been a reason for many kernel panics, atleast for me. > But of course it has to be actually bridging packets in the first > place to see those. Yes, you're right concerning the man-page. But that was not the reason for my problems. I changed the cluster-IDs but nothing has changed. As I've mentioned before, I have no problems concerning bridging. With 'sh /etc/rc.firewall open', all networking is up 'n running. Therefor I think that ipfw (or myself) has problems. But I don't think that I've made a larger mistake - 'allow icmp any to any' should make pinging work, don't it? > Have you remembered to set vlan0 and vlan1's parent interface into > promiscous mode? Yes, I checked it again, fxp0 and fxp1 *are* in promiscous mode. Seems to be automagic because of the bridging - I did no 'ifconfig' to set the interfaces explicitly into promiscous mode but they are... Anyway - thanks a lot! I'm trying to check this ipfw behaviour with another bridging machine with FreeBSD 4.9-STABLE and ipfw1 next week - perhaps there is any difference, perhaps even not... -- Ciao/BSD - Matthias Matthias Schuendehuette , Berlin (Germany) PGP-Key at and ID: 0xDDFB0A5F From owner-freebsd-ipfw@FreeBSD.ORG Sat Jan 17 15:13:54 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7F9B16A4CE; Sat, 17 Jan 2004 15:13:54 -0800 (PST) Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA41E43D39; Sat, 17 Jan 2004 15:13:52 -0800 (PST) (envelope-from fbsd_user@a1poweruser.com) Received: from barbish ([67.20.101.103]) by mta13.adelphia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with SMTP id <20040117231010.VIIA8989.mta13.adelphia.net@barbish>; Sat, 17 Jan 2004 18:10:10 -0500 From: "fbsd_user" To: "freebsd-questions@FreeBSD. ORG" Date: Sat, 17 Jan 2004 18:10:09 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal cc: freebsd-ipfw@freebsd.org Subject: 5.2 + ipfw2 + keep-state rules Bug X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: fbsd_user@a1poweruser.com List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2004 23:13:55 -0000 Using an fresh install of FBSD 5.2 RC2 I am trying to get stateful rules to function. For some reason ipfw2 seems to be issuing an ICMP:3.3 packet to my ISP's dns. Here is my rules file # Flush out the list before we begin. /sbin/ipfw -q -f flush # Set rules command prefix cmd="ipfw -q add" # Internal gateway housekeeping $cmd 00100 allow all from any to any via lo0 # allow all localhost $cmd 00105 allow all from any to any via xl0 # allow all local Lan $cmd 00110 check-state log logamount 500 $cmd 00150 divert natd all from any to any $cmd 00170 count log logamount 500 all from any to any $cmd 00310 allow log logamount 500 tcp from any to any 53 out via rl0 setup keep-state $cmd 00311 allow log logamount 500 udp from any to any 53 out via rl0 keep-state $cmd 00315 allow log logamount 500 tcp from any to any 80 out via rl0 setup keep-state $cmd 00350 allow log logamount 500 icmp from any to any out via rl0 keep-state $cmd 00500 deny log logamount 500 all from any to any Here is the ipfw2 log Ipfw: 110 UNKNOWN UDP 10.0.10.5:1181 208.206.15.11:53 out via rl0 Ipfw: 170 Count UDP 67.20.101.103:1181 208.206.15.11:53 out via rl0 Ipfw: 311 Accept UDP 67.20.101.103:1181 208.206.15.11:53 out via rl0 Ipfw: 110 UNKNOWN UDP 208.206.15.11:53 67.20.101.103:1181 in via rl0 Ipfw: 311 Accept UDP 208.206.15.11:53 67.20.101.103:1181 in via rl0 Ipfw: 110 UNKNOWN ICMP:3.3 67.20.101.103 208.206.15.11 out via rl0 Ipfw: 170 Count ICMP:3.3 67.20.101.103 208.206.15.11 out via rl0 Ipfw: 350 Accept ICMP:3.3 67.20.101.103 208.206.15.11 out via rl0 Ipfw: 110 UNKNOWN UDP 10.0.10.5:1181 208.206.15.11:53 out via rl0 Ipfw: 170 Count UDP 67.20.101.103:1181 208.206.15.11:53 out via rl0 Ipfw: 311 Accept UDP 67.20.101.103:1181 208.206.15.11:53 out via rl0 Ipfw: 110 UNKNOWN UDP 208.206.15.11:53 67.20.101.103:1181 in via rl0 Ipfw: 311 Accept UDP 208.206.15.11:53 67.20.101.103:1181 in via rl0 Ipfw: 110 UNKNOWN ICMP:3.3 67.20.101.103 208.206.15.11 out via rl0 Ipfw: 350 Accept ICMP:3.3 67.20.101.103 208.206.15.11 out via rl0 Ipfw: 110 UNKNOWN UDP 10.0.10.5:1181 208.206.15.12:53 out via rl0 Ipfw: 170 Count UDP 67.20.101.103:1181 208.206.15.12:53 out via rl0 Ipfw: 311 Accept UDP 67.20.101.103:1181 208.206.15.12:53 out via rl0 Ipfw: 110 UNKNOWN UDP 208.206.15.12:53 67.20.101.103:1181 in via rl0 Ipfw: 311 Accept UDP 208.206.15.12:53 67.20.101.103:1181 in via rl0 Ipfw: 110 UNKNOWN ICMP:3.3 67.20.101.103 208.206.15.12 out via rl0 Ipfw: 170 Count ICMP:3.3 67.20.101.103 208.206.15.12 out via rl0 Ipfw: 350 Accept ICMP:3.3 67.20.101.103 208.206.15.12 out via rl0 When I change the rules to use pass all just to test if there is something wrong with my ISP's dns server, everything works. So there is no reason for the icmp 3.3 packet. # Flush out the list before we begin. /sbin/ipfw -q -f flush # Set rules command prefix cmd="ipfw -q add" # Internal gateway housekeeping $cmd 00100 allow all from any to any via lo0 # allow all localhost $cmd 00105 allow all from any to any via xl0 # allow all local Lan $cmd 00150 divert natd all from any to any $cmd 00160 allow log logamount 500 all from any to any Log from about rules file Ipfw: 160 Accept UDP 67.20.101.103:1175 208.206.15.11:53 out via rl0 Ipfw: 160 Accept UDP 208.206.15.11:53 10.0.10.5:1175 in via rl0 Ipfw: 160 Accept TCP 67.20.101.103:1176 216.136.204.117:80 out via rl0 Ipfw: 160 Accept TCP 216.136.204.117:80 10.0.10.5:1176 in via rl0 Ipfw: 160 Accept TCP 67.20.101.103:1176 216.136.204.117:80 out via rl0 Ipfw: 160 Accept TCP 67.20.101.103:1176 216.136.204.117:80 out via rl0 Ipfw: 160 Accept TCP 216.136.204.117:80 10.0.10.5:1176 in via rl0 Ipfw: 160 Accept TCP 67.20.101.103:1176 216.136.204.117:80 out via rl0 Ipfw: 160 Accept TCP 216.136.204.117:80 10.0.10.5:1176 in via rl0 This looks like 5.2 ipfw2 bug to me. Any body explain why ipfw2 is doing this?