Date: Mon, 29 Jul 2013 13:23:34 +0100 From: Karl Pielorz <kpielorz_lst@tdx.co.uk> To: Simon Dick <simond@irrelevant.org> Cc: freebsd-hackers@freebsd.org Subject: Re: kldload ipfw, with IPFIREWALL_DEFAULT_TO_ACCEPT Message-ID: <67FACFDFDA838E0B60BBDDF4@Mail-PC.tdx.co.uk> In-Reply-To: <CAPyG9gP7Yqm1mTj6Ruqavnnc6eZJf0EZrZyAjQSJbqYjAMQSRQ@mail.gmail.com> References: <1D6BF13DFC536AFC94EC6D64@Mail-PC.tdx.co.uk> <51F64BCC.9000301@freebsd.org> <AC5633093C6F6EB16C5C7DEF@Mail-PC.tdx.co.uk> <CAPyG9gP7Yqm1mTj6Ruqavnnc6eZJf0EZrZyAjQSJbqYjAMQSRQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--On 29 July 2013 12:30 +0100 Simon Dick <simond@irrelevant.org> wrote: > My normal way is to run the kldload in screen and manually run an allow > all right afterwards > e.g. > > kldload ipfw && ipfw <blah>... :) Yeah, that would probably work - I'm more concerned what impact it would have on the CARP interfaces on the box - i.e. if they get 'cut off' even for a fractional period, they may decide they are the new master (or worse, other boxes may decide they need to become the new master). If there's no way of getting a 'default allow' on kldload (other than the workaround kind of way) it looks like I'll just have to plan for a cut off of things like CARP, and design around it :( Cheers, -Karl
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?67FACFDFDA838E0B60BBDDF4>