From owner-freebsd-ipfw@freebsd.org Sun Jul 26 08:52:27 2015 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CDB7C9A3FCF for ; Sun, 26 Jul 2015 08:52:27 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 37E3EBA for ; Sun, 26 Jul 2015 08:52:26 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t6Q8iYTY019246; Sun, 26 Jul 2015 18:44:37 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 26 Jul 2015 18:44:34 +1000 (EST) From: Ian Smith To: hiren panchasara cc: freebsd-ipfw@freebsd.org Subject: Re: Traffic not going through dummynet In-Reply-To: <20150720040653.GV38517@strugglingcoder.info> Message-ID: <20150726181056.C17327@sola.nimnet.asn.au> References: <20150718194020.GQ38517@strugglingcoder.info> <20150718202818.GR38517@strugglingcoder.info> <20150720040653.GV38517@strugglingcoder.info> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2015 08:52:27 -0000 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: > > 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. 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