From owner-freebsd-hackers@FreeBSD.ORG  Mon Jul 29 12:23:36 2013
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
 (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTP id DAA80512;
 Mon, 29 Jul 2013 12:23:36 +0000 (UTC)
 (envelope-from kpielorz_lst@tdx.co.uk)
Received: from mail.tdx.com (mail.tdx.com [62.13.128.18])
 by mx1.freebsd.org (Postfix) with ESMTP id 9FF6E2357;
 Mon, 29 Jul 2013 12:23:36 +0000 (UTC)
Received: from Mail-PC.tdx.co.uk (storm.tdx.co.uk [62.13.130.251])
 (authenticated bits=0)
 by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id r6TCNYqQ003679
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
 Mon, 29 Jul 2013 13:23:35 +0100 (BST)
Date: Mon, 29 Jul 2013 13:23:34 +0100
From: Karl Pielorz <kpielorz_lst@tdx.co.uk>
To: Simon Dick <simond@irrelevant.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>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: freebsd-hackers@freebsd.org
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
 <freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
 <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jul 2013 12:23:36 -0000


--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