[PATCH] PF+dummynet
Ermal Luçi
ermal.luci at gmail.com
Tue Nov 4 07:53:53 PST 2008
On Mon, Nov 3, 2008 at 7:03 AM, Peter Jeremy
<peterjeremy at optushome.com.au> wrote:
> On 2007-Oct-27 19:45:59 +0000, Ermal Luçi <ermal.luci at 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.
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.RELENG_7.diff?rev=1.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 Max
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.RELENG_7.diff?rev=1.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 behaviour.
>
--
Ermal
More information about the freebsd-pf
mailing list