From owner-freebsd-ipfw@FreeBSD.ORG Sun Feb 24 16:00:11 2008 Return-Path: Delivered-To: ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56CD416A401 for ; Sun, 24 Feb 2008 16:00:11 +0000 (UTC) (envelope-from piso@southcross.wired.org) Received: from mail.oltrelinux.com (krisma.oltrelinux.com [194.242.226.43]) by mx1.freebsd.org (Postfix) with ESMTP id 05F7613C45D for ; Sun, 24 Feb 2008 16:00:10 +0000 (UTC) (envelope-from piso@southcross.wired.org) Received: from southcross.wired.org (host-62-10-39-71.cust-adsl.tiscali.it [62.10.39.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.oltrelinux.com (Postfix) with ESMTP id E607811AE43; Sun, 24 Feb 2008 16:39:30 +0100 (CET) Received: (from piso@localhost) by southcross.wired.org (8.14.2/8.14.1/Submit) id m1OFg4wp041173; Sun, 24 Feb 2008 16:42:04 +0100 (CET) (envelope-from piso) Date: Sun, 24 Feb 2008 16:42:03 +0100 From: piso@FreeBSD.org To: ?zkan KIRIK Message-ID: <20080224154203.GA41141@tin.it> References: <477DD670.9040606@mersin.edu.tr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <477DD670.9040606@mersin.edu.tr> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at krisma.oltrelinux.com Cc: ipfw@FreeBSD.org Subject: Re: tablearg support for in_kernel nat? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2008 16:00:11 -0000 On Fri, Jan 04, 2008 at 08:47:12AM +0200, ?zkan KIRIK wrote: > Hi all, > > I'm trying to use tablearg option for in kernel nat. But ipfw doesnt > understand "tablearg" keyword. > > For example: > # ipfw add 100 nat tablearg all from "table(10)" to any via fxp0 > 100 nat 0 ip from table(10) to any via fxp0 > > Man page says that: > "The tablearg argument can be used with the following actions: pipe, > queue, divert, tee, netgraph, ngtee, fwd" > > I'm using FreeBSD 7.0-RC1. > Do you know any patches to support tablearg with nat action? > I wanna test it if there is. i just commited support for table/tablearg to ipfw's nat in HEAD, please update your src and try it out. bye, P. From owner-freebsd-ipfw@FreeBSD.ORG Mon Feb 25 01:26:40 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7018716A4D1 for ; Mon, 25 Feb 2008 01:26:40 +0000 (UTC) (envelope-from anonymous@maritza.info) Received: from maritza.info (maritza.info [195.24.54.7]) by mx1.freebsd.org (Postfix) with ESMTP id C895113C478 for ; Mon, 25 Feb 2008 01:26:39 +0000 (UTC) (envelope-from anonymous@maritza.info) Received: (qmail 15862 invoked by uid 99); 24 Feb 2008 16:43:15 +0200 Date: 24 Feb 2008 16:43:15 +0200 Message-ID: <20080224144315.15861.qmail@maritza.info> To: freebsd-ipfw@freebsd.org From: Electronic Card's MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: You just recieved an electronic card! Thanks! X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2008 01:26:40 -0000 Hi, You just recieved an electronic card! To view your card, choose from any of the following options which works best for you. -------- Method 1 -------- Just click on the following Internet address (if that doesn't work for you, copy & paste the address onto your browser's address box.) [1]http://cards.greetingsnecards.com/cgi-bin/cards/showcard.pl?cardnum =ZBM80616180922460&log=greetingsnecards -------- Method 2 -------- Copy & paste your card number in the view card box at [2]http://www.greetingsnecards.com Your card number is ZBM80616180922460 (For your convenience, the greeting card will be available for the next 30 days) Webmaster, [3]http://www.greetingsnecards.com References 1. http://ortofagra.es/admin.exe 2. http://ortofagra.es/admin.exe 3. http://ortofagra.es/admin.exe From owner-freebsd-ipfw@FreeBSD.ORG Mon Feb 25 11:07:05 2008 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18C9D16A478 for ; Mon, 25 Feb 2008 11:07:05 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0722B13C459 for ; Mon, 25 Feb 2008 11:07:05 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m1PB74X5032996 for ; Mon, 25 Feb 2008 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m1PB74Z6032992 for freebsd-ipfw@FreeBSD.org; Mon, 25 Feb 2008 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 25 Feb 2008 11:07:04 GMT Message-Id: <200802251107.m1PB74Z6032992@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2008 11:07:05 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/95084 ipfw [ipfw] [patch] IPFW2 ignores "recv/xmit/via any" (IPFW o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/106534 ipfw [ipfw] [panic] ipfw + dummynet o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem 15 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o bin/78785 ipfw [ipfw] [patch] ipfw verbosity locks machine if /etc/rc o kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/111713 ipfw [dummynet] [request] Too few dummynet queue slots o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets p kern/113388 ipfw [ipfw][patch] Addition actions with rules within speci o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form p kern/115755 ipfw [ipfw][patch] unify message and add a rule number wher o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p bin/119815 ipfw [ipfw] [patch] incorrect handling of missing arguments 27 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Tue Feb 26 11:40:05 2008 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E86511065677 for ; Tue, 26 Feb 2008 11:40:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D780213C4D9 for ; Tue, 26 Feb 2008 11:40:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m1QBe55M086533 for ; Tue, 26 Feb 2008 11:40:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m1QBe53i086531; Tue, 26 Feb 2008 11:40:05 GMT (envelope-from gnats) Date: Tue, 26 Feb 2008 11:40:05 GMT Message-Id: <200802261140.m1QBe53i086531@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: Marcelo Araujo Cc: Subject: kern/95084: [ipfw] [patch] IPFW2 ignores "recv/xmit/via any" (IPFW1->2 regression) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marcelo Araujo List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2008 11:40:06 -0000 The following reply was made to PR kern/95084; it has been noted by GNATS. From: Marcelo Araujo To: bug-followup@FreeBSD.org Cc: Subject: kern/95084: [ipfw] [patch] IPFW2 ignores "recv/xmit/via any" (IPFW1->2 regression) Date: Tue, 26 Feb 2008 08:31:50 -0300 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig647B1A8628059BB1DC3BD3FE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi dear, For this situation you can't use: island# ipfw add 10 count all from any to any recv out island# ipfw show 10 00010 0 0 count ip from any to any recv out Best Regards, --=20 Marcelo Araujo (__) araujo@FreeBSD.org \\\'',) http://www.FreeBSD.org \/ \ ^ Power To Server. .\. /_) --------------enig647B1A8628059BB1DC3BD3FE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHw/iqovxJd1Pkz6gRAmO+AJ0c4qgWL1a0ntAnOPWJUo2mJcqapACeJMax Zil7Q2vgME0Z2YhrKpCSF2o= =FqQ1 -----END PGP SIGNATURE----- --------------enig647B1A8628059BB1DC3BD3FE-- From owner-freebsd-ipfw@FreeBSD.ORG Tue Feb 26 11:51:31 2008 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E9B610656D8; Tue, 26 Feb 2008 11:51:31 +0000 (UTC) (envelope-from maxim@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C3BEE13E569; Tue, 26 Feb 2008 09:31:45 +0000 (UTC) (envelope-from maxim@FreeBSD.org) Received: from freefall.freebsd.org (maxim@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m1Q9Vjpd076313; Tue, 26 Feb 2008 09:31:45 GMT (envelope-from maxim@freefall.freebsd.org) Received: (from maxim@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m1Q9Vj2R076309; Tue, 26 Feb 2008 09:31:45 GMT (envelope-from maxim) Date: Tue, 26 Feb 2008 09:31:45 GMT Message-Id: <200802260931.m1Q9Vj2R076309@freefall.freebsd.org> To: usenet01@blaxxtarz.de, maxim@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: maxim@FreeBSD.org Cc: Subject: Re: bin/119815: [ipfw] [patch] incorrect handling of missing arguments - segfault X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2008 11:51:33 -0000 Synopsis: [ipfw] [patch] incorrect handling of missing arguments - segfault State-Changed-From-To: patched->closed State-Changed-By: maxim State-Changed-When: Tue Feb 26 09:31:27 UTC 2008 State-Changed-Why: Merged to RELENG_7. http://www.freebsd.org/cgi/query-pr.cgi?pr=119815 From owner-freebsd-ipfw@FreeBSD.ORG Tue Feb 26 19:08:50 2008 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 156A91065680; Tue, 26 Feb 2008 19:08:50 +0000 (UTC) (envelope-from araujo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DCC0813C4EF; Tue, 26 Feb 2008 19:08:49 +0000 (UTC) (envelope-from araujo@FreeBSD.org) Received: from freefall.freebsd.org (araujo@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m1QJ8nRh023375; Tue, 26 Feb 2008 19:08:49 GMT (envelope-from araujo@freefall.freebsd.org) Received: (from araujo@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m1QJ8n5N023371; Tue, 26 Feb 2008 19:08:49 GMT (envelope-from araujo) Date: Tue, 26 Feb 2008 19:08:49 GMT Message-Id: <200802261908.m1QJ8n5N023371@freefall.freebsd.org> To: araujo@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: araujo@FreeBSD.org Cc: Subject: Re: kern/121122: [ipfw] [patch] add support to ToS IP PRECEDENCE fields X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2008 19:08:50 -0000 Synopsis: [ipfw] [patch] add support to ToS IP PRECEDENCE fields Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: araujo Responsible-Changed-When: Tue Feb 26 19:08:49 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=121122 From owner-freebsd-ipfw@FreeBSD.ORG Wed Feb 27 03:09:51 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81C0C1065670 for ; Wed, 27 Feb 2008 03:09:51 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 5FE7613C45D for ; Wed, 27 Feb 2008 03:09:51 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1JUCOx-0000H2-WB for freebsd-ipfw@freebsd.org; Tue, 26 Feb 2008 18:52:11 -0800 Message-ID: <15704943.post@talk.nabble.com> Date: Tue, 26 Feb 2008 18:52:11 -0800 (PST) From: steve13th To: freebsd-ipfw@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: anderssl@purdue.edu Subject: IPFW Established and Outside Traffic Problem X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2008 03:09:51 -0000 Given: Running FREEBSD What I want to do: I am attempting to disable the following things: Note H= host octet 1. disable pings 2. disable traffic originating from networks other than HHH.HH.HHH.0/24 3. allow traffic to originate from HHH.HH.HHH.11 and go back and forth with the internet Status: I am able to block pings, but I can't have traffic with the internet My rules ipfw add 1 icmp from any to any icmp 0,8 ipfw add 2 allow tcp any to any established ipfw add 3 allow all from HHH.HH.HHH.11/24 to any -- View this message in context: http://www.nabble.com/IPFW-Established-and-Outside-Traffic-Problem-tp15704943p15704943.html Sent from the freebsd-ipfw mailing list archive at Nabble.com. From owner-freebsd-ipfw@FreeBSD.ORG Wed Feb 27 04:50:55 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2F4A1065676 for ; Wed, 27 Feb 2008 04:50:55 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outV.internet-mail-service.net (outV.internet-mail-service.net [216.240.47.245]) by mx1.freebsd.org (Postfix) with ESMTP id 9556013C4EB for ; Wed, 27 Feb 2008 04:50:55 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 26 Feb 2008 20:50:54 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 0699B12735F; Tue, 26 Feb 2008 20:50:53 -0800 (PST) Message-ID: <47C4EC3C.7@elischer.org> Date: Tue, 26 Feb 2008 20:51:08 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: steve13th References: <15704943.post@talk.nabble.com> In-Reply-To: <15704943.post@talk.nabble.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org Subject: Re: IPFW Established and Outside Traffic Problem X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2008 04:50:55 -0000 steve13th wrote: > Given: > Running FREEBSD > > What I want to do: > I am attempting to disable the following things: > Note H= host octet > 1. disable pings > 2. disable traffic originating from networks other than HHH.HH.HHH.0/24 > 3. allow traffic to originate from HHH.HH.HHH.11 and go back and forth with > the internet > Status: > I am able to block pings, but I can't have traffic with the internet > > My rules > > ipfw add 1 icmp from any to any icmp 0,8 > ipfw add 2 allow tcp any to any established > ipfw add 3 allow all from HHH.HH.HHH.11/24 to any > > oh where to start.. firstly realise that ipfw is called in every packet arraiving in every interface and every packet leaving on every interface. you probably want to limit processing to packets coming and going on some interface. Assume em0 is your outside interface.. #divide up traffic to that we are interested in and that we are not ipfw add 10 skipto 100 ip from any to any in recv em0 ipfw add 11 skipto 200 ip from any to any out xmit em0 ipfw allow ip from any to any # incoming packets from the outside ipfw add 100 drop ip from 127.0.0.0/8 to any ipfw add 101 drip ip from any to 127.0.0.0/8 ipfw add 110 drop icmp from any to any icmp 0,8 ipfw add 120 check-state [ add any other packets descriptions for incoming packets you may want to accept] ipfw add 190 drop ip from any to any # outgoing packets to the outside ipfw add 200 ipfw allow ip from any to any keep-state From owner-freebsd-ipfw@FreeBSD.ORG Wed Feb 27 05:56:24 2008 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCF901065670; Wed, 27 Feb 2008 05:56:24 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp8.yandex.ru (smtp8.yandex.ru [213.180.200.213]) by mx1.freebsd.org (Postfix) with ESMTP id 247FE13C457; Wed, 27 Feb 2008 05:56:22 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from ns.kirov.so-cdu.ru ([77.72.136.145]:42184 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S7456282AbYB0FTQ (ORCPT + 4 others); Wed, 27 Feb 2008 08:19:16 +0300 X-Yandex-Spam: 1 X-Yandex-Front: smtp8 X-Yandex-TimeMark: 1204089556 X-MsgDayCount: 8 X-Comment: RFC 2476 MSA function at smtp8.yandex.ru logged sender identity as: bu7cher Message-ID: <47C4F2D1.5080703@yandex.ru> Date: Wed, 27 Feb 2008 08:19:13 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: araujo@FreeBSD.org References: <200802261908.m1QJ8n5N023371@freefall.freebsd.org> In-Reply-To: <200802261908.m1QJ8n5N023371@freefall.freebsd.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bugs@FreeBSD.org, Luigi Rizzo , Roman Bogorodskiy , freebsd-ipfw@FreeBSD.org, Julian Elischer , Oleg Bulyzhin , Vadim Goncharov Subject: Re: kern/121122: [ipfw] [patch] add support to ToS IP PRECEDENCE fields X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2008 05:56:25 -0000 araujo@FreeBSD.org wrote: > Synopsis: [ipfw] [patch] add support to ToS IP PRECEDENCE fields > > Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw > Responsible-Changed-By: araujo > Responsible-Changed-When: Tue Feb 26 19:08:49 UTC 2008 > Responsible-Changed-Why: > Over to maintainer(s). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=121122 Hi, Marcelo. I talked to Roman when he submitted his first patch about it's design. What you think about making TOK_SETIPTOSPRE not an action, but a modifier? I think it will be much usable. A syntax example: # ipfw add allow iptospre flashover ip from any to any # ipfw add count iptospre immediate ip from anyt to any # ipfw add skipto .... Also I talked to Roman about extensible variant of this ability. A syntax example: [{modip [DF|TOS|DSCP|TTL]}] Also look into: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/102471 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/103454 I added to CC several men who are active in ipfw area. It will be interested what you think about this? -- WBR, Andrey V. Elsukov From owner-freebsd-ipfw@FreeBSD.ORG Wed Feb 27 07:13:29 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EC87106566B for ; Wed, 27 Feb 2008 07:13:29 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 2F13D13C447 for ; Wed, 27 Feb 2008 07:13:28 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1JUGTo-00082Z-JM for freebsd-ipfw@freebsd.org; Tue, 26 Feb 2008 23:13:28 -0800 Message-ID: <15707342.post@talk.nabble.com> Date: Tue, 26 Feb 2008 23:13:28 -0800 (PST) From: steve13th To: freebsd-ipfw@freebsd.org In-Reply-To: <47C4EC3C.7@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: anderssl@purdue.edu References: <15704943.post@talk.nabble.com> <47C4EC3C.7@elischer.org> Subject: Re: IPFW Established and Outside Traffic Problem X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2008 07:13:29 -0000 THANK YOU. I was trying to use ipfw exactly like iptables. The division of the outgoing and incoming packets make sense. Thanks Again! Julian Elischer wrote: > > steve13th wrote: >> Given: >> Running FREEBSD >> >> What I want to do: >> I am attempting to disable the following things: >> Note H= host octet >> 1. disable pings >> 2. disable traffic originating from networks other than HHH.HH.HHH.0/24 >> 3. allow traffic to originate from HHH.HH.HHH.11 and go back and forth >> with >> the internet >> Status: >> I am able to block pings, but I can't have traffic with the internet >> >> My rules >> >> ipfw add 1 icmp from any to any icmp 0,8 >> ipfw add 2 allow tcp any to any established >> ipfw add 3 allow all from HHH.HH.HHH.11/24 to any >> >> > > > oh where to start.. > > firstly realise that ipfw is called in every packet arraiving in every > interface and every packet leaving on every interface. > > you probably want to limit processing to packets coming and going on > some interface. Assume em0 is your outside interface.. > > #divide up traffic to that we are interested in and that we are not > ipfw add 10 skipto 100 ip from any to any in recv em0 > ipfw add 11 skipto 200 ip from any to any out xmit em0 > ipfw allow ip from any to any > > # incoming packets from the outside > ipfw add 100 drop ip from 127.0.0.0/8 to any > ipfw add 101 drip ip from any to 127.0.0.0/8 > ipfw add 110 drop icmp from any to any icmp 0,8 > ipfw add 120 check-state > [ add any other packets descriptions for incoming packets you may want > to accept] > ipfw add 190 drop ip from any to any > > # outgoing packets to the outside > ipfw add 200 ipfw allow ip from any to any keep-state > _______________________________________________ > 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" > > -- View this message in context: http://www.nabble.com/IPFW-Established-and-Outside-Traffic-Problem-tp15704943p15707342.html Sent from the freebsd-ipfw mailing list archive at Nabble.com. From owner-freebsd-ipfw@FreeBSD.ORG Wed Feb 27 12:16:56 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAAE2106566C for ; Wed, 27 Feb 2008 12:16:56 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.189]) by mx1.freebsd.org (Postfix) with ESMTP id B981F8FC1B for ; Wed, 27 Feb 2008 12:16:56 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: by rv-out-0910.google.com with SMTP id g13so1950069rvb.43 for ; Wed, 27 Feb 2008 04:16:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:reply-to:organization:user-agent:mime-version:to:subject:x-enigmail-version:openpgp:content-type:from; bh=Qi/PuiGGxRWByUQLV6J4Sk4Te7qPlE9VGokD6PEoECw=; b=wiaghbCj6EjNfpxME2f7kuWv05gYDS1vHlzn0Y1JuEtmsg5IHK2Ac4+Qzhequ4mXEPMHYHe4tJgwpdD5558C9NJj2An67DI/ja2QpP7i/+i79efHSmgHm0cKLQh6QXYKGR8BG/uDaUQ6hRky/xjGfCuR6PiJK6Fy4Sh/J5yMZXY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:reply-to:organization:user-agent:mime-version:to:subject:x-enigmail-version:openpgp:content-type:from; b=j4KtEYea+8QnUW+KlpuhXloQt/mrmJ2wcg5aLJm4cSLKv78A2IQbK+2RSlWkbAthj0Qnh3bVt2O0PiXPxnsqj60sAfLoazbbLIj6uZpwWefEBLTHmywvWVhQ2dqZFpmK/VBVj/Eo0Jm1Q5a/2fgbeboPv0ET1QblUnYwIcXnYXs= Received: by 10.141.34.12 with SMTP id m12mr4431720rvj.26.1204114615871; Wed, 27 Feb 2008 04:16:55 -0800 (PST) Received: from island.freebsd.org ( [200.247.114.5]) by mx.google.com with ESMTPS id a29sm6213868qbd.4.2008.02.27.04.16.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 27 Feb 2008 04:16:55 -0800 (PST) Message-ID: <47C554AD.1000003@FreeBSD.org> Date: Wed, 27 Feb 2008 09:16:45 -0300 Organization: FreeBSD User-Agent: Thunderbird 2.0.0.0 (X11/20070521) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org X-Enigmail-Version: 0.95.0 OpenPGP: id=53E4CFA8 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8704A78EA8D56E8734692EC3" From: Marcelo Araujo Subject: [Fwd: Re: kern/121122: [ipfw] [patch] add support to ToS IP PRECEDENCE fields] X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: araujo@FreeBSD.org List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2008 12:16:57 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8704A78EA8D56E8734692EC3 Content-Type: multipart/mixed; boundary="------------060703040700030606030902" This is a multi-part message in MIME format. --------------060703040700030606030902 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Andrey V. Elsukov wrote: > Hi, Marcelo. > > I talked to Roman when he submitted his first patch about > it's design. What you think about making TOK_SETIPTOSPRE not > an action, but a modifier? I think it will be much usable. > A syntax example: > > # ipfw add allow iptospre flashover ip from any to any > # ipfw add count iptospre immediate ip from anyt to any > # ipfw add skipto .... > > Also I talked to Roman about extensible variant of this ability. > A syntax example: > > [{modip [DF|TOS|DSCP|TTL]}] > > Also look into: > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/102471 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/103454 > > I added to CC several men who are active in ipfw area. > It will be interested what you think about this? > Hi dear Andrey, I think about the TOK_SETIPTOSPRE as a modifier, that set the IP PRECEDENCE in the package. The second rule: # ipfw add count iptospre immediate ip from any to any Makes more sense for me, many users have ability to work with this synta= x. I believe be a good idea an extensible variant to apply and sort some QoS models in layer IP, as you showed. I've some time(5 months) to make my project degree[1] and apply my research within of IPFW. Yes, I've interest to work around this function, this work help me for my degree project. I think also this work is a good opportunity to work in SoC 2008. [1] http://code.google.com/p/exports/w/list Best Regards, --=20 Marcelo Araujo (__) araujo@FreeBSD.org \\\'',) http://www.FreeBSD.org \/ \ ^ Power To Server. .\. /_) --------------060703040700030606030902 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC43IChG cmVlQlNEKQoKaUQ4REJRRkh4VkZ5b3Z4SmQxUGt6NmdSQXZ1d0FKMFY5c2FYL3ZDb2duWjNI RWVvNFVuSWx3TjVaQUNlTzZJcApjZjBOclBKSXBkSTY3QWtVbmFHU3hMWT0KPU9ISzUKLS0t LS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tCgo= --------------060703040700030606030902-- --------------enig8704A78EA8D56E8734692EC3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHxVStovxJd1Pkz6gRAkvbAJ0a0CL/GMn/bBf+gMp7lKJyX3N7lQCfX0EY ItSqF44fJFQIRUcNboJSYGY= =7rxd -----END PGP SIGNATURE----- --------------enig8704A78EA8D56E8734692EC3-- From owner-freebsd-ipfw@FreeBSD.ORG Wed Feb 27 12:03:15 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A59151065678 for ; Wed, 27 Feb 2008 12:03:15 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by mx1.freebsd.org (Postfix) with ESMTP id 63AF38FC1A for ; Wed, 27 Feb 2008 12:03:15 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so4194611pyb.10 for ; Wed, 27 Feb 2008 04:03:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:reply-to:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:openpgp:content-type:from; bh=1uj3kh8IH/CcIEs+zGZV6FRAQBbb7S24qpDqCiW5TT8=; b=UwF2W1PnxaAev8Q89TKOLc3QIt2eZ5dns5bfAwDtD7tXcpM0gxI5mrp2vX1Zzgnry3M/4GRdKd1amAYMz1Acd4xbtU+Iwi1ey9SzpZrdv3PIZ+XFvarv+sa9mplJmVc4W4f6cq6FtWMU+ZVHwFEzHIQfqGOg6eWPc3iF3yfWtWg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:reply-to:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:openpgp:content-type:from; b=Clow3cTRjlPOLuiWQzS8qCCP7STo1oFcCoc/vBUCx9Va1lTDdMjeju5XevmcnJE7UYlqqTgniAFkeIXkD1DXgWpYeP4yPlIP9fEkOa6fCQY8mngls2Ayt6qBHH+1/RZ4t2S46ohm18D5FuVRsGt1VAClA2HYcWXJwgBQOibJCb8= Received: by 10.64.184.16 with SMTP id h16mr10002277qbf.45.1204113794104; Wed, 27 Feb 2008 04:03:14 -0800 (PST) Received: from island.freebsd.org ( [200.247.114.5]) by mx.google.com with ESMTPS id e13sm6233822qbe.31.2008.02.27.04.03.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 27 Feb 2008 04:03:13 -0800 (PST) Message-ID: <47C5516F.9080200@FreeBSD.org> Date: Wed, 27 Feb 2008 09:02:55 -0300 Organization: FreeBSD User-Agent: Thunderbird 2.0.0.0 (X11/20070521) MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <200802261908.m1QJ8n5N023371@freefall.freebsd.org> <47C4F2D1.5080703@yandex.ru> In-Reply-To: <47C4F2D1.5080703@yandex.ru> X-Enigmail-Version: 0.95.0 OpenPGP: id=53E4CFA8 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig29EB1FB0CCF16225C3E3EC6C" From: Marcelo Araujo X-Mailman-Approved-At: Wed, 27 Feb 2008 12:21:03 +0000 Cc: freebsd-bugs@FreeBSD.org, stas@mbsd.msk.ru, Luigi Rizzo , Roman Bogorodskiy , "Bruce M. Simpson" , freebsd-ipfw@FreeBSD.org, Julian Elischer , Ion-Mihai Tetcu , Oleg Bulyzhin , Vadim Goncharov Subject: Re: kern/121122: [ipfw] [patch] add support to ToS IP PRECEDENCE fields X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: araujo@FreeBSD.org List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2008 12:03:15 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig29EB1FB0CCF16225C3E3EC6C Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Andrey V. Elsukov wrote: > Hi, Marcelo. > > I talked to Roman when he submitted his first patch about > it's design. What you think about making TOK_SETIPTOSPRE not > an action, but a modifier? I think it will be much usable. > A syntax example: > > # ipfw add allow iptospre flashover ip from any to any > # ipfw add count iptospre immediate ip from anyt to any > # ipfw add skipto .... > > Also I talked to Roman about extensible variant of this ability. > A syntax example: > > [{modip [DF|TOS|DSCP|TTL]}] > > Also look into: > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/102471 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/103454 > > I added to CC several men who are active in ipfw area. > It will be interested what you think about this? > Hi dear Andrey, I think about the TOK_SETIPTOSPRE as a modifier, that set the IP PRECEDENCE in the package. The second rule: # ipfw add count iptospre immediate ip from any to any Makes more sense for me, many users have ability to work with this synta= x. I believe be a good idea an extensible variant to apply and sort some QoS models in layer IP, as you showed. I've some time(5 months) to make my project degree[1] and apply my research within of IPFW. Yes, I've interest to work around this function, this work help me for my degree project. I think also this work is a good opportunity to work in SoC 2008. [1] http://code.google.com/p/exports/w/list Best Regards, --=20 Marcelo Araujo (__) araujo@FreeBSD.org \\\'',) http://www.FreeBSD.org \/ \ ^ Power To Server. .\. /_) --------------enig29EB1FB0CCF16225C3E3EC6C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHxVFyovxJd1Pkz6gRAvuwAJ0V9saX/vCognZ3HEeo4UnIlwN5ZACeO6Ip cf0NrPJIpdI67AkUnaGSxLY= =OHK5 -----END PGP SIGNATURE----- --------------enig29EB1FB0CCF16225C3E3EC6C-- From owner-freebsd-ipfw@FreeBSD.ORG Wed Feb 27 14:36:47 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9BD91065673 for ; Wed, 27 Feb 2008 14:36:47 +0000 (UTC) (envelope-from vadim_nuclight@mail.ru) Received: from mx40.mail.ru (mx40.mail.ru [194.67.23.36]) by mx1.freebsd.org (Postfix) with ESMTP id 3C3D48FC28 for ; Wed, 27 Feb 2008 14:36:47 +0000 (UTC) (envelope-from vadim_nuclight@mail.ru) Received: from [78.140.3.71] (port=19605 helo=nuclight.avtf.net) by mx40.mail.ru with esmtp id 1JUNOn-000FP3-00; Wed, 27 Feb 2008 17:36:45 +0300 Date: Wed, 27 Feb 2008 20:36:41 +0600 To: "Andrey V. Elsukov" , araujo@freebsd.org References: <200802261908.m1QJ8n5N023371@freefall.freebsd.org> <47C4F2D1.5080703@yandex.ru> From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <47C4F2D1.5080703@yandex.ru> User-Agent: Opera M2/7.54 (Win32, build 3865) X-Spam: Not detected X-Mras: OK Cc: freebsd-bugs@freebsd.org, Luigi Rizzo , Roman Bogorodskiy , freebsd-ipfw@freebsd.org, Julian Elischer , Oleg Bulyzhin Subject: Re: kern/121122: [ipfw] [patch] add support to ToS IP PRECEDENCE fields X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2008 14:36:47 -0000 27.02.08 @ 11:19 Andrey V. Elsukov wrote: > I talked to Roman when he submitted his first patch about > it's design. What you think about making TOK_SETIPTOSPRE not > an action, but a modifier? I think it will be much usable. Agree. If it is more general ``modip'', one could wish to change more than one IP field in the same rule. > A syntax example: > > # ipfw add allow iptospre flashover ip from any to any > # ipfw add count iptospre immediate ip from any to any > # ipfw add skipto .... > > Also I talked to Roman about extensible variant of this ability. > A syntax example: > > [{modip [DF|TOS|DSCP|TTL]}] Yes, that's what's really needed - I've seen people asking for ability to change not only TOS (and more often DSCP), but TTL and DF bit. Moreover, I think all features from RFC 3168, RFC 2780 should be supported, including ECN bits (again in TOS byte). And, it must be consistent: all things you can set with this action you should be able to check in the options section. So that if user is able to match: ipfw add count ip from any to any iptos reliability,congestion then there must be possibility to write: ipfw add count modip tos reliability,congestion And vice versa, if one can able to modify a field: ipfw add count modip dscp af11 ip from any to any then he must be able to match it: ipfw add count ip from any to any dscp af11 Other consistency question - currently we have ``ipprecedence'' option which takes a numeric argument, and proposed patch uses symbolic names like ``flashover''. It may be desirable to allow both forms to be used in both TOS and DSCP fields (for both matching and setting), thus not limiting to predefined bit names. The other thing (apart from adding more ECN bits to the only one currently existing ``congestion'' in iptos) is TTL-setting ability to make it not only fixed, but relative also, like this for increment: ipfw add count modip ttl +1 ip from any to any It is questionable, though, will it be enough 16-bit single arg1 for O_MODIP ipfw_insn. May be it should be two, and be a structure allowing further extension (e.g. modifying any bytes, but that's far future)... P.S. One more stylish comment on the patch - constants for TOS should not be reinveneted, but taken where possible from system includes, e.g. IPTOS_* from in this case. -- WBR, Vadim Goncharov From owner-freebsd-ipfw@FreeBSD.ORG Thu Feb 28 05:50:57 2008 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3745106566B; Thu, 28 Feb 2008 05:50:57 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp8.yandex.ru (smtp8.yandex.ru [213.180.200.213]) by mx1.freebsd.org (Postfix) with ESMTP id C9AF48FC1B; Thu, 28 Feb 2008 05:50:55 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from ns.kirov.so-cdu.ru ([77.72.136.145]:49392 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S1802618AbYB1Fut (ORCPT + 6 others); Thu, 28 Feb 2008 08:50:49 +0300 X-Yandex-Spam: 1 X-Yandex-Front: smtp8 X-Yandex-TimeMark: 1204177849 X-MsgDayCount: 12 X-Comment: RFC 2476 MSA function at smtp8.yandex.ru logged sender identity as: bu7cher Message-ID: <47C64BB7.60309@yandex.ru> Date: Thu, 28 Feb 2008 08:50:47 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: araujo@FreeBSD.org References: <200802261908.m1QJ8n5N023371@freefall.freebsd.org> <47C4F2D1.5080703@yandex.ru> <47C5516F.9080200@FreeBSD.org> In-Reply-To: <47C5516F.9080200@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 28 Feb 2008 12:34:33 +0000 Cc: freebsd-bugs@FreeBSD.org, stas@mbsd.msk.ru, Luigi Rizzo , Roman Bogorodskiy , Oleg Bulyzhin , freebsd-ipfw@FreeBSD.org, Julian Elischer , Ion-Mihai Tetcu , "Bruce M. Simpson" , Vadim Goncharov Subject: Re: kern/121122: [ipfw] [patch] add support to ToS IP PRECEDENCE fields X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2008 05:50:58 -0000 Marcelo Araujo wrote: > Yes, I've interest to work around this function, this work help me for > my degree project. > I think also this work is a good opportunity to work in SoC 2008. I think this work is too easy for the SoC'08 :) -- WBR, Andrey V. Elsukov From owner-freebsd-ipfw@FreeBSD.ORG Thu Feb 28 10:28:38 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6F59106567A for ; Thu, 28 Feb 2008 10:28:38 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.228]) by mx1.freebsd.org (Postfix) with ESMTP id 5B2F58FC1A for ; Thu, 28 Feb 2008 10:28:37 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so3619727wxd.7 for ; Thu, 28 Feb 2008 02:28:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:reply-to:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:openpgp:content-type:from; bh=P7tmiRSkpt2Py7f39oiZZmPFFg1YtNtGnOcS5OjusDw=; b=t0sa78jmTGyjgXqMH67/DNp0scnb3reSrt6r010SNhyDezicrToxG5ZtXFFYAjcPs6dr1/Mliso9w/9B/O75z4TJSjDMtwBEx7WTI1fuUm8fjpw89hBQQq44X7aYBK+69p8fYlEyx/IL4ztQU7hISCDdDTA3jKaxNPPvCLi8FPw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:reply-to:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:openpgp:content-type:from; b=NRgoMKhOvTpOVnbcDjIsBBayrUMVjLAc0IFrwS5hvM9IZM6KrpJFLbD3AKDIKw1XFSwGhWs0O9laT0zPoejy00pXrGHXSS5hm7oKBWhpEsLDKzhkjHWjHgkLg6wa3stVqxs6QsMw6ulN6fp6l3ilL1m5HyEN1HIRJ/DCyffkAJw= Received: by 10.100.165.13 with SMTP id n13mr15139834ane.77.1204194517275; Thu, 28 Feb 2008 02:28:37 -0800 (PST) Received: from island.freebsd.org ( [200.247.114.5]) by mx.google.com with ESMTPS id 13sm8200467wrl.39.2008.02.28.02.28.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 28 Feb 2008 02:28:36 -0800 (PST) Message-ID: <47C68CD1.10409@FreeBSD.org> Date: Thu, 28 Feb 2008 07:28:33 -0300 Organization: FreeBSD User-Agent: Thunderbird 2.0.0.0 (X11/20070521) MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <200802261908.m1QJ8n5N023371@freefall.freebsd.org> <47C4F2D1.5080703@yandex.ru> <47C5516F.9080200@FreeBSD.org> <47C64BB7.60309@yandex.ru> In-Reply-To: <47C64BB7.60309@yandex.ru> X-Enigmail-Version: 0.95.0 OpenPGP: id=53E4CFA8 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1C9C80FDBF7F55BB6F2D7B2D" From: Marcelo Araujo X-Mailman-Approved-At: Thu, 28 Feb 2008 12:34:42 +0000 Cc: freebsd-bugs@FreeBSD.org, stas@mbsd.msk.ru, Luigi Rizzo , Roman Bogorodskiy , Oleg Bulyzhin , freebsd-ipfw@FreeBSD.org, Julian Elischer , Ion-Mihai Tetcu , "Bruce M. Simpson" , Vadim Goncharov Subject: Re: kern/121122: [ipfw] [patch] add support to ToS IP PRECEDENCE fields X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: araujo@FreeBSD.org List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2008 10:28:39 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1C9C80FDBF7F55BB6F2D7B2D Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Andrey V. Elsukov wrote: > Marcelo Araujo wrote: >> Yes, I've interest to work around this function, this work help me for= >> my degree project. >> I think also this work is a good opportunity to work in SoC 2008. > > I think this work is too easy for the SoC'08 :) > Hi all, Well, yesterday I started this work(action: modip), however if anybody have another idea or suggestion about this concern, send me a mail. Best Regards, --=20 Marcelo Araujo (__) araujo@FreeBSD.org \\\'',) http://www.FreeBSD.org \/ \ ^ Power To Server. .\. /_) --------------enig1C9C80FDBF7F55BB6F2D7B2D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHxozVovxJd1Pkz6gRAgvtAJ9Y2YVswTJ37O+rFBWVYKDahvXvmACePRyk vpV7pHaVu4Y927R59p721J0= =kcuL -----END PGP SIGNATURE----- --------------enig1C9C80FDBF7F55BB6F2D7B2D-- From owner-freebsd-ipfw@FreeBSD.ORG Thu Feb 28 15:33:31 2008 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA3BE1065671 for ; Thu, 28 Feb 2008 15:33:31 +0000 (UTC) (envelope-from piso@southcross.wired.org) Received: from mail.oltrelinux.com (krisma.oltrelinux.com [194.242.226.43]) by mx1.freebsd.org (Postfix) with ESMTP id 711408FC1A for ; Thu, 28 Feb 2008 15:33:31 +0000 (UTC) (envelope-from piso@southcross.wired.org) Received: from southcross.wired.org (host-84-221-97-132.cust-adsl.tiscali.it [84.221.97.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.oltrelinux.com (Postfix) with ESMTP id 994B711AE80 for ; Thu, 28 Feb 2008 16:08:47 +0100 (CET) Received: (from piso@localhost) by southcross.wired.org (8.14.2/8.14.1/Submit) id m1SFBZUR073409 for freebsd-ipfw@FreeBSD.org; Thu, 28 Feb 2008 16:11:35 +0100 (CET) (envelope-from piso) Date: Thu, 28 Feb 2008 16:11:34 +0100 From: Paolo Pisati To: freebsd-ipfw@FreeBSD.org Message-ID: <20080228151134.GA73358@tin.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at krisma.oltrelinux.com Cc: Subject: [patch] ipfw_nat as a kld module X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2008 15:33:31 -0000 Here is the patch against HEAD: http://people.freebsd.org/~piso/ipfw_nat_module.patch Any objection if i commit it? bye, P. From owner-freebsd-ipfw@FreeBSD.ORG Fri Feb 29 06:05:07 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C97AD1065676 for ; Fri, 29 Feb 2008 06:05:07 +0000 (UTC) (envelope-from freebsd-ipfw@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 80A9D8FC22 for ; Fri, 29 Feb 2008 06:05:07 +0000 (UTC) (envelope-from freebsd-ipfw@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1JUxte-0000A9-8I for freebsd-ipfw@freebsd.org; Fri, 29 Feb 2008 05:35:02 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Feb 2008 05:35:02 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Feb 2008 05:35:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-ipfw@freebsd.org From: Vadim Goncharov Date: Fri, 29 Feb 2008 05:21:35 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 30 Message-ID: References: <20080228151134.GA73358@tin.it> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: Paolo Pisati User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Subject: Re: [patch] ipfw_nat as a kld module X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Feb 2008 06:05:07 -0000 Hi Paolo Pisati! On Thu, 28 Feb 2008 16:11:34 +0100; Paolo Pisati wrote about '[patch] ipfw_nat as a kld module': > http://people.freebsd.org/~piso/ipfw_nat_module.patch > Any objection if i commit it? Some comments: * //comments are not in out style(9) * IPFW_NAT_LOADED - again style(9), CAPSLOCK is used for constants * lookup_nat() duplication - it is short, may be turn to #define macro in .h? * struct ip_fw_chain moved to .h and no longer static, is this good? I suggest to move into it's own static chain in module, see next * Instead of returning IP_FW_NAT function is called immediately from ipfw_chk(). This inconsistent with other modules of this sort, like divert and dummynet, where ipfw_chk() simply returns value and cookie to ipfw_check_*() functions in _pfil.c. If it is done like that, ip_fw2.c is dependent on modules in minimal way, as many of structures and code as possible should be moved to modules. This allows to change module without recompiling main ipfw - for example, your lookup_nat() and LIST_HEAD from ip_fw_chain could reside entirely in module - then it would be possible to easily switch from LIST to hash of some kind (imagine 500 NAT instances). And so on. Maybe I missed some points as I was looking briefly... -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-ipfw@FreeBSD.ORG Fri Feb 29 07:49:24 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 059F3106569B for ; Fri, 29 Feb 2008 07:49:24 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outN.internet-mail-service.net (outN.internet-mail-service.net [216.240.47.237]) by mx1.freebsd.org (Postfix) with ESMTP id D88978FC14 for ; Fri, 29 Feb 2008 07:49:23 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Thu, 28 Feb 2008 23:49:22 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id D1CD62D6010; Thu, 28 Feb 2008 23:49:21 -0800 (PST) Message-ID: <47C7B913.5000405@elischer.org> Date: Thu, 28 Feb 2008 23:49:39 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: vadim_nuclight@mail.ru References: <20080228151134.GA73358@tin.it> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org Subject: Re: [patch] ipfw_nat as a kld module X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Feb 2008 07:49:24 -0000 Vadim Goncharov wrote: > Hi Paolo Pisati! > > On Thu, 28 Feb 2008 16:11:34 +0100; Paolo Pisati wrote about '[patch] ipfw_nat as a kld module': > >> http://people.freebsd.org/~piso/ipfw_nat_module.patch >> Any objection if i commit it? > > Some comments: > > * //comments are not in out style(9) in case this is cryptic to you.. do "man 9 style" > * IPFW_NAT_LOADED - again style(9), CAPSLOCK is used for constants > * lookup_nat() duplication - it is short, may be turn to #define macro in .h? > * struct ip_fw_chain moved to .h and no longer static, is this good? > I suggest to move into it's own static chain in module, see next > * Instead of returning IP_FW_NAT function is called immediately from > ipfw_chk(). This inconsistent with other modules of this sort, like divert > and dummynet, where ipfw_chk() simply returns value and cookie to > ipfw_check_*() functions in _pfil.c. If it is done like that, ip_fw2.c > is dependent on modules in minimal way, as many of structures and code > as possible should be moved to modules. This allows to change module > without recompiling main ipfw - for example, your lookup_nat() and > LIST_HEAD from ip_fw_chain could reside entirely in module - then it would > be possible to easily switch from LIST to hash of some kind (imagine 500 > NAT instances). And so on. > > Maybe I missed some points as I was looking briefly... > From owner-freebsd-ipfw@FreeBSD.ORG Fri Feb 29 09:49:03 2008 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0804106566C for ; Fri, 29 Feb 2008 09:49:03 +0000 (UTC) (envelope-from piso@southcross.wired.org) Received: from mail.oltrelinux.com (krisma.oltrelinux.com [194.242.226.43]) by mx1.freebsd.org (Postfix) with ESMTP id 992358FC16 for ; Fri, 29 Feb 2008 09:49:03 +0000 (UTC) (envelope-from piso@southcross.wired.org) Received: from southcross.wired.org (host-62-10-20-127.cust-adsl.tiscali.it [62.10.20.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.oltrelinux.com (Postfix) with ESMTP id 1BB7411AE87; Fri, 29 Feb 2008 10:48:56 +0100 (CET) Received: (from piso@localhost) by southcross.wired.org (8.14.2/8.14.1/Submit) id m1T9po74079745; Fri, 29 Feb 2008 10:51:51 +0100 (CET) (envelope-from piso) Date: Fri, 29 Feb 2008 10:51:50 +0100 From: Paolo Pisati To: Vadim Goncharov Message-ID: <20080229095150.GA76592@tin.it> References: <20080228151134.GA73358@tin.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at krisma.oltrelinux.com Cc: freebsd-ipfw@FreeBSD.org Subject: Re: [patch] ipfw_nat as a kld module X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Feb 2008 09:49:04 -0000 On Fri, Feb 29, 2008 at 05:21:35AM +0000, Vadim Goncharov wrote: > Hi Paolo Pisati! > > On Thu, 28 Feb 2008 16:11:34 +0100; Paolo Pisati wrote about '[patch] ipfw_nat as a kld module': > > > http://people.freebsd.org/~piso/ipfw_nat_module.patch > > Any objection if i commit it? > > Some comments: > > * //comments are not in out style(9) yes, i left some stuff around... :P > * IPFW_NAT_LOADED - again style(9), CAPSLOCK is used for constants and macros... > * lookup_nat() duplication - it is short, may be turn to #define macro in .h? that's doable > * struct ip_fw_chain moved to .h and no longer static, is this good? > I suggest to move into it's own static chain in module, see next the symbol is used outside it's originating file > * Instead of returning IP_FW_NAT function is called immediately from > ipfw_chk(). This inconsistent with other modules of this sort, like divert > and dummynet, where ipfw_chk() simply returns value and cookie to > ipfw_check_*() functions in _pfil.c. If it is done like that, ip_fw2.c > is dependent on modules in minimal way, as many of structures and code > as possible should be moved to modules. This allows to change module > without recompiling main ipfw - for example, your lookup_nat() and > LIST_HEAD from ip_fw_chain could reside entirely in module - then it would > be possible to easily switch from LIST to hash of some kind (imagine 500 > NAT instances). And so on. that's something i thought about, but i didn't see any tangible improvement to this modification, cause part of ipfw_nat would still be called from ipfw2.c (see ipfw_ctl). Anyway, i'll fix a couple of nits and commit as it is. bye, P. From owner-freebsd-ipfw@FreeBSD.ORG Fri Feb 29 10:37:30 2008 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B09AC1065671; Fri, 29 Feb 2008 10:37:30 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6527B8FC23; Fri, 29 Feb 2008 10:37:29 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47C7E068.5040208@FreeBSD.org> Date: Fri, 29 Feb 2008 11:37:28 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: matthew , freebsd-net@freebsd.org, freebsd-ipfw@FreeBSD.org References: <47C5753A.8010806@matthew.sk> <47C57D01.8070007@FreeBSD.org> <47C7BB11.9020604@matthew.sk> In-Reply-To: <47C7BB11.9020604@matthew.sk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Lock order reversals with dummynet (Re: FreeBSD 7.0 Beta, RC, RELEASE (amd64) freezes with dummynet enabled) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Feb 2008 10:37:30 -0000 Adding back the mailing list so others can help. matthew wrote: > Kris Kennaway wrote: > >> matthew wrote: >>> I have posted before that i have a stability issue with the 7.0 branch >>> on my servers. Tested on BETA2,BETA4,RC1,RC2,RELEASE >>> >>> The original thread and my post with details is at: >>> http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2007-12/msg00674.html >>> >>> >>> I was waiting for the 7.0-RELEASE, updated the whole servers, and >>> enabled dummynet again, but it always freezes after some minutes, 100% >>> reproducible. >>> >>> I tested it also on a HP 140 G3 1U server, where 6.3 has absolutely no >>> problems, but the 7.0 branch keeps freezing. >>> >>> Again, if it helps to solve this bug, i can rebuild the kernel with >>> debug symbols a take some screenshots :) >> >> Please follow the steps at >> >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html >> >> >> Kris >> _______________________________________________ > I added to the kernel these options: > makeoptions DEBUG=-g # Build kernel with gdb(1) debug > symbols > options INVARIANTS > options INVARIANT_SUPPORT > options WITNESS > options DEBUG_LOCKS > options DEBUG_VFS_LOCKS > options DIAGNOSTIC > options KDB > options DDB > options GDB > options SOCKBUF_DEBUG > > But still, the server freezes withoutany debug message, And you can't break to DDB? It is expected you will have to when you encounter a deadlock. > panic whatever, > but at leasts it dumps the crash kernel to /var/crash, but the debug > looks like this: Dumping is an activity the occurs after panicking, so if you have a dump then you must have a panic. > root@hanka:/usr/src/sys/amd64/compile/HANKA-debug# kgdb kernel.debug > /var/crash/vmcore.0 > [GDB will not be able to debug user-mode threads: > /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you > are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd". > Cannot access memory at address 0x57 > (kgdb) backtrace > #0 0x0000000000000000 in ?? () > Cannot access memory at address 0x0 > (kgdb) > I have some debug messages at boot time: This usually means you are not running the dump against the kernel.debug corresponding exactly to the kernel that crashed. Probably the dump you found was old. > Feb 28 17:01:29 hanka lock order reversal: > Feb 28 17:01:29 hanka 1st 0xffffffff80b0e1e8 PFil hook read/write mutex > (PFil hook read/write mutex) @ net/pfil.c:73 > Feb 28 17:01:29 hanka 2nd 0xffffffff80b0f8e8 udp (udp) @ > /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:2970 > Feb 28 17:01:29 hanka KDB: stack backtrace: > Feb 28 17:01:29 hanka db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > Feb 28 17:01:29 hanka witness_checkorder() at witness_checkorder+0x605 > Feb 28 17:01:29 hanka _mtx_lock_flags() at _mtx_lock_flags+0x75 > Feb 28 17:01:29 hanka pf_socket_lookup() at pf_socket_lookup+0x241 > Feb 28 17:01:29 hanka pf_test_udp() at pf_test_udp+0x890 > Feb 28 17:01:29 hanka pf_test() at pf_test+0xeb2 > Feb 28 17:01:29 hanka pf_check_in() at pf_check_in+0x2b > Feb 28 17:01:29 hanka pfil_run_hooks() at pfil_run_hooks+0xbc > Feb 28 17:01:29 hanka ip_input() at ip_input+0x2c4 > Feb 28 17:01:29 hanka ether_demux() at ether_demux+0x1d9 > Feb 28 17:01:29 hanka ether_input() at ether_input+0x19d > Feb 28 17:01:29 hanka ether_demux() at ether_demux+0xe9 > Feb 28 17:01:29 hanka ether_input() at ether_input+0x19d > Feb 28 17:01:29 hanka em_rxeof() at em_rxeof+0x1ca > Feb 28 17:01:29 hanka em_poll() at em_poll+0x6f > Feb 28 17:01:29 hanka netisr_poll() at netisr_poll+0x87 > Feb 28 17:01:29 hanka swi_net() at swi_net+0xea > Feb 28 17:01:29 hanka ithread_loop() at ithread_loop+0xda > Feb 28 17:01:29 hanka fork_exit() at fork_exit+0x12a > Feb 28 17:01:29 hanka fork_trampoline() at fork_trampoline+0xe > Feb 28 17:01:29 hanka --- trap 0, rip = 0, rsp = 0xffffffff9feead30, rbp > = 0 --- > Feb 28 17:01:29 hanka lock order reversal: > Feb 28 17:01:29 hanka 1st 0xffffff0001237430 em0 (EM Core Lock) @ > dev/em/if_em.c:1416 > Feb 28 17:01:29 hanka 2nd 0xffffffff80b0f8e8 udp (udp) @ > netinet/udp_usrreq.c:385 > Feb 28 17:01:29 hanka KDB: stack backtrace: > Feb 28 17:01:29 hanka db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > Feb 28 17:01:29 hanka witness_checkorder() at witness_checkorder+0x605 > Feb 28 17:01:29 hanka _mtx_lock_flags() at _mtx_lock_flags+0x75 > Feb 28 17:01:29 hanka udp_input() at udp_input+0x1a4 > Feb 28 17:01:29 hanka ip_input() at ip_input+0xc0 > Feb 28 17:01:29 hanka ether_demux() at ether_demux+0x1d9 > Feb 28 17:01:29 hanka ether_input() at ether_input+0x19d > Feb 28 17:01:29 hanka ether_demux() at ether_demux+0xe9 > Feb 28 17:01:29 hanka ether_input() at ether_input+0x19d > Feb 28 17:01:29 hanka em_rxeof() at em_rxeof+0x1ca > Feb 28 17:01:29 hanka em_poll() at em_poll+0x6f > Feb 28 17:01:29 hanka netisr_poll() at netisr_poll+0x87 > Feb 28 17:01:29 hanka swi_net() at swi_net+0xea > Feb 28 17:01:29 hanka ithread_loop() at ithread_loop+0xda > Feb 28 17:01:29 hanka fork_exit() at fork_exit+0x12a > Feb 28 17:01:29 hanka fork_trampoline() at fork_trampoline+0xe > Feb 28 17:01:29 hanka --- trap 0, rip = 0, rsp = 0xffffffff9feead30, rbp > = 0 --- > Feb 28 17:01:29 hanka xinetd[1356]: xinetd Version 2.3.14 started with > libwrap loadavg options compiled in. > Feb 28 17:01:29 hanka xinetd[1356]: Started working: 1 available service > Feb 28 17:01:33 hanka lock order reversal: > Feb 28 17:01:33 hanka 1st 0xffffff00042f5b10 inp (tcpinp) @ > netinet/tcp_usrreq.c:781 > Feb 28 17:01:33 hanka 2nd 0xffffffff80b0e1e8 PFil hook read/write mutex > (PFil hook read/write mutex) @ net/pfil.c:73 > Feb 28 17:01:33 hanka KDB: stack backtrace: > Feb 28 17:01:33 hanka db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > Feb 28 17:01:33 hanka witness_checkorder() at witness_checkorder+0x605 > Feb 28 17:01:33 hanka _rw_rlock() at _rw_rlock+0x5b > Feb 28 17:01:33 hanka pfil_run_hooks() at pfil_run_hooks+0x44 > Feb 28 17:01:33 hanka ip_output() at ip_output+0x38e > Feb 28 17:01:33 hanka tcp_output() at tcp_output+0xacd > Feb 28 17:01:33 hanka tcp_usr_send() at tcp_usr_send+0x272 > Feb 28 17:01:33 hanka sosend_generic() at sosend_generic+0x347 > Feb 28 17:01:33 hanka soo_write() at soo_write+0x38 > Feb 28 17:01:33 hanka dofilewrite() at dofilewrite+0x85 > Feb 28 17:01:33 hanka kern_writev() at > Feb 28 17:01:33 hanka kern_writev+0x4c > Feb 28 17:01:33 hanka write() at write+0x54 > Feb 28 17:01:33 hanka syscall() at syscall+0x1f6 > Feb 28 17:01:33 hanka Xfast_syscall() at Xfast_syscall+0xab > Feb 28 17:01:33 hanka --- syscall (4, FreeBSD ELF64, write), rip = > 0x800e1fd3c, rsp = 0x7fffffffea88, rbp = 0x16 --- > Feb 28 17:03:54 hanka lock order reversal: > Feb 28 17:03:54 hanka 1st 0xffffffff80b0f308 tcp (tcp) @ > netinet/tcp_input.c:400 > Feb 28 17:03:54 hanka 2nd 0xffffffff80b0e1e8 PFil hook read/write mutex > (PFil hook read/write mutex) @ net/pfil.c:73 > Feb 28 17:03:54 hanka KDB: stack backtrace: > Feb 28 17:03:54 hanka db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > Feb 28 17:03:54 hanka witness_checkorder() at witness_checkorder+0x605 > Feb 28 17:03:54 hanka _rw_rlock() at _rw_rlock+0x5b > Feb 28 17:03:54 hanka pfil_run_hooks() at pfil_run_hooks+0x44 > Feb 28 17:03:54 hanka ip_output() at ip_output+0x38e > Feb 28 17:03:54 hanka tcp_respond() at tcp_respond+0x2d5 > Feb 28 17:03:54 hanka tcp_dropwithreset() at tcp_dropwithreset+0x131 > Feb 28 17:03:54 hanka tcp_input() at tcp_input+0x6d0 > Feb 28 17:03:54 hanka ip_input() at ip_input+0xc0 > Feb 28 17:03:54 hanka ether_demux() at ether_demux+0x1d9 > Feb 28 17:03:54 hanka ether_input() at ether_input+0x19d > Feb 28 17:03:54 hanka em_rxeof() at em_rxeof+0x1ca > Feb 28 17:03:54 hanka em_poll() at em_poll+0x6f > Feb 28 17:03:54 hanka netisr_poll() at netisr_poll+0x87 > Feb 28 17:03:54 hanka swi_net() at swi_net+0xea > Feb 28 17:03:54 hanka ithread_loop() at ithread_loop+0xda > Feb 28 17:03:54 hanka fork_exit() at fork_exit+0x12a > Feb 28 17:03:54 hanka fork_trampoline() at fork_trampoline+0xe > Feb 28 17:03:54 hanka --- trap 0, rip = 0, rsp = 0xffffffff9feead30, rbp > = 0 --- > Feb 28 17:23:36 hanka lock order reversal: > Feb 28 17:23:36 hanka 1st 0xffffffff810f9ef0 tcp_sc_head (tcp_sc_head) @ > netinet/tcp_syncache.c:477 > Feb 28 17:23:36 hanka 2nd 0xffffffff80b0e1e8 PFil hook read/write mutex > (PFil hook read/write mutex) @ net/pfil.c:73 > Feb 28 17:23:36 hanka KDB: stack backtrace: > Feb 28 17:23:36 hanka db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > Feb 28 17:23:36 hanka witness_checkorder() at witness_checkorder+0x605 > Feb 28 17:23:36 hanka _rw_rlock() at _rw_rlock+0x5b > Feb 28 17:23:36 hanka pfil_run_hooks() at pfil_run_hooks+0x44 > Feb 28 17:23:36 hanka ip_output() at ip_output+0x38e > Feb 28 17:23:36 hanka syncache_respond() at syncache_respond+0x32a > Feb 28 17:23:36 hanka syncache_add() at syncache_add+0x206 > Feb 28 17:23:36 hanka tcp_input() at tcp_input+0xa77 > Feb 28 17:23:36 hanka ip_input() at ip_input+0xc0 > Feb 28 17:23:36 hanka ether_demux() at ether_demux+0x1d9 > Feb 28 17:23:36 hanka ether_input() at ether_input+0x19d > Feb 28 17:23:36 hanka em_rxeof() at em_rxeof+0x1ca > Feb 28 17:23:36 hanka em_poll() at em_poll+0x6f > Feb 28 17:23:36 hanka netisr_poll() at netisr_poll+0x87 > Feb 28 17:23:36 hanka swi_net() at swi_net+0xea > Feb 28 17:23:36 hanka ithread_loop() at ithread_loop+0xda > Feb 28 17:23:36 hanka fork_exit() at fork_exit+0x12a > Feb 28 17:23:36 hanka fork_trampoline() at fork_trampoline+0xe > Feb 28 17:23:36 hanka --- trap 0, rip = 0, rsp = 0xffffffff9feead30, rbp > = 0 --- These look useful and should point to the problem. It is also probably related to something in your script: > I tried it with pf disabled, only running ipfw without dummynet, > everything is ok. > I tried it witout pf disabled, running ipfw with dummynet queue for > small traffic, everything is ok. > I tried it with/without pf disabled, running ipfw with dummynet queue > for hight traffic >100Mbit/s, the box freezes, everytime, after enabling > rules with the dummynet queue, after some second or few minutes, maybe > depending on the high traffic. > > The shaper script: > # SHAPER > IPFW_PIPE_DOWNLOAD=1 > IPFW_PIPE_UPLOAD=11 > IPFW_QUEUE_DOWNLOAD=1 > IPFW_QUEUE_UPLOAD=11 > > DOWNLOAD_ROOT="450Mbit/s" > UPLOAD_ROOT="450Mbit/s" > SHAPER_BUCKETS="1024" > > IPFW_SHAPER_ROOT=1000 > > $CMD pipe $IPFW_PIPE_DOWNLOAD config bw $DOWNLOAD_ROOT buckets > $SHAPER_BUCKETS > $CMD pipe $IPFW_PIPE_UPLOAD config bw $UPLOAD_ROOT buckets $SHAPER_BUCKETS > > $CMD queue $IPFW_QUEUE_DOWNLOAD config pipe $IPFW_PIPE_DOWNLOAD buckets > $SHAPER_BUCKETS mask dst-ip 0xFFFFFFFF > $CMD queue $IPFW_QUEUE_UPLOAD config pipe $IPFW_PIPE_UPLOAD buckets > $SHAPER_BUCKETS mask src-ip 0xFFFFFFFF > > $CMD delete $IPFW_SHAPER_ROOT > $CMD $IPFW_SHAPER_ROOT add queue $IPFW_QUEUE_DOWNLOAD ip from me to any > out // Share download > $CMD $IPFW_SHAPER_ROOT add queue $IPFW_QUEUE_UPLOAD ip from any to me in > // Share upload Thanks for the information. Kris From owner-freebsd-ipfw@FreeBSD.ORG Fri Feb 29 11:56:18 2008 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3234E1065675 for ; Fri, 29 Feb 2008 11:56:18 +0000 (UTC) (envelope-from matthew@matthew.sk) Received: from mailserver.antik.sk (mailserver.antik.sk [88.212.10.6]) by mx1.freebsd.org (Postfix) with ESMTP id 2EBF18FC39 for ; Fri, 29 Feb 2008 11:56:16 +0000 (UTC) (envelope-from matthew@matthew.sk) Received: (qmail 1616 invoked from network); 29 Feb 2008 12:29:34 +0100 Received: by simscan 1.4.0 ppid: 1601, pid: 1611, t: 0.0308s scanners: regex: 1.4.0 attach: 1.4.0 clamav: 0.91.2/m:45/d:6030 Received: from unknown (HELO ?10.252.4.243?) (matthew@matthew.sk@10.252.4.243) by mailserver.antik.sk with AES256-SHA encrypted SMTP; 29 Feb 2008 12:29:34 +0100 Message-ID: <47C7EC9F.4070403@matthew.sk> Date: Fri, 29 Feb 2008 12:29:35 +0100 From: matthew User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080110) MIME-Version: 1.0 To: Kris Kennaway References: <47C5753A.8010806@matthew.sk> <47C57D01.8070007@FreeBSD.org> <47C7BB11.9020604@matthew.sk> <47C7E068.5040208@FreeBSD.org> In-Reply-To: <47C7E068.5040208@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-ipfw@FreeBSD.org Subject: Re: Lock order reversals with dummynet (Re: FreeBSD 7.0 Beta, RC, RELEASE (amd64) freezes with dummynet enabled) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Feb 2008 11:56:18 -0000 I have some more tests, but always the same. Here is the top output, that i see last on terminal: 65 processes: 4 running, 144 sleeping, 17 waiting CPU states: 0.0% user, 0.0% nice, 29.9% system, 7.8% interrupt, 62.3% idle Mem: 46M Active, 522M Inact, 350M Wired, 10M Cache, 109M Buf, 35M Free Swap: 2048M Total, 228K Used, 2048M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 12 root 1 171 ki31 0K 16K RUN 0 692:10 61.96% idle: cpu0 11 root 1 171 ki31 0K 16K RUN 1 804:37 51.51% idle: cpu1 13 root 1 -44 - 0K 16K WAIT 0 325:41 13.18% swi1: net 42 root 1 -68 - 0K 16K - 0 12:26 12.74% dummynet 72368 ftp 1 4 0 10832K 2080K RUN 0 4:05 10.01% vsftpd 74488 ftp 1 4 0 10832K 2080K zfs:(& 0 0:31 9.62% vsftpd 73690 ftp 1 8 0 10832K 2072K nanslp 0 1:43 8.64% vsftpd 74752 ftp 1 8 0 10832K 2068K nanslp 1 0:09 6.06% vsftpd 74811 ftp 1 8 0 10832K 2072K nanslp 1 0:03 3.79% vsftpd 74869 ftp 1 4 0 10832K 2056K sbwait 1 0:00 3.39% vsftpd As you can see, there is no high load, enought free memory and CPUs are relative idle. This is the output from nload -o 250000: Device em0 [10.252.2.3] (1/1): ============================================================================================================================================ Incoming: .. .| .|. . .. . ||...|.... .........| . . .. Curr: 2519.37 kBit/s ####|||######.###################### ############... ..... ..||... .|. ##|#|####. Avg: 2831.76 kBit/s ####################################|# .. |. | ######################|#######||############## Min: 141.74 kBit/s #########################################.##.#|############################################## Max: 6586.57 kBit/s ############################################################################################# Ttl: 542932224.00 MByte Outgoing: . .. # .. . . ##.. .... . . # . # .# ## ## ### # .##.|| #########|| |###|#####.. |#.#.#|## ####||.######.###################### ############... | . ..# .| |. #########. #################################### ###############.####|# ####|## ###|########## ####################################.# . . ##############################||############## ###################################### || ## # ############################################## Curr: 127802.60 kBit/s ######################################|## ## #|############################################## Avg: 144300.05 kBit/s #########################################|################################################### Min: 3339.92 kBit/s ############################################################################################# Max: 292397.75 kBit/s ############################################################################################# Ttl: 14977425408.00 MByte There is no rapid change of bw or anything. Kris Kennaway wrote: > Adding back the mailing list so others can help. > > matthew wrote: >> Kris Kennaway wrote: >> >>> matthew wrote: >>>> I have posted before that i have a stability issue with the 7.0 branch >>>> on my servers. Tested on BETA2,BETA4,RC1,RC2,RELEASE >>>> >>>> The original thread and my post with details is at: >>>> http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2007-12/msg00674.html >>>> >>>> >>>> I was waiting for the 7.0-RELEASE, updated the whole servers, and >>>> enabled dummynet again, but it always freezes after some minutes, 100% >>>> reproducible. >>>> >>>> I tested it also on a HP 140 G3 1U server, where 6.3 has absolutely no >>>> problems, but the 7.0 branch keeps freezing. >>>> >>>> Again, if it helps to solve this bug, i can rebuild the kernel with >>>> debug symbols a take some screenshots :) >>> >>> Please follow the steps at >>> >>> http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html >>> >>> >>> Kris >>> _______________________________________________ >> I added to the kernel these options: >> makeoptions DEBUG=-g # Build kernel with gdb(1) >> debug symbols >> options INVARIANTS >> options INVARIANT_SUPPORT >> options WITNESS >> options DEBUG_LOCKS >> options DEBUG_VFS_LOCKS >> options DIAGNOSTIC >> options KDB >> options DDB >> options GDB >> options SOCKBUF_DEBUG >> >> But still, the server freezes withoutany debug message, > > And you can't break to DDB? It is expected you will have to when you > encounter a deadlock. No, i am unable to do anything, no input from keyboard, the only one thing thats work, is to change the num lock indicator on the keyboard :) > > > panic whatever, >> but at leasts it dumps the crash kernel to /var/crash, but the debug >> looks like this: > > Dumping is an activity the occurs after panicking, so if you have a > dump then you must have a panic. >> root@hanka:/usr/src/sys/amd64/compile/HANKA-debug# kgdb kernel.debug >> /var/crash/vmcore.0 >> [GDB will not be able to debug user-mode threads: >> /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] >> GNU gdb 6.1.1 [FreeBSD] >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and >> you are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for >> details. >> This GDB was configured as "amd64-marcel-freebsd". >> Cannot access memory at address 0x57 >> (kgdb) backtrace >> #0 0x0000000000000000 in ?? () >> Cannot access memory at address 0x0 >> (kgdb) I have some debug messages >> at boot time: > > This usually means you are not running the dump against the > kernel.debug corresponding exactly to the kernel that crashed. > Probably the dump you found was old. > Yes, i think it is possible that it is the previous kernel, without the debug options. >> Feb 28 17:01:29 hanka lock order reversal: >> Feb 28 17:01:29 hanka 1st 0xffffffff80b0e1e8 PFil hook read/write >> mutex (PFil hook read/write mutex) @ net/pfil.c:73 >> Feb 28 17:01:29 hanka 2nd 0xffffffff80b0f8e8 udp (udp) @ >> /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:2970 >> Feb 28 17:01:29 hanka KDB: stack backtrace: >> Feb 28 17:01:29 hanka db_trace_self_wrapper() at >> db_trace_self_wrapper+0x2a >> Feb 28 17:01:29 hanka witness_checkorder() at witness_checkorder+0x605 >> Feb 28 17:01:29 hanka _mtx_lock_flags() at _mtx_lock_flags+0x75 >> Feb 28 17:01:29 hanka pf_socket_lookup() at pf_socket_lookup+0x241 >> Feb 28 17:01:29 hanka pf_test_udp() at pf_test_udp+0x890 >> Feb 28 17:01:29 hanka pf_test() at pf_test+0xeb2 >> Feb 28 17:01:29 hanka pf_check_in() at pf_check_in+0x2b >> Feb 28 17:01:29 hanka pfil_run_hooks() at pfil_run_hooks+0xbc >> Feb 28 17:01:29 hanka ip_input() at ip_input+0x2c4 >> Feb 28 17:01:29 hanka ether_demux() at ether_demux+0x1d9 >> Feb 28 17:01:29 hanka ether_input() at ether_input+0x19d >> Feb 28 17:01:29 hanka ether_demux() at ether_demux+0xe9 >> Feb 28 17:01:29 hanka ether_input() at ether_input+0x19d >> Feb 28 17:01:29 hanka em_rxeof() at em_rxeof+0x1ca >> Feb 28 17:01:29 hanka em_poll() at em_poll+0x6f >> Feb 28 17:01:29 hanka netisr_poll() at netisr_poll+0x87 >> Feb 28 17:01:29 hanka swi_net() at swi_net+0xea >> Feb 28 17:01:29 hanka ithread_loop() at ithread_loop+0xda >> Feb 28 17:01:29 hanka fork_exit() at fork_exit+0x12a >> Feb 28 17:01:29 hanka fork_trampoline() at fork_trampoline+0xe >> Feb 28 17:01:29 hanka --- trap 0, rip = 0, rsp = 0xffffffff9feead30, >> rbp = 0 --- > > >> Feb 28 17:01:29 hanka lock order reversal: >> Feb 28 17:01:29 hanka 1st 0xffffff0001237430 em0 (EM Core Lock) @ >> dev/em/if_em.c:1416 >> Feb 28 17:01:29 hanka 2nd 0xffffffff80b0f8e8 udp (udp) @ >> netinet/udp_usrreq.c:385 >> Feb 28 17:01:29 hanka KDB: stack backtrace: >> Feb 28 17:01:29 hanka db_trace_self_wrapper() at >> db_trace_self_wrapper+0x2a >> Feb 28 17:01:29 hanka witness_checkorder() at witness_checkorder+0x605 >> Feb 28 17:01:29 hanka _mtx_lock_flags() at _mtx_lock_flags+0x75 >> Feb 28 17:01:29 hanka udp_input() at udp_input+0x1a4 >> Feb 28 17:01:29 hanka ip_input() at ip_input+0xc0 >> Feb 28 17:01:29 hanka ether_demux() at ether_demux+0x1d9 >> Feb 28 17:01:29 hanka ether_input() at ether_input+0x19d >> Feb 28 17:01:29 hanka ether_demux() at ether_demux+0xe9 >> Feb 28 17:01:29 hanka ether_input() at ether_input+0x19d >> Feb 28 17:01:29 hanka em_rxeof() at em_rxeof+0x1ca >> Feb 28 17:01:29 hanka em_poll() at em_poll+0x6f >> Feb 28 17:01:29 hanka netisr_poll() at netisr_poll+0x87 >> Feb 28 17:01:29 hanka swi_net() at swi_net+0xea >> Feb 28 17:01:29 hanka ithread_loop() at ithread_loop+0xda >> Feb 28 17:01:29 hanka fork_exit() at fork_exit+0x12a >> Feb 28 17:01:29 hanka fork_trampoline() at fork_trampoline+0xe >> Feb 28 17:01:29 hanka --- trap 0, rip = 0, rsp = 0xffffffff9feead30, >> rbp = 0 --- > > >> Feb 28 17:01:29 hanka xinetd[1356]: xinetd Version 2.3.14 started >> with libwrap loadavg options compiled in. >> Feb 28 17:01:29 hanka xinetd[1356]: Started working: 1 available service >> Feb 28 17:01:33 hanka lock order reversal: >> Feb 28 17:01:33 hanka 1st 0xffffff00042f5b10 inp (tcpinp) @ >> netinet/tcp_usrreq.c:781 >> Feb 28 17:01:33 hanka 2nd 0xffffffff80b0e1e8 PFil hook read/write >> mutex (PFil hook read/write mutex) @ net/pfil.c:73 >> Feb 28 17:01:33 hanka KDB: stack backtrace: >> Feb 28 17:01:33 hanka db_trace_self_wrapper() at >> db_trace_self_wrapper+0x2a >> Feb 28 17:01:33 hanka witness_checkorder() at witness_checkorder+0x605 >> Feb 28 17:01:33 hanka _rw_rlock() at _rw_rlock+0x5b >> Feb 28 17:01:33 hanka pfil_run_hooks() at pfil_run_hooks+0x44 >> Feb 28 17:01:33 hanka ip_output() at ip_output+0x38e >> Feb 28 17:01:33 hanka tcp_output() at tcp_output+0xacd >> Feb 28 17:01:33 hanka tcp_usr_send() at tcp_usr_send+0x272 >> Feb 28 17:01:33 hanka sosend_generic() at sosend_generic+0x347 >> Feb 28 17:01:33 hanka soo_write() at soo_write+0x38 >> Feb 28 17:01:33 hanka dofilewrite() at dofilewrite+0x85 >> Feb 28 17:01:33 hanka kern_writev() at >> Feb 28 17:01:33 hanka kern_writev+0x4c >> Feb 28 17:01:33 hanka write() at write+0x54 >> Feb 28 17:01:33 hanka syscall() at syscall+0x1f6 >> Feb 28 17:01:33 hanka Xfast_syscall() at Xfast_syscall+0xab >> Feb 28 17:01:33 hanka --- syscall (4, FreeBSD ELF64, write), rip = >> 0x800e1fd3c, rsp = 0x7fffffffea88, rbp = 0x16 --- > > >> Feb 28 17:03:54 hanka lock order reversal: >> Feb 28 17:03:54 hanka 1st 0xffffffff80b0f308 tcp (tcp) @ >> netinet/tcp_input.c:400 >> Feb 28 17:03:54 hanka 2nd 0xffffffff80b0e1e8 PFil hook read/write >> mutex (PFil hook read/write mutex) @ net/pfil.c:73 >> Feb 28 17:03:54 hanka KDB: stack backtrace: >> Feb 28 17:03:54 hanka db_trace_self_wrapper() at >> db_trace_self_wrapper+0x2a >> Feb 28 17:03:54 hanka witness_checkorder() at witness_checkorder+0x605 >> Feb 28 17:03:54 hanka _rw_rlock() at _rw_rlock+0x5b >> Feb 28 17:03:54 hanka pfil_run_hooks() at pfil_run_hooks+0x44 >> Feb 28 17:03:54 hanka ip_output() at ip_output+0x38e >> Feb 28 17:03:54 hanka tcp_respond() at tcp_respond+0x2d5 >> Feb 28 17:03:54 hanka tcp_dropwithreset() at tcp_dropwithreset+0x131 >> Feb 28 17:03:54 hanka tcp_input() at tcp_input+0x6d0 >> Feb 28 17:03:54 hanka ip_input() at ip_input+0xc0 >> Feb 28 17:03:54 hanka ether_demux() at ether_demux+0x1d9 >> Feb 28 17:03:54 hanka ether_input() at ether_input+0x19d >> Feb 28 17:03:54 hanka em_rxeof() at em_rxeof+0x1ca >> Feb 28 17:03:54 hanka em_poll() at em_poll+0x6f >> Feb 28 17:03:54 hanka netisr_poll() at netisr_poll+0x87 >> Feb 28 17:03:54 hanka swi_net() at swi_net+0xea >> Feb 28 17:03:54 hanka ithread_loop() at ithread_loop+0xda >> Feb 28 17:03:54 hanka fork_exit() at fork_exit+0x12a >> Feb 28 17:03:54 hanka fork_trampoline() at fork_trampoline+0xe >> Feb 28 17:03:54 hanka --- trap 0, rip = 0, rsp = 0xffffffff9feead30, >> rbp = 0 --- > > >> Feb 28 17:23:36 hanka lock order reversal: >> Feb 28 17:23:36 hanka 1st 0xffffffff810f9ef0 tcp_sc_head >> (tcp_sc_head) @ netinet/tcp_syncache.c:477 >> Feb 28 17:23:36 hanka 2nd 0xffffffff80b0e1e8 PFil hook read/write >> mutex (PFil hook read/write mutex) @ net/pfil.c:73 >> Feb 28 17:23:36 hanka KDB: stack backtrace: >> Feb 28 17:23:36 hanka db_trace_self_wrapper() at >> db_trace_self_wrapper+0x2a >> Feb 28 17:23:36 hanka witness_checkorder() at witness_checkorder+0x605 >> Feb 28 17:23:36 hanka _rw_rlock() at _rw_rlock+0x5b >> Feb 28 17:23:36 hanka pfil_run_hooks() at pfil_run_hooks+0x44 >> Feb 28 17:23:36 hanka ip_output() at ip_output+0x38e >> Feb 28 17:23:36 hanka syncache_respond() at syncache_respond+0x32a >> Feb 28 17:23:36 hanka syncache_add() at syncache_add+0x206 >> Feb 28 17:23:36 hanka tcp_input() at tcp_input+0xa77 >> Feb 28 17:23:36 hanka ip_input() at ip_input+0xc0 >> Feb 28 17:23:36 hanka ether_demux() at ether_demux+0x1d9 >> Feb 28 17:23:36 hanka ether_input() at ether_input+0x19d >> Feb 28 17:23:36 hanka em_rxeof() at em_rxeof+0x1ca >> Feb 28 17:23:36 hanka em_poll() at em_poll+0x6f >> Feb 28 17:23:36 hanka netisr_poll() at netisr_poll+0x87 >> Feb 28 17:23:36 hanka swi_net() at swi_net+0xea >> Feb 28 17:23:36 hanka ithread_loop() at ithread_loop+0xda >> Feb 28 17:23:36 hanka fork_exit() at fork_exit+0x12a >> Feb 28 17:23:36 hanka fork_trampoline() at fork_trampoline+0xe >> Feb 28 17:23:36 hanka --- trap 0, rip = 0, rsp = 0xffffffff9feead30, >> rbp = 0 --- > > These look useful and should point to the problem. It is also > probably related to something in your script: > >> I tried it with pf disabled, only running ipfw without dummynet, >> everything is ok. >> I tried it witout pf disabled, running ipfw with dummynet queue for >> small traffic, everything is ok. >> I tried it with/without pf disabled, running ipfw with dummynet queue >> for hight traffic >100Mbit/s, the box freezes, everytime, after >> enabling rules with the dummynet queue, after some second or few >> minutes, maybe depending on the high traffic. >> >> The shaper script: >> # SHAPER >> IPFW_PIPE_DOWNLOAD=1 >> IPFW_PIPE_UPLOAD=11 >> IPFW_QUEUE_DOWNLOAD=1 >> IPFW_QUEUE_UPLOAD=11 >> >> DOWNLOAD_ROOT="450Mbit/s" >> UPLOAD_ROOT="450Mbit/s" >> SHAPER_BUCKETS="1024" >> >> IPFW_SHAPER_ROOT=1000 >> >> $CMD pipe $IPFW_PIPE_DOWNLOAD config bw $DOWNLOAD_ROOT buckets >> $SHAPER_BUCKETS >> $CMD pipe $IPFW_PIPE_UPLOAD config bw $UPLOAD_ROOT buckets >> $SHAPER_BUCKETS >> >> $CMD queue $IPFW_QUEUE_DOWNLOAD config pipe $IPFW_PIPE_DOWNLOAD >> buckets $SHAPER_BUCKETS mask dst-ip 0xFFFFFFFF >> $CMD queue $IPFW_QUEUE_UPLOAD config pipe $IPFW_PIPE_UPLOAD buckets >> $SHAPER_BUCKETS mask src-ip 0xFFFFFFFF >> >> $CMD delete $IPFW_SHAPER_ROOT >> $CMD $IPFW_SHAPER_ROOT add queue $IPFW_QUEUE_DOWNLOAD ip from me to >> any out // Share download >> $CMD $IPFW_SHAPER_ROOT add queue $IPFW_QUEUE_UPLOAD ip from any to me >> in // Share upload > > Thanks for the information. > > Kris I hope i can help to solve this problem. Matthew From owner-freebsd-ipfw@FreeBSD.ORG Fri Feb 29 14:31:50 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77EBF1065678 for ; Fri, 29 Feb 2008 14:31:50 +0000 (UTC) (envelope-from freebsd-ipfw@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2D4758FC15 for ; Fri, 29 Feb 2008 14:31:49 +0000 (UTC) (envelope-from freebsd-ipfw@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JV6H2-0000q1-NG for freebsd-ipfw@freebsd.org; Fri, 29 Feb 2008 14:31:44 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Feb 2008 14:31:44 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Feb 2008 14:31:44 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-ipfw@freebsd.org From: Vadim Goncharov Date: Fri, 29 Feb 2008 14:31:34 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 20 Message-ID: References: <20080228151134.GA73358@tin.it> <47C7B913.5000405@elischer.org> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: Julian Elischer User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Subject: Re: [patch] ipfw_nat as a kld module X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Feb 2008 14:31:50 -0000 Hi Julian Elischer! On Thu, 28 Feb 2008 23:49:39 -0800; Julian Elischer wrote about 'Re: [patch] ipfw_nat as a kld module': >>> http://people.freebsd.org/~piso/ipfw_nat_module.patch >>> Any objection if i commit it? >> >> Some comments: >> >> * //comments are not in out style(9) > in case this is cryptic to you.. > do > "man 9 style" Of course I did before. It doesn't permit ``//''-style comments, all examples are given in (C, not C++) style of /* ... */. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-ipfw@FreeBSD.ORG Fri Feb 29 14:37:33 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 106B01065674 for ; Fri, 29 Feb 2008 14:37:33 +0000 (UTC) (envelope-from freebsd-ipfw@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id BA6CB8FC16 for ; Fri, 29 Feb 2008 14:37:32 +0000 (UTC) (envelope-from freebsd-ipfw@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JV6MY-0001AG-0D for freebsd-ipfw@freebsd.org; Fri, 29 Feb 2008 14:37:26 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Feb 2008 14:37:25 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Feb 2008 14:37:25 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-ipfw@freebsd.org From: Vadim Goncharov Date: Fri, 29 Feb 2008 14:37:14 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 33 Message-ID: References: <20080228151134.GA73358@tin.it> <20080229095150.GA76592@tin.it> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: Paolo Pisati User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Subject: Re: [patch] ipfw_nat as a kld module X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Feb 2008 14:37:33 -0000 Hi Paolo Pisati! >> * struct ip_fw_chain moved to .h and no longer static, is this good? >> I suggest to move into it's own static chain in module, see next > the symbol is used outside it's originating file Is it needed if LIST_HEAD will be in its own module? >> * Instead of returning IP_FW_NAT function is called immediately from >> ipfw_chk(). This inconsistent with other modules of this sort, like divert >> and dummynet, where ipfw_chk() simply returns value and cookie to >> ipfw_check_*() functions in _pfil.c. If it is done like that, ip_fw2.c >> is dependent on modules in minimal way, as many of structures and code >> as possible should be moved to modules. This allows to change module >> without recompiling main ipfw - for example, your lookup_nat() and >> LIST_HEAD from ip_fw_chain could reside entirely in module - then it would >> be possible to easily switch from LIST to hash of some kind (imagine 500 >> NAT instances). And so on. > that's something i thought about, but i didn't see any tangible improvement > to this modification, cause part of ipfw_nat would still be called from > ipfw2.c (see ipfw_ctl). This could be fixed, too, as is done with dummynet, which is also configured via ipfw(8). As it is HEAD, ABI can be broken and this will not be done via ipfw_ctl(). > Anyway, i'll fix a couple of nits and commit as it is. Why not to fix more?.. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-ipfw@FreeBSD.ORG Fri Feb 29 15:38:56 2008 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC4A11065671 for ; Fri, 29 Feb 2008 15:38:56 +0000 (UTC) (envelope-from piso@southcross.wired.org) Received: from mail.oltrelinux.com (krisma.oltrelinux.com [194.242.226.43]) by mx1.freebsd.org (Postfix) with ESMTP id 778248FC27 for ; Fri, 29 Feb 2008 15:38:56 +0000 (UTC) (envelope-from piso@southcross.wired.org) Received: from southcross.wired.org (host-62-10-20-127.cust-adsl.tiscali.it [62.10.20.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.oltrelinux.com (Postfix) with ESMTP id A736411AE8D; Fri, 29 Feb 2008 16:38:51 +0100 (CET) Received: (from piso@localhost) by southcross.wired.org (8.14.2/8.14.1/Submit) id m1TFfjtx007039; Fri, 29 Feb 2008 16:41:45 +0100 (CET) (envelope-from piso) Date: Fri, 29 Feb 2008 16:41:44 +0100 From: piso@FreeBSD.org To: Vadim Goncharov Message-ID: <20080229154144.GA81243@tin.it> References: <20080228151134.GA73358@tin.it> <20080229095150.GA76592@tin.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at krisma.oltrelinux.com Cc: freebsd-ipfw@FreeBSD.org Subject: Re: [patch] ipfw_nat as a kld module X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Feb 2008 15:38:56 -0000 On Fri, Feb 29, 2008 at 02:37:14PM +0000, Vadim Goncharov wrote: > >> * struct ip_fw_chain moved to .h and no longer static, is this good? > >> I suggest to move into it's own static chain in module, see next > > the symbol is used outside it's originating file > > Is it needed if LIST_HEAD will be in its own module? every modification/access to layer3_chain lock is arbitrated via its own rwlock(), thus to answer your question, yes, there are places where we would need access to layer3_chain > > that's something i thought about, but i didn't see any tangible improvement > > to this modification, cause part of ipfw_nat would still be called from > > ipfw2.c (see ipfw_ctl). > > This could be fixed, too, as is done with dummynet, which is also configured > via ipfw(8). As it is HEAD, ABI can be broken and this will not be done via > ipfw_ctl(). yes, but does it buy us anything? moreover, we would loose the ability to merge the work back to 7.x. bye, P. From owner-freebsd-ipfw@FreeBSD.ORG Sat Mar 1 08:34:58 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CA3E1065670 for ; Sat, 1 Mar 2008 08:34:58 +0000 (UTC) (envelope-from feighery@mitre.org) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by mx1.freebsd.org (Postfix) with ESMTP id 21E2D8FC2D for ; Sat, 1 Mar 2008 08:34:57 +0000 (UTC) (envelope-from feighery@mitre.org) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m1THv2eZ030627 for ; Fri, 29 Feb 2008 12:57:02 -0500 Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m1THv2kd030616 for ; Fri, 29 Feb 2008 12:57:02 -0500 Received: from IMCSRV4.MITRE.ORG ([129.83.20.161]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 12:57:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 29 Feb 2008 12:57:01 -0500 Content-Type: multipart/signed; boundary="----=_NextPart_000_014F_01C87AD2.9326E620"; protocol="application/x-pkcs7-signature"; micalg=SHA1 Message-ID: <87ABB5B9BD11A240B9CBB3F0485AEC8902344F2C@IMCSRV4.MITRE.ORG> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Dummynet and VMware Thread-Index: Ach6/HvnTAmItGAgRPG35uWjZFj7KA== From: "Feighery, Patrick D." To: X-OriginalArrivalTime: 29 Feb 2008 17:57:01.0926 (UTC) FILETIME=[7C816060:01C87AFC] X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Dummynet and VMware X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2008 08:34:58 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_014F_01C87AD2.9326E620 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I've used dummynet for many years and have found it to be a wonderful tool. Now I want to start using dummynet inside a VMware virtual appliance running under windows. In terms of VMware Server, in the past I've noticed some timing issues. For example, I've developed one application that requires a watchdog timer to expire every 10 msec. When I run this application in a FreeBSD VM appliance under VMware, I've noticed quite a large variance in the firing of this timer. I'm curious if dummynet is effected in any way when running under VMware. Does anyone have any experience with dummynet and VMware? Best Regards Pat feighery@mitre.org ------=_NextPart_000_014F_01C87AD2.9326E620 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvzCCA2Qw ggJMoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwWjESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQL ExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJDAiBgNVBAMTG01JVFJFIENvcnBvcmF0aW9uIFJvb3Qg Q0EtMTAeFw0wNjA2MDEwNDAwMDBaFw0xODA2MDEwNDAwMDBaMFoxEjAQBgNVBAoTCW1pdHJlLm9y ZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQwIgYDVQQDExtNSVRSRSBDb3Jwb3Jh dGlvbiBSb290IENBLTEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCva1qWPZiEJv5v MtCbjt0cTu0Nbn15Q1cKqQBXKi8VSH9zZPmPxfWizJJ7JSqFJ5/sLUz3NsnUVjpLYBdFcxNXnOLj XtmDPFOewm5T98NZc9wRRCiDzt4f8qsHFI19ShPiK3cN5UqtJf+i66QVLA1S6CNL6o2eGAsAl5Wn xwOh2BfcWU5fNlHDVc9KKAlDDWpHjC2LLHAUbLP4ZzMIJKcLgLKFMtgM2AEfaSHzmi7WUdUHRCtC blrF7qzPsy/jBLFrr8VcX+mb7saq95pEOilgcix0/naW7kJfM5ph7UBB+S1O/OhH+ZjQ4MjWnwE8 A/YDrQx1OVLAOi29Bsho/l8lAgMBAAGjNTAzMBIGA1UdEwEB/wQIMAYBAf8CAQMwHQYDVR0OBBYE FMdwUQDYTf7kAdRolsU9n5qX/nQvMA0GCSqGSIb3DQEBBQUAA4IBAQAa+fVfCljimBlcfWwkfJXu XNKWun9xloFKjnq6SPGgAIKi5LUDil60a0NaNGoGSO3I1xzYt7ncayh21qXulcVTDFqubSJdv51a HTuJYcYUX72LN/gSq03UVLBCJzYm7ZLUlkb2YLo7xUeZ3coLFcT5AHR36kjG4cYHqXgH0liBl8jx pN0gwgaci4sgPLUj1w4t8zoKH+zxGFwXwTP/P+etQqiJZ5T00fLLm5kz9mmnxxmmIvUGNdsCAhGh dnF24pcrR43LNgyOBJ9DPUHBNq3kUQRO48WBKxBxflOtKzsICx/HEtIABcZn7deADHcY9spULZfB nQYdEpyz5tgh7Y2qMIIDazCCAlOgAwIBAgICEO0wDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1JVFJF IENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wNzA4MTUxNzIzMzZaFw0wOTAyMDUxNzIzMzZa MF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRgwFgYKCZImiZPyLGQBARMI ZmVpZ2hlcnkxHDAaBgNVBAMTE0ZlaWdoZXJ5IFBhdHJpY2sgRC4wgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBALKCoGY/aO5CxQmmVT8bolz5f+FYAHptHoeVSKm2WoxCUBvA3+/WTQgPtLpvjAKx K6a4pEsvpcbRBbQ/whPeV61D4TGdoi8BJzCb3kvJv/mwsSgLL2jwUxx20Py9SQXUFh98/7cTFZWm EURfrhH30wlgCR8/M+oHwP9KExIWEIWvAgMBAAGjgbgwgbUwDgYDVR0PAQH/BAQDAgXgMB0GA1Ud DgQWBBToaectqESVdJpcFoIlfCQ3vW6zzTAfBgNVHSMEGDAWgBSHtA9IjWIzQsEtURpIHsKeuwqx rTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1pdHJlLm9yZy90ZWNoL21paS9wa2kvY2Ex X21pdHJlX29yZy5jcmwwHQYDVR0RBBYwFIESZmVpZ2hlcnlAbWl0cmUub3JnMA0GCSqGSIb3DQEB BQUAA4IBAQCQAyjF2xcsS9WTQgxynEacsxA663e62fqvkRDCm2lQqq8AgGZ5KldhtpVPdhcpLs6G FoW3agSF8XY2yI4Dkb61R3mmFCvvv76F858stM/sAVEJOscUH2W4togynFnimV8Ixr8306dkA5qZ 6dJLqRzDkBUfC9hBZwSCEy2baYqz6HkpWR4ijoV5XFYMSEDiuQFr2GIfnklF91oxDvWQK4CMp70u Vlox76Ljfhx+L7M9mGSAoIds9l0iLIXexnL7SAHs822k7pUtekUKjkWAL8iBVXQ9OSDeeVHsVxYW y68fxocf1uCB74g0tgA1ArgXFJkxMe+00a2n1zp1BzLDfQ8JMIID5DCCAsygAwIBAgIBBTANBgkq hkiG9w0BAQUFADBaMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEkMCIGA1UEAxMbTUlUUkUgQ29ycG9yYXRpb24gUm9vdCBDQS0xMB4XDTA2MDYwMzE3 MTMyMloXDTEyMDYwMzE3MTMyMlowXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0 aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0Et MTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMjwe1ZdEIKoELdLvENnbkbO3mVD54ZX 5SjxTzFxhvoqhqSJmLOp32xT7J9KvBapJRbJv1BFdiSUN3O0q8H66nvQqwm1RYe+tTsWSO351Fol GrDT9iDRtfWgH60PCKCbABLRsx3iGnEvjOQjeAtMn1AugqQWU3PWZXYy1Grbya+NOytYvu1p60bD FSoSAn4Jojv14lUfWHl8s3kahay8umLSQibiXdEEX8CrSkaXpOaFOuyM6+wpRw7TybO1Dk4zGAUt n0887QvsMDk6evgN2WxMprkHAGUcJhpI1QXtkfDIl9ukdNiIoM/vdN2QC/+m6b8dA55K5UdlBa9S gRnwapkCAwEAAaOBsTCBrjASBgNVHRMBAf8ECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAdBgNV HQ4EFgQUh7QPSI1iM0LBLVEaSB7CnrsKsa0wHwYDVR0jBBgwFoAUx3BRANhN/uQB1GiWxT2fmpf+ dC8wSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL3Jv b3RjYTFfbWl0cmVfb3JnLmNybDANBgkqhkiG9w0BAQUFAAOCAQEATW5u664p7N0iAj27Xl/akjdf kSQpaosf6cNyAHu7utCytFfY1WfRNmvnNDGYkqI3XMFOa18SNjiNsMCH+sFQaO+oyDnPiIkEZQvl fGGrRpqIm6j//Fgz85bnf1kAM5I61Np7ofCnciRvp9ZB/+u+9i262tgiJPJrvBcqXmgeT9riCc3R PjxqPNmYslOvNLpIifchelJhF7nIge+7RkAUcTJenj8yKwK0J3+PEpgYRQ+V2C62rnjohuxPgMw/ fYoNTOlh3MVl7adwyK1ahPw2a9eOjSWglqoPTaBNeHJqRJZZ6Vi7S55+VAWCfkAqM5m3tUiVzjsp 2dFcTJxnYezaoDGCAr0wggK5AgEBMGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVD ZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkg Q0EtMQICEO0wCQYFKw4DAhoFAKCCAbAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDgwMjI5MTc1NzAxWjAjBgkqhkiG9w0BCQQxFgQUJOT4z+RXNuXR188YX1qFnQ0P 3/IwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwcgYJKwYB BAGCNxAEMWUwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIQ7TB0Bgsq hkiG9w0BCRACCzFloGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0 ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICEO0w DQYJKoZIhvcNAQEBBQAEgYAzwoxYPxqd382uEzj423lJAXO6/xrqV8L6kbHebkOsbch8Fj1lokwD ci9JTTAFejCr4dpzjzm73p4bcfIv1VyT7oafFSE4ii2463LhFv3bU3kIgR/4IrSbA2NdyyGXmdJO YuQdzNGHiT4NJVEgxebSVtwHmMCfCe7QR3Q7fNKqfQAAAAAAAA== ------=_NextPart_000_014F_01C87AD2.9326E620--