From owner-freebsd-pf@FreeBSD.ORG Mon Nov 3 17:27:14 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21B60106568F for ; Mon, 3 Nov 2008 17:27:14 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id 9DE9F8FC21 for ; Mon, 3 Nov 2008 17:27:13 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id mA363O8b008780 for ; Mon, 3 Nov 2008 17:03:24 +1100 Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id mA363LK0010362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Nov 2008 17:03:22 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id mA363Lhs045510; Mon, 3 Nov 2008 17:03:21 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id mA363LGE045509; Mon, 3 Nov 2008 17:03:21 +1100 (EST) (envelope-from peter) Date: Mon, 3 Nov 2008 17:03:21 +1100 From: Peter Jeremy To: Ermal =?iso-8859-1?Q?Lu=E7i?= Message-ID: <20081103060321.GA45414@server.vk2pj.dyndns.org> References: <9a542da30710161409o4732a77bybdf4ba35d7491bb@mail.gmail.com> <200710171043.08126.max@love2party.net> <9a542da30710211232v4d3c930fg8ea778a12f3f16cb@mail.gmail.com> <9a542da30710280617t11e668e2o4d122998192f71c@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw" Content-Disposition: inline In-Reply-To: <9a542da30710280617t11e668e2o4d122998192f71c@mail.gmail.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-pf@freebsd.org Subject: Re: [PATCH] PF+dummynet X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2008 17:27:14 -0000 --wac7ysb48OaltWcw Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Oct-27 19:45:59 +0000, Ermal Lu=E7i wrote: >Attached is the patch against -CURRENT for integrating PF with dummynet! > >It gives full dummynet support in pf.conf syntax and removes dummynet >depndency to ipfw. I've recently found this and applied it to 7.1-PRERELEASE. There were a few rejects and a couple of printf format problems which were all quite easy to fix. I also found an incorrect getopt() string in pfctl, incorrect PLR definition, and an uninitialised dnflow variable. Actually using it presents some more problems. Firstly, if you have ipfw in the kernel then dummynet packets appear to loop indefinitely. Disabling ipfw fixed this (I had built ipfw into the kernel incase I couldn't get pf+dummy to work). The above left me with wierd delays and incorrect packet counts on the rules. Further sleuthing shows that I'm falling foul of the state rules that pf is creating - though the behaviour is still wierd. Given the following: dnpipe 128 bandwidth 2Mb delay 500 queue 64KB dnpipe 136 bandwidth 2Mb delay 500 queue 64KB r1) pass in quick on vlan128 from any to 192.168.136.0/22 dnpipe 128 r2) pass in quick on vlan136 from any to 192.168.128.0/22 dnpipe 136 I get the following: t0 ICMP ECHO REQ a->b -> match r1: pass to pipe 128 (delay 500msec), create state s1 t+.5s -> ICMP ECHO REQ a->b t+.5s <- ICMP ECHO RESP b->a match r2: pass to pipe 136 (delay 500msec), create state s2 match s1: pass to pipe 128 (delay 500msec) t+1.5s ICMP ECHO RESP b->a <- t2 ICMP ECHO REQ a->b -> match s1: pass to pipe 128 (delay 500msec) match s2: pass to pipe 136 (delay 500msec) t2+1s -> ICMP ECHO REQ a->b t2+1s <- ICMP ECHO RESP b->a match s2: pass to pipe 136 (delay 500msec) match s1: pass to pipe 128 (delay 500msec) t2+2s ICMP ECHO RESP b->a <- I managed to fix ICMP by testing that the rule direction matches the packet direction before passing it to dummynet. Unfortunately, this means that TCP only goes through dummynet in one direction (since TCP only has a single state entry). I think the duplicate ICMP state entry is a bug in pf. And the dummynet patches need to support two pipes (one for each direction). I am still looking into this. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --wac7ysb48OaltWcw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkkOlCkACgkQ/opHv/APuIdDegCglsBa2q7OY5emhmD6oTz3ZP7Y 9YUAnR7u3ankRApRO4/cAlYzxq6MjsZ6 =b1p9 -----END PGP SIGNATURE----- --wac7ysb48OaltWcw--