Re: Traffic not going through dummynet
On Jul 31, 2015 3:23 AM, Ian Smith smi...@nimnet.asn.au wrote: firewall_enable=YES firewall_type=OPEN # permit all, regardless of default_to_accept dummynet_anable=YES which would at least load those modules in the right order, The order of variables in /etc/rc.conf is irrelevant, except that a later assignment for the same variable will overwrite the value. - M ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: Traffic not going through dummynet
On Fri, 31 Jul 2015 09:43:25 -0700, Michael Sierchio wrote: On Jul 31, 2015 3:23 AM, Ian Smith smi...@nimnet.asn.au wrote: firewall_enable=YES firewall_type=OPEN # permit all, regardless of default_to_accept dummynet_anable=YES which would at least load those modules in the right order, The order of variables in /etc/rc.conf is irrelevant, except that a later assignment for the same variable will overwrite the value. Yes, quite so. Sorry, I was referring to earlier in the thread about using the rc mechanism via rc.conf with /etc/rc.d/ipfw, which then loads dummynet at the right time; rather than invoking dummynet by preloading, which seems to be triggering this regression from sometime? after 9.x cheers, Ian ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: Traffic not going through dummynet
On Sun, 19 Jul 2015 21:05:53 -0700, hiren panchasara wrote: Bah. So I removed ipfw and dummynet from kernconf and loaded them manually after machine came up and it worked as expected. In your previous post, you'd said you were using 11-current, and: And GENERIC has: options IPFIREWALL options DUMMYNET options HZ=1000 Are you sure this was a 11 GENERIC kernconf? Those options haven't been in GENERIC for ages (if ever?), though they haven't needed to be since (perhaps) 8.0. I guess people just follow the handbook :( Looks like some ordering issue between ipfw and dummynet. Fwiw, for working setup, kldstat shows: 132 0x81e21000 21490ipfw.ko 141 0x81e43000 d0f6 dummynet.ko Indeed. If you load ipfw and dummynet by the usual means, being firewall_enable=YES and dummynet_enable=YES in rc.conf, you'll notice that /etc/rc.d/ipfw, in ipfw_prestart, loads dummynet if enabled, and natd and/or firewall_nat if enabled, in that order. The downside to doing that is that you have to have specified a type for rc.firewall or pointed to a custom ruleset so it's sane on startup. Regarding the related(?) Bug 201488 - dummynet appears broken in 10.0-RELEASE and onwards (can't traffic shape on bridges) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201488 it does seem likely to be the same issue as you noted. Did you ever hear back from James Rice (for whom I seem to have seen no other messages for an email address) as to whether your advice about loading these in the other order helped there? As to whether this is a regression, or it would have ever worked loading dummynet and then ipfw, I don't know, but I have a vague feeling that I've seen other issues regarding loading a module that's already in kernel in recent times .. sorry I can't be any more exact. Maybe dummynet needs a check that ipfw is loaded before starting? cheers, Ian ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: Traffic not going through dummynet
Bah. So I removed ipfw and dummynet from kernconf and loaded them manually after machine came up and it worked as expected. Looks like some ordering issue between ipfw and dummynet. Fwiw, for working setup, kldstat shows: 132 0x81e21000 21490ipfw.ko 141 0x81e43000 d0f6 dummynet.ko Cheers, Hiren pgpCD0bMSgmcE.pgp Description: PGP signature
Re: Traffic not going through dummynet
On 07/18/15 at 12:40P, hiren panchasara wrote: This is driving me nuts. I've had an ipfw/dummynet working config on separate setup and the same thing doesn't work on this new setup I have so I tried to narrow it down and removed all complexity and trying to see if this works on just single host. But it doesn't work as I expect it to. I am pretty sure I am missing something here. 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r283696M: Fri Jul 17 15:43:05 MST 2015 loader.conf has: net.inet.ip.fw.default_to_accept=1 dummynet_load=YES I did: # ipfw add pipe 1 ip from any to any # ipfw pipe 1 config delay 100ms # ipfw show 001000 0 pipe 1 ip from any to any 65535 4321 509541 allow ip from any to any # ipfw pipe show 1: unlimited 100 ms burst 0 q131073 50 sl. 0 flows (1 buckets) sched 65537 weight 0 lmax 0 pri 0 droptail sched 65537 type FIFO flags 0x0 0 buckets 0 active Now if I ping anything, I don't see 100ms delay. # sysctl -a | grep ipfw kern.features.ipfw_ctl3: 1 net.link.ether.ipfw: 0 net.inet.ip.dummynet.io_pkt_fast: 0 net.inet.ip.dummynet.io_fast: 0 net.link.ether.ipfw: 0 And GENERIC has: options IPFIREWALL options DUMMYNET options HZ=1000 Cheers, Hiren pgp9KWKb2ZUJg.pgp Description: PGP signature
