From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 18 02:39:03 2005 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFA8E16A41C for ; Mon, 18 Jul 2005 02:39:03 +0000 (GMT) (envelope-from smartweb@leadhill.net) Received: from natco8.natcotech.com (natco8.natcotech.com [205.167.142.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6517C43D45 for ; Mon, 18 Jul 2005 02:39:03 +0000 (GMT) (envelope-from smartweb@leadhill.net) Received: from localhost (int9.natcotech.com [192.168.1.9]) by natco8.natcotech.com (Postfix) with ESMTP id 7606C29807F for ; Sun, 17 Jul 2005 21:39:02 -0500 (CDT) Received: from natco8.natcotech.com ([192.168.1.8]) by localhost (natco9 [192.168.1.9]) (amavisd-new, port 10024) with LMTP id 21595-01-20 for ; Sun, 17 Jul 2005 21:39:02 -0500 (CDT) Received: from ibm.nlcc.us (ldhl-ras1-dial-12-28-24-226.natcotech.com [12.28.24.226]) by natco8.natcotech.com (Postfix) with ESMTP id BE73329807C for ; Sun, 17 Jul 2005 21:39:01 -0500 (CDT) Received: (qmail 98918 invoked by uid 89); 18 Jul 2005 02:39:01 -0000 Received: from unknown (HELO ?192.168.0.2?) (192.168.0.2) by ibm.nlcc.us with SMTP; 18 Jul 2005 02:39:01 -0000 Message-ID: <42DB1642.4020801@leadhill.net> Date: Sun, 17 Jul 2005 21:38:58 -0500 From: Billy Newsom User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: stefan@aeschbacher.ch, hackers@freebsd.org References: <1121426237.42d79b3dcf954@horde.nts.ch> In-Reply-To: <1121426237.42d79b3dcf954@horde.nts.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at natco9.natcotech.com Cc: Subject: Re: rc.d ppp dependency X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 02:39:04 -0000 stefan@aeschbacher.ch wrote: > Hi > when using ppp together with pf there seems to exist a dependency problem. > I start ppp and pf with : ppp_enable="YES" and pf_enable="YES" in rc.conf. > > At startup when the pf rulefile is loaded, the tun0 (which I use in the pf > config) device does not yet exist and therefore the rules can not load. > > I noticed that in /etc/rc.d/ppp-user, ipfilter is resynced after ppp has > started. Shouldn't the same be done for pf? > > thanks > > Stefan > > P.S. a similar problem exists with sshd when a ListenAddress directive is > used with an address configured to tun0 Attn: I have been trying to get the same exact problem dealt with for ipnat and renaming interfaces. It appears that under FreeBSD 5-Stable, that although we are welcome to rename a network interface (like fxp0) to whatever we want (say out0), there seems to be a problem with the order in which things happen at boot. RENAMING happens after the ipnat has started, and so I feel that we need to re-sync ipnat after the renaming occurs. Otherwise, ipnat seems to have the old interface names, and ipnat will not work. Notice that in the rcorder of things, we see this (I skipped a bunch for brevity): ipfilter ... ipmon ... ipnat ipfs ... netif (interface renaming occurs; resync of ipfilter) isdnd ppp-user ipfw dhclient nsswitch ip6addrctl atm2 routing ip6fw network_ipv6 mroute6d route6d mrouted routed NETWORKING ... pflog pf pppoed ... localpkg natd What I see is that we need an IF-THEN-ELSE statement in the rcorder system someplace, that can notify pf if ppp is being used, and that will force ipnat to reload, etc. The ppp-user file, as you say, might need to reload pf if necessary. A simple patch could be thought up and attached here, huh? Can you post some of these comments as a bug (PR) to the FreeBSD system? I have one that could probably be fixed if my patch is used. See my related PR at http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/81606 You might refer to PR 81606 as potentially being a similar issue with rcng. These thigns are slowly coming to light. rcng has got a lot of little tweaks it needs, especially if we start to let ports interact with the system rcng files. Billy