# dummynet / ipfw pipe delay blocks all traffic



## arusan (Aug 24, 2011)

hi,

when i config a pipe with delay >0ms, all my traffic gets blocked. with the pipe active but delay 0 the traffic is ok. this was working before:

i had working scripts in 8.0 to delay traffic over a bridge, filtering by dst/src-ip on out. ipfw, dummynet compiled into the kernel, hz=1000.

now i did a fresh install of 8.2 on the same machine, same HW, put the same options in the kernel and recompiled, just HZ=5000 and took out lots of devices i never use (firewire, some SCSI etc). I have the same NICs, same bridge config, same rc.conf, firewall default to accept (as before).

--> but, as describedin the beginning, when I now configure the pipe with delay >0ms (even 1ms) my whole link dies! and even though it's filtering by src/dst ip on out (in 2 different rules, that used to work ok before), it blocks all my traffic.
set the pipe delay back to 0ms or flush --> all back to normal.

Any ideas? did you come across this before? did I forget to configure something? it's driving me crazy and I couldn't find much on this topic on the net...


----------



## DutchDaemon (Aug 24, 2011)

Post relevant configuration bits and rulesets, or it'll all be guesswork and questions from here.


----------



## arusan (Aug 24, 2011)

I was just about to post all details, but found the problem:

while in 8.0 I used in sysctl.conf:

```
net.link.ether.ipfw=1
net.link.bridge.ipfw=1
```

...and dummynet+bridge performed as expected for delay, plr etc, in 8.2 this does not work anymore.

In 8.2 I have to use:

```
net.link.ether.ipfw=0
net.link.bridge.ipfw=1
```

all the rest stays the same in my config, but the net-link.ether.ipfw must be 0 now.

I have not found the explanation for this, since I found the hint on a forum.
If someone can eexplain it I would be happy to know what I was doing wrong (and why it worked in 8.0 with no problems for many tests).
And why it was ok in 8.2 when i configured the pipe with delay 0 (and the rules, of course), but it blocked all traffic (including the one not matching my rules) when i set the delay to anything different than 0. I believe the bridge was cut off altogether in that case, right?

I have IPFIREWALL and DUMMYNET compiled in my kernel, Hz=5000.
I load the bridge in /boot/loader.conf (though I think it is not really necessary, it is loaded even without this  config line, it seems).

sysctl.conf explained above (no other options configured).

rc.conf:

```
firewall_enable="YES"
cloned_interfaces="bridge0"
ifconfig_bridge0="addm re0 addm re1 up"
ifconfig_re0="up"
ifconfig_re1="up"
gateway_enable="YES"
ifconfig_re2="inet x.x.x.x netmask x.x.x.x up"  #details irelevant, not used in my bridge
defaultrouter="x.x.x.x" #details again irelevant
```

for the delay:

```
ipfw -q flush
ipfw -q pipe flush
ipfw pipe 2 config delay 0ms
ipfw add 100 pipe 2 out dst-ip y.y.y.y/yy
ipfw add 200 pipe 2 out src-ip y.y.y.y/yy   #same y.y.y.y/yy as before,I only delay for one IP
```

all ok when I run this for ipfw.
as soon as i run anything like:

```
ipfw pipe 2 config delay 1ms  #or anything with delay>0
```

all my traffic gets blocked.
as soon as I put the delay back to 0ms or flush, all is again ok.


----------



## phoenix (Aug 24, 2011)

Just to confirm, do you have *IPFIREWALL_DEFAULT_TO_ACCEPT* set in your kernel, with all the other *IPFIREWALL_** options?  And you do not load any *ip** modules?

If you enable *net.link.ether.ipfw*, does it work if you add rules to allow Layer2 (ethernet) frames through the firewall:

```
# Allow ARP traffic
$IPFW add 4 allow ip from any to any layer2 mac-type arp

# Allow ethernet traffic
$IPFW add 7 allow ip from any to any MAC any any
```

When *net.link.ether.ipfw* is enabled, every packet is sent through the firewall twice:

First as an ethernet frame where the rules check the src/dest MAC addresses, then
Second as an IP package where src/dest addresses, ports, and protocols are checked.
You have to allow packets at both levels in order for the packet to pass through the firewall.  Block it at either level, and the packet is dropped.


----------



## arusan (Sep 6, 2011)

yes, I have IPFIREWALL_DEFAULT_TO_ACCEPT. I do not load any other ip* modules.
What other IPFIREWALL_* options should I have?

unfortunately I cannot test now what happens if I enable net.link.ether.ipfw and set that rule, since the machine is used, but hopefully I can try that next week.


----------

