dummynet / ipfw pipe delay blocks all traffic

arusan

arusan

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...
 
Post relevant configuration bits and rulesets, or it'll all be guesswork and questions from here.
 
I was just about to post all details, but found the problem:

while in 8.0 I used in sysctl.conf:
Code: 
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:
Code: 
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:
Code: 
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:
Code: 
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:
Code: 
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.
 
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:
Code: 
# 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:
  1. First as an ethernet frame where the rules check the src/dest MAC addresses, then
  2. 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.
 
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.
 
You must log in or register to reply here.
Back
Top