From owner-freebsd-stable Thu Mar 15 7:46: 2 2001 Delivered-To: freebsd-stable@freebsd.org Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by hub.freebsd.org (Postfix) with ESMTP id 9BD7537B718 for ; Thu, 15 Mar 2001 07:45:58 -0800 (PST) (envelope-from mvh@ix.netcom.com) Received: from netcom1.netcom.com (lai-ca3a-228.ix.netcom.com [209.110.240.228]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id KAA18781; Thu, 15 Mar 2001 10:45:55 -0500 (EST) Received: by netcom1.netcom.com (Postfix, from userid 1000) id C53AC113AF2; Thu, 15 Mar 2001 07:45:47 -0800 (PST) From: Mike Harding To: Gerhard.Sittig@gmx.net Cc: stable@FreeBSD.ORG In-reply-to: <20010314203520.Y20830@speedy.gsinet> (message from Gerhard Sittig on Wed, 14 Mar 2001 20:35:20 +0100) Subject: Re: /etc/default/rc.conf bad default ipfilter_flags? References: <20010314113640.741AF1140FC@netcom1.netcom.com> <20010314203520.Y20830@speedy.gsinet> Message-Id: <20010315154547.C53AC113AF2@netcom1.netcom.com> Date: Thu, 15 Mar 2001 07:45:47 -0800 (PST) Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I don't believe it will load the module - it, as you say, seems to do the opposite of 'ipf -D'. As ipf seems to be enabled by default, you get a (harmless?) error message. 'ipf -y' should be in your ppp.linkup, but if you use the autodial/nat mode it won't work because the link won't come up until ppp dials, and it won't dial until traffic goes out tun0, and that won't happen because ipf doesn't know about the interface. Needs to be in the network startup. Darren, you out there? Thanks for a great package btw... - MIke Harding Date: Wed, 14 Mar 2001 20:35:20 +0100 From: Gerhard Sittig Content-Type: text/plain; charset=us-ascii Organization: System Defenestrators Inc. Sender: owner-freebsd-stable@FreeBSD.ORG X-Loop: FreeBSD.ORG Precedence: bulk On Wed, Mar 14, 2001 at 03:36 -0800, Mike Harding wrote: > > I can confirm that the "-E" seems to be unecessary for both > kernel and kernel module loads. I'm "guilty" of having provided this default setting (see PR conf/20202). :) It's because I tried the OpenBSD invocation (and what I got from the excellent "IPFilter HowTo") in FreeBSD, too. Admittedly I never tried anything else than compiling ipf(4) into the kernel. And I honestly assume a module loaded by the loader (i.e. before / together with the kernel) to be more of an integral part of the kernel than a module loaded much later after having run for some time without the additional functionality. I'm not 100% positive what the -E switch does to the ipf(8) command. If it makes it load the module at all, that's of course a problem when the functionality is already active. "man 8 ipf" tells me: -E Enable the filter (if disabled). Not effective for loadable kernel versions. so I guess it's about having pass as the default action? Or is it the opposite of temporarily issuing "ipf -D" for whatever reason? To summarize: I don't know. And as discussed (in quite some detail) in "man 5 rc.conf" I don't care about ipf(4) being a module. :> Just state when you're sure ipfilter_flags could always be empty and file a PR to have the default corrected ... > I can also confirm that ppp does not play well with ipfilter > because ipfilter needs a 'ipf -y' to pick up the dynamically > configured interfaces - it's set up before these interfaces > exist, so that any rules applying to them don't work! I stick > a 'ipf -y' near the end of pass 1 in /etc/rc.network but this > is my local hack. Are you referring to conf/22859? There's a followup by me discussing three methods of avoiding the problem. One of them being really easy to apply: it's the "ipf -y" you state. The PR got assigned to darrenr, just ask him kindly to commit the three line extension. But yet I feel that ppp users usually have an "ipf -y" in their /etc/ppp/ppp.link{up,down} anyway ... virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message