(For various reason's I didn't get/see Ian's message. Trying to do the
right thing by setting "In-Reply-To".)

On 07/27/15 at 01:07P, Ian Smith wrote:
> 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 :(

I modified GENERIC and added those options. I should have been more
clear here.
> 
>  > Looks like some ordering issue between ipfw and dummynet. Fwiw, for
>  > working setup, kldstat shows:
>  > 
>  > 13    2 0xffffffff81e21000 21490    ipfw.ko
>  > 14    1 0xffffffff81e43000 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.

Didn't know the usual mean of rc.conf modifications.
> 
> 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?

I haven't heard back yet.
> 
> 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.

Yeah, good point about whether this is a regression or not. I am not
aware of any such loading issues wrt modules.
> 
> Maybe dummynet needs a check that ipfw is loaded before starting?

That'd be logical, imo.

Cheers,
Hiren

Attachment: pgpMoZh7E9Lcn.pgp
Description: PGP signature

Reply via email to