From owner-freebsd-questions@FreeBSD.ORG Tue Oct 8 10:06:08 2013 Return-Path: Delivered-To: freebsd-questions@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 DE8C9AAB for ; Tue, 8 Oct 2013 10:06:08 +0000 (UTC) (envelope-from freebsd-questions@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9EA572513 for ; Tue, 8 Oct 2013 10:06:08 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VTTwR-0006sl-FY for freebsd-questions@freebsd.org; Tue, 08 Oct 2013 11:50:59 +0200 Received: from pool-173-79-84-117.washdc.fios.verizon.net ([173.79.84.117]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 08 Oct 2013 11:50:59 +0200 Received: from nightrecon by pool-173-79-84-117.washdc.fios.verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 08 Oct 2013 11:50:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-questions@freebsd.org From: Michael Powell Subject: Re: NAT: Handbook vs mailing list Date: Tue, 08 Oct 2013 05:50:45 -0400 Lines: 44 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: pool-173-79-84-117.washdc.fios.verizon.net X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: nightrecon@hotmail.com List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 10:06:08 -0000 Olivier Nicole wrote: [snip] >> >> The mailing list message linked above suggests that the handbook >> information is the "old way" and that the correct way is to set >> ipfw_enable and natd_enable in rc.conf. "Then /etc/rc.d/ipfw will >> load ipfw.ko, and if natd_enable is set, will invoke /etc/rc.d/natd, >> which loads ipdivert.ko at the right time." > > From what you copied/explained, natd_enable will load ipdivert.ko and > the handbook suggests that you load ipdivert.ko, so either way the > module will be loaded. > > I'd go with the ipfw_enable and natd_enable as it may also do other > needed things than just loading a kernel module. +1 on this. It is also present in the /etc/defaults/rc.conf this way as well (of course, use /etc/rc.conf for override customization). The original situation referred to early in the mailing-list content was a timing related problem where the ipdivert module would fail, even after ipfw loading _did_ succeed. Most of the 'old way' is a holdover from before the init system brought in the rc.subr startup scripts (imported from netbsd if memory serves). There have been a couple of hiccups along the way concerning the order things are started. For example, it doesn't really work to start a dhcp client prior to successful network initiate completion. Over time the rc.subr system has evolved and been cleaned up. A long time ago I eschewed running mergemaster when doing source-based upgrades. Just didn't like it and it never seemed like not doing it hurt anything. For quite some time I never experienced any problem with this approach. However, this eventually did bite me in the rump in a very bad way! :-) When running mergemaster while upgrading to a new release you may see these scripts being updated. So they are continuing to evolve, and a lot of this is to start up and configure things as the system comes up in a 'correct' and coherent order. So imho the Handbook is a wee bit outdated. -Mike