Date: Mon, 3 Nov 2008 17:03:21 +1100 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Ermal =?iso-8859-1?Q?Lu=E7i?= <ermal.luci@gmail.com> Cc: freebsd-pf@freebsd.org Subject: Re: [PATCH] PF+dummynet Message-ID: <20081103060321.GA45414@server.vk2pj.dyndns.org> In-Reply-To: <9a542da30710280617t11e668e2o4d122998192f71c@mail.gmail.com> References: <9a542da30710161409o4732a77bybdf4ba35d7491bb@mail.gmail.com> <200710171043.08126.max@love2party.net> <d5992baf0710171324n65c4b171l71db8aeac445b52d@mail.gmail.com> <9a542da30710211232v4d3c930fg8ea778a12f3f16cb@mail.gmail.com> <9a542da30710280617t11e668e2o4d122998192f71c@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <ermal.luci@gmail.com> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081103060321.GA45414>