From owner-freebsd-pf@FreeBSD.ORG Tue Nov 4 15:53:53 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 A202B1065673 for ; Tue, 4 Nov 2008 15:53:53 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 538618FC24 for ; Tue, 4 Nov 2008 15:53:53 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: by qw-out-2122.google.com with SMTP id 9so1421045qwb.7 for ; Tue, 04 Nov 2008 07:53:52 -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:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=mQOCmlo9H+GPVZTh8St00AB7O0iDpo8DEJ6AURtB+N4=; b=x888isOmYMIYUTBY7elnlOyWnUSVEvFpTvqfukpTtKJPF6zkeg9DJDywWW43PeeiXb 5CMPQKS0n05fbCqyAAX1MvQvq3VDNx0Jgv5Z6h1Fy2o31nuAO34VjnE3XQjfJEHkrKyY vN7jEuLeZeOLtcKDZ3Wo8zOG+/vkYJTc379Lk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=jS+gJY0GdiKcRf5hAHduSNMTpfSOzBwLNztrgv/SLJOU3K2sZYW22Vx1ASHWWgl47W mByUoVRLVEg+M3jNZUyRUFvrXtQDdf7NoMF+vTj5mZ9GlQoXAHpZ00wWuAoI0syQODkI Tk5z6vR1i5FLgk+3OMweelU8LzbvNIu0GYUZI= Received: by 10.215.40.16 with SMTP id s16mr1873268qaj.215.1225814032551; Tue, 04 Nov 2008 07:53:52 -0800 (PST) Received: by 10.214.43.4 with HTTP; Tue, 4 Nov 2008 07:53:52 -0800 (PST) Message-ID: <9a542da30811040753m1a2728bcu365c65da8fb61721@mail.gmail.com> Date: Tue, 4 Nov 2008 16:53:52 +0100 From: "=?ISO-8859-1?Q?Ermal_Lu=E7i?=" To: "Peter Jeremy" In-Reply-To: <20081103060321.GA45414@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <9a542da30710161409o4732a77bybdf4ba35d7491bb@mail.gmail.com> <200710171043.08126.max@love2party.net> <9a542da30710211232v4d3c930fg8ea778a12f3f16cb@mail.gmail.com> <9a542da30710280617t11e668e2o4d122998192f71c@mail.gmail.com> <20081103060321.GA45414@server.vk2pj.dyndns.org> 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: Tue, 04 Nov 2008 15:53:53 -0000 On Mon, Nov 3, 2008 at 7:03 AM, Peter Jeremy wrote: > 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. actually this is the latest against RELENG_7 which is confirmed to work with full features of pf(4) like route-to/reply-to etc... http://cvs.pfsense.org/cgi-bin/cvsweb.cgi/tools/patches/RELENG_7/dummynet.R= ELENG_7.diff?rev=3D1.5 The problem that is that i have yet to find time to post it here but since you have interes here it is. Its problem is that from the whole patches here http://cvs.pfsense.org/cgi-bin/cvsweb.cgi/tools/patches/RELENG_7/ you need to apply these others before it applies cleanly fairq.RELENG_7.diff <-- Mathew Dillon ALTQ_FAIRQ discipline dscp.RELENG_7.diff <-- a simple dscp syntax addition queuestats.RELENG_7.diff <-- you do not need this actually hfscconfig.RELENG_7.diff <-- this is on pfSense and only discussed with Ma= x killifstates.RELENG_7.diff <-- pfctl -b $ip addition to kill states from the gateway ip(interface ip) dummynet.RELENG_7.diff <-- dummynet(4) divert.RELENG_7.diff <-- divert(4) these are incorporated in the latest snapshots of pfSense but if you want to do the patching yourself I have no problems with it. Since i am sending this mail there is another patch that might interest you http://cvs.pfsense.org/cgi-bin/cvsweb.cgi/tools/patches/RELENG_7/pfil.RELEN= G_7.diff?rev=3D1.1 it allows to reorder pfil hook or even disable one of them. Its a long time i am saying i will make them ready for review and commit for FreeBSD but still not found it. So i cannot state more on this. Feedback is always welcomed. The syntax on the this new patch is pass in ........ keep state dnpipe 1 or pass in ........ keep state dnpipe (1 ) or pass in ........ keep state dnpipe (1,3) where the latest pipe/queue 1 applies to in direction and pipe/queue 3 applies to out direction. > > -- > 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 behaviou= r. > --=20 Ermal