From owner-freebsd-stable Sun Jan 27 1:50:27 2002 Delivered-To: freebsd-stable@freebsd.org Received: from hawk.prod.itd.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 8BFAB37B402 for ; Sun, 27 Jan 2002 01:50:25 -0800 (PST) Received: from dialup-209.245.129.180.dial1.sanjose1.level3.net ([209.245.129.180] helo=blossom.cjclark.org) by hawk.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16Ulwy-0006VY-00; Sun, 27 Jan 2002 01:50:17 -0800 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.3) id g0R9mvV25181; Sun, 27 Jan 2002 01:48:57 -0800 (PST) (envelope-from cjc) Date: Sun, 27 Jan 2002 01:48:48 -0800 From: "Crist J. Clark" To: "M. Warner Losh" Cc: nate@yogotech.com, stable@FreeBSD.ORG Subject: Re: Firewall config non-intuitiveness Message-ID: <20020127014848.F23259@blossom.cjclark.org> References: <15443.42601.781625.356369@caddis.yogotech.com> <20020127.002337.37328950.imp@village.org> <15443.44156.595426.139371@caddis.yogotech.com> <20020127.004656.53474822.imp@village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020127.004656.53474822.imp@village.org>; from imp@village.org on Sun, Jan 27, 2002 at 12:46:56AM -0700 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Warner, if the proposed change were to be made, you could get the same effect by doing, firewall_enable="YES" firewall_script="/dev/null" Which I think more accurately describes the behavior you want (if someone were to browse the rc.conf and try to understand your configuration, they'd be more likely to understand what you are trying to do if they saw the above). You want to enable firewalling, but don't want to load any rules. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 2: 1:58 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by hub.freebsd.org (Postfix) with ESMTP id 2EECF37B400; Sun, 27 Jan 2002 02:01:52 -0800 (PST) Received: from levais.imp.ch (levais.imp.ch [157.161.4.66]) by mail.imp.ch (8.11.1/8.11.1) with ESMTP id g0RA1ov96604; Sun, 27 Jan 2002 11:01:50 +0100 (CET) (envelope-from Martin.Blapp@imp.ch) Date: Sun, 27 Jan 2002 11:01:48 +0100 (CET) From: Martin Blapp To: Greg Lehey Cc: Subject: Re: double fault with vinum and 4.5 RC3 In-Reply-To: <20020127142643.A19909@wantadilla.lemis.com> Message-ID: <20020127105617.I67380-100000@levais.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi Greg. > As I've mentioned elsewhere, this is seriously suboptimal. The > "mirror" command is a toy for people getting used to Vinum. You want Why is this suboptimal ? It's fast done. It seems to work. Else you have to say: "not supported, since it can panic your machine". > a proper config file. Then create one drive per spindle, and choose > your subdisk sizes to match what you want. Specifically, your config > file should look like this: So why this isn't noted in the documentation ? Also the documentation is not up to date. vinum(4) still refers to raw disks etc. > > took da0 out and replaced it with a new disk. I switched jumpers, so > > da0 got da1, and da1 got da0 and rebooted. > > I still don't know why you're switching jumpers. That's not needed. > But it doesn't change anything. Vinum still doesn't support booting from a vinum volume. If I do not switch jumpers, I'm not able to boot. I could also change the SCSI boot ID in the BIOS, but then FreeBSD cannot boot into Multiuser, since it cannot mount root from ad1s1a (it likes to do it from ad0s1a) > > > > And boom I got a double fault. > > Yes, we've found the cause of that. What I get now is: I'll look now it fixes my problem. Just rebooted and made new kernel. Martin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 2:11:36 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by hub.freebsd.org (Postfix) with ESMTP id 22DA137B404; Sun, 27 Jan 2002 02:11:33 -0800 (PST) Received: from levais.imp.ch (levais.imp.ch [157.161.4.66]) by mail.imp.ch (8.11.1/8.11.1) with ESMTP id g0RABWv97408; Sun, 27 Jan 2002 11:11:32 +0100 (CET) (envelope-from Martin.Blapp@imp.ch) Date: Sun, 27 Jan 2002 11:11:30 +0100 (CET) From: Martin Blapp To: Greg Lehey Cc: Thomas Moestl , , Subject: Re: double fault with vinum and 4.5 RC3 In-Reply-To: <20020127140703.A41130@wantadilla.lemis.com> Message-ID: <20020127110808.A67380-100000@levais.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi all, > I tried looking, but the net connection was terrible. Anyway, I've > been able to reproduce it here, and I have a patch which should make > it go away: Just tried the patch and it fixes my problem completly. Thanks Thomas for the excelent work you've done. And thank you Greg for providing a fix. We really should include this important fix in 4.5-Release. So I sent a copy to re@freebsd.org too. Can you send them your fix too Greg ? Martin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 2:34: 9 2002 Delivered-To: freebsd-stable@freebsd.org Received: from smtp.web.de (smtp02.web.de [217.72.192.151]) by hub.freebsd.org (Postfix) with ESMTP id 3175B37B400 for ; Sun, 27 Jan 2002 02:34:07 -0800 (PST) Received: from p50856b45.dip.t-dialin.net ([80.133.107.69] helo=web.de) by smtp.web.de with asmtp (Exim 4.11 #37) id 16UmdN-0002pR-00; Sun, 27 Jan 2002 11:34:01 +0100 Message-ID: <3C53D713.2030008@web.de> Date: Sun, 27 Jan 2002 11:31:47 +0100 From: Jens Rehsack Reply-To: rehsack@liwing.de Organization: LiWing IT-Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: de-DE MIME-Version: 1.0 To: stable@freebsd.org Subject: which dumps core on 4.5-RC2 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi there, on my just installed DSL-Router based on FreeBSD 4.5-RC2 iso image with a new compiled kernel (added NETGRAPH, removed IPv6): "which" abc results in showing the full path and terminates with "illegal instruction: core dumped" My System is: AMD 5x86, 100MHz 16 MB RAM 3G HD 2x ne2000 compatible NIC's floppy I've configured and have running ipfilter (but I don't think that matters) Hopes s.o. find the bug (or by me...) Jens To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 3:23:22 2002 Delivered-To: freebsd-stable@freebsd.org Received: from emmi.physik.TU-Berlin.DE (emmi.physik.TU-Berlin.DE [130.149.160.103]) by hub.freebsd.org (Postfix) with ESMTP id 9ED5D37B400 for ; Sun, 27 Jan 2002 03:23:14 -0800 (PST) Received: from rosa.physik.TU-Berlin.DE (rosa.physik.TU-Berlin.DE [130.149.160.209]) by emmi.physik.TU-Berlin.DE (8.11.6/8.11.6) with ESMTP id g0RBNCN55533; Sun, 27 Jan 2002 12:23:12 +0100 (CET) (envelope-from jschlesn@emmi.physik.TU-Berlin.DE) Received: (from jschlesn@localhost) by rosa.physik.TU-Berlin.DE (8.11.6/8.11.1) id g0RBNBR28179; Sun, 27 Jan 2002 12:23:11 +0100 (CET) (envelope-from jschlesn) Date: Sun, 27 Jan 2002 12:23:11 +0100 From: Jan Schlesner To: rehsack@liwing.de Cc: stable@freebsd.org Subject: Re: which dumps core on 4.5-RC2 Message-ID: <20020127122311.A28061@physik.TU-Berlin.DE> References: <3C53D713.2030008@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C53D713.2030008@web.de>; from rehsack@web.de on Sun, Jan 27, 2002 at 11:31:47AM +0100 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, On Sun, Jan 27, 2002 at 11:31:47AM +0100, Jens Rehsack wrote: > on my just installed DSL-Router based on FreeBSD 4.5-RC2 iso image > with a new compiled kernel (added NETGRAPH, removed IPv6): > > "which" abc results in showing the full path and terminates with > "illegal instruction: core dumped" that looks like, that your system and your kernel isn't build from the same sources. Have you install the sources from the CD? I don't know the iso-image, but I have no problems with 4.5-RC installed from the cvsuped sources. If you cvsup the sources an rebuild your system and kernel, I'm sure the problem disapear. Jan -- [ gpg key: http://wwwnlds.physik.tu-berlin.de/~schlesner/jschlesn.gpg ] [ key fingerprint: 4236 3497 C4CF 4F3A 274F B6E2 C4F6 B639 1DF4 CF0A ] -- It's better to reign in hell, than to serve in heaven... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 3:31:46 2002 Delivered-To: freebsd-stable@freebsd.org Received: from smtp.web.de (smtp02.web.de [217.72.192.151]) by hub.freebsd.org (Postfix) with ESMTP id 26C0937B404 for ; Sun, 27 Jan 2002 03:31:42 -0800 (PST) Received: from p50856b45.dip.t-dialin.net ([80.133.107.69] helo=web.de) by smtp.web.de with asmtp (Exim 4.11 #37) id 16UnVf-0001Ey-00; Sun, 27 Jan 2002 12:30:07 +0100 Message-ID: <3C53E43A.8010606@web.de> Date: Sun, 27 Jan 2002 12:27:54 +0100 From: Jens Rehsack Reply-To: rehsack@liwing.de Organization: LiWing IT-Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: de-DE MIME-Version: 1.0 To: Jan Schlesner Cc: stable@freebsd.org Subject: Re: which dumps core on 4.5-RC2 References: <3C53D713.2030008@web.de> <20020127122311.A28061@physik.TU-Berlin.DE> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi Jan, from the cvsup-Sources I do not have a problem, too. But on this machine I do not want to compile world, because the 16MB results in 8 hours kernel compile, so I decided to keep the sources from CD. Jens Jan Schlesner wrote: > Hi, > > On Sun, Jan 27, 2002 at 11:31:47AM +0100, Jens Rehsack wrote: > >>on my just installed DSL-Router based on FreeBSD 4.5-RC2 iso image >>with a new compiled kernel (added NETGRAPH, removed IPv6): >> >>"which" abc results in showing the full path and terminates with >>"illegal instruction: core dumped" >> > > that looks like, that your system and your kernel isn't build from the > same sources. Have you install the sources from the CD? I don't know > the iso-image, but I have no problems with 4.5-RC installed from the > cvsuped sources. If you cvsup the sources an rebuild your system and > kernel, I'm sure the problem disapear. > > Jan > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 3:36: 9 2002 Delivered-To: freebsd-stable@freebsd.org Received: from moreton.com.au (pacific.moreton.com.au [203.143.238.4]) by hub.freebsd.org (Postfix) with ESMTP id B11AD37B400 for ; Sun, 27 Jan 2002 03:36:04 -0800 (PST) Received: from pdh by bofh.internal.moreton.com.au with local (Exim 3.33 #1 (Debian)) id 16Uj1f-0000DR-00 for ; Sun, 27 Jan 2002 16:42:51 +1000 Date: Sun, 27 Jan 2002 16:42:50 +1000 From: Phil Homewood To: stable@freebsd.org Subject: FS corruption w/softupdates on 4.5-RC ? Message-ID: <20020127064250.GA333@moreton.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i X-PGP-Key-ID: 1024/EDE1CCB5 1996/02/26 X-PGP-Fingerprint: 86 B5 37 9D 5B ED EC BB 7C 0D B5 D6 C2 45 13 F1 X-PGP-Public-Key-Finger: phil@rivendell.apana.org.au X-PGP-Public-Key-URL: http://rivendell.apana.org.au/~phil/pgp.asc Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG A system recently upgraded from a 6 month old 4.3-STABLE image appears to be suddenly experiencing massive FS corruption (or fsck is very confused when checking a readonly-mounted FS.) I've been following what seem to be a lot of dead-ends on this, but seem to have tracked it down to the following specifics: * Only softupdate filesystems appear to have the problem. I first thought I saw it on a non-softupdate FS, but may have been mistaken. * 4.5-RC kernel (as of Jan 26, also reupdated today) breaks, 4.3-STABLE does not. (Tried 4.4-REL, no breakage, but the kernel I had didn't have softupdates, so inconclusive.) * GENERIC kernel is sufficient to reproduce * Unmounting the FS and fscking it doesn't *seem* to show the problem up. fscking the filesystem after remounting readonly does cause breakage. Unmounting, remounting readonly, and fscking seems safe. * dd'ing a mounted fs to another identical device (I've been backing up the root fs to a twin partition like this forever) and then fscking the backup device exhibits the breakage. (Maybe I should change that to dump|restore, like I thought I'd been doing all along :-) * The bug seems to be most easily tickled using MAKEDEV. I can reproduce the problem reliably by doing: # newfs /dev/da0s2g # tunefs -n enable /dev/da0s2g # mount /dev/da0s2g /tmp # cd /tmp # mkdir dev # cd dev # cp /dev/MAKEDEV . # sh MAKEDEV all # cd / # mount -u -r /tmp # fsck /tmp * Occasionally the fsck or (if fsck comes up clean) subsequent mount will panic: so far I've seen panic: handle_workitem_remove: bad file delta softdep_deallocate_dependencies: dangling deps (that one was interspersed with fsck output, so I could have got it wrong) and one that may have involved a dup alloc; I unfortunately didn't copy it down. Attached is a copy of my dmesg and kernel config. Any clues greatfully appreciated... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 3:36:30 2002 Delivered-To: freebsd-stable@freebsd.org Received: from moreton.com.au (pacific.moreton.com.au [203.143.238.4]) by hub.freebsd.org (Postfix) with ESMTP id 348EA37B404 for ; Sun, 27 Jan 2002 03:36:13 -0800 (PST) Received: from pdh by bofh.internal.moreton.com.au with local (Exim 3.33 #1 (Debian)) id 16Uj1f-0000DR-00 for ; Sun, 27 Jan 2002 16:42:51 +1000 Date: Sun, 27 Jan 2002 16:42:50 +1000 From: Phil Homewood To: stable@freebsd.org Subject: FS corruption w/softupdates on 4.5-RC ? Message-ID: <20020127064250.GA333@moreton.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i X-PGP-Key-ID: 1024/EDE1CCB5 1996/02/26 X-PGP-Fingerprint: 86 B5 37 9D 5B ED EC BB 7C 0D B5 D6 C2 45 13 F1 X-PGP-Public-Key-Finger: phil@rivendell.apana.org.au X-PGP-Public-Key-URL: http://rivendell.apana.org.au/~phil/pgp.asc Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG A system recently upgraded from a 6 month old 4.3-STABLE image appears to be suddenly experiencing massive FS corruption (or fsck is very confused when checking a readonly-mounted FS.) I've been following what seem to be a lot of dead-ends on this, but seem to have tracked it down to the following specifics: * Only softupdate filesystems appear to have the problem. I first thought I saw it on a non-softupdate FS, but may have been mistaken. * 4.5-RC kernel (as of Jan 26, also reupdated today) breaks, 4.3-STABLE does not. (Tried 4.4-REL, no breakage, but the kernel I had didn't have softupdates, so inconclusive.) * GENERIC kernel is sufficient to reproduce * Unmounting the FS and fscking it doesn't *seem* to show the problem up. fscking the filesystem after remounting readonly does cause breakage. Unmounting, remounting readonly, and fscking seems safe. * dd'ing a mounted fs to another identical device (I've been backing up the root fs to a twin partition like this forever) and then fscking the backup device exhibits the breakage. (Maybe I should change that to dump|restore, like I thought I'd been doing all along :-) * The bug seems to be most easily tickled using MAKEDEV. I can reproduce the problem reliably by doing: # newfs /dev/da0s2g # tunefs -n enable /dev/da0s2g # mount /dev/da0s2g /tmp # cd /tmp # mkdir dev # cd dev # cp /dev/MAKEDEV . # sh MAKEDEV all # cd / # mount -u -r /tmp # fsck /tmp * Occasionally the fsck or (if fsck comes up clean) subsequent mount will panic: so far I've seen panic: handle_workitem_remove: bad file delta softdep_deallocate_dependencies: dangling deps (that one was interspersed with fsck output, so I could have got it wrong) and one that may have involved a dup alloc; I unfortunately didn't copy it down. Attached is a copy of my dmesg and kernel config. Any clues greatfully appreciated... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 3:37:21 2002 Delivered-To: freebsd-stable@freebsd.org Received: from moreton.com.au (pacific.moreton.com.au [203.143.238.4]) by hub.freebsd.org (Postfix) with ESMTP id 0B24F37B402 for ; Sun, 27 Jan 2002 03:36:08 -0800 (PST) Received: from pdh by bofh.internal.moreton.com.au with local (Exim 3.33 #1 (Debian)) id 16UjeM-0000G1-00 for ; Sun, 27 Jan 2002 17:22:50 +1000 Date: Sun, 27 Jan 2002 17:22:50 +1000 From: Phil Homewood To: stable@freebsd.org Subject: Re: FS corruption w/softupdates on 4.5-RC ? Message-ID: <20020127072250.GA976@moreton.com.au> References: <20020127064250.GA333@moreton.com.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline In-Reply-To: <20020127064250.GA333@moreton.com.au> User-Agent: Mutt/1.3.25i X-PGP-Key-ID: 1024/EDE1CCB5 1996/02/26 X-PGP-Fingerprint: 86 B5 37 9D 5B ED EC BB 7C 0D B5 D6 C2 45 13 F1 X-PGP-Public-Key-Finger: phil@rivendell.apana.org.au X-PGP-Public-Key-URL: http://rivendell.apana.org.au/~phil/pgp.asc Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Phil Homewood wrote: > Attached is a copy of my dmesg and kernel config. Well, it would have been, if I hadn't been distracted by... ooh, shiny... Um, yeah. Here it is. (Also another point: UFS_DIRHASH appears to make no difference.) --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.out" Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.5-RC #7: Sun Jan 27 15:30:53 EST 2002 root@:/usr/obj/usr/src/sys/DORFL Timecounter "i8254" frequency 1193182 Hz CPU: AMD Athlon(tm) Processor (1299.38-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x642 Stepping = 2 Features=0x183f9ff AMD Features=0xc0440000<,AMIE,DSP,3DNow!> real memory = 536870912 (524288K bytes) avail memory = 518922240 (506760K bytes) Preloaded elf kernel "kernel" at 0xc03a7000. Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 9 entries at 0xc00fdbd0 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib2: at device 1.0 on pci0 pci1: on pcib2 pci1: at 0.0 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xc000-0xc00f at device 7.1 on pci0 atapci0: Correcting VIA config for southbridge data corruption bug ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 chip2: port 0xd400-0xd403,0xd000-0xd003,0xcc00-0xccff irq 12 at device 7.5 on pci0 ahc0: port 0xdc00-0xdcff mem 0xdd021000-0xdd021fff irq 11 at device 8.0 on pci0 aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/255 SCBs fxp0: port 0xe000-0xe03f mem 0xdd000000-0xdd01ffff,0xdd020000-0xdd020fff irq 10 at device 9.0 on pci0 fxp0: Ethernet address 00:02:b3:5e:1a:bb inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcib1: on motherboard pci2: on pcib1 orm0:

subscribe

------=_NextPart_000_0001_01C1A739.0138AAF0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 13:57:20 2002 Delivered-To: freebsd-stable@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id B56CC37B400 for ; Sun, 27 Jan 2002 13:57:17 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g0RLvGo13767; Sun, 27 Jan 2002 14:57:16 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g0RLvFx04784; Sun, 27 Jan 2002 14:57:15 -0700 (MST) (envelope-from imp@village.org) Date: Sun, 27 Jan 2002 14:56:36 -0700 (MST) Message-Id: <20020127.145636.75560737.imp@village.org> To: joe.halpin@attbi.com Cc: freebsd-stable@FreeBSD.ORG Subject: Re: FreeBSD install doesn't see the whole disk From: "M. Warner Losh" In-Reply-To: <3C546F38.AE459B3A@attbi.com> References: <3C546F38.AE459B3A@attbi.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <3C546F38.AE459B3A@attbi.com> Joe Halpin writes: : Out of curiosity, what's different between FreeBSD and Linx/DOS/BIOS : such that they get the right disk parameters but FreeBSD doesn't? I doubt that there's anything different. I recently grabbed a 40G IDE disk and it showed up as 31G until I removed the 4092 limit jumper. The 4092 limit jumper is next to the Cable Select jumper and easily confused with it. Short of access to the systems, you ask a question that will be almost impossible to answer. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 14: 3:53 2002 Delivered-To: freebsd-stable@freebsd.org Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14]) by hub.freebsd.org (Postfix) with ESMTP id 77E2B37B42C for ; Sun, 27 Jan 2002 14:03:41 -0800 (PST) Received: from [192.168.1.10] (helo=den2) by vimfuego.saarinen.org with esmtp (Exim 3.33 #1 (Red Hack)) id 16UxOc-0002u9-00; Mon, 28 Jan 2002 11:03:30 +1300 Date: Mon, 28 Jan 2002 11:03:30 +1300 (New Zealand Daylight Time) From: Juha Saarinen To: "M. Warner Losh" Cc: "joe.halpin@attbi.com" , "freebsd-stable@FreeBSD.ORG" Subject: Re: FreeBSD install doesn't see the whole disk In-Reply-To: <20020127.145636.75560737.imp@village.org> Message-ID: X-Message-Flag: "Please remember to trim your quotes." X-X-Sender: juha@vimfuego.saarinen.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 27 Jan 2002, M. Warner Losh wrote: > Short of access to the systems, you ask a question that will be almost > impossible to answer. I've had Windows and Linux boxes going up their own debuggers with CSEL as well. You're probably looking at an interaction between the BIOS, the IDE devices themselves, and the OS device drivers. Anyway, the long and short of it is that CSEL needs CSEL cable, CSEL on both drives, and CSEL-capable interface. Can't see the point of CSEL myself actually... what's so hard about setting one drive as Master and the other as Slave? -- Juha Take off every sig! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 14:50:57 2002 Delivered-To: freebsd-stable@freebsd.org Received: from rockstar.stealthgeeks.net (h-66-134-120-173.LSANCA54.covad.net [66.134.120.173]) by hub.freebsd.org (Postfix) with SMTP id 2F22737B416 for ; Sun, 27 Jan 2002 14:50:51 -0800 (PST) Received: (qmail 82502 invoked by uid 1001); 27 Jan 2002 22:50:50 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 27 Jan 2002 22:50:50 -0000 Date: Sun, 27 Jan 2002 14:50:50 -0800 (PST) From: Patrick Greenwell To: Gerhard Sittig Cc: stable@freebsd.org Subject: Re: Firewall config non-intuitiveness In-Reply-To: <20020127220923.B1494@shell.gsinet.sittig.org> Message-ID: <20020127134511.Q81780-100000@rockstar.stealthgeeks.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 27 Jan 2002, Gerhard Sittig wrote: > I filed a PR which does adjust the rc.conf comment (I understand > that LINT resp. NOTES as well as "man 5 rc.conf" both told the > originator of the thread what would happen while rc.conf was too > short and not authoritative enough a source to stop him from > shooting into his foot). I didn't address this issue earlier because I was more concerned with having something called "firewall_enable" do something that made sense when it was set to no. However, since you along with a couple of others have made the claim that this mislabled behavior is well-documented, I'd like to point out why I believe you are mistaken. Here's the relevent "documentation" that has been mentioned: From LINT: # WARNING: IPFIREWALL defaults to a policy of "deny ip from any to any" # and if you do not add other rules during startup to allow access, # YOU WILL LOCK YOURSELF OUT. It is suggested that you set # firewall_type=open in /etc/rc.conf when first enabling this feature, # then refining the firewall rules in /etc/rc.firewall after you've tested # that the new kernel feature works properly. See anything in there about the firewall_enable variable? Anything that says something along the lines of "the firewall_enable variable has no effect if set to no?" While we're on the subject, the above documentation is incomplete as it fails to mention that you need to set firewall_enable to yes in order for the rc.firewall script to be executed(if I'm reading /etc/rc.network correctly.) The results of following the documentation outlined in LINT as written is that you'd still be locked out of your box. and here's the info from the rc.conf man page firewall_enable (bool) Set to ``YES'' to load firewall rules at startup. If the kernel was not built with IPFIREWALL, the ipfw kernel module will be loaded. See also ipfilter_enable. See anything in there about setting firewall_enable to "no"? So much for well-documented behavior. Really, I'm just arguing for doing something that makes sense, and the current behavior does not qualify, regardless of how long it's been understood to be broken that way. Even if this behavior were adequately documented, which it isn't, it's extremely user-unfriendly to have no mean yes. At this point I'm rather reticent to even bother submitting anything to the "security officer" role as Warner has indicated that he's part of that role and will speak out against it in the name of security. I'm not a member of the inner circle, just a long-time user who saw some confusing behavior and thought that there was an opportunity to fix it. I'll go tilt at some other windmills now. :-) /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Patrick Greenwell Stealthgeeks,LLC. Operations Consulting http://www.stealthgeeks.net \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 15:41:37 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mao.stokely.org (mao.stokely.org [65.84.64.228]) by hub.freebsd.org (Postfix) with ESMTP id 0D43637B416 for ; Sun, 27 Jan 2002 15:41:32 -0800 (PST) Received: by mao.stokely.org (Postfix, from userid 2074) id 25AE54B661; Sun, 27 Jan 2002 15:41:31 -0800 (PST) Date: Sun, 27 Jan 2002 15:41:31 -0800 From: murray@stokely.org To: Erik Trulsson Cc: Matthew Emmerton , "Thomas T. Veldhouse" , freebsd-stable@freebsd.org Subject: Re: RELENG_4_5 tagged yet? Message-ID: <20020127234131.GB9395@freebsdmall.com> References: <006801c1a750$c15c04a0$0101a8c0@cascade> <004201c1a75f$21019c90$1200a8c0@gsicomp.on.ca> <20020127182639.GA80199@student.uu.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QKdGvSO+nmPlgiQ/" Content-Disposition: inline In-Reply-To: <20020127182639.GA80199@student.uu.se> User-Agent: Mutt/1.3.25i X-GPG-Key-ID: 1024D/0E451F7D X-GPG-Key-Fingerprint: E2CA 411D DD44 53FD BB4B 3CB5 B4D7 10A2 0E45 1F7D Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --QKdGvSO+nmPlgiQ/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 27, 2002 at 07:26:39PM +0100, Erik Trulsson wrote: > On Sun, Jan 27, 2002 at 01:19:15PM -0500, Matthew Emmerton wrote: > >=20 > >=20 > > > Has the release been tagged yet and the bugfix branch been created? > >=20 > > I was browsing the web CVS last night and noticed some RELENG_4_5 tags. > > That probably means that RELENG_4_5_0_RELEASE tags are also present, but > > you'd have to check to be sure. >=20 > The RELENG_4_5_0_RELEASE tags are not yet present. The RELENG_4_5 tags > are in place. Yes. I'm waiting for the package builds to complete and 3 trivial security-related fixes to be committed to the RELENG_4_5 branch before we lay down the RELENG_4_5_0_RELEASE tag. The release bits will likely not be available from the FTP sites until tommorow. - Murray --QKdGvSO+nmPlgiQ/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (SunOS) Comment: For info see http://www.gnupg.org iD8DBQE8VJAqtNcQog5FH30RAqR+AKC5xijiMe9vV5p3FcSguujYedo5RwCcDE+Y 977td+p/h+tJ7IUyT4OUr14= =TAyX -----END PGP SIGNATURE----- --QKdGvSO+nmPlgiQ/-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 15:43:13 2002 Delivered-To: freebsd-stable@freebsd.org Received: from sapphire.tenebras.com (sapphire.tenebras.com [66.92.188.241]) by hub.freebsd.org (Postfix) with ESMTP id C060C37B400 for ; Sun, 27 Jan 2002 15:42:55 -0800 (PST) Received: from tenebras.com (localhost [127.0.0.1]) by sapphire.tenebras.com (8.11.6/8.11.6) with ESMTP id g0RNfiN75384; Sun, 27 Jan 2002 15:41:45 -0800 (PST) (envelope-from kudzu@tenebras.com) Message-ID: <3C549033.B51B5EFE@tenebras.com> Date: Sun, 27 Jan 2002 15:41:39 -0800 From: Michael Sierchio X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams , Bob K , Patrick Greenwell , stable@FreeBSD.ORG Subject: Re: Firewall config non-intuitiveness References: <000c01c1a5ff$a4539870$0101a8c0@cascade> <20020125165307.C54729-100000@rockstar.stealthgeeks.net> <20020125203328.A454@yip.org> <15443.41177.259786.242696@caddis.yogotech.com> <3C53A5A2.A5F8FBD6@tenebras.com> <15443.42601.781625.356369@caddis.yogotech.com> <3C543976.147A50E2@tenebras.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Michael Sierchio wrote: > > Nate Williams wrote: > > > See above. It can easily be done in a more standard way. (One can > > argue that the '-z' should be the default flag, but so far I've failed > > to convince Warner of this fact. :) :) Thanks, Nate - for the sake of stability I had been using an old version of pccard_ether. 'mergemaster' is occasionally useful... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 15:43:15 2002 Delivered-To: freebsd-stable@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id AD6E837B417; Sun, 27 Jan 2002 15:42:49 -0800 (PST) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 7E66878318; Mon, 28 Jan 2002 09:43:55 +1030 (CST) Date: Mon, 28 Jan 2002 09:43:55 +1030 From: Greg Lehey To: Martin Blapp Cc: Bernd Walter , freebsd-stable@FreeBSD.ORG, tmm@FreeBSD.ORG Subject: Re: double fault with vinum and 4.5 RC3 Message-ID: <20020128094355.D72512@wantadilla.lemis.com> References: <20020127153009.B92489@cicely8.cicely.de> <20020127202242.H68322-100000@levais.imp.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020127202242.H68322-100000@levais.imp.ch> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sunday, 27 January 2002 at 20:24:12 +0100, Martin Blapp wrote: > > I found my previous problem: > > It is absolutly needed that the old dates are erased. > Else it can make big problems for vinum. > > eg: > > dd bs=4096k if=/dev/zero of=/dev/da0e > dd bs=4096k if=/dev/zero of=/dev/da1e > > After that it worked. You haven't found any problem. You've just found another way to avoid using the correct configuration procedure. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 15:43:10 2002 Delivered-To: freebsd-stable@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 6345637B402 for ; Sun, 27 Jan 2002 15:42:49 -0800 (PST) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 9C14978317; Mon, 28 Jan 2002 09:54:19 +1030 (CST) Date: Mon, 28 Jan 2002 09:54:19 +1030 From: Greg Lehey To: Martin Blapp Cc: freebsd-stable@FreeBSD.org Subject: Re: double fault with vinum and 4.5 RC3 Message-ID: <20020128095419.G72512@wantadilla.lemis.com> References: <20020127142643.A19909@wantadilla.lemis.com> <20020127105617.I67380-100000@levais.imp.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020127105617.I67380-100000@levais.imp.ch> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sunday, 27 January 2002 at 11:01:48 +0100, Martin Blapp wrote: > > Hi Greg. > >> As I've mentioned elsewhere, this is seriously suboptimal. The >> "mirror" command is a toy for people getting used to Vinum. You want > > Why is this suboptimal ? It's fast done. It wastes time and space. > It seems to work. Else you have to say: "not supported, since it can > panic your machine". It does not panic your machine. >> a proper config file. Then create one drive per spindle, and choose >> your subdisk sizes to match what you want. Specifically, your config >> file should look like this: > > So why this isn't noted in the documentation ? It is. I have a strong suspicion that you haven't read the documentation. > Also the documentation is not up to date. vinum(4) still refers to > raw disks etc. Yes, that needs changing. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 15:44:54 2002 Delivered-To: freebsd-stable@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 9F6FE37B41E; Sun, 27 Jan 2002 15:43:00 -0800 (PST) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id A7D247831D; Mon, 28 Jan 2002 09:57:58 +1030 (CST) Date: Mon, 28 Jan 2002 09:57:58 +1030 From: Greg Lehey To: Martin Blapp Cc: freebsd-stable@FreeBSD.org, tmm@FreeBSD.org Subject: Re: double fault with vinum and 4.5 RC3 Message-ID: <20020128095758.H72512@wantadilla.lemis.com> References: <20020127142643.A19909@wantadilla.lemis.com> <20020127132210.Y67380-100000@levais.imp.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020127132210.Y67380-100000@levais.imp.ch> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sunday, 27 January 2002 at 13:40:29 +0100, Martin Blapp wrote: > > Greg, > >> As I've mentioned elsewhere, this is seriously suboptimal. The >> "mirror" command is a toy for people getting used to Vinum. You want >> a proper config file. Then create one drive per spindle, and choose >> your subdisk sizes to match what you want. Specifically, your config >> file should look like this: >> >> drive 0 device /dev/da0e >> drive 1 device /dev/da1e >> volume var setupstate >> plex org concat >> sd drive 0 len 2096000s >> plex org concat >> sd drive 1 len 2096000s >> volume docsis setupstate >> plex org concat >> sd drive 0 len 1257000s >> plex org concat >> sd drive 1 len 1257000s >> volume docsisvar setupstate >> plex org concat >> sd drive 0 len 4651000s >> plex org concat >> sd drive 1 len 4651000s > > Is this really mirrored ? I want a mirror, not a concatenated drive ! > I want RAID 1. You obviously haven't understood the documentation. > And - this isn't very optimal for a user to create. > > I do not want to calculate the sd offset size. You have to know how big your drives are. The method you use requires repartitioning the drive. You can't do that while any partition is open, but you do need to calculate the values. > IMHO there should be a way for vinum to add this dynamically > like: > > vinum sd-add -d 0 -n var -l 1GB > vinum sd-add -d 0 -n docsis -l 6GB > vinum sd-add -d 0 -n docsisvar -l end Well, apart from the obvious missing information here, what's the difference? The difference is the possibility of race conditions that this alternative adds. > A program under unix does not have to be very cryptic, it also has > to be userfriendly. I think your version there is more cryptic. "-n" presumably means "name". "-d 0" presumably means "drive". Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 15:45:31 2002 Delivered-To: freebsd-stable@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id DC14E37B41B for ; Sun, 27 Jan 2002 15:42:49 -0800 (PST) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 6831778312; Sun, 27 Jan 2002 14:26:43 +1030 (CST) Date: Sun, 27 Jan 2002 14:26:43 +1030 From: Greg Lehey To: Martin Blapp Cc: freebsd-stable@freebsd.org Subject: Re: double fault with vinum and 4.5 RC3 Message-ID: <20020127142643.A19909@wantadilla.lemis.com> References: <20020124184810.M47234-100000@levais.imp.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020124184810.M47234-100000@levais.imp.ch> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thursday, 24 January 2002 at 19:14:10 +0100, Martin Blapp wrote: > > ... unfortunatly I'm not able to recover from a simulated > disk-crash. Here is what I made: > > Two disks: da0, da0, both 35GB > > 1) Installed FreeBSD on da0s1a > > 2) mount so single user mode > dd bs=4096k if=/dev/da0 of=/dev/da1 > > (to have the root on disk 2 too, I did this cold mirror) > > I plan to do a cold mirror procedure each evening, since > the root will be mostly static anyway. > > mount /dev/da1a /mnt > cd /mnt && dump -rf 0 /dev/da0a -f - | restore -xf - > rm /mnt/restoresytable > umount /mnt > > 3) I edited the disklabels and set da0e, da0f, da0g > to type vinum > > # vinum mirror -n var /dev/da0e /dev/da1e > # vinum mirror -n docsis /dev/da0f /dev/da1f > # vinum mirror -n docsisvar /dev/da0g /dev/da1g As I've mentioned elsewhere, this is seriously suboptimal. The "mirror" command is a toy for people getting used to Vinum. You want a proper config file. Then create one drive per spindle, and choose your subdisk sizes to match what you want. Specifically, your config file should look like this: drive 0 device /dev/da0e drive 1 device /dev/da1e volume var setupstate plex org concat sd drive 0 len 2096000s plex org concat sd drive 1 len 2096000s volume docsis setupstate plex org concat sd drive 0 len 1257000s plex org concat sd drive 1 len 1257000s volume docsisvar setupstate plex org concat sd drive 0 len 4651000s plex org concat sd drive 1 len 4651000s This will require repartitioning the disks, of course, and in the process you'll regain a little additional space. Theoretically you could repartition and use the existing data, but that is rather risky. > But now I tried what happens if the disk 0 fails, I mean da0. I > took da0 out and replaced it with a new disk. I switched jumpers, so > da0 got da1, and da1 got da0 and rebooted. I still don't know why you're switching jumpers. That's not needed. But it doesn't change anything. > I could boot fine, vinum failed to start and I was in single user > mode. The I saw: > > # vinum start > Warning: defective objects > > D vinumdrive0 State: referenced Device Avail: 0/0 MB > D vinumdrive2 State: referenced Device Avail: 0/0 MB > D vinumdrive4 State: referenced Device Avail: 0/0 MB > P var.p0 C State: faulty Subdisks: 1 Size: 1023 > P docsis.p0 C State: faulty Subdisks: 1 Size: 6143 > P docsisvar.p0 C State: faulty Subdisks: 1 Size: 22 > S var.p0.s0 State: stale PO: 0 B Size: 1023 > S docsis.p0.s0 State: stale PO: 0 B Size: 6143 > S docsisvar.p0.s0 State: stale PO: 0 B Size: 22 > > where is p1 ??? Not defective. I've repeated this configuration almost exactly (I was using much smaller disks, so the size is different). What I got was: vinum -> start Warning: defective objects D vinumdrive0 State: referenced A: 0/0 MB D vinumdrive2 State: referenced A: 0/0 MB D vinumdrive4 State: referenced A: 0/0 MB P var.p0 C State: faulty Subdisks: 1 Size: 1023 MB P docsis.p0 C State: faulty Subdisks: 1 Size: 613 MB P docsisvar.p0 C State: faulty Subdisks: 1 Size: 2270 MB S var.p0.s0 State: stale D: vinumdrive0 Size: 1023 MB S docsis.p0.s0 State: stale D: vinumdrive2 Size: 613 MB S docsisvar.p0.s0 State: stale D: vinumdrive4 Size: 2270 MB This is simply a list of the defective objects, as the warning message states. To see them all, use the list (or l) command: vinum -> l 3 drives: D vinumdrive1 State: up /dev/da0e A: 0/1023 MB (0%) D vinumdrive3 State: up /dev/da0f A: 0/614 MB (0%) D vinumdrive5 State: up /dev/da0g A: 0/2271 MB (0%) D vinumdrive0 State: referenced A: 0/0 MB D vinumdrive2 State: referenced A: 0/0 MB D vinumdrive4 State: referenced A: 0/0 MB 3 volumes: V var State: up Plexes: 2 Size: 1023 MB V docsis State: up Plexes: 2 Size: 613 MB V docsisvar State: up Plexes: 2 Size: 2270 MB 6 plexes: P var.p0 C State: faulty Subdisks: 1 Size: 1023 MB P var.p1 C State: up Subdisks: 1 Size: 1023 MB P docsis.p0 C State: faulty Subdisks: 1 Size: 613 MB P docsis.p1 C State: up Subdisks: 1 Size: 613 MB P docsisvar.p0 C State: faulty Subdisks: 1 Size: 2270 MB P docsisvar.p1 C State: up Subdisks: 1 Size: 2270 MB 6 subdisks: S var.p0.s0 State: stale D: vinumdrive0 Size: 1023 MB S var.p1.s0 State: up D: vinumdrive1 Size: 1023 MB S docsis.p0.s0 State: stale D: vinumdrive2 Size: 613 MB S docsis.p1.s0 State: up D: vinumdrive3 Size: 613 MB S docsisvar.p0.s0 State: stale D: vinumdrive4 Size: 2270 MB S docsisvar.p1.s0 State: up D: vinumdrive5 Size: 2270 MB > Then I tried to do: > > # echo "drive evar device /dev/da1e" >> configfile > # echo "drive edocsis device /dev/da1f" >> configfile > # echo "drive edocsisvar device /dev/da1g" >> configfile > # vinum create configfile > > And boom I got a double fault. Yes, we've found the cause of that. What I get now is: vinum -> create /wantadilla/var/tmp/vinumconfig2-bp 6 drives: D vinumdrive1 State: up /dev/da0e A: 0/1023 MB (0%) D vinumdrive3 State: up /dev/da0f A: 0/614 MB (0%) D vinumdrive5 State: up /dev/da0g A: 0/2271 MB (0%) D vinumdrive0 State: referenced A: 0/0 MB D vinumdrive2 State: referenced A: 0/0 MB D vinumdrive4 State: referenced A: 0/0 MB D evar State: up /dev/da1e A: 1023/1023 MB (100%) D edocsis State: up /dev/da1f A: 614/614 MB (100%) D edocsisvar State: up /dev/da1g A: 2271/2271 MB (100%) 3 volumes: V var State: up Plexes: 2 Size: 1023 MB V docsis State: up Plexes: 2 Size: 613 MB V docsisvar State: up Plexes: 2 Size: 2270 MB 6 plexes: P var.p0 C State: faulty Subdisks: 1 Size: 1023 MB P var.p1 C State: up Subdisks: 1 Size: 1023 MB P docsis.p0 C State: faulty Subdisks: 1 Size: 613 MB P docsis.p1 C State: up Subdisks: 1 Size: 613 MB P docsisvar.p0 C State: faulty Subdisks: 1 Size: 2270 MB P docsisvar.p1 C State: up Subdisks: 1 Size: 2270 MB 6 subdisks: S var.p0.s0 State: stale D: vinumdrive0 Size: 1023 MB S var.p1.s0 State: up D: vinumdrive1 Size: 1023 MB S docsis.p0.s0 State: stale D: vinumdrive2 Size: 613 MB S docsis.p1.s0 State: up D: vinumdrive3 Size: 613 MB S docsisvar.p0.s0 State: stale D: vinumdrive4 Size: 2270 MB S docsisvar.p1.s0 State: up D: vinumdrive5 Size: 2270 MB See those referenced drives? It's going to be almost impossible to get rid of them without removing the subdisks and plexes. Then you're going to have to create new ones. All that is unnecessary, though. The whole point of "referenced" drives is so that you can add them later. Use this config file: drive vinumdrive0 device /dev/da1e drive vinumdrive2 device /dev/da1f drive vinumdrive4 device /dev/da1g With this, I get: vinum -> create /wantadilla/var/tmp/vinumconfig3-bp 6 drives: D vinumdrive1 State: up /dev/da0e A: 0/1023 MB (0%) D vinumdrive3 State: up /dev/da0f A: 0/614 MB (0%) D vinumdrive5 State: up /dev/da0g A: 0/2271 MB (0%) D vinumdrive0 State: up /dev/da1e A: 0/1023 MB (0%) D vinumdrive2 State: up /dev/da1f A: 0/614 MB (0%) D vinumdrive4 State: up /dev/da1g A: 0/2271 MB (0%) 3 volumes: V var State: up Plexes: 2 Size: 1023 MB V docsis State: up Plexes: 2 Size: 613 MB V docsisvar State: up Plexes: 2 Size: 2270 MB 6 plexes: P var.p0 C State: faulty Subdisks: 1 Size: 1023 MB P var.p1 C State: up Subdisks: 1 Size: 1023 MB P docsis.p0 C State: faulty Subdisks: 1 Size: 613 MB P docsis.p1 C State: up Subdisks: 1 Size: 613 MB P docsisvar.p0 C State: faulty Subdisks: 1 Size: 2270 MB P docsisvar.p1 C State: up Subdisks: 1 Size: 2270 MB 6 subdisks: S var.p0.s0 State: stale D: vinumdrive0 Size: 1023 MB S var.p1.s0 State: up D: vinumdrive1 Size: 1023 MB S docsis.p0.s0 State: stale D: vinumdrive2 Size: 613 MB S docsis.p1.s0 State: up D: vinumdrive3 Size: 613 MB S docsisvar.p0.s0 State: stale D: vinumdrive4 Size: 2270 MB S docsisvar.p1.s0 State: up D: vinumdrive5 Size: 2270 MB The subdisks are still down, of course. You need to start them: vinum -> start var.p0 Reviving var.p0.s0 in the background vinum[327]: reviving var.p0.s0 vinum -> l -r var V var State: up Plexes: 2 Size: 1023 MB P var.p0 C State: faulty Subdisks: 1 Size: 1023 MB P var.p1 C State: up Subdisks: 1 Size: 1023 MB S var.p0.s0 State: R 14% D: vinumdrive0 Size: 1023 MB S var.p1.s0 State: up D: vinumdrive1 Size: 1023 MB That 14% by var.p0.s0 shows how far the revive has progressed. You'll have to wait, of course, and you shouldn't try to do the revives in parallel on a single spindle. That will greatly slow things down due to unnecessary seeks. With only one subdisk reviving at a time, iostat shows (on these old disks): tty ad0 da0 da1 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 0 230 4.00 2 0.01 64.00 43 2.68 64.00 43 2.68 0 0 1 2 98 0 76 0.00 0 0.00 64.00 44 2.72 64.00 45 2.78 0 0 2 1 98 If you try to do two at the same time, the aggregate data rate drops: tty ad0 da0 da1 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 0 229 0.00 0 0.00 64.00 35 2.17 64.00 35 2.17 0 0 0 2 98 0 76 0.00 0 0.00 64.00 35 2.17 64.00 35 2.17 0 0 0 2 98 When the revive completes, Vinum sets the states of the defective objects to "up". Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 15:45:46 2002 Delivered-To: freebsd-stable@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 1874B37B420; Sun, 27 Jan 2002 15:43:01 -0800 (PST) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id C2BB778316; Mon, 28 Jan 2002 09:43:10 +1030 (CST) Date: Mon, 28 Jan 2002 09:43:10 +1030 From: Greg Lehey To: Martin Blapp Cc: Bernd Walter , freebsd-stable@FreeBSD.ORG, tmm@FreeBSD.ORG Subject: Re: double fault with vinum and 4.5 RC3 Message-ID: <20020128094310.C72512@wantadilla.lemis.com> References: <20020127153009.B92489@cicely8.cicely.de> <20020127195120.K68322-100000@levais.imp.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020127195120.K68322-100000@levais.imp.ch> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sunday, 27 January 2002 at 19:53:52 +0100, Martin Blapp wrote: > > I just got another panic while executing; > > vinum resetconfig Why are you using resetconfig? It's almost never needed. > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x28 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc135abcb > stack pointer = 0x10:0xcdad8d20 > frame pointer = 0x10:0xcdad8d34 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 271 (vinum) > interrupt mask = none > kernel: type 12 trap, code=0 > Stopped at driveio+0x47: movl 0x28(%eax),%eax > > driveio(c12520fc,c11aa200,200,1000,0) at driveio+0x47 > remove_drive(1,4649,c134c380,cdad8d8c,c135c131) at remove_drive+0x79 > free_vinum(1,cdad8de4,c134c380,cbfae700,cdad8ea8) at free_vinum+0x26 > vinumioctl(c134c380,4649,cdad8ea8,3,cbfae700) at vinumioctl+0x47d > spec_ioctl(cdad8de4,cdad8dcc,c02634e1,cdad8de4,cdad8e74) at spec_ioctl+0x26 > spec_vnoperate(cdad8de4,cdad8e74,c01d41ab,cdad8de4,c1312b80) at > spec_vnoperate+0x15 > ufs_vnoperatespec(cdad8de4,c1312b80,3,0,c02f80a0) at ufs_vnoperatespec+0x15 > vn_ioctl(c1312b80,4649,cdad8ea8,cbfae700,cbfae700) at vn_ioctl+0x10f > ioctl(cbfae700,cdad8f80,bfbffb88,bfbffb93,8095d39) at ioctl+0x20a > syscall2(2f,2f,2f,8095d39,bfbffb93) at syscall2+0x1f5 > Xint0x80_syscall() at Xint0x80_syscall+0x25 I'd guess that this is some race condition I've never seen before. I've asked you several times now to read http://www.vinumvm.org/vinum/how-to-debug.html and supply me the information I ask for there. In particular, I need log output. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 15:46:14 2002 Delivered-To: freebsd-stable@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 241C937B422 for ; Sun, 27 Jan 2002 15:43:01 -0800 (PST) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 4C948782D0; Sun, 27 Jan 2002 14:07:03 +1030 (CST) Date: Sun, 27 Jan 2002 14:07:03 +1030 From: Greg Lehey To: Thomas Moestl Cc: Martin Blapp , freebsd-stable@FreeBSD.org Subject: Re: double fault with vinum and 4.5 RC3 Message-ID: <20020127140703.A41130@wantadilla.lemis.com> References: <20020125131225.E4778@wantadilla.lemis.com> <20020125111624.S47234-100000@levais.imp.ch> <20020126233709.GA459@crow.dom2ip.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020126233709.GA459@crow.dom2ip.de> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sunday, 27 January 2002 at 0:37:09 +0100, Thomas Moestl wrote: > On Fri, 2002/01/25 at 11:38:31 +0100, Martin Blapp wrote: >> vinum create /root/configfile twice ! makes STABLE 4.5RC3 crashing with a double >> fault. I guess we should fix that. I'm makeing now a debug kernel. > > I've had a quick look at Martin's crash dump; Well, for a quick look you've done some really good work. This bug has probably been chasing me for years. > the double fault is caused by a longjmp() that restores an invalid > %esp. By accessing the stack that is to be restored by longjmp > before actually setting %esp, I was able to get a usable trace > (showing the vinum-relevant parts only): > > longjmp(c034a120,0,0,c1c31af4,3) at longjmp+0x7 > throw_rude_remark(0,c02dbfc0,c1c41406,c1c31b84,c1c31af4) at > > > Apparently, this process slept in disk I/O initiated by > vinum_read_label(); meanwhile, the vinum process forked in > start_daemon() was scheduled and performed an ioctl() to find out > whether the daemon was running. In this case, it was, so it exited. > After some time, the other process is woken up because the I/O > finished. vinum_read_label() returned DL_WRONG_DRIVE, so eventually > throw_rude_remark() was called, which tried to longjmp() back to > vinumioctl(). However, because vinumioctl() was called by another > process in between, command_fail had been overwritten (it is a global > variable). The stack referenced in that jmpbuf was unmapped when > that process exited, so the result was a double fault. Exactly. The culprit is an extraneous call to setjmp in vinumioctl. The setjmp logic assumes that the process is holding the config lock, so it can use command_fail. Unfortunately, this call was outside the protected code, and that's what caused the problem. > Greg, Martin should the crash dump I'm talking about available if > you would like to take a look (the kernel in question has longjmp > debugging code and a few printf()s added). I tried looking, but the net connection was terrible. Anyway, I've been able to reproduce it here, and I have a patch which should make it go away: RCS file: /home/ncvs/src/sys/dev/vinum/vinumconfig.c,v retrieving revision 1.32.2.5 diff -w -u -r1.32.2.5 vinumconfig.c --- vinumconfig.c 28 May 2001 05:56:27 -0000 1.32.2.5 +++ vinumconfig.c 27 Jan 2002 03:31:33 -0000 @@ -99,6 +99,8 @@ static int finishing; /* don't recurse */ int was_finishing; + if ((vinum_conf.flags & VF_LOCKED) == 0) /* bug catcher */ + panic ("throw_rude_remark: called without config lock"); va_start(ap, msg); if ((ioctl_reply != NULL) /* we're called from the user */ &&(!(vinum_conf.flags & VF_READING_CONFIG))) { /* and not reading from disk: return msg */ Index: vinumioctl.c =================================================================== RCS file: /home/ncvs/src/sys/dev/vinum/vinumioctl.c,v retrieving revision 1.25.2.3 diff -w -u -r1.25.2.3 vinumioctl.c --- vinumioctl.c 13 Mar 2001 02:59:43 -0000 1.25.2.3 +++ vinumioctl.c 27 Jan 2002 03:31:06 -0000 @@ -82,9 +82,6 @@ switch (DEVTYPE(dev)) { case VINUM_SUPERDEV_TYPE: /* ordinary super device */ ioctl_reply = (struct _ioctl_reply *) data; /* save the address to reply to */ - error = setjmp(command_fail); /* come back here on error */ - if (error) /* bombed out */ - return 0; /* the reply will contain meaningful info */ switch (cmd) { #ifdef VINUMDEBUG case VINUM_DEBUG: The panic in throw_rude_remark is "just in case", since it's a lot easier to debug like that than after a double fault. Please try that and let me know if you still have problems. In view of the impending release of 4.5, it would be nice to get this fix in. This doesn't change the fact that Martin's approach to recovery is incorrect. I'll address that in a separate message. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 16: 1:21 2002 Delivered-To: freebsd-stable@freebsd.org Received: from guru.mired.org (dsl-64-192-6-133.telocity.com [64.192.6.133]) by hub.freebsd.org (Postfix) with SMTP id DFDEF37B416 for ; Sun, 27 Jan 2002 16:01:18 -0800 (PST) Received: (qmail 79496 invoked by uid 100); 28 Jan 2002 00:01:17 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15444.38092.267015.297844@guru.mired.org> Date: Sun, 27 Jan 2002 18:01:16 -0600 To: Gerhard Sittig Cc: stable@FreeBSD.ORG Subject: Re: Firewall config non-intuitiveness In-Reply-To: <20020127220935.C1494@shell.gsinet.sittig.org> References: <20020127014848.F23259@blossom.cjclark.org> <3.0.5.32.20020127075816.01831ca0@mail.sage-american.com> <20020127.102748.70374201.imp@village.org> <200201271757.g0RHvTF12944@midway.uchicago.edu> <20020127220935.C1494@shell.gsinet.sittig.org> X-Mailer: VM 6.90 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ From: "Mike Meyer" X-Delivery-Agent: TMDA/0.44 (Python 2.2; freebsd-4.5-RC-i386) Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Gerhard Sittig types: > On Sun, Jan 27, 2002 at 11:57 -0600, David Syphers wrote: > > [ ... surprise ... ] As others have pointed out this behavior is > > documented, but we must remember that a variable name itself is the most > > important and immediate documentation. And having a firewall load when > > firewall_enable is NO is complete nonsense. > So maybe the variables should be named a little longer to fully > describe their effect? Like > firewall_ruleset_script_run_enable_when_set_to_yes? If you're going to do it, do it right: firewall_load_ipfw_if_needed_then_run_ruleset_script_when_set_to_yes http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 16:22:13 2002 Delivered-To: freebsd-stable@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 8348537B400 for ; Sun, 27 Jan 2002 16:22:11 -0800 (PST) Received: from dialup-209.245.129.180.dial1.sanjose1.level3.net ([209.245.129.180] helo=blossom.cjclark.org) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16UzYM-0003xQ-00; Sun, 27 Jan 2002 16:22:00 -0800 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.3) id g0S0K0127236; Sun, 27 Jan 2002 16:20:00 -0800 (PST) (envelope-from cjc) Date: Sun, 27 Jan 2002 16:19:51 -0800 From: "Crist J. Clark" To: "M. Warner Losh" Cc: jacks@sage-american.com, nate@yogotech.com, stable@FreeBSD.ORG Subject: Re: Firewall config non-intuitiveness Message-ID: <20020127161951.A27080@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <20020127014848.F23259@blossom.cjclark.org> <20020127.052626.107682843.imp@village.org> <3.0.5.32.20020127075816.01831ca0@mail.sage-american.com> <20020127.102748.70374201.imp@village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020127.102748.70374201.imp@village.org>; from imp@village.org on Sun, Jan 27, 2002 at 10:27:48AM -0700 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jan 27, 2002 at 10:27:48AM -0700, M. Warner Losh wrote: [snip] > Right now what I have works. You are changing the semantics of a > security related feature of the system in such a way that after this > change what I have will not work. I agree that your work around will > allow me to easily correct things. However, if I fail to do so, I > open my firewall up completely. To me, that's an unacceptible change > in the API. I agree that changing this in -STABLE may be too much of a disruption in the API. It may be too late. That's why I think this discussion has been necessary. However, changing the behavior in -CURRENT... That's a whole different issue (but not really a topic for this list). -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 16:22:32 2002 Delivered-To: freebsd-stable@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id C8F3937B400 for ; Sun, 27 Jan 2002 16:22:28 -0800 (PST) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 0EDCF782D0; Mon, 28 Jan 2002 10:52:27 +1030 (CST) Date: Mon, 28 Jan 2002 10:52:27 +1030 From: Greg Lehey To: Martin Blapp Cc: Bernd Walter , freebsd-stable@FreeBSD.ORG Subject: Re: double fault with vinum and 4.5 RC3 Message-ID: <20020128105227.A18585@wantadilla.lemis.com> References: <20020127153009.B92489@cicely8.cicely.de> <20020127194221.H68322-100000@levais.imp.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020127194221.H68322-100000@levais.imp.ch> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sunday, 27 January 2002 at 19:46:28 +0100, Martin Blapp wrote: > > Uhh, what I'm doing wrong ? > > cat configfile > The config file looks fine. > # vinum create configfile > 2: drive vinumdrive2 device /dev/da1s1e > ** 2 : Invalid argument > > D vinumdrive1 State: up Device /dev/da0s1e Avail: 0/29880 MB (0%) > D vinumdrive2 State: up Device Avail: 0/0 MB > > Uhh ? Vinum does not find the second drive ? So it seems. I've heard of this in a couple of cases. It would be interesting to see the log output, but if I understand you correctly you have since found a way to work around the problem. I suspect that there was something in the disk label which confused the issue, but it would be nice to find what it is. Possibly /dev/da1e would have worked. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 16:54:43 2002 Delivered-To: freebsd-stable@freebsd.org Received: from star.sstec.com (adsl-216-102-148-67.dsl.lsan03.pacbell.net [216.102.148.67]) by hub.freebsd.org (Postfix) with ESMTP id CE6EF37B404 for ; Sun, 27 Jan 2002 16:54:34 -0800 (PST) Received: from comm.sstec.com (comm.sstec.com [192.168.74.10]) by star.sstec.com (8.11.6/8.11.6) with ESMTP id g0S0una80077; Sun, 27 Jan 2002 16:56:49 -0800 (PST) (envelope-from fbsd@sstec.com) Message-Id: <5.1.0.14.2.20020127150544.00ac95c0@mail.sstec.com> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 27 Jan 2002 16:30:11 -0700 To: Patrick Greenwell , Gerhard Sittig From: "John R. Long" Subject: Re: Firewall config non-intuitiveness Cc: stable@FreeBSD.ORG In-Reply-To: <20020127134511.Q81780-100000@rockstar.stealthgeeks.net> References: <20020127220923.B1494@shell.gsinet.sittig.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I have to go along with common sense and logic with this one. I was once burnt by it about 2 years ago. I compiled it in and set it to NO in .rc and nothing going thru. Strange, NO means no right?, it is a control knob to the kernel so NO must disable it right?. And disabled means the same as not in there right? If it means something else then say so clearly. I read this as allow "# firewall_type=open in /etc/rc.conf when first enabling this feature" similarly "firewall_enable="NO" means allow also. This problem cost me several hours of work, I was thinking that the compile was wrong because it did not make any sense. I say NO and it is dead so I boot GENERIC w/o firewall it works therefore the compile must have borked it. Recompile, tweak etc... LINT was/is Not comprehensive nor clear on that point! Just one of those things I guess, forget it for now. This thread brings up that damn problem of days past and that it was Not me. Everyone is new to Freebsd at some time but this goes beyond that, It should make common sense and not be an illogical nightmare. Say what you mean and be coherent about it. John R. Long sstec.com At 03:50 PM 1/27/2002, Patrick Greenwell wrote: >On Sun, 27 Jan 2002, Gerhard Sittig wrote: > > > I filed a PR which does adjust the rc.conf comment (I understand > > that LINT resp. NOTES as well as "man 5 rc.conf" both told the > > originator of the thread what would happen while rc.conf was too > > short and not authoritative enough a source to stop him from > > shooting into his foot). > >I didn't address this issue earlier because I was more concerned with >having something called "firewall_enable" do something that made sense >when it was set to no. However, since you along with a couple of others >have made the claim that this mislabled behavior is well-documented, I'd >like to point out why I believe you are mistaken. > >Here's the relevent "documentation" that has been mentioned: > > >From LINT: > ># WARNING: IPFIREWALL defaults to a policy of "deny ip from any to any" ># and if you do not add other rules during startup to allow access, ># YOU WILL LOCK YOURSELF OUT. It is suggested that you set ># firewall_type=open in /etc/rc.conf when first enabling this feature, ># then refining the firewall rules in /etc/rc.firewall after you've tested ># that the new kernel feature works properly. > >See anything in there about the firewall_enable variable? Anything that >says something along the lines of "the firewall_enable variable has no >effect if set to no?" > >While we're on the subject, the above documentation is incomplete as it fails >to mention that you need to set firewall_enable to yes in order for the >rc.firewall script to be executed(if I'm reading /etc/rc.network correctly.) > >The results of following the documentation outlined in LINT as written is >that you'd still be locked out of your box. > >and here's the info from the rc.conf man page > >firewall_enable >(bool) Set to ``YES'' to load firewall rules at startup. >If the kernel was not built with IPFIREWALL, the ipfw >kernel module will be loaded. See also ipfilter_enable. > >See anything in there about setting firewall_enable to "no"? > >So much for well-documented behavior. > >Really, I'm just arguing for doing something that makes sense, and the >current behavior does not qualify, regardless of how long it's been >understood to be broken that way. Even if this behavior were adequately >documented, which it isn't, it's extremely user-unfriendly to have no mean >yes. > >At this point I'm rather reticent to even bother submitting anything to >the "security officer" role as Warner has indicated that he's part of that >role and will speak out against it in the name of security. I'm not a >member of the inner circle, just a long-time user who saw some confusing >behavior and thought that there was an opportunity to fix it. > >I'll go tilt at some other windmills now. :-) > >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > Patrick Greenwell > Stealthgeeks,LLC. Operations Consulting > http://www.stealthgeeks.net >\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > > > > > > > >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 From owner-freebsd-stable Sun Jan 27 16:57:26 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by hub.freebsd.org (Postfix) with ESMTP id 85CC437B416; Sun, 27 Jan 2002 16:57:20 -0800 (PST) Received: from levais.imp.ch (levais.imp.ch [157.161.4.66]) by mail.imp.ch (8.11.1/8.11.1) with ESMTP id g0S0vJv75536; Mon, 28 Jan 2002 01:57:19 +0100 (CET) (envelope-from Martin.Blapp@imp.ch) Date: Mon, 28 Jan 2002 01:57:17 +0100 (CET) From: Martin Blapp To: Greg Lehey Cc: Bernd Walter , Subject: Re: double fault with vinum and 4.5 RC3 In-Reply-To: <20020128105227.A18585@wantadilla.lemis.com> Message-ID: <20020128014332.W68322-100000@levais.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi Greg, > So it seems. I've heard of this in a couple of cases. It would be > interesting to see the log output, but if I understand you correctly > you have since found a way to work around the problem. I suspect that > there was something in the disk label which confused the issue, but it > would be nice to find what it is. Possibly /dev/da1e would have > worked. I tried first with /dev/da1e. Then I shought I should use /dev/da1s1e. No way. Errm, If it's allowed to ask, what is exactly the difference between the name with slice (s1e) and just the slice entry (e) ? I suppose I know what happened. da1 still had the vinum information stored at the same place as before from my three mirrors I made before. One time it worked, but vinum showed me a size of 1024m, exactly the size what /var was before. You see, da0s1e is exactly at the same place as the da0s1g with the new config ! I just did: - Removed the three slices da0s1e, da0s1f, da0s1g. - Removed the three slices da1s1e, da1s1f, da1s1g. - Made a big partiton on them. - Executed newfs on it. - Relabeled this partition as type "vinum" - Executed vinum create config and had the failure. Should be easy to find out what vinum does wrong here. Btw: I have a crash dump available for the race you said, it you are interested. If you login to the machine, there are also the log entries in /var/log/messages. Another thing I noted: newfs seems to make less superblock backups on big volumes now. Vinum still does make as many backups as FreeBSD did earlier for other filesystems. At least my experiments lead to some bug discovery ;) Martin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 17:13: 1 2002 Delivered-To: freebsd-stable@freebsd.org Received: from leviathan.inethouston.net (leviathan.inethouston.net [66.64.12.249]) by hub.freebsd.org (Postfix) with ESMTP id 7F3F737B400; Sun, 27 Jan 2002 17:12:59 -0800 (PST) Received: by leviathan.inethouston.net (Postfix, from userid 1001) id 609AA319AFA; Sun, 27 Jan 2002 19:12:59 -0600 (CST) Date: Sun, 27 Jan 2002 19:12:59 -0600 From: "David W. Chapman Jr." To: Greg Lehey Cc: Martin Blapp , freebsd-stable@freebsd.org Subject: Re: double fault with vinum and 4.5 RC3 Message-ID: <20020128011259.GA5158@leviathan.inethouston.net> Reply-To: "David W. Chapman Jr." Mail-Followup-To: Greg Lehey , Martin Blapp , freebsd-stable@freebsd.org References: <20020124184810.M47234-100000@levais.imp.ch> <20020127142643.A19909@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020127142643.A19909@wantadilla.lemis.com> User-Agent: Mutt/1.3.27i X-Operating-System: FreeBSD 4.5-RC i386 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I still don't know why you're switching jumpers. That's not needed. > But it doesn't change anything. wouldn't he have to change the scsi id's if id 1 was set to boot in the controller and drive 1 no longer exists. I suppose he could change the boot id in the scsi adapters bios as well. -- David W. Chapman Jr. dwcjr@inethouston.net Raintree Network Services, Inc. dwcjr@freebsd.org FreeBSD Committer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 17:23: 5 2002 Delivered-To: freebsd-stable@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 8450737B400 for ; Sun, 27 Jan 2002 17:22:59 -0800 (PST) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 3A247782D0; Mon, 28 Jan 2002 11:52:57 +1030 (CST) Date: Mon, 28 Jan 2002 11:52:57 +1030 From: Greg Lehey To: Martin Blapp , freebsd-stable@freebsd.org Subject: Re: double fault with vinum and 4.5 RC3 Message-ID: <20020128115257.D18585@wantadilla.lemis.com> References: <20020124184810.M47234-100000@levais.imp.ch> <20020127142643.A19909@wantadilla.lemis.com> <20020128011259.GA5158@leviathan.inethouston.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020128011259.GA5158@leviathan.inethouston.net> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sunday, 27 January 2002 at 19:12:59 -0600, David W. Chapman Jr. wrote: >> I still don't know why you're switching jumpers. That's not needed. >> But it doesn't change anything. > > wouldn't he have to change the scsi id's if id 1 was set to boot in > the controller and drive 1 no longer exists. I suppose he could > change the boot id in the scsi adapters bios as well. Yes, this appears to be the case. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 17:55:47 2002 Delivered-To: freebsd-stable@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id CE7CA37B428 for ; Sun, 27 Jan 2002 17:55:44 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id SAA21012; Sun, 27 Jan 2002 18:55:39 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0S1tc959306; Sun, 27 Jan 2002 18:55:38 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15444.44954.347602.724162@caddis.yogotech.com> Date: Sun, 27 Jan 2002 18:55:38 -0700 To: Michael Sierchio Cc: Nate Williams , Bob K , Patrick Greenwell , stable@FreeBSD.ORG Subject: Re: Firewall config non-intuitiveness In-Reply-To: <3C543976.147A50E2@tenebras.com> References: <000c01c1a5ff$a4539870$0101a8c0@cascade> <20020125165307.C54729-100000@rockstar.stealthgeeks.net> <20020125203328.A454@yip.org> <15443.41177.259786.242696@caddis.yogotech.com> <3C53A5A2.A5F8FBD6@tenebras.com> <15443.42601.781625.356369@caddis.yogotech.com> <3C543976.147A50E2@tenebras.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > See above. It can easily be done in a more standard way. (One can > > argue that the '-z' should be the default flag, but so far I've failed > > to convince Warner of this fact. :) :) > > Forgive me if I'm mistaken, but the pccard_ether script (when last I > looked at it) seems to assume exactly one network interface, and > I was never able to get the "standard" way to work properly with > two. You don't have to use pccard_ifconfig. You can use the normal ifconfig_ed0 and/or ifconfig_ep0 lines to configure the interfaces just as easily. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 19:28:50 2002 Delivered-To: freebsd-stable@freebsd.org Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18]) by hub.freebsd.org (Postfix) with SMTP id 63AC537B421 for ; Sun, 27 Jan 2002 19:28:41 -0800 (PST) Received: (qmail 1608 invoked by uid 20182); 28 Jan 2002 03:28:41 -0000 Received: from unknown (HELO tenebras.com) (192.168.1.123) by 0 with SMTP; 28 Jan 2002 03:28:41 -0000 Message-ID: <3C54C569.7952CBE0@tenebras.com> Date: Sun, 27 Jan 2002 19:28:41 -0800 From: Michael Sierchio Reply-To: kudzu@tenebras.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: stable@FreeBSD.ORG Subject: Re: Firewall config non-intuitiveness References: <000c01c1a5ff$a4539870$0101a8c0@cascade> <20020125165307.C54729-100000@rockstar.stealthgeeks.net> <20020125203328.A454@yip.org> <15443.41177.259786.242696@caddis.yogotech.com> <3C53A5A2.A5F8FBD6@tenebras.com> <15443.42601.781625.356369@caddis.yogotech.com> <3C543976.147A50E2@tenebras.com> <15444.44954.347602.724162@caddis.yogotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nate Williams wrote: > > > > See above. It can easily be done in a more standard way. (One can > > > argue that the '-z' should be the default flag, but so far I've failed > > > to convince Warner of this fact. :) :) > > > > Forgive me if I'm mistaken, but the pccard_ether script (when last I > > looked at it) seems to assume exactly one network interface, and > > I was never able to get the "standard" way to work properly with > > two. > > You don't have to use pccard_ifconfig. You can use the normal > ifconfig_ed0 and/or ifconfig_ep0 lines to configure the interfaces just > as easily. Right, I discovered this after updating my pccard_ether... With the -z flag the cards get configured in order -- that is, the card in slot0 gets configured first, and everything seems to work right. Thanks again. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 19:30:54 2002 Delivered-To: freebsd-stable@freebsd.org Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18]) by hub.freebsd.org (Postfix) with SMTP id 49BC337B404 for ; Sun, 27 Jan 2002 19:30:50 -0800 (PST) Received: (qmail 1632 invoked by uid 20182); 28 Jan 2002 03:30:50 -0000 Received: from unknown (HELO tenebras.com) (192.168.1.123) by 0 with SMTP; 28 Jan 2002 03:30:50 -0000 Message-ID: <3C54C5E9.1EA6634D@tenebras.com> Date: Sun, 27 Jan 2002 19:30:49 -0800 From: Michael Sierchio Reply-To: kudzu@tenebras.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams , stable@FreeBSD.ORG Subject: Re: Firewall config non-intuitiveness References: <000c01c1a5ff$a4539870$0101a8c0@cascade> <20020125165307.C54729-100000@rockstar.stealthgeeks.net> <20020125203328.A454@yip.org> <15443.41177.259786.242696@caddis.yogotech.com> <3C53A5A2.A5F8FBD6@tenebras.com> <15443.42601.781625.356369@caddis.yogotech.com> <3C543976.147A50E2@tenebras.com> <15444.44954.347602.724162@caddis.yogotech.com> <3C54C569.7952CBE0@tenebras.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Michael Sierchio wrote: > > Nate Williams wrote: > > > > > > See above. It can easily be done in a more standard way. (One can > > > > argue that the '-z' should be the default flag, but so far I've failed > > > > to convince Warner of this fact. :) :) > > > > > > Forgive me if I'm mistaken, but the pccard_ether script (when last I > > > looked at it) seems to assume exactly one network interface, and > > > I was never able to get the "standard" way to work properly with > > > two. > > > > You don't have to use pccard_ifconfig. You can use the normal > > ifconfig_ed0 and/or ifconfig_ep0 lines to configure the interfaces just > > as easily. > > Right, I discovered this after updating my pccard_ether... With the -z > flag the cards get configured in order -- that is, the card in slot0 > gets configured first, and everything seems to work right. Thanks again. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 19:30:52 2002 Delivered-To: freebsd-stable@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id EE0B437B402 for ; Sun, 27 Jan 2002 19:30:47 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id UAA24740; Sun, 27 Jan 2002 20:30:46 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0S3Uh360019; Sun, 27 Jan 2002 20:30:43 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15444.50658.246125.49778@caddis.yogotech.com> Date: Sun, 27 Jan 2002 20:30:42 -0700 To: kudzu@tenebras.com Cc: Nate Williams , stable@FreeBSD.ORG Subject: Re: Firewall config non-intuitiveness In-Reply-To: <3C54C569.7952CBE0@tenebras.com> References: <000c01c1a5ff$a4539870$0101a8c0@cascade> <20020125165307.C54729-100000@rockstar.stealthgeeks.net> <20020125203328.A454@yip.org> <15443.41177.259786.242696@caddis.yogotech.com> <3C53A5A2.A5F8FBD6@tenebras.com> <15443.42601.781625.356369@caddis.yogotech.com> <3C543976.147A50E2@tenebras.com> <15444.44954.347602.724162@caddis.yogotech.com> <3C54C569.7952CBE0@tenebras.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > > See above. It can easily be done in a more standard way. (One can > > > > argue that the '-z' should be the default flag, but so far I've failed > > > > to convince Warner of this fact. :) :) > > > > > > Forgive me if I'm mistaken, but the pccard_ether script (when last I > > > looked at it) seems to assume exactly one network interface, and > > > I was never able to get the "standard" way to work properly with > > > two. > > > > You don't have to use pccard_ifconfig. You can use the normal > > ifconfig_ed0 and/or ifconfig_ep0 lines to configure the interfaces just > > as easily. > > Right, I discovered this after updating my pccard_ether... With the -z > flag the cards get configured in order -- that is, the card in slot0 > gets configured first, and everything seems to work right. Thanks again. Glad it helped! Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 20:34:41 2002 Delivered-To: freebsd-stable@freebsd.org Received: from herald.cc.purdue.edu (herald.cc.purdue.edu [128.210.11.29]) by hub.freebsd.org (Postfix) with ESMTP id CA95637B400 for ; Sun, 27 Jan 2002 20:34:38 -0800 (PST) Received: from twitch (hill-d-193.resnet.purdue.edu [128.211.207.193]) by herald.cc.purdue.edu (8.11.6/8.11.6/herald) with ESMTP id g0S4Yb002678 for ; Sun, 27 Jan 2002 23:34:37 -0500 (EST) From: "Sumanth Peddamatham" To: Subject: Date: Sun, 27 Jan 2002 23:36:48 -0600 Message-ID: <006a01c1a7bd$caec8400$0200a8c0@twitch> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG subscribe freebsd-stable To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 22:24:55 2002 Delivered-To: freebsd-stable@freebsd.org Received: from jupiter.centrin.net.id (jupiter.centrin.net.id [202.146.255.3]) by hub.freebsd.org (Postfix) with ESMTP id AE12037B400 for ; Sun, 27 Jan 2002 22:24:50 -0800 (PST) Received: from netmail.centrin.net.id (rhea.centrin.net.id [202.146.241.20]) by jupiter.centrin.net.id (8.11.3/8.11.3) with SMTP id g0S6OkR20473 for ; Mon, 28 Jan 2002 13:24:47 +0700 Message-Id: <200201280624.g0S6OkR20473@jupiter.centrin.net.id> To: freebsd-stable@FREEBSD.ORG From: budsan02@bdg.centrin.net.id Subject: conflict: orinoco card vs 3com in my 4.4-stable box? Date: Mon, 28 Jan 2002 13:24:47 +0700 X-Mailer: Net-Mail 1.0 X-Mailer-Info: Netindo Teknologi (http://www.netindo.co.id) Content-Type: text/plain Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi all, i'm installing orinoco silver card in my 4.4 Stable FreeBSD box, which already has a boomerang 3-com xl0 running as an intranet gateway inside. The problem is I can't connect/ping neither to my ISP's DNS server nor the isp gateway nomore. here is my configuration in rc.conf: gateway_enable="yes" default_router="202.143.99.200" <-- ISP's gateway ip. pccard_enable="yes" pccard_config="inet 202.143.97.210 netmask 255.255.255.252" <-- orinoco static ip. ifconfig_xl0="inet 192.168.0.88 netmask 255.255.255.0" <-- 3com eth ip. I add 'add 65000 allow all from any to any' to rc.firewall to bypass all rules (Temporarily!) during orinoco's setup. default firewall is to deny. Here is my wicontrol flags: wicontrol -i wi0 -p 1 wicontrol -e 1 -k 'my ISP key value' -v 1 wicontrol -T 1 wicontrol -s 'my station name' wicontrol -n 'isp network name' channel 8 <-- my isp channel (BSS service set) there are very very few activity in orinoco's transmit LED when i do wicontrol -n with my isp network name.. Could somebody help me please? Also where can i get some urls about same problem? TIA budsz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 22:49:30 2002 Delivered-To: freebsd-stable@freebsd.org Received: from post.mail.nl.demon.net (post-10.mail.nl.demon.net [194.159.73.20]) by hub.freebsd.org (Postfix) with ESMTP id BF08F37B400 for ; Sun, 27 Jan 2002 22:49:27 -0800 (PST) Received: from [212.238.194.207] (helo=tanya.raggedclown.net) by post.mail.nl.demon.net with esmtp (Exim 3.33 #1) id 16V5ba-00001F-00 for stable@freebsd.org; Mon, 28 Jan 2002 06:49:26 +0000 Received: by tanya.raggedclown.net (tanya.raggedclown.intra, from userid 500) id 63B7645218; Mon, 28 Jan 2002 07:49:25 +0100 (CET) Date: Mon, 28 Jan 2002 07:49:25 +0100 From: Cliff Sarginson To: stable@freebsd.org Subject: Re: Firewall config non-intuitiveness Message-ID: <20020128064925.GA1180@raggedclown.net> References: <20020127220923.B1494@shell.gsinet.sittig.org> <20020127134511.Q81780-100000@rockstar.stealthgeeks.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020127134511.Q81780-100000@rockstar.stealthgeeks.net> User-Agent: Mutt/1.3.24i Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jan 27, 2002 at 02:50:50PM -0800, Patrick Greenwell wrote: > > Really, I'm just arguing for doing something that makes sense, and the > current behavior does not qualify, regardless of how long it's been > understood to be broken that way. Even if this behavior were adequately > documented, which it isn't, it's extremely user-unfriendly to have no mean > yes. > > At this point I'm rather reticent to even bother submitting anything to > the "security officer" role as Warner has indicated that he's part of that > role and will speak out against it in the name of security. I'm not a > member of the inner circle, just a long-time user who saw some confusing > behavior and thought that there was an opportunity to fix it. > I think you were quite right to, and I think you are right. But you are fighting the forces of reaction here, in my view. This whole thread has been a very depressing reflection on the inability of any of the people arguing against you to make any coherent argument against changing something to make sense. This is just conservative status-quoism gone mad. You are not alone in finding the current wording and behaviour of this feature inconsistent, and initially incoherent. Perhaps we are just too dumb. -- Regards Cliff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 22:49:48 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mail.dynamic-cast.com (ip4.gte4.rb1.bel.nwlink.com [209.20.215.4]) by hub.freebsd.org (Postfix) with ESMTP id 116B837B417 for ; Sun, 27 Jan 2002 22:49:46 -0800 (PST) Received: from neo (neo.private.dynamic-cast.com [192.168.1.3]) by mail.dynamic-cast.com (Postfix) with SMTP id 2D8DBD905 for ; Sun, 27 Jan 2002 22:49:45 -0800 (PST) Message-ID: <001201c1a7c7$f7b74c40$0301a8c0@neo> From: "Hervey Wilson" To: Subject: ipfilter_enable problem on 4.5 Date: Sun, 27 Jan 2002 22:49:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I just upgraded my server to 4.5 RC from 4-STABLE last cvsup'd late last year and it appears that my IP filter configuration is no longer being automatically loaded. I know this since it's set to default block and once the server boots, I've lost all contact with both the connected networks and the loopback interfaces. Reloading ipfilter using the commands from rc.conf results in a working system. rc.conf has simply: ipfilter_enable="YES" With rules in /etc/ipf.rules. IP filter is also compiled into my kernel; I see the initialization message during boot but cannot find any other messages regarding the load of the rules - has anyone else run into this or can suggest where I look for additional error messages beyond /var/log/messages ? Thanks in advance, H. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 23: 3:29 2002 Delivered-To: freebsd-stable@freebsd.org Received: from smtpout.mac.com (smtpout.mac.com [204.179.120.89]) by hub.freebsd.org (Postfix) with ESMTP id 59C6937B416 for ; Sun, 27 Jan 2002 23:03:09 -0800 (PST) Received: from smtp-relay01.mac.com (server-source-si02 [10.13.10.6]) by smtpout.mac.com (8.12.1/8.10.2/1.0) with ESMTP id g0S738Gm002123 for ; Sun, 27 Jan 2002 23:03:09 -0800 (PST) Received: from asmtp02.mac.com ([10.13.10.66]) by smtp-relay01.mac.com (Netscape Messaging Server 4.15 relay01 Jun 21 2001 23:53:48) with ESMTP id GQMZL800.UH3 for ; Sun, 27 Jan 2002 23:03:08 -0800 Received: from quinn ([24.91.220.49]) by asmtp02.mac.com (Netscape Messaging Server 4.15 asmtp02 Jun 21 2001 23:53:48) with ESMTP id GQMZL700.ECP for ; Sun, 27 Jan 2002 23:03:07 -0800 Date: Mon, 28 Jan 2002 02:03:03 -0500 Mime-Version: 1.0 (Apple Message framework v480) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: re: firewall config (CTFM) From: Justin White To: freebsd-stable@FreeBSD.ORG Content-Transfer-Encoding: 7bit Message-Id: <12A141AE-13BD-11D6-876A-000393092F82@mac.com> X-Mailer: Apple Mail (2.480) Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG instead of changing the way the system works, let's change the documentation. new people _should_ be reading the docs, and for people that already know, well, their existing configuration won't need to change a bit. in RELENG_4 from 5 Nov, /etc/defaults/rc.conf reads: -snip- firewall_enable="NO" # Set to YES to enable firewall functionality firewall_script="/etc/rc.firewall" # Which script to run to set up the firewall -snip- change the first line to read: firewall_enable="NO" # set to YES to enable running of the following firewall script since they _should_ have already read about default-deny in the kernel config, the rc.conf docs will remind them that the kernel's policy will stand without any rules being run. i'm not trying to be mean, but if you don't read the docs, you deserve the problems you get. but we need to have good docs to get people using the system without getting frustrated. i'm now going to scope out the documentation project on freebsd.org some more:-) -Justin White just6979@yahoo.com http://justinfinity.2y.net/ AIM:just6979 PS: for fun, here's a diff for the latest file in cvs as of right now :-P ---snip--- 52c52 < firewall_enable="NO" # Set to YES to enable firewall functionality --- > firewall_enable="NO" # Set to YES to run the following firewall script ---snip--- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 23:43:49 2002 Delivered-To: freebsd-stable@freebsd.org Received: from blackhelicopters.org (geburah.blackhelicopters.org [209.69.178.18]) by hub.freebsd.org (Postfix) with ESMTP id 5DE0937B495 for ; Sun, 27 Jan 2002 23:43:32 -0800 (PST) Received: (from mwlucas@localhost) by blackhelicopters.org (8.11.6/8.11.6) id g0S7hPU92698; Mon, 28 Jan 2002 02:43:25 -0500 (EST) (envelope-from mwlucas) Date: Mon, 28 Jan 2002 02:43:25 -0500 From: Michael Lucas To: George Michaelson Cc: Lowell Gilbert , freebsd-stable@FreeBSD.ORG Subject: Re: longer range FreeBSD projects into stable Message-ID: <20020128024325.A92628@blackhelicopters.org> References: <44665q1ila.fsf@lowellg.ne.mediaone.net> <17094.1012011679@apnic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <17094.1012011679@apnic.net>; from ggm@apnic.net on Sat, Jan 26, 2002 at 12:21:19PM +1000 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Jan 26, 2002 at 12:21:19PM +1000, George Michaelson wrote: > So we'll get one end of this month covering December and January? cool! > > many thanks > > I guess I think this report should be on -stable too! Well, it's FreeBSD policy to only send messages to one list. -hackers is the most appropriate list for that, as a large chunk of the status report is for -current only. -- Michael Lucas mwlucas@FreeBSD.org, mwlucas@BlackHelicopters.org my FreeBSD column: http://www.oreillynet.com/pub/q/Big_Scary_Daemons http://www.blackhelicopters.org/~mwlucas/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 23:50:34 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mail.dynamic-cast.com (ip4.gte4.rb1.bel.nwlink.com [209.20.215.4]) by hub.freebsd.org (Postfix) with ESMTP id 958AF37B404 for ; Sun, 27 Jan 2002 23:50:29 -0800 (PST) Received: from neo (neo.private.dynamic-cast.com [192.168.1.3]) by mail.dynamic-cast.com (Postfix) with SMTP id 1C6F9D905 for ; Sun, 27 Jan 2002 23:50:29 -0800 (PST) Message-ID: <000d01c1a7d0$7396e6b0$0301a8c0@neo> From: "Hervey Wilson" To: References: <001201c1a7c7$f7b74c40$0301a8c0@neo> Subject: Re: ipfilter_enable problem on 4.5 Date: Sun, 27 Jan 2002 23:50:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Updated diagnostics inline, appears to be a problem between /etc/defaults/rc.conf and /etc/rc.network. Maybe I have a bad cvsup or merge - can anyone confirm the file contents below ? H ----- Original Message ----- From: "Hervey Wilson" To: Sent: Sunday, January 27, 2002 10:49 PM Subject: ipfilter_enable problem on 4.5 > I just upgraded my server to 4.5 RC from 4-STABLE last cvsup'd late last > year and it appears that my IP filter configuration is no longer being > automatically loaded. I know this since it's set to default block and once > the server boots, I've lost all contact with both the connected networks and > the loopback interfaces. Reloading ipfilter using the commands from rc.conf > results in a working system. rc.conf has simply: > > ipfilter_enable="YES" /etc/defaults/rc.conf has: ipfilter_program="/sbin/ipf -Fa -f" ipfilter_rules="/etc/ipf.rules" ipfilter_flags="-E" In rc.network, at the point where IPF is to be loaded, I find: ... echo -n ' ipfilter' ${ipfilter_program:-/sbin/ipf} -Fa -f "${ipfilter_rules}" ${ipfilter_flags} ... which therefore results in the following command at boot: /sbin/ipf -Fa -f -Fa -f /etc/ipf.rules -E leading to ipf trying to open a file called "-Fa" as a result of the duplicate switches. > > With rules in /etc/ipf.rules. IP filter is also compiled into my kernel; I > see the initialization message during boot but cannot find any other > messages regarding the load of the rules - has anyone else run into this or > can suggest where I look for additional error messages beyond > /var/log/messages ? Finally found the file open error in dmesg, d'oh ;) H To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Sun Jan 27 23:51:18 2002 Delivered-To: freebsd-stable@freebsd.org Received: from ns.karlsruhe.punkt.de (ns.karlsruhe.punkt.de [217.29.32.130]) by hub.freebsd.org (Postfix) with ESMTP id C823B37B400; Sun, 27 Jan 2002 23:51:12 -0800 (PST) Received: from hugo10.ka.punkt.de (kagate.punkt.de [194.77.232.254]) by ns.karlsruhe.punkt.de (8.9.3/8.9.3) with ESMTP id IAA25762; Mon, 28 Jan 2002 08:52:51 +0100 (CET) (envelope-from hausen@punkt.de) Received: (from ry93@localhost) by hugo10.ka.punkt.de (8.11.4/8.11.4) id g0S7p5414157; Mon, 28 Jan 2002 08:51:05 +0100 (CET) (envelope-from ry93) From: "Patrick M. Hausen" Message-Id: <200201280751.g0S7p5414157@hugo10.ka.punkt.de> Subject: Re: Firewall config non-intuitiveness In-Reply-To: <20020127.120138.07163985.imp@village.org> To: "M. Warner Losh" Date: Mon, 28 Jan 2002 08:51:05 +0100 (CET) Cc: charon@seektruth.org, dsyphers@uchicago.edu, security-officer@FreeBSD.ORG, stable@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL92 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi all! In a long and tiring thread Warner Losh once wrote: > : > The current behavior fails safe. The current behavior is documented. > : > I relied on that documentation when setting up my firewall. Now you > : > are wanting to change that documented behavior. It is that way > : > specifically so we fail safe. > : > : The current behavior also renders systems unusable. What good is having my > : web/mail server safe doing me if it can't process any mail or http requests? > : The default rc.conf says next to firewall_enable "Set to YES to enable > : firewall functionality," which implies that NO disables firewall > : functionality. Which is read "disables firewall", not "disables custom > : firewall scripts." I view the kernel as containing stuff that's > : _potentially_ used - I can have support in it for an ethernet card > : that's not installed. But the system doesn't hang looking for it. > > Rendering the system unusable is fail safe. > > : Anyway, the default rc.conf could have firewall_enable set to YES, which > : would make it "fail safe." > > No. That's not fail safe. My machine will still break in an > unacceptible way by this change. > > Please write up the exact details that you want to do so that those on > security-officer know exactly what you are proposing. It is my > understanding that you want to make enable_firewall=NO totally dyke > out the firewall that was compiled into the kernel and be a totally > open realy. I know that this breaks at least one machine that I have, > but I also know that this breaks our current fail-safe behavior, which > I'm strongly opposed to. > > However, I think I've become too embroiled in this issue, which is why > I want the fine folks at security-officer@ to evaluate it (since I'm > on that list, I'll refrain from doing more than stating my position). > It just doesn't seem right to me. Partly I agree with you, partly I think the original author is correct in the way that the current behaviour is confusing at least to novices. apm_enable="NO" -> disable apm. sendmail_enable="NO" -> disable sendmail. firewall_enable="NO" -> you get the idea. I'd suggest changing the name of the parameter to firewall_rules_enable or firewall_script_enable, or ... Wouldn't we get rid of this entire argument, if IPFIREWALL_DEFAULT_TO_ACCEPT was the default for the kernel part of ipfw and there was an option IPFIREWALL_DEFAULT_TO_DENY for anyone preferring the "old" behaviour? Since it is recommended to explicitly state every rule in your config file - with Cisco access lists as well as with ipfw - I assume almost everyone has a "add deny all from any to any" line at the end of his ruleset already? I'm currently in a project where I build a bridging firewall. Seems like I need DEFAULT_TO_ACCEPT to get arp through. I wouldn't mind if it became the default. Regards, Patrick M. Hausen Technical Director -- punkt.de GmbH Internet - Dienstleistungen - Beratung Scheffelstr. 17 a Tel. 0721 9109 -0 Fax: -100 76135 Karlsruhe http://punkt.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 0: 0:34 2002 Delivered-To: freebsd-stable@freebsd.org Received: from server.rucus.ru.ac.za (server.rucus.ru.ac.za [146.231.115.1]) by hub.freebsd.org (Postfix) with SMTP id 3D89E37B400 for ; Mon, 28 Jan 2002 00:00:27 -0800 (PST) Received: (qmail 28293 invoked from network); 28 Jan 2002 08:00:24 -0000 Received: from shell-fxp1.rucus.ru.ac.za (HELO shell.rucus.ru.ac.za) (10.0.0.1) by server.rucus.ru.ac.za with SMTP; 28 Jan 2002 08:00:24 -0000 Received: (qmail 99390 invoked by uid 1040); 28 Jan 2002 08:00:24 -0000 Date: Mon, 28 Jan 2002 10:00:24 +0200 From: =?iso-8859-1?Q?David_Sieb=F6rger?= To: freebsd-stable@freebsd.org Subject: Re: conflict: orinoco card vs 3com in my 4.4-stable box? Message-ID: <20020128100024.A99241@rucus.ru.ac.za> References: <200201280624.g0S6OkR20473@jupiter.centrin.net.id> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <200201280624.g0S6OkR20473@jupiter.centrin.net.id> Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG budsan02@bdg.centrin.net.id wrote: > here is my configuration in rc.conf: > gateway_enable="yes" > default_router="202.143.99.200" <-- ISP's gateway ip. > pccard_enable="yes" > pccard_config="inet 202.143.97.210 netmask 255.255.255.252" <--orinoco static ip. Double-check those IP addresses and netmask. With a 255.255.255.252 netmask, you won't be able to reach 202.143.99.200 directly. With your configuration as it is, I expect you'll see a message like this as your PC boots: add net default: gateway 202.143.99.200: Network is unreachable -- David Siebörger drs-stable@rucus.ru.ac.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 0:11:22 2002 Delivered-To: freebsd-stable@freebsd.org Received: from dream.mplik.ru (dream.mplik.ru [195.58.1.132]) by hub.freebsd.org (Postfix) with ESMTP id D06E137B402 for ; Mon, 28 Jan 2002 00:11:15 -0800 (PST) Received: from sight (sight.mplik.ru [195.58.27.104]) by dream.mplik.ru (8.9.3/8.9.1) with ESMTP id NAA09032; Mon, 28 Jan 2002 13:11:01 +0500 (YEKT) Date: Mon, 28 Jan 2002 13:09:47 +0500 From: Sergey Gershtein X-Mailer: The Bat! (v1.53bis) Business Reply-To: Sergey Gershtein Organization: Ural Relcom Ltd X-Priority: 3 (Normal) Message-ID: <1931130530386.20020128130947@ur.ru> To: Doug White Cc: freebsd-stable@FreeBSD.ORG Subject: Re[5]: Strange lock-ups during backup over nfs after adding 1024M RAM In-Reply-To: <20020126204941.H17540-100000@resnet.uoregon.edu> References: <20020126204941.H17540-100000@resnet.uoregon.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sunday, January 27, 2002 you wrote: >> Today the lock-up happened again during backup over nfs with no sign >> in any log files or on console. It was running 4.4-STABLE kernel >> cvsuped yesterday with MAXUSERS 128 and NMBCLUSTERS=8192... Any ideas >> on where to look? DW> Get a serial console. Something may be logged but since it doesn't sync to DW> disk you can't see it afterwards. There is nothing unusual on the console, I checked that. I don't have a serial console, but I guess there's nothing wrong with a regular monitor and keyboard that I use. It was surprising to me that when everything is locked-up you can still type on the keyboard, switch consoles (alt-F1..Alt-Fn), but not log in or even reboot the system with ctrl-alt-del. It just ignores ctrl-alt-del, but allowes to type, scroll the console with arrow keys after pressing scrollLock, etc. There is additional weird thing that I found -- there was at least one process in the system that continued running and writing to log files. It was nmbd that continued to answer its queries and was able to write to log file. All other log files including /var/log/cron and web server logs stopped at the time of lock-up. >> The strange thins is that we have another server with exactly the same >> hardware and amout of RAM which works fine. The only difference is >> that its kernel was compiled with MAXUSERS 1024 for some reason. Do I >> really need to bump MAXUSERS so high to handle more than 1Gb of RAM? DW> So *high*? You need to *reduce* it! 128 should work; if that is blowing DW> up on wierd VM failures, start up a crontask that runs 'sysctl vm.zone' DW> and 'netstat -m' every so often and logs the output. That will say what is DW> gobbling up all the space. DW> NFS is also suspicious .. this is after you updated to today's -STABLE? Currently the server that suffers lock-ups has 1,5Gb RAM, 4.4-RELEASE-p4 kernel csvuped on Jan 24 and compiled with MAXUSERS 128 and NMBCLUSTERS=4096. We disabled backup during the weekend and everything was fine. But right now while I was typing this the lock-up happened again. I just set up a cron job with 'sysctl vm.zone' and 'netstat -m' and the last output was the following: ------------------------------------------------------ vm.zone: ITEM SIZE LIMIT USED FREE REQUESTS PIPE: 160, 0, 28, 74, 517824 SWAPMETA: 160, 385728, 1, 24, 1 unpcb: 64, 0, 29, 227, 15866052 ripcb: 192, 4136, 0, 42, 102 tcpcb: 544, 4136, 2446, 1404, 9889396 udpcb: 192, 4136, 32, 115, 3212780 socket: 192, 4136, 2507, 1462, 28974999 KNOTE: 64, 0, 0, 192, 3139957 NFSNODE: 352, 0, 0, 0, 0 NFSMOUNT: 544, 0, 0, 0, 0 VNODE: 192, 0, 203330, 84, 203330 NAMEI: 1024, 0, 1, 47, 693373551 VMSPACE: 192, 0, 296, 152, 221127 PROC: 416, 0, 300, 141, 221149 DP fakepg: 64, 0, 0, 0, 0 PV ENTRY: 28, 1199982, 192743, 200448, 505651089 MAP ENTRY: 48, 0, 7100, 3398, 40174897 KMAP ENTRY: 48, 96560, 1001, 147, 573777 MAP: 108, 0, 7, 3, 7 VM OBJECT: 96, 0, 203957, 83, 6800770 ------------------------------------------------------ 241/736/16384 mbufs in use (current/peak/max): 197 mbufs allocated to data 44 mbufs allocated to packet headers 175/492/4096 mbuf clusters in use (current/peak/max) 1168 Kbytes allocated to network (9% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines ====================================================== The same output right after reboot: ====================================================== vm.zone: ITEM SIZE LIMIT USED FREE REQUESTS PIPE: 160, 0, 41, 61, 3046 SWAPMETA: 160, 385728, 0, 0, 0 unpcb: 64, 0, 42, 214, 41927 ripcb: 192, 4136, 0, 42, 96 tcpcb: 544, 4136, 2285, 242, 30823 udpcb: 192, 4136, 33, 30, 4686 socket: 192, 4136, 2360, 265, 77534 KNOTE: 64, 0, 1, 127, 4430 NFSNODE: 352, 0, 0, 0, 0 NFSMOUNT: 544, 0, 0, 0, 0 VNODE: 192, 0, 5202, 98, 5202 NAMEI: 1024, 0, 2, 94, 2673554 VMSPACE: 192, 0, 300, 148, 2176 PROC: 416, 0, 304, 137, 2181 DP fakepg: 64, 0, 0, 0, 0 PV ENTRY: 28, 1199982, 170530, 222661, 2468552 MAP ENTRY: 48, 0, 7354, 2464, 125904 KMAP ENTRY: 48, 96560, 1059, 174, 6141 MAP: 108, 0, 7, 3, 7 VM OBJECT: 96, 0, 6682, 168, 37244 ------------------------------------------------------ 317/960/16384 mbufs in use (current/peak/max): 266 mbufs allocated to data 51 mbufs allocated to packet headers 240/686/4096 mbuf clusters in use (current/peak/max) 1612 Kbytes allocated to network (13% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines ====================================================== Is there a chance that cvsuping to 4.5-RC and compiling the kernel with MAXUSERS 0 will make it better? Regards, Sergey Gershtein To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 0:28:18 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mile.nevermind.kiev.ua (freebsddiary.org.ua [213.186.199.26]) by hub.freebsd.org (Postfix) with ESMTP id 6B35C37B400 for ; Mon, 28 Jan 2002 00:28:07 -0800 (PST) Received: (from never@localhost) by mile.nevermind.kiev.ua (8.11.6/8.11.4) id g0S8RAQ55090; Mon, 28 Jan 2002 10:27:10 +0200 (EET) (envelope-from never) Date: Mon, 28 Jan 2002 10:27:10 +0200 From: Nevermind To: Joe Halpin Cc: freebsd-stable@FreeBSD.ORG Subject: Re: FreeBSD install doesn't see the whole disk Message-ID: <20020128082710.GD41742@nevermind.kiev.ua> References: <3C533643.E161CC67@attbi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <3C533643.E161CC67@attbi.com> User-Agent: Mutt/1.3.26i Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, Joe Halpin! On Sat, Jan 26, 2002 at 05:05:39PM -0600, you wrote: > I just put a new 30GB drive in my test machine (Maxtor IDE). When I > tried to install, fdisk didn't get the drive size right. So I used the > 'G' option and set the drive geometry manually. The summary at the top > of the screen looked correct after that, but the 'C' create option > apparently didn't get updated, and wouldn't let me create more than a > 2GB partition. > > Anyone have ideas? Try to set exact geometry for this drive manually, not autodetect in bios. Do you have 53073H4 model? If so, then set in your BIOS settings manually: 59554 cyl, 16 heads, 63 sectors. For reference see: http://www.maxtor.com/products/DiamondMax/DiamondMaxPlus/QuickSpecs/42077.pdf I had the same problems with my ad0: 14655MB [29777/16/63] at ata0-master UDMA100 -- NEVE-RIPE To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 0:35:38 2002 Delivered-To: freebsd-stable@freebsd.org Received: from hawk.prod.itd.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 7A2CD37B400 for ; Mon, 28 Jan 2002 00:35:31 -0800 (PST) Received: from dialup-209.247.139.86.dial1.sanjose1.level3.net ([209.247.139.86] helo=blossom.cjclark.org) by hawk.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16V7G3-0001TI-00; Mon, 28 Jan 2002 00:35:25 -0800 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.3) id g0S8YBe28634; Mon, 28 Jan 2002 00:34:11 -0800 (PST) (envelope-from cjc) Date: Mon, 28 Jan 2002 00:34:02 -0800 From: "Crist J. Clark" To: Hervey Wilson Cc: freebsd-stable@FreeBSD.ORG Subject: Re: ipfilter_enable problem on 4.5 Message-ID: <20020128003402.D27080@blossom.cjclark.org> References: <001201c1a7c7$f7b74c40$0301a8c0@neo> <000d01c1a7d0$7396e6b0$0301a8c0@neo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000d01c1a7d0$7396e6b0$0301a8c0@neo>; from herveyw@dynamic-cast.com on Sun, Jan 27, 2002 at 11:50:27PM -0800 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jan 27, 2002 at 11:50:27PM -0800, Hervey Wilson wrote: > Updated diagnostics inline, appears to be a problem between > /etc/defaults/rc.conf and /etc/rc.network. Maybe I have a bad cvsup or > merge - can anyone confirm the file contents below ? It looks like you did not update your /etc/defaults/rc.conf, $ fgrep ipfilter etc/defaults/rc.conf ipfilter_enable="NO" # Set to YES to enable ipfilter functionality ipfilter_program="/sbin/ipf" # where the ipfilter program lives ipfilter_rules="/etc/ipf.rules" # rules definition file for ipfilter, see # /usr/src/contrib/ipfilter/rules for examples ipfilter_flags="" # additional flags for ipfilter > ----- Original Message ----- > From: "Hervey Wilson" > To: > Sent: Sunday, January 27, 2002 10:49 PM > Subject: ipfilter_enable problem on 4.5 > > > > I just upgraded my server to 4.5 RC from 4-STABLE last cvsup'd late last > > year and it appears that my IP filter configuration is no longer being > > automatically loaded. I know this since it's set to default block and once > > the server boots, I've lost all contact with both the connected networks > and > > the loopback interfaces. Reloading ipfilter using the commands from > rc.conf > > results in a working system. rc.conf has simply: > > > > ipfilter_enable="YES" > > /etc/defaults/rc.conf has: > > ipfilter_program="/sbin/ipf -Fa -f" > ipfilter_rules="/etc/ipf.rules" > ipfilter_flags="-E" > > In rc.network, at the point where IPF is to be loaded, I find: > > ... > echo -n ' ipfilter' > ${ipfilter_program:-/sbin/ipf} -Fa -f "${ipfilter_rules}" ${ipfilter_flags} > ... > > which therefore results in the following command at boot: > > /sbin/ipf -Fa -f -Fa -f /etc/ipf.rules -E > > leading to ipf trying to open a file called "-Fa" as a result of the > duplicate switches. > > > > > With rules in /etc/ipf.rules. IP filter is also compiled into my kernel; I > > see the initialization message during boot but cannot find any other > > messages regarding the load of the rules - has anyone else run into this > or > > can suggest where I look for additional error messages beyond > > /var/log/messages ? > > Finally found the file open error in dmesg, d'oh ;) > > H > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" in the body of the message -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 1:45:12 2002 Delivered-To: freebsd-stable@freebsd.org Received: from andrsn.stanford.edu (andrsn.Stanford.EDU [171.66.112.163]) by hub.freebsd.org (Postfix) with ESMTP id 3004537B402 for ; Mon, 28 Jan 2002 01:45:06 -0800 (PST) Received: from localhost (andrsn@localhost.stanford.edu [127.0.0.1]) by andrsn.stanford.edu (8.9.3/8.9.1) with ESMTP id BAA18180; Mon, 28 Jan 2002 01:34:23 -0800 (PST) Date: Mon, 28 Jan 2002 01:34:23 -0800 (PST) From: Annelise Anderson To: Makoto Matsushita Cc: stable@FreeBSD.ORG Subject: Re: New cdboot ISO available In-Reply-To: <20020127233016E.matusita@jp.FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 27 Jan 2002, Makoto Matsushita wrote: > > andrsn> I used the RC1 cdboot to install FreeBSD in vmware on my ASUS > andrsn> Thunder K7 running win2k. It worked fine although it was very > andrsn> slow to boot (even after recompiling the kernel, it's slow). > andrsn> Slow is 20 or 30 minutes....I have no clue about why this is > andrsn> the case, but I assume once installed, it doesn't matter how > andrsn> it got there. > > (I suppose your VMware's version is 3.0) > > What's happen if you change your VMware's BIOS configuration, to > disable DMA disk access? > I looked at the VMWare BIOS and it seems to have no option for disabling DMA access. However it was VMWare version 2, no longer boots, and I can't seem to repeat the reinstalling trick (although I did it twice); so guess I'll try VMWare 3. Annelise -- Annelise Anderson Author of: FreeBSD: An Open-Source Operating System for Your PC Available from: BSDmall.com and amazon.com Book Website: http://www.bittreepress.com/FreeBSD/introbook/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 2:47:12 2002 Delivered-To: freebsd-stable@freebsd.org Received: from scribble.fsn.hu (scribble.fsn.hu [193.224.40.95]) by hub.freebsd.org (Postfix) with SMTP id 87CE737B404 for ; Mon, 28 Jan 2002 02:47:08 -0800 (PST) Received: (qmail 11377 invoked by uid 1000); 28 Jan 2002 10:47:07 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 28 Jan 2002 10:47:07 -0000 Date: Mon, 28 Jan 2002 11:47:07 +0100 (CET) From: Attila Nagy To: Jason Andresen Cc: freebsd-stable@freebsd.org Subject: Re: Multiple Promise controllers In-Reply-To: <3C51CB7A.8E23CD60@mitre.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, > This brings me to my final option: has anybody managed to mix IDE > controller cards successfully? What cards are good for this? Quoting Soren Schmidt: Q: "Is it possible to use multiple Promise ATA-100 cards in one machine? If yes, how much?" A: "Yes, you should be able to use as many as you have PCI slots for. I have made systems with 3 promises with no problems." And: "Well, I would buy HPT370 based cards, like the Abit hotrod100, the HPT370 chip is a far better design than the promise, and gives better performance." So I think it is possible to use more than two Promise ATA cards, but the HPT 37x is the preferred way, by the ATA-driver author. -------------------------------------------------------------------------- Attila Nagy e-mail: Attila.Nagy@fsn.hu Budapest Polytechnic (BMF.HU) @work: +361 210 1415 (194) H-1084 Budapest, Tavaszmezo u. 15-17. cell.: +3630 306 6758 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 3: 6:38 2002 Delivered-To: freebsd-stable@freebsd.org Received: from venus.vulcan.nu (luna.vulcan.nu [213.84.24.53]) by hub.freebsd.org (Postfix) with ESMTP id 3AE4F37B41E for ; Mon, 28 Jan 2002 03:06:10 -0800 (PST) Received: from terra.ad.vulcan.nu (terra.ad.vulcan.nu [172.16.1.90]) by venus.vulcan.nu (Postfix) with ESMTP id CBA4C2AA1C; Mon, 28 Jan 2002 12:06:08 +0100 (CET) Received: from mail pickup service by terra.ad.vulcan.nu with Microsoft SMTPSVC; Mon, 28 Jan 2002 12:06:08 +0100 From: Thread-Topic: MailMonitor for Exchange delivery from quarantine Cc: To: "Jason Andresen" thread-index: AcGn68lyaRHYxwbERlKMqm20TRSmYw== Subject: MailMonitor for Exchange delivery from quarantine Date: Mon, 28 Jan 2002 12:06:08 +0100 Message-ID: <000c01c1a7eb$c98a9420$5a0110ac@ad.vulcan.nu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000D_01C1A7F4.2B4EFC20" X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 28 Jan 2002 11:06:08.0594 (UTC) FILETIME=[C9AF3320:01C1A7EB] Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C1A7F4.2B4EFC20 Content-Type: text/plain Content-Transfer-Encoding: 7bit MailMonitor for Exchange 2000 has found a virus or encrypted content in the email. Your mail administrator has removed the affected attachment(s) or part(s) of the email before sending it to you. For more details, contact your mail administrator. ------=_NextPart_000_000D_01C1A7F4.2B4EFC20 Content-Type: message/rfc822; name="Re%3A Multiple Promise controllers[Scanned].EML" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Re%3A Multiple Promise controllers[Scanned].EML" thread-index: AcGn6TlDrb6yx56JT6igUiEeMaPnBQ== Received: from venus.vulcan.nu ([172.16.0.1]) by terra.ad.vulcan.nu with Microsoft SMTPSVC(5.0.2195.3779); Mon, 28 Jan 2002 11:47:47 +0100 Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by venus.vulcan.nu (Postfix) with SMTP id 6B2AA2AA23 for ; Mon, 28 Jan 2002 11:47:44 +0100 (CET) Received: from hub.freebsd.org (hub.FreeBSD.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id D118B55413; Mon, 28 Jan 2002 02:45:29 -0800 (PST) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: by hub.freebsd.org (Postfix, from userid 538) id 065C737B41B; Mon, 28 Jan 2002 02:47:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id AE0872E8007; Mon, 28 Jan 2002 02:47:11 -0800 (PST) Received: by hub.freebsd.org (bulk_mailer v1.12); Mon, 28 Jan 2002 02:47:11 -0800 Delivered-To: freebsd-stable@freebsd.org Received: from scribble.fsn.hu (scribble.fsn.hu [193.224.40.95]) by hub.freebsd.org (Postfix) with SMTP id 87CE737B404 for ; Mon, 28 Jan 2002 02:47:08 -0800 (PST) Received: (qmail 11377 invoked by uid 1000); 28 Jan 2002 10:47:07 -0000 Content-Transfer-Encoding: 7bit Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 28 Jan 2002 10:47:07 -0000 Date: Mon, 28 Jan 2002 11:47:07 +0100 (CET) From: "Attila Nagy" To: "Jason Andresen" Cc: Subject: Re: Multiple Promise controllers[Scanned] In-Reply-To: <3C51CB7A.8E23CD60@mitre.org> Content-Class: urn:content-classes:message Importance: normal Priority: normal Message-ID: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Sender: List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Precedence: bulk Return-Path: X-OriginalArrivalTime: 28 Jan 2002 10:47:47.0090 (UTC) FILETIME=[39230720:01C1A7E9] Hello, > This brings me to my final option: has anybody managed to mix IDE > controller cards successfully? What cards are good for this? Quoting Soren Schmidt: Q: "Is it possible to use multiple Promise ATA-100 cards in one machine? If yes, how much?" A: "Yes, you should be able to use as many as you have PCI slots for. I have made systems with 3 promises with no problems." And: "Well, I would buy HPT370 based cards, like the Abit hotrod100, the HPT370 chip is a far better design than the promise, and gives better performance." So I think it is possible to use more than two Promise ATA cards, but the HPT 37x is the preferred way, by the ATA-driver author. -------------------------------------------------------------------------- Attila Nagy e-mail: Attila.Nagy@fsn.hu Budapest Polytechnic (BMF.HU) @work: +361 210 1415 (194) H-1084 Budapest, Tavaszmezo u. 15-17. cell.: +3630 306 6758 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message ------=_NextPart_000_000D_01C1A7F4.2B4EFC20-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 5:36:50 2002 Delivered-To: freebsd-stable@freebsd.org Received: from veldy.net (veldy-host33.dsl.visi.com [209.98.200.33]) by hub.freebsd.org (Postfix) with ESMTP id 200D537B404 for ; Mon, 28 Jan 2002 05:36:46 -0800 (PST) Received: from HP2500B (localhost.veldy.net [127.0.0.1]) by veldy.net (Postfix) with SMTP id 996661A191; Mon, 28 Jan 2002 07:36:43 -0600 (CST) Message-ID: <006b01c1a800$86ff28e0$3028680a@tgt.com> From: "Thomas T. Veldhouse" To: "Cliff Sarginson" , References: <20020127220923.B1494@shell.gsinet.sittig.org> <20020127134511.Q81780-100000@rockstar.stealthgeeks.net> <20020128064925.GA1180@raggedclown.net> Subject: Re: Firewall config non-intuitiveness Date: Mon, 28 Jan 2002 07:34:35 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG All right -- it is time ..... Hitler. Tom Veldhouse veldy@veldy.net ----- Original Message ----- From: "Cliff Sarginson" To: Sent: Monday, January 28, 2002 12:49 AM Subject: Re: Firewall config non-intuitiveness > On Sun, Jan 27, 2002 at 02:50:50PM -0800, Patrick Greenwell wrote: > > > > Really, I'm just arguing for doing something that makes sense, and the > > current behavior does not qualify, regardless of how long it's been > > understood to be broken that way. Even if this behavior were adequately > > documented, which it isn't, it's extremely user-unfriendly to have no mean > > yes. > > > > At this point I'm rather reticent to even bother submitting anything to > > the "security officer" role as Warner has indicated that he's part of that > > role and will speak out against it in the name of security. I'm not a > > member of the inner circle, just a long-time user who saw some confusing > > behavior and thought that there was an opportunity to fix it. > > > I think you were quite right to, and I think you are right. > But you are fighting the forces of reaction here, in my view. > This whole thread has been a very depressing reflection on the > inability of any of the people arguing against you to make > any coherent argument against changing something to make sense. > > This is just conservative status-quoism gone mad. > > You are not alone in finding the current wording and behaviour > of this feature inconsistent, and initially incoherent. > > Perhaps we are just too dumb. > > -- > Regards > Cliff > > > > 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 From owner-freebsd-stable Mon Jan 28 5:44:32 2002 Delivered-To: freebsd-stable@freebsd.org Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id C297437B402; Mon, 28 Jan 2002 05:44:27 -0800 (PST) Received: from madman.nectar.cc (madman.nectar.cc [10.0.1.111]) by gw.nectar.cc (Postfix) with ESMTP id 2B7F94C; Mon, 28 Jan 2002 07:44:27 -0600 (CST) Received: (from nectar@localhost) by madman.nectar.cc (8.11.6/8.11.6) id g0SDiRj38385; Mon, 28 Jan 2002 07:44:27 -0600 (CST) (envelope-from nectar) Date: Mon, 28 Jan 2002 07:44:27 -0600 From: "Jacques A. Vidrine" To: "Patrick M. Hausen" Cc: security-officer@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: Firewall config non-intuitiveness Message-ID: <20020128134427.GF33952@madman.nectar.cc> References: <20020127.120138.07163985.imp@village.org> <200201280751.g0S7p5414157@hugo10.ka.punkt.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200201280751.g0S7p5414157@hugo10.ka.punkt.de> User-Agent: Mutt/1.3.27i X-Url: http://www.nectar.cc/ Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jan 28, 2002 at 08:51:05AM +0100, Patrick M. Hausen wrote: > Wouldn't we get rid of this entire argument, if IPFIREWALL_DEFAULT_TO_ACCEPT > was the default for the kernel part of ipfw and there was an option > IPFIREWALL_DEFAULT_TO_DENY for anyone preferring the "old" behaviour? This will not happen. Default-to-accept is unsafe. -- Jacques A. Vidrine http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 5:45:23 2002 Delivered-To: freebsd-stable@freebsd.org Received: from veldy.net (veldy-host33.dsl.visi.com [209.98.200.33]) by hub.freebsd.org (Postfix) with ESMTP id 8010837B430 for ; Mon, 28 Jan 2002 05:45:02 -0800 (PST) Received: from HP2500B (localhost.veldy.net [127.0.0.1]) by veldy.net (Postfix) with SMTP id AE8BE1A191; Mon, 28 Jan 2002 07:45:00 -0600 (CST) Message-ID: <007e01c1a801$af40ae90$3028680a@tgt.com> From: "Thomas T. Veldhouse" To: "Hervey Wilson" , References: <001201c1a7c7$f7b74c40$0301a8c0@neo> <000d01c1a7d0$7396e6b0$0301a8c0@neo> Subject: Re: ipfilter_enable problem on 4.5 Date: Mon, 28 Jan 2002 07:42:52 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG You /etc/defaults/rc.conf should have this: ipfilter_enable="NO" # Set to YES to enable ipfilter functionality ipfilter_program="/sbin/ipf" # where the ipfilter program lives ipfilter_rules="/etc/ipf.rules" # rules definition file for ipfilter, see You should never edit /etc/defaults/rc.conf, but instead, override it by placing entries in /etc/rc.conf. Essentially, it looks like you need to remove the "-Fa -f" options from your ipfilter_program knob in /etc/defaults/rc.conf to get it back to the way it was. -Fa will flush all the rules, no problem, but -f expects a filename as a parameter and you are not supplying it with one. Tom Veldhouse veldy@veldy.net ----- Original Message ----- From: "Hervey Wilson" To: Sent: Monday, January 28, 2002 1:50 AM Subject: Re: ipfilter_enable problem on 4.5 > Updated diagnostics inline, appears to be a problem between > /etc/defaults/rc.conf and /etc/rc.network. Maybe I have a bad cvsup or > merge - can anyone confirm the file contents below ? > > H > > ----- Original Message ----- > From: "Hervey Wilson" > To: > Sent: Sunday, January 27, 2002 10:49 PM > Subject: ipfilter_enable problem on 4.5 > > > > I just upgraded my server to 4.5 RC from 4-STABLE last cvsup'd late last > > year and it appears that my IP filter configuration is no longer being > > automatically loaded. I know this since it's set to default block and once > > the server boots, I've lost all contact with both the connected networks > and > > the loopback interfaces. Reloading ipfilter using the commands from > rc.conf > > results in a working system. rc.conf has simply: > > > > ipfilter_enable="YES" > > /etc/defaults/rc.conf has: > > ipfilter_program="/sbin/ipf -Fa -f" > ipfilter_rules="/etc/ipf.rules" > ipfilter_flags="-E" > > In rc.network, at the point where IPF is to be loaded, I find: > > ... > echo -n ' ipfilter' > ${ipfilter_program:-/sbin/ipf} -Fa -f "${ipfilter_rules}" ${ipfilter_flags} > ... > > which therefore results in the following command at boot: > > /sbin/ipf -Fa -f -Fa -f /etc/ipf.rules -E > > leading to ipf trying to open a file called "-Fa" as a result of the > duplicate switches. > > > > > With rules in /etc/ipf.rules. IP filter is also compiled into my kernel; I > > see the initialization message during boot but cannot find any other > > messages regarding the load of the rules - has anyone else run into this > or > > can suggest where I look for additional error messages beyond > > /var/log/messages ? > > Finally found the file open error in dmesg, d'oh ;) > > H > > > 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 From owner-freebsd-stable Mon Jan 28 5:51:55 2002 Delivered-To: freebsd-stable@freebsd.org Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id CD3FB37B435; Mon, 28 Jan 2002 05:51:17 -0800 (PST) Received: from madman.nectar.cc (madman.nectar.cc [10.0.1.111]) by gw.nectar.cc (Postfix) with ESMTP id 6980C34; Mon, 28 Jan 2002 07:51:17 -0600 (CST) Received: (from nectar@localhost) by madman.nectar.cc (8.11.6/8.11.6) id g0SDpEc38426; Mon, 28 Jan 2002 07:51:14 -0600 (CST) (envelope-from nectar) Date: Mon, 28 Jan 2002 07:51:14 -0600 From: "Jacques A. Vidrine" To: charon@seektruth.org Cc: security-officer@freebsd.org, stable@freebsd.org Subject: Re: Firewall config non-intuitiveness Message-ID: <20020128135114.GG33952@madman.nectar.cc> References: <3.0.5.32.20020127075816.01831ca0@mail.sage-american.com> <200201271757.g0RHvTF12944@midway.uchicago.edu> <20020127.110854.32932954.imp@village.org> <200201271853.g0RIrVF03620@midway.uchicago.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200201271853.g0RIrVF03620@midway.uchicago.edu> User-Agent: Mutt/1.3.27i X-Url: http://www.nectar.cc/ Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jan 27, 2002 at 12:53:34PM -0600, David Syphers wrote: > The fact that something is documented doesn't mean it should remain > unchanged. No, it doesn't. There's no single `fact' that makes a change acceptable or not. > If a manpage has a bugs section, does this mean we shouldn't try > to fix anything listed there? Docs are supposed to conform to programs, not > the other way around. Warner maintains UPDATING, right? A change like this > would go in there. That file is a list of changes to documented behavior. > And we expect people to read it, especially if they've read enough docs to > know the true meaning of firewall_enable. At least within a release (e.g. 4.x), we try to avoid changing defaults that would result in existing administrators shooting themselves in the foot. > The current behavior also renders systems unusable. What good is having my > web/mail server safe doing me if it can't process any mail or http > requests? When you fix it, you will not have the additional worry that it has been comprimised because your firewall rules weren't loaded. > The default rc.conf says next to firewall_enable "Set to YES to enable > firewall functionality," which implies that NO disables firewall > functionality. I never read it that way, but I can understand your point. > Which is read "disables firewall", not "disables custom > firewall scripts." I view the kernel as containing stuff that's > _potentially_ used - I can have support in it for an ethernet card > that's not > installed. But the system doesn't hang looking for it. > > Anyway, the default rc.conf could have firewall_enable set to YES, which > would make it "fail safe." I missed the beginning of this thread. If anybody still actually cares, will they please follow Warner's suggestion and post a concise summary to ? Cheers, -- Jacques A. Vidrine http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 5:56:49 2002 Delivered-To: freebsd-stable@freebsd.org Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id C222937B402 for ; Mon, 28 Jan 2002 05:56:44 -0800 (PST) Received: from madman.nectar.cc (madman.nectar.cc [10.0.1.111]) by gw.nectar.cc (Postfix) with ESMTP id 44E5434; Mon, 28 Jan 2002 07:56:44 -0600 (CST) Received: (from nectar@localhost) by madman.nectar.cc (8.11.6/8.11.6) id g0SDuhf38457; Mon, 28 Jan 2002 07:56:43 -0600 (CST) (envelope-from nectar) Date: Mon, 28 Jan 2002 07:56:43 -0600 From: "Jacques A. Vidrine" To: Cliff Sarginson Cc: stable@freebsd.org Subject: Re: Firewall config non-intuitiveness Message-ID: <20020128135643.GH33952@madman.nectar.cc> References: <20020127220923.B1494@shell.gsinet.sittig.org> <20020127134511.Q81780-100000@rockstar.stealthgeeks.net> <20020128064925.GA1180@raggedclown.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020128064925.GA1180@raggedclown.net> User-Agent: Mutt/1.3.27i X-Url: http://www.nectar.cc/ Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jan 28, 2002 at 07:49:25AM +0100, Cliff Sarginson wrote: > On Sun, Jan 27, 2002 at 02:50:50PM -0800, Patrick Greenwell wrote: > > At this point I'm rather reticent to even bother submitting anything to > > the "security officer" role as Warner has indicated that he's part of that > > role and will speak out against it in the name of security. I'm not a > > member of the inner circle, just a long-time user who saw some confusing > > behavior and thought that there was an opportunity to fix it. Warner's not the only member of the Security Officer Team. If you actually feel there is a problem, please write it up concisely. I have only seen vague arguments here (probably because I missed the beginning of the thread), and couldn't make a judgement. I'm sure others are in the same position. > I think you were quite right to, and I think you are right. > But you are fighting the forces of reaction here, in my view. > This whole thread has been a very depressing reflection on the > inability of any of the people arguing against you to make > any coherent argument against changing something to make sense. > > This is just conservative status-quoism gone mad. > > You are not alone in finding the current wording and behaviour > of this feature inconsistent, and initially incoherent. > > Perhaps we are just too dumb. Or perhaps there has been no effective case made for a change. Cheers, -- Jacques A. Vidrine http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 6:22:20 2002 Delivered-To: freebsd-stable@freebsd.org Received: from smtpproxy2.mitre.org (smtpproxy2.mitre.org [128.29.154.90]) by hub.freebsd.org (Postfix) with ESMTP id 2E2E937B400 for ; Mon, 28 Jan 2002 06:22:03 -0800 (PST) Received: from avsrv2.mitre.org (avsrv2.mitre.org [128.29.154.4]) by smtpproxy2.mitre.org (8.11.3/8.11.3) with ESMTP id g0SELsc18063; Mon, 28 Jan 2002 09:21:55 -0500 (EST) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv2.mitre.org (8.11.3/8.11.3) with ESMTP id g0SELqi25930; Mon, 28 Jan 2002 09:21:53 -0500 (EST) Received: from dhcp-105-164.mitre.org (128.29.105.164) by mailhub1.mitre.org with SMTP id 8980606; Mon, 28 Jan 2002 09:21:16 -0500 Message-ID: <3C555E80.6F4DF431@mitre.org> Date: Mon, 28 Jan 2002 09:21:52 -0500 From: Jason Andresen Organization: The MITRE Corporation X-Mailer: Mozilla 4.75 [en]C-20000818M (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Lawrence Farr Cc: freebsd-stable@freebsd.org, craig@meoqu.gank.org, "'Kent Stewart'" Subject: Re: Multiple Promise controllers References: <002d01c1a65a$6620af10$c80aa8c0@lfarr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Lawrence Farr wrote: > > I love the 3ware controllers, and have: > > twe0: <3ware Storage Controller> port 0xa400-0xa40f mem > 0xde800000-0xdeffffff,0xdf000000-0xdf00000f irq 11 at device 12.0 on > pci0 > twe0: 8 ports, Firmware FE7X 1.02.01.043, BIOS BE7X 1.07.01.009 > twed0: on twe0 > twed0: 667766MB (1367586304 sectors) > > Now they're on sale again, Im gonna get a few more! Even on sale $300US is a bit more than I was wanting to spend on a system I was trying to keep under $1500. :) Those certainly look like nice cards though, I'll keep them in mind for the future. -- \ |_ _|__ __|_ \ __| Jason Andresen jandrese@mitre.org |\/ | | | / _| Network and Distributed Systems Engineer _| _|___| _| _|_\___| Office: 703-883-7755 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 6:33:10 2002 Delivered-To: freebsd-stable@freebsd.org Received: from smtpproxy2.mitre.org (smtpproxy2.mitre.org [128.29.154.90]) by hub.freebsd.org (Postfix) with ESMTP id 5F87F37B416 for ; Mon, 28 Jan 2002 06:33:04 -0800 (PST) Received: from avsrv2.mitre.org (avsrv2.mitre.org [128.29.154.4]) by smtpproxy2.mitre.org (8.11.3/8.11.3) with ESMTP id g0SEWXc19865; Mon, 28 Jan 2002 09:32:33 -0500 (EST) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv2.mitre.org (8.11.3/8.11.3) with ESMTP id g0SEWWi26917; Mon, 28 Jan 2002 09:32:32 -0500 (EST) Received: from dhcp-105-164.mitre.org (128.29.105.164) by mailhub1.mitre.org with SMTP id 8980899; Mon, 28 Jan 2002 09:31:56 -0500 Message-ID: <3C5560FF.E89644EF@mitre.org> Date: Mon, 28 Jan 2002 09:32:31 -0500 From: Jason Andresen Organization: The MITRE Corporation X-Mailer: Mozilla 4.75 [en]C-20000818M (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Attila Nagy Cc: freebsd-stable@freebsd.org Subject: Re: Multiple Promise controllers References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Attila Nagy wrote: > > Hello, > > > This brings me to my final option: has anybody managed to mix IDE > > controller cards successfully? What cards are good for this? > Quoting Soren Schmidt: > > Q: "Is it possible to use multiple Promise ATA-100 cards in one machine? > If yes, how much?" > A: "Yes, you should be able to use as many as you have PCI slots for. > I have made systems with 3 promises with no problems." > > And: "Well, I would buy HPT370 based cards, like the Abit hotrod100, the > HPT370 chip is a far better design than the promise, and gives better > performance." > > So I think it is possible to use more than two Promise ATA cards, but the > HPT 37x is the preferred way, by the ATA-driver author. Quick question to anybody who has these cards: Can HPT370 based cards run as JBOD (with all of the RAID features turned off) controllers? I'm not looking for the card to do any sort of RAID itself since that's what I'm using vinum for. Mostly, I'm trying to avoid having two disks on the same lun share an IDE controller (IE as master and slave). -- \ |_ _|__ __|_ \ __| Jason Andresen jandrese@mitre.org |\/ | | | / _| Network and Distributed Systems Engineer _| _|___| _| _|_\___| Office: 703-883-7755 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 6:55:23 2002 Delivered-To: freebsd-stable@freebsd.org Received: from post.mail.nl.demon.net (post-11.mail.nl.demon.net [194.159.73.21]) by hub.freebsd.org (Postfix) with ESMTP id D94A737B400 for ; Mon, 28 Jan 2002 06:55:19 -0800 (PST) Received: from [212.238.194.207] (helo=tanya.raggedclown.net) by post.mail.nl.demon.net with esmtp (Exim 3.33 #1) id 16VDBm-000Ms3-00 for stable@freebsd.org; Mon, 28 Jan 2002 14:55:18 +0000 Received: by tanya.raggedclown.net (tanya.raggedclown.intra, from userid 500) id DBEAE45218; Mon, 28 Jan 2002 15:55:17 +0100 (CET) Date: Mon, 28 Jan 2002 15:55:17 +0100 From: Cliff Sarginson To: stable@freebsd.org Subject: Re: Firewall config non-intuitiveness Message-ID: <20020128145517.GB1907@raggedclown.net> References: <20020127220923.B1494@shell.gsinet.sittig.org> <20020127134511.Q81780-100000@rockstar.stealthgeeks.net> <20020128064925.GA1180@raggedclown.net> <20020128135643.GH33952@madman.nectar.cc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020128135643.GH33952@madman.nectar.cc> User-Agent: Mutt/1.3.24i Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jan 28, 2002 at 07:56:43AM -0600, Jacques A. Vidrine wrote: > On Mon, Jan 28, 2002 at 07:49:25AM +0100, Cliff Sarginson wrote: > > On Sun, Jan 27, 2002 at 02:50:50PM -0800, Patrick Greenwell wrote: > > > At this point I'm rather reticent to even bother submitting anything to > > > the "security officer" role as Warner has indicated that he's part of that > > > role and will speak out against it in the name of security. I'm not a > > > member of the inner circle, just a long-time user who saw some confusing > > > behavior and thought that there was an opportunity to fix it. > > Warner's not the only member of the Security Officer Team. If you > actually feel there is a problem, please write it up concisely. I > have only seen vague arguments here (probably because I missed the > beginning of the thread), and couldn't make a judgement. I'm sure > others are in the same position. > > > I think you were quite right to, and I think you are right. > > But you are fighting the forces of reaction here, in my view. > > This whole thread has been a very depressing reflection on the > > inability of any of the people arguing against you to make > > any coherent argument against changing something to make sense. > > > > This is just conservative status-quoism gone mad. > > > > You are not alone in finding the current wording and behaviour > > of this feature inconsistent, and initially incoherent. > > > > Perhaps we are just too dumb. > > Or perhaps there has been no effective case made for a change. > In your opinion. The case has been made, clearly and coherently. In my opinion. Opinions are wonderful things. People hold onto them so dearly, and proclaim them so loudly :) It is clear that the current situation is a) satisfactory to the old-guard who don't want even the smallest detail changed and b)unsatisfactory to dumb newcomers who are asking that something makes sense (sense in the English Language). -- Regards Cliff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 7:11:37 2002 Delivered-To: freebsd-stable@freebsd.org Received: from femail1.sdc1.sfba.home.com (femail1.sdc1.sfba.home.com [24.0.95.81]) by hub.freebsd.org (Postfix) with ESMTP id 2740237B41B for ; Mon, 28 Jan 2002 07:11:33 -0800 (PST) Received: from ddrlestat ([68.57.88.80]) by femail1.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20020128151132.GQMF28203.femail1.sdc1.sfba.home.com@ddrlestat> for ; Mon, 28 Jan 2002 07:11:32 -0800 Message-ID: <001c01c1a80d$c92a5340$0a01a8c0@ddrlestat> From: "Kevin J. Anderson" To: Subject: Date: Mon, 28 Jan 2002 10:09:30 -0500 Organization: Counter-Map MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 7:17:20 2002 Delivered-To: freebsd-stable@freebsd.org Received: from ns.thinkburst.com (ns.thinkburst.com [204.214.64.66]) by hub.freebsd.org (Postfix) with ESMTP id 6B63937B429 for ; Mon, 28 Jan 2002 07:17:09 -0800 (PST) Received: from thinkburstmedia.com (gateway.thinkburstmedia.com [204.214.64.100]) by ns.thinkburst.com (Postfix) with ESMTP id 831059B0A for ; Mon, 28 Jan 2002 09:21:44 -0600 (CST) Received: by gateway.thinkburstmedia.com id <119042>; Mon, 28 Jan 2002 09:17:05 -0600 From: "Jaime Bozza" To: Subject: HPT372 (HighPoint) Driver Comparison Date: Mon, 28 Jan 2002 09:16:59 -0600 Message-Id: <02Jan28.091705cst.119042@gateway.thinkburstmedia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, While looking at all the IDE RAID options, searching through the list archives, and visiting assorted websites, I noticed that HighPoint has their own driver for the HPT372 (nothing for the 374 as of yet) chipset, which is used in the RocketRaid 133 controllers. This driver supports the controller/chipset under the daX SCSI devices. How is this driver different from the one built into Freebsd (ata device)? Has anyone tried using the Highpoint created one? (I believe it's available as a binary-only module for FreeBSD 4.3/4.4 as of now) Are they any comparisons yet between HPT controllers (with their driver) and the other IDE RAID options? Also, their driver set also seems to contain an X-based management utility. Jaime Bozza To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 7:56:36 2002 Delivered-To: freebsd-stable@freebsd.org Received: from lists.unixathome.org (lists.unixathome.org [210.48.103.158]) by hub.freebsd.org (Postfix) with ESMTP id B2E5537B400 for ; Mon, 28 Jan 2002 07:56:33 -0800 (PST) Received: from wocker (lists.unixathome.org [210.48.103.158]) by lists.unixathome.org (8.11.6/8.11.6) with ESMTP id g0SFuVD09391 for ; Tue, 29 Jan 2002 04:56:31 +1300 (NZDT) (envelope-from dan@lists.unixathome.org) Message-Id: <200201281556.g0SFuVD09391@lists.unixathome.org> From: "Dan Langille" Organization: DVL Software Limited To: freebsd-stable@freebsd.org Date: Mon, 28 Jan 2002 10:56:27 -0500 MIME-Version: 1.0 Subject: ipfstat -t not showing any connections Reply-To: dan@langille.org X-mailer: Pegasus Mail for Windows (v4.01) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I just tried the ipfstat -t option on my 4.5-RC2 gateway. ipnat -l | wc - l shows 61 entries, most of which are NAT, not the ipnat rules themselves. Is ipfstat broken? -- Dan Langille The FreeBSD Diary - http://freebsddiary.org/ - practical examples To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 8: 4:23 2002 Delivered-To: freebsd-stable@freebsd.org Received: from leviathan.inethouston.net (leviathan.inethouston.net [66.64.12.249]) by hub.freebsd.org (Postfix) with ESMTP id F16E637B41E for ; Mon, 28 Jan 2002 08:03:54 -0800 (PST) Received: by leviathan.inethouston.net (Postfix, from userid 1001) id CF97E319AFB; Mon, 28 Jan 2002 10:03:51 -0600 (CST) Date: Mon, 28 Jan 2002 10:03:51 -0600 From: "David W. Chapman Jr." To: Dan Langille Cc: freebsd-stable@freebsd.org Subject: Re: ipfstat -t not showing any connections Message-ID: <20020128160351.GA43864@leviathan.inethouston.net> Reply-To: "David W. Chapman Jr." Mail-Followup-To: Dan Langille , freebsd-stable@freebsd.org References: <200201281556.g0SFuVD09391@lists.unixathome.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200201281556.g0SFuVD09391@lists.unixathome.org> User-Agent: Mutt/1.3.27i X-Operating-System: FreeBSD 4.5-RC i386 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jan 28, 2002 at 10:56:27AM -0500, Dan Langille wrote: > I just tried the ipfstat -t option on my 4.5-RC2 gateway. ipnat -l | wc - > l shows 61 entries, most of which are NAT, not the ipnat rules themselves. > > Is ipfstat broken? ipfstat -t only shoes connections that its keeping track of via keepstate -- David W. Chapman Jr. dwcjr@inethouston.net Raintree Network Services, Inc. dwcjr@freebsd.org FreeBSD Committer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 8: 7:33 2002 Delivered-To: freebsd-stable@freebsd.org Received: from lists.unixathome.org (lists.unixathome.org [210.48.103.158]) by hub.freebsd.org (Postfix) with ESMTP id 7011237B41D for ; Mon, 28 Jan 2002 08:07:19 -0800 (PST) Received: from wocker (lists.unixathome.org [210.48.103.158]) by lists.unixathome.org (8.11.6/8.11.6) with ESMTP id g0SG78D09663; Tue, 29 Jan 2002 05:07:10 +1300 (NZDT) (envelope-from dan@lists.unixathome.org) Message-Id: <200201281607.g0SG78D09663@lists.unixathome.org> From: "Dan Langille" Organization: DVL Software Limited To: "David W. Chapman Jr." Date: Mon, 28 Jan 2002 11:07:03 -0500 MIME-Version: 1.0 Subject: Re: ipfstat -t not showing any connections Reply-To: dan@langille.org Cc: freebsd-stable@freebsd.org In-reply-to: <20020128160351.GA43864@leviathan.inethouston.net> References: <200201281556.g0SFuVD09391@lists.unixathome.org> X-mailer: Pegasus Mail for Windows (v4.01) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 28 Jan 2002 at 10:03, David W. Chapman Jr. wrote: > On Mon, Jan 28, 2002 at 10:56:27AM -0500, Dan Langille wrote: > > I just tried the ipfstat -t option on my 4.5-RC2 gateway. ipnat -l | wc > > - l shows 61 entries, most of which are NAT, not the ipnat rules > > themselves. > > > > Is ipfstat broken? > > ipfstat -t only shoes connections that its keeping track of via > keepstate That is consistent with what I am seeing. Thanks. -- Dan Langille The FreeBSD Diary - http://freebsddiary.org/ - practical examples To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 8:16:58 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mail7.nc.rr.com (fe7.southeast.rr.com [24.93.67.54]) by hub.freebsd.org (Postfix) with ESMTP id 44D2A37B400 for ; Mon, 28 Jan 2002 08:16:55 -0800 (PST) Received: from i8k.babbleon.org ([66.57.85.154]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Mon, 28 Jan 2002 10:14:29 -0500 Received: by i8k.babbleon.org (Postfix, from userid 111) id 92F0A4032; Mon, 28 Jan 2002 10:12:20 -0500 (EST) Content-Type: text/plain; charset="iso-8859-1" From: Brian T.Schellenberger To: Cliff Sarginson , stable@FreeBSD.ORG Subject: Re: Firewall config non-intuitiveness Date: Mon, 28 Jan 2002 10:12:20 -0500 X-Mailer: KMail [version 1.3] References: <20020127220923.B1494@shell.gsinet.sittig.org> <20020128135643.GH33952@madman.nectar.cc> <20020128145517.GB1907@raggedclown.net> In-Reply-To: <20020128145517.GB1907@raggedclown.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020128151220.92F0A4032@i8k.babbleon.org> Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Monday 28 January 2002 09:55 am, Cliff Sarginson wrote: > On Mon, Jan 28, 2002 at 07:56:43AM -0600, Jacques A. Vidrine wrote: > > > Perhaps we are just too dumb. > > > > Or perhaps there has been no effective case made for a change. > > In your opinion. I think there's more than an opinion at work here because . . . > The case has been made, clearly and coherently. But by definition not effectively if the change isn't actually going to be made. > In my opinion. > Opinions are wonderful things. > People hold onto them so dearly, and proclaim them so loudly :) > It is clear that the current situation is a) satisfactory to the > old-guard who don't want even the smallest detail changed and > b)unsatisfactory to dumb newcomers who are asking that something > makes sense (sense in the English Language). Speaking as a sort of "nuetral bystander" who found the old way quirky but understandable, I'd say that the new proposal *would* be more logical, but at the same time it is always good to be careful about changing the definiation of something within a minor release. So why not put together a simple proposal with a justification and submit it to, say, the security list or perhaps even the hackers list as a proposal for FreeBSD 5.0? And for 4.x some documentation clarification is surely in order. (Though I must admit I found the current documentation adaquate for myself--the big note in the kernel config file conveyed the situation to me sufficiently.) Perhaps a note in /etc/defeaults/rc.conf or something? -- Brian T. Schellenberger . . . . . . . bts@wnt.sas.com (work) Brian, the man from Babble-On . . . . bts@babbleon.org (personal) http://www.babbleon.org -------> Free Dmitry Sklyarov! (let him go home) <----------- http://www.eff.org http://www.programming-freedom.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 8:44:12 2002 Delivered-To: freebsd-stable@freebsd.org Received: from cobble.capnet.state.tx.us (cobble.capnet.state.tx.us [141.198.179.13]) by hub.freebsd.org (Postfix) with ESMTP id 7C92137B772 for ; Mon, 28 Jan 2002 08:43:22 -0800 (PST) Received: from localhost (fbsdstable@localhost) by cobble.capnet.state.tx.us (8.11.6/8.11.6) with ESMTP id g0SGjEW90267; Mon, 28 Jan 2002 10:45:16 -0600 (CST) (envelope-from fbsdstable@cobble.capnet.state.tx.us) Date: Mon, 28 Jan 2002 10:45:14 -0600 (CST) From: FreeBSD Stable To: Nevermind Cc: Subject: Setting Geometry on big drives (Was Re: FreeBSD install doesn't see the whole disk) In-Reply-To: <20020128082710.GD41742@nevermind.kiev.ua> Message-ID: <20020128093203.D90198-100000@cobble.capnet.state.tx.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 28 Jan 2002, Nevermind wrote: > > I just put a new 30GB drive in my test machine (Maxtor IDE). When I > > tried to install, fdisk didn't get the drive size right. So I used the > > 'G' option and set the drive geometry manually. The summary at the top > > of the screen looked correct after that, but the 'C' create option > > apparently didn't get updated, and wouldn't let me create more than a > > 2GB partition. > > Anyone have ideas? > Try to set exact geometry for this drive manually, not autodetect in > bios. > Do you have 53073H4 model? > If so, then set in your BIOS settings manually: > 59554 cyl, 16 heads, 63 sectors. > For reference see: > http://www.maxtor.com/products/DiamondMax/DiamondMaxPlus/QuickSpecs/42077.pdf > I had the same problems with my > ad0: 14655MB [29777/16/63] at ata0-master UDMA100 I have an IBM Deskstar 60GB that the BIOS reports as 29437/16/255. The startup probe reports 119150/16/63. When I try to configure the drive, I get a message saying 119150/16/63 is incorrect, and that I need to set it to the BIOS numbers. If I set it to the BIOS numbers, it still complains that it is incorrect. There is a message in there warning me not to set the drive to its physical geometry, though the BIOS 29437/16/255 seems a likely physical geometry. So the partition editor picks another default, which is 7476/255/63. Which seems to work, but now I have three different numbers. The boot still shows 119150/16/63, the BIOS still shows 29437/16/255, and the disklabel shows 7476/255/63. Question: Why the warning about not using the PHYSICAL GEOMETRY, especially since the BIOS (on a Tyan K7 MB) reports a proper physical geometry? Why is the boot message still reporting 119150/16/63, when that isn't set anywhere??? stu fbsdstable@cobble.capnet.state.tx.us To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 8:47:31 2002 Delivered-To: freebsd-stable@freebsd.org Received: from smtpproxy2.mitre.org (smtpproxy2.mitre.org [128.29.154.90]) by hub.freebsd.org (Postfix) with ESMTP id 94F7537B404 for ; Mon, 28 Jan 2002 08:47:24 -0800 (PST) Received: from avsrv2.mitre.org (avsrv2.mitre.org [128.29.154.4]) by smtpproxy2.mitre.org (8.11.3/8.11.3) with ESMTP id g0SGktc14399; Mon, 28 Jan 2002 11:46:55 -0500 (EST) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv2.mitre.org (8.11.3/8.11.3) with ESMTP id g0SGkri18276; Mon, 28 Jan 2002 11:46:53 -0500 (EST) Received: from dhcp-105-164.mitre.org (128.29.105.164) by mailhub1.mitre.org with SMTP id 8984709; Mon, 28 Jan 2002 11:46:17 -0500 Message-ID: <3C55807B.2CD7BC69@mitre.org> Date: Mon, 28 Jan 2002 11:46:51 -0500 From: Jason Andresen Organization: The MITRE Corporation X-Mailer: Mozilla 4.75 [en]C-20000818M (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Attila Nagy Cc: freebsd-stable@freebsd.org Subject: Re: Multiple Promise controllers References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Attila Nagy wrote: > > Hello, > > > This brings me to my final option: has anybody managed to mix IDE > > controller cards successfully? What cards are good for this? > Quoting Soren Schmidt: > > Q: "Is it possible to use multiple Promise ATA-100 cards in one machine? > If yes, how much?" > A: "Yes, you should be able to use as many as you have PCI slots for. > I have made systems with 3 promises with no problems." With DMA though? :) FreeBSD is happy to run the card, in PIO mode... > And: "Well, I would buy HPT370 based cards, like the Abit hotrod100, the > HPT370 chip is a far better design than the promise, and gives better > performance." > > So I think it is possible to use more than two Promise ATA cards, but the > HPT 37x is the preferred way, by the ATA-driver author. Thanks! That's exactly the info I was looking for. Where did you find this FAQ by the way? I never found anything even remotely like it when searching through google. I'm sure it's someplace obvious. :) -- \ |_ _|__ __|_ \ __| Jason Andresen jandrese@mitre.org |\/ | | | / _| Network and Distributed Systems Engineer _| _|___| _| _|_\___| Office: 703-883-7755 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 8:56:37 2002 Delivered-To: freebsd-stable@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 6FC0A37B417 for ; Mon, 28 Jan 2002 08:56:29 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g0SGuSo18115; Mon, 28 Jan 2002 09:56:28 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g0SGuRx10577; Mon, 28 Jan 2002 09:56:27 -0700 (MST) (envelope-from imp@village.org) Date: Mon, 28 Jan 2002 09:55:03 -0700 (MST) Message-Id: <20020128.095503.08646553.imp@village.org> To: cliff@raggedclown.net Cc: stable@FreeBSD.ORG Subject: Re: Firewall config non-intuitiveness From: "M. Warner Losh" In-Reply-To: <20020128145517.GB1907@raggedclown.net> References: <20020128064925.GA1180@raggedclown.net> <20020128135643.GH33952@madman.nectar.cc> <20020128145517.GB1907@raggedclown.net> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20020128145517.GB1907@raggedclown.net> Cliff Sarginson writes: : > Or perhaps there has been no effective case made for a change. : > : In your opinion. : The case has been made, clearly and coherently. : In my opinion. : Opinions are wonderful things. : People hold onto them so dearly, and proclaim them so loudly :) : It is clear that the current situation is a) satisfactory to the : old-guard who don't want even the smallest detail changed and : b)unsatisfactory to dumb newcomers who are asking that something : makes sense (sense in the English Language). You'll notice that nectar (who is my boss on the security-officer@ list) said he missed the original, exact description of the change. Maybe you could restate it for him, plus the justification. I know that you are getting frustrated with this, but he's the right person to talk to. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 9:13:10 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id EE9F937B400 for ; Mon, 28 Jan 2002 09:13:04 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id g0SHD0r52828; Mon, 28 Jan 2002 12:13:00 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20020127165021.6152b03a.ptiJo@noos.fr> References: <20020127165021.6152b03a.ptiJo@noos.fr> Date: Mon, 28 Jan 2002 12:12:58 -0500 To: ptiJo From: Garance A Drosihn Subject: Re: Possible bug in 4.5-RC1 vs VMware (linux emulation?) Cc: stable@freebsd.org, marcel@xcllnt.net, des@ofug.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >Garance A Drosihn wrote: > > > I upgraded to 4.5-RC1 as it was on Wednesday (Jan 9th) at about 7pm. >> I then upgraded most (but not quite all) of my ports. On Thursday >> I needed to run VMware2 to debug some obscure problem I am seeing >> elsewhere (something not related to freebsd at all). >> >> The possible-bug part is that I get an error message when starting >> up vmware, saying "VMware was unable to read from /dev/acd0c. This >> can be caused by a Linux kernel bug...". It is saying "Linux kernel" >> because this is the Linux version of VMware2, which I am running via >> Linux emulation on freebsd. So, it thinks the host OS is linux. In > > any case, I wasn't getting this error until after those upgrades. Sigh. Well, sometime after I wrote the above message, I wrote another saying that I had upgraded and the problem was gone. I had even *read* cd's under two different virtual-system OS's without any trouble. So, I assumed that it had been fixed sometime after 4.5-RC2, but now the warning is back -- and I am not sure what I did to change things... So, I probably have to pin this down some more before claiming it is really solved. It is not much of a problem for my use, but it's just a little annoying (particularly since I don't know why it comes and goes). -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 9:19:54 2002 Delivered-To: freebsd-stable@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id EE6B237B400 for ; Mon, 28 Jan 2002 09:19:48 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id KAA27233; Mon, 28 Jan 2002 10:19:47 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0SHJkG63907; Mon, 28 Jan 2002 10:19:46 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15445.34866.827021.644844@caddis.yogotech.com> Date: Mon, 28 Jan 2002 10:19:46 -0700 To: Justin White Cc: freebsd-stable@FreeBSD.ORG Subject: re: firewall config (CTFM) In-Reply-To: <12A141AE-13BD-11D6-876A-000393092F82@mac.com> References: <12A141AE-13BD-11D6-876A-000393092F82@mac.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > i'm not trying to be mean, but if you don't read the docs A comment in a configuration file that the user should never have to see is considered documentation? *sheesh* Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 9:52:22 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mail.27in.tv (roc-66-24-112-7.rochester.rr.com [66.24.112.7]) by hub.freebsd.org (Postfix) with ESMTP id 4C07C37B402 for ; Mon, 28 Jan 2002 09:52:16 -0800 (PST) Received: (from root@localhost) by mail.27in.tv (8.11.6/8.11.6) id g0SHqDU72576; Mon, 28 Jan 2002 12:52:13 -0500 (EST) (envelope-from cjm2@earthling.net) Received: from 27in.tv (roc-66-24-112-7.rochester.rr.com [66.24.112.7]) by mail.27in.tv (8.11.6/8.11.6av) with SMTP id g0SHqBU72567; Mon, 28 Jan 2002 12:52:11 -0500 (EST) (envelope-from cjm2@earthling.net) Received: from 216.153.202.59 (SquirrelMail authenticated user cjm2) by www1.27in.tv with HTTP; Mon, 28 Jan 2002 12:52:12 -0500 (EST) Message-ID: <1617.216.153.202.59.1012240332.squirrel@www1.27in.tv> Date: Mon, 28 Jan 2002 12:52:12 -0500 (EST) Subject: Re: Firewall config non-intuitiveness From: "C J Michaels" To: In-Reply-To: <200201271757.g0RHvTF12944@midway.uchicago.edu> References: <200201271757.g0RHvTF12944@midway.uchicago.edu> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal Cc: , , X-Mailer: SquirrelMail (version 1.2.5 [cvs]) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by AMaViS perl-11 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David Syphers said: > On Sunday 27 January 2002 11:27 am, M. Warner Losh wrote: >> Right now what I have works. You are changing the semantics of a >> security related feature of the system in such a way that after this >> change what I have will not work. I agree that your work around will >> allow me to easily correct things. However, if I fail to do so, I >> open my firewall up completely. To me, that's an unacceptible change >> in the API. > > You yourself said that you're doing things that "don't fit in well with > the current firewall paradigm." So they're hacks, and you shouldn't > expect them to work indefinitely. For every person like you, there > are probably ten like me, who in a state of ignorant bliss rebooted a > machine they were remotely admining with firewall_enable set to NO. > Imagine the surprise when I was completely locked out. As others have > pointed out this behavior is documented, but we must remember that a > variable name itself is the most important and immediate > documentation. And having a firewall load when firewall_enable is NO > is complete nonsense. Warner, Should not Everyone who tracks -STABLE be reading /usr/src/UPDATING?? _Especially_ those who have non-standard (hacked) configurations such as yours! I'd be quite disappointed if you didn't read your own work. :) That being said, I've been 'caught with my pants down' by not reading that file before... and that was no one's fault but my own. I can see this issue from both sides. One of the best things about FreeBSD is the fact that with the right knowledge you can do and change almost anything you want. Does that mean that your unusual configuration should be considered when changes are made to the OS? Yes. Does it mean that changes shouldn't happen? No. That's the point of the HEADS-UP messages on this list, and /usr/src/UPDATING. Both of which _everyone_ who tracks - STABLE should be following. Personally, I think the way things are now is highly non-intuitive. Having firewall_enable="NO" disable the firewall would make sense to someone who does not yet have alot of knowledge about that portion of the system. And quite frankly, to myself. I also agree 100% that, if someone adds IPFIREWALL to their kernel config (or anything for that matter) they should be aware of the consequences of that action. On the other hand, there are quite a number of how-to documents, that tell people to do exactly that to configure a firewall on FreeBSD. > > This change would affect security only for the people who are > knowledgeable enough to understand this weird variable in the first > place. This effect would be minimal. A default desktop install of > FreeBSD will enable Sendmail and inetd and have no firewall, and > you're worried about this security effect? He's worried about the security effect because it would take a working (assumed) secure machine, and make it insecure. Securing a FreeBSD system out of the box, because the user is too lazy to figure out how to do it on their own, is hand holding (let's not argue that out, in this thread please). Going through the trouble of locking it down afterward, and having the firewall spontaneously disappear is flat out breakage. So, on that note, I think we should not be making this change to -STABLE (at least, not yet). I do think this should be implemented in -CURRENT and later inclusion into the base system. And if/and when this change is implemented in -STABLE, a notice to FreeBSD-Security- Advisories@FreeeBSD.org would be a VERY good idea. Status-quo is not always good for business. > > -David > Center for Cosmological Physics > The University of Chicago -- Chris "I'll defend to the death your right to say that, but I never said I'd listen to it!" -- Tom Galloway with apologies to Voltaire To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 9:53:59 2002 Delivered-To: freebsd-stable@freebsd.org Received: from ns2.robhughes.com (12-237-138-77.client.attbi.com [12.237.138.77]) by hub.freebsd.org (Postfix) with SMTP id 413B737B402 for ; Mon, 28 Jan 2002 09:53:52 -0800 (PST) Received: (qmail 10133 invoked from network); 28 Jan 2002 17:53:19 -0000 Received: from hexch01.robhughes.com (192.168.1.3) by ns2.robhughes.com with SMTP; 28 Jan 2002 17:53:19 -0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: firewall config (CTFM) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 28 Jan 2002 11:53:50 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: firewall config (CTFM) Thread-Index: AcGoIA7b03RxyeA0R1OuQBlKmED3qwAAzJLg From: "Robert D. Hughes" To: "Nate Williams" , "Justin White" Cc: Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG While this will probably get me flamed to no end, users not reading the docs and keeping up with advisories (sys admins are users too) is only the cause of little things like nimda, code red, and probably at least 90% of all the other problems people report with any system. If you've read them, and at least tried to follow them and it still doesn't work, I have great sympathy and want to help. I never answer a question on a list that I know I can look at a manual and find the answer to in under a half-hour. Most questions I see posted can be easily solved by 15-30 minutes of reading though. Heck, I've made my entire career on the fact that I'm willing to do a bit of research when everyone else throws up their hands and says "it don't work". Just my .02, Rob -----Original Message----- From: Nate Williams [mailto:nate@yogotech.com] Sent: Monday, January 28, 2002 11:20 AM To: Justin White Cc: freebsd-stable@FreeBSD.ORG Subject: re: firewall config (CTFM) > i'm not trying to be mean, but if you don't read the docs A comment in a configuration file that the user should never have to see is considered documentation? *sheesh* Nate 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 From owner-freebsd-stable Mon Jan 28 9:56:18 2002 Delivered-To: freebsd-stable@freebsd.org Received: from www.lambertfam.org (eqbsd.lambertfam.org [209.142.170.25]) by hub.freebsd.org (Postfix) with ESMTP id A220D37B404 for ; Mon, 28 Jan 2002 09:56:14 -0800 (PST) Received: from laptop.lambertfam.org (r-201.162.alltel.net [166.102.201.162]) by www.lambertfam.org (Postfix) with ESMTP id 426A064C1C for ; Mon, 28 Jan 2002 11:56:12 -0600 (CST) Received: by laptop.lambertfam.org (Postfix, from userid 1000) id 4A73D28B0E; Mon, 28 Jan 2002 12:55:40 -0500 (EST) Date: Mon, 28 Jan 2002 12:55:40 -0500 From: Scott Lambert To: stable@freebsd.org Subject: Re: Firewall config non-intuitiveness Message-ID: <20020128175540.GB82240@laptop.lambertfam.org> Mail-Followup-To: stable@freebsd.org References: <200201271757.g0RHvTF12944@midway.uchicago.edu> <1617.216.153.202.59.1012240332.squirrel@www1.27in.tv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1617.216.153.202.59.1012240332.squirrel@www1.27in.tv> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I want the bikeshed to be green. It will blend with the grass that way and create less visual impact. -- Scott Lambert KC5MLE Unix SysAdmin -- Looking for work. lambert@lambertfam.org http://www.lambertfam.org/~lambert/resume.html 2.5 years Sr. SysAdmin experience with FreeBSD in small & medium size ISPs. The last 5 months have included exposure to Solaris 7, True64 5, and Linux. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 9:59:35 2002 Delivered-To: freebsd-stable@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id D683337B417 for ; Mon, 28 Jan 2002 09:59:10 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id KAA28782; Mon, 28 Jan 2002 10:58:47 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0SHwjW68309; Mon, 28 Jan 2002 10:58:45 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15445.37204.693732.376471@caddis.yogotech.com> Date: Mon, 28 Jan 2002 10:58:44 -0700 To: "Robert D. Hughes" Cc: "Nate Williams" , "Justin White" , Subject: RE: firewall config (CTFM) In-Reply-To: References: X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > While this will probably get me flamed to no end, users not reading the > docs and keeping up with advisories (sys admins are users too) is only > the cause of little things like nimda, code red, and probably at least > 90% of all the other problems people report with any system. Again, a comment in a unused file cannot properly be called documentation. And, when the comment is misleading, it's even worse. :( > If you've read them, and at least tried to follow them and it still > doesn't work, I have great sympathy and want to help. I never answer a > question on a list that I know I can look at a manual and find the > answer to in under a half-hour. *Bwah* *hah* *hah* *hah* *hah* *hah* Yeah, right. I've been involved with this project *longer* than anyone (including Jordan), although I haven't been as involved with it as of late. However, I read *all* the mailing lists (except questions), which I've done for almost 9 years now. I've hacked on the kernel, hacked on userland, including parts of ipfw that currently exist. *I* consider the current behavior non-intuitive. Also, even *I* can't find answers to my questions with 30 minutes, and I know where to look, so I find you statement, well, to be brutally honest, both humerous and a little bit egotistical. : My .25 worth.... Nate > -----Original Message----- > From: Nate Williams [mailto:nate@yogotech.com] > Sent: Monday, January 28, 2002 11:20 AM > To: Justin White > Cc: freebsd-stable@FreeBSD.ORG > Subject: re: firewall config (CTFM) > > > > i'm not trying to be mean, but if you don't read the docs > > A comment in a configuration file that the user should never have to see > is considered documentation? > > *sheesh* > > > Nate > > 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 From owner-freebsd-stable Mon Jan 28 10: 9:29 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mail.27in.tv (roc-66-24-112-7.rochester.rr.com [66.24.112.7]) by hub.freebsd.org (Postfix) with ESMTP id 1105F37B404 for ; Mon, 28 Jan 2002 10:09:23 -0800 (PST) Received: (from root@localhost) by mail.27in.tv (8.11.6/8.11.6) id g0SI9L673127; Mon, 28 Jan 2002 13:09:21 -0500 (EST) (envelope-from cjm2@earthling.net) Received: from 27in.tv (roc-66-24-112-7.rochester.rr.com [66.24.112.7]) by mail.27in.tv (8.11.6/8.11.6av) with SMTP id g0SI9IU73118; Mon, 28 Jan 2002 13:09:19 -0500 (EST) (envelope-from cjm2@earthling.net) Received: from 216.153.202.59 (SquirrelMail authenticated user cjm2) by www1.27in.tv with HTTP; Mon, 28 Jan 2002 13:09:19 -0500 (EST) Message-ID: <1681.216.153.202.59.1012241359.squirrel@www1.27in.tv> Date: Mon, 28 Jan 2002 13:09:19 -0500 (EST) Subject: Re: Firewall config non-intuitiveness From: "C J Michaels" To: In-Reply-To: <20020127220935.C1494@shell.gsinet.sittig.org> References: <20020127220935.C1494@shell.gsinet.sittig.org> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal Cc: X-Mailer: SquirrelMail (version 1.2.5 [cvs]) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by AMaViS perl-11 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Gerhard Sittig said: > On Sun, Jan 27, 2002 at 11:57 -0600, David Syphers wrote: >> >> [ ... surprise ... ] As others have pointed out this behavior is >> documented, but we must remember that a variable name itself is the >> most important and immediate documentation. And having a firewall >> load when firewall_enable is NO is complete nonsense. > > So maybe the variables should be named a little longer to fully > describe their effect? Like > firewall_ruleset_script_run_enable_when_set_to_yes? I'm sorry > if I sound a little ironic, but when one is to administer a UNIX Sarcastic, but I understand your point. But anyway... this mentality of just because it's UNIX means it should be significantly more difficult to administer is getting old. Yes people should read the docs, yes people should be held responsible for their actions. And YES, the original poster is entirely, 100% at fault for his mistake. But, by making said mistake, he found something that he felt would use a little work for the betterment of all. No, I don't want FreeBSD to be a user-friendly induced mess that other OS's are... but there are minor compromises we could make in name of ease of use and better understanding. Intuitive variable names in rc.conf(5) is one of them. Which MOST of them are. Obviously one person started this whole mess, and maybe he is in the very small minority, but there's wouldn't be such a hubub if no one cared about one way or the other. I think (at the very least) a compromise that serves both ends would be appropriate. > system one should have learned to use the available docs when in > doubt. Otherwise we end up with variable names not fitting on 80 > column lines while their accompanying comments occupy the next > ten lines. This would mean mirroring the manpage in the script > once more and is not really the way things usually work. > > > 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. -- Chris "I'll defend to the death your right to say that, but I never said I'd listen to it!" -- Tom Galloway with apologies to Voltaire To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 10:14:24 2002 Delivered-To: freebsd-stable@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id D6A1F37B416 for ; Mon, 28 Jan 2002 10:14:20 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id LAA29408; Mon, 28 Jan 2002 11:14:19 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0SIEJP68406; Mon, 28 Jan 2002 11:14:19 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15445.38139.56874.444902@caddis.yogotech.com> Date: Mon, 28 Jan 2002 11:14:19 -0700 To: Justin White Cc: nate@yogotech.com (Nate Williams), freebsd-stable@FreeBSD.ORG Subject: Re: firewall config (CTFM) In-Reply-To: <6085443A-141A-11D6-AD14-000393092F82@mac.com> References: <15445.34866.827021.644844@caddis.yogotech.com> <6085443A-141A-11D6-AD14-000393092F82@mac.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > >> i'm not trying to be mean, but if you don't read the docs > > > > A comment in a configuration file that the user should never have to see > > is considered documentation? > > no, the user _should_ making a point to see that configuration file. if > they're changing /etc/rc.conf, they should be reading the corresponding > defaults file. if they're changing /etc/rc.conf without previously > reading the defaults file, too bad. > > by your logic, when someone configures a new kernel, they shouldn't need > to look at LINT? I doubt most users look at LINT for building their kernels. I rarely do, since it rarely contains information *I* need for my kernels. Only when I add them to my local workstation do I look (for things like sound drivers and such), and more often than not, I need to check the archives or ask a local question since I'm not sure *what* configuration is right for my box. So, in answer to your question, I don't consider /etc/defaults/rc.conf proper documentation, nor do I consider LINT proper documenation. It's better than nothing, but it's not adequate for many tasks. (And, as stated before, what 'documentation' exists for the variable is poorly worded, so the documentation we have currently is not only inadequate, it's bad.) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 10:24: 9 2002 Delivered-To: freebsd-stable@freebsd.org Received: from jeff.ath.cx (d141-99-70.home.cgocable.net [24.141.99.70]) by hub.freebsd.org (Postfix) with ESMTP id B614537B400 for ; Mon, 28 Jan 2002 10:24:04 -0800 (PST) Received: by jeff.ath.cx (Postfix, from userid 1000) id D9BB372510; Mon, 28 Jan 2002 13:16:08 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by jeff.ath.cx (Postfix) with ESMTP id 94E7E6A907 for ; Mon, 28 Jan 2002 13:16:08 -0500 (EST) Date: Mon, 28 Jan 2002 13:16:08 -0500 (EST) From: All Mail To: freebsd-stable@FreeBSD.org Subject: SUBSCRIBE Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 10:38:26 2002 Delivered-To: freebsd-stable@freebsd.org Received: from scribble.fsn.hu (scribble.fsn.hu [193.224.40.95]) by hub.freebsd.org (Postfix) with SMTP id 0501037B402 for ; Mon, 28 Jan 2002 10:38:24 -0800 (PST) Received: (qmail 14624 invoked by uid 1000); 28 Jan 2002 18:38:23 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 28 Jan 2002 18:38:23 -0000 Date: Mon, 28 Jan 2002 19:38:23 +0100 (CET) From: Attila Nagy To: Jason Andresen Cc: freebsd-stable@freebsd.org Subject: Re: Multiple Promise controllers In-Reply-To: <3C55807B.2CD7BC69@mitre.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, > With DMA though? :) FreeBSD is happy to run the card, in PIO mode... Erm, I don't know :) But PIO mode isn't that good, that's right... > Thanks! That's exactly the info I was looking for. Where did you find > this FAQ by the way? In /var/mail/bra :) I wrote Soren and he was very-very kind and replied all of my questions (the main question was that is it possible to use more than one Promise cards in one system). -------------------------------------------------------------------------- Attila Nagy e-mail: Attila.Nagy@fsn.hu Budapest Polytechnic (BMF.HU) @work: +361 210 1415 (194) H-1084 Budapest, Tavaszmezo u. 15-17. cell.: +3630 306 6758 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 10:48:17 2002 Delivered-To: freebsd-stable@freebsd.org Received: from reypastor.hispalinux.es (host10390-1830.eunet.es [193.127.103.90]) by hub.freebsd.org (Postfix) with ESMTP id D686E37B400; Mon, 28 Jan 2002 10:48:11 -0800 (PST) Received: by reypastor.hispalinux.es (Postfix, from userid 1019) id D7DD35B7DD; Mon, 28 Jan 2002 19:48:09 +0100 (CET) Date: Mon, 28 Jan 2002 19:48:09 +0100 From: Jesus Climent To: freebsd-stable@freebsd.org Cc: freebsd-ports@freebsd.org Subject: xf86cfg segfaults in 4.5-RC3 Message-ID: <20020128184809.GA20635@reypastor.hispalinux.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Port: XFree86 4.1 (under 4.5-RC3) Problem: xf86cfg segfaults. System: Fujitsu x365. Integrated ATI Rage Pro. Description: After installing the system I installed the port XFree86: XFree86-4.1.0_12,1 X11R6.5/XFree86 core distribution (complete) XFree86-Server-4.1.0_4 XFree86-4 X server and related programs XFree86-clients-4.1.0_2 XFree86-4 Client environments XFree86-font100dpi-4.1.0 XFree86-4 bitmap 100 dpi fonts XFree86-fontEncodings-4.1.0 XFree86-4 font encoding files XFree86-fontScalable-4.1.0 XFree86-4 Scalable font files XFree86-libraries-4.1.0_1 XFree86-4 include/(shared) library kit Trying to configure it with xf86cfg opens the XWindow system, starts the application and after few seconds it suddenly crashes, without moving anything. Checked also in another computer with the same result. J. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 10:53:20 2002 Delivered-To: freebsd-stable@freebsd.org Received: from petra.vif.com (ip216-239-64-165.vif.net [216.239.64.165]) by hub.freebsd.org (Postfix) with ESMTP id 09E7637B404 for ; Mon, 28 Jan 2002 10:53:15 -0800 (PST) Received: (from squid@localhost) by petra.vif.com (8.11.6/8.11.6) id g0SIrEo07315 for stable@FreeBSD.ORG; Mon, 28 Jan 2002 13:53:14 -0500 (EST) (envelope-from talist@vif.com) X-Authentication-Warning: petra.vif.com: squid set sender to talist@vif.com using -f Received: from 216.239.71.137 ( [216.239.71.137]) as user talist@mail.vif.com by email.vif.com with HTTP; Mon, 28 Jan 2002 13:53:14 -0500 Message-ID: <1012243994.3c559e1a0e0d5@email.vif.com> Date: Mon, 28 Jan 2002 13:53:14 -0500 From: talist@vif.com To: stable@FreeBSD.ORG Subject: Crashing Freebsd + Dummynet + heavy traffic MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I am using a freebsd box as a gateway in order to throttle down bandwidth for some particular traffic. The box freezes under high load and the only way to recover is through a power cycle. The crash does not generate any logs, but I have ruled out hardware causes. I can repeat the lock-out with 2 different hardware and with xl(4) and dc(4) NIC's I am suspecting a problem with DUMMYNET's PIPE and QUEUE. I have collected all the config information about the machine with a small script that helps in crashing the box after a few minutes of alternating the dummynet pipe's size. http://www.geocities.com/dummynetus/ipfw.txt In summary, I have tried the following: - Boost maxusers to 128 - Boost NMBCLUSTERS to 10240 - monitor netstat -m gives normal readings even before freeze To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 11:29:50 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by hub.freebsd.org (Postfix) with ESMTP id C4CC337B404 for ; Mon, 28 Jan 2002 11:29:36 -0800 (PST) Received: from d1o913.telia.com (d1o913.telia.com [195.252.44.241]) by mailg.telia.com (8.11.6/8.11.6) with ESMTP id g0SJTZn26478 for ; Mon, 28 Jan 2002 20:29:35 +0100 (CET) Received: from falcon.midgard.homeip.net (h185n2fls20o913.telia.com [212.181.163.185]) by d1o913.telia.com (8.8.8/8.8.8) with SMTP id UAA00175 for ; Mon, 28 Jan 2002 20:29:34 +0100 (CET) Received: (qmail 86777 invoked by uid 1001); 28 Jan 2002 19:29:31 -0000 Date: Mon, 28 Jan 2002 20:29:31 +0100 From: Erik Trulsson To: C J Michaels Cc: charon@seektruth.org, dsyphers@uchicago.edu, imp@village.org, stable@freebsd.org Subject: Re: Firewall config non-intuitiveness Message-ID: <20020128192930.GA86720@student.uu.se> Mail-Followup-To: C J Michaels , charon@seektruth.org, dsyphers@uchicago.edu, imp@village.org, stable@freebsd.org References: <200201271757.g0RHvTF12944@midway.uchicago.edu> <1617.216.153.202.59.1012240332.squirrel@www1.27in.tv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1617.216.153.202.59.1012240332.squirrel@www1.27in.tv> User-Agent: Mutt/1.3.25i Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jan 28, 2002 at 12:52:12PM -0500, C J Michaels wrote: > > Personally, I think the way things are now is highly non-intuitive. Having > firewall_enable="NO" disable the firewall would make sense to someone who > does not yet have alot of knowledge about that portion of the system. And > quite frankly, to myself. > > I also agree 100% that, if someone adds IPFIREWALL to their kernel config > (or anything for that matter) they should be aware of the consequences of > that action. On the other hand, there are quite a number of how-to > documents, that tell people to do exactly that to configure a firewall on > FreeBSD. Note that "do not enable firewall" (which is implied by firewall_enable="NO") is *not* equivalent to "disable firewall". So, no, I don't think it is obvious that firewall_enable="NO" should disable the firewall if it already was enabled by adding IPFIREWALL to the kernel config. (Nor is it obvious that it will not be disabled.) As other people have noted before firewall_enable really should be a tri-state variable with the possible values: "YES" -- enable firewall "NO" -- do not enable firewall "DISABLE" -- disable firewall (The values might instead be "ENABLE", "USE_DEFAULT" and "DISABLE" which might be more intuitive.) (The last possible function, "invert state of firewall", is not very useful IMO.) For a reason why having firewall_enable="NO" disable the firewall can be ha bad idea consider the following scenario: Assume a machine with IPFIREWALL set in the kernel config and with firewall_enable="YES" in /etc/rc.conf. Now imagine that the admin screws up when upgrading the machine or changing the configuration and accidentally removes the firewall_enable="YES" line from /etc/rc.conf. When rebooting the machine, since firewall_enable is not set in /etc/rc.conf, the default value of that variable would be used which is "NO". With the current behaviour what would happen then is that the firewall would default to "deny all". This would probably be noticed very quickly since no packets will get through the firewall. Annoying (for a remote machine possibly very annoying and troublesome) but not a security problem. With the proposed change (disabling the firewall if firewall_enable="NO") what would happen is that the firewall machine would be wide open. This might not be noticed for some time and is definitely a security problem. So, while I agree the the current situation might not be quite as intuitive as it might be changing the behaviour of firewall_enable="NO" to actually disabling the firewall is, IMO, *not* the right way to fix this. (If the admin went to the trouble of adding IPFIREWALL to the kernel, the default behaviour should be to not disable it.) -- Erik Trulsson ertr1013@student.uu.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 11:44:41 2002 Delivered-To: freebsd-stable@freebsd.org Received: from wow.atlasta.net (wow.atlasta.net [128.241.97.71]) by hub.freebsd.org (Postfix) with ESMTP id 5B1C337B400 for ; Mon, 28 Jan 2002 11:44:39 -0800 (PST) Received: from localhost (drais@localhost) by wow.atlasta.net (8.11.2/8.11.2) with ESMTP id g0SJiPW28519; Mon, 28 Jan 2002 11:44:25 -0800 (PST) Date: Mon, 28 Jan 2002 11:44:25 -0800 (PST) From: David Raistrick To: Nate Williams Cc: Justin White , freebsd-stable@FreeBSD.ORG Subject: Re: firewall config (CTFM) In-Reply-To: <15445.38139.56874.444902@caddis.yogotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > no, the user _should_ making a point to see that configuration file. if > > they're changing /etc/rc.conf, they should be reading the corresponding > > defaults file. if they're changing /etc/rc.conf without previously > > reading the defaults file, too bad. I have to definitely disagree here. The place to read would be man rc.conf, would it not? I obviously missed the first part of this...is the specific variable in question covered in the rc.conf man page? ....david --- david raistrick (no longer deep in the south georgia woods) drais@atlasta.net http://www.expita.com/nomime.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 11:51:53 2002 Delivered-To: freebsd-stable@freebsd.org Received: from rockstar.stealthgeeks.net (h-66-134-120-173.LSANCA54.covad.net [66.134.120.173]) by hub.freebsd.org (Postfix) with SMTP id 5D60537B400 for ; Mon, 28 Jan 2002 11:51:50 -0800 (PST) Received: (qmail 96116 invoked by uid 1001); 28 Jan 2002 19:51:49 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 28 Jan 2002 19:51:49 -0000 Date: Mon, 28 Jan 2002 11:51:49 -0800 (PST) From: Patrick Greenwell To: "Robert D. Hughes" Cc: Nate Williams , Justin White , Subject: RE: firewall config (CTFM) In-Reply-To: Message-ID: <20020128113806.O95859-100000@rockstar.stealthgeeks.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 28 Jan 2002, Robert D. Hughes wrote: > While this will probably get me flamed to no end, users not reading the > docs and keeping up with advisories (sys admins are users too) is only > the cause of little things like nimda, code red, and probably at least > 90% of all the other problems people report with any system. It's always amusing when "keyword commentators" chime in. You know the type; a certain set of keywords trigger a post from these well-intentioned folks that usually haven't bothered to read an entire thread. I've said it repeatedly, but since you weren't paying attention, I'll say it specifically for your benefit: there is no documentation on the ineffectiveness of setting firewall_enable to no, anywhere. One is left to their crystal ball and various and sundry scrying devices in order to intuit that unlike setting firewall_enable to yes, setting firewall_enable to no doesn't do anything and leaves you with a box that doesn't pass packets. [insert obligatory follow-up argument from other parties that says that people that are smart enough to compile a firewall into their kernel aren't smart enough to enable it so it needs to be done for them regardless.] /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Patrick Greenwell Stealthgeeks,LLC. Operations Consulting http://www.stealthgeeks.net \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 11:54:17 2002 Delivered-To: freebsd-stable@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id B90EB37B404 for ; Mon, 28 Jan 2002 11:54:06 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id MAA03513; Mon, 28 Jan 2002 12:53:49 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0SJrha69398; Mon, 28 Jan 2002 12:53:44 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15445.44102.288461.155113@caddis.yogotech.com> Date: Mon, 28 Jan 2002 12:53:42 -0700 To: Erik Trulsson Cc: C J Michaels , charon@seektruth.org, dsyphers@uchicago.edu, imp@village.org, stable@FreeBSD.ORG Subject: Re: Firewall config non-intuitiveness In-Reply-To: <20020128192930.GA86720@student.uu.se> References: <200201271757.g0RHvTF12944@midway.uchicago.edu> <1617.216.153.202.59.1012240332.squirrel@www1.27in.tv> <20020128192930.GA86720@student.uu.se> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Note that "do not enable firewall" (which is implied by firewall_enable="NO") > is *not* equivalent to "disable firewall". Maybe we're having an English language question. If something isn't enabled, doesn't that imply that it's disabled? Last I checked, enabled/disabled were binary operations. If I enable the clutch in my car, my car moves (assuming it's in gear). If I disable it, the power is no longer going to the drive wheels. It's either enabled or disabled. There is no 'in-between' state. (Well, unless you're riding the clutch, but that's not considered a valid state, since the behavior is undefined, as well as bad for your clutch. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 11:56:40 2002 Delivered-To: freebsd-stable@freebsd.org Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NetScum.dyndns.dk (dclient217-162-168-72.hispeed.ch [217.162.168.72]) by hub.freebsd.org (Postfix) with ESMTP id 81D4B37B420 for ; Mon, 28 Jan 2002 11:56:24 -0800 (PST) Received: from beerswilling.netscum.dyndns.dk (dcf77-zeit.netscum.dyndns.dk [172.27.72.27] (may be forged)) by dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NetScum.dyndns.dk (8.11.6/8.11.6) with ESMTP id g0SJuJT05870 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL) for ; Mon, 28 Jan 2002 20:56:22 +0100 (CET) (envelope-from bounce@dcf77-zeit.netscum.dyndns.dk) Received: (from root@localhost) by beerswilling.netscum.dyndns.dk (8.11.6/8.11.6) id g0SJuJp05869; Mon, 28 Jan 2002 20:56:19 +0100 (CET) (envelope-from bounce@dcf77-zeit.netscum.dyndns.dk) Date: Mon, 28 Jan 2002 20:56:19 +0100 (CET) Message-Id: <200201281956.g0SJuJp05869@beerswilling.netscum.dyndns.dk> From: BOUWSMA Beery To: freebsd-stable@freebsd.org Subject: Weird wedge with ep0 ethernet and dhclient Organization: Men not wearing any pants that dont shave X-Hacked: via telnet to your port 25, what else? X-Internet-Access-Provided-By: Mountain Informatik AG, Zuerich X-NetScum: Yes X-One-And-Only-Real-True-Fluffy: No Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Serwus I've been semi-consistently having my machine freeze up in a weird way when attempting to run /sbin/dhclient when the Cabal Modem is connected to an ep0 3Com 3C509 card. When I connect instead to the xl0 card in the same machine, I have no problems at all. I'm just partially looking into this now, if someone else wants to try this and see if I'm full of hot air, or what. The first time I tried this after going multi-user with both the ep0 and xl0 card installed, I think the machine froze, but an attempt to switch consoles (Alt-F?) resulted in the block cursor disappearing, but nothing more. Scroll lock and such keys toggled the LEDs, but I couldn't switch consoles. I could get into the debugger, from which I *could* switch consoles (which I've never tried in normal operation so I don't know if it means anything), but upon `c'ontinuing, things were wedged again. I'm pretty sure that I was able to break into the debugger when I set things up to run dhclient on ep0 as part of the boot, which otherwise seemed to hang forever. Then I pulled out the xl0 card. After going multi-user, I had no problems the one time I used dhclient to configure ep0. Honest. But when I tried to use an identical config file as part of the boot process, whammo -- wedge city. Today I thought I'd try a different machine, and a different slot to boot (same machine model, though, which a friend was eager to throw away though I've had no unresolvable problems so far). The same wedges at boot happen, and I can't get into the debugger (but it's also a different kernel which *should* have DDB and should be otherwise very similar). What I still haven't done is to swap the card into a completely different make of machine and see if I get the same wedges, or if it's a problem with the one particular old 1994-vintage machine I'm using (Digital Venturis 575). I won't rule out a 3C509-card- specific hardware problem too, given that it's an ISA card and my friend who gave it plus the two Digital PCs to me has had much unluck with hardware. Anyway, I just thought that I'd mention that under a fresh -stable I'm seeing this problem, and I'll be looking more at it (at least, juggling hardware) to see if it's a Real Problem or just some odd hardware quirk. More later, like anyone cares thanks barry bouwsma To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 12:10:27 2002 Delivered-To: freebsd-stable@freebsd.org Received: from rockstar.stealthgeeks.net (h-66-134-120-173.LSANCA54.covad.net [66.134.120.173]) by hub.freebsd.org (Postfix) with SMTP id 782D137B404 for ; Mon, 28 Jan 2002 12:10:18 -0800 (PST) Received: (qmail 96418 invoked by uid 1001); 28 Jan 2002 20:10:17 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 28 Jan 2002 20:10:17 -0000 Date: Mon, 28 Jan 2002 12:10:17 -0800 (PST) From: Patrick Greenwell To: Justin White Cc: freebsd-stable@FreeBSD.ORG Subject: re: firewall config (CTFM) In-Reply-To: <12A141AE-13BD-11D6-876A-000393092F82@mac.com> Message-ID: <20020127231521.J87241-100000@rockstar.stealthgeeks.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Note: This was my last post on this issue as I find myself merely repeating points that I've already made.(a cheer goes up from the crowd...) On Mon, 28 Jan 2002, Justin White wrote: > instead of changing the way the system works, let's change the > documentation. new people _should_ be reading the docs, and for people > that already know, well, their existing configuration won't need to > change a bit. > > in RELENG_4 from 5 Nov, /etc/defaults/rc.conf reads: > -snip- > firewall_enable="NO" # Set to YES to enable firewall functionality > firewall_script="/etc/rc.firewall" # Which script to run to set up the > firewall > -snip- > > change the first line to read: > firewall_enable="NO" # set to YES to enable running of the > following firewall script Wow, you've single-handedly suggested a change that solves absolutely nothing, and clarifies absolutely nothing. We all know what setting firewall_enable to yes does. The problem isn't that firewall_enable=yes doesn't do something sane and/or isn't documented(it does and is), it's that firewall_enable=no doesn't and the inconsistent behavior it exhibits isn't documented. Note that if you don't have firewall capabilities compiled in and you set firewall_enable=no, guess what, you end up with no firewall, which is how the distro ships. I'd call that behavior non-intuitive and confusing(firewall_enable=no actually means no if you don't have firewalling compiled in, but it means yes if you do have firewalling compiled in.) > since they _should_ have already read about default-deny in the kernel > config, Oh you mean the one that says nothing absolutely nothing about the firewall_enable option, and gives only partial information that if followed as written will still result in someone being locked out of their box? > the rc.conf docs will remind them that the kernel's policy will > stand without any rules being run. > i'm not trying to be mean, but if you don't read the docs, you deserve > the problems you get. Ah yes, another jumper-on to the RTFM and the "you get what you deserve" bandwagon. The only small problem your argument is that when telling someone to RTFM, it's usually a good idea to make certain that there is something to read. In this case there isn't. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Patrick Greenwell Stealthgeeks,LLC. Operations Consulting http://www.stealthgeeks.net \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 12:14:51 2002 Delivered-To: freebsd-stable@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id CE69637B402 for ; Mon, 28 Jan 2002 12:14:43 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g0SKEdo19363; Mon, 28 Jan 2002 13:14:39 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g0SKETx12129; Mon, 28 Jan 2002 13:14:29 -0700 (MST) (envelope-from imp@village.org) Date: Mon, 28 Jan 2002 13:14:14 -0700 (MST) Message-Id: <20020128.131414.49257581.imp@village.org> To: nate@yogotech.com Cc: ertr1013@student.uu.se, cjm2@earthling.net, charon@seektruth.org, dsyphers@uchicago.edu, stable@FreeBSD.ORG Subject: Re: Firewall config non-intuitiveness From: "M. Warner Losh" In-Reply-To: <15445.44102.288461.155113@caddis.yogotech.com> References: <1617.216.153.202.59.1012240332.squirrel@www1.27in.tv> <20020128192930.GA86720@student.uu.se> <15445.44102.288461.155113@caddis.yogotech.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <15445.44102.288461.155113@caddis.yogotech.com> Nate Williams writes: : If I enable the clutch in my car, my car moves (assuming it's in gear). : If I disable it, the power is no longer going to the drive wheels. That's not quite right, but it is a good analogy. If you disable your clutch, then you are going to have to shift without it and deal with putting it into gear at stops. If you enable your clutch, then you can use it to help in shifting. This isn't quite the same as what you said, and an analogous condition exists with the firewall rules. If you engage your clutch, then you can shift. If you disengage your clutch then your car will go if it is gear (and won't if it isn't). Also, when you enable apm, you aren't enabling power management. That's done in the BIOS. You are enabling the OS using the power management. If you set apm_enable to NO, then the OS doesn't enable power management, but at the same time it doesn't go down to the BIOS to turn off the power management settings in the BIOS. The effects in this case are almost identical, but some BIOSes will still spin down the hard disk, etc even when APM isn't engaged. When you say sendmail_enable=no, it doesn't prevent another mailer from binding to port 25. It just fails to start sendmail, which is the default behavior for the system. If you have sendmail_enable=NO, it doesn't go through and delete the mail queue, or make it impossible to run sendmail from a cron job. I'd argue that the firewall_enable is poorly named, but does the same thing. At most we should rename it to ipfw_maybe_load_ipfw_and_then_load_rules to be 100% correct. firewall_enable=YES means, right now: 1) If ipfw isn't in the kernel, load it. 2) load the rules firewall_enable=NO means do nothing. Same as when sendmail_enable=NO. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 12:17:42 2002 Delivered-To: freebsd-stable@freebsd.org Received: from wow.atlasta.net (wow.atlasta.net [128.241.97.71]) by hub.freebsd.org (Postfix) with ESMTP id 7017937B416 for ; Mon, 28 Jan 2002 12:17:35 -0800 (PST) Received: from localhost (drais@localhost) by wow.atlasta.net (8.11.2/8.11.2) with ESMTP id g0SKHWJ29215; Mon, 28 Jan 2002 12:17:32 -0800 (PST) Date: Mon, 28 Jan 2002 12:17:32 -0800 (PST) From: David Raistrick To: Nate Williams Cc: stable@FreeBSD.ORG Subject: Re: Firewall config non-intuitiveness In-Reply-To: <15445.44102.288461.155113@caddis.yogotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 28 Jan 2002, Nate Williams wrote: > > Note that "do not enable firewall" (which is implied by firewall_enable="NO") > > is *not* equivalent to "disable firewall". > > Maybe we're having an English language question. > > If something isn't enabled, doesn't that imply that it's disabled? Last > I checked, enabled/disabled were binary operations. It would so appear...but there is this alternative: The firewall is already on. If there is not an explicit disable, it is still on. firewall_enable="NO" wouldnt be a "disable" just a "do nothing. if on, leave on, if off, leave off." It IS confusing though. Especially when man rc.conf says: firewall_enable (bool) Set to ``NO'' if you do not want have firewall rules loaded at startup, or ``YES'' if you do. that sort of implies that it would disable it...but only an implication. I guess that it leaves to the obvious that if it is enabled through a method other then the rc.conf, it is up to the user..er..admin...to know that. anyway. i probably should have read how this all started...:p ...david --- david raistrick (no longer deep in the south georgia woods) drais@atlasta.net http://www.expita.com/nomime.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 12:19:17 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mail.27in.tv (roc-66-24-112-7.rochester.rr.com [66.24.112.7]) by hub.freebsd.org (Postfix) with ESMTP id D472737B416 for ; Mon, 28 Jan 2002 12:19:00 -0800 (PST) Received: (from root@localhost) by mail.27in.tv (8.11.6/8.11.6) id g0SKIsn75272; Mon, 28 Jan 2002 15:18:54 -0500 (EST) (envelope-from cjm2@earthling.net) Received: from 27in.tv (roc-66-24-112-7.rochester.rr.com [66.24.112.7]) by mail.27in.tv (8.11.6/8.11.6av) with SMTP id g0SKIrU75262; Mon, 28 Jan 2002 15:18:53 -0500 (EST) (envelope-from cjm2@earthling.net) Received: from 216.153.202.59 (SquirrelMail authenticated user cjm2) by www1.27in.tv with HTTP; Mon, 28 Jan 2002 15:18:53 -0500 (EST) Message-ID: <1913.216.153.202.59.1012249133.squirrel@www1.27in.tv> Date: Mon, 28 Jan 2002 15:18:53 -0500 (EST) Subject: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] From: "C J Michaels" To: In-Reply-To: <20020128192930.GA86720@student.uu.se> References: <20020128192930.GA86720@student.uu.se> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal Cc: , X-Mailer: SquirrelMail (version 1.2.5 [cvs]) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by AMaViS perl-11 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 1st off.. Warner: Sorry for sending my earlier reply w/o reading the whole thread. Jacques: Would the proposed change (below) still require approval from the security officer? ====== In light of all the recent ipfw hubub, I think I have a equitable solution for all. Most or all of these have been suggested by others, I am just trying to put them into one consice proposal. This thread has really gotten out of control and I think, forked in the wrong direction. Instead of changing the functionality of the knob, all we should need to do is properly document the knob and (almost) everyone should be happy. This is the situation as I see it: 1. We have an option that is not intuitive to all, it's not even intuitive to many, even Nate. :) 2. Said knob has the potential to seriously degrade system security if changed. 2a. System security takes precidence to usability, at least with something that can this seriously break a config. 3. We have unclear documentation about said knob. I am going to propose the following changes: 1. We rename the option to something like "firewall_load_rules" or "firewall_enable_rules", etc... Someone else can come up with a short yet more concise variable name. 2. We grandfather in the old option of "firewall_enable" so existing rc.conf(5)'s are not broken. 2a. Obviously we are going to have a default in /etc/default/rc.conf for this newly renamed knob. We should, in cases where firewall_enable="YES", it should override the new knob. 2b. At some point in the future, with much fanfare and documentation, and probably messages to FreeBSD-Security-Advisories we phase out the old option completely, so we don't keep a kludge in the system. 3. Document said change in /etc/defaults/rc.conf and in rc.conf(5). 4. Explicitly document the effect of both "YES" and "NO" in rc.conf(5). This should suit the needs of just about every person who has been involved in this discussion. Please follow up with comments, esp if I missed something. Thanks for you time. -- Chris "I'll defend to the death your right to say that, but I never said I'd listen to it!" -- Tom Galloway with apologies to Voltaire To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 12:21: 7 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mail.acns.ab.ca (mail.acns.ab.ca [142.179.151.95]) by hub.freebsd.org (Postfix) with ESMTP id CDA3337B400 for ; Mon, 28 Jan 2002 12:20:21 -0800 (PST) Received: from colnta.acns.ab.ca (colnta.acns.ab.ca [192.168.1.2]) by mail.acns.ab.ca (8.11.6/8.11.3) with ESMTP id g0SKKGV18667; Mon, 28 Jan 2002 13:20:16 -0700 (MST) (envelope-from davidc@colnta.acns.ab.ca) Received: (from davidc@localhost) by colnta.acns.ab.ca (8.11.6/8.11.3) id g0SKKG766439; Mon, 28 Jan 2002 13:20:16 -0700 (MST) (envelope-from davidc) Date: Mon, 28 Jan 2002 13:20:15 -0700 From: Chad David To: Patrick Greenwell Cc: "Robert D. Hughes" , Nate Williams , Justin White , freebsd-stable@FreeBSD.ORG Subject: Re: firewall config (CTFM) Message-ID: <20020128132015.A66369@colnta.acns.ab.ca> Mail-Followup-To: Patrick Greenwell , "Robert D. Hughes" , Nate Williams , Justin White , freebsd-stable@FreeBSD.ORG References: <20020128113806.O95859-100000@rockstar.stealthgeeks.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020128113806.O95859-100000@rockstar.stealthgeeks.net>; from patrick@stealthgeeks.net on Mon, Jan 28, 2002 at 11:51:49AM -0800 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jan 28, 2002 at 11:51:49AM -0800, Patrick Greenwell wrote: > On Mon, 28 Jan 2002, Robert D. Hughes wrote: > > > While this will probably get me flamed to no end, users not reading the > > docs and keeping up with advisories (sys admins are users too) is only > > the cause of little things like nimda, code red, and probably at least > > 90% of all the other problems people report with any system. > > It's always amusing when "keyword commentators" chime in. You know the > type; a certain set of keywords trigger a post from these well-intentioned > folks that usually haven't bothered to read an entire thread. I can see that your attitude has done nothing but help you gain support for your position :). (and yes I have been reading this thread) > > I've said it repeatedly, but since you weren't paying attention, I'll say > it specifically for your benefit: there is no documentation on the > ineffectiveness of setting firewall_enable to no, anywhere. One is left to > their crystal ball and various and sundry scrying devices in order to > intuit that unlike setting firewall_enable to yes, setting firewall_enable > to no doesn't do anything and leaves you with a box that doesn't pass packets. Could you please explain how the following makes sense? 1) I enable ipfw in my kernel 2) I do not configure it to allow by default 3) I reboot with firewall_enable="NO" 4) The firewall defaults to allow If I set the default in my kernel config to deny, then that is exactly what I want it to do. If I want it to allow by default then that is what I will put in the kernel config. What you are asking for is that the firewall code not be enabled in the kernel (same as allow ip from any to any), which goes against your previous wishes when you compiled it into your kernel. Perhaps neither is obvious, but who gets to win?. It seems obvious to me that FreeBSD will not change the default to allow, so arguing for that is a waste of time; instead, I would recommend fixing the documentation. One of the things I would recommend documenting very clearly is that you DO NOT NEED TO COMPILE IPFW INTO THE KERNEL. Load the module. If you left it out of your kernel, and used the module for what it was designed for then firewall_enable="NO" would do exactly what you want it to do. > > [insert obligatory follow-up argument from other parties that says that > people that are smart enough to compile a firewall into their kernel > aren't smart enough to enable it so it needs to be done for them > regardless.] Again, I don't see how that helped, but... When I consider how many times a day my webserver gets hit with spam from windows machines that are run by admins who do not know how to apply patches, a lot of my concern for folks who want to run network services, but do not know, how goes away. What they need is documentation, not a configuration system that reads like english (or whatever). If you have any constructive comments about the exsiting docs, and would like to supply patches (or even raw text), I'm sure somebody would be willing to commit them for you (I would even format them for you if you wanted). There are two places I would start, firewall(7), and rc.conf(5). For the group at large, does FreeBSD recommend ipfw be compiled into the kernel (for general use), and if so what is the module for? If we change the documented recommendation (firewall(7)) from compiling it in to using the module, new users would get behaviour they seem to expect from firewall_enable="XXX", while more experienced users would be left with the existing behaviour. Let me point out that my personal preference is for deny to be the default, and that if I make a mistake in the config that it defaults to locking everything out (note that I protect real assets behind firewalls). -- Chad David davidc@acns.ab.ca www.FreeBSD.org davidc@freebsd.org ACNS Inc. Calgary, Alberta Canada Fourthly, The constant breeders, beside the gain of eight shillings sterling per annum by the sale of their children, will be rid of the charge of maintaining them after the first year. - Johnathan Swift To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 12:21:33 2002 Delivered-To: freebsd-stable@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id ECD9437B444 for ; Mon, 28 Jan 2002 12:20:56 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id NAA04641; Mon, 28 Jan 2002 13:20:42 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0SKKft69842; Mon, 28 Jan 2002 13:20:41 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15445.45720.514136.887062@caddis.yogotech.com> Date: Mon, 28 Jan 2002 13:20:40 -0700 To: "M. Warner Losh" Cc: nate@yogotech.com, ertr1013@student.uu.se, cjm2@earthling.net, charon@seektruth.org, dsyphers@uchicago.edu, stable@FreeBSD.ORG Subject: Re: Firewall config non-intuitiveness In-Reply-To: <20020128.131414.49257581.imp@village.org> References: <1617.216.153.202.59.1012240332.squirrel@www1.27in.tv> <20020128192930.GA86720@student.uu.se> <15445.44102.288461.155113@caddis.yogotech.com> <20020128.131414.49257581.imp@village.org> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > : If I enable the clutch in my car, my car moves (assuming it's in gear). > : If I disable it, the power is no longer going to the drive wheels. > > That's not quite right, but it is a good analogy. If you disable your > clutch, then you are going to have to shift without it and deal with > putting it into gear at stops. Unfortunately, you can't do it w/out a clutch. (At least, not without tearing your clutch/transmission to bits). > If you enable your clutch, then you > can use it to help in shifting. This isn't quite the same as what you > said, and an analogous condition exists with the firewall rules. "help in shifting"? I'd call a clutch the most critical part of a transmission. W/out a clutch, you don't have a transmission. > Also, when you enable apm, you aren't enabling power management. Sure you are. > That's done in the BIOS. You are enabling the OS using the power > management. If you don't enable apm in the OS, power management won't be done. It (the BIOS) sends the commands to the OS, which ignores them, and the BIOS does nothing. (It means that you can't shutdown the box automatically when the power gets low, etc...) > If you set apm_enable to NO, then the OS doesn't enable power > management, but at the same time it doesn't go down to the BIOS to > turn off the power management settings in the BIOS. Because that wouldn't do much. > The effects in this case are almost identical, but some BIOSes will > still spin down the hard disk, etc even when APM isn't engaged. Not w/out OS participation on any of the dozen or so laptops I've owned, or any of the desktops. > When you say sendmail_enable=no, it doesn't prevent another mailer > from binding to port 25. No, but it disables 'sendmail' from binding to port 25. Note the item is 'sendmail_enable', not 'mail_enable'. > It just fails to start sendmail, which is the default behavior for the > system. If you have sendmail_enable=NO, it doesn't go through and > delete the mail queue, or make it impossible to run sendmail from a > cron job. Who said anything about making anything impossible? Saying 'firewall_enable'=NO doesn't disable the system from using the firewall in the future. It doesn't recompile the kernel and remove the FIREWALL capability from the kernel, and/or delete ipfw.ko from the system. Now you're being silly. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 12:26:19 2002 Delivered-To: freebsd-stable@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id E2CFB37B400 for ; Mon, 28 Jan 2002 12:26:15 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id NAA04868; Mon, 28 Jan 2002 13:26:04 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0SKQ3V69881; Mon, 28 Jan 2002 13:26:03 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15445.46043.85910.572903@caddis.yogotech.com> Date: Mon, 28 Jan 2002 13:26:03 -0700 To: Chad David Cc: Patrick Greenwell , "Robert D. Hughes" , Nate Williams , Justin White , freebsd-stable@FreeBSD.ORG Subject: Re: firewall config (CTFM) In-Reply-To: <20020128132015.A66369@colnta.acns.ab.ca> References: <20020128113806.O95859-100000@rockstar.stealthgeeks.net> <20020128132015.A66369@colnta.acns.ab.ca> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Could you please explain how the following makes sense? > > 1) I enable ipfw in my kernel > 2) I do not configure it to allow by default > 3) I reboot with firewall_enable="NO" > 4) The firewall defaults to allow > > If I set the default in my kernel config to deny, then that is exactly > what I want it to do. If I want it to allow by default then that is > what I will put in the kernel config. Can you give me a *REAL WORLD* example of when you would want this sort of setup once a box has been configured? (Seriously). Don't give me straw-man (if the box wasn't configured, etc...), since you could just as easily enable the firewall and it behaves the same. Basically, if you have a firewall, firewall_enable="NO" == firewall_enable="YES" if you don't touch /etc/rc.firewall or /etc/rc.firewall_script. > What you are asking for is that the firewall code not be enabled in the > kernel (same as allow ip from any to any), which goes against your > previous wishes when you compiled it into your kernel. Perhaps neither > is obvious, but who gets to win?. Why did you compile in the firewall if you don't want it enabled? In any case, the people arguing against are arguing for the sake of keeping past behavior, regardless of how logical it should be. "Let's keep those bugs, cause I've grown accustomed to them so long that I now expect them to be there. Screw any new users who want to use the system!" Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 12:32:38 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mail.acns.ab.ca (mail.acns.ab.ca [142.179.151.95]) by hub.freebsd.org (Postfix) with ESMTP id C175B37B419 for ; Mon, 28 Jan 2002 12:32:33 -0800 (PST) Received: from colnta.acns.ab.ca (colnta.acns.ab.ca [192.168.1.2]) by mail.acns.ab.ca (8.11.6/8.11.3) with ESMTP id g0SKWXV18724; Mon, 28 Jan 2002 13:32:33 -0700 (MST) (envelope-from davidc@colnta.acns.ab.ca) Received: (from davidc@localhost) by colnta.acns.ab.ca (8.11.6/8.11.3) id g0SKWWj66473; Mon, 28 Jan 2002 13:32:32 -0700 (MST) (envelope-from davidc) Date: Mon, 28 Jan 2002 13:32:32 -0700 From: Chad David To: Nate Williams Cc: Erik Trulsson , C J Michaels , charon@seektruth.org, dsyphers@uchicago.edu, imp@village.org, stable@FreeBSD.ORG Subject: Re: Firewall config non-intuitiveness Message-ID: <20020128133232.C66369@colnta.acns.ab.ca> Mail-Followup-To: Nate Williams , Erik Trulsson , C J Michaels , charon@seektruth.org, dsyphers@uchicago.edu, imp@village.org, stable@FreeBSD.ORG References: <200201271757.g0RHvTF12944@midway.uchicago.edu> <1617.216.153.202.59.1012240332.squirrel@www1.27in.tv> <20020128192930.GA86720@student.uu.se> <15445.44102.288461.155113@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15445.44102.288461.155113@caddis.yogotech.com>; from nate@yogotech.com on Mon, Jan 28, 2002 at 12:53:42PM -0700 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jan 28, 2002 at 12:53:42PM -0700, Nate Williams wrote: > > Note that "do not enable firewall" (which is implied by firewall_enable="NO") > > is *not* equivalent to "disable firewall". > > Maybe we're having an English language question. > > If something isn't enabled, doesn't that imply that it's disabled? Last > I checked, enabled/disabled were binary operations. > > If I enable the clutch in my car, my car moves (assuming it's in gear). > If I disable it, the power is no longer going to the drive wheels. True, but the real question is what does firewall_enable actually enable and disable? In its current state it enables and disables the adding of rules as defined by firewall_type (rc.conf(5)). The docs could be a little better about what will happen if you set firewall_enable="NO", and have it compiled into your kernel. -- Chad David davidc@acns.ab.ca www.FreeBSD.org davidc@freebsd.org ACNS Inc. Calgary, Alberta Canada Fourthly, The constant breeders, beside the gain of eight shillings sterling per annum by the sale of their children, will be rid of the charge of maintaining them after the first year. - Johnathan Swift To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 12:33:44 2002 Delivered-To: freebsd-stable@freebsd.org Received: from zaphod.wox.org (CPE0050bae86969.cpe.net.cable.rogers.com [24.112.22.141]) by hub.freebsd.org (Postfix) with ESMTP id 0652F37B416 for ; Mon, 28 Jan 2002 12:33:20 -0800 (PST) Received: from localhost (rglidden@localhost) by zaphod.wox.org (8.11.6/8.11.6) with ESMTP id g0SKX5q10997; Mon, 28 Jan 2002 15:33:05 -0500 (EST) (envelope-from rglidden@zaphod.wox.org) Date: Mon, 28 Jan 2002 15:33:05 -0500 (EST) From: Richard Glidden X-X-Sender: rglidden@charon.acheron.localnet To: Nate Williams Cc: freebsd-stable@FreeBSD.ORG Subject: RE: firewall config (CTFM) In-Reply-To: <15445.37204.693732.376471@caddis.yogotech.com> Message-ID: <20020128150458.E10891-100000@charon.acheron.localnet> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 28 Jan 2002, Nate Williams wrote: > Also, even *I* can't find answers to my questions with 30 minutes, and I > know where to look, so I find you statement, well, to be brutally > honest, both humerous and a little bit egotistical. : man rc.conf: firewall_enable (bool) Set to ``NO'' if you do not want have firewall rules loaded at startup, or ``YES'' if you do. If set to ``YES'', and the kernel was not built with IPFIREWALL, the ipfw kernel module will be loaded. See also ipfilter_enable. Obviously, NO means "Don't Load Firewall Rules." This implies, to me, that some sort of defaults might be loaded, but what those defaults are, who knows? What does the firewall do if there are no rules? Better check what IPFIREWALL really means... LINT: # IPFIREWALL enables support for IP firewall construction, in # conjunction with the `ipfw' program. IPFIREWALL_VERBOSE sends # logged packets to the system logger. IPFIREWALL_VERBOSE_LIMIT # limits the number of times a matching entry can be logged. # # WARNING: IPFIREWALL defaults to a policy of "deny ip from any to any" # and if you do not add other rules during startup to allow access, # YOU WILL LOCK YOURSELF OUT. It is suggested that you set # firewall_type=open in /etc/rc.conf when first enabling this feature, # then refining the firewall rules in /etc/rc.firewall after you've # tested that the new kernel feature works properly. Ok, so if I don't load rules, I will lock myself out. So firewall_enable="NO" + IPFIREWALL = instant lockout. Seems pretty clear. What does rc.conf say? firewall_enable="NO" # Set to YES to enable firewall functionality Hrm. A little vague, but it's in line with what the man page says. Besides, I shouldn't be looking at this file anyway, right? The answers are there, and are not too difficult to find. The problem is that the answer is spread across LINT and man rc.conf, plus there's a vague statement in rc.conf and the variable name is misleading. Depending on what documentation you stumble across, or how little documentation you read, you don't get the right answer. Really, the man page should be updated to include the information from LINT, so you know that firewall_enable=NO may lock you out if to built the firewall into the kernel, and the rc.conf comment should be adjusted in case people look there instead of the man page. The whole source of the confusion is that "firewall_enable" behaves differently depending on whether or not you have IPFIREWALL defined in your kernel. Without it, "firewall_enable='NO'" means to not load any firewall functionality, and leave everything wide open. With IPFIREWALL defined, it means to not load any custom rules, and do whatever is the default in the kernel (deny or accept everything) which may lock you out. The only good solution is to turn firewall_enable into a tri-state variable, as has been suggested, or break the two options out into two rc.conf variables. "firewall_enable" which enables or disables firewall functionality (or controls loading of the module) and "firewall_rules" which controls loading of the rules or not, for example. Of course, as has been pointed out, this will break people's configurations, and should probably wait for FreeBSD 5.0. Thanks, - Richard To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 12:35:54 2002 Delivered-To: freebsd-stable@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id CD6D537B416 for ; Mon, 28 Jan 2002 12:35:48 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id NAA05263; Mon, 28 Jan 2002 13:35:47 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0SKZj170110; Mon, 28 Jan 2002 13:35:45 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15445.46625.765383.179068@caddis.yogotech.com> Date: Mon, 28 Jan 2002 13:35:45 -0700 To: Richard Glidden Cc: Nate Williams , freebsd-stable@FreeBSD.ORG Subject: RE: firewall config (CTFM) In-Reply-To: <20020128150458.E10891-100000@charon.acheron.localnet> References: <15445.37204.693732.376471@caddis.yogotech.com> <20020128150458.E10891-100000@charon.acheron.localnet> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > Also, even *I* can't find answers to my questions with 30 minutes, and I > > know where to look, so I find you statement, well, to be brutally > > honest, both humerous and a little bit egotistical. : > > man rc.conf: > > firewall_enable > (bool) Set to ``NO'' if you do not want have firewall > rules loaded at startup, or ``YES'' if you do. If set > to ``YES'', and the kernel was not built with > IPFIREWALL, the ipfw kernel module will be loaded. See > also ipfilter_enable. > > Obviously, NO means "Don't Load Firewall Rules." This implies, to me, > that some sort of defaults might be loaded, but what those defaults > are, who knows? They might be loaded. And then again, they might not be loaded. Who knows (unless you've done this, and it's bitten you in the *ss.) I give up. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 12:36:45 2002 Delivered-To: freebsd-stable@freebsd.org Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id E95F537B404 for ; Mon, 28 Jan 2002 12:36:41 -0800 (PST) Received: from madman.nectar.cc (madman.nectar.cc [10.0.1.111]) by gw.nectar.cc (Postfix) with ESMTP id 6C8DF4C; Mon, 28 Jan 2002 14:36:41 -0600 (CST) Received: (from nectar@localhost) by madman.nectar.cc (8.11.6/8.11.6) id g0SKafB43156; Mon, 28 Jan 2002 14:36:41 -0600 (CST) (envelope-from nectar) Date: Mon, 28 Jan 2002 14:36:40 -0600 From: "Jacques A. Vidrine" To: Chad David Cc: freebsd-stable@FreeBSD.ORG Subject: Re: firewall config (CTFM) Message-ID: <20020128203640.GB42996@madman.nectar.cc> Mail-Followup-To: "Jacques A. Vidrine" , Chad David , freebsd-stable@FreeBSD.ORG References: <20020128113806.O95859-100000@rockstar.stealthgeeks.net> <20020128132015.A66369@colnta.acns.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020128132015.A66369@colnta.acns.ab.ca> User-Agent: Mutt/1.3.27i X-Url: http://www.nectar.cc/ Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jan 28, 2002 at 01:20:15PM -0700, Chad David wrote: > One of the things I would recommend documenting very clearly is that > you DO NOT NEED TO COMPILE IPFW INTO THE KERNEL. Except if you want to default to deny, you must [1]. The rc system loads the firewall after configuring your interfaces. This may be a bug. Cheers, -- Jacques A. Vidrine http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se [1] Well, I suppose you could load the ipfw module with the boot loader instead. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 12:36:51 2002 Delivered-To: freebsd-stable@freebsd.org Received: from ns1.pilikia.net (ns1.pilikia.net [63.173.194.12]) by hub.freebsd.org (Postfix) with ESMTP id 12FDC37B416 for ; Mon, 28 Jan 2002 12:36:43 -0800 (PST) Received: from gecko (gecko.local.net [10.25.0.9]) by ns1.pilikia.net (8.11.6/8.11.6) with ESMTP id g0SKaJl68426; Mon, 28 Jan 2002 10:36:19 -1000 (HST) (envelope-from art@pilikia.net) Message-ID: <200201281036190800.033FD7A3@smtp> In-Reply-To: <20020128192930.GA86720@student.uu.se> References: <200201271757.g0RHvTF12944@midway.uchicago.edu> <1617.216.153.202.59.1012240332.squirrel@www1.27in.tv> <20020128192930.GA86720@student.uu.se> X-Mailer: Calypso Version 3.20.02.00 (3) Date: Mon, 28 Jan 2002 10:36:19 -1000 Reply-To: art@pilikia.net From: "Arthur W. Neilson III" To: "Erik Trulsson" Cc: freebsd-stable@freebsd.org Subject: Re: Firewall config non-intuitiveness Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: by AMaViS/NAI-uvscan-4.14 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Right on. I want my firewalls to protect by default, no dufus admin typo can accidently expose us to intrusion. Most security doctrines adhere to the tenet of denying by default and allowing as needed instead of vice versa. To allow by default is asking for trouble. On 1/28/02 at 8:29 PM Erik Trulsson wrote: > >So, while I agree the the current situation might not be quite as >intuitive as it might be changing the behaviour of firewall_enable="NO" >to actually disabling the firewall is, IMO, *not* the right way to fix >this. >(If the admin went to the trouble of adding IPFIREWALL to the kernel, >the default behaviour should be to not disable it.) -- __ / ) _/_ It is a capital mistake to theorise before one has data. /--/ __ / Insensibly one begins to twist facts to suit theories, / (_/ (_<__ Instead of theories to suit facts. -- Sherlock Holmes, "A Scandal in Bohemia" Arthur W. Neilson III, WH7N - FISTS #7448 Bank of Hawaii Network Services http://www.pilikia.net art@pilikia.net, aneilson@boh.com, wh7n@arrl.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 12:38:20 2002 Delivered-To: freebsd-stable@freebsd.org Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id B031337B402 for ; Mon, 28 Jan 2002 12:38:01 -0800 (PST) Received: from madman.nectar.cc (madman.nectar.cc [10.0.1.111]) by gw.nectar.cc (Postfix) with ESMTP id 4D4E734; Mon, 28 Jan 2002 14:38:01 -0600 (CST) Received: (from nectar@localhost) by madman.nectar.cc (8.11.6/8.11.6) id g0SKc1K43177; Mon, 28 Jan 2002 14:38:01 -0600 (CST) (envelope-from nectar) Date: Mon, 28 Jan 2002 14:38:01 -0600 From: "Jacques A. Vidrine" To: Patrick Greenwell Cc: freebsd-stable@FreeBSD.ORG Subject: Re: firewall config (CTFM) Message-ID: <20020128203800.GC42996@madman.nectar.cc> Mail-Followup-To: "Jacques A. Vidrine" , Patrick Greenwell , freebsd-stable@FreeBSD.ORG References: <20020128113806.O95859-100000@rockstar.stealthgeeks.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020128113806.O95859-100000@rockstar.stealthgeeks.net> User-Agent: Mutt/1.3.27i X-Url: http://www.nectar.cc/ Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jan 28, 2002 at 11:51:49AM -0800, Patrick Greenwell wrote: > I've said it repeatedly, but since you weren't paying attention, I'll say > it specifically for your benefit: there is no documentation on the > ineffectiveness of setting firewall_enable to no, anywhere. So submit patches for the documentation and let's move on already. -- Jacques A. Vidrine http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 12:40:23 2002 Delivered-To: freebsd-stable@freebsd.org Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 2E64A37B400 for ; Mon, 28 Jan 2002 12:40:16 -0800 (PST) Received: from madman.nectar.cc (madman.nectar.cc [10.0.1.111]) by gw.nectar.cc (Postfix) with ESMTP id 8223A4C; Mon, 28 Jan 2002 14:40:16 -0600 (CST) Received: (from nectar@localhost) by madman.nectar.cc (8.11.6/8.11.6) id g0SKeDG43189; Mon, 28 Jan 2002 14:40:13 -0600 (CST) (envelope-from nectar) Date: Mon, 28 Jan 2002 14:40:13 -0600 From: "Jacques A. Vidrine" To: Nate Williams Cc: freebsd-stable@FreeBSD.ORG Subject: Re: firewall config (CTFM) Message-ID: <20020128204013.GD42996@madman.nectar.cc> Mail-Followup-To: "Jacques A. Vidrine" , Nate Williams , freebsd-stable@FreeBSD.ORG References: <20020128113806.O95859-100000@rockstar.stealthgeeks.net> <20020128132015.A66369@colnta.acns.ab.ca> <15445.46043.85910.572903@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15445.46043.85910.572903@caddis.yogotech.com> User-Agent: Mutt/1.3.27i X-Url: http://www.nectar.cc/ Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jan 28, 2002 at 01:26:03PM -0700, Nate Williams wrote: > In any case, the people arguing against are arguing for the sake of > keeping past behavior, regardless of how logical it should be. > > "Let's keep those bugs, cause I've grown accustomed to them so long that > I now expect them to be there. Screw any new users who want to use the > system!" Other than the documentation, what is the bug exactly? -- Jacques A. Vidrine http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 12:41:42 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mail.acns.ab.ca (mail.acns.ab.ca [142.179.151.95]) by hub.freebsd.org (Postfix) with ESMTP id 505C537B400 for ; Mon, 28 Jan 2002 12:41:33 -0800 (PST) Received: from colnta.acns.ab.ca (colnta.acns.ab.ca [192.168.1.2]) by mail.acns.ab.ca (8.11.6/8.11.3) with ESMTP id g0SKfRV18784; Mon, 28 Jan 2002 13:41:28 -0700 (MST) (envelope-from davidc@colnta.acns.ab.ca) Received: (from davidc@localhost) by colnta.acns.ab.ca (8.11.6/8.11.3) id g0SKfRr66511; Mon, 28 Jan 2002 13:41:27 -0700 (MST) (envelope-from davidc) Date: Mon, 28 Jan 2002 13:41:27 -0700 From: Chad David To: Nate Williams Cc: Patrick Greenwell , "Robert D. Hughes" , Justin White , freebsd-stable@FreeBSD.ORG Subject: Re: firewall config (CTFM) Message-ID: <20020128134127.E66369@colnta.acns.ab.ca> Mail-Followup-To: Nate Williams , Patrick Greenwell , "Robert D. Hughes" , Justin White , freebsd-stable@FreeBSD.ORG References: <20020128113806.O95859-100000@rockstar.stealthgeeks.net> <20020128132015.A66369@colnta.acns.ab.ca> <15445.46043.85910.572903@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15445.46043.85910.572903@caddis.yogotech.com>; from nate@yogotech.com on Mon, Jan 28, 2002 at 01:26:03PM -0700 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jan 28, 2002 at 01:26:03PM -0700, Nate Williams wrote: > > Could you please explain how the following makes sense? > > > > 1) I enable ipfw in my kernel > > 2) I do not configure it to allow by default > > 3) I reboot with firewall_enable="NO" > > 4) The firewall defaults to allow > > > > If I set the default in my kernel config to deny, then that is exactly > > what I want it to do. If I want it to allow by default then that is > > what I will put in the kernel config. > > Can you give me a *REAL WORLD* example of when you would want this sort > of setup once a box has been configured? (Seriously). I actually do this all of the time when I do updates on my gateway. I drop the security level, disable the firewall and reboot. After that I install the new kernel etc., reset everything and reboot again (to test it). I wouldn't object to being told, "use firewall_type="CLOSED" as firewall_enable="NO" disables the firewall code", but this would have to be well documented, and probably introducted into current, and not stable. > > Don't give me straw-man (if the box wasn't configured, etc...), since > you could just as easily enable the firewall and it behaves the same. > > Basically, if you have a firewall, firewall_enable="NO" == > firewall_enable="YES" if you don't touch /etc/rc.firewall or > /etc/rc.firewall_script. As I pointed out in my other email to you, what are we enabling and disabling? By the documentation not the code, but the rules. Again, I don't have a problem with this changing, as long is it is documented and introduced into the correct branch. > > > What you are asking for is that the firewall code not be enabled in the > > kernel (same as allow ip from any to any), which goes against your > > previous wishes when you compiled it into your kernel. Perhaps neither > > is obvious, but who gets to win?. > > Why did you compile in the firewall if you don't want it enabled? Thats my question :). > > In any case, the people arguing against are arguing for the sake of > keeping past behavior, regardless of how logical it should be. > > "Let's keep those bugs, cause I've grown accustomed to them so long that > I now expect them to be there. Screw any new users who want to use the > system!" > I'm not, I just want to make sure we are all on the same page while we argue; otherwise, we will never agree and all of this is for nothing (if I wanted that I would join the Linux kernel mailing lists). -- Chad David davidc@acns.ab.ca www.FreeBSD.org davidc@freebsd.org ACNS Inc. Calgary, Alberta Canada Fourthly, The constant breeders, beside the gain of eight shillings sterling per annum by the sale of their children, will be rid of the charge of maintaining them after the first year. - Johnathan Swift To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 12:42:29 2002 Delivered-To: freebsd-stable@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 4533837B402 for ; Mon, 28 Jan 2002 12:42:25 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g0SKgKo19600; Mon, 28 Jan 2002 13:42:20 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g0SKgIx12486; Mon, 28 Jan 2002 13:42:18 -0700 (MST) (envelope-from imp@village.org) Date: Mon, 28 Jan 2002 13:42:03 -0700 (MST) Message-Id: <20020128.134203.76273366.imp@village.org> To: nate@yogotech.com Cc: ertr1013@student.uu.se, cjm2@earthling.net, charon@seektruth.org, dsyphers@uchicago.edu, stable@FreeBSD.ORG Subject: Re: Firewall config non-intuitiveness From: "M. Warner Losh" In-Reply-To: <15445.45720.514136.887062@caddis.yogotech.com> References: <15445.44102.288461.155113@caddis.yogotech.com> <20020128.131414.49257581.imp@village.org> <15445.45720.514136.887062@caddis.yogotech.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <15445.45720.514136.887062@caddis.yogotech.com> Nate Williams writes: : > : If I enable the clutch in my car, my car moves (assuming it's in gear). : > : If I disable it, the power is no longer going to the drive wheels. : > : > That's not quite right, but it is a good analogy. If you disable your : > clutch, then you are going to have to shift without it and deal with : > putting it into gear at stops. : : Unfortunately, you can't do it w/out a clutch. (At least, not without : tearing your clutch/transmission to bits). Yes, you can. : > If you enable your clutch, then you : > can use it to help in shifting. This isn't quite the same as what you : > said, and an analogous condition exists with the firewall rules. : : "help in shifting"? I'd call a clutch the most critical part of a : transmission. W/out a clutch, you don't have a transmission. I have seen people goe years w/o a functioning clutch. Randy Seager, an old boss, didn't have a clutch in his 1974 trans-am for the three years I worked for him. He had to match the gear speeds exactly to shift at stoplights, but was able to do it. : > Also, when you enable apm, you aren't enabling power management. : : Sure you are. : : > That's done in the BIOS. You are enabling the OS using the power : > management. : : If you don't enable apm in the OS, power management won't be done. It : (the BIOS) sends the commands to the OS, which ignores them, and the : BIOS does nothing. : : (It means that you can't shutdown the box automatically when the power : gets low, etc...) That's not correct. I have had machines that did spin down disks, even when the OS didn't enable the APM/ACPI interface. I just tried it on my inspiron 8000 from dell, and the disks did spin down. You couldn't turn off the machine with apm not enabled, but not all power management functions were disabled. : > It just fails to start sendmail, which is the default behavior for the : > system. If you have sendmail_enable=NO, it doesn't go through and : > delete the mail queue, or make it impossible to run sendmail from a : > cron job. : : Who said anything about making anything impossible? Saying : 'firewall_enable'=NO doesn't disable the system from using the firewall : in the future. It doesn't recompile the kernel and remove the FIREWALL : capability from the kernel, and/or delete ipfw.ko from the system. : : Now you're being silly. No. I'm being consistant. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 12:46: 0 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by hub.freebsd.org (Postfix) with ESMTP id B24AC37B400 for ; Mon, 28 Jan 2002 12:45:49 -0800 (PST) Received: from d1o913.telia.com (d1o913.telia.com [195.252.44.241]) by mailc.telia.com (8.11.6/8.11.6) with ESMTP id g0SKjm403553 for ; Mon, 28 Jan 2002 21:45:48 +0100 (CET) Received: from falcon.midgard.homeip.net (h185n2fls20o913.telia.com [212.181.163.185]) by d1o913.telia.com (8.8.8/8.8.8) with SMTP id VAA14152 for ; Mon, 28 Jan 2002 21:45:45 +0100 (CET) Received: (qmail 87454 invoked by uid 1001); 28 Jan 2002 20:45:43 -0000 Date: Mon, 28 Jan 2002 21:45:43 +0100 From: Erik Trulsson To: Nate Williams Cc: C J Michaels , charon@seektruth.org, dsyphers@uchicago.edu, imp@village.org, stable@FreeBSD.ORG Subject: Re: Firewall config non-intuitiveness Message-ID: <20020128204542.GA87400@student.uu.se> Mail-Followup-To: Nate Williams , C J Michaels , charon@seektruth.org, dsyphers@uchicago.edu, imp@village.org, stable@FreeBSD.ORG References: <200201271757.g0RHvTF12944@midway.uchicago.edu> <1617.216.153.202.59.1012240332.squirrel@www1.27in.tv> <20020128192930.GA86720@student.uu.se> <15445.44102.288461.155113@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15445.44102.288461.155113@caddis.yogotech.com> User-Agent: Mutt/1.3.25i Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jan 28, 2002 at 12:53:42PM -0700, Nate Williams wrote: > > Note that "do not enable firewall" (which is implied by firewall_enable="NO") > > is *not* equivalent to "disable firewall". > > Maybe we're having an English language question. Probably. Natural languages are notoriously ambiguous and easy to misinterpret. > > If something isn't enabled, doesn't that imply that it's disabled? Last Correct so far. > I checked, enabled/disabled were binary operations. No, they are binary states. An operation is someting you do. (Enabled/disabled are states. Enable/disable are operations.) > If I enable the clutch in my car, my car moves (assuming it's in gear). > If I disable it, the power is no longer going to the drive wheels. > > It's either enabled or disabled. There is no 'in-between' state. > (Well, unless you're riding the clutch, but that's not considered a > valid state, since the behavior is undefined, as well as bad for your > clutch. :) Never heard about fuzzy logic? :-) There are four possible functions (or operations) taking a binary value to another binary value. (I.e. a function f(x) from {0,1} -> {0,1}) You can: 1) Map all input values to 1 2) Map all input values to 0 3) Return the input unchanged 4) Return logical inverse of the input. Now let us represent 'enabled' by 1 and 'disabled' by 0 Then I would say that "to enable something" corresponds to function 1), i.e. to move it to the enabled state regardless of what state it was in previously. Similarily "to disable something" corresponds to function 2) Now what should "do not enable it" correspond to? It obviously can't be 1), and 4) seems quite counter-intuitive and (when talking about firewalls) not very useful. Remains 2) and 3) where 3) is the current behaviour for firewalls and 2) the proposed one. To me "do not enable" means that we should not change the state to 'enabled'. But if we already are in the enabled state then what? Since letting it remain in the current state does not constitute *changing* the state to 'enabled' this is a perfectly good interpretation of "do not enable". Now, changing the state to 'disabled' also fits the decription "do not enable", but IMO changing the state unless explicitly asked to do so is a bad idea. That is why I (and others before) have said that a tristate variable (corresponding to functions 1), 2) and 3) above) is probably the best solution. (With 3) being the default.) (Function 4) is fairly useless for this so we can skip it.) Another possiblity is changing the name. For example using "firewall_enabled" instead of "firewall_enable" To me that means "should the firewall state be in the 'enabled' state" rather than "should we move the firewall state to 'enabled'" (I.e. describing the state rather than the operation.) In either case, changing the meaning of 'firewall_enable="NO"' should probably not be done in -STABLE to avoid messing things up for people who depend on the current behaviour. (Since changing the behaviour as proposed would, for some configurations, mean a lowered security this is extra important for this case.) -- Erik Trulsson ertr1013@student.uu.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 12:46:16 2002 Delivered-To: freebsd-stable@freebsd.org Received: from gscamnlm03.wr.usgs.gov (gscamnlm03.wr.usgs.gov [130.118.4.113]) by hub.freebsd.org (Postfix) with ESMTP id 1DD4037B402; Mon, 28 Jan 2002 12:46:06 -0800 (PST) To: art@pilikia.net Cc: "Erik Trulsson" , freebsd-stable@freebsd.org, owner-freebsd-stable@FreeBSD.ORG Subject: Re: Firewall config non-intuitiveness MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Robert L Sowders" Date: Mon, 28 Jan 2002 12:45:57 -0800 X-MIMETrack: Serialize by Router on gscamnlm03/SERVER/USGS/DOI(Release 5.0.8 |June 18, 2001) at 01/28/2002 12:46:06 PM, Serialize complete at 01/28/2002 12:46:06 PM Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG You have obviously missed the beginning of this thread, check google to come up to speed "Arthur W. Neilson III" Sent by: owner-freebsd-stable@FreeBSD.ORG 01/28/2002 12:36 PM Please respond to art To: "Erik Trulsson" cc: freebsd-stable@freebsd.org Subject: Re: Firewall config non-intuitiveness Right on. I want my firewalls to protect by default, no dufus admin typo can accidently expose us to intrusion. Most security doctrines adhere to the tenet of denying by default and allowing as needed instead of vice versa. To allow by default is asking for trouble. On 1/28/02 at 8:29 PM Erik Trulsson wrote: > >So, while I agree the the current situation might not be quite as >intuitive as it might be changing the behaviour of firewall_enable="NO" >to actually disabling the firewall is, IMO, *not* the right way to fix >this. >(If the admin went to the trouble of adding IPFIREWALL to the kernel, >the default behaviour should be to not disable it.) -- __ / ) _/_ It is a capital mistake to theorise before one has data. /--/ __ / Insensibly one begins to twist facts to suit theories, / (_/ (_<__ Instead of theories to suit facts. -- Sherlock Holmes, "A Scandal in Bohemia" Arthur W. Neilson III, WH7N - FISTS #7448 Bank of Hawaii Network Services http://www.pilikia.net art@pilikia.net, aneilson@boh.com, wh7n@arrl.net 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 From owner-freebsd-stable Mon Jan 28 12:47:30 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mail.acns.ab.ca (mail.acns.ab.ca [142.179.151.95]) by hub.freebsd.org (Postfix) with ESMTP id 463FD37B404 for ; Mon, 28 Jan 2002 12:47:26 -0800 (PST) Received: from colnta.acns.ab.ca (colnta.acns.ab.ca [192.168.1.2]) by mail.acns.ab.ca (8.11.6/8.11.3) with ESMTP id g0SKlHV18812; Mon, 28 Jan 2002 13:47:17 -0700 (MST) (envelope-from davidc@colnta.acns.ab.ca) Received: (from davidc@localhost) by colnta.acns.ab.ca (8.11.6/8.11.3) id g0SKlHk66538; Mon, 28 Jan 2002 13:47:17 -0700 (MST) (envelope-from davidc) Date: Mon, 28 Jan 2002 13:47:17 -0700 From: Chad David To: "Jacques A. Vidrine" , freebsd-stable@FreeBSD.ORG Subject: Re: firewall config (CTFM) Message-ID: <20020128134717.F66369@colnta.acns.ab.ca> Mail-Followup-To: "Jacques A. Vidrine" , freebsd-stable@FreeBSD.ORG References: <20020128113806.O95859-100000@rockstar.stealthgeeks.net> <20020128132015.A66369@colnta.acns.ab.ca> <20020128203640.GB42996@madman.nectar.cc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020128203640.GB42996@madman.nectar.cc>; from n@nectar.cc on Mon, Jan 28, 2002 at 02:36:40PM -0600 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jan 28, 2002 at 02:36:40PM -0600, Jacques A. Vidrine wrote: > On Mon, Jan 28, 2002 at 01:20:15PM -0700, Chad David wrote: > > One of the things I would recommend documenting very clearly is that > > you DO NOT NEED TO COMPILE IPFW INTO THE KERNEL. > > Except if you want to default to deny, you must [1]. The rc system > loads the firewall after configuring your interfaces. This may be a > bug. Hmmm, possibly. But given that this is exactly the behavior that is being argued for I'm not sure I'd call it a bug. If you want rc.conf to be able to disable or enable the actual firewall code then this is something that you have to live with, unless it defaults to deny and when == "NO" is found it disables it, but the if you for some reason make a mistake you are locked out (which I like), and that was at least one of the problems people have had with the current way things work. -- Chad David davidc@acns.ab.ca www.FreeBSD.org davidc@freebsd.org ACNS Inc. Calgary, Alberta Canada Fourthly, The constant breeders, beside the gain of eight shillings sterling per annum by the sale of their children, will be rid of the charge of maintaining them after the first year. - Johnathan Swift To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 12:50:24 2002 Delivered-To: freebsd-stable@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 3364D37B41C for ; Mon, 28 Jan 2002 12:49:15 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id NAA05836; Mon, 28 Jan 2002 13:48:59 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0SKmvp70275; Mon, 28 Jan 2002 13:48:57 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15445.47417.195311.667565@caddis.yogotech.com> Date: Mon, 28 Jan 2002 13:48:57 -0700 To: "M. Warner Losh" Cc: nate@yogotech.com, ertr1013@student.uu.se, cjm2@earthling.net, charon@seektruth.org, dsyphers@uchicago.edu, stable@FreeBSD.ORG Subject: Re: Firewall config non-intuitiveness In-Reply-To: <20020128.134203.76273366.imp@village.org> References: <15445.44102.288461.155113@caddis.yogotech.com> <20020128.131414.49257581.imp@village.org> <15445.45720.514136.887062@caddis.yogotech.com> <20020128.134203.76273366.imp@village.org> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > : > : If I enable the clutch in my car, my car moves (assuming it's in gear). > : > : If I disable it, the power is no longer going to the drive wheels. > : > > : > That's not quite right, but it is a good analogy. If you disable your > : > clutch, then you are going to have to shift without it and deal with > : > putting it into gear at stops. > : > : Unfortunately, you can't do it w/out a clutch. (At least, not without > : tearing your clutch/transmission to bits). > > Yes, you can. Not unless you understand how things work in the engine. (The average car owner is not capable of shifting w/out a clutch, and even the most savvy of car owners is unable to *NOT* use a clutch when starting/stopping a car.) So, following that analogy, if I can read/understand how a kernel works, then I'm qualified to ignore the defaults, since I can make it do *whatever* I want it to. However, car manufacturers do not primarily build cars for those kinds of people, but instead build it (as well as document it) for an 'average' driver. > : > If you enable your clutch, then you > : > can use it to help in shifting. This isn't quite the same as what you > : > said, and an analogous condition exists with the firewall rules. > : > : "help in shifting"? I'd call a clutch the most critical part of a > : transmission. W/out a clutch, you don't have a transmission. > > I have seen people goe years w/o a functioning clutch. Randy Seager, > an old boss, didn't have a clutch in his 1974 trans-am for the three > years I worked for him. He had to match the gear speeds exactly to > shift at stoplights, but was able to do it. FWIW, he couldn't do that with a newer manual transmission. The synchro-mesh wouldn't allow you to shift in/out of gear at a stop. (And, I'm suprised it worked on his TA. My suspicion is that it was so worn out that it only worked b/c of wear.) > : > Also, when you enable apm, you aren't enabling power management. > : > : Sure you are. > : > : > That's done in the BIOS. You are enabling the OS using the power > : > management. > : > : If you don't enable apm in the OS, power management won't be done. It > : (the BIOS) sends the commands to the OS, which ignores them, and the > : BIOS does nothing. > : > : (It means that you can't shutdown the box automatically when the power > : gets low, etc...) > > That's not correct. I have had machines that did spin down disks, > even when the OS didn't enable the APM/ACPI interface. Again, that is completely different from my experience with the over a dozen laptops I've had in 7+ years. > : > It just fails to start sendmail, which is the default behavior for the > : > system. If you have sendmail_enable=NO, it doesn't go through and > : > delete the mail queue, or make it impossible to run sendmail from a > : > cron job. > : > : Who said anything about making anything impossible? Saying > : 'firewall_enable'=NO doesn't disable the system from using the firewall > : in the future. It doesn't recompile the kernel and remove the FIREWALL > : capability from the kernel, and/or delete ipfw.ko from the system. > : > : Now you're being silly. > > No. I'm being consistant. I refuse to respond anymore when then discussion has sunk to this level. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 12:51:57 2002 Delivered-To: freebsd-stable@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 0221737B400 for ; Mon, 28 Jan 2002 12:51:50 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g0SKpao19669; Mon, 28 Jan 2002 13:51:37 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g0SKpZx12569; Mon, 28 Jan 2002 13:51:36 -0700 (MST) (envelope-from imp@village.org) Date: Mon, 28 Jan 2002 13:51:20 -0700 (MST) Message-Id: <20020128.135120.11184725.imp@village.org> To: cjm2@earthling.net Cc: stable@freebsd.org, n@nectar.cc Subject: Re: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] From: "M. Warner Losh" In-Reply-To: <1913.216.153.202.59.1012249133.squirrel@www1.27in.tv> References: <20020128192930.GA86720@student.uu.se> <1913.216.153.202.59.1012249133.squirrel@www1.27in.tv> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <1913.216.153.202.59.1012249133.squirrel@www1.27in.tv> "C J Michaels" writes: : 1st off.. : Warner: Sorry for sending my earlier reply w/o reading the whole thread. : Jacques: Would the proposed change (below) still require approval from the : security officer? : : ====== : : In light of all the recent ipfw hubub, I think I have a equitable solution : for all. Most or all of these have been suggested by others, I am just : trying to put them into one consice proposal. : : This thread has really gotten out of control and I think, forked in the : wrong direction. Instead of changing the functionality of the knob, all we : should need to do is properly document the knob and (almost) everyone : should be happy. : : This is the situation as I see it: : 1. We have an option that is not intuitive to all, it's not even : intuitive to many, even Nate. :) : 2. Said knob has the potential to seriously degrade system security : if changed. : 2a. System security takes precidence to usability, at least with : something that can this seriously break a config. : 3. We have unclear documentation about said knob. : : I am going to propose the following changes: : 1. We rename the option to something like "firewall_load_rules" or : "firewall_enable_rules", etc... Someone else can come up with a : short yet more concise variable name. : 2. We grandfather in the old option of "firewall_enable" so existing : rc.conf(5)'s are not broken. : 2a. Obviously we are going to have a default in /etc/default/rc.conf : for this newly renamed knob. We should, in cases where : firewall_enable="YES", it should override the new knob. : 2b. At some point in the future, with much fanfare and documentation, : and probably messages to FreeBSD-Security-Advisories we phase out : the old option completely, so we don't keep a kludge in the system. : 3. Document said change in /etc/defaults/rc.conf and in rc.conf(5). : 4. Explicitly document the effect of both "YES" and "NO" in rc.conf(5). How about renaming things a little more: ipfw_load_rules={yes,no} ipfw_disable_firewall={yes,no} ipfw_kldload={yes,no} ipfw_load_rules would load ipfw rules, like firewall_enable does now. ipfw_disable_firewall breaks symetry on purpose, and would disable all ipfw functionality that may be compiled into the kernel. Since this is fairly explicit, it can default to no and if someone sets it to yes, they know what to expect without the current ambiguous situation (yes, it is ambiguous, which is why we're arguing about it). I know that all other foo_enable stuff uses the form foo_enable, but that is ambiguous in this case since there are two parts. ipfw_kldload would allow kld the ipfw.ko module. It would default to no. Note: There would be no ipfw_enable. We should then deprecate firewall_*. We have two firewall systems in the kernel (ipfw and ipfilter). We shouldn't be favoring one by calling it firewall and the other as ipfilter. No one is advocating disabling ipfilter also when firewall_enable=NO, are they? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 12:52:39 2002 Delivered-To: freebsd-stable@freebsd.org Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 464F637B419 for ; Mon, 28 Jan 2002 12:52:04 -0800 (PST) Received: from madman.nectar.cc (madman.nectar.cc [10.0.1.111]) by gw.nectar.cc (Postfix) with ESMTP id 2B5F158; Mon, 28 Jan 2002 14:52:03 -0600 (CST) Received: (from nectar@localhost) by madman.nectar.cc (8.11.6/8.11.6) id g0SKq3h43230; Mon, 28 Jan 2002 14:52:03 -0600 (CST) (envelope-from nectar) Date: Mon, 28 Jan 2002 14:52:03 -0600 From: "Jacques A. Vidrine" To: C J Michaels Cc: stable@freebsd.org, imp@village.org Subject: Re: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] Message-ID: <20020128205203.GE42996@madman.nectar.cc> References: <20020128192930.GA86720@student.uu.se> <1913.216.153.202.59.1012249133.squirrel@www1.27in.tv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1913.216.153.202.59.1012249133.squirrel@www1.27in.tv> User-Agent: Mutt/1.3.27i X-Url: http://www.nectar.cc/ Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jan 28, 2002 at 03:18:53PM -0500, C J Michaels wrote: > In light of all the recent ipfw hubub, I think I have a equitable solution > for all. Most or all of these have been suggested by others, I am just > trying to put them into one consice proposal. Thanks for the effort, CJ. > I am going to propose the following changes: > 1. We rename the option to something like "firewall_load_rules" or > "firewall_enable_rules", etc... Someone else can come up with a > short yet more concise variable name. I don't see any value in renaming the knob for -STABLE. Renaming it for -CURRENT might be useful. > 2. We grandfather in the old option of "firewall_enable" so existing > rc.conf(5)'s are not broken. It is easier to ensure no breakage by not renaming it. :-) Despite the chatter here, the current name has apparently caused little confusion in the over 2 years that it has been around. That's not to say that it shouldn't be better documented. > 2b. At some point in the future, with much fanfare and documentation, > and probably messages to FreeBSD-Security-Advisories we phase out > the old option completely, so we don't keep a kludge in the > system. Any requirement for fanfare and messages to security-notifications should be a red flag that the change was too disruptive. > 4. Explicitly document the effect of both "YES" and "NO" in rc.conf(5). By golly, I think you've got it. :-) For the record, I have no objection to renaming the knob in -STABLE as Security Officer. I do not believe that renaming will endanger any existing systems (/etc is untouched during upgrades unless the administrator does an explicit merge). However, as a committer and even as Joe User, I think it is an inappropriate change for the -STABLE branch. Cheers, -- Jacques A. Vidrine http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 12:56:11 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mail.acns.ab.ca (mail.acns.ab.ca [142.179.151.95]) by hub.freebsd.org (Postfix) with ESMTP id 5878237B400 for ; Mon, 28 Jan 2002 12:56:04 -0800 (PST) Received: from colnta.acns.ab.ca (colnta.acns.ab.ca [192.168.1.2]) by mail.acns.ab.ca (8.11.6/8.11.3) with ESMTP id g0SKu4V18855; Mon, 28 Jan 2002 13:56:04 -0700 (MST) (envelope-from davidc@colnta.acns.ab.ca) Received: (from davidc@localhost) by colnta.acns.ab.ca (8.11.6/8.11.3) id g0SKu3266563; Mon, 28 Jan 2002 13:56:03 -0700 (MST) (envelope-from davidc) Date: Mon, 28 Jan 2002 13:56:03 -0700 From: Chad David To: Nate Williams Cc: "M. Warner Losh" , ertr1013@student.uu.se, cjm2@earthling.net, charon@seektruth.org, dsyphers@uchicago.edu, stable@FreeBSD.ORG Subject: Transmissions :) Was: Firewall config non-intuitiveness Message-ID: <20020128135603.G66369@colnta.acns.ab.ca> Mail-Followup-To: Nate Williams , "M. Warner Losh" , ertr1013@student.uu.se, cjm2@earthling.net, charon@seektruth.org, dsyphers@uchicago.edu, stable@FreeBSD.ORG References: <1617.216.153.202.59.1012240332.squirrel@www1.27in.tv> <20020128192930.GA86720@student.uu.se> <15445.44102.288461.155113@caddis.yogotech.com> <20020128.131414.49257581.imp@village.org> <15445.45720.514136.887062@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15445.45720.514136.887062@caddis.yogotech.com>; from nate@yogotech.com on Mon, Jan 28, 2002 at 01:20:40PM -0700 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jan 28, 2002 at 01:20:40PM -0700, Nate Williams wrote: > > : If I enable the clutch in my car, my car moves (assuming it's in gear). > > : If I disable it, the power is no longer going to the drive wheels. > > > > That's not quite right, but it is a good analogy. If you disable your > > clutch, then you are going to have to shift without it and deal with > > putting it into gear at stops. > > Unfortunately, you can't do it w/out a clutch. (At least, not without > tearing your clutch/transmission to bits). No true :). While at a stop a clutch is a good idea, you can avoid ware on a number of parts if you learn to shift without clutch while moving. On smaller four and five speed transmissions (or bikes)this is actually quite easy... on 3 ton grain trucks and tractors its a little more tricky. > > > If you enable your clutch, then you > > can use it to help in shifting. This isn't quite the same as what you > > said, and an analogous condition exists with the firewall rules. > > "help in shifting"? I'd call a clutch the most critical part of a > transmission. W/out a clutch, you don't have a transmission. Perhaps, but in its purest form what do gears have to do with a transmission? Think torque converter or hydrostatic drive :). And to think I gave up being a heavy duty mechanic to do this... since its current ~ -20C outside I think I made the correct choice :). -- Chad David davidc@acns.ab.ca www.FreeBSD.org davidc@freebsd.org ACNS Inc. Calgary, Alberta Canada Fourthly, The constant breeders, beside the gain of eight shillings sterling per annum by the sale of their children, will be rid of the charge of maintaining them after the first year. - Johnathan Swift To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 12:57:29 2002 Delivered-To: freebsd-stable@freebsd.org Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 37E7C37B402 for ; Mon, 28 Jan 2002 12:57:22 -0800 (PST) Received: from madman.nectar.cc (madman.nectar.cc [10.0.1.111]) by gw.nectar.cc (Postfix) with ESMTP id C1CE258; Mon, 28 Jan 2002 14:57:21 -0600 (CST) Received: (from nectar@localhost) by madman.nectar.cc (8.11.6/8.11.6) id g0SKvL043250; Mon, 28 Jan 2002 14:57:21 -0600 (CST) (envelope-from nectar) Date: Mon, 28 Jan 2002 14:57:21 -0600 From: "Jacques A. Vidrine" To: "M. Warner Losh" Cc: cjm2@earthling.net, stable@freebsd.org Subject: Re: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] Message-ID: <20020128205721.GF42996@madman.nectar.cc> References: <20020128192930.GA86720@student.uu.se> <1913.216.153.202.59.1012249133.squirrel@www1.27in.tv> <20020128.135120.11184725.imp@village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020128.135120.11184725.imp@village.org> User-Agent: Mutt/1.3.27i X-Url: http://www.nectar.cc/ Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jan 28, 2002 at 01:51:20PM -0700, M. Warner Losh wrote: > How about renaming things a little more: I almost wrote in another message that should someone decide to rename the knob, I hope that they will take into account the entire rc system and make sure that the names are consistent. If `firewall_enable' can be improved upon, I'm sure other knobs can, too. > ipfw_load_rules={yes,no} > ipfw_disable_firewall={yes,no} > ipfw_kldload={yes,no} > > ipfw_load_rules would load ipfw rules, like firewall_enable does now. > ipfw_disable_firewall breaks symetry on purpose, and would disable all > ipfw functionality that may be compiled into the kernel. Since this > is fairly explicit, it can default to no and if someone sets it to > yes, they know what to expect without the current ambiguous situation > (yes, it is ambiguous, which is why we're arguing about it). I know > that all other foo_enable stuff uses the form foo_enable, but that > is ambiguous in this case since there are two parts. This is why I think all the names need to be re-examined. A better scheme would probably result. What we have is (IMHO) sufficient ... but there is room for improvement. > ipfw_kldload would allow kld the ipfw.ko module. It would default to > no. There could be a whole series of such knobs, parallel to those we use in /boot/defaults/loader.conf. > Note: There would be no ipfw_enable. > > We should then deprecate firewall_*. We have two firewall systems in > the kernel (ipfw and ipfilter). We shouldn't be favoring one by > calling it firewall and the other as ipfilter. No one is advocating > disabling ipfilter also when firewall_enable=NO, are they? Yeah, no kidding. I use ipfilter. ;-) Cheers, -- Jacques A. Vidrine http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 12:59:53 2002 Delivered-To: freebsd-stable@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 0D02C37B416 for ; Mon, 28 Jan 2002 12:59:45 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g0SKxho19772; Mon, 28 Jan 2002 13:59:43 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g0SKxgx12639; Mon, 28 Jan 2002 13:59:42 -0700 (MST) (envelope-from imp@village.org) Date: Mon, 28 Jan 2002 13:59:23 -0700 (MST) Message-Id: <20020128.135923.16493900.imp@village.org> To: nate@yogotech.com Cc: stable@FreeBSD.ORG Subject: Re: Firewall config non-intuitiveness From: "M. Warner Losh" In-Reply-To: <15445.47417.195311.667565@caddis.yogotech.com> References: <15445.45720.514136.887062@caddis.yogotech.com> <20020128.134203.76273366.imp@village.org> <15445.47417.195311.667565@caddis.yogotech.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <15445.47417.195311.667565@caddis.yogotech.com> Nate Williams writes: : (And, I'm suprised it worked on his TA. My suspicion is that it was so : worn out that it only worked b/c of wear.) I just know what he did. His clutch did nothing, but this is getting fairly off topic. He was able to gun the engine a little, and slide it into second at stop lights, then lug the engine through it. It was the strangest thing that I ever saw... : > : > Also, when you enable apm, you aren't enabling power management. : > : : > : Sure you are. : > : : > : > That's done in the BIOS. You are enabling the OS using the power : > : > management. : > : : > : If you don't enable apm in the OS, power management won't be done. It : > : (the BIOS) sends the commands to the OS, which ignores them, and the : > : BIOS does nothing. : > : : > : (It means that you can't shutdown the box automatically when the power : > : gets low, etc...) : > : > That's not correct. I have had machines that did spin down disks, : > even when the OS didn't enable the APM/ACPI interface. : : Again, that is completely different from my experience with the over a : dozen laptops I've had in 7+ years. I have a machine that does this. My Dell Inspiron 8000. The reason that it does this is because the disk spinning down has nothing to do with APM. The BIOS tells the disk to spin down when it has been idle for 30s. When FreeBSD boots, it doesn't give orders to the contrary, so it still spins down when it has been idle for 30s, regardless of FreeBSD's APM or ACPI use. I've commented on how I think that it should be in other mail. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 13: 1:39 2002 Delivered-To: freebsd-stable@freebsd.org Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id DD88C37B402 for ; Mon, 28 Jan 2002 13:01:28 -0800 (PST) Received: from madman.nectar.cc (madman.nectar.cc [10.0.1.111]) by gw.nectar.cc (Postfix) with ESMTP id 743304C for ; Mon, 28 Jan 2002 15:01:28 -0600 (CST) Received: (from nectar@localhost) by madman.nectar.cc (8.11.6/8.11.6) id g0SL1SS43269 for freebsd-stable@FreeBSD.ORG; Mon, 28 Jan 2002 15:01:28 -0600 (CST) (envelope-from nectar) Date: Mon, 28 Jan 2002 15:01:28 -0600 From: "Jacques A. Vidrine" To: freebsd-stable@FreeBSD.ORG Subject: Re: firewall config (CTFM) Message-ID: <20020128210128.GG42996@madman.nectar.cc> Mail-Followup-To: "Jacques A. Vidrine" , freebsd-stable@FreeBSD.ORG References: <20020128113806.O95859-100000@rockstar.stealthgeeks.net> <20020128132015.A66369@colnta.acns.ab.ca> <20020128203640.GB42996@madman.nectar.cc> <20020128134717.F66369@colnta.acns.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020128134717.F66369@colnta.acns.ab.ca> User-Agent: Mutt/1.3.27i X-Url: http://www.nectar.cc/ Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jan 28, 2002 at 01:47:17PM -0700, Chad David wrote: > On Mon, Jan 28, 2002 at 02:36:40PM -0600, Jacques A. Vidrine wrote: > > On Mon, Jan 28, 2002 at 01:20:15PM -0700, Chad David wrote: > > > One of the things I would recommend documenting very clearly is that > > > you DO NOT NEED TO COMPILE IPFW INTO THE KERNEL. > > > > Except if you want to default to deny, you must [1]. The rc system > > loads the firewall after configuring your interfaces. This may be a > > bug. > > Hmmm, possibly. But given that this is exactly the behavior that is > being argued for I'm not sure I'd call it a bug. I'm not sure you understood what I meant (I should have written `firewall module' rather than `firewall' above). It could be called a bug for network interfaces to be activated before the network security policy has been set. > If you want rc.conf > to be able to disable or enable the actual firewall code then this is > something that you have to live with, unless it defaults to deny and when > == "NO" is found it disables it, but the if you for some reason make a > mistake you are locked out (which I like), and that was at least one of > the problems people have had with the current way things work. I'm sorry, I don't follow you. Cheers, -- Jacques A. Vidrine http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 13: 2:46 2002 Delivered-To: freebsd-stable@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 26A3037B41B; Mon, 28 Jan 2002 13:02:26 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id OAA06389; Mon, 28 Jan 2002 14:02:21 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0SL2KI70409; Mon, 28 Jan 2002 14:02:20 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15445.48220.670641.705228@caddis.yogotech.com> Date: Mon, 28 Jan 2002 14:02:20 -0700 To: Chad David Cc: Nate Williams , "M. Warner Losh" , chat@FreeBSD.ORG Subject: Re: Transmissions :) Was: Firewall config non-intuitiveness In-Reply-To: <20020128135603.G66369@colnta.acns.ab.ca> References: <1617.216.153.202.59.1012240332.squirrel@www1.27in.tv> <20020128192930.GA86720@student.uu.se> <15445.44102.288461.155113@caddis.yogotech.com> <20020128.131414.49257581.imp@village.org> <15445.45720.514136.887062@caddis.yogotech.com> <20020128135603.G66369@colnta.acns.ab.ca> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [ This is getting way off topic, so I've moved this to -chat ] > > > : If I enable the clutch in my car, my car moves (assuming it's in gear). > > > : If I disable it, the power is no longer going to the drive wheels. > > > > > > That's not quite right, but it is a good analogy. If you disable your > > > clutch, then you are going to have to shift without it and deal with > > > putting it into gear at stops. > > > > Unfortunately, you can't do it w/out a clutch. (At least, not without > > tearing your clutch/transmission to bits). > > No true :). While at a stop a clutch is a good idea, you can avoid > ware on a number of parts if you learn to shift without clutch while > moving. Actually, the wear you save on the clutch (which is designed for this) will be translated to the gears in the transmission. Very few (!!) people are capable of shifting w/out a clutch and *NOT* doing damage to the gears. Hence the reason for a clutch. > On smaller four and five speed transmissions (or bikes)this is > actually quite easy... on 3 ton grain trucks and tractors its a little > more tricky. Actually, on grain trucks it's *easier*. (Speaking with 15 years of experience driving them. :) :) :) On the smaller cars, the synchro-mesh setup on the gears makes it *much* harder to do it cleanly, while on big grain trucks and bikes, it's easier since they don't add such things since they are mostly un-necessary. (And, not using a clutch is more common.) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 13: 9:10 2002 Delivered-To: freebsd-stable@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 803C637B400 for ; Mon, 28 Jan 2002 13:09:02 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id OAA06645; Mon, 28 Jan 2002 14:08:58 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0SL8w070437; Mon, 28 Jan 2002 14:08:58 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15445.48617.802871.870971@caddis.yogotech.com> Date: Mon, 28 Jan 2002 14:08:57 -0700 To: "M. Warner Losh" Cc: cjm2@earthling.net, stable@FreeBSD.ORG, n@nectar.cc Subject: Re: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] In-Reply-To: <20020128.135120.11184725.imp@village.org> References: <20020128192930.GA86720@student.uu.se> <1913.216.153.202.59.1012249133.squirrel@www1.27in.tv> <20020128.135120.11184725.imp@village.org> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > How about renaming things a little more: > > ipfw_load_rules={yes,no} > ipfw_disable_firewall={yes,no} > ipfw_kldload={yes,no} I don't mind the first two, but I dislike the third for the following reasons. 1) We are moving (slowly) to a kernel where things are loaded 'automagically'. In other words, the user shouldn't have to explicitly load a module if it's being used. (All of the network adapters are moving in this direction.) 2) If possible (I've not analyzed this), it would be nice that if the firewall is 'enabled' (second variable), the script would determine *IF* the firewall module is in the kernel or not (like is done with the current network adapter modules), and if not, load it. This obviates the need for the third rule. That being said, I'd argue for a rename of rule 2 to 'ipfw_enable_firewall', which when set to 'YES', loads the firewall capability (if necessary) and ensures that it's sysctl is set correctly. If set to NO, simply disables the sysctl if it exists (no need to unload the module in the startup scripts, IMO). The default behavior of the firewall would be related to how it was configured statically in the kernel, or how the module was created. No more confusion. (Also, another reason for 'enable' vs. 'disable' is it's more connsistent with the other variables we are using in the rc.conf file.) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 13:12:46 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mail.acns.ab.ca (mail.acns.ab.ca [142.179.151.95]) by hub.freebsd.org (Postfix) with ESMTP id 7C36937B417 for ; Mon, 28 Jan 2002 13:12:43 -0800 (PST) Received: from colnta.acns.ab.ca (colnta.acns.ab.ca [192.168.1.2]) by mail.acns.ab.ca (8.11.6/8.11.3) with ESMTP id g0SLCcV18914; Mon, 28 Jan 2002 14:12:38 -0700 (MST) (envelope-from davidc@colnta.acns.ab.ca) Received: (from davidc@localhost) by colnta.acns.ab.ca (8.11.6/8.11.3) id g0SLCcA66606; Mon, 28 Jan 2002 14:12:38 -0700 (MST) (envelope-from davidc) Date: Mon, 28 Jan 2002 14:12:38 -0700 From: Chad David To: "Jacques A. Vidrine" Cc: freebsd-stable@FreeBSD.ORG Subject: Re: firewall config (CTFM) Message-ID: <20020128141238.H66369@colnta.acns.ab.ca> Mail-Followup-To: "Jacques A. Vidrine" , freebsd-stable@FreeBSD.ORG References: <20020128113806.O95859-100000@rockstar.stealthgeeks.net> <20020128132015.A66369@colnta.acns.ab.ca> <20020128203640.GB42996@madman.nectar.cc> <20020128134717.F66369@colnta.acns.ab.ca> <20020128210128.GG42996@madman.nectar.cc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020128210128.GG42996@madman.nectar.cc>; from n@nectar.cc on Mon, Jan 28, 2002 at 03:01:28PM -0600 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jan 28, 2002 at 03:01:28PM -0600, Jacques A. Vidrine wrote: > On Mon, Jan 28, 2002 at 01:47:17PM -0700, Chad David wrote: > > On Mon, Jan 28, 2002 at 02:36:40PM -0600, Jacques A. Vidrine wrote: > > > On Mon, Jan 28, 2002 at 01:20:15PM -0700, Chad David wrote: > > > > One of the things I would recommend documenting very clearly is that > > > > you DO NOT NEED TO COMPILE IPFW INTO THE KERNEL. > > > > > > Except if you want to default to deny, you must [1]. The rc system > > > loads the firewall after configuring your interfaces. This may be a > > > bug. > > > > Hmmm, possibly. But given that this is exactly the behavior that is > > being argued for I'm not sure I'd call it a bug. > > I'm not sure you understood what I meant (I should have written > `firewall module' rather than `firewall' above). It could be called a > bug for network interfaces to be activated before the network security > policy has been set. Yes, I understood you... its was I who was unclear. Basically I was agree with you :). -- Chad David davidc@acns.ab.ca www.FreeBSD.org davidc@freebsd.org ACNS Inc. Calgary, Alberta Canada Fourthly, The constant breeders, beside the gain of eight shillings sterling per annum by the sale of their children, will be rid of the charge of maintaining them after the first year. - Johnathan Swift To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 13:23:22 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mail.27in.tv (roc-66-24-112-7.rochester.rr.com [66.24.112.7]) by hub.freebsd.org (Postfix) with ESMTP id 36FA837B402 for ; Mon, 28 Jan 2002 13:23:16 -0800 (PST) Received: (from root@localhost) by mail.27in.tv (8.11.6/8.11.6) id g0SLNEo77633; Mon, 28 Jan 2002 16:23:14 -0500 (EST) (envelope-from cjm2@earthling.net) Received: from 27in.tv (roc-66-24-112-7.rochester.rr.com [66.24.112.7]) by mail.27in.tv (8.11.6/8.11.6av) with SMTP id g0SLNCU77609; Mon, 28 Jan 2002 16:23:12 -0500 (EST) (envelope-from cjm2@earthling.net) Received: from 216.153.202.59 (SquirrelMail authenticated user cjm2) by www1.27in.tv with HTTP; Mon, 28 Jan 2002 16:23:12 -0500 (EST) Message-ID: <2403.216.153.202.59.1012252992.squirrel@www1.27in.tv> Date: Mon, 28 Jan 2002 16:23:12 -0500 (EST) Subject: Re: Proposed Solution To Recent 'firewall_enable' Thread. [Please Read] From: "C J Michaels" To: In-Reply-To: <20020128205203.GE42996@madman.nectar.cc> References: <20020128205203.GE42996@madman.nectar.cc> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal Cc: X-Mailer: SquirrelMail (version 1.2.5 [cvs]) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by AMaViS perl-11 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Jacques A. Vidrine said: > On Mon, Jan 28, 2002 at 03:18:53PM -0500, C J Michaels wrote: >> In light of all the recent ipfw hubub, I think I have a equitable >> solution for all. Most or all of these have been suggested by others, >> I am just trying to put them into one consice proposal. > > Thanks for the effort, CJ. > >> I am going to propose the following changes: >> 1. We rename the option to something like "firewall_load_rules" or >> "firewall_enable_rules", etc... Someone else can come up with a >> short yet more concise variable name. > > I don't see any value in renaming the knob for -STABLE. Renaming it > for -CURRENT might be useful. > Agreed, I forgot to mention this, but it was my intent. Unfortunately this seems to be happening more frequently as of late. >> 2. We grandfather in the old option of "firewall_enable" so existing >> rc.conf(5)'s are not broken. > > It is easier to ensure no breakage by not renaming it. :-) Despite the > chatter here, the current name has apparently caused little confusion > in the over 2 years that it has been around. > > That's not to say that it shouldn't be better documented. > >> 2b. At some point in the future, with much fanfare and documentation, >> and probably messages to FreeBSD-Security-Advisories we phase out >> the old option completely, so we don't keep a kludge in the >> system. > > Any requirement for fanfare and messages to security-notifications > should be a red flag that the change was too disruptive. Good point... I'm a bit torn as I believe this would be a beneficial change overall, but I am not fond of kludges in the base OS of any sort, it add more overhead and allows for configs that are easily broken, but not easily repaired when the kludge is gone. Hence my suggestion for fanfare. I'd prefer to not have the kludge at all, which I would believe is acceptable if this change didn't occur until 5.0 was released. > >> 4. Explicitly document the effect of both "YES" and "NO" in >> rc.conf(5). > > By golly, I think you've got it. :-) > Isn't it amazing what a mess one little question can make. :) > > For the record, I have no objection to renaming the knob in -STABLE as > Security Officer. I do not believe that renaming will endanger any > existing systems (/etc is untouched during upgrades unless the > administrator does an explicit merge). However, as a committer and > even as Joe User, I think it is an inappropriate change for the > -STABLE branch. Agreed again. I do think that this generated enough noise, even if it took 2 years to crop up, to point out that the current variables, and maybe even the whole rc.conf(5) could use an overhaul (as noted on your reply to Warner's other message). Mind you that sounds like quite an undertaking. The thing we have to consider here is that it's not "us", the people (Joe Experienced) who have working ipfw configurations, who understand the meaning of firewall_enable through trial and error, that would gain from this change. It is people who are either new to FreeBSD, or at least new to using ipfw (Joe Newbee) that stand to gain the most from this. Thanks! P.S. Has anyone worked on PR's to update the current documenation? > > Cheers, > -- > Jacques A. Vidrine http://www.nectar.cc/ > NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos > jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se -- Chris "I'll defend to the death your right to say that, but I never said I'd listen to it!" -- Tom Galloway with apologies to Voltaire To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 13:27:15 2002 Delivered-To: freebsd-stable@freebsd.org Received: from rockstar.stealthgeeks.net (h-66-134-120-173.LSANCA54.covad.net [66.134.120.173]) by hub.freebsd.org (Postfix) with SMTP id 535F437B400 for ; Mon, 28 Jan 2002 13:27:13 -0800 (PST) Received: (qmail 97968 invoked by uid 1001); 28 Jan 2002 21:27:13 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 28 Jan 2002 21:27:13 -0000 Date: Mon, 28 Jan 2002 13:27:12 -0800 (PST) From: Patrick Greenwell To: C J Michaels Cc: n@nectar.cc, Subject: Re: Proposed Solution To Recent 'firewall_enable' Thread. [Please Read] In-Reply-To: <2403.216.153.202.59.1012252992.squirrel@www1.27in.tv> Message-ID: <20020128132552.F97943-100000@rockstar.stealthgeeks.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 28 Jan 2002, C J Michaels wrote: > Thanks! > > P.S. Has anyone worked on PR's to update the current documenation? I'm going to submit proposed changes to Chad who indicated that he will possibly commit them. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Patrick Greenwell Stealthgeeks,LLC. Operations Consulting http://www.stealthgeeks.net \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 13:30:49 2002 Delivered-To: freebsd-stable@freebsd.org Received: from [208.237.133.234] (mail.ade.com [208.237.133.234]) by hub.freebsd.org (Postfix) with SMTP id BDF5B37B49A for ; Mon, 28 Jan 2002 13:30:32 -0800 (PST) Received: from no.name.available by [208.237.133.234] via smtpd (for hub.FreeBSD.org [216.136.204.18]) with SMTP; 28 Jan 2002 21:30:32 UT Received: (private information removed) Message-ID: From: Chris Corayer To: "'stable@FreeBSD.ORG'" Subject: RE: stable-digest V5 #417 Date: Mon, 28 Jan 2002 16:31:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ----------------------------------------------- |Date: Mon, 28 Jan 2002 19:48:09 +0100 |From: Jesus Climent |Subject: xf86cfg segfaults in 4.5-RC3 | |Port: XFree86 4.1 (under 4.5-RC3) |Problem: xf86cfg segfaults. |System: Fujitsu x365. Integrated ATI Rage Pro. |Description: | |After installing the system I installed the port XFree86: | |XFree86-4.1.0_12,1 X11R6.5/XFree86 core distribution (complete) |XFree86-Server-4.1.0_4 XFree86-4 X server and related programs |XFree86-clients-4.1.0_2 XFree86-4 Client environments |XFree86-font100dpi-4.1.0 XFree86-4 bitmap 100 dpi fonts |XFree86-fontEncodings-4.1.0 XFree86-4 font encoding files |XFree86-fontScalable-4.1.0 XFree86-4 Scalable font files |XFree86-libraries-4.1.0_1 XFree86-4 include/(shared) library kit | |Trying to configure it with xf86cfg opens the XWindow system, starts the |application and after few seconds it suddenly crashes, without moving |anything. | |Checked also in another computer with the same result. | |J. | ------------------------------ FWIW. I've tried installing this on an AlphaServer 800 using 4-Release ( Generic kernel ). Compile and install give no problems. When running xf86cfg it crashes it as well, all the way down to SRM. I can run the shell based config, but then the same crash down to SRM happens when I run startx. The only recourse is power down and restart or boot dka0. The system does not apparently have time to write any errors or core dump. Upon a restart/reboot the system does not even bother to fsck the disks, which I find odd as well. I'm still having issues with XFree86 3.3.6 and xdm, but that's another issue altogether... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 14: 6: 1 2002 Delivered-To: freebsd-stable@freebsd.org Received: from smtp.noos.fr (zola.noos.net [212.198.2.76]) by hub.freebsd.org (Postfix) with ESMTP id EFDC037B404 for ; Mon, 28 Jan 2002 14:05:49 -0800 (PST) Received: (qmail 48665634 invoked by uid 0); 28 Jan 2002 22:05:33 -0000 Received: from unknown (HELO atheria.ptijo.net) ([195.132.200.187]) (envelope-sender ) by 212.198.2.76 (qmail-ldap-1.03) with SMTP for ; 28 Jan 2002 22:05:33 -0000 Date: Mon, 28 Jan 2002 23:05:31 +0100 From: ptiJo To: freebsd-stable@FreeBSD.ORG Cc: freebsd-questions@FreeBSD.ORG Subject: divers SCSI questions... Message-Id: <20020128230531.20f8d55b.ptiJo@noos.fr> X-Mailer: Sylpheed version 0.6.5 (GTK+ 1.2.10; i386--freebsd4.4) User-Agent: X-Face: X-Operating-System: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, as I never played with SCSI and get an old PCI Card, I would like to be enlightened a bit :) so, I got the "Adaptec AHA-2940UW" which specs are: Computer Bus: PCI Local Bus Interface Protocol: Bus master DMA Host Bus Burst Data Rate: 133 MByte/sec Peripheral Bus: 8-bit and 16-bit Wide UltraSCSI SCSI Synchronous Data Rate: 40 MByte/sec SCSI Asynchronous Data Rate: 3.3 MByte/sec Device Protocol: SCSI-1, SCSI-2, SCSI-3, Wide UltraSCSI Device Support: Up to 15 devices under DOS 5.0 and above Here are the questions :) -1- does the data rates specify that, in general, the transfer rate is 3.3 MBytes/sec ? -2- 15 devices under DOS... would it be more under FreeBSD ? is there also a limitation on total size that I would get (15*36Go or 15*9Go, for eg) ? I would like to buy disks now :) IBM 36 Go 10000 RPM SCSI IBM 18 Go 10000 RPM SCSI IBM 9 Go 10000 RPM SCSI -3- do I have to take special care ? I mean, the supported device protocol are SCSI-{1,2,3} and Wide - do all disks (like those recent above) supports @least one of them ? Or do I have to check the disks specs to see which protocol they support ? thX a lot for answers, --------------------- ptiJo Linux: For those who don't like Windows *BSD: For those who like UNIX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 14:12:11 2002 Delivered-To: freebsd-stable@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 9A46937B404 for ; Mon, 28 Jan 2002 14:12:00 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g0SMBuo20229; Mon, 28 Jan 2002 15:11:56 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g0SMBrx13118; Mon, 28 Jan 2002 15:11:55 -0700 (MST) (envelope-from imp@village.org) Date: Mon, 28 Jan 2002 15:11:38 -0700 (MST) Message-Id: <20020128.151138.115627568.imp@village.org> To: nate@yogotech.com Cc: cjm2@earthling.net, stable@FreeBSD.ORG, n@nectar.cc Subject: Re: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] From: "M. Warner Losh" In-Reply-To: <15445.48617.802871.870971@caddis.yogotech.com> References: <1913.216.153.202.59.1012249133.squirrel@www1.27in.tv> <20020128.135120.11184725.imp@village.org> <15445.48617.802871.870971@caddis.yogotech.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I'm most worried about the case where you have compiled ipfw into the kernel. When you do that, the default is don't route anything. I want to preserve that. Loading ipfw is less secure than having it in the kernel, since there's a window at boot that packets can pass. The problem with ipfw now is that if you don't have the default deny rule, there's a small window where you have packets passed. ipfilter is done much sooner in the boot process, so doesn't appear to suffer from this vulnerability. If possible, we should move ipfw to the same location as ipfilter (I suspect that it isn't there for some reason). We'd also need to change ipfilter rules as well. It doesn't defaults to blocking everything and if you set ipfilter_enable to NO, you get that same behavior. The ipfilter stuff also will blindly try to load the ipfilter rules, even if ipfilter isn't in the kernel and can't be loaded. So leaving that aside for the moment, returning to ipfw stuff. firewall_enable is really firewall_rules_enable at the moment. Looking at the code closely, we see things like: case ${firewall_in_kernel} in 1) ... (indentation <<) case ${firewall_enable} in [Yy][Ee][Ss]) if [ -r "${firewall_script}" ]; then ... elif [ "`ipfw l 65535`" = "65535 deny ip from any to any" ]; then echo 'Warning: kernel has firewall functionality,' \ 'but firewall rules are not enabled.' echo ' All ip services are disabled.' fi ... ;; esac ;; esac My understanding of what I want and what you want, rendered in code excerpt form is: # Initialize IP filtering using ipfw # if /sbin/ipfw -q flush > /dev/null 2>&1; then ipfw_in_kernel=1 else ipfw_in_kernel=0 fi case ${ipfw_enable} in [Yy][Ee][Ss]) if [ "${ipfw_in_kernel}" -eq 0 ] && kldload ipfw; then ipfw_in_kernel=1 echo 'Kernel firewall module loaded' elif [ "${ipfw_in_kernel}" -eq 0 ]; then echo 'Warning: firewall kernel module failed to load' fi ;; esac case ${ipfw_in_kernel} in 1) ... (indentation <<) case ${ipfw_firewall_enable} in *) if [ -r "${ipfw_script}" ]; then ... elif [ "`ipfw l 65535`" = "65535 deny ip from any to any" ]; then echo 'Warning: kernel has firewall functionality,' \ 'but firewall rules are not enabled.' echo ' All ip services are disabled.' fi ... ;; [Nn][oO]) echo 'Warning: kernel has firewall functionality,' \ 'but user disabled it in /etc/rc.conf' echo ' All ip services are ENABLED' sysctl ... # turn off ipfw via sysctl ;; esac Is that right? Forget my old proposal for the moment (and do a s/firewall/ipfw/ on all the current firewall_ variables not specifically mentioned). We'd introduce a ipfw_firewall_enable. /etc/defaults/rc.conf would have: ipfw_enable=no ipfw_firewall_enable=yes Or in less shellese pseudo-code: in-kernel=`ask the kernel if there's ipfw` if !in-kenrel && ipfw_enable == yes load ipfw in-kernel=true endif if in-kenrel if ipfw_firewall_enable == no turn off ipfw else load rules, natd, etc. endif endif ipfw_enable == Load ipfw if it isn't in the kernel. ipfw_firewall_eanble == turn ipfw on/off if it is in the kenrel. Comments? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 14:27:49 2002 Delivered-To: freebsd-stable@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id EA12E37B425 for ; Mon, 28 Jan 2002 14:26:47 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id PAA09718; Mon, 28 Jan 2002 15:26:44 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0SMQi071017; Mon, 28 Jan 2002 15:26:44 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15445.53283.957773.221016@caddis.yogotech.com> Date: Mon, 28 Jan 2002 15:26:43 -0700 To: "M. Warner Losh" Cc: nate@yogotech.com, cjm2@earthling.net, stable@FreeBSD.ORG, n@nectar.cc Subject: Re: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] In-Reply-To: <20020128.151138.115627568.imp@village.org> References: <1913.216.153.202.59.1012249133.squirrel@www1.27in.tv> <20020128.135120.11184725.imp@village.org> <15445.48617.802871.870971@caddis.yogotech.com> <20020128.151138.115627568.imp@village.org> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I'm most worried about the case where you have compiled ipfw into the > kernel. When you do that, the default is don't route anything. I > want to preserve that. That's a tricky one. If we make the default to 'YES' (to preserve the current behavior of enabled firewall in compiled in kernels), then the firewall would get loaded by default on *every* setup, even if they are currently not using a kernel. > Loading ipfw is less secure than having it in the kernel, since > there's a window at boot that packets can pass. Except on those machines who don't use a 'standard' ipfw setup. IMO, using the existing configuration/rc.conf setup, it's hard to get a secure setup. You have to either modify /etc/rc.firewall (bad, since you have to carefully merge in any mergemaster updates), or you have to build your own customized scripts (again, that means you have to hand-merge any updates to the stock /etc/rc.firewall.) In short, the current 'status quo' doesn't work well for any but the most simple firewall setup (using NAT). And, the default setup is both ineffecient as well as insecure, IMO. (However, it's hard to be all things to all people, because each firewall really needs to be customized for the user's particular setup, hence some of the problems.) > The problem with ipfw > now is that if you don't have the default deny rule, there's a small > window where you have packets passed. ipfilter is done much sooner in > the boot process, so doesn't appear to suffer from this > vulnerability. If possible, we should move ipfw to the same location > as ipfilter (I suspect that it isn't there for some reason). Agreed. What needs to occur is the firewall needs to be loaded *before* the network devices are configured, to avoid this. Although, there is still a *small* chance of something bad happen w/regards to ARP/DHCP and/or broadcast packets. I'm not sure how paranoid we should be here. > We'd also need to change ipfilter rules as well. It doesn't defaults > to blocking everything and if you set ipfilter_enable to NO, you get > that same behavior. *urk* > The ipfilter stuff also will blindly try to load the ipfilter rules, > even if ipfilter isn't in the kernel and can't be loaded. Ahh, so we'd be doing the same (broken) thing for ipfw. At least it would be consistent. :) :) > So leaving that aside for the moment, returning to ipfw stuff. > firewall_enable is really firewall_rules_enable at the moment. > Looking at the code closely, we see things like: > > case ${firewall_in_kernel} in > 1) > ... (indentation <<) > case ${firewall_enable} in > [Yy][Ee][Ss]) > if [ -r "${firewall_script}" ]; then > ... > elif [ "`ipfw l 65535`" = "65535 deny ip from any to any" ]; then > echo 'Warning: kernel has firewall functionality,' \ > 'but firewall rules are not enabled.' > echo ' All ip services are disabled.' > fi > ... > ;; > esac > ;; > esac > > My understanding of what I want and what you want, rendered in code > excerpt form is: > > # Initialize IP filtering using ipfw > # > if /sbin/ipfw -q flush > /dev/null 2>&1; then > ipfw_in_kernel=1 > else > ipfw_in_kernel=0 > fi > > case ${ipfw_enable} in > [Yy][Ee][Ss]) > if [ "${ipfw_in_kernel}" -eq 0 ] && kldload ipfw; then > ipfw_in_kernel=1 > echo 'Kernel firewall module loaded' > elif [ "${ipfw_in_kernel}" -eq 0 ]; then > echo 'Warning: firewall kernel module failed to load' > fi > ;; > esac This loads things automagically if 'firewall is enabled', and does nothing if if the 'firewall isn't enabled'. > case ${ipfw_in_kernel} in > 1) > ... (indentation <<) > case ${ipfw_firewall_enable} in All of the above is just safety code. > *) > if [ -r "${ipfw_script}" ]; then > ... > elif [ "`ipfw l 65535`" = "65535 deny ip from any to any" ]; then > echo 'Warning: kernel has firewall functionality,' \ > 'but firewall rules are not enabled.' > echo ' All ip services are disabled.' > fi Which doesn't help much if you are not sitting at the console, but you be seen once you login and check the logfiles. (Been there, done that, hence the reason for my passioned opinions on this subject. :) > ... > ;; > [Nn][oO]) > echo 'Warning: kernel has firewall functionality,' \ > 'but user disabled it in /etc/rc.conf' > echo ' All ip services are ENABLED' > sysctl ... # turn off ipfw via sysctl > ;; > esac > > Is that right? Forget my old proposal for the moment (and do a > s/firewall/ipfw/ on all the current firewall_ variables not > specifically mentioned). We'd introduce a ipfw_firewall_enable. > > /etc/defaults/rc.conf would have: > > ipfw_enable=no > ipfw_firewall_enable=yes > > Or in less shellese pseudo-code: > in-kernel=`ask the kernel if there's ipfw` > if !in-kenrel && ipfw_enable == yes > load ipfw > in-kernel=true > endif > if in-kenrel > if ipfw_firewall_enable == no > turn off ipfw > else > load rules, natd, etc. > endif > endif > if in-kenrel > if ipfw_firewall_enable == no > turn off ipfw > else > load rules, natd, etc. > endif > endif > > ipfw_enable == Load ipfw if it isn't in the kernel. > ipfw_firewall_eanble == turn ipfw on/off if it is in the kenrel. > > Comments? Except the chicken/egg problem, I'm not sure how to get the old 'default' functionality and still allow someone to easily 'disable' the kernel. (Again, I don't care for the ipfw_firewall_disable variable. Also, the name is a bit redundant, but now I'm picking nits. :) :) :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 14:37:32 2002 Delivered-To: freebsd-stable@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 094B337B402 for ; Mon, 28 Jan 2002 14:37:26 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g0SMbLo20374; Mon, 28 Jan 2002 15:37:22 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g0SMbKx13269; Mon, 28 Jan 2002 15:37:20 -0700 (MST) (envelope-from imp@village.org) Date: Mon, 28 Jan 2002 15:37:04 -0700 (MST) Message-Id: <20020128.153704.109572342.imp@village.org> To: nate@yogotech.com Cc: cjm2@earthling.net, stable@FreeBSD.ORG, n@nectar.cc Subject: Re: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] From: "M. Warner Losh" In-Reply-To: <15445.53283.957773.221016@caddis.yogotech.com> References: <15445.48617.802871.870971@caddis.yogotech.com> <20020128.151138.115627568.imp@village.org> <15445.53283.957773.221016@caddis.yogotech.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <15445.53283.957773.221016@caddis.yogotech.com> Nate Williams writes: : > My understanding of what I want and what you want, rendered in code : > excerpt form is: : > : > # Initialize IP filtering using ipfw : > # : > if /sbin/ipfw -q flush > /dev/null 2>&1; then : > ipfw_in_kernel=1 : > else : > ipfw_in_kernel=0 : > fi : > : > case ${ipfw_enable} in : > [Yy][Ee][Ss]) : > if [ "${ipfw_in_kernel}" -eq 0 ] && kldload ipfw; then : > ipfw_in_kernel=1 : > echo 'Kernel firewall module loaded' : > elif [ "${ipfw_in_kernel}" -eq 0 ]; then : > echo 'Warning: firewall kernel module failed to load' : > fi : > ;; : > esac : : This loads things automagically if 'firewall is enabled', and does : nothing if if the 'firewall isn't enabled'. No. It says if ipfw is enable, and not in the kernel, load it. : > case ${ipfw_in_kernel} in : > 1) : > ... (indentation <<) : > case ${ipfw_firewall_enable} in : : All of the above is just safety code. This says that "I know that I have IPFW in the kernel, but I want to disable its firewall functionality" : > *) : > if [ -r "${ipfw_script}" ]; then : > ... : > elif [ "`ipfw l 65535`" = "65535 deny ip from any to any" ]; then : > echo 'Warning: kernel has firewall functionality,' \ : > 'but firewall rules are not enabled.' : > echo ' All ip services are disabled.' : > fi : : Which doesn't help much if you are not sitting at the console, but you : be seen once you login and check the logfiles. (Been there, done that, : hence the reason for my passioned opinions on this subject. :) Agreed. But the warning is there still. : Except the chicken/egg problem, I'm not sure how to get the old : 'default' functionality and still allow someone to easily 'disable' the : kernel. (Again, I don't care for the ipfw_firewall_disable variable. : Also, the name is a bit redundant, but now I'm picking nits. :) :) :) You missed the no clause of the case. If you set ipfw_firewall_enable=no, it will disable ipfw even if it is compiled into the kernel. This is failsafe, and would be very easy to document. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 14:40: 6 2002 Delivered-To: freebsd-stable@freebsd.org Received: from relay3-gui.server.ntli.net (relay3-gui.server.ntli.net [194.168.4.200]) by hub.freebsd.org (Postfix) with ESMTP id 31E2C37B400 for ; Mon, 28 Jan 2002 14:40:02 -0800 (PST) Received: from pc4-card4-0-cust162.cdf.cable.ntl.com ([80.4.14.162] helo=rhadamanth.private.submonkey.net ident=exim) by relay3-gui.server.ntli.net with esmtp (Exim 3.03 #2) id 16VKRC-0006F1-01; Mon, 28 Jan 2002 22:39:42 +0000 Received: from setantae by rhadamanth.private.submonkey.net with local (Exim 3.34 #1) id 16VKQh-0001ry-00; Mon, 28 Jan 2002 22:39:11 +0000 Date: Mon, 28 Jan 2002 22:39:11 +0000 From: Ceri To: Nate Williams Cc: Richard Glidden , freebsd-stable@FreeBSD.ORG Subject: Re: firewall config (CTFM) Message-ID: <20020128223911.GA7080@rhadamanth> Mail-Followup-To: Ceri , Nate Williams , Richard Glidden , freebsd-stable@FreeBSD.ORG References: <15445.37204.693732.376471@caddis.yogotech.com> <20020128150458.E10891-100000@charon.acheron.localnet> <15445.46625.765383.179068@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15445.46625.765383.179068@caddis.yogotech.com> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jan 28, 2002 at 03:33:05PM -0500, Richard Glidden wrote: > On Mon, 28 Jan 2002, Nate Williams wrote: > > Ok, so if I don't load rules, I will lock myself out. So > firewall_enable="NO" + IPFIREWALL = instant lockout. Seems pretty clear. > What does rc.conf say? > > firewall_enable="NO" # Set to YES to enable firewall functionality I freely admit to not having read more than two messages on this thread, but I'm happy I get the general idea. Why not just change the comment to : firewall_enable="NO" # Set to YES to load firewall rulesets. # Setting this to NO will drop all packets if # IPFIREWALL is enabled in your kernel. Job done as I see it. Ceri -- keep a mild groove on To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 14:41:17 2002 Delivered-To: freebsd-stable@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 6D39E37B416 for ; Mon, 28 Jan 2002 14:41:02 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id PAA10286; Mon, 28 Jan 2002 15:40:57 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0SMev171096; Mon, 28 Jan 2002 15:40:57 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15445.54136.731213.811969@caddis.yogotech.com> Date: Mon, 28 Jan 2002 15:40:56 -0700 To: "M. Warner Losh" Cc: nate@yogotech.com, cjm2@earthling.net, stable@FreeBSD.ORG, n@nectar.cc Subject: Re: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] In-Reply-To: <20020128.153704.109572342.imp@village.org> References: <15445.48617.802871.870971@caddis.yogotech.com> <20020128.151138.115627568.imp@village.org> <15445.53283.957773.221016@caddis.yogotech.com> <20020128.153704.109572342.imp@village.org> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > : > # Initialize IP filtering using ipfw > : > # > : > if /sbin/ipfw -q flush > /dev/null 2>&1; then > : > ipfw_in_kernel=1 > : > else > : > ipfw_in_kernel=0 > : > fi > : > > : > case ${ipfw_enable} in > : > [Yy][Ee][Ss]) > : > if [ "${ipfw_in_kernel}" -eq 0 ] && kldload ipfw; then > : > ipfw_in_kernel=1 > : > echo 'Kernel firewall module loaded' > : > elif [ "${ipfw_in_kernel}" -eq 0 ]; then > : > echo 'Warning: firewall kernel module failed to load' > : > fi > : > ;; > : > esac > : > : This loads things automagically if 'firewall is enabled', and does > : nothing if if the 'firewall isn't enabled'. > > No. It says if ipfw is enable, and not in the kernel, load it. I'm in violent agreement with that. > : > case ${ipfw_in_kernel} in > : > 1) > : > ... (indentation <<) > : > case ${ipfw_firewall_enable} in > : > : All of the above is just safety code. > > This says that "I know that I have IPFW in the kernel, but I want to > disable its firewall functionality" Actually, this says I know that I have firewall in the kernel. The only time this code is used is when the firewall isn't statically compiled in, and it failed to load. > : > *) > : > if [ -r "${ipfw_script}" ]; then > : > ... > : > elif [ "`ipfw l 65535`" = "65535 deny ip from any to any" ]; then > : > echo 'Warning: kernel has firewall functionality,' \ > : > 'but firewall rules are not enabled.' > : > echo ' All ip services are disabled.' > : > fi > : > : Which doesn't help much if you are not sitting at the console, but you > : be seen once you login and check the logfiles. (Been there, done that, > : hence the reason for my passioned opinions on this subject. :) > > Agreed. But the warning is there still. > > : Except the chicken/egg problem, I'm not sure how to get the old > : 'default' functionality and still allow someone to easily 'disable' the > : kernel. (Again, I don't care for the ipfw_firewall_disable variable. > : Also, the name is a bit redundant, but now I'm picking nits. :) :) :) > > You missed the no clause of the case. > > If you set ipfw_firewall_enable=no, it will disable ipfw even if it is > compiled into the kernel. Yes, and I think having this is a good thing. However, what are the default values for the variables? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 14:47:28 2002 Delivered-To: freebsd-stable@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 6C2E337B400 for ; Mon, 28 Jan 2002 14:47:19 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g0SMlEo20459; Mon, 28 Jan 2002 15:47:15 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g0SMlDx13364; Mon, 28 Jan 2002 15:47:13 -0700 (MST) (envelope-from imp@village.org) Date: Mon, 28 Jan 2002 15:46:56 -0700 (MST) Message-Id: <20020128.154656.123855750.imp@village.org> To: nate@yogotech.com Cc: cjm2@earthling.net, stable@FreeBSD.ORG, n@nectar.cc Subject: Re: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] From: "M. Warner Losh" In-Reply-To: <15445.54136.731213.811969@caddis.yogotech.com> References: <15445.53283.957773.221016@caddis.yogotech.com> <20020128.153704.109572342.imp@village.org> <15445.54136.731213.811969@caddis.yogotech.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <15445.54136.731213.811969@caddis.yogotech.com> Nate Williams writes: : > : > # Initialize IP filtering using ipfw : > : > # : > : > if /sbin/ipfw -q flush > /dev/null 2>&1; then : > : > ipfw_in_kernel=1 : > : > else : > : > ipfw_in_kernel=0 : > : > fi : > : > : > : > case ${ipfw_enable} in : > : > [Yy][Ee][Ss]) : > : > if [ "${ipfw_in_kernel}" -eq 0 ] && kldload ipfw; then : > : > ipfw_in_kernel=1 : > : > echo 'Kernel firewall module loaded' : > : > elif [ "${ipfw_in_kernel}" -eq 0 ]; then : > : > echo 'Warning: firewall kernel module failed to load' : > : > fi : > : > ;; : > : > esac : > : : > : This loads things automagically if 'firewall is enabled', and does : > : nothing if if the 'firewall isn't enabled'. : > : > No. It says if ipfw is enable, and not in the kernel, load it. : : I'm in violent agreement with that. : : > : > case ${ipfw_in_kernel} in : > : > 1) At this point we know we have ipfw in the kernel, either statically or dynamically loaded. : > : > ... (indentation <<) : > : > case ${ipfw_firewall_enable} in : > : : > : All of the above is just safety code. : > : > This says that "I know that I have IPFW in the kernel, but I want to : > disable its firewall functionality" : : Actually, this says I know that I have firewall in the kernel. The only : time this code is used is when the firewall isn't statically compiled : in, and it failed to load. I think that what I wrote doesn't match this statement. Since we set ipfw_in_kernel when we've loaded it or when it is in the kernel, the code gets executed when ipfw is in the kernel, by whatever path. The no clause of this case would then issue the warning, and turn off the ipfw stuff. In the case where ipfw isn't in the kernel (statically or dynatmically), no action is necessary to disable it. : > : > *) : > : > if [ -r "${ipfw_script}" ]; then : > : > ... : > : > elif [ "`ipfw l 65535`" = "65535 deny ip from any to any" ]; then : > : > echo 'Warning: kernel has firewall functionality,' \ : > : > 'but firewall rules are not enabled.' : > : > echo ' All ip services are disabled.' : > : > fi : > : : > : Which doesn't help much if you are not sitting at the console, but you : > : be seen once you login and check the logfiles. (Been there, done that, : > : hence the reason for my passioned opinions on this subject. :) : > : > Agreed. But the warning is there still. : > : > : Except the chicken/egg problem, I'm not sure how to get the old : > : 'default' functionality and still allow someone to easily 'disable' the : > : kernel. (Again, I don't care for the ipfw_firewall_disable variable. : > : Also, the name is a bit redundant, but now I'm picking nits. :) :) :) : > : > You missed the no clause of the case. : > : > If you set ipfw_firewall_enable=no, it will disable ipfw even if it is : > compiled into the kernel. : : Yes, and I think having this is a good thing. However, what are the : default values for the variables? In previous mail I suggested: ipfw_enable=no ipfw_firewall_enable=yes Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 14:51:30 2002 Delivered-To: freebsd-stable@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id D200237B41F for ; Mon, 28 Jan 2002 14:51:22 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id PAA10706; Mon, 28 Jan 2002 15:51:16 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0SMpFh71209; Mon, 28 Jan 2002 15:51:15 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15445.54755.551301.284078@caddis.yogotech.com> Date: Mon, 28 Jan 2002 15:51:15 -0700 To: "M. Warner Losh" Cc: nate@yogotech.com, cjm2@earthling.net, stable@FreeBSD.ORG, n@nectar.cc Subject: Re: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] In-Reply-To: <20020128.154656.123855750.imp@village.org> References: <15445.53283.957773.221016@caddis.yogotech.com> <20020128.153704.109572342.imp@village.org> <15445.54136.731213.811969@caddis.yogotech.com> <20020128.154656.123855750.imp@village.org> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > : Yes, and I think having this is a good thing. However, what are the > : default values for the variables? > > In previous mail I suggested: > > ipfw_enable=no > ipfw_firewall_enable=yes Gotcha, I confused ipfw_enable with ipfw_firewall_enable. Unfortunately, it's not obvious which one the users should use to enable the functionality. Now we have two variables that *appear* to be redundant.... Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 15: 4:28 2002 Delivered-To: freebsd-stable@freebsd.org Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.122.47]) by hub.freebsd.org (Postfix) with ESMTP id 4E72237B402 for ; Mon, 28 Jan 2002 15:04:26 -0800 (PST) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.11.3/8.10.1) with ESMTP id g0SN4jx07918; Mon, 28 Jan 2002 15:04:45 -0800 (PST) Date: Mon, 28 Jan 2002 15:04:45 -0800 (PST) From: Doug White To: ptiJo Cc: freebsd-stable@FreeBSD.ORG Subject: Re: ARCHOS Jukebox Studio 20 support In-Reply-To: <20020127165006.5d1f6f1c.ptiJo@noos.fr> Message-ID: <20020128150053.X6367-100000@resnet.uoregon.edu> X-All-Your-Base: are belong to us MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 27 Jan 2002, ptiJo wrote: > it seems the specs have been released... the linux kernel has support > for it (ISD-200) http://bjorn.haxx.se/isd200/ (...) The ISD-200 is an > ASIC designed by In-System Design Inc. that acts as a USB to ATA bridge > and which is used in many USB mass storage devices. The vendor/product > code for the ISD-200 chip is 05ab/0031. (...) > > do you think it would be hard to port them to FreeBee ? I could try but > I've never done such things before... and I'm not really a good hacker > ;( That's a pointer to the Linux driver, which was contributed by ISD themselves. You'd want to find out if it's OK by the license to modify or reuse data from that driver. Since it is a linux driver and they are not directly portable, you could potentially use the information from it, if the license allows, to write a new driver. The linux usb code isn't that dense, but I also haven't seen how hard it is to create CAM attachments in our code. I don't have an Archos so writing anything useful would be hard... Doug White | FreeBSD: The Power to Serve dwhite@resnet.uoregon.edu | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 15: 6: 2 2002 Delivered-To: freebsd-stable@freebsd.org Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.122.47]) by hub.freebsd.org (Postfix) with ESMTP id 075A337B400 for ; Mon, 28 Jan 2002 15:05:57 -0800 (PST) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.11.3/8.10.1) with ESMTP id g0SN6AF07978; Mon, 28 Jan 2002 15:06:10 -0800 (PST) Date: Mon, 28 Jan 2002 15:06:10 -0800 (PST) From: Doug White To: ptiJo Cc: freebsd-stable@FreeBSD.ORG Subject: Re: ARCHOS Jukebox Studio 20 support In-Reply-To: <20020127165006.5d1f6f1c.ptiJo@noos.fr> Message-ID: <20020128150541.F6367-100000@resnet.uoregon.edu> X-All-Your-Base: are belong to us MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 27 Jan 2002, ptiJo wrote: > it seems the specs have been released... > the linux kernel has support for it (ISD-200) > http://bjorn.haxx.se/isd200/ [/me checks] oh, it's GPL. So it should be OK to derive a new driver from it. Doug White | FreeBSD: The Power to Serve dwhite@resnet.uoregon.edu | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 15:30:14 2002 Delivered-To: freebsd-stable@freebsd.org Received: from smtp.noos.fr (camus.noos.net [212.198.2.70]) by hub.freebsd.org (Postfix) with ESMTP id 58E3237B400 for ; Mon, 28 Jan 2002 15:30:11 -0800 (PST) Received: (qmail 1629788 invoked by uid 0); 28 Jan 2002 23:30:09 -0000 Received: from unknown (HELO atheria.ptijo.net) ([195.132.200.187]) (envelope-sender ) by 212.198.2.70 (qmail-ldap-1.03) with SMTP for ; 28 Jan 2002 23:30:09 -0000 Date: Tue, 29 Jan 2002 00:30:22 +0100 From: ptiJo To: Doug White Cc: freebsd-stable@FreeBSD.ORG Subject: Re: ARCHOS Jukebox Studio 20 support Message-Id: <20020129003022.434a25ff.ptiJo@noos.fr> In-Reply-To: <20020128150541.F6367-100000@resnet.uoregon.edu> References: <20020127165006.5d1f6f1c.ptiJo@noos.fr> <20020128150541.F6367-100000@resnet.uoregon.edu> X-Mailer: Sylpheed version 0.6.5 (GTK+ 1.2.10; i386--freebsd4.4) User-Agent: X-Face: X-Operating-System: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG GPL ! nice starting point :) I've wrote an email to in-system to ask for a minimal FreeBSD driver... I'll let you know if they reply... as I previously said, I'm not used to coding/porting devices... if you can't do it (no time, no will, no jukebox ;), I may try to do it myself... should it be really hard ? do you have any pointer (aka tutorial) on porting devices from Linux to FreeBSD ? On Mon, 28 Jan 2002 15:06:10 -0800 (PST) Doug White wrote: > On Sun, 27 Jan 2002, ptiJo wrote: > > > it seems the specs have been released... > > the linux kernel has support for it (ISD-200) > > http://bjorn.haxx.se/isd200/ > > [/me checks] > > oh, it's GPL. So it should be OK to derive a new driver from it. > > Doug White | FreeBSD: The Power to Serve > dwhite@resnet.uoregon.edu | www.FreeBSD.org > > --------------------- ptiJo Linux: For those who don't like Windows *BSD: For those who like UNIX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 15:37:12 2002 Delivered-To: freebsd-stable@freebsd.org Received: from csun.edu (krusty.csun.edu [130.166.1.51]) by hub.freebsd.org (Postfix) with ESMTP id 59F4837B422 for ; Mon, 28 Jan 2002 15:36:59 -0800 (PST) Received: from csun.edu (s097n152.csun.edu [130.166.97.152]) by csun.edu (8.9.3 (MessagingDirect 1.0.4)/8.9.3) with ESMTP id PAA8069260; Mon, 28 Jan 2002 15:36:51 -0800 (PST) Message-ID: <3C55E092.D4E4B628@csun.edu> Date: Mon, 28 Jan 2002 15:36:50 -0800 From: Albert Kinderman X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.5-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org Subject: Running 4.5 Stable Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ls -l /usr/src/sys/conf/newvers.sh .... Jan 28 11:57 /usr/src/sys/conf/newvers.sh uname -a ... FreeBSD 4.5-STABLE Mon Jan 28 15:18:31 Al -- Albert Kinderman California State University, Northridge Department of Systems and Operations Management To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 15:47:32 2002 Delivered-To: freebsd-stable@freebsd.org Received: from marvin.nildram.co.uk (marvin.nildram.co.uk [195.112.4.71]) by hub.freebsd.org (Postfix) with SMTP id 3837C37B400 for ; Mon, 28 Jan 2002 15:47:27 -0800 (PST) Received: (qmail 8939 invoked from network); 28 Jan 2002 23:47:24 -0000 Received: from muttley.gotadsl.co.uk (HELO VicNBob) (213.208.123.26) by marvin.nildram.co.uk with SMTP; 28 Jan 2002 23:47:24 -0000 From: Matthew Whelan To: "M. Warner Losh" , nate@yogotech.com (Nate Williams) Cc: cjm2@earthling.net, stable@FreeBSD.ORG, n@nectar.cc Date: Mon, 28 Jan 2002 23:47:19 -0000 X-Priority: 3 (Normal) In-Reply-To: <15445.48617.802871.870971@caddis.yogotech.com> Message-Id: Subject: Re: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Opera 6.0 build 1010 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 28/01/2002 21:08:57, Nate Williams wrote: >> How about renaming things a little more: >> >> ipfw_load_rules={yes,no} >> ipfw_disable_firewall={yes,no} >> ipfw_kldload={yes,no} > >I don't mind the first two, but I dislike the third for the following >reasons. > >1) We are moving (slowly) to a kernel where things are loaded > 'automagically'. In other words, the user shouldn't have to > explicitly load a module if it's being used. (All of the network > adapters are moving in this direction.) > >2) If possible (I've not analyzed this), it would be nice that if the > firewall is 'enabled' (second variable), the script would determine > *IF* the firewall module is in the kernel or not (like is done with > the current network adapter modules), and if not, load it. My ?0.02: ipfw_load_rules could happily continue to work as it does at current (auto- load the module if it's needed) ipfw_disable_firewall shouldn't exist - nowhere else does rc knockout kernel code like this, and to me, such behaviour is NOT something that should happen in boot-time scripts. You have to make some effort to compile ipfw in, if you have done so, it should be assumed that you want to keep it in. This should not be needed anyway, as the renaming of firewall_enable -> ipfw_load_rules should destroy the misunderstanding that bites people. ipfw_kldload would therefore only be needed (a) for people who wanted to default-deny and have the module loaded before the interfaces are configured, or (b) for people who wanted effectively to have firewall_type=closed, by another route. It would have to be noted that ipfw_load_rules could still force a kldload even if this was no... or perhaps this could be a tri-state, YES/NO/NEVER, with the three behaviours being fairly obvious I think :) Would you also rename the other firewall_* variables accordingly? Isn't this starting to get a bit big a change for -STABLE? (unless you have an interim rc.network that understands both the old and new, translates old to new, and flashes a big warning that you change, or something :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 15:55:26 2002 Delivered-To: freebsd-stable@freebsd.org Received: from rockstar.stealthgeeks.net (h-66-134-120-173.LSANCA54.covad.net [66.134.120.173]) by hub.freebsd.org (Postfix) with SMTP id 3AF4B37B402 for ; Mon, 28 Jan 2002 15:55:21 -0800 (PST) Received: (qmail 385 invoked by uid 1001); 28 Jan 2002 23:55:20 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 28 Jan 2002 23:55:20 -0000 Date: Mon, 28 Jan 2002 15:55:20 -0800 (PST) From: Patrick Greenwell To: Matthew Whelan Cc: "M. Warner Losh" , Nate Williams , , , Subject: Re: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] In-Reply-To: Message-ID: <20020128155135.X342-100000@rockstar.stealthgeeks.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 28 Jan 2002, Matthew Whelan wrote: > Isn't this starting to get a bit big a change for -STABLE? (unless you have > an interim rc.network that understands both the old and new, translates old > to new, and flashes a big warning that you change, or something :) My fault for opening this can of worms on -stable. The discussion/proposed changes probably do belong on -current. I've just never run a -CURRENT system and don't subscribe to -current... /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Patrick Greenwell Stealthgeeks,LLC. Operations Consulting http://www.stealthgeeks.net \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 15:57:14 2002 Delivered-To: freebsd-stable@freebsd.org Received: from uucp0.ash.ops.us.uu.net (uucp0.ash.ops.us.uu.net [198.5.241.21]) by hub.freebsd.org (Postfix) with ESMTP id 03C5137B402 for ; Mon, 28 Jan 2002 15:57:09 -0800 (PST) Received: from uucp0.ash.ops.us.uu.net by uucp0.ash.ops.us.uu.net with SMTP (peer crosschecked as: uucp0.ash.ops.us.uu.net [198.5.241.21]) id QQlzvb09299 for ; Mon, 28 Jan 2002 23:57:07 GMT Received: from m10.UUCP by uucp0.ash.ops.us.uu.net with UUCP/RMAIL ; Mon, 28 Jan 2002 23:57:07 +0000 Received: from lorentzian.com by m10.gaussian.com; Mon, 28 Jan 2002 18:46:47 -0500 Message-ID: <3C55E26A.4050906@lorentzian.com> Date: Mon, 28 Jan 2002 18:44:42 -0500 From: AEleen Frisch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: freebsd-stable@FreeBSD.ORG Subject: Seeking tech reviewer Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I am the author of a book on UNIX system administration (O'Reilly). We are looking for someone who knows FreeBSD well who would be interested in serving as a technical reviewer for the upcoming 3rd edition of the book, which includes FreeBSd as one of the reference operating systems. The review period starts immediately, need to be done rather quickly, and consists of ~1000 pages. Sadly, publishers pay very little for this sort of thing (a few hundred dollars I think). Of course, reviewers are acknowledged in the book, and receive the author's tremendous gratitude and a free copy of the final work. If you are interested in doing this, please send me email (aefrisch@lorentzian.com). -- aefrisch@lorentzian.com AEleen Frisch To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 16: 7:27 2002 Delivered-To: freebsd-stable@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 27A7937B41B for ; Mon, 28 Jan 2002 16:07:21 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g0T07Ho20829; Mon, 28 Jan 2002 17:07:17 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g0T07Fx13809; Mon, 28 Jan 2002 17:07:15 -0700 (MST) (envelope-from imp@village.org) Date: Mon, 28 Jan 2002 17:06:59 -0700 (MST) Message-Id: <20020128.170659.97077059.imp@village.org> To: nate@yogotech.com Cc: cjm2@earthling.net, stable@FreeBSD.ORG, n@nectar.cc Subject: Re: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] From: "M. Warner Losh" In-Reply-To: <15445.54755.551301.284078@caddis.yogotech.com> References: <15445.54136.731213.811969@caddis.yogotech.com> <20020128.154656.123855750.imp@village.org> <15445.54755.551301.284078@caddis.yogotech.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <15445.54755.551301.284078@caddis.yogotech.com> Nate Williams writes: : > : Yes, and I think having this is a good thing. However, what are the : > : default values for the variables? : > : > In previous mail I suggested: : > : > ipfw_enable=no : > ipfw_firewall_enable=yes : : Gotcha, I confused ipfw_enable with ipfw_firewall_enable. : Unfortunately, it's not obvious which one the users should use to enable : the functionality. : : Now we have two variables that *appear* to be redundant.... That's as far as I'm willing to go. The rest would be a documentation issue. It can be clearly stated how to disable things in the documentation. Of course, one could also argue that if you set firewall_enable to no now that one could add net.inet.ip.fw.enable=0 to /etc/sysctl.conf. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 16:10:27 2002 Delivered-To: freebsd-stable@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 3431E37B400 for ; Mon, 28 Jan 2002 16:10:20 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id RAA13779; Mon, 28 Jan 2002 17:10:11 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0T0ABJ77586; Mon, 28 Jan 2002 17:10:11 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15445.59490.902141.369997@caddis.yogotech.com> Date: Mon, 28 Jan 2002 17:10:10 -0700 To: "M. Warner Losh" Cc: nate@yogotech.com, cjm2@earthling.net, stable@FreeBSD.ORG, n@nectar.cc Subject: Re: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] In-Reply-To: <20020128.170659.97077059.imp@village.org> References: <15445.54136.731213.811969@caddis.yogotech.com> <20020128.154656.123855750.imp@village.org> <15445.54755.551301.284078@caddis.yogotech.com> <20020128.170659.97077059.imp@village.org> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Nate Williams writes: > : > : Yes, and I think having this is a good thing. However, what are the > : > : default values for the variables? > : > > : > In previous mail I suggested: > : > > : > ipfw_enable=no > : > ipfw_firewall_enable=yes > : > : Gotcha, I confused ipfw_enable with ipfw_firewall_enable. > : Unfortunately, it's not obvious which one the users should use to enable > : the functionality. > : > : Now we have two variables that *appear* to be redundant.... > > That's as far as I'm willing to go. The rest would be a documentation > issue. It can be clearly stated how to disable things in the > documentation. Sorry, but I think this would be *worse* (ie; more confusing) than the already confusing setup we have now. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 16:11:31 2002 Delivered-To: freebsd-stable@freebsd.org Received: from web14704.mail.yahoo.com (web14704.mail.yahoo.com [216.136.224.121]) by hub.freebsd.org (Postfix) with SMTP id 2DB1837B402 for ; Mon, 28 Jan 2002 16:11:27 -0800 (PST) Message-ID: <20020129001127.96035.qmail@web14704.mail.yahoo.com> Received: from [216.251.139.106] by web14704.mail.yahoo.com via HTTP; Mon, 28 Jan 2002 16:11:27 PST Date: Mon, 28 Jan 2002 16:11:27 -0800 (PST) From: Dennis Dai Subject: RE: Multiple Promise controllers To: FreeBSD-Stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG (Please cc me as I'm not on the list.) I used to plug 5 promise Ultra100 TX2 cards in one computer. All of them were recognized. But when I plugged 12 drives into those cards, only 8 drives were recognized correctly (or maybe I need to MAKEDEV?). I remember reading somewhere (probably in one of the source code either in FreeBSD or in Linux kernel) that promise has a upper limit of 12 drives in one system but only the first 8 will be in DMA mode and the last 4 in PIO with some treak (burst? can't remember). Dennis __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 16:30:36 2002 Delivered-To: freebsd-stable@freebsd.org Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2]) by hub.freebsd.org (Postfix) with ESMTP id 6A8E137B402 for ; Mon, 28 Jan 2002 16:30:30 -0800 (PST) Received: from Frustration (deelfes-host187.dsl.visi.com [209.98.238.187]) by conn.mc.mpls.visi.com (Postfix) with SMTP id 6A3F3815D for ; Mon, 28 Jan 2002 18:30:29 -0600 (CST) From: "Dale Elfes" To: Subject: subsribe Date: Mon, 28 Jan 2002 18:28:34 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C1A829.98996600" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-MS-TNEF-Correlator: Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C1A829.98996600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Dale Elfes "This life has been a test. Had this been an actual life, you would have been given instructions on where to go, and what to do when you got there." deelfes@visi.com (Home Email) ------=_NextPart_000_0000_01C1A829.98996600 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IiIAAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHAQAcABIAHAAAAAEAJQEB A5AGAFQFAAAjAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAACQAAAHN1YnNyaWJlAAAAAAIBcQABAAAAFgAAAAHBqFvi8DBogygUFhHWrcsAoMmB+bIAAAIB HQwBAAAAFgAAAFNNVFA6REVFTEZFU0BWSVNJLkNPTQAAAAsAAQ4AAAAAQAAGDgAoUc5bqMEBAgEK DgEAAAAYAAAAAAAAAGvoEXzazdQRrcsAoMmB+bLCgAAACwAfDgEAAAACAQkQAQAAAGkBAABlAQAA 3wEAAExaRnWo7cykAwAKAHJjcGcxMjUWMgD4C2BuDhAwMzNPAfcCpAPjAgBjaArAc/BldDAgBxMC gwBQA1QhEMlCb29rA4JPbEJkBgB0eWxlAoB9swqACMggOwlvDiA4AoAlCoF2CJB3awuAZDT9DGBj AFALAwu2CrEKhAqEnQswYwBBDDIAQCBEB0BgZSBFbGYHkBiUIuRUaAQAIGwGkBqQEPCFBCBiCeEg YSB0B5CkdC4YlEhhE+B0G4JjHFQcgWN0dQdAG7Ms5CB5CGAgdwhgE9EQ8M52GpAcUhiUZ2kgEAOg ywuAHOByF5B0aQIgBCAbAiAfgGgEkBqQdG8gvGdvHzAAcBPgIkBhBUD9IqFkIrAiQQOgH1Ii0COB WSJSLiIYlAEAZRrCQEsW8ACQLgWgbSAmoCjeSANwGpEAwAMQKRiVGbA7ChEBQGkC0RiJCzBvYoJq I3B0cGhcJxh2BRRxACrgAAAACwABgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAOACCAG AAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAsABIAIIAYAAAAAAMAAAAAAAABGAAAAABSFAAAAAAAA AwAHgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAALZ0AQAeAAmACCAGAAAAAADAAAAAAAAARgAAAABU hQAAAQAAAAQAAAA5LjAACwANgAggBgAAAAAAwAAAAAAAAEYAAAAAgoUAAAEAAAALADqACCAGAAAA AADAAAAAAAAARgAAAAAOhQAAAAAAAAMAPIAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwA9 gAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAALAFKACCAGAAAAAADAAAAAAAAARgAAAAAGhQAA AAAAAAMAU4AIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAAAgH4DwEAAAAQAAAAa+gRfNrN1BGt ywCgyYH5sgIB+g8BAAAAEAAAAGvoEXzazdQRrcsAoMmB+bICAfsPAQAAAIIAAAAAAAAAOKG7EAXl EBqhuwgAKypWwgAAUFNUUFJYLkRMTAAAAAAAAAAATklUQfm/uAEAqgA32W4AAABDOlxXSU5ET1dT XExvY2FsIFNldHRpbmdzXEFwcGxpY2F0aW9uIERhdGFcTWljcm9zb2Z0XE91dGxvb2tcb3V0bG9v ay5wc3QAAAADAP4PBQAAAAMADTT9NwAAAgF/AAEAAAAwAAAAPE5FQkJLTk1MR0xFSU5JUE5DREhQ Q0VBRkNGQUEuZGVlbGZlc0B2aXNpLmNvbT4AAwAGEFMn58sDAAcQmAAAAAMAEBAAAAAAAwAREAAA AAAeAAgQAQAAAGUAAABEQUxFRUxGRVMiVEhJU0xJRkVIQVNCRUVOQVRFU1RIQURUSElTQkVFTkFO QUNUVUFMTElGRSxZT1VXT1VMREhBVkVCRUVOR0lWRU5JTlNUUlVDVElPTlNPTldIRVJFVE9HTyxB AAAAANMkAgKQBgAOAAAAAQDLAAAAIAAgAAAAAAAMAQITgAMADgAAANEHAQARAAYAMgAMAAMAMQEC D4AGAEwBAABCRUdJTjpWQ0FSRA0KVkVSU0lPTjoyLjENCk46RWxmZXM7RGFsZTtFLg0KRk46RGFs ZSBFLiBFbGZlcw0KVEVMO0hPTUU7Vk9JQ0U6KDYxMikgODY2LTkwNDcNCkFEUjtIT01FOjs7NzUy NyBIYXJyaWV0IEF2ZS4gUy47UmljaGZpZWxkO01OOzU1NDIzO1VuaXRlZCBTdGF0ZXMNCkxBQkVM O0hPTUU7RU5DT0RJTkc9UVVPVEVELVBSSU5UQUJMRTo3NTI3IEhhcnJpZXQgQXZlLiBTLj0wRD0w QVJpY2hmaWVsZCwgTU4gNTU0MjM9MEQ9MEFVbml0ZWQgU3RhdGVzDQpFTUFJTDtQUkVGO0lOVEVS TkVUOmRlZWxmZXNAdmlzaS5jb20NClJFVjoyMDAxMDExN1QxMjUwMTFaDQpFTkQ6VkNBUkQNCsVb AhCAAQANAAAAREFMRUVFfjEuVkNGAFwDAhGABgCUDQAAAQAJAAADygYAAAAAIQYAAAAABQAAAAEC ////AAUAAAAJAgAAAAAEAAAABwEBAGUAAABBC8YAiAAgACAAAAAAACAAIAAAAAAAKAAAACAAAAAg AAAAAQABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///8A//////8B///wAB//wAAH/4AA A/+AAAP/gAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAA AIAAAACAAAP/gAAD/4AAA/+AAAP/gAAD/4AAA/+AAAP/gAAD/4AAA/+AAAP/gAAD/4AAB/8EAAAA BwEBAAUAAAAJAgEAAAAFAAAAAQIBAAAABQAAAAEC////AAUAAAAJAgAAAAAEAAAABwEDACEGAABB C0YAZgAgACAAAAAAACAAIAAAAAAAKAAAACAAAAAgAAAAAQAYAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgICAgICA gICAgICAgICAgICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAICAgICAgICAgICAgICAgICAgICAgAAAAICAgICAgICAgICAgICA gICAgICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwICA gICAgICAgICAgAAAAMDAwICAgICAgAAAAICAgICAgAAAAMDAwICAgICAgICAgICAgAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwICAgICAgICAgICAgAAAAAAAAICA gICAgAAAAICAgICAgAAAAAAAAICAgICAgICAgICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAMDAwICAgAAAAMDAwICAgICAgICAgICAgICAgAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDA wICAgAAAAAAAAICAgICAgICAgICAgICAgICAgAAAAP8AAP8AAP8AAP8AAP8AAP8AAMDAwMDAwP// /////////////////////////////////////wAAAAAAAAAAAMDAwICAgICAgICAgICAgICAgMDA wMDAwMDAwMDAwAAAAP8AAP8AAP8AAP8AAMDAwP///////////////wAAAP///wAAAAAAAAAAAP// /////////////wAAAAAAAAAAAMDAwICAgICAgMDAwMDAwMDAwMDAwICAgMDAwICAgAAAAP8AAP8A AMDAwP///////////////////////////////////////////////////////////wAAAAAAAAAA AMDAwICAgICAgMDAwAAAAMDAwICAgMDAwICAgMDAwAAAAP8AAMDAwP////////////////////// /////wAAAAAAAAAAAP///wAAAP///////////////wAAAAAAAAAAAMDAwICAgICAgMDAwMDAwMDA wMDAwICAgMDAwICAgAAAAP8AAP////////////////////////////////////////////////// /////////////////wAAAAAAAAAAAMDAwICAgICAgMDAwAAAAMDAwICAgMDAwICAgMDAwAAAAP8A AP///////////////////////////////////////////////////////////////////wAAAAAA AAAAAMDAwICAgICAgMDAwMDAwMDAwMDAwMDAwMDAwMDAwAAAAP8AAP8AAP///8DAwP////////// /////////wAAAAAAAAAAAAAAAP///wAAAP///wAAAP///wAAAAAAAAAAAMDAwICAgICAgAD/AP// AAD/AP//AAD/AP//AAD/AAAAAP8AAP8AAIAAAIAAAIAAAP////////////////////////////// /////////////////////wAAAAAAAAAAAMDAwICAgICAgP//AAD/AP//AAD/AP//AAD/AP//AAAA AP8AAP8AAIAAAIAAAIAAAMDAwP///////////wAAAAAAAP///wAAAAAAAP///////////////wAA AAAAAAAAAMDAwICAgICAgAD/AP//AAD/AP//AAD/AP//AAD/AAAAAP8AAP8AAIAAAIAAAIAAAMDA wP///////////////////////////////////////////////wAAAAAAAAAAAMDAwICAgICAgP// AAD/AP//AAD/AP//AAD/AP//AAAAAP8AAP8AAP8AAP8AAP8AAP8AAMDAwMDAwP////////////// /////////////////////////wAAAAAAAAAAAMDAwICAgICAgAD/AP//AAD/AP//AAD/AP//AAD/ AAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8A AAAAAAAAAAAAAMDAwICAgICAgP//AAD/AP//AAD/AP//AAD/AP//AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwICAgICA gAD/AP//AAD/AP//AAD/AP//AAD/AP//AAD/AP//AAD/AP//AAD/AICAgICAgAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwICAgICAgP//AAD/AP//AAD/AP//AAD/ AP//AAD/AP//AAD/AP//AAD/AP//AICAgICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAMDAwICAgICAgAD/AP//AAD/AP//AAD/AP//AAD/AP//AAD/AP//AAD/AP// AAD/AICAgICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwICA gICAgP//AAD/AP//AAD/AP//AAD/AP//AAD/AP//AAD/AP//AAD/AP//AICAgICAgAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwICAgICAgAD/AP//AAD/AP//AAD/ AP//AAD/AP//AAD/AP//AAD/AP//AAD/AICAgICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAMDAwICAgICAgP//AAD/AP//AAD/AP//AAD/AP//AAD/AP//AAD/AP// AAD/AP//AICAgICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDA wICAgICAgAD/AP//AAD/AP//AAD/AP//AAD/AP//AAD/AP//AAD/AP//AAD/AICAgICAgAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwICAgICAgP//AAD/AP//AAD/ AP//AAD/AP//AAD/AP//AAD/AP//AAD/AP//AICAgICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAP///4CAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA gICAgICAgICAgICAgICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AP///4CAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgACAAICAgICAgAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////8DAwMDA wMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwAD/AACAAACAAMDAwAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQA AAAHAQEABQAAAAkCAQAAAAUAAAABAgEAAAADAAAAAAAmfQIFkAYAhAEAABEAAAADACAORw8AAB4A ATABAAAAEgAAAERhbGUgRS4gRWxmZXMudmNmAAAAAgECNwEAAAAAAAAAHgADNwEAAAAFAAAALnZj ZgAAAAADAAU3AQAAAB4ABzcBAAAAEgAAAERhbGUgRS4gRWxmZXMudmNmAAAAAwALN8sAAAADAPp/ AAAAAEAA+38AQN2jV0WzDEAA/H8AQN2jV0WzDAMA/X8AAAAACwD+fwAAAAADACEOJdkBAAIB+A8B AAAAEAAAAGvoEXzazdQRrcsAoMmB+bICAfoPAQAAABAAAABr6BF82s3UEa3LAKDJgfmyAgH7DwEA AACCAAAAAAAAADihuxAF5RAaobsIACsqVsIAAFBTVFBSWC5ETEwAAAAAAAAAAE5JVEH5v7gBAKoA N9luAAAAQzpcV0lORE9XU1xMb2NhbCBTZXR0aW5nc1xBcHBsaWNhdGlvbiBEYXRhXE1pY3Jvc29m dFxPdXRsb29rXG91dGxvb2sucHN0AAAAAwD+DwcAAACzYA== ------=_NextPart_000_0000_01C1A829.98996600-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 16:31:55 2002 Delivered-To: freebsd-stable@freebsd.org Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2]) by hub.freebsd.org (Postfix) with ESMTP id 3CAEC37B425 for ; Mon, 28 Jan 2002 16:31:35 -0800 (PST) Received: from Frustration (deelfes-host187.dsl.visi.com [209.98.238.187]) by conn.mc.mpls.visi.com (Postfix) with SMTP id 82D1281E4 for ; Mon, 28 Jan 2002 18:31:34 -0600 (CST) From: "Dale Elfes" To: Subject: subscribe freebsd-stable Date: Mon, 28 Jan 2002 18:29:40 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0003_01C1A829.BF655820" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-MS-TNEF-Correlator: Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C1A829.BF655820 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit subscribe freebsd-stable subscribe cvs-all Dale Elfes "This life has been a test. Had this been an actual life, you would have been given instructions on where to go, and what to do when you got there." deelfes@visi.com (Home Email) ------=_NextPart_000_0003_01C1A829.BF655820 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IigAAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHAQAcABIAHQAAAAEAJgEB A5AGAKgFAAAjAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAAGQAAAHN1YnNjcmliZSBmcmVlYnNkLXN0YWJsZQAAAAACAXEAAQAAABYAAAABwahcCd4waIMt FBYR1q3LAKDJgfmyAAACAR0MAQAAABYAAABTTVRQOkRFRUxGRVNAVklTSS5DT00AAAALAAEOAAAA AEAABg4AbhTyW6jBAQIBCg4BAAAAGAAAAAAAAABr6BF82s3UEa3LAKDJgfmywoAAAAsAHw4BAAAA AgEJEAEAAACwAQAArAEAAJACAABMWkZ1gfLC8gMACgByY3BnMTI1FjIA+Atgbg4QMDMzTwH3AqQD 4wIAY2gKwHPwZXQwIAcTAoMAUANUHxDJB20Cgw5QEj9Cb28iawOCT2xkBgB0eTRsZQKAfQqACMgg O1sJbw4gOAKACoF2CJB30msLgGQ0DGBjAFALA88LtgqxCoQLMHNiD0ABQBxzYRviEgIL8DQgc8R1 YgTyYmUgA1AJ4PEdIGQtcwGRFqAbBB0I8GN2cy0HQAlQGxcgOp0afmMAQQwyFHAgRAdAMR2ARWxm B5AbBCJU8mgEACBsBpAdgBDwBCBDHXAJ8CBhIHQHkHTSLhsESGEWUHQkIiT0MSUhY3R1B0AkUywg cnkIYCB3CGAWQRDwducdgCTyGwRnaSiwA6ALgOUeIHIaAHRpAiAEIAIgDSggaASQHYB0byBn3m8n 0ABwFlAq4GEFQCtB/mQrUCrhA6An8itwLCEq8qwuIhsEAQBlI2JAGWAlAJAuBaBtIC9AKEjvA3Aj MQDAAxApIecKEQFAjmkC0Rr/HAZvYmosEOB0cGhcJwwBHIUgvwsa5hbhADXwCwABgAggBgAAAAAA wAAAAAAAAEYAAAAAA4UAAAAAAAADAAOACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAsABIAI IAYAAAAAAMAAAAAAAABGAAAAABSFAAAAAAAAAwAHgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAALZ0 AQAeAAmACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA5LjAACwANgAggBgAAAAAAwAAA AAAAAEYAAAAAgoUAAAEAAAALADqACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAPIAIIAYA AAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwA9gAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAL AFKACCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAAMAU4AIIAYAAAAAAMAAAAAAAABGAAAAAAGF AAAAAAAAAgH4DwEAAAAQAAAAa+gRfNrN1BGtywCgyYH5sgIB+g8BAAAAEAAAAGvoEXzazdQRrcsA oMmB+bICAfsPAQAAAIIAAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAAUFNUUFJYLkRMTAAAAAAAAAAA TklUQfm/uAEAqgA32W4AAABDOlxXSU5ET1dTXExvY2FsIFNldHRpbmdzXEFwcGxpY2F0aW9uIERh dGFcTWljcm9zb2Z0XE91dGxvb2tcb3V0bG9vay5wc3QAAAADAP4PBQAAAAMADTT9NwAAAgF/AAEA AAAwAAAAPE5FQkJLTk1MR0xFSU5JUE5DREhQR0VBRkNGQUEuZGVlbGZlc0B2aXNpLmNvbT4AAwAG EKw7yncDAAcQvwAAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABTVUJTQ1JJQkVGUkVFQlNE LVNUQUJMRVNVQlNDUklCRUNWUy1BTExEQUxFRUxGRVMiVEhJU0xJRkVIQVNCRUVOQVRFU1RIQURU SElTQkVFTkFOQUNUVUFMTElGRSxZT1VXT1VMAAAAAEg8AgKQBgAOAAAAAQD8AAAAIAAgAAAAAAA9 AQITgAMADgAAANEHAQARAAYAMgAMAAMAMQECD4AGAEwBAABCRUdJTjpWQ0FSRA0KVkVSU0lPTjoy LjENCk46RWxmZXM7RGFsZTtFLg0KRk46RGFsZSBFLiBFbGZlcw0KVEVMO0hPTUU7Vk9JQ0U6KDYx MikgODY2LTkwNDcNCkFEUjtIT01FOjs7NzUyNyBIYXJyaWV0IEF2ZS4gUy47UmljaGZpZWxkO01O OzU1NDIzO1VuaXRlZCBTdGF0ZXMNCkxBQkVMO0hPTUU7RU5DT0RJTkc9UVVPVEVELVBSSU5UQUJM RTo3NTI3IEhhcnJpZXQgQXZlLiBTLj0wRD0wQVJpY2hmaWVsZCwgTU4gNTU0MjM9MEQ9MEFVbml0 ZWQgU3RhdGVzDQpFTUFJTDtQUkVGO0lOVEVSTkVUOmRlZWxmZXNAdmlzaS5jb20NClJFVjoyMDAx MDExN1QxMjUwMTFaDQpFTkQ6VkNBUkQNCsVbAhCAAQANAAAAREFMRUVFfjEuVkNGAFwDAhGABgCU DQAAAQAJAAADygYAAAAAIQYAAAAABQAAAAEC////AAUAAAAJAgAAAAAEAAAABwEBAGUAAABBC8YA iAAgACAAAAAAACAAIAAAAAAAKAAAACAAAAAgAAAAAQABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAD///8A//////8B///wAB//wAAH/4AAA/+AAAP/gAAAAIAAAACAAAAAgAAAAIAAAACAAAAA gAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAP/gAAD/4AAA/+AAAP/gAAD/4AAA/+A AAP/gAAD/4AAA/+AAAP/gAAD/4AAB/8EAAAABwEBAAUAAAAJAgEAAAAFAAAAAQIBAAAABQAAAAEC ////AAUAAAAJAgAAAAAEAAAABwEDACEGAABBC0YAZgAgACAAAAAAACAAIAAAAAAAKAAAACAAAAAg AAAAAQAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAICAgICAgICAgICAgICAgICAgICAgAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICAgICAgICAgICA gICAgICAgICAgAAAAICAgICAgICAgICAgICAgICAgICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwICAgICAgICAgICAgAAAAMDAwICAgICAgAAAAICAgICA gAAAAMDAwICAgICAgICAgICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAMDAwICAgICAgICAgICAgAAAAAAAAICAgICAgAAAAICAgICAgAAAAAAAAICAgICAgICAgICA gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwICAgAAAAMDAwICA gICAgICAgICAgICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwICAgAAAAAAAAICAgICAgICAgICAgICAgICAgAAA AP8AAP8AAP8AAP8AAP8AAP8AAMDAwMDAwP///////////////////////////////////////wAA AAAAAAAAAMDAwICAgICAgICAgICAgICAgMDAwMDAwMDAwMDAwAAAAP8AAP8AAP8AAP8AAMDAwP// /////////////wAAAP///wAAAAAAAAAAAP///////////////wAAAAAAAAAAAMDAwICAgICAgMDA wMDAwMDAwMDAwICAgMDAwICAgAAAAP8AAP8AAMDAwP////////////////////////////////// /////////////////////////wAAAAAAAAAAAMDAwICAgICAgMDAwAAAAMDAwICAgMDAwICAgMDA wAAAAP8AAMDAwP///////////////////////////wAAAAAAAAAAAP///wAAAP////////////// /wAAAAAAAAAAAMDAwICAgICAgMDAwMDAwMDAwMDAwICAgMDAwICAgAAAAP8AAP////////////// /////////////////////////////////////////////////////wAAAAAAAAAAAMDAwICAgICA gMDAwAAAAMDAwICAgMDAwICAgMDAwAAAAP8AAP////////////////////////////////////// /////////////////////////////wAAAAAAAAAAAMDAwICAgICAgMDAwMDAwMDAwMDAwMDAwMDA wMDAwAAAAP8AAP8AAP///8DAwP///////////////////wAAAAAAAAAAAAAAAP///wAAAP///wAA AP///wAAAAAAAAAAAMDAwICAgICAgAD/AP//AAD/AP//AAD/AP//AAD/AAAAAP8AAP8AAIAAAIAA AIAAAP///////////////////////////////////////////////////wAAAAAAAAAAAMDAwICA gICAgP//AAD/AP//AAD/AP//AAD/AP//AAAAAP8AAP8AAIAAAIAAAIAAAMDAwP///////////wAA AAAAAP///wAAAAAAAP///////////////wAAAAAAAAAAAMDAwICAgICAgAD/AP//AAD/AP//AAD/ AP//AAD/AAAAAP8AAP8AAIAAAIAAAIAAAMDAwP////////////////////////////////////// /////////wAAAAAAAAAAAMDAwICAgICAgP//AAD/AP//AAD/AP//AAD/AP//AAAAAP8AAP8AAP8A AP8AAP8AAP8AAMDAwMDAwP///////////////////////////////////////wAAAAAAAAAAAMDA wICAgICAgAD/AP//AAD/AP//AAD/AP//AAD/AAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8A AP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAAAAAAAAAMDAwICAgICAgP//AAD/AP//AAD/ AP//AAD/AP//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAMDAwICAgICAgAD/AP//AAD/AP//AAD/AP//AAD/AP//AAD/AP// AAD/AP//AAD/AICAgICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AMDAwICAgICAgP//AAD/AP//AAD/AP//AAD/AP//AAD/AP//AAD/AP//AAD/AP//AICAgICAgAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwICAgICAgAD/AP//AAD/ AP//AAD/AP//AAD/AP//AAD/AP//AAD/AP//AAD/AICAgICAgAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwICAgICAgP//AAD/AP//AAD/AP//AAD/AP//AAD/AP// AAD/AP//AAD/AP//AICAgICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAMDAwICAgICAgAD/AP//AAD/AP//AAD/AP//AAD/AP//AAD/AP//AAD/AP//AAD/AICAgICA gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwICAgICAgP//AAD/ AP//AAD/AP//AAD/AP//AAD/AP//AAD/AP//AAD/AP//AICAgICAgAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwICAgICAgAD/AP//AAD/AP//AAD/AP//AAD/AP// AAD/AP//AAD/AP//AAD/AICAgICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAMDAwICAgICAgP//AAD/AP//AAD/AP//AAD/AP//AAD/AP//AAD/AP//AAD/AP//AICA gICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///4CAgICAgICA gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///4CAgICAgICAgICAgICAgICAgICAgICAgICA gICAgICAgICAgICAgICAgACAAICAgICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP///////////////8DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwAD/AACA AACAAMDAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAHAQEABQAAAAkCAQAAAAUAAAABAgEAAAADAAAA AAAmfQIFkAYAhAEAABEAAAADACAORw8AAB4AATABAAAAEgAAAERhbGUgRS4gRWxmZXMudmNmAAAA AgECNwEAAAAAAAAAHgADNwEAAAAFAAAALnZjZgAAAAADAAU3AQAAAB4ABzcBAAAAEgAAAERhbGUg RS4gRWxmZXMudmNmAAAAAwALN/wAAAADAPp/AAAAAEAA+38AQN2jV0WzDEAA/H8AQN2jV0WzDAMA /X8AAAAACwD+fwAAAAADACEOZdkBAAIB+A8BAAAAEAAAAGvoEXzazdQRrcsAoMmB+bICAfoPAQAA ABAAAABr6BF82s3UEa3LAKDJgfmyAgH7DwEAAACCAAAAAAAAADihuxAF5RAaobsIACsqVsIAAFBT VFBSWC5ETEwAAAAAAAAAAE5JVEH5v7gBAKoAN9luAAAAQzpcV0lORE9XU1xMb2NhbCBTZXR0aW5n c1xBcHBsaWNhdGlvbiBEYXRhXE1pY3Jvc29mdFxPdXRsb29rXG91dGxvb2sucHN0AAAAAwD+DwcA AAAkYQ== ------=_NextPart_000_0003_01C1A829.BF655820-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 16:34:10 2002 Delivered-To: freebsd-stable@freebsd.org Received: from sage-american.com (sage-american.com [216.122.141.44]) by hub.freebsd.org (Postfix) with ESMTP id B613537B402 for ; Mon, 28 Jan 2002 16:34:04 -0800 (PST) Received: from SAGEONE (adsl-64-219-20-214.dsl.crchtx.swbell.net [64.219.20.214]) by sage-american.com (8.9.3/8.9.3) with SMTP id SAA07080; Mon, 28 Jan 2002 18:33:34 -0600 (CST) Message-Id: <3.0.5.32.20020128183332.01831ca0@mail.sage-american.com> X-Sender: jacks@mail.sage-american.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 28 Jan 2002 18:33:32 -0600 To: Patrick Greenwell , Matthew Whelan From: jacks@sage-american.com Subject: Re: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] Cc: "M. Warner Losh" , Nate Williams , , , In-Reply-To: <20020128155135.X342-100000@rockstar.stealthgeeks.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Patrick: I truly believe you started a good thread that has certainly gained attention to something I suspect will be treated some day and no doubt -current is the place to start it. I never got into trouble with a lock out with this issue, but was just lucky methinks.... I certainly was doing a degree of guessing initially with the rc after compiling FW into the kernel. But, I set the rc to "open" figuring that would at least keep letting me in while tweaking the rules... Sure those that already know what it does have no problem one way or another, but many more newbies are lined up at the gate.... so who should be bothered the oldies or the newbies...? Wasn't everyone a newbie at some time...? (I didn't mean you JC!) At 03:55 PM 1.28.2002 -0800, Patrick Greenwell wrote: >On Mon, 28 Jan 2002, Matthew Whelan wrote: > >> Isn't this starting to get a bit big a change for -STABLE? (unless you have >> an interim rc.network that understands both the old and new, translates old >> to new, and flashes a big warning that you change, or something :) > >My fault for opening this can of worms on -stable. The discussion/proposed >changes probably do belong on -current. I've just never run a -CURRENT >system and don't subscribe to -current... > > >/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ \/\ > Patrick Greenwell > Stealthgeeks,LLC. Operations Consulting > http://www.stealthgeeks.net >\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ /\/ > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-stable" in the body of the message > > Best regards, Jack L. Stone, Server Admin =================================================== Sage-American http://www.sage-american.com jacks@sage-american.com "My center is giving way, my right is in retreat; ....situation excellent! ....I shall attack!" =================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 17:12:26 2002 Delivered-To: freebsd-stable@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 4C68037B404 for ; Mon, 28 Jan 2002 17:12:21 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id SAA16250; Mon, 28 Jan 2002 18:12:19 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0T1CIi82309; Mon, 28 Jan 2002 18:12:18 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15445.63218.867859.875288@caddis.yogotech.com> Date: Mon, 28 Jan 2002 18:12:18 -0700 To: aefrisch@lorentzian.com Cc: freebsd-stable@FreeBSD.ORG Subject: Re: Seeking tech reviewer In-Reply-To: <3C55E26A.4050906@lorentzian.com> References: <3C55E26A.4050906@lorentzian.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I am the author of a book on UNIX system administration (O'Reilly). We > are looking for someone who knows FreeBSD well who would be interested > in serving as a technical reviewer for the upcoming 3rd edition of the > book, which includes FreeBSd as one of the reference operating systems. > The review period starts immediately, need to be done rather quickly, > and consists of ~1000 pages. How quickly? One week, one day, one month? > Sadly, publishers pay very little for this > sort of thing (a few hundred dollars I think). Of course, reviewers are > acknowledged in the book, and receive the author's tremendous gratitude > and a free copy of the final work. If you are interested in doing this, > please send me email (aefrisch@lorentzian.com). Done. Credentials: 1) One of the original three founders of FreeBSD. 2) Former sys. admin 3) Currently employed as an embedded software developer Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 18:24:45 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mail.lewman.org (lowrider.rootme.org [209.67.240.51]) by hub.freebsd.org (Postfix) with ESMTP id 3788937B416 for ; Mon, 28 Jan 2002 18:24:41 -0800 (PST) Received: by mail.lewman.org (Postfix, from userid 1001) id 38E463D22; Mon, 28 Jan 2002 21:24:40 -0500 (EST) Date: Mon, 28 Jan 2002 21:24:40 -0500 From: Andrew To: stable@freebsd.org Subject: Re: Possible bug in 4.5-RC1 vs VMware (linux emulation?) Message-ID: <20020129022440.GA81699@lowrider.rootme.org> References: <20020127165021.6152b03a.ptiJo@noos.fr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.26i X-phase_of_moon: The Moon is Full Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 28, 2002 at 12:12:58PM -0500, drosih@rpi.edu spewed 1.6K bytes = in 31 lines about: I've actually had a similar problem, except I get a reboot. I've narrowed it down to either vmware or linux emuluation. I disable the cdrom support in vmware at boot, normally. It still reboots right as I should get the vmware phoenix bios screen. This is on a 4.5-RC system with a cvsup as of Sun Jan 27 before 10 am. I've also had problems with the system freezing under heavy network traffic through my dc0 nic. I'm doing about 75mb/s in nfs traffic at the time it locks up. However, I believe it to be due to dc0 be put into promiscuous mode by the vmnet module. I can't recreate these lockups with the vmware modules not loaded. I'm making the assumption it's the vmmon that's doing the promiscuous based on these boot messages: /dev/vmmon: Module vmmon: registered with major=3D200 minor=3D0 tag=3D$Name: build-570 $ /dev/vmmon: Module vmmon: initialized dc0: promiscuous mode enabled vmnet1: promiscuous mode enabled --=20 | Andy | e-mail | web | gpg/pgp keyid | | | andy@lewman.com | www.lewman.com | ED788962 | You're not drunk if you can lie on the floor without holding on. -- Dean Martin --EeQfGwPcQSOJBaQU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE8Vgfoof7Zie14iWIRAnkGAJ9lc+uF1hsdLEGnYHrFFJQ2FiiUPQCfaj+h Nd7GowU3SEYJBc+OH8z8pBM= =7yXn -----END PGP SIGNATURE----- --EeQfGwPcQSOJBaQU-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 18:49:42 2002 Delivered-To: freebsd-stable@freebsd.org Received: from jesus.apogeetelecom.com (jesus.apogeetelecom.com [64.245.60.241]) by hub.freebsd.org (Postfix) with ESMTP id BEADB37B400 for ; Mon, 28 Jan 2002 18:49:36 -0800 (PST) Received: (from eliedtke@localhost) by jesus.apogeetelecom.com (8.11.6/8.11.6) id g0T2nZ631665 for freebsd-stable@freebsd.org; Mon, 28 Jan 2002 20:49:35 -0600 (CST) (envelope-from eliedtke) Date: Mon, 28 Jan 2002 20:49:35 -0600 From: Eric Liedtke To: freebsd-stable@freebsd.org Subject: Linksys WDT11 Problem/Update Message-ID: <20020129024935.GA31653@apogeetelecom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I recently posted that I had a Linksys WDT11 PCI 802.11b adapter working...well I was shuffling parts and machines today and the wireless card got moved to a different machine, which unlike the previous one has a functioning USB controller...so the card started failing with the "No irq?!" message ( the irq it was trying to use was being assigned to the USB controller first) so I started looking around. I found a reference to this in PR30224 which suggests or'ing RF_SHAREABLE in the bus_alloc_resource call (sys/i386/isa/if_wi.c), I tried this out and it seems to work fine, so I, like Peter, was curious what effect this would have on the pcmcia cards using this driver? Thanks -- ----------------------------------------------------------------------- | Eric Liedtke | "In theory, there is no difference | | Sr. Network Engineer | between theory and practice, but, | | Apogee Telecommunications | in practice, there is." | | 512.801.0958 Cl | | | 512.485.8601 Wk | -Jan L.A. van Snepsheut | ----------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 18:52:12 2002 Delivered-To: freebsd-stable@freebsd.org Received: from jesus.apogeetelecom.com (jesus.apogeetelecom.com [64.245.60.241]) by hub.freebsd.org (Postfix) with ESMTP id 4CDD237B402 for ; Mon, 28 Jan 2002 18:52:07 -0800 (PST) Received: (from eliedtke@localhost) by jesus.apogeetelecom.com (8.11.6/8.11.6) id g0T2q6h31688 for freebsd-stable@freebsd.org; Mon, 28 Jan 2002 20:52:06 -0600 (CST) (envelope-from eliedtke) Date: Mon, 28 Jan 2002 20:52:06 -0600 From: Eric Liedtke To: freebsd-stable@freebsd.org Subject: Another Linksys WDT11 problem Message-ID: <20020129025206.GC31653@apogeetelecom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ok, from my last mail I got the card working fine. So it was time to tranfer it to a 3rd machine, my home router, as it's final resting place and I have run into a new problem....I am getting a error message of wi0: mac read failed 5 I poked around in the code a little bit, but couldn't come up with anything of use. I am not sure how to go about troubleshooting this from here, so any advice would be great. Thanks -- ----------------------------------------------------------------------- | Eric Liedtke | "In theory, there is no difference | | Sr. Network Engineer | between theory and practice, but, | | Apogee Telecommunications | in practice, there is." | | 512.801.0958 Cl | | | 512.485.8601 Wk | -Jan L.A. van Snepsheut | ----------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 19: 6:10 2002 Delivered-To: freebsd-stable@freebsd.org Received: from hsd.com.au (CPE-144-132-42-44.vic.bigpond.net.au [144.132.42.44]) by hub.freebsd.org (Postfix) with ESMTP id EF54237B419 for ; Mon, 28 Jan 2002 19:05:46 -0800 (PST) Received: from ariel by hsd.com.au with SMTP (MDaemon.v3.0.1.R) for ; Tue, 29 Jan 2002 14:04:58 +1100 Reply-To: From: "Andrew Cowan" To: "Nate Williams" Cc: "Freebsd-Stable" Subject: RE: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] Date: Tue, 29 Jan 2002 14:04:57 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <15445.54755.551301.284078@caddis.yogotech.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-MDaemon-Deliver-To: freebsd-stable@FreeBSD.ORG X-Return-Path: andrew.cowan@hsd.com.au X-MDRcpt-To: freebsd-stable@FreeBSD.ORG Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Sorry, but: ipfw_enable=no ipfw_firewall_enable=yes Will still be confusing to newbies. I had to read the descriptions to see what they did as they should like they do the same thing. It is really to much work to change the script variable names in current, so that they relate exactly to what they do? eg. ipfw_load_firewall_rules={yes,no} ipfw_firewall_rules_file={open,simple,etc,/etc/myfirewall.rule} If ipfw_firewall_rules_file is not specified then it does not load one. (defaults to kernel setting or deny_all I think) If ipfw_load_firewall_rules is no then module is not loaded (handles ipfw not in kernel) (The ipfw_load_firewall_rules could be replaced by checking if the file is specified, but it would be too confusing again) Could old and new variables be used to handle the transition. I just don't like the idea of not fixing something that needs it. As long as it handle old configs then its fine right? To summarise: 1. Functionality of system is not changed. 2. Configuration is made consistent with functionality. 3. System is backwards compatible with old configurations via adding new variables rather than the changing of old ones. (just requires duplication of code in network script) 4. Version 5 will soon replace 4 - this is as good an opportunity as we'll ever get. The old script variables can be made defunct in 5 if you wish I appologise if parts of this have been said elsewhere, I just wanted to put my view across. Regards, Andrew Cowan > > > > : Yes, and I think having this is a good thing. However, what are the > > : default values for the variables? > > > > In previous mail I suggested: > > > > ipfw_enable=no > > ipfw_firewall_enable=yes > > Gotcha, I confused ipfw_enable with ipfw_firewall_enable. > Unfortunately, it's not obvious which one the users should use to enable > the functionality. > > Now we have two variables that *appear* to be redundant.... > > > Nate > > 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 From owner-freebsd-stable Mon Jan 28 19:19:34 2002 Delivered-To: freebsd-stable@freebsd.org Received: from veldy.net (veldy-host33.dsl.visi.com [209.98.200.33]) by hub.freebsd.org (Postfix) with ESMTP id 9AADF37B417 for ; Mon, 28 Jan 2002 19:19:24 -0800 (PST) Received: from cascade (cascade.veldy.net [192.168.1.1]) by veldy.net (Postfix) with SMTP id B89411A187; Mon, 28 Jan 2002 21:19:23 -0600 (CST) Message-ID: <001e01c1a873$bdf12f10$0101a8c0@cascade> From: "Thomas T. Veldhouse" To: , "Nate Williams" Cc: "Freebsd-Stable" References: Subject: Re: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] Date: Mon, 28 Jan 2002 21:19:19 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG What would the expected functionality be for this? ipfw_enable=no ipfw_firewall_enable=yes And what would the expected funcationality be for this? ipfw_enable=yes ipfw_firewall_enable=no I would expect the former to not load the ipfw module, so what does the firewall enable option do? I would expect the latter to load the ipfw module and the latter to not run the firewall script. Seems to make sense, except what happens when you have IPFIREWALL built into the kernel? Tom Veldhouse veldy@veldy.net ----- Original Message ----- From: "Andrew Cowan" To: "Nate Williams" Cc: "Freebsd-Stable" Sent: Monday, January 28, 2002 9:04 PM Subject: RE: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] > Sorry, but: > > ipfw_enable=no > ipfw_firewall_enable=yes > > Will still be confusing to newbies. I had to read the descriptions to see > what they did as they should like they do the same thing. It is really to > much work to change the script variable names in current, so that they > relate exactly to what they do? > eg. > > ipfw_load_firewall_rules={yes,no} > ipfw_firewall_rules_file={open,simple,etc,/etc/myfirewall.rule} > > If ipfw_firewall_rules_file is not specified then it does not load one. > (defaults to kernel setting or deny_all I think) > If ipfw_load_firewall_rules is no then module is not loaded (handles ipfw > not in kernel) > (The ipfw_load_firewall_rules could be replaced by checking if the file is > specified, but it would be too confusing again) > > Could old and new variables be used to handle the transition. I just don't > like the idea of not fixing something that needs it. As long as it handle > old configs then its fine right? > > To summarise: > > 1. Functionality of system is not changed. > 2. Configuration is made consistent with functionality. > 3. System is backwards compatible with old configurations > via adding new variables rather than the changing of > old ones. (just requires duplication of code in > network script) > 4. Version 5 will soon replace 4 - this is as good an > opportunity as we'll ever get. The old script variables > can be made defunct in 5 if you wish > > I appologise if parts of this have been said elsewhere, I just wanted to put > my view across. > > Regards, > > Andrew Cowan > > > > > > > > > > : Yes, and I think having this is a good thing. However, what are the > > > : default values for the variables? > > > > > > In previous mail I suggested: > > > > > > ipfw_enable=no > > > ipfw_firewall_enable=yes > > > > Gotcha, I confused ipfw_enable with ipfw_firewall_enable. > > Unfortunately, it's not obvious which one the users should use to enable > > the functionality. > > > > Now we have two variables that *appear* to be redundant.... > > > > > > Nate > > > > 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 19:42:37 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mail.rz.uni-ulm.de (gemini.rz.uni-ulm.de [134.60.246.16]) by hub.freebsd.org (Postfix) with ESMTP id B9D1737B417 for ; Mon, 28 Jan 2002 19:42:30 -0800 (PST) Received: from lilith (lilith.wh-wurm.uni-ulm.de [134.60.106.64]) by mail.rz.uni-ulm.de (8.12.1/8.12.1) with SMTP id g0T3gTxQ013630 for ; Tue, 29 Jan 2002 04:42:29 +0100 (MET) Message-ID: <008001c1a877$091c2aa0$4011a8c0@whwurm.uniulm.de> From: "Siegbert Baude" To: References: <15445.37204.693732.376471@caddis.yogotech.com> <20020128150458.E10891-100000@charon.acheron.localnet> <15445.46625.765383.179068@caddis.yogotech.com> <20020128223911.GA7080@rhadamanth> Subject: Summary: Problems and Proposals of firewall_enable (was: Re: firewall config (CTFM)) Date: Tue, 29 Jan 2002 04:42:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello folks, thanks to Ceri, Erik, Richard and Warner, who made the points, I'm repeating here with a slight addition of mine. In media res: comparing defaults/rc.conf and "man rc.conf": defaults/rc.conf: firewall_enable="NO" # Set to YES to enable firewall functionality man rc.conf: firewall_enable (bool) Set to ``NO'' if you do not want have firewall rules loaded at startup, or ``YES'' if you do. If set to ``YES'', and the kernel was not built with IPFIREWALL, the ipfw kernel module will be loaded. See also ipfilter_enable. Problem 1: The variable's main function is about loading rule sets, as clearly indicated in the man page, but the name is stressing the less important part of loading the kernel module. Problem 2: The comment in defaults/rc.conf even enforces the misleading name as it talks about functionality, which is only true in case of using the kernel module, but not in the case of compiled in IPFIREWALL. To mention functionality really is a bug, as someone said: firewall_enable is about the operation not the state (which is equivalent to functionality in this case)! Problem 3: Neither man page nor defaults/rc.conf mentions the possibility of locking yourself out with compiled in IPFIREWALL without additional ruleset, as the kernel defaults to "deny all" (which is not obvious at all, but is secure and therefore should be kept as is). Problem 4: Maybe only my ignorance, because I never did it: How do I find out before reboot, if IPFIREWALL is compiled in my kernel, if the relevant config file is not there, e.g. on very stripped installations, where make buildworld/-kernel is done on external machines? We all know the lack of documentation in the real admin's world. Verbal heritage between admin generations is sometimes suboptimal, too. Don't forget compiling kernel with IPFIREWALL to be the recommended way, as someone mentioned in this thread! So this should be found in numerous computers. Steps to be taken: To solve Problem 2, Ceri's suggestion to change the comment in defaults/rc.conf is very good. I just added one remark and used capital letters as warning like in LINT/NOTES: firewall_enable="NO" # Set to YES: 1) to load firewall rulesets. # 2) to load kernel module, if needed. # Set to NO: CAN LOCK YOU OUT, if you have # IPFIREWALL compiled in your kernel! This could be done immediately without any bad consequences. The hint should make users read more documentation, before they shoot themselves in the foot. To solve problem 3 and 4, somebody *duck* has to add some phrases in the rc.conf manpage. To solve problem 1, the short term solution is to rename "firewall_enable" with "firewall_rules_load". The comment YES/2) should probably be altered to: "This implies loading the kernel module, if needed." Long term solution #1: Use Warner's improved scripts suggested some mails before, but _please_: Name the variable "firewall_functionality", what Warner called "firewall_enable"! This is so much clearer. Long term solution #2: Rethink the variables with having two different methods in mind, i.e. ipfw and ipfilter. Should be in the line of (capital letters denote defaults): firewall_functionality on/OFF firewall_method ipfilter/IPFW firewall_ruleset UNKNOWN #see /etc/rc.firewall * firewall_ruleset_load on/OFF #always OFF if ruleset==UNKNOWN * firewall_kernel_overrule ON/off #will overrule firewall_functionality #if IPFIREWALL is compiled in kernel ** some_ipfw/ipfilter_specifics #as already is *: This is in accordance to Warner's point, that compiled in kernel rules, shouldn't be touched unless explicitly wanted. This should be true not only for IPFIREWALL but also for IPFIREWALL_DEFAULT_TO_ACCEPT. "firewall_ruleset" replaces "firewall_type". With firewall_ruleset_load the method UNKNOWN maybe is dispensable and should be replaced with "filename" pointing to a standard place in /etc . Possibility: throw out the types, but instead create some equivalent standard rulesets. Similar to the cvsup examples. DEFAULT to something useful then, of course. **: This is in accordance to Warner's point, that the fallback of admin's error with firewall_functionality shouldn't disable the kernel firewall. So if you accidentally turn firewall_functionality to OFF, you will still have your kernel firewall enabled (note the default ON of overrule). Enough security Warner? I think you can also imagine situations, where you want kernel firewall disabled on reboot. It is better to keep things in one place, so we need this one instead of some sysctl tweaking in other places. If some admin changes both variables accidentally, he deserves to have his pants^h^h^h^h^hfirewall down. :-) As I never fiddle with CURRENT, it's up to security and core team to decide, which steps could be taken when and where (CURRENT or STABLE). Has the discussion to be continued on the stable list? Ciao Siegbert To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 20:15:52 2002 Delivered-To: freebsd-stable@freebsd.org Received: from guru.mired.org (dsl-64-192-6-133.telocity.com [64.192.6.133]) by hub.freebsd.org (Postfix) with SMTP id 997EE37B402 for ; Mon, 28 Jan 2002 20:15:47 -0800 (PST) Received: (qmail 65609 invoked by uid 100); 29 Jan 2002 04:15:43 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15446.8687.379406.482030@guru.mired.org> Date: Mon, 28 Jan 2002 22:15:43 -0600 To: nate@yogotech.com (Nate Williams) Cc: stable@FreeBSD.ORG Subject: Re: Firewall config non-intuitiveness In-Reply-To: <15445.44102.288461.155113@caddis.yogotech.com> References: <200201271757.g0RHvTF12944@midway.uchicago.edu> <1617.216.153.202.59.1012240332.squirrel@www1.27in.tv> <20020128192930.GA86720@student.uu.se> <15445.44102.288461.155113@caddis.yogotech.com> X-Mailer: VM 6.90 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ From: "Mike Meyer" X-Delivery-Agent: TMDA/0.44 (Python 2.2; freebsd-4.5-RC-i386) Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nate Williams types: > > Note that "do not enable firewall" (which is implied by firewall_enable="NO") > > is *not* equivalent to "disable firewall". > Maybe we're having an English language question. I'd say you are. > If something isn't enabled, doesn't that imply that it's disabled? Last > I checked, enabled/disabled were binary operations. No. Failing to enable something doesn't mean that you disable it. Those are both actions. It's also possible that to take no action whatsoever. Tanya Harding disabled Nancy Kerrigan. Nobody else in the world disabled her. By your logic, they all must therefore have enabled her, which clearly isn't the case. Most of them did nothing. A small number of people did the things necessary to enable her to skate again. That said, I don't really have an objection to changing the variable name, or making it tristated, or some such to avoid this confusion. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message From owner-freebsd-stable Mon Jan 28 20:18:22 2002 Delivered-To: freebsd-stable@freebsd.org Received: from voi.aagh.net (pc1-hart4-0-cust168.mid.cable.ntl.com [62.254.84.168]) by hub.freebsd.org (Postfix) with ESMTP id BA8B437B402 for ; Mon, 28 Jan 2002 20:18:13 -0800 (PST) Received: from freaky by voi.aagh.net with local (Exim 3.34 #1) id 16VPid-000IRp-00; Tue, 29 Jan 2002 04:18:03 +0000 Date: Tue, 29 Jan 2002 04:18:03 +0000 From: Thomas Hurst To: Andrew Cowan Cc: Nate Williams , Freebsd-Stable Subject: Re: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] Message-ID: <20020129041803.GA69785@voi.aagh.net> Mail-Followup-To: Andrew Cowan , Nate Williams , Freebsd-Stable References: <15445.54755.551301.284078@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Organization: Not much. X-Operating-System: FreeBSD/4.5-PRERELEASE (i386) X-Uptime: 3:23AM up 39 days, 12:08, 4 users, load averages: 2.11, 2.04, 2.01 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Andrew Cowan (andrew.cowan@hsd.com.au) wrote: > It is really to much work to change the script variable names in > current, so that they relate exactly to what they do? eg. > ipfw_load_firewall_rules={yes,no} > ipfw_firewall_rules_file={open,simple,etc,/etc/myfirewall.rule} The -stable firewalls are scripts, not rule files. Rule files are a different thing again :) > If ipfw_firewall_rules_file is not specified then it does not load > one. (defaults to kernel setting or deny_all I think) Except ipfw_firewall_rules_file=open specifies a firewall *type*, not a file. > If ipfw_load_firewall_rules is no then module is not loaded (handles > ipfw not in kernel) > (The ipfw_load_firewall_rules could be replaced by checking if the > file is specified, but it would be too confusing again) We have a lot of different things being piled into these variables. We've got: * Disabled * Default rule names (open, simple, closed, ..) * Rule files * Firewall scripts These are currently handled like this: firewall_enable={yes, no} firewall_type={open, simple, closed .., /some/rule/file} firewall_script={/etc/rc.firewall, /some/firewall/script} I think it's fairly plain to see these are rather ugly, even without going into a discussion about what enabled actually means. How about something more along the lines of: ipfw_enable = {yes, no} ipfw_type = {script, rule, builtin} ipfw_rule = {/path/to/rule/file} ipfw_script = {/path/to/script} ipfw_builtin = {open, closed, simple, client} You could merge ipfw_enable with ipfw_type, but then you loose the generic YES/NO and the entire _enable looses it's meaning, which is customary throughout rc.conf. Aren't we reworking the rc system in -CURRENT anyway? This looks like something to start playing with there. > Could old and new variables be used to handle the transition. I just > don't like the idea of not fixing something that needs it. As long as > it handle old configs then its fine right? Frankly, I think we need to concentrate on making all these changes to -CURRENT; that's a big enough version difference to fix things *properly* without worrying about breaking Joe User's -STABLE config. > 3. System is backwards compatible with old configurations > via adding new variables rather than the changing of > old ones. (just requires duplication of code in > network script) The way builtin firewalls are handled atm means people need to edit rc.firewall themselves to configure them.. I'd be careful about making major changes that might not merge very easily. CURRENT, of course, should pork away and move the individual scripts to /etc/ipfw/