From owner-freebsd-current Sun Feb 25 00:05:16 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA18889 for current-outgoing; Sun, 25 Feb 1996 00:05:16 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA18884 for ; Sun, 25 Feb 1996 00:05:14 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tqbSB-0003wVC; Sun, 25 Feb 96 00:05 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id JAA08396; Sun, 25 Feb 1996 09:05:24 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: Nate Williams cc: current@FreeBSD.org Subject: Re: New Dual-personality crypt In-reply-to: Your message of "Sun, 25 Feb 1996 00:27:06 MST." <199602250727.AAA26800@rocky.sri.MT.net> Date: Sun, 25 Feb 1996 09:05:22 +0100 Message-ID: <8394.825235522@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.org Precedence: bulk > How do I force it to generate old-style DES passwords in spite of what > the old passwords were, short of removing the password completely and > then re-generating passwords? Shouldn't the new routine 'generate' > passwords using the default routines, but read passwords from both? passwd should read the preferred type from /etc/default/passwd or possibly /etc/default/login... It doesn't. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Sun Feb 25 00:07:51 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA18989 for current-outgoing; Sun, 25 Feb 1996 00:07:51 -0800 (PST) Received: from grumble.grondar.za (root@grumble.grondar.za [196.7.18.130]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA18982 for ; Sun, 25 Feb 1996 00:07:45 -0800 (PST) Received: from grumble.grondar.za (mark@localhost [127.0.0.1]) by grumble.grondar.za (8.7.3/8.7.3) with ESMTP id KAA20978; Sun, 25 Feb 1996 10:07:22 +0200 (SAT) Message-Id: <199602250807.KAA20978@grumble.grondar.za> To: Nate Williams cc: current@FreeBSD.org Subject: Re: New Dual-personality crypt Date: Sun, 25 Feb 1996 10:07:22 +0200 From: Mark Murray Sender: owner-current@FreeBSD.org Precedence: bulk Nate Williams wrote: > How can I force my passwords to be the old DES crypt function on a box > that previously used MD5 crypt? There are only two accounts on it (mine > and root), but I'd like it to use DES like all of the other machines in > the group. This was a design point that I could not quite decide on. I decided to go the route-of-least-change and keep the encryption algorithm that was used to make the entry in the first place. > Even after I've re-run passwd after installing the new libraries and > binaries, it's still generating MD5 passwords instead of DES passwords. I have been slowly getting round to putting a option in passwd(1) to allow the user to select the encryption algorithm, but I am not too sure how to deal with the case of the system without DES. I'm sure I can come up with something. > How do I force it to generate old-style DES passwords in spite of what > the old passwords were, short of removing the password completely and > then re-generating passwords? Shouldn't the new routine 'generate' > passwords using the default routines, but read passwords from both? See above. I'd greatly appreciate some input on this. I'm kinda prepared to go either way once I have some sort of idea what the group would prefer. In the meanwhile, it is unfortunately only possible to force DES by removing the old MD5 password. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grondar.za for PGP key From owner-freebsd-current Sun Feb 25 00:21:28 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA19370 for current-outgoing; Sun, 25 Feb 1996 00:21:28 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA19359 for ; Sun, 25 Feb 1996 00:21:19 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id TAA09810; Sun, 25 Feb 1996 19:19:23 +1100 Date: Sun, 25 Feb 1996 19:19:23 +1100 From: Bruce Evans Message-Id: <199602250819.TAA09810@godzilla.zeta.org.au> To: jhay@mikom.csir.co.za, pst@shockwave.com Subject: Re: Bug in libc/db/hash/hash.c??? Cc: freebsd-current@freebsd.org Sender: owner-current@freebsd.org Precedence: bulk >> Well, I haven't seen it happen here yet, perhaps it only breaks if the water >> in your drain goes the wrong way? Actually, the only reason I could imagine >:-) I thought my computer didn't know that. :-) >> ... >> I've put up on freefall a new revision of hash.c, >> try http://freefall.cdrom.com/~pst/hash.c >> >> This postpones the stat until you've successfully opened the file and then >> just does a fstat. I don't like it, because it adds additional syscall >> overhead, but wtf. >> > >OK, I tried this one and it does work correctly now. I'm not sure how postponing the stat helps. The problem seems to be with concurrent accesses to the database. First cap_mkdb opens it and it gets initialized. This hasn't changed. Then the getcap library opens it and it gets initialized again because the file length is 0. Oops. I noticed a(nother) Heisenbug in the old code. statbuf.st_size isn't initialized if stat() fails. This only matters if stat() fails with an error other than ENOENT. (There is a similar bug involving errno.) Bruce From owner-freebsd-current Sun Feb 25 05:28:51 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA29957 for current-outgoing; Sun, 25 Feb 1996 05:28:51 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA29948 for ; Sun, 25 Feb 1996 05:28:46 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id OAA17140; Sun, 25 Feb 1996 14:28:21 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id OAA04948; Sun, 25 Feb 1996 14:28:20 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.3/8.6.9) id OAA15589; Sun, 25 Feb 1996 14:16:03 +0100 (MET) From: J Wunsch Message-Id: <199602251316.OAA15589@uriah.heep.sax.de> Subject: Re: NIC memory correupt on SMC8013EPC To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 25 Feb 1996 14:16:02 +0100 (MET) Cc: roberto@keltia.freenix.fr (Ollivier Robert) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199602241542.QAA00279@keltia.freenix.fr> from "Ollivier Robert" at Feb 24, 96 04:42:42 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org Precedence: bulk As Ollivier Robert wrote: > ed0: NIC memory corrupt - invalid packet length 9984 > It is in 0xbc000 because the diag program complained when I put it > elsewhere. In 0xcc000 (as was another 8013 a while ago before it died), it > would refuse to work. 0xbc000 falls into the area reserved for the video frame buffer (0xa0000 ... 0xbffff). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Feb 25 07:10:27 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA02597 for current-outgoing; Sun, 25 Feb 1996 07:10:27 -0800 (PST) Received: from fieber-john.campusview.indiana.edu (Fieber-John.campusview.indiana.edu [149.159.1.34]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA02592 for ; Sun, 25 Feb 1996 07:10:24 -0800 (PST) Received: (from jfieber@localhost) by fieber-john.campusview.indiana.edu (8.6.12/8.6.12) id KAA06967; Sun, 25 Feb 1996 10:09:45 -0500 Date: Sun, 25 Feb 1996 10:09:45 -0500 (EST) From: John Fieber X-Sender: jfieber@fieber-john.campusview.indiana.edu To: Mark Murray cc: Nate Williams , current@FreeBSD.org Subject: Re: New Dual-personality crypt In-Reply-To: <199602250807.KAA20978@grumble.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org Precedence: bulk On Sun, 25 Feb 1996, Mark Murray wrote: > I have been slowly getting round to putting a option in passwd(1) > to allow the user to select the encryption algorithm, but I am not Just a random opinion here, but I think the choice should be up to the sysadmin, not the user. If you choose to make it a user option, then give the sysadmin veto power. -john == jfieber@indiana.edu =========================================== == http://fieber-john.campusview.indiana.edu/~jfieber ============ From owner-freebsd-current Sun Feb 25 08:21:13 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA05112 for current-outgoing; Sun, 25 Feb 1996 08:21:13 -0800 (PST) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id IAA05104 for ; Sun, 25 Feb 1996 08:21:08 -0800 (PST) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) id RAA08443 for current@freebsd.org; Sun, 25 Feb 1996 17:15:17 +0100 (MET) Received: (from andreas@localhost) by knobel.gun.de (8.7.4/8.7.3) id RAA00217 for current@freebsd.org; Sun, 25 Feb 1996 17:07:45 +0100 (MET) From: Andreas Klemm Message-Id: <199602251607.RAA00217@knobel.gun.de> Subject: -current breaks shell and tset To: current@freebsd.org Date: Sun, 25 Feb 1996 17:07:44 +0100 (MET) X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk Hi ! I have big trouble with FreeBSD-current after supping it yesterday. When I try to login, tset isn't able to set the correct terminal type. If I try to do a simple # cd / I get the message: chdir: Too many arguments. My tcsh (even after rebuild in single user mode from the ports collection) isn't useable... Only in single user mode I'm currently able to to things with the shell. But tset doesn't work in single user mode, too. Heeeeeellllppp ;-) It's my one and only system here. Andreas /// andreas@knobel.gun.de /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ $$ Support Unix - aklemm@wup.de $$ pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< "Ich bleibe bei der Aussage und trotze den Flames. :-)" Ulli Horlacher 02/96 From owner-freebsd-current Sun Feb 25 09:19:47 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA06991 for current-outgoing; Sun, 25 Feb 1996 09:19:47 -0800 (PST) Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA06986 for ; Sun, 25 Feb 1996 09:19:43 -0800 (PST) Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.6.12/8.6.9) id SAA26010; Sun, 25 Feb 1996 18:57:32 +0200 From: John Hay Message-Id: <199602251657.SAA26010@zibbi.mikom.csir.co.za> Subject: Re: -current breaks shell and tset To: andreas@knobel.gun.de (Andreas Klemm) Date: Sun, 25 Feb 1996 18:57:32 +0200 (SAT) Cc: current@FreeBSD.org In-Reply-To: <199602251607.RAA00217@knobel.gun.de> from "Andreas Klemm" at Feb 25, 96 05:07:44 pm X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org Precedence: bulk Hi, That is the problem that I reported with lib/libc/db/hash/hash.c. There was a fix commited already so if you sup again you should get it. To get going in the meantime, I think you should be able to delete /usr/share/misc/termcap.db. The termcap routines should fall back to using the text file. John -- John Hay -- John.Hay@csir.co.za > > Hi ! > > I have big trouble with FreeBSD-current after supping it > yesterday. > > When I try to login, tset isn't able to set the correct > terminal type. > > If I try to do a simple > # cd / > I get the message: > chdir: Too many arguments. > > My tcsh (even after rebuild in single user mode from the > ports collection) isn't useable... > > Only in single user mode I'm currently able to to things > with the shell. > > But tset doesn't work in single user mode, too. > > Heeeeeellllppp ;-) It's my one and only system here. > > Andreas /// > > andreas@knobel.gun.de /\/\___ Wiechers & Partner Datentechnik GmbH > Andreas Klemm ___/\/\/ $$ Support Unix - aklemm@wup.de $$ > pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< > ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< > "Ich bleibe bei der Aussage und trotze den Flames. :-)" Ulli Horlacher 02/96 > From owner-freebsd-current Sun Feb 25 10:10:20 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA09510 for current-outgoing; Sun, 25 Feb 1996 10:10:20 -0800 (PST) Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA09503 for ; Sun, 25 Feb 1996 10:10:18 -0800 (PST) Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD4.4) id FAA00531; Mon, 26 Feb 1996 05:09:46 +1100 From: michael butler Message-Id: <199602251809.FAA00531@asstdc.scgt.oz.au> Subject: Re: -current breaks shell and tset To: andreas@knobel.gun.de (Andreas Klemm) Date: Mon, 26 Feb 1996 05:09:44 +1100 (EST) Cc: current@freebsd.org In-Reply-To: <199602251607.RAA00217@knobel.gun.de> from "Andreas Klemm" at Feb 25, 96 05:07:44 pm X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk Andreas Klemm writes: > If I try to do a simple > # cd / > I get the message: > chdir: Too many arguments. > My tcsh (even after rebuild in single user mode from the > ports collection) isn't useable... This is another non-obvious side-effect of the broken lib/libc/db/hash/hash.c which also broke -stable completely. You have to get a fixed version, remake termcap and anything else that was statically linked with libc :-( On -stable (since I backed out of running -current for precisely this kind of instability) reversing out the change does not appear to fix kvm_mkdb (and probably more) .. ps only spits out process names in parentheses. But then, the -stable kernel doesn't even boot any more here .. michael From owner-freebsd-current Sun Feb 25 10:42:35 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA11093 for current-outgoing; Sun, 25 Feb 1996 10:42:35 -0800 (PST) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA11086 for ; Sun, 25 Feb 1996 10:42:28 -0800 (PST) Received: from localhost.shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.4/8.7.3) with SMTP id KAA15438; Sun, 25 Feb 1996 10:40:53 -0800 (PST) Message-Id: <199602251840.KAA15438@precipice.shockwave.com> To: Bruce Evans cc: jhay@mikom.csir.co.za, freebsd-current@freebsd.org Subject: Re: Bug in libc/db/hash/hash.c??? In-reply-to: Your message of "Sun, 25 Feb 1996 19:19:23 +1100." <199602250819.TAA09810@godzilla.zeta.org.au> Date: Sun, 25 Feb 1996 10:40:51 -0800 From: Paul Traina Sender: owner-current@freebsd.org Precedence: bulk From: Bruce Evans Subject: Re: Bug in libc/db/hash/hash.c??? I'm not sure how postponing the stat helps. The problem seems to be with concurrent accesses to the database. First cap_mkdb opens it and it gets initialized. This hasn't changed. Then the getcap library opens it and it gets initialized again because the file length is 0. Oops. I'm not sure what code you're looking at, but that doesn't match my version of cap_mkdb. There is no getcap library code linked with this file, it's merely opened once, with flags O_CREAT | O_TRUNC, no more. I noticed a(nother) Heisenbug in the old code. statbuf.st_size isn't initialized if stat() fails. This only matters if stat() fails with an error other than ENOENT. (There is a similar bug involving errno.) Yes, which is why I changed it to a fstat and I only check statbuf.st_size if the fstat succeeded. Again, I did not save/restore errno because a perusal of the surrounding code shows that it's in an indeterminate state at that point (that is, there are calls immediately following it that would change the state). Now, the big question: "Is there still a bug with this?" Even if cap_mkdb doesn't do what you suggest, what happens if someone /does/ do concurrent opens of a file? You're correct, there -is- a race condition for the window between the open and the first hash_sync. We could either reduce that window by doing an initial hash_sync immediately after the table is initialized (yuck for two reasons), or toss this entire idea as being bad and revert back to pre-pst code. I don't have any brilliant ideas on how to do this, because if we implement locking, we'll break semantics further elsewhere. From owner-freebsd-current Sun Feb 25 11:16:28 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA12858 for current-outgoing; Sun, 25 Feb 1996 11:16:28 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA12845 for ; Sun, 25 Feb 1996 11:16:19 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id GAA31346; Mon, 26 Feb 1996 06:11:11 +1100 Date: Mon, 26 Feb 1996 06:11:11 +1100 From: Bruce Evans Message-Id: <199602251911.GAA31346@godzilla.zeta.org.au> To: bde@zeta.org.au, pst@shockwave.com Subject: Re: Bug in libc/db/hash/hash.c??? Cc: freebsd-current@freebsd.org, jhay@mikom.csir.co.za Sender: owner-current@freebsd.org Precedence: bulk > I'm not sure how postponing the stat helps. The problem seems to be > with concurrent accesses to the database. First cap_mkdb opens it and > it gets initialized. This hasn't changed. Then the getcap library > opens it and it gets initialized again because the file length is 0. > Oops. >I'm not sure what code you're looking at, but that doesn't match my version >of cap_mkdb. There is no getcap library code linked with this file, it's >merely opened once, with flags O_CREAT | O_TRUNC, no more. I'm looking at the standard version of cap_mkdb.c, which hasn't changed since 4.4lite. It calls cgetnext(). > I noticed a(nother) Heisenbug in the old code. statbuf.st_size isn't > initialized if stat() fails. This only matters if stat() fails with > an error other than ENOENT. (There is a similar bug involving errno.) >Yes, which is why I changed it to a fstat and I only check statbuf.st_size >if the fstat succeeded. Again, I did not save/restore errno because a >perusal of the surrounding code shows that it's in an indeterminate state >at that point (that is, there are calls immediately following it that would >change the state). I think the fix works because the O_CREAT flag is now honoured (perhaps it should check O_TRUNC too?). I think the database was messed up when cgetnext() opened it without (O_CREAT | O_TRUNC). >Now, the big question: "Is there still a bug with this?" Even if cap_mkdb >doesn't do what you suggest, what happens if someone /does/ do concurrent >opens of a file? You're correct, there -is- a race condition for the window >between the open and the first hash_sync. We could either reduce that window >by doing an initial hash_sync immediately after the table is initialized >(yuck for two reasons), or toss this entire idea as being bad and revert >back to pre-pst code. I doubt that the old way survived concurrent opens. The second opener got an empty database if the first opener hasn't synced anything. How could that work? I think it usually gets read error early, so it usually fails safely. Worse can probably happen if the first opener the database is half written. You've certainly introduced a new race, but I wouldn't worry about it especially. There must be more opportunities to read inconsistent data while the database is being updated. Bruce From owner-freebsd-current Sun Feb 25 11:28:55 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA13273 for current-outgoing; Sun, 25 Feb 1996 11:28:55 -0800 (PST) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA13268 for ; Sun, 25 Feb 1996 11:28:53 -0800 (PST) Received: from localhost.shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.4/8.7.3) with SMTP id LAA00548; Sun, 25 Feb 1996 11:28:15 -0800 (PST) Message-Id: <199602251928.LAA00548@precipice.shockwave.com> To: Bruce Evans cc: freebsd-current@freebsd.org, jhay@mikom.csir.co.za Subject: Re: Bug in libc/db/hash/hash.c??? In-reply-to: Your message of "Mon, 26 Feb 1996 06:11:11 +1100." <199602251911.GAA31346@godzilla.zeta.org.au> Date: Sun, 25 Feb 1996 11:28:15 -0800 From: Paul Traina Sender: owner-current@freebsd.org Precedence: bulk From: Bruce Evans Subject: Re: Bug in libc/db/hash/hash.c??? > I'm not sure how postponing the stat helps. The problem seems to be > with concurrent accesses to the database. First cap_mkdb opens it and > it gets initialized. This hasn't changed. Then the getcap library > opens it and it gets initialized again because the file length is 0. > Oops. >I'm not sure what code you're looking at, but that doesn't match my version >of cap_mkdb. There is no getcap library code linked with this file, it's >merely opened once, with flags O_CREAT | O_TRUNC, no more. I'm looking at the standard version of cap_mkdb.c, which hasn't changed since 4.4lite. It calls cgetnext(). Yep, sorry, missed the implicit open there. > I noticed a(nother) Heisenbug in the old code. statbuf.st_size isn't > initialized if stat() fails. This only matters if stat() fails with > an error other than ENOENT. (There is a similar bug involving errno.) >Yes, which is why I changed it to a fstat and I only check statbuf.st_size >if the fstat succeeded. Again, I did not save/restore errno because a >perusal of the surrounding code shows that it's in an indeterminate state >at that point (that is, there are calls immediately following it that would >change the state). I think the fix works because the O_CREAT flag is now honoured (perhaps it should check O_TRUNC too?). I think the database was messed up when cgetnext() opened it without (O_CREAT | O_TRUNC). Do you mean it should require both O_CREAT and O_TRUNC or either? If either, that case is covered earlier. I'm not certain both should be required if the file is already 0 sized. However, I'm easy going, whichever you want is fine by me, just as long as you clarify what you want. :-) >Now, the big question: "Is there still a bug with this?" Even if cap_mkdb >doesn't do what you suggest, what happens if someone /does/ do concurrent >opens of a file? You're correct, there -is- a race condition for the window >between the open and the first hash_sync. We could either reduce that windo >>w >by doing an initial hash_sync immediately after the table is initialized >(yuck for two reasons), or toss this entire idea as being bad and revert >back to pre-pst code. I doubt that the old way survived concurrent opens. The second opener got an empty database if the first opener hasn't synced anything. How could that work? I think it usually gets read error early, so it usually fails safely. Worse can probably happen if the first opener the database is half written. You've certainly introduced a new race, but I wouldn't worry about it especially. There must be more opportunities to read inconsistent data while the database is being updated. Yeah, it looks like paging to disk is rather asynchronous in nature. In my opinion, the whole damn thing should internally be protected with advisory locks, but that completely breaks ndbm semantics where the callers expect to have to lock the database themselves. Sigh. From owner-freebsd-current Sun Feb 25 11:56:28 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA15068 for current-outgoing; Sun, 25 Feb 1996 11:56:28 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA15056 for ; Sun, 25 Feb 1996 11:56:19 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id GAA32445; Mon, 26 Feb 1996 06:54:00 +1100 Date: Mon, 26 Feb 1996 06:54:00 +1100 From: Bruce Evans Message-Id: <199602251954.GAA32445@godzilla.zeta.org.au> To: bde@zeta.org.au, pst@shockwave.com Subject: Re: Bug in libc/db/hash/hash.c??? Cc: freebsd-current@freebsd.org, jhay@mikom.csir.co.za Sender: owner-current@freebsd.org Precedence: bulk > I think the fix works because the O_CREAT flag is now honoured (perhaps > it should check O_TRUNC too?). I think the database was messed up when > cgetnext() opened it without (O_CREAT | O_TRUNC). >Do you mean it should require both O_CREAT and O_TRUNC or either? If either, >that case is covered earlier. I'm not certain both should be required if >the file is already 0 sized. However, I'm easy going, whichever you want >is fine by me, just as long as you clarify what you want. :-) I think backing it out was best :-). 0-length database files shouldn't exist unless another process is initializing them, and you can't fix a 0-length `cap' database file except by deleting it. >Yeah, it looks like paging to disk is rather asynchronous in nature. In my Did we break something by using mmap? >opinion, the whole damn thing should internally be protected with advisory >locks, but that completely breaks ndbm semantics where the callers expect >to have to lock the database themselves. Sigh. pwd_mkdb uses O_EXCL and a temporary database. I think that's the only way to ensure that writing the database doesn't corrupt it. Bruce From owner-freebsd-current Sun Feb 25 13:51:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA22877 for current-outgoing; Sun, 25 Feb 1996 13:51:38 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA22870 for ; Sun, 25 Feb 1996 13:51:34 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA27259 for ; Sun, 25 Feb 1996 22:51:32 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id WAA11199 for freebsd-current@FreeBSD.org; Sun, 25 Feb 1996 22:51:31 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id WAA02985 for freebsd-current@FreeBSD.org; Sun, 25 Feb 1996 22:33:59 +0100 (MET) From: J Wunsch Message-Id: <199602252133.WAA02985@uriah.heep.sax.de> Subject: Re: -current breaks shell and tset To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 25 Feb 1996 22:33:59 +0100 (MET) In-Reply-To: <199602251607.RAA00217@knobel.gun.de> from "Andreas Klemm" at Feb 25, 96 05:07:44 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org Precedence: bulk As Andreas Klemm wrote: > I have big trouble with FreeBSD-current after supping it > yesterday. Hmm, sorry, i can't confirm it. I've just rebuilt the world, and despite of a panic (see other mail), i can't see any sign of your problems. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Feb 25 13:53:29 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA22980 for current-outgoing; Sun, 25 Feb 1996 13:53:29 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA22974 for ; Sun, 25 Feb 1996 13:53:25 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA27303 for ; Sun, 25 Feb 1996 22:53:23 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id WAA11231 for freebsd-current@FreeBSD.org; Sun, 25 Feb 1996 22:53:23 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id WAA04207 for freebsd-current@FreeBSD.org; Sun, 25 Feb 1996 22:49:20 +0100 (MET) From: J Wunsch Message-Id: <199602252149.WAA04207@uriah.heep.sax.de> Subject: Problem building chpass(1) To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 25 Feb 1996 22:49:19 +0100 (MET) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org Precedence: bulk My ``make world'' stopped while building chpass(1). It seems that the following patch is needed. Can somebody verify that this is the correct fix (& commit it)? Index: chpass/chpass.c =================================================================== RCS file: /home/cvs/src/usr.bin/chpass/chpass.c,v retrieving revision 1.7 diff -u -u -r1.7 chpass.c --- chpass.c 1996/02/23 16:08:56 1.7 +++ chpass.c 1996/02/25 17:55:47 @@ -63,6 +63,7 @@ #include #include "pw_copy.h" #ifdef YP +#include #include int yp_errno = YP_TRUE; #include "pw_yp.h" -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Feb 25 13:53:34 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA23001 for current-outgoing; Sun, 25 Feb 1996 13:53:34 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA22987 for ; Sun, 25 Feb 1996 13:53:30 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA27299 for ; Sun, 25 Feb 1996 22:53:22 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id WAA11230 for freebsd-current@FreeBSD.org; Sun, 25 Feb 1996 22:53:21 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id WAA04115 for freebsd-current@FreeBSD.org; Sun, 25 Feb 1996 22:47:08 +0100 (MET) From: J Wunsch Message-Id: <199602252147.WAA04115@uriah.heep.sax.de> Subject: panic report To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 25 Feb 1996 22:47:07 +0100 (MET) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-current@FreeBSD.org Precedence: bulk My machine just panicked, immediately when logging in (after launching X11, and shutting it down again). Here's the kgdb log. The structures look a bit strange, so i wouldn't trust it too much. I'll keep the core for ~ 3 days, just in case somebody needs more information. uriah # gdb -k kernel /tmp/crash/vmcore.0 GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.13 (i386-unknown-freebsd), Copyright 1994 Free Software Foundation, Inc... IdlePTD 227000 current pcb at 1f073c panic: from debugger #0 boot (howto=256) at ../../i386/i386/machdep.c:940 940 dumppcb.pcb_ptd = rcr3(); (kgdb) where #0 boot (howto=256) at ../../i386/i386/machdep.c:940 #1 0xf01157e4 in panic () #2 0xf0101215 in db_panic () #3 0xf01010fe in db_command () #4 0xf010127d in db_command_loop () #5 0xf01035e8 in db_trap () #6 0xf01a6dfa in kdb_trap () #7 0xf01b2207 in trap_fatal (frame=0xefbffe0c) at ../../i386/i386/trap.c:755 #8 0xf01b1d84 in trap_pfault (frame=0xefbffe0c, usermode=0) at ../../i386/i386/trap.c:681 #9 0xf01b19bf in trap (frame={tf_es = -222035952, tf_ds = -272695280, tf_edi = -2147483648, tf_esi = -265569472, tf_ebp = -272630188, tf_isp = -272630220, tf_ebx = 136265728, tf_edx = -188620800, tf_ecx = -254204828, tf_eax = 32, tf_trapno = 12, tf_err = -266797056, tf_eip = -266665426, tf_cs = -254279672, tf_eflags = 66066, tf_esp = -265817664, tf_ss = -254159360}) at ../../i386/i386/trap.c:320 #10 0xf01a7661 in calltrap () #11 0xf019e802 in vm_object_pmap_copy (object=0xf0d9d600, start=0, end=30) at ../../vm/vm_page.h:296 #12 0xf019c537 in vm_map_copy_entry (src_map=0xf0d92900, dst_map=0xf0d98b00, src_entry=0xf0d95d00, dst_entry=0xf0c6e600) at ../../vm/vm_map.c:1817 #13 0xf019c727 in vmspace_fork (vm1=0xf0d92900) at ../../vm/vm_map.c:1945 #14 0xf0199beb in vm_fork () #15 0xf010af41 in fork1 () #16 0xf010ab56 in vfork () #17 0xf01b24f3 in syscall (frame={tf_es = 327719, tf_ds = -272695257, tf_edi = 2, tf_esi = 0, tf_ebp = -272641252, tf_isp = -272629788, tf_ebx = 3, tf_edx = -272641344, tf_ecx = 110773, tf_eax = 66, tf_trapno = 0, tf_err = 642, tf_eip = 134852066, tf_cs = 31, tf_eflags = 642, tf_esp = -272641340, tf_ss = 39}) at ../../i386/i386/trap.c:919 #18 0xf01a76ad in Xsyscall () #19 0x1b63f in ?? () #20 0x3be7 in ?? () #21 0x3410 in ?? () #22 0x2fd1 in ?? () #23 0x2c54 in ?? () #24 0x10e8 in ?? () (kgdb) up 9 #9 0xf01b19bf in trap (frame={tf_es = -222035952, tf_ds = -272695280, tf_edi = -2147483648, tf_esi = -265569472, tf_ebp = -272630188, tf_isp = -272630220, tf_ebx = 136265728, tf_edx = -188620800, tf_ecx = -254204828, tf_eax = 32, tf_trapno = 12, tf_err = -266797056, tf_eip = -266665426, tf_cs = -254279672, tf_eflags = 66066, tf_esp = -265817664, tf_ss = -254159360}) at ../../i386/i386/trap.c:320 320 (void) trap_pfault(&frame, FALSE); (kgdb) frame frame->tf_ebp frame->tf_eip #0 0xf01b022e in pmap_page_protect (phys=18567168, prot=1) at ../../i386/i386/pmap.c:229 229 if (pmap && *pmap_pde(pmap, va)) { (kgdb) l 224 pmap_pte(pmap, va) 225 register pmap_t pmap; 226 vm_offset_t va; 227 { 228 229 if (pmap && *pmap_pde(pmap, va)) { 230 vm_offset_t frame = (int) pmap->pm_pdir[PTDPTDI] & PG_FRAME; 231 232 /* are we current address space or kernel? */ 233 if ((pmap == kernel_pmap) || (frame == ((int) PTDpde & PG_FRAME))) (kgdb) p pmap $1 = (struct pmap *) 0x0 (kgdb) p va $2 = 3 (kgdb) up #1 0xf019e802 in vm_object_pmap_copy (object=0xf0d9d600, start=0, end=30) at ../../vm/vm_page.h:296 296 pmap_page_protect(VM_PAGE_TO_PHYS(mem), prot); (kgdb) up #2 0xf019c537 in vm_map_copy_entry (src_map=0xf0d92900, dst_map=0xf0d98b00, src_entry=0xf0d95d00, dst_entry=0xf0c6e600) at ../../vm/vm_map.c:1817 1817 vm_object_pmap_copy(src_entry->object.vm_object, (kgdb) p *src_entry $3 = {prev = 0x472, next = 0x89551234, start = 2634181349, end = 3767457932, object = {vm_object = 0x7d83e88e, share_map = 0x7d83e88e, sub_map = 0x7d83e88e}, offset = 0x00187d8338740004, is_a_map = 0, is_sub_map = 0, copy_on_write = -1, needs_copy = 0, protection = 1 '\001', max_protection = 244 'ô', inheritance = -117 '\213', wired_count = 59448413} (kgdb) quit -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Feb 25 13:59:36 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA23290 for current-outgoing; Sun, 25 Feb 1996 13:59:36 -0800 (PST) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA23285 for ; Sun, 25 Feb 1996 13:59:33 -0800 (PST) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) id WAA18448; Sun, 25 Feb 1996 22:45:20 +0100 (MET) Received: (from andreas@localhost) by knobel.gun.de (8.7.4/8.7.3) id VAA00240; Sun, 25 Feb 1996 21:35:32 +0100 (MET) From: Andreas Klemm Message-Id: <199602252035.VAA00240@knobel.gun.de> Subject: Re: -current breaks shell and tset To: jhay@mikom.csir.co.za (John Hay) Date: Sun, 25 Feb 1996 21:35:32 +0100 (MET) Cc: current@FreeBSD.org In-Reply-To: <199602251657.SAA26010@zibbi.mikom.csir.co.za> from "John Hay" at Feb 25, 96 06:57:32 pm X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org Precedence: bulk > That is the problem that I reported with lib/libc/db/hash/hash.c. There > was a fix commited already so if you sup again you should get it. To > get going in the meantime, I think you should be able to delete > /usr/share/misc/termcap.db. The termcap routines should fall back to > using the text file. Thanks, removing termcap.db cured all my problems. tset works again and I can again change directories... The "chdir: Too many arguments." error has gone. What I don't understand is the dependency between an unreadable termcap database and the 'cd' command. Any ideas ? -- andreas@knobel.gun.de /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ $$ Support Unix - aklemm@wup.de $$ pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< From owner-freebsd-current Sun Feb 25 13:59:58 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA23336 for current-outgoing; Sun, 25 Feb 1996 13:59:58 -0800 (PST) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA23331 for ; Sun, 25 Feb 1996 13:59:55 -0800 (PST) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) id WAA18451; Sun, 25 Feb 1996 22:45:25 +0100 (MET) Received: (from andreas@localhost) by knobel.gun.de (8.7.4/8.7.3) id VAA00287; Sun, 25 Feb 1996 21:47:42 +0100 (MET) From: Andreas Klemm Message-Id: <199602252047.VAA00287@knobel.gun.de> Subject: Re: -current breaks shell and tset To: imb@scgt.oz.au (michael butler) Date: Sun, 25 Feb 1996 21:47:42 +0100 (MET) Cc: current@FreeBSD.org In-Reply-To: <199602251809.FAA00531@asstdc.scgt.oz.au> from "michael butler" at Feb 26, 96 05:09:44 am X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org Precedence: bulk > This is another non-obvious side-effect of the broken > lib/libc/db/hash/hash.c which also broke -stable completely. You have to get > a fixed version, remake termcap and anything else that was statically linked > with libc :-( I'll do a another make world this night. Hope, that the german sup server has the newest files... > On -stable (since I backed out of running -current for precisely this kind > of instability) Well after running -current for nearly three months this was the biggest problem, that I had 'til now. I'm generally satisfied with -currents stability. The problem is solved for me now, after waiting only a few hours. I don't expect more damage.... Very good mailinglist support ! > reversing out the change does not appear to fix kvm_mkdb > (and probably more) .. ps only spits out process names in parentheses. But > then, the -stable kernel doesn't even boot any more here .. Puh, so -current is more stable than -stable :-)) Well, was a strange experience to write an e-mail with 'cat > x' and after that cat x | elm -s .... ;-)) Andreas /// -- andreas@knobel.gun.de /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ $$ Support Unix - aklemm@wup.de $$ pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< From owner-freebsd-current Sun Feb 25 15:07:06 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA26629 for current-outgoing; Sun, 25 Feb 1996 15:07:06 -0800 (PST) Received: from ki.net (root@ki.net [142.77.249.8]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id PAA26606 for ; Sun, 25 Feb 1996 15:06:57 -0800 (PST) Received: (from scrappy@localhost) by ki.net (8.7.3/8.7.3) id SAA26841; Sun, 25 Feb 1996 18:06:40 -0500 (EST) Date: Sun, 25 Feb 1996 18:06:39 -0500 (EST) From: "Marc G. Fournier" To: current@freebsd.org Subject: vm_map_insert panic, but can't get core dump to analyze... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk Hi... I'm trying to get my 486 up to -current from -stable, and due to a bug in vm_map_insert, can't seem to do it...it causes a panic. The stable kernel, now, has been running 9 days straight, no problems, whereas, the -current kernel I'm lucky to keep going for over 6hrs. I've performed a diff between the -stable and -current vm_map.c file, and there are substantial changes, which I expected since the VM code was totally "revamped". I have put in a problem report for it, but for some reason I can't seem to get a core dump out of the machine, so can't send a "proper" report in...only that which I can get out of ddb. I have the appropriate settings in /etc/sysconfig set: dumpdev=/dev/sd0b # Set to YES if you want kernel crashdumps to be saved for debugging savecore=YES I have the kernel compiled with DUMP and DDB enabled: options DODUMP options DDB And /var/crash exists, and has lots of disk space available: ki# df /var/crash Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/sd0s1f 100398 51334 41032 56% /var ki# ls -lt /var/crash total 2 -rw-rw-r-- 1 root wheel 5 Nov 16 04:59 minfree The only thing I can think about is that since its a VM panic, it can't save the core to /dev/sd0b, and therefore, I can't get a core file out of it. Is there anything else I can do to debug this problem? If it wasn't for the fact that -stable is, in fact, stable on this machine, my first idea would be hardware, so my second idea has to be somewhere in the kernel code itself... And, the last changes to vm_map.c was on the 11th of Febuary, before my last kernel attempt, so there have been no changes in vm_map.c that would entice me to try a new kernel... Recommendations? Marc G. Fournier | POP Mail Telnet Acct DNS Hosting System | WWW Services Database Services | Knowledge, Administrator | | Information and scrappy@ki.net | WWW: http://www.ki.net | Communications, Inc From owner-freebsd-current Sun Feb 25 16:00:21 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA02644 for current-outgoing; Sun, 25 Feb 1996 16:00:21 -0800 (PST) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA02636 for ; Sun, 25 Feb 1996 16:00:16 -0800 (PST) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id SAA11196; Sun, 25 Feb 1996 18:59:40 -0500 From: Bill Paul Message-Id: <199602252359.SAA11196@skynet.ctr.columbia.edu> Subject: Re: Problem building chpass(1) To: j@uriah.heep.sax.de (J Wunsch) Date: Sun, 25 Feb 1996 18:59:38 -0500 (EST) Cc: current@freebsd.org In-Reply-To: <199602252149.WAA04207@uriah.heep.sax.de> from "J Wunsch" at Feb 25, 96 10:49:19 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org Precedence: bulk Of all the gin joints in all the towns in all the world, J Wunsch had to walk into mine and say: > > My ``make world'' stopped while building chpass(1). It seems that the > following patch is needed. Can somebody verify that this is the > correct fix (& commit it)? Can you please share with us the error that you saw? I strongly suspect that this is another problem related to bootstrapping rpcgen. > Index: chpass/chpass.c > =================================================================== > RCS file: /home/cvs/src/usr.bin/chpass/chpass.c,v > retrieving revision 1.7 > diff -u -u -r1.7 chpass.c > --- chpass.c 1996/02/23 16:08:56 1.7 > +++ chpass.c 1996/02/25 17:55:47 > @@ -63,6 +63,7 @@ > #include > #include "pw_copy.h" > #ifdef YP > +#include > #include > int yp_errno = YP_TRUE; > #include "pw_yp.h" Assuming you have correctly rebuilt your /usr/include/rpcsvc directory with the _new_ rpcgen, will #include for you. Check that you have the _new_ rpcgen compiled and installed, rebuild your /usr/include/rpcsvc directory with it and try again. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= License error: The license for this .sig file has expired. You must obtain a new license key before any more witty phrases will appear in this space. ============================================================================= From owner-freebsd-current Sun Feb 25 16:20:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA03637 for current-outgoing; Sun, 25 Feb 1996 16:20:54 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA03632 for ; Sun, 25 Feb 1996 16:20:46 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id BAA29916 for ; Mon, 26 Feb 1996 01:20:44 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id BAA13163 for freebsd-current@FreeBSD.org; Mon, 26 Feb 1996 01:20:43 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id BAA00383 for freebsd-current@FreeBSD.org; Mon, 26 Feb 1996 01:03:15 +0100 (MET) From: J Wunsch Message-Id: <199602260003.BAA00383@uriah.heep.sax.de> Subject: Re: -current breaks shell and tset To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Mon, 26 Feb 1996 01:03:15 +0100 (MET) In-Reply-To: <199602252047.VAA00287@knobel.gun.de> from "Andreas Klemm" at Feb 25, 96 09:47:42 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org Precedence: bulk As Andreas Klemm wrote: > Well, was a strange experience to write an e-mail with 'cat > x' > and after that cat x | elm -s .... ;-)) You don't like using ed(1)? :-) It's statically linked, and it doesn't require termcap. That makes it survive almost everything. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Feb 25 17:13:37 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA08679 for current-outgoing; Sun, 25 Feb 1996 17:13:37 -0800 (PST) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id RAA08673 for ; Sun, 25 Feb 1996 17:13:35 -0800 (PST) Received: from localhost.shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.4/8.7.3) with SMTP id RAA04186; Sun, 25 Feb 1996 17:12:38 -0800 (PST) Message-Id: <199602260112.RAA04186@precipice.shockwave.com> To: Bruce Evans cc: freebsd-current@freebsd.org, jhay@mikom.csir.co.za Subject: Re: Bug in libc/db/hash/hash.c??? In-reply-to: Your message of "Mon, 26 Feb 1996 06:54:00 +1100." <199602251954.GAA32445@godzilla.zeta.org.au> Date: Sun, 25 Feb 1996 17:12:37 -0800 From: Paul Traina Sender: owner-current@freebsd.org Precedence: bulk From: Bruce Evans Subject: Re: Bug in libc/db/hash/hash.c??? > I think the fix works because the O_CREAT flag is now honoured (perhaps > it should check O_TRUNC too?). I think the database was messed up when > cgetnext() opened it without (O_CREAT | O_TRUNC). >Do you mean it should require both O_CREAT and O_TRUNC or either? If either >>, >that case is covered earlier. I'm not certain both should be required if >the file is already 0 sized. However, I'm easy going, whichever you want >is fine by me, just as long as you clarify what you want. :-) I think backing it out was best :-). 0-length database files shouldn't exist unless another process is initializing them, and you can't fix a 0-length `cap' database file except by deleting it. The whole point was that mh's slocal uses an 0-length file to indicate that it should keep track of message id's, that's the only way to bootstrap yourself up. From owner-freebsd-current Sun Feb 25 17:17:28 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA09027 for current-outgoing; Sun, 25 Feb 1996 17:17:28 -0800 (PST) Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA09022 for ; Sun, 25 Feb 1996 17:17:26 -0800 (PST) Message-Id: <199602260117.RAA09022@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol To: current Subject: 3c5x9 driver updated in -current. Date: Sun, 25 Feb 1996 17:17:26 -0800 From: "Justin T. Gibbs" Sender: owner-current@FreeBSD.ORG Precedence: bulk I'd like to bring these changes into -stable. To do that, I'll need to know that they work for people besides myself. Please test the updated driver out and let me know if you have any problems. Thanks, Justin ------- Forwarded Message Date: Sun, 25 Feb 1996 17:05:39 -0800 (PST) From: "Justin T. Gibbs" Message-Id: <199602260105.RAA08117@freefall.freebsd.org> To: CVS-committers, cvs-all, cvs-sys Subject: cvs commit: src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c src/sys/i386/isa if_ep.c if_epreg.h src/sys/i386/conf files.i386 Sender: owner-cvs-committers@FreeBSD.org Precedence: bulk gibbs 96/02/25 17:05:38 Modified: sys/i386/conf files.i386 Log: Add i386/eisa/3c5x9.c, the eisaconf probe for the 3Com 3c579 and the 3c509 when in eisa configuration mode. Revision Changes Path 1.128 +2 -1 src/sys/i386/conf/files.i386 Modified: sys/i386/eisa aha1742.c aic7770.c bt74x.c eisaconf.c Added: sys/i386/eisa 3c5x9.c Log: 3c5x9.c: The eisaconf probe for the 3Com 3c579 and the 3c509 when in eisa configuration mode. aha1742.c aic7770.c bt74x.c: Only call eisa_registerdev after the probe is successfully. eisaconf.c: Increase kdc->kdc_datalen during the eisa_reg* functions instead of in the eisa_add* functions since eisa_registerdev has already been called and we have a kdc to manipulate. Revision Changes Path 1.51 +2 -2 src/sys/i386/eisa/aha1742.c 1.25 +2 -2 src/sys/i386/eisa/aic7770.c 1.5 +3 -3 src/sys/i386/eisa/bt74x.c 1.16 +2 -2 src/sys/i386/eisa/eisaconf.c Modified: sys/i386/isa if_ep.c if_epreg.h Log: Clean up the 3c5x9 driver and add an eisaconf probe to it. This should prevent it from conflicting with other drivers (like the aic7xxx driver). Most of the work was in spliting out common portions of the driver and making them generic enough to be called from the eisaconf probe. Revision Changes Path 1.42 +243 -185 src/sys/i386/isa/if_ep.c 1.12 +17 -6 src/sys/i386/isa/if_epreg.h ------- End of Forwarded Message From owner-freebsd-current Sun Feb 25 17:55:56 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA10824 for current-outgoing; Sun, 25 Feb 1996 17:55:56 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA10819 for ; Sun, 25 Feb 1996 17:55:53 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id CAA01707 for ; Mon, 26 Feb 1996 02:55:51 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id CAA13754 for freebsd-current@FreeBSD.org; Mon, 26 Feb 1996 02:55:51 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id BAA01856 for freebsd-current@FreeBSD.org; Mon, 26 Feb 1996 01:30:01 +0100 (MET) From: J Wunsch Message-Id: <199602260030.BAA01856@uriah.heep.sax.de> Subject: Re: Problem building chpass(1) To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Mon, 26 Feb 1996 01:30:00 +0100 (MET) In-Reply-To: <199602252359.SAA11196@skynet.ctr.columbia.edu> from "Bill Paul" at Feb 25, 96 06:59:38 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org Precedence: bulk As Bill Paul wrote: > Can you please share with us the error that you saw? I strongly > suspect that this is another problem related to bootstrapping > rpcgen. It was too longish to write it down, and i didn't run it in an xterm to cut'npaste it. > Assuming you have correctly rebuilt your /usr/include/rpcsvc directory > with the _new_ rpcgen, will #include for you. Of course, the new rpcgen was correctly installed, but the files in /usr/src/include/rpcsvc (incorrectly) don't depend on it, so they haven't been rebuilt. I had to manually ``make clean'' there. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Feb 25 18:16:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA12059 for current-outgoing; Sun, 25 Feb 1996 18:16:54 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id SAA12054 for ; Sun, 25 Feb 1996 18:16:51 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id DAA02126 for ; Mon, 26 Feb 1996 03:16:48 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id DAA13900 for freebsd-current@FreeBSD.org; Mon, 26 Feb 1996 03:16:48 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id DAA00948 for freebsd-current@FreeBSD.org; Mon, 26 Feb 1996 03:13:40 +0100 (MET) From: J Wunsch Message-Id: <199602260213.DAA00948@uriah.heep.sax.de> Subject: pmap_page_protect() panic To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Mon, 26 Feb 1996 03:13:39 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org Precedence: bulk Just a FYI: I've seen it four times by now, within relatively short time. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Feb 25 18:18:17 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA12174 for current-outgoing; Sun, 25 Feb 1996 18:18:17 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id SAA12169 Sun, 25 Feb 1996 18:18:13 -0800 (PST) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id SAA13484; Sun, 25 Feb 1996 18:18:04 -0800 From: "Rodney W. Grimes" Message-Id: <199602260218.SAA13484@GndRsh.aac.dev.com> Subject: Re: 3c5x9 driver updated in -current. To: gibbs@freefall.freebsd.org (Justin T. Gibbs) Date: Sun, 25 Feb 1996 18:18:04 -0800 (PST) Cc: current@freefall.freebsd.org In-Reply-To: <199602260117.RAA09022@freefall.freebsd.org> from "Justin T. Gibbs" at Feb 25, 96 05:17:26 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG Precedence: bulk > > I'd like to bring these changes into -stable. To do that, I'll > need to know that they work for people besides myself. Please > test the updated driver out and let me know if you have any problems. You should have sent this to -stable probably :-). I have no problems with these changes coming over _AFTER_ all of the current brokeness in stable is fixed. I have not done my weekly update of my master install tree this weekend for production machines due to the number of recent bugs created in stable. > Thanks, > Justin > ------- Forwarded Message > > Date: Sun, 25 Feb 1996 17:05:39 -0800 (PST) > From: "Justin T. Gibbs" > Message-Id: <199602260105.RAA08117@freefall.freebsd.org> > To: CVS-committers, cvs-all, cvs-sys > Subject: cvs commit: src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c src/sys/i386/isa if_ep.c if_epreg.h src/sys/i386/conf files.i386 > Sender: owner-cvs-committers@FreeBSD.org > Precedence: bulk > > gibbs 96/02/25 17:05:38 > > Modified: sys/i386/conf files.i386 > Log: > Add i386/eisa/3c5x9.c, the eisaconf probe for the 3Com 3c579 and the > 3c509 when in eisa configuration mode. > > Revision Changes Path > 1.128 +2 -1 src/sys/i386/conf/files.i386 > > Modified: sys/i386/eisa aha1742.c aic7770.c bt74x.c eisaconf.c > Added: sys/i386/eisa 3c5x9.c > Log: > 3c5x9.c: > The eisaconf probe for the 3Com 3c579 and the 3c509 when in eisa > configuration mode. > > aha1742.c aic7770.c bt74x.c: > Only call eisa_registerdev after the probe is successfully. > > eisaconf.c: > Increase kdc->kdc_datalen during the eisa_reg* functions instead of > in the eisa_add* functions since eisa_registerdev has already been > called and we have a kdc to manipulate. > > Revision Changes Path > 1.51 +2 -2 src/sys/i386/eisa/aha1742.c > 1.25 +2 -2 src/sys/i386/eisa/aic7770.c > 1.5 +3 -3 src/sys/i386/eisa/bt74x.c > 1.16 +2 -2 src/sys/i386/eisa/eisaconf.c > > Modified: sys/i386/isa if_ep.c if_epreg.h > Log: > Clean up the 3c5x9 driver and add an eisaconf probe to it. This should > prevent it from conflicting with other drivers (like the aic7xxx driver). > Most of the work was in spliting out common portions of the driver and > making them generic enough to be called from the eisaconf probe. > > Revision Changes Path > 1.42 +243 -185 src/sys/i386/isa/if_ep.c > 1.12 +17 -6 src/sys/i386/isa/if_epreg.h > > ------- End of Forwarded Message > > -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Sun Feb 25 20:41:00 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA19592 for current-outgoing; Sun, 25 Feb 1996 20:41:00 -0800 (PST) Received: from cocoa.ops.neosoft.com (root@cocoa.ops.neosoft.com [206.109.5.227]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id UAA19586 for ; Sun, 25 Feb 1996 20:40:56 -0800 (PST) Received: (from dbaker@localhost) by cocoa.ops.neosoft.com (8.7.4/8.6.12) id WAA02932; Sun, 25 Feb 1996 22:40:25 -0600 (CST) Date: Sun, 25 Feb 1996 22:40:23 -0600 (CST) From: Daniel Baker X-Sender: dbaker@cocoa.ops.neosoft.com To: Andreas Klemm cc: current@freebsd.org Subject: Re: -current breaks shell and tset In-Reply-To: <199602251607.RAA00217@knobel.gun.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk I had the same problem with tset, and termcap and stuff. I fixed it by adding setenv TERMCAP /etc/termcap to my .cshrc file. Daniel On Sun, 25 Feb 1996, Andreas Klemm wrote: > Hi ! > > I have big trouble with FreeBSD-current after supping it > yesterday. > > When I try to login, tset isn't able to set the correct > terminal type. > > If I try to do a simple > # cd / > I get the message: > chdir: Too many arguments. > > My tcsh (even after rebuild in single user mode from the > ports collection) isn't useable... > > Only in single user mode I'm currently able to to things > with the shell. > > But tset doesn't work in single user mode, too. > > Heeeeeellllppp ;-) It's my one and only system here. > > Andreas /// > > andreas@knobel.gun.de /\/\___ Wiechers & Partner Datentechnik GmbH > Andreas Klemm ___/\/\/ $$ Support Unix - aklemm@wup.de $$ > pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< > ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< > "Ich bleibe bei der Aussage und trotze den Flames. :-)" Ulli Horlacher 02/96 > Daniel Baker - Daniel@Cuckoo.COM "Uhhhhhhh, thank you, drive through please" From owner-freebsd-current Sun Feb 25 22:41:52 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA28716 for current-outgoing; Sun, 25 Feb 1996 22:41:52 -0800 (PST) Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id WAA28711 for ; Sun, 25 Feb 1996 22:41:49 -0800 (PST) Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id HAA26420 ; Mon, 26 Feb 1996 07:41:47 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id HAA27391 ; Mon, 26 Feb 1996 07:41:46 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.3/keltia-uucp-2.7) id AAA04548; Mon, 26 Feb 1996 00:56:38 +0100 (MET) From: Ollivier Robert Message-Id: <199602252356.AAA04548@keltia.freenix.fr> Subject: Re: NIC memory correupt on SMC8013EPC To: joerg_wunsch@uriah.heep.sax.de Date: Mon, 26 Feb 1996 00:56:37 +0100 (MET) Cc: freebsd-current@FreeBSD.org In-Reply-To: <199602251316.OAA15589@uriah.heep.sax.de> from J Wunsch at "Feb 25, 96 02:16:02 pm" X-Operating-System: FreeBSD 2.2-CURRENT ctm#1688 X-Mailer: ELM [version 2.4ME+ PL7 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org Precedence: bulk It seems that J Wunsch said: > 0xbc000 falls into the area reserved for the video frame buffer > (0xa0000 ... 0xbffff). I know expect the area is 4 KB (maybe FreeBSD uses more than the usual screen). The funny thing is that after a few minutes it works... -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #1: Tue Feb 20 01:16:51 MET 1996 From owner-freebsd-current Mon Feb 26 01:21:56 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA06724 for current-outgoing; Mon, 26 Feb 1996 01:21:56 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA06665 for ; Mon, 26 Feb 1996 01:20:28 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA10957 for ; Mon, 26 Feb 1996 10:20:21 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id KAA16134 for freebsd-current@FreeBSD.org; Mon, 26 Feb 1996 10:20:21 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id JAA00426 for freebsd-current@FreeBSD.org; Mon, 26 Feb 1996 09:52:16 +0100 (MET) From: J Wunsch Message-Id: <199602260852.JAA00426@uriah.heep.sax.de> Subject: VM instability To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Mon, 26 Feb 1996 09:52:16 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org Precedence: bulk Umm, the Nth panic in a row. This time in: pmap_clear_modify() swap_pager_getpages() vm_pager_get_pages() vm_fault() ... as scribbled down from the panic message. Since i'm going to be away from here for the rest of the week, and i hesitate the machine would crash while i'm away, i've switched back to the Feb 3 kernel. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Mon Feb 26 01:32:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA07633 for current-outgoing; Mon, 26 Feb 1996 01:32:38 -0800 (PST) Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA07627 for ; Mon, 26 Feb 1996 01:32:34 -0800 (PST) Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD4.4) id UAA05214 for current@freebsd.org; Mon, 26 Feb 1996 20:29:07 +1100 From: michael butler Message-Id: <199602260929.UAA05214@asstdc.scgt.oz.au> Subject: Opti 82C895 cache coherency ? To: current@freebsd.org Date: Mon, 26 Feb 1996 20:29:06 +1100 (EST) X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk I wonder if anyone can vouch for an Opti 82C895/82C602 motherboard with an AMD 486DX4/100 in respect of cache coherency. Specifically, in combination with an Adaptec 2842 (VLB) controller. Just trying to track down a "quirk" with a (sort of working) -stable .. I don't know if it's -stable or the motherboard :-( michael From owner-freebsd-current Mon Feb 26 02:45:18 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA11189 for current-outgoing; Mon, 26 Feb 1996 02:45:18 -0800 (PST) Received: from maui.com (root@waena.mrtc.maui.com [199.4.33.17]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA11184 for ; Mon, 26 Feb 1996 02:45:16 -0800 (PST) Received: from caliban.dihelix.com (caliban.dihelix.com [199.4.33.251]) by maui.com (8.6.10/8.6.6) with ESMTP id AAA00165 for ; Mon, 26 Feb 1996 00:50:20 -1000 Received: (from root@localhost) by caliban.dihelix.com (8.7.4/8.6.9) id AAA02032 for current@freebsd.org; Mon, 26 Feb 1996 00:45:11 -1000 (HST) Message-Id: <199602261045.AAA02032@caliban.dihelix.com> Subject: Problem with current (and stable) with TYAN MB To: current@freebsd.org Date: Mon, 26 Feb 1996 00:45:11 -1000 (HST) From: "David Langford" From: "David Langford" X-blank-line: This space intentionaly left blank. X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk TYAN TITAN III Award v2.5 also with latest MR. BIOS bios PCI info: CHIP:0 Intel 82437 Triton PCI cache memory controller rev 1 on PCI0:0 CHIP:1 Intel 82371 Triton PCI ISA bridge rev 2 on PCI0:7 CHIP:2 Intel 82371 Triton bustmaster IDE controller rev 2 on PCI0:7 It seems to hang at the end of the autoconfig part of the kernel boot. All devices seem to probe just fine. Windows95 seems to work very very very well on this board. Has anyone heard of any problems like this. Thanks David Langford langfod@dihelix.com From owner-freebsd-current Mon Feb 26 04:29:21 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA15970 for current-outgoing; Mon, 26 Feb 1996 04:29:21 -0800 (PST) Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA15963 Mon, 26 Feb 1996 04:29:02 -0800 (PST) Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD4.4) id XAA07877; Mon, 26 Feb 1996 23:28:57 +1100 From: michael butler Message-Id: <199602261228.XAA07877@asstdc.scgt.oz.au> Subject: -stable hangs at boot (fwd) To: stable@freebsd.org Date: Mon, 26 Feb 1996 23:28:56 +1100 (EST) Cc: current@freebsd.org X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk I wrote: > Having backed out the troublesome /usr/lib/libc/db/hash/hash.c change, I > still have the problem of a recently built -stable kernel stopping during > start-up immediately after "ifconfig ed0 .." but before "ifconfig lo0 .." > If I wait long enough, it seems that it will eventually continue but cannot > transmit packets at all on the ed0 interface. This is as a direct consequence of compiling IPFW into the kernel .. it can't receive packets from its own ethernet interface ! If you ^C your way to a shell prompt, there's a single rule that's in the firewall list saying "deny all from any to any". Courtesy of the same recent brain-damage in ipfw(8), you can't delete this rule either ("setsockopt failed"). I suspect the very same problem in -current. The only workaround I can think of is to add "ipfw addf accept .." statements _prior_ to the running of ifconfig in netstart .. theory as yet untested .. michael From owner-freebsd-current Mon Feb 26 05:26:34 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA18134 for current-outgoing; Mon, 26 Feb 1996 05:26:34 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA18129 Mon, 26 Feb 1996 05:26:32 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tr2wc-0003wSC; Mon, 26 Feb 96 05:26 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id OAA11366; Mon, 26 Feb 1996 14:26:25 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: michael butler cc: stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-reply-to: Your message of "Mon, 26 Feb 1996 23:28:56 +1100." <199602261228.XAA07877@asstdc.scgt.oz.au> Date: Mon, 26 Feb 1996 14:26:23 +0100 Message-ID: <11364.825341183@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org Precedence: bulk > If you ^C your way to a shell prompt, there's a single rule that's in the > firewall list saying "deny all from any to any". Courtesy of the same recent > brain-damage in ipfw(8), you can't delete this rule either ("setsockopt > failed"). If you call this "brain-damage" then you quite clearly don't need IPFW. > I suspect the very same problem in -current. > > The only workaround I can think of is to add "ipfw addf accept .." > statements _prior_ to the running of ifconfig in netstart .. theory as yet > untested .. This is all correct, designed that way, and it is the way it should work, according to all material I have on the subject. If you have IPFW in your kernel, you don't want it to pass any packets you haven't approved in your filters. QED: Setup your filters before anything gets passed. Wrt to the rule #65535 "deny all from any to any", then you are correct, you cannot delete it. It represents the default policy of "anything not specifically allowed, is banned. If you want to have another policy, they you must define rules that implement that policy, "65000 allow all from any to any" sounds like the policy for your needs. If you want to dispute this design, then please find at least one textbook or capacity in the area who agree with you first, that will save a lot of my time. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Mon Feb 26 05:41:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA18988 for current-outgoing; Mon, 26 Feb 1996 05:41:38 -0800 (PST) Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA18978 Mon, 26 Feb 1996 05:41:31 -0800 (PST) Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD4.4) id AAA09032; Tue, 27 Feb 1996 00:41:16 +1100 From: michael butler Message-Id: <199602261341.AAA09032@asstdc.scgt.oz.au> Subject: Re: -stable hangs at boot (fwd) To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Tue, 27 Feb 1996 00:41:15 +1100 (EST) Cc: stable@freebsd.org, current@freebsd.org In-Reply-To: <11364.825341183@critter.tfs.com> from "Poul-Henning Kamp" at Feb 26, 96 02:26:23 pm X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk Poul-Henning Kamp writes: > > If you ^C your way to a shell prompt, there's a single rule that's in > > the firewall list saying "deny all from any to any". Courtesy of the > > same recent brain-damage in ipfw(8), you can't delete this rule either > > ("setsockopt failed"). > If you call this "brain-damage" then you quite clearly don't need IPFW. I call it "brain-damage" to render a machine unbootable because it can't "see" it's _own_ interfaces. AFAIK, firewalls by default prevent packets passing _through_ them but are themselves permitted to talk to anything they have a route to (the previous behaviour with a default policy of "deny"). A direct connection (interface in the same box) constitutes having a "route to". Further, there are no hints whatsoever in the current rc, sysconfig, netstart, et al to indicate that this (current condition) is the problem. Even if this (IMHO unusual) behaviour was documented it wouldn't be so much of a problem, michael From owner-freebsd-current Mon Feb 26 05:46:58 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA19298 for current-outgoing; Mon, 26 Feb 1996 05:46:58 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA19293 Mon, 26 Feb 1996 05:46:57 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tr3GR-0003wgC; Mon, 26 Feb 96 05:46 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id OAA11447; Mon, 26 Feb 1996 14:46:56 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: michael butler cc: stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-reply-to: Your message of "Tue, 27 Feb 1996 00:41:15 +1100." <199602261341.AAA09032@asstdc.scgt.oz.au> Date: Mon, 26 Feb 1996 14:46:55 +0100 Message-ID: <11445.825342415@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org Precedence: bulk > Poul-Henning Kamp writes: > > > > If you ^C your way to a shell prompt, there's a single rule that's in > > > the firewall list saying "deny all from any to any". Courtesy of the > > > same recent brain-damage in ipfw(8), you can't delete this rule either > > > ("setsockopt failed"). > > > If you call this "brain-damage" then you quite clearly don't need IPFW. > > I call it "brain-damage" to render a machine unbootable because it can't > "see" it's _own_ interfaces. AFAIK, firewalls by default prevent packets > passing _through_ them but are themselves permitted to talk to anything they > have a route to (the previous behaviour with a default policy of "deny"). A > direct connection (interface in the same box) constitutes having a "route to" Well, this happens to be your view. I know machines where IPFW are being used to restrict what users on the machine can do, this is only possible if you filter >ALL< traffic, to and from the machine. The IPFW is not a policy, it's a tool to implement policies. As such it needs to be able to implement the widest possible range of policies. > Further, there are no hints whatsoever in the current rc, sysconfig, > netstart, et al to indicate that this (current condition) is the problem. > Even if this (IMHO unusual) behaviour was documented it wouldn't be so much > of a problem, No, this is still on it's way. You should be on -committers if you run -stable or -current. If you were, you would have seen it. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Mon Feb 26 06:06:11 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA20373 for current-outgoing; Mon, 26 Feb 1996 06:06:11 -0800 (PST) Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA20368 Mon, 26 Feb 1996 06:06:08 -0800 (PST) Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD4.4) id BAA09438; Tue, 27 Feb 1996 01:05:50 +1100 From: michael butler Message-Id: <199602261405.BAA09438@asstdc.scgt.oz.au> Subject: Re: -stable hangs at boot (fwd) To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Tue, 27 Feb 1996 01:05:48 +1100 (EST) Cc: stable@freebsd.org, current@freebsd.org In-Reply-To: <11445.825342415@critter.tfs.com> from "Poul-Henning Kamp" at Feb 26, 96 02:46:55 pm X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk Poul-Henning Kamp writes: > Well, this happens to be your view. I know machines where IPFW are being > used to restrict what users on the machine can do, this is only possible > if you filter >ALL< traffic, to and from the machine. OK .. but, personally, I wouldn't call or attempt to use those boxes as firewalls .. any "sensitive" firewall/filtering router I have control over has two valid accounts which have any access at all, mine and one other, with limited privilege, for daily monitoring. No users == much reduced risk. If security is _that_ important, investing in a dedicated box to do the job is cheap at triple the price :-) > The IPFW is not a policy, it's a tool to implement policies. As such it > needs to be able to implement the widest possible range of policies. I can see where you're coming from .. but this behaviour caught me out because it is unusual and I'm sure it'll catch many others :-(. > You should be on -committers if you run -stable or -current. If you were, > you would have seen it. If I could get half-way through the stuff I'm obliged to read now .. michael From owner-freebsd-current Mon Feb 26 06:22:13 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA21102 for current-outgoing; Mon, 26 Feb 1996 06:22:13 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA21096 Mon, 26 Feb 1996 06:22:11 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tr3oX-0003wSC; Mon, 26 Feb 96 06:22 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id PAA11521; Mon, 26 Feb 1996 15:22:10 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: michael butler cc: stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-reply-to: Your message of "Tue, 27 Feb 1996 01:05:48 +1100." <199602261405.BAA09438@asstdc.scgt.oz.au> Date: Mon, 26 Feb 1996 15:22:08 +0100 Message-ID: <11519.825344528@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org Precedence: bulk > Poul-Henning Kamp writes: > > > Well, this happens to be your view. I know machines where IPFW are being > > used to restrict what users on the machine can do, this is only possible > > if you filter >ALL< traffic, to and from the machine. > > OK .. but, personally, I wouldn't call or attempt to use those boxes as > firewalls .. any "sensitive" firewall/filtering router I have control over > has two valid accounts which have any access at all, mine and one other, > with limited privilege, for daily monitoring. No users == much reduced risk. I agree, I'd do that too. However, that is all a question of what your policy is. The IPFW, should not affect your policy, but merely be able to implement it. > If security is _that_ important, investing in a dedicated box to do the job > is cheap at triple the price :-) depends, sometimes other things are of some importance too :-) > > The IPFW is not a policy, it's a tool to implement policies. As such it > > needs to be able to implement the widest possible range of policies. > > I can see where you're coming from .. but this behaviour caught me out > because it is unusual and I'm sure it'll catch many others :-(. I'm sure about that too, that is really too bad :-( However, the reason why I'm in this business right now was that a (by now documented) criminal person gained access through a FreeBSD firewall, even though the filters claimed that it wasn't possible. This was not something I could have sitting on my shoulders as a security supplier. I decided to fix it once and for all, so that the policy would be entirely in the hands of the sysadmin, rather than some of it being done in a very obscure piece of code. Security will always require people to know what they do, unfortunately. > > You should be on -committers if you run -stable or -current. If you were, > > you would have seen it. > > If I could get half-way through the stuff I'm obliged to read now .. Talk to me about it... Ohh, and don't forget to read >all< of Terrys emails :-) Now, how about you check out the ipfw.8 from -current and send me your comments, and possibly a couple of good commented rule-sets for the doc, then I'll make sure the kernel-code does what we want it to and what we think ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Mon Feb 26 06:44:37 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA22142 for current-outgoing; Mon, 26 Feb 1996 06:44:37 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id GAA22136 Mon, 26 Feb 1996 06:44:34 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id IAA15422; Mon, 26 Feb 1996 08:43:14 -0600 From: Joe Greco Message-Id: <199602261443.IAA15422@brasil.moneng.mei.com> Subject: Re: -stable hangs at boot (fwd) To: imb@scgt.oz.au (michael butler) Date: Mon, 26 Feb 1996 08:43:14 -0600 (CST) Cc: phk@critter.tfs.com, stable@freebsd.org, current@freebsd.org In-Reply-To: <199602261341.AAA09032@asstdc.scgt.oz.au> from "michael butler" at Feb 27, 96 00:41:15 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org Precedence: bulk > Poul-Henning Kamp writes: > > > > If you ^C your way to a shell prompt, there's a single rule that's in > > > the firewall list saying "deny all from any to any". Courtesy of the > > > same recent brain-damage in ipfw(8), you can't delete this rule either > > > ("setsockopt failed"). > > > If you call this "brain-damage" then you quite clearly don't need IPFW. > > I call it "brain-damage" to render a machine unbootable because it can't > "see" it's _own_ interfaces. AFAIK, firewalls by default prevent packets > passing _through_ them but are themselves permitted to talk to anything they > have a route to (the previous behaviour with a default policy of "deny"). A > direct connection (interface in the same box) constitutes having a "route to". Sorry, I quite vehemently disagree. In order to preserve any pretense of being a firewall, the firewall itself MUST be able to be protected by the same policies that protect the networks it is protecting. My firewalls generally drop *everything* bound for themselves (i.e. you CANNOT telnet, ftp, NFS, finger, ping, etc from EITHER side of the firewall, the policy is that external packets may not cause the firewall to execute programs, modify data, etc - only route packets). This policy guarantees the invulnerability of the firewall - and generally the nets that I firewall have similar rules. You cannot have a firewall that firewalls routed packets but not packets to itself. The chance exists for someone to cause something to happen on the firewall (be it a telnet session, whatever), and once your firewall is compromised, the firewall is useless. The firewall MUST be effectively protected itself. My 2.0.5R/2.1.0R firewalls start out with the assumption that the world is not firewalled and I build firewalls from that point, restricting vast ranges. It would probably be "easier" for the reverse to happen, at least for me. Either way - I don't care because I know the desired end result. > Further, there are no hints whatsoever in the current rc, sysconfig, > netstart, et al to indicate that this (current condition) is the problem. > Even if this (IMHO unusual) behaviour was documented it wouldn't be so much > of a problem, Sure, absolutely agree with that! :-) ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-current Mon Feb 26 06:55:57 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA22593 for current-outgoing; Mon, 26 Feb 1996 06:55:57 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id GAA22588 Mon, 26 Feb 1996 06:55:55 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id IAA15449; Mon, 26 Feb 1996 08:54:41 -0600 From: Joe Greco Message-Id: <199602261454.IAA15449@brasil.moneng.mei.com> Subject: Re: -stable hangs at boot (fwd) To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Mon, 26 Feb 1996 08:54:40 -0600 (CST) Cc: imb@scgt.oz.au, stable@freebsd.org, current@freebsd.org In-Reply-To: <11519.825344528@critter.tfs.com> from "Poul-Henning Kamp" at Feb 26, 96 03:22:08 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org Precedence: bulk > > Poul-Henning Kamp writes: > > > > > Well, this happens to be your view. I know machines where IPFW are being > > > used to restrict what users on the machine can do, this is only possible > > > if you filter >ALL< traffic, to and from the machine. > > > > OK .. but, personally, I wouldn't call or attempt to use those boxes as > > firewalls .. any "sensitive" firewall/filtering router I have control over > > has two valid accounts which have any access at all, mine and one other, > > with limited privilege, for daily monitoring. No users == much reduced risk. > > I agree, I'd do that too. However, that is all a question of what your > policy is. The IPFW, should not affect your policy, but merely be able to > implement it. Agree. Sometimes you use IPFW for "related but not really" policy things. The uses are quite varied. My firewalls all have a "root" account and require console access, my routers have a single wheel user. But beyond that, I use it in several "insecure" places: The PPP/term servers I build will drop packets that claim a source address that is not assigned to the term server. (think: prevent IP spoofing). They also drop routing packets and a few other things that "shouldn't or don't need to happen". My public access UNIX system, Solaria, is not allowed to access the Internet directly because it doesn't generate the revenue that's paying for the T1. I use IPFW's accounting abilities in numerous places. Etc. None of these are "secure" or absolutely required, even, but the functionality of IPFW makes life so much easier. > However, the reason why I'm in this business right now was that a (by now > documented) criminal person gained access through a FreeBSD firewall, even > though the filters claimed that it wasn't possible. This was not something > I could have sitting on my shoulders as a security supplier. :-( ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-current Mon Feb 26 07:38:22 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA25664 for current-outgoing; Mon, 26 Feb 1996 07:38:22 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA25640 Mon, 26 Feb 1996 07:38:15 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id IAA29287; Mon, 26 Feb 1996 08:40:53 -0700 Date: Mon, 26 Feb 1996 08:40:53 -0700 From: Nate Williams Message-Id: <199602261540.IAA29287@rocky.sri.MT.net> To: Poul-Henning Kamp Cc: michael butler , stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-Reply-To: <11364.825341183@critter.tfs.com> References: <199602261228.XAA07877@asstdc.scgt.oz.au> <11364.825341183@critter.tfs.com> Sender: owner-current@freebsd.org Precedence: bulk Poul-Henning Kamp writes: > > If you ^C your way to a shell prompt, there's a single rule that's in the > > firewall list saying "deny all from any to any". Courtesy of the same recent > > brain-damage in ipfw(8), you can't delete this rule either ("setsockopt > > failed"). > > If you call this "brain-damage" then you quite clearly don't need IPFW. I understand that it's there to stop a race condition where folks can 'get into' the system before the FW rules are brought in. However, ... > > I suspect the very same problem in -current. > > > > The only workaround I can think of is to add "ipfw addf accept .." > > statements _prior_ to the running of ifconfig in netstart .. theory as yet > > untested .. > > This is all correct, designed that way, and it is the way it should work, > according to all material I have on the subject. > > If you have IPFW in your kernel, you don't want it to pass any packets > you haven't approved in your filters. > > QED: Setup your filters before anything gets passed. I can't do this on my box at all. It's a PPP connection, and *all* of the filtering is done on my PPP interface, which can vary depending on incoming calls. So, by having a default 'global' firewall entry I have a couple problems. 1) There is no established way to have it be on a per-process. This is *bad* news for me since my PPP box is also my DNS/router. I can't wait for my PPP connection to come up before I add entries, and I want all of my local machines to have access to *everything* on my router box. 2) There is no established method for adding IPFW entries in FreeBSD. If we are going to make this the default method, I think we need some hooks in /etc/netstart added to make this work. 3) The code -stable is un-documented and incomplete w/regard to -current. The documentation in -stable hasn't been updated yet. Here is the last entry for the ipfw.8 man-page. revision 1.7.4.5 date: 1996/02/23 15:28:38; author: phk; state: Exp; lines: +2 -0 Make ipfw handle the new kernel stuff. Put notice in man-page that it doesn't match reality right now. - But there have been commits since this time to the man-page, so I'm assuming that documentation has been written to document the new functionality. > Wrt to the rule #65535 "deny all from any to any", then you are correct, > you cannot delete it. It represents the default policy of "anything not > specifically allowed, is banned. While I understand why (see above), I still don't think this should be the 'global' default behavior. It should be applied on a specific interface since every gateway must have 2 interfaces, and only one will need the 'block everything' rule. Yes, I understand that I can add a 'open up everything' rule on my ethernet, but it'll also be necessary for all of my incoming PPP/SLIP connections. Also, how does this affect the PPP/SLIP startup code? Can a connection be established with the new IPFW code in place? > If you want to dispute this design, then please find at least one textbook > or capacity in the area who agree with you first, that will save a lot of > my time. I will dispute the design in that the current implementation *increases* the liklihood of errors due to lack of documentation and flexibility. The former may be the cause of the latter, but it's still a great cause of concern. Nate From owner-freebsd-current Mon Feb 26 07:48:49 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA26596 for current-outgoing; Mon, 26 Feb 1996 07:48:49 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA26570 Mon, 26 Feb 1996 07:48:38 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id IAA29317; Mon, 26 Feb 1996 08:51:22 -0700 Date: Mon, 26 Feb 1996 08:51:22 -0700 From: Nate Williams Message-Id: <199602261551.IAA29317@rocky.sri.MT.net> To: Poul-Henning Kamp Cc: michael butler , stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-Reply-To: <11445.825342415@critter.tfs.com> References: <199602261341.AAA09032@asstdc.scgt.oz.au> <11445.825342415@critter.tfs.com> Sender: owner-current@freebsd.org Precedence: bulk > > I call it "brain-damage" to render a machine unbootable because it > > can't "see" it's _own_ interfaces. AFAIK, firewalls by default > > prevent packets passing _through_ them but are themselves permitted > > to talk to anything they have a route to (the previous behaviour > > with a default policy of "deny"). A direct connection (interface in > > the same box) constitutes having a "route to" > > Well, this happens to be your view. I know machines where IPFW are being > used to restrict what users on the machine can do, this is only possible > if you filter >ALL< traffic, to and from the machine. This is a policy decision which is *now* the default policy for *everyone*. > The IPFW is not a policy, it's a tool to implement policies. As such it > needs to be able to implement the widest possible range of policies. It is capable of filtering all traffic into and out of a machine before w/out the the default rule. After thinking about the ramifications of this, I'm beginning to swap more towards the side of keep it more useful and document the heck out of it. Anyone who is using firewall software better be intimately knowledgable about what they are doing. If we document (there's the icky word again) the known problems with the current system w/out the obnoxious default policy (notably the race condition), then we are better off than by making the system unusable by a # of folks. > > Further, there are no hints whatsoever in the current rc, sysconfig, > > netstart, et al to indicate that this (current condition) is the problem. > > Even if this (IMHO unusual) behaviour was documented it wouldn't be so much > > of a problem, > > No, this is still on it's way. > > You should be on -committers if you run -stable or -current. If you were, > you would have seen it. I am on both, but the code in -stable is different from the code in -current, so the documentation is not up to snuff. Here's commit information for just ip_fw.c: ---------------------------- revision 1.31 date: 1996/02/24 00:17:32; author: phk; state: Exp; lines: +49 -45 The new firewall functionality: Filter on the direction (in/out). Filter on fragment/not fragment. ---------------------------- revision 1.30 date: 1996/02/23 20:11:37; author: phk; state: Exp; lines: +6 -1 I overlooked this one. ---------------------------- revision 1.29 date: 1996/02/23 15:47:49; author: phk; state: Exp; lines: +290 -719 Big sweep over the IPFIREWALL and IPACCT code. Close the ip-fragment hole. Waste less memory. Rewrite to contemporary more readable style. Kill separate IPACCT facility, use "accept" rules in IPFIREWALL. Filter incoming >and< outgoing packets. Replace "policy" by sticky "deny all" rule. Rules have numbers used for ordering and deletion. Remove "rerorder" code entirely. Count packet & bytecount matches for rules. Code in -current & -stable is now the same. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ And there have been apparently a significant commit to -current which hasn't been done to -stable at which point the documentation to -current was updated. ---------------------------- revision 1.14.4.5 date: 1996/02/23 20:10:52; author: phk; state: Exp; lines: +6 -1 Overloooked this one. ---------------------------- revision 1.14.4.4 date: 1996/02/23 15:26:03; author: phk; state: Exp; lines: +381 -694 Big sweep over the IPFIREWALL and IPACCT code. Close the ip-fragment hole. Waste less memory. Rewrite to contemporary more readable style. Kill separate IPACCT facility, use "accept" rules in IPFIREWALL. Filter incoming >and< outgoing packets. Replace "policy" by sticky "deny all" rule. Rules have numbers used for ordering and deletion. Remove "rerorder" code entirely. Count packet & bytecount matches for rules. ---------------------------- According to the -stable commit to ipfw(8) (see previous email) the documentation is invalid. Short of perusing the code (which IMHO shouldn't be necessary for -stable bits) there is no valid documentation for the code in -stable. This is unacceptable, since we are telling folks that -stable contains code that should be run in production systems. Nate From owner-freebsd-current Mon Feb 26 07:56:45 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA27167 for current-outgoing; Mon, 26 Feb 1996 07:56:45 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA27159 for ; Mon, 26 Feb 1996 07:56:43 -0800 (PST) Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA22670; Mon, 26 Feb 1996 10:56:30 -0500 Date: Mon, 26 Feb 1996 10:56:30 -0500 From: "Garrett A. Wollman" Message-Id: <9602261556.AA22670@halloran-eldar.lcs.mit.edu> To: Poul-Henning Kamp Cc: current@FreeBSD.org Subject: Re: -stable hangs at boot (fwd) In-Reply-To: <11364.825341183@critter.tfs.com> References: <199602261228.XAA07877@asstdc.scgt.oz.au> <11364.825341183@critter.tfs.com> Sender: owner-current@FreeBSD.org Precedence: bulk < said: > If you have IPFW in your kernel, you don't want it to pass any packets > you haven't approved in your filters. Um, not necessarily. I have a situation here where there is /one/ network (out of three) that I need to isolate, and everything else should operate normally. Next time I update that machine, I'll have to go hacking through the startup files to make it do what I want to do. (It doesn't matter whether some traffic gets passed while the machine is rebooting, since it doesn't take that long to reboot. In any case, no traffic would get passed until such time as net.inet.ip.forwarding is enabled, which doesn't happen until my /etc/rc.local runs.) > If you want to dispute this design, then please find at least one textbook > or capacity in the area who agree with you first, that will save a lot of > my time. Appeal to irrelevant authority. Try again. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Mon Feb 26 08:14:13 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA27800 for current-outgoing; Mon, 26 Feb 1996 08:14:13 -0800 (PST) Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA27783 Mon, 26 Feb 1996 08:14:06 -0800 (PST) Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD4.4) id DAA14868; Tue, 27 Feb 1996 03:13:54 +1100 From: michael butler Message-Id: <199602261613.DAA14868@asstdc.scgt.oz.au> Subject: Re: -stable hangs at boot (fwd) To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Tue, 27 Feb 1996 03:13:52 +1100 (EST) Cc: stable@freebsd.org, current@freebsd.org In-Reply-To: <11445.825342415@critter.tfs.com> from "Poul-Henning Kamp" at Feb 26, 96 02:46:55 pm X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk Poul-Henning Kamp writes: > Well, this happens to be your view. I know machines where IPFW are being > used to restrict what users on the machine can do, this is only possible > if you filter >ALL< traffic, to and from the machine. I haven't checked this but .. what happens to a packet which matches a "reject" rule when it's not actually destined for the machine doing the filtering .. does it still generate an ICMP "host unreachable" ? This can happen, for example, with multiple subnets on one wire .. If so .. we have our incarnation of the M$ "sniper bug" that plagued WFW and WinNT boxes and which arbitrarilt shot down packets which were not theirs to kill :-( michael From owner-freebsd-current Mon Feb 26 09:05:03 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA01268 for current-outgoing; Mon, 26 Feb 1996 09:05:03 -0800 (PST) Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA01246 for ; Mon, 26 Feb 1996 09:04:40 -0800 (PST) Received: by Sysiphos id AA10215 (5.67b/IDA-1.5 for current@FreeBSD.org); Mon, 26 Feb 1996 18:03:59 +0100 Message-Id: <199602261703.AA10215@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Mon, 26 Feb 1996 18:03:58 +0100 In-Reply-To: "David Langford" , "David Langford" "Problem with current (and stable) with TYAN MB" (Feb 26, 0:45) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: "David Langford" , "David Langford" Subject: Re: Problem with current (and stable) with TYAN MB Cc: current@freebsd.org Sender: owner-current@freebsd.org Precedence: bulk On Feb 26, 0:45, "David Langford" wrote: } Subject: Problem with current (and stable) with TYAN MB } } TYAN TITAN III } Award v2.5 } also with latest MR. BIOS bios } } PCI info: } CHIP:0 Intel 82437 Triton PCI cache memory controller rev 1 on PCI0:0 } CHIP:1 Intel 82371 Triton PCI ISA bridge rev 2 on PCI0:7 } CHIP:2 Intel 82371 Triton bustmaster IDE controller rev 2 on PCI0:7 } } It seems to hang at the end of the autoconfig part of the kernel boot. } All devices seem to probe just fine. } Windows95 seems to work very very very well on this board. } Has anyone heard of any problems like this. No, and you provided not much information that might help diagnose your problem ... What's your disk controller/drives and what other operating systems share the boot disk ? Did you make sure the root partition lies completely within the first 1024 cylinders ? Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/~se From owner-freebsd-current Mon Feb 26 09:15:37 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA01881 for current-outgoing; Mon, 26 Feb 1996 09:15:37 -0800 (PST) Received: from haven.uniserve.com (haven.uniserve.com [198.53.215.121]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA01875 Mon, 26 Feb 1996 09:15:32 -0800 (PST) Received: by haven.uniserve.com id <30786-28103>; Mon, 26 Feb 1996 09:18:08 -0800 Date: Mon, 26 Feb 1996 09:17:59 -0800 (PST) From: Tom Samplonius To: michael butler cc: Poul-Henning Kamp , stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-Reply-To: <199602261613.DAA14868@asstdc.scgt.oz.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk On Tue, 27 Feb 1996, michael butler wrote: > Poul-Henning Kamp writes: > > > Well, this happens to be your view. I know machines where IPFW are being > > used to restrict what users on the machine can do, this is only possible > > if you filter >ALL< traffic, to and from the machine. > > I haven't checked this but .. what happens to a packet which matches a > "reject" rule when it's not actually destined for the machine doing the > filtering .. does it still generate an ICMP "host unreachable" ? The system shouldn't be getting packets not destined for it, unless the interface is in promiscous mode, which it not normally. Tom From owner-freebsd-current Mon Feb 26 09:22:27 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA02299 for current-outgoing; Mon, 26 Feb 1996 09:22:27 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA02294 Mon, 26 Feb 1996 09:22:26 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tr6bZ-0003wmC; Mon, 26 Feb 96 09:20 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id QAA11761; Mon, 26 Feb 1996 16:43:42 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: Joe Greco cc: imb@scgt.oz.au, stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-reply-to: Your message of "Mon, 26 Feb 1996 08:54:40 CST." <199602261454.IAA15449@brasil.moneng.mei.com> Date: Mon, 26 Feb 1996 16:43:38 +0100 Message-ID: <11758.825349418@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org Precedence: bulk > I use IPFW's accounting abilities in numerous places. I would like to hear more about this: 1. is the present packet & byte count per rule enough ? 2. are you going to miss "bidir" much ? 3. do we need a precise, atomic "read & reset" operation ? 4. anything else ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Mon Feb 26 09:50:30 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA03872 for current-outgoing; Mon, 26 Feb 1996 09:50:30 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA03867 Mon, 26 Feb 1996 09:50:28 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tr744-0003wyC; Mon, 26 Feb 96 09:50 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id SAA11933; Mon, 26 Feb 1996 18:50:20 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: stable@freebsd.org, current@freebsd.org Subject: IPFW (was: Re: -stable hangs at boot) Date: Mon, 26 Feb 1996 18:50:16 +0100 Message-ID: <11931.825357016@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org Precedence: bulk I have tried to collapse three threads here, sorry for the cross-posting PHK: > If you have IPFW in your kernel, you don't want it to pass any packets PHK: > you haven't approved in your filters. PHK: > PHK: > QED: Setup your filters before anything gets passed. Nate: I can't do this on my box at all. It's a PPP connection, and *all* of Nate: the filtering is done on my PPP interface, which can vary depending on Nate: incoming calls. So, by having a default 'global' firewall entry I have Nate: a couple problems. Nate: 1) There is no established way to have it be on a per-process. This is Nate: *bad* news for me since my PPP box is also my DNS/router. I can't wait Nate: for my PPP connection to come up before I add entries, and I want all of Nate: my local machines to have access to *everything* on my router box. Yes you can. Add this to the top of /etc/netstart: ipfw add 65000 pass all from any to any. This changes your default policy to "pass everything". Then later you can add the restrictions you want to. Nate: 2) There is no established method for adding IPFW entries in FreeBSD. Nate: If we are going to make this the default method, I think we need some Nate: hooks in /etc/netstart added to make this work. This is next on my list of things. Nate: 3) The code -stable is un-documented and incomplete w/regard to Nate: -current. The documentation in -stable hasn't been updated yet. Here Nate: is the last entry for the ipfw.8 man-page. Reality has overtaken you again. A couple of hours ago I committed a almost complete synopsis and description to the man page. PHK: Wrt to the rule #65535 "deny all from any to any", then you are correct, PHK: you cannot delete it. It represents the default policy of "anything not PHK: specifically allowed, is banned. Nate: While I understand why (see above), I still don't think this should be Nate: the 'global' default behavior. I has to be the default, otherwise you leave a bunch of holes open in an "secure" installation. Nate: I will dispute the design in that the current implementation *increases* Nate: the liklihood of errors due to lack of documentation and flexibility. Nate: The former may be the cause of the latter, but it's still a great cause Nate: of concern. This I agree to, and I'm working as fast as I can to address it. I felt it was very important though, to give people a tool to shut what seems to be a published hole in the FreeBSD (ipfw) security. Comming up next :-) PHK: If you have IPFW in your kernel, you don't want it to pass any packets PHK: you haven't approved in your filters. Wollman: Um, not necessarily. I have a situation here where there is /one/ Wollman: network (out of three) that I need to isolate, and everything else Wollman: should operate normally. And You can do that now, you couldn't before. You may not care about the short time machines take to reboot, other people do. You can get what you want now, and now: so can some other people. PHK If you want to dispute this design, then please find at least one textbook PHK or capacity in the area who agree with you first, that will save a lot of PHK my time. Wollman: Appeal to irrelevant authority. Try again. Show me one sane authority on IP security that would defend "pass all" as the boot time default... IMB: I haven't checked this but .. what happens to a packet which matches a IMB: "reject" rule when it's not actually destined for the machine doing the IMB: filtering .. does it still generate an ICMP "host unreachable" ? IMB: This can happen, for example, with multiple subnets on one wire .. IMB: If so .. we have our incarnation of the M$ "sniper bug" that plagued WFW IMB: and WinNT boxes and which arbitrarilt shot down packets which were not IMB: theirs to kill :-( You decide if you want ICMP to be sent or the packet to silently be discarded. I am seriously considering to make the filtering better than it is now. To be effective, we need to be able to apply multiple chains of rules, something along the line of: "In" (per i/f), "Out" (per i/f), "routed", "to me" and "from me". I will probably post a strawman in tonight some time, then please take time to think over the issues and tell me your thoughts... Until then, rest assured that I'm not trying to make anybodys life misserable intentionally, I'm have merely tried to close a security hole, and at the same time improved your chances of doing so too... Poul-Henning From owner-freebsd-current Mon Feb 26 10:14:04 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA05268 for current-outgoing; Mon, 26 Feb 1996 10:14:04 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA05259 Mon, 26 Feb 1996 10:14:00 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id MAA15629; Mon, 26 Feb 1996 12:12:15 -0600 From: Joe Greco Message-Id: <199602261812.MAA15629@brasil.moneng.mei.com> Subject: Re: -stable hangs at boot (fwd) To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Mon, 26 Feb 1996 12:12:14 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, imb@scgt.oz.au, stable@freebsd.org, current@freebsd.org In-Reply-To: <11758.825349418@critter.tfs.com> from "Poul-Henning Kamp" at Feb 26, 96 04:43:38 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org Precedence: bulk > > I use IPFW's accounting abilities in numerous places. > > I would like to hear more about this: ****** Note: I am not running it under -stable or -current, the following comments are relative to 2.0.5R/2.1.0R and what little I am aware of as far as the changes you have made. Since you have asked, I have gone into detail about what _I_ would like to see. > 1. is the present packet & byte count per rule enough ? Adequate for what I am doing. I am worried, however, about the potential for byte count rollover, I don't know if it's a 32-bit or 64-bit quantity. I would like to be able to leave a "cumulative" counter running... > 2. are you going to miss "bidir" much ? !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Owwwww. See below. I use it a lot :-( > 3. do we need a precise, atomic "read & reset" operation ? I am sampling hourly and my belief is that it takes less than a second to do, and a 1/3600 error is acceptable to me. However, for those folks who might be making more practical measurements (i.e. measuring NNTP traffic to various sites every 5 seconds), a read and reset operation would be great. I believe that the current implementation allows you to sample and clear (non-atomically) individual entries, but if I am wrong, I would also like to see that, preferably atomically. And as mentioned above I would like to leave a few cumulative counters running, sampling but NOT clearing them occasionally. So the answer is "Yes but not for me right now". > 4. anything else ? Okay, here's a problem I've been wanting to solve. I have a rule: ipfw adda bidirectional all from 0/0 to 0/0 via 204.95.219.1 that I use to give me a really rough guess about my T1 loading. The problem is, I handle multiple CIDR blocks. If I had a single CIDR block, I could do # Outbound traffic ipfw adda all from CIDR/20 to 0/0 via 204.95.219.1 # Inbound traffic ipfw adda all from 0/0 to CIDR/20 via 204.95.219.1 I can add multiple rules to deal with it but that seems echhy. There are also some firewalling things I can relate to this same problem. But I *know* the interface I want to watch! What I would LIKE to see: # Outbound traffic ipfw adda all from 0/0 to 0/0 sentvia 204.95.219.1 # Inbound traffic ipfw adda all from 0/0 to 0/0 rcvdvia 204.95.219.1 In other words, I would like the ability to specify the direction the packet was travelling on the "via" interface... it would pretty much kill the main use for "bidir" that I have, and give me a much more accurate idea of what's going on. How about IPFW issues? I know you didn't ask but as long as you're in the code, maybe some of these issues are of interest to you too. Is it possible to fill in the byte/packets dropped by a particular filter? (the fields in ipfw -s -a -n l are always 0) Last time I checked (2.0.5R), the "reject" keyword didn't produce a ICMP HOST_UNREACHABLE. Last time I checked (2.0.5R), the "log" (also l before reject/deny) panicked the box. I can't match specific icmp messages - i.e. I allow ping in both directions or I break ping in both directions. That bites. The "syn" protocol (to firewall TCP connections being opened in a direction) didn't seem to work. Maybe it was just me. Obviously I know you can't possibly address all of the above, but these are all issues that I believe lower the value of IPFW. Solving some/all of these problems would go a long way towards making IPFW look much more like a professional firewalling product and not just something hacked together. (not to mention increase the utility greatly!) Thanks for your efforts, ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-current Mon Feb 26 10:39:32 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA07005 for current-outgoing; Mon, 26 Feb 1996 10:39:32 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA06997 Mon, 26 Feb 1996 10:39:28 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id MAA15680; Mon, 26 Feb 1996 12:37:51 -0600 From: Joe Greco Message-Id: <199602261837.MAA15680@brasil.moneng.mei.com> Subject: Re: -stable hangs at boot (fwd) To: tom@uniserve.com (Tom Samplonius) Date: Mon, 26 Feb 1996 12:37:51 -0600 (CST) Cc: imb@scgt.oz.au, phk@critter.tfs.com, stable@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: from "Tom Samplonius" at Feb 26, 96 09:17:59 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@FreeBSD.ORG Precedence: bulk > On Tue, 27 Feb 1996, michael butler wrote: > > > Poul-Henning Kamp writes: > > > > > Well, this happens to be your view. I know machines where IPFW are being > > > used to restrict what users on the machine can do, this is only possible > > > if you filter >ALL< traffic, to and from the machine. > > > > I haven't checked this but .. what happens to a packet which matches a > > "reject" rule when it's not actually destined for the machine doing the > > filtering .. does it still generate an ICMP "host unreachable" ? > > The system shouldn't be getting packets not destined for it, unless the > interface is in promiscous mode, which it not normally. Think about: "route add -net 123.45.67.0 -netmask 0xffffff00 some.firewall.router.org 1" Not all packet delivery(/routing) is passively sitting on your butt on an Ethernet waiting for an ARP request. Sometimes you have things pushed at you by other routers :-) In my opinion it would be most useful to catch things and return ICMP HOST_UNREACHABLE messages at the firewall. Your average Cisco/etc router can do it. The only thing you might need to be careful about would be broadcasts/multicasts. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-current Mon Feb 26 11:05:08 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA08489 for current-outgoing; Mon, 26 Feb 1996 11:05:08 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA08484 Mon, 26 Feb 1996 11:05:05 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id NAA15710; Mon, 26 Feb 1996 13:03:06 -0600 From: Joe Greco Message-Id: <199602261903.NAA15710@brasil.moneng.mei.com> Subject: Re: -stable hangs at boot (fwd) To: nate@sri.MT.net (Nate Williams) Date: Mon, 26 Feb 1996 13:03:06 -0600 (CST) Cc: phk@critter.tfs.com, imb@scgt.oz.au, stable@freebsd.org, current@freebsd.org In-Reply-To: <199602261540.IAA29287@rocky.sri.MT.net> from "Nate Williams" at Feb 26, 96 08:40:53 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org Precedence: bulk > Poul-Henning Kamp writes: > > > If you ^C your way to a shell prompt, there's a single rule that's in the > > > firewall list saying "deny all from any to any". Courtesy of the same recent > > > brain-damage in ipfw(8), you can't delete this rule either ("setsockopt > > > failed"). > > > > If you call this "brain-damage" then you quite clearly don't need IPFW. > > I understand that it's there to stop a race condition where folks can > 'get into' the system before the FW rules are brought in. However, ... THIS can be generally solved by installing the rules before configuring the interfaces (at least that's how I do it). The disadvantage is that if you re-install the rules, you probably flush the old ones first, and you leave a small opening. That is not terrible but the ideal solution would address it. Argument FOR keeping this "default" rule, IMHO. > > QED: Setup your filters before anything gets passed. > > I can't do this on my box at all. It's a PPP connection, and *all* of > the filtering is done on my PPP interface, which can vary depending on > incoming calls. So, by having a default 'global' firewall entry I have > a couple problems. That's true. > 1) There is no established way to have it be on a per-process. This is > *bad* news for me since my PPP box is also my DNS/router. I can't wait > for my PPP connection to come up before I add entries, and I want all of > my local machines to have access to *everything* on my router box. But your local machines are well known: ipfw addf pass all from nates.net/24 to nates.router You can run a script when your PPP link {goes up, comes down} that installs further firewall entries to deal with your Internet connection, including correct dynamic addresses, etc. I'm not clear on what the problem that you perceive is. > 2) There is no established method for adding IPFW entries in FreeBSD. > If we are going to make this the default method, I think we need some > hooks in /etc/netstart added to make this work. Absolutely!!!!!!!!!!! And BEFORE the interfaces are configured AND before forwarding is enabled. I simply stuck in "sh /etc/fw", where /etc/fw is a script that flushes rules and then installs the new ones. We should probably ship one that cancels out the effect of the "default" rule, but has several other examples in it. Yes, you heard that right. In my opinion having the default drop rule is a good idea. It closes some small windows of opportunity. But it will confuse the hell out of people. By default we should "undo" the problem in the config file, document it, and give examples of configurations that offer low risk / no risk firewall profiles, which users can then uncomment and activate. > 3) The code -stable is un-documented and incomplete w/regard to > -current. The documentation in -stable hasn't been updated yet. Here > is the last entry for the ipfw.8 man-page. > > revision 1.7.4.5 > date: 1996/02/23 15:28:38; author: phk; state: Exp; lines: +2 -0 > Make ipfw handle the new kernel stuff. Put notice in man-page that it > doesn't match reality right now. > - > But there have been commits since this time to the man-page, so I'm > assuming that documentation has been written to document the new > functionality. True. > > Wrt to the rule #65535 "deny all from any to any", then you are correct, > > you cannot delete it. It represents the default policy of "anything not > > specifically allowed, is banned. > > While I understand why (see above), I still don't think this should be > the 'global' default behavior. It should be applied on a specific > interface since every gateway must have 2 interfaces, and only one will > need the 'block everything' rule. Yes, but which one? The current setup doesn't worry about it, it assumes you will open up the interface you want opened. And paranoids like me do actually firewall both interfaces :-) > Yes, I understand that I can add a > 'open up everything' rule on my ethernet, but it'll also be necessary > for all of my incoming PPP/SLIP connections. Also, how does this affect > the PPP/SLIP startup code? Can a connection be established with the new > IPFW code in place? Sure. I already run the firewall rule config script before starting any interfaces. That works. (I don't see how it would interfere with a connection being established anyways, we are firewalling at the protocol level, not the byte level). > > If you want to dispute this design, then please find at least one textbook > > or capacity in the area who agree with you first, that will save a lot of > > my time. > > I will dispute the design in that the current implementation *increases* > the liklihood of errors due to lack of documentation and flexibility. > The former may be the cause of the latter, but it's still a great cause > of concern. % cat /etc/ipfw.conf #! /bin/sh - # # Default IPFW Rule Configuration File # # The kernel has a built in rule that drops all packets. The intention is # to close any window of opportunity for potential attackers. The following # rule overrides this until a local firewall policy is implemented. # ipfw addf pass all from 0/0 to 0/0 # # To define a local firewall policy, comment out the above line and insert # new rules below that define the types of traffic you wish to permit on # your network. Please note that you will need to understand the ipfw # syntax, see man ipfw(1). Also note that by commenting out the command # above, ONLY packets allowed by your declared policy will be allowed to # pass! # # Samples: # --- Allow incoming SMTP. # ipfw addf pass tcp from 0/0 to my.net.number.0/bits 25 # --- Allow outbound SMTP. # ipfw addf pass tcp from my.net.number.0/bits to 0/0 25 # --- Allow outbound telnet. # ipfw addf pass tcp from my.net.number.0/bits to 0/0 23 # --- Allow ICMP messages (ping and friends). # ipfw addf pass icmp from 0/0 to 0/0 % Note I wrote that from memory. Somebody sanity check it, commit it, and stick if [ -f /etc/ipfw.conf -a -x /sbin/ipfw ]; then sh /etc/ipfw.conf fi into /etc/rcwhereever and we can be done with this argument :-) Or we can hash this to a bloody pulp and not make any forward progress. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-current Mon Feb 26 11:06:19 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA08530 for current-outgoing; Mon, 26 Feb 1996 11:06:19 -0800 (PST) Received: from maui.com (root@waena.mrtc.maui.com [199.4.33.17]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA08524 for ; Mon, 26 Feb 1996 11:06:18 -0800 (PST) Received: from caliban.dihelix.com (caliban.dihelix.com [199.4.33.251]) by maui.com (8.6.10/8.6.6) with ESMTP id JAA12063; Mon, 26 Feb 1996 09:11:20 -1000 Received: (from root@localhost) by caliban.dihelix.com (8.7.4/8.6.9) id JAA02962; Mon, 26 Feb 1996 09:06:11 -1000 (HST) Message-Id: <199602261906.JAA02962@caliban.dihelix.com> Subject: Re: Problem with current (and stable) with TYAN MB To: se@zpr.uni-koeln.de (Stefan Esser) Date: Mon, 26 Feb 1996 09:06:11 -1000 (HST) From: "David Langford" Cc: langfod@dihelix.com, current@freebsd.org In-Reply-To: <199602261703.AA10215@Sysiphos> from "Stefan Esser" at Feb 26, 96 06:03:58 pm From: "David Langford" X-blank-line: This space intentionaly left blank. X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk >On Feb 26, 0:45, "David Langford" wrote: >} Subject: Problem with current (and stable) with TYAN MB >} >} TYAN TITAN III >} Award v2.5 >} also with latest MR. BIOS bios >} >} PCI info: >} CHIP:0 Intel 82437 Triton PCI cache memory controller rev 1 on PCI0:0 >} CHIP:1 Intel 82371 Triton PCI ISA bridge rev 2 on PCI0:7 >} CHIP:2 Intel 82371 Triton bustmaster IDE controller rev 2 on PCI0:7 >} >} It seems to hang at the end of the autoconfig part of the kernel boot. >} All devices seem to probe just fine. >} Windows95 seems to work very very very well on this board. >} Has anyone heard of any problems like this. > >No, and you provided not much information >that might help diagnose your problem ... >What's your disk controller/drives and what >other operating systems share the boot disk ? >Did you make sure the root partition lies >completely within the first 1024 cylinders ? > >Regards, STefan > http://www.zpr.uni-koeln.de/~se True I did not know what all to include in my first attempt at looking for information to the problem. This system was working on and intel Neptune board and another version of the Tyan motherboard. After a couple of exchanges with Tyan of the mother board (and BIOS revisions) to correct what looked like a problem with spontaneous reboots (in both BSD and Win95) we arrived witht the current motherboard. Again the system works very well with Win95 - in fact I havent seen Win95 (at least this Win95 ) run this good before. We tried swapping an IDE (boot drive is sd0 normally) drive in with Stable on it and the same thing occurs. We have tried different COAST (cache ram) modules and as I said before both the standard Award BIOS and MR BIOS. Here is config file: (note no ep0 - learned that as soon as new ep driver was placed into current) machine "i386" cpu "I386_CPU" cpu "I486_CPU" ident PUGA maxusers 24 config kernel root on sd0 options "COMPAT_43" options SYSVSHM options SYSVSEM options SYSVMSG options UCONSOLE options SCSIDEBUG options SCSI_REPORT_GEOMETRY controller isa0 options "AUTO_EOI_2" options BOUNCE_BUFFERS device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr options HARDFONTS options MAXCONS=4 device npx0 at isa? port "IO_NPX" irq 13 vector npxintr controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr disk wd0 at wdc0 drive 0 disk wd1 at wdc0 drive 1 controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr disk wd2 at wdc1 drive 0 disk wd3 at wdc1 drive 1 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 disk fd1 at fdc0 drive 1 device lpt0 at isa? port? tty irq 7 vector lptintr device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device sio0 at isa? port "IO_COM2" tty irq 3 vector siointr device sio0 at isa? port "IO_COM3" tty irq 5 vector siointr controller pci0 controller ahc1 device vx0 options PROBE_VERBOSE options COMPAT_LINUX From owner-freebsd-current Mon Feb 26 11:23:19 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA09555 for current-outgoing; Mon, 26 Feb 1996 11:23:19 -0800 (PST) Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA09544 for ; Mon, 26 Feb 1996 11:23:13 -0800 (PST) Received: by Sysiphos id AA13356 (5.67b/IDA-1.5 for current@freebsd.org); Mon, 26 Feb 1996 20:23:02 +0100 Message-Id: <199602261923.AA13356@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Mon, 26 Feb 1996 20:23:02 +0100 In-Reply-To: "David Langford" , "David Langford" "Re: Problem with current (and stable) with TYAN MB" (Feb 26, 9:06) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: "David Langford" , "David Langford" Subject: Re: Problem with current (and stable) with TYAN MB Cc: current@freebsd.org Sender: owner-current@freebsd.org Precedence: bulk On Feb 26, 9:06, "David Langford" wrote: } Subject: Re: Problem with current (and stable) with TYAN MB } True I did not know what all to include in my first attempt at looking for } information to the problem. Hmm, Ok, but there is some information on the minimum contents of a problem report somewhere in the docs. (Don't ask me where, didn't need it for quite some time :) } This system was working on and intel Neptune board and another version of the Tyan motherboard. After a couple of exchanges with Tyan of the mother board } (and BIOS revisions) to correct what looked like a problem with spontaneous } reboots (in both BSD and Win95) we arrived witht the current motherboard. } Again the system works very well with Win95 - in fact I havent seen Win95 } (at least this Win95 ) run this good before. } We tried swapping an IDE (boot drive is sd0 normally) drive in with Stable } on it and the same thing occurs. } } We have tried different COAST (cache ram) modules and as I said before both } the standard Award BIOS and MR BIOS. Doesn't look like Cache/RAM or BIOS problem. } Here is config file: } (note no ep0 - learned that as soon as new ep driver was placed into current) } machine "i386" } cpu "I386_CPU" } cpu "I486_CPU" Hmmm, there is NO cpu "I586_CPU" line. Does you current kernel contain it ??? } ident PUGA } maxusers 24 } config kernel root on sd0 } options "COMPAT_43" } options SYSVSHM } options SYSVSEM } options SYSVMSG } options UCONSOLE } options SCSIDEBUG } options SCSI_REPORT_GEOMETRY } controller isa0 } options "AUTO_EOI_2" This doesn't work with all chip sets, so I'd not try it unless the system worked without, first ... } options BOUNCE_BUFFERS Not needed unless you got a bus-master ISA controller (Adaptec 1542 or ISA Buslogic). } device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr } options HARDFONTS } options MAXCONS=4 } device npx0 at isa? port "IO_NPX" irq 13 vector npxintr } controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr } disk wd0 at wdc0 drive 0 } disk wd1 at wdc0 drive 1 } controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr } disk wd2 at wdc1 drive 0 } disk wd3 at wdc1 drive 1 } controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr } disk fd0 at fdc0 drive 0 } disk fd1 at fdc0 drive 1 } device lpt0 at isa? port? tty irq 7 vector lptintr } device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr } device sio0 at isa? port "IO_COM2" tty irq 3 vector siointr } device sio0 at isa? port "IO_COM3" tty irq 5 vector siointr } controller pci0 } controller ahc1 Ok. You didn't tell about your hardware, but I assume the SCSI card is detected and all drives are identified ... } device vx0 } options PROBE_VERBOSE The PROBE_VERBOSE is a NOP, since this functionality is now handled by the -v boot option ... } options COMPAT_LINUX Ok. Please tri with I586_CPU and let me know what you find ... Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/~se From owner-freebsd-current Mon Feb 26 12:15:42 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA12787 for current-outgoing; Mon, 26 Feb 1996 12:15:42 -0800 (PST) Received: from mailgate.ericsson.se (mailgate.ericsson.se [130.100.2.2]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA12782 for ; Mon, 26 Feb 1996 12:15:37 -0800 (PST) Received: from sa.erisoft.se (epls01.sa.erisoft.se [150.132.128.1]) by mailgate.ericsson.se (8.6.11/1.0) with SMTP id VAA18269 for ; Mon, 26 Feb 1996 21:15:35 +0100 Received: from sws021.sa.erisoft.se by sa.erisoft.se (4.1/SMI-4.1-ERIS0.99) id AA11261; Mon, 26 Feb 96 21:15:34 +0100 From: Mattias.Gronlund@sa.erisoft.se (Mattias Gronlund) Received: by sws021.sa.erisoft.se (5.x/client-1.3) id AA08474; Mon, 26 Feb 1996 21:14:50 +0100 Message-Id: <9602262014.AA08474@sws021.sa.erisoft.se> Subject: Problems using kerneldump To: FreeBSD-current@FreeBSD.ORG Date: Mon, 26 Feb 1996 21:14:49 +0100 (MET) Cc: Mattias.Gronlund@sa.erisoft.se X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG Precedence: bulk Hi, I have some problems with the nfs code when running netbooted and current from 960226, the problem is that I get log messages saying biodone: buffer already done when running kvm_mkdb and when saving files with vi. At last I managed to get the symboltable accessible for ddb and could insert a panic line in the biodone routine so that I could get a trace and se that the faulty call come from the nfs-code. I then decided that I should try get a core to debug with gdb -k to get that I used `call dumpsys' in ddb and the system dumped the core. I then rebooted and run `savecore /mnt' waited for a while. Then when trying to debug the core all I got was this: bash# gdb -k kernel /mnt/vmcore.0 GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.13 (i386-unknown-freebsd), Copyright 1994 Free Software Foundation, Inc... IdlePTD 909000 current pcb at 1efd3c panic: biodone: buffer already done #0 0x0 in ?? () (kgdb) where #0 0x0 in ?? () (kgdb) I had expected to get a backtrace like the one in ddb and some way to see what was going on. Can this have someting with the fact that I did go multiuser before running savecore, can it have something to do with the fact that I'm netbooting the machine or what can it be I'm doing wrong? /Mattias From owner-freebsd-current Mon Feb 26 12:25:33 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA13229 for current-outgoing; Mon, 26 Feb 1996 12:25:33 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA13212 Mon, 26 Feb 1996 12:25:29 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tr9U0-0003wyC; Mon, 26 Feb 96 12:25 PST Apparently-To: , Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id VAA12244; Mon, 26 Feb 1996 21:25:17 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol Date: Mon, 26 Feb 1996 21:25:15 +0100 Message-ID: <12238.825366315@critter.tfs.com> From: Poul-Henning Kamp Subject: IP filtering strawman, comments please. MIME-Version: 1.0 Content-Type: multipart/digest; boundary="----- =_aaaaaaaaaa" Sender: owner-current@freebsd.org Precedence: bulk ------- =_aaaaaaaaaa To: hackers@freebsd.org Subject: IP filtering strawman, comments please. Date: Mon, 26 Feb 1996 21:25:15 +0100 Message-ID: <12238.825366315@critter.tfs.com> From: Poul-Henning Kamp Sorry for the wide cross-posting, followups to "hackers" only please ! IP filtering in FreeBSD, a strawman proposal. Poul-Henning Kamp 26 feb 1996 Ver: 1.1 This is a strawman intended to foster discussion about the future support for IP packet filtering in the FreeBSD kernel. Fig 1 shows a simplified schematic of the paths of IP packets in the FreeBSD kernel, and various potential spots for applying filters. =========================================================================== if0 --->(0i)--->+ | if1 --->(1i)--->+ | applications if2 --->(2i)--->+ ^ | | | v +--->(A)---> protocol stack --->(B)--->+ | | +--->(Ci)---> route through ---->(Co)--->+ | +--->(0o)---> if0 | +--->(1o)---> if1 | +--->(2o)---> if2 == Fig 1 ================================================================== The present support (as of 960226) provides the following support: There is one chain of rules, and it is applied at (A), (B), (Ci) and (Co). The following information is available, in addition to the packet itself: At (A) and (Ci), receiving interface. At (B) and (Co), destination interface. Now, this is clearly not optimal from particular many points, therefore I suggest the following model instead: There will be multiple chains of rules as follows: For each interface, two chains of rules. One filters incoming packets, the other outgoing packets. In Fig 1 these are the pairs (0i/0o), (1i/1o) &c. No information is available apart from the packet itself. There will be a filter-chain at (A) to filter what packets we let into the local protocol stack. In addition to the packet, information about the arrival interface is available. There will be a filter-chain at (B) to filter what packets we let out of the local protocol stack. In addition to the packet, information about the destination interface is available. There will be two filter-chains at (Ci) and (Co) to filter what packets we route through this machine. At (Ci) the arrival interface is known and at (Co) the destination interface is known in addition to the packet itself. Rules are numbered with 16 bit integers, and can appear on any number of filter-chains, such that a conceptual matrix is formed, as illustrated in Fig 2: =========================================================================== Rule# criteria 0i 1i 2i A Ci Co B 0o 1o 2o --------------------------------------------------------------------------- 00010 Deny all loose source route X X X X 00020 Deny all strict source route X X X X 00030 Deny all traffic via if0 X X 00040 Deny all tcp setup packets X X 65535 Allow all traffic X X X X X X X X X X == Fig 2 ================================================================== At each filtering point, the rules are applied in numeric order, until one of them matches the packet, the action from that rule is then taken. Just as important as where a rule can be applied, is what the rule can express, I suggest this functionality, this is more or less what we have now as well: Source-ip matches target+netmask Destination-ip matches target+netmask Protocol matches (any, udp, icmp, tcp, other). Packet has (not) ip-option(s) (loose source route, strict source route, timestamp, record route, other). Interface matches name Interface matches IP. For UDP & TCP: source-port matches target(-range) destination-port matches target(-range) For TCP: packet has (not) TCP flags (syn, rst, psh, urg, ack). Packet is (not) a non-initial fragment. Packet is (not) a broadcast. Packet is (not) a multicast. And finally, what should be done when the rule matches: "drop" the packet is discarded. "refuse" as drop, but an ICMP packet is sent if applicable. "pass" the packet is OK and continues it's merry way. "count" the counters for this rule is updated, but the rule doesn't match the packet, and the next rule is tried. "divert" the packet is sent to a (specific) instance of the tun# interface, where a user-mode process can have fun with it. Some modifiers to this exist: "printf" register the match with printf. "syslog" register the match with syslog. "verbose" be very detailed. "hexdump" be very very detailed. The changes to the code to support this scheme are rather simple: Add reference counts to each rule. Add two rule-chain headers to the if structure. Add the logic to specify what chains a rule applies to. Make sure ip_output knows if the packet was locally generated or routed. Comments ? Poul-Henning ------- =_aaaaaaaaaa-- From owner-freebsd-current Mon Feb 26 12:25:58 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA13294 for current-outgoing; Mon, 26 Feb 1996 12:25:58 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA13259 Mon, 26 Feb 1996 12:25:48 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id MAA00360; Mon, 26 Feb 1996 12:26:22 -0700 Date: Mon, 26 Feb 1996 12:26:22 -0700 From: Nate Williams Message-Id: <199602261926.MAA00360@rocky.sri.MT.net> To: Poul-Henning Kamp Cc: stable@freebsd.org, current@freebsd.org Subject: Re: IPFW (was: Re: -stable hangs at boot) In-Reply-To: <11931.825357016@critter.tfs.com> References: <11931.825357016@critter.tfs.com> Sender: owner-current@freebsd.org Precedence: bulk > I have tried to collapse three threads here, sorry for the cross-posting No problem, I like it this way and appreciate the extra work you've done. > PHK: > If you have IPFW in your kernel, you don't want it to pass any packets > PHK: > you haven't approved in your filters. > PHK: > > PHK: > QED: Setup your filters before anything gets passed. > > Nate: I can't do this on my box at all. It's a PPP connection, and *all* of > Nate: the filtering is done on my PPP interface, which can vary depending on > Nate: incoming calls. So, by having a default 'global' firewall entry I have > Nate: a couple problems. > > Nate: 1) There is no established way to have it be on a per-process. This is > Nate: *bad* news for me since my PPP box is also my DNS/router. I can't wait > Nate: for my PPP connection to come up before I add entries, and I want all of > Nate: my local machines to have access to *everything* on my router box. > > Yes you can. Add this to the top of /etc/netstart: > > ipfw add 65000 pass all from any to any. OK so far, but it needs to be in doable from a sysconfig or netstart hook (which you talk about later). > This changes your default policy to "pass everything". > Then later you can add the restrictions you want to. So far so good. :) > Nate: 2) There is no established method for adding IPFW entries in FreeBSD. > Nate: If we are going to make this the default method, I think we need some > Nate: hooks in /etc/netstart added to make this work. > This is next on my list of things. I'll be glad to see it go in. > Nate: 3) The code -stable is un-documented and incomplete w/regard to > Nate: -current. The documentation in -stable hasn't been updated yet. Here > Nate: is the last entry for the ipfw.8 man-page. > > Reality has overtaken you again. A couple of hours ago I committed a almost > complete synopsis and description to the man page. Glad to hear it, but it happened after I sup'd the CVS tree. It also appears that you need to add the patch you just made to -current into -stable as well. Don't you just hate having to keep two trees in sync sometimes? (Though the advantages outweigh the disadvantages). > PHK: Wrt to the rule #65535 "deny all from any to any", then you are correct, > PHK: you cannot delete it. It represents the default policy of "anything not > PHK: specifically allowed, is banned. > > Nate: While I understand why (see above), I still don't think this should be > Nate: the 'global' default behavior. > > I has to be the default, otherwise you leave a bunch of holes open in an > "secure" installation. Unless you require them to add a line similar to what you are requiring me to do in /etc/sysconfig. I think it should be sysconfig know to 'lock-down' the system, rather than have it be the default. It's just as easy to add a line to /etc/netstart to 'tighten up' the system as it is to 'loosen-up'. The latter will cause us much more support grief than the former. > Nate: I will dispute the design in that the current implementation *increases* > Nate: the liklihood of errors due to lack of documentation and flexibility. > Nate: The former may be the cause of the latter, but it's still a great cause > Nate: of concern. > > This I agree to, and I'm working as fast as I can to address it. I felt > it was very important though, to give people a tool to shut what seems > to be a published hole in the FreeBSD (ipfw) security. Comming up next :-) Waiting expectantly. (And I won't even bug you about reviewing the PC-CARD patches either. *grin*) > PHK: If you have IPFW in your kernel, you don't want it to pass any packets > PHK: you haven't approved in your filters. > > Wollman: Um, not necessarily. I have a situation here where there is /one/ > Wollman: network (out of three) that I need to isolate, and everything else > Wollman: should operate normally. > > And You can do that now, you couldn't before. Sure you could. I'm doing that now w/out the changes you've made. > You may not care about > the short time machines take to reboot, other people do. You can get > what you want now, and now: so can some other people. You could do it before, and can do it now if we add a line to /etc/netstart which is off by default which shuts down the entire machine. > PHK If you want to dispute this design, then please find at least one textbook > PHK or capacity in the area who agree with you first, that will save a lot of > PHK my time. > > Wollman: Appeal to irrelevant authority. Try again. > > Show me one sane authority on IP security that would defend "pass all" > as the boot time default... > I am seriously considering to make the filtering better than it is now. > > To be effective, we need to be able to apply multiple chains of rules, > something along the line of: "In" (per i/f), "Out" (per i/f), "routed", > "to me" and "from me". Doesn't the current code already do that? Obviously since it wasn't filtering outgoing packets before it didn't, but I'm not sure I could see the need for filtering differently for incoming vs. outgoing (except in the case of syn. packets). That reminds me. I haven't looked yet, but does the new code also filter out routing information? The old code didn't (and other firewall code I have used does). > Until then, rest assured that I'm not trying to make anybodys life misserable > intentionally, I'm have merely tried to close a security hole, and at the > same time improved your chances of doing so too... If you would have had the 'entire' solution in place at the same time as you made the changes I suspect most of this wouldn't be happening. Providing a solution I can't use simply makes it more difficult for me since I must do extra work to 'back out' the changes since I can't use them. I'm not tracking -current on my router box since that would be silly, but I can't even use the fixes you've put into fix holes w/out documentation. Nate From owner-freebsd-current Mon Feb 26 12:27:39 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA13473 for current-outgoing; Mon, 26 Feb 1996 12:27:39 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA13425 Mon, 26 Feb 1996 12:27:24 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id MAA00322; Mon, 26 Feb 1996 12:20:04 -0700 Date: Mon, 26 Feb 1996 12:20:04 -0700 From: Nate Williams Message-Id: <199602261920.MAA00322@rocky.sri.MT.net> To: Joe Greco Cc: nate@sri.MT.net (Nate Williams), phk@critter.tfs.com, stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-Reply-To: <199602261903.NAA15710@brasil.moneng.mei.com> References: <199602261540.IAA29287@rocky.sri.MT.net> <199602261903.NAA15710@brasil.moneng.mei.com> Sender: owner-current@freebsd.org Precedence: bulk Joe Greco writes: > > Poul-Henning Kamp writes: > > > > If you ^C your way to a shell prompt, there's a single rule that's in the > > > > firewall list saying "deny all from any to any". Courtesy of the same recent > > > > brain-damage in ipfw(8), you can't delete this rule either ("setsockopt > > > > failed"). > > > > > > If you call this "brain-damage" then you quite clearly don't need IPFW. > > > > I understand that it's there to stop a race condition where folks can > > 'get into' the system before the FW rules are brought in. However, ... > > THIS can be generally solved by installing the rules before configuring the > interfaces (at least that's how I do it). I can't do this on my box, since I don't know which interface is going to be used for my outgoing PPP connections until after the interface is completely up. That's the disadvantage of keeping the system running all the time no matter what the network affair is. The current system won't allow me to do this now. Now, I can explicitly force the old behavior by adding a rule to open up the world, but I haven't gained anything. The reason I think it should be open is because of support. Making the system unable to talk to *anything* at bootup is going to cause more support headaches than it's worth. If we add a line to /etc/sysconfig similar to: # Set this to yes if you want to avoid *any* possibiity of un-authorized # packets from getting into your system. # Note: # By setting this to YES, *NO* network data will be allowed into your # system, which may cause mis-configured firewalls to take a *very* # long # time to boot if they rely on external networking services. SECURE_IPFW=NO > The disadvantage is that if you re-install the rules, you probably > flush the old ones first, and you leave a small opening. That is not > terrible but the ideal solution would address it. Argument FOR > keeping this "default" rule, IMHO. I disagree for support reasons. See above. > > > QED: Setup your filters before anything gets passed. > > > > I can't do this on my box at all. It's a PPP connection, and *all* of > > the filtering is done on my PPP interface, which can vary depending on > > incoming calls. So, by having a default 'global' firewall entry I have > > a couple problems. > > That's true. > > > 1) There is no established way to have it be on a per-process. This is > > *bad* news for me since my PPP box is also my DNS/router. I can't wait > > for my PPP connection to come up before I add entries, and I want all of > > my local machines to have access to *everything* on my router box. > > But your local machines are well known: > > ipfw addf pass all from nates.net/24 to nates.router > > You can run a script when your PPP link {goes up, comes down} that installs > further firewall entries to deal with your Internet connection, including > correct dynamic addresses, etc. Which I do. However, how do I filter out packets from machines that *appear* to be mine from external now that I've setup the above default rule? > I'm not clear on what the problem that you perceive is. The old behavior was more flexible and made for less confusion. :) > In my opinion having the default drop rule is a good idea. It closes some > small windows of opportunity. But it will confuse the hell out of > people. Yep. I think we should make it really easy to add a default 'close' rule, but leave the stock behavior, because of the confusion. Make the user explicitly firewall everything rather than forcing him to open up things. This is the behavior all other firewalls take, so why should we be different? > > > Wrt to the rule #65535 "deny all from any to any", then you are correct, > > > you cannot delete it. It represents the default policy of "anything not > > > specifically allowed, is banned. > > > > While I understand why (see above), I still don't think this should be > > the 'global' default behavior. It should be applied on a specific > > interface since every gateway must have 2 interfaces, and only one will > > need the 'block everything' rule. > > Yes, but which one? The current setup doesn't worry about it, it assumes > you will open up the interface you want opened. And paranoids like me do > actually firewall both interfaces :-) There have been two people on the list that disagree with the 'policy' decision, and two that agree. I think we should go with the behavior other firewall vendors use and let the user choose his own default policy, which you and Poul are free to do. > > Yes, I understand that I can add a > > 'open up everything' rule on my ethernet, but it'll also be necessary > > for all of my incoming PPP/SLIP connections. Also, how does this affect > > the PPP/SLIP startup code? Can a connection be established with the new > > IPFW code in place? > > Sure. I already run the firewall rule config script before starting any > interfaces. That works. (I don't see how it would interfere with a > connection being established anyways, we are firewalling at the protocol > level, not the byte level). I wasn't sure if some of the 'startup' code required some IP traffic late in the game. Nate From owner-freebsd-current Mon Feb 26 12:45:55 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA14702 for current-outgoing; Mon, 26 Feb 1996 12:45:55 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA14697 Mon, 26 Feb 1996 12:45:53 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tr9mM-0003x0C; Mon, 26 Feb 96 12:44 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id VAA12321; Mon, 26 Feb 1996 21:44:16 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: Joe Greco cc: imb@scgt.oz.au, stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-reply-to: Your message of "Mon, 26 Feb 1996 12:12:14 CST." <199602261812.MAA15629@brasil.moneng.mei.com> Date: Mon, 26 Feb 1996 21:44:14 +0100 Message-ID: <12319.825367454@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org Precedence: bulk > > 1. is the present packet & byte count per rule enough ? > > Adequate for what I am doing. I am worried, however, about the potential > for byte count rollover, I don't know if it's a 32-bit or 64-bit quantity. > I would like to be able to leave a "cumulative" counter running... yes, I would really love to make them 64 instead of 32, but right now the structure is 64bytes, and I'd hate to increase it to 128 :-( > > 2. are you going to miss "bidir" much ? > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > Owwwww. See below. I use it a lot :-( I thought so, it's just that we need a lot of special code to do it, and I think it is kind of messy anyway... > > 3. do we need a precise, atomic "read & reset" operation ? > > I am sampling hourly and my belief is that it takes less than a second to > do, and a 1/3600 error is acceptable to me. However, for those folks who > might be making more practical measurements (i.e. measuring NNTP traffic to > various sites every 5 seconds), a read and reset operation would be great. Ok, not bad to do. > So the answer is "Yes but not for me right now". OK, will think. > > 4. anything else ? > > Okay, here's a problem I've been wanting to solve. I have a rule: > > ipfw adda bidirectional all from 0/0 to 0/0 via 204.95.219.1 > > that I use to give me a really rough guess about my T1 loading. > > The problem is, I handle multiple CIDR blocks. If I had a single CIDR > block, I could do CIDR ? Uhm, Canned Indian Doughnut Rolls ? no, hmm, I guess, Contiguous Internet something ? > *know* the interface I want to watch! What I would LIKE to see: > > # Outbound traffic > ipfw adda all from 0/0 to 0/0 sentvia 204.95.219.1 > > # Inbound traffic > ipfw adda all from 0/0 to 0/0 rcvdvia 204.95.219.1 Check out the strawman I just emailed, and actually you can do that in the present code: ipfw add count from any to any in via 204.95.219.1 ipfw add count from any to any out via 204.95.219.1 :-) > In other words, I would like the ability to specify the direction the packet > was travelling on the "via" interface... it would pretty much kill the main > use for "bidir" that I have, and give me a much more accurate idea of what's > going on. got it :-) > How about IPFW issues? I know you didn't ask but as long as you're in the > code, maybe some of these issues are of interest to you too. > > Is it possible to fill in the byte/packets dropped by a particular filter? > (the fields in ipfw -s -a -n l are always 0) It is :-) I can see that I'm about two days ahead of you still :-) > Last time I checked (2.0.5R), the "reject" keyword didn't produce a > ICMP HOST_UNREACHABLE. It only does in some cases, I'll have to check it out a bit. It's a mine- field, so I'm very careful. > Last time I checked (2.0.5R), the "log" (also l before reject/deny) panicked > the box. doesn't now. > I can't match specific icmp messages - i.e. I allow ping in both directions > or I break ping in both directions. That bites. Hmmm, noted. > The "syn" protocol (to firewall TCP connections being opened in a direction) > didn't seem to work. Maybe it was just me. It does now, better than ever I think. Sounds like you should take a peek on the ipfw.8 manpage of -stable or -current, you may just like it :-) > Obviously I know you can't possibly address all of the above, but these are try me :-) > all issues that I believe lower the value of IPFW. Solving some/all of > these problems would go a long way towards making IPFW look much more like a > professional firewalling product and not just something hacked together. > (not to mention increase the utility greatly!) I'm looking forward to your comments on the strawman I sent out! -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Mon Feb 26 12:57:46 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA15456 for current-outgoing; Mon, 26 Feb 1996 12:57:46 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA15432 Mon, 26 Feb 1996 12:56:48 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id OAA15921; Mon, 26 Feb 1996 14:55:26 -0600 From: Joe Greco Message-Id: <199602262055.OAA15921@brasil.moneng.mei.com> Subject: Re: -stable hangs at boot (fwd) To: nate@sri.MT.net (Nate Williams) Date: Mon, 26 Feb 1996 14:55:26 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, nate@sri.MT.net, phk@critter.tfs.com, stable@freebsd.org, current@freebsd.org In-Reply-To: <199602261920.MAA00322@rocky.sri.MT.net> from "Nate Williams" at Feb 26, 96 12:20:04 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org Precedence: bulk > I can't do this on my box, since I don't know which interface is going > to be used for my outgoing PPP connections until after the interface is > completely up. That's the disadvantage of keeping the system running > all the time no matter what the network affair is. The current system > won't allow me to do this now. Why not? Stick a few rules with a variable in a script that is called when the interface is started. This can be driven from sysconfig, OR manually by startslip/ppp/etc. I do this all the time for routing purposes. > Now, I can explicitly force the old behavior by adding a rule to open up > the world, but I haven't gained anything. YOU haven't, but you haven't lost anything either. On the other hand, it's fixed a loophole in ipfw, and OTHERS have gained something. > The reason I think it should be open is because of support. Making the > system unable to talk to *anything* at bootup is going to cause more > support headaches than it's worth. If we add a line to /etc/sysconfig > similar to: Why not just put in the sample ipfw.conf I gave at the end of the last message... > # Set this to yes if you want to avoid *any* possibiity of un-authorized > # packets from getting into your system. > # Note: > # By setting this to YES, *NO* network data will be allowed into your > # system, which may cause mis-configured firewalls to take a *very* > # long # time to boot if they rely on external networking services. > SECURE_IPFW=NO > > > The disadvantage is that if you re-install the rules, you probably > > flush the old ones first, and you leave a small opening. That is not > > terrible but the ideal solution would address it. Argument FOR > > keeping this "default" rule, IMHO. > > I disagree for support reasons. See above. And that is plain and simple bull. The problem is circumventable at that level. Just use our heads and stick in a wide-open ipfw.conf. I *agree* we can't ship something out the door that is network-dumb!!!! But if we can do a simple wide-open configuration and SOLVE your support problem AND not punch a needless hole in IPFW, LET'S DO IT. > > But your local machines are well known: > > > > ipfw addf pass all from nates.net/24 to nates.router > > > > You can run a script when your PPP link {goes up, comes down} that installs > > further firewall entries to deal with your Internet connection, including > > correct dynamic addresses, etc. > > Which I do. However, how do I filter out packets from machines that > *appear* to be mine from external now that I've setup the above default > rule? % cat /etc/ppp/ip-up ipfw addf deny all from nates.net/24 to nates.net/25 via ${nates.dynamic.ppp.address} would work for me. > > I'm not clear on what the problem that you perceive is. > > The old behavior was more flexible and made for less confusion. :) Less confusion, maybe. More confusion when it didn't work as expected. More flexible? We'll see where this is all taken in the end. I suspect the new stuff will be most flexible. Either way I think it needs to be documented. > > In my opinion having the default drop rule is a good idea. It closes some > > small windows of opportunity. But it will confuse the hell out of > > people. > > Yep. I think we should make it really easy to add a default 'close' > rule, but leave the stock behavior, because of the confusion. Make the > user explicitly firewall everything rather than forcing him to open up > things. This is the behavior all other firewalls take, so why should we > be different? I wasn't aware that that's how other firewalls work. Really, it would be GREAT to be able to edit my "ipfw.conf" file and rerun it, not having to worry about even small holes opening when "ipfw f" runs. This is all about making IPFW act like a REAL firewall. Real firewalls DON'T open holes. We have no reason to argue with this change. The sample ipfw.conf I gave in my last message addresses your concerns, provides a system that performs as you expect, yet does not have any of the holes that the rest of us are worried about. If we can agree that this is a MOST optimal solution, let's put this to bed. Thanks, ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-current Mon Feb 26 13:02:17 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA15801 for current-outgoing; Mon, 26 Feb 1996 13:02:17 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA15795 for ; Mon, 26 Feb 1996 13:02:10 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA02567; Mon, 26 Feb 1996 13:55:58 -0700 From: Terry Lambert Message-Id: <199602262055.NAA02567@phaeton.artisoft.com> Subject: Re: Opti 82C895 cache coherency ? To: imb@scgt.oz.au (michael butler) Date: Mon, 26 Feb 1996 13:55:57 -0700 (MST) Cc: current@FreeBSD.ORG In-Reply-To: <199602260929.UAA05214@asstdc.scgt.oz.au> from "michael butler" at Feb 26, 96 08:29:06 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG Precedence: bulk > I wonder if anyone can vouch for an Opti 82C895/82C602 motherboard with an > AMD 486DX4/100 in respect of cache coherency. Specifically, in combination > with an Adaptec 2842 (VLB) controller. Just trying to track down a "quirk" > with a (sort of working) -stable .. I don't know if it's -stable or the > motherboard :-( Does it work with cache disabled? If so, I suspect the VLB slot the controller is in is not a master slot. If you plan to use a VLB controller that does bus master DMA, make sure the controller is in a master slot. Identifying a master slot may require talking to 5 or 6 people at the motherboard manufacturer, and even then you might never find out the right slot. THe rule of thumb has been "the slot closest to the edge of the motherboard", for what it's worth. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Feb 26 13:11:44 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA16549 for current-outgoing; Mon, 26 Feb 1996 13:11:44 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA16526 Mon, 26 Feb 1996 13:11:31 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id OAA00842; Mon, 26 Feb 1996 14:12:45 -0700 Date: Mon, 26 Feb 1996 14:12:45 -0700 From: Nate Williams Message-Id: <199602262112.OAA00842@rocky.sri.MT.net> To: Joe Greco Cc: nate@sri.MT.net (Nate Williams), phk@critter.tfs.com, stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-Reply-To: <199602262055.OAA15921@brasil.moneng.mei.com> References: <199602261920.MAA00322@rocky.sri.MT.net> <199602262055.OAA15921@brasil.moneng.mei.com> Sender: owner-current@freebsd.org Precedence: bulk Joe Greco writes: > > I can't do this on my box, since I don't know which interface is going > > to be used for my outgoing PPP connections until after the interface is > > completely up. That's the disadvantage of keeping the system running > > all the time no matter what the network affair is. The current system > > won't allow me to do this now. > > Why not? Stick a few rules with a variable in a script that is called when > the interface is started. When I start, I don't know that it will succeed? When my link goes down, it usually means my ISP is having problem and will continue to have problems for a couple hours. During that time, a home user will dial in to the system. This user may take the ppp0 slot since the outside connection isn't used. > This can be driven from sysconfig, OR manually by > startslip/ppp/etc. I do this all the time for routing purposes. I won't know until the PPP link is successful which interface to use. Now, the first thing that happens (/etc/ppp/ip-up) is that the ipfw entries are added, but there is still that window of opportunity (which is acceptable to me) between the time the link goes up but before ip-up is run where packets can get into my machine. I consider this acceptable for me. > > Now, I can explicitly force the old behavior by adding a rule to open up > > the world, but I haven't gained anything. > > YOU haven't, but you haven't lost anything either. On the other hand, it's > fixed a loophole in ipfw, and OTHERS have gained something. See my comment. Since we have the ability to close the loophole, my concern is to minimize support headaches now. Make the default behavior less likely to bit the casual user, and make them shoot themselves in the foot by enabling it so they don't ask me questions. :) > > The reason I think it should be open is because of support. Making the > > system unable to talk to *anything* at bootup is going to cause more > > support headaches than it's worth. If we add a line to /etc/sysconfig > > similar to: > > Why not just put in the sample ipfw.conf I gave at the end of the last > message... Support. If we're going to disable it by default, then why have it enabled in the first place? > > # Set this to yes if you want to avoid *any* possibiity of un-authorized > > # packets from getting into your system. > > # Note: > > # By setting this to YES, *NO* network data will be allowed into your > > # system, which may cause mis-configured firewalls to take a *very* > > # long # time to boot if they rely on external networking services. > > SECURE_IPFW=NO > > > > > The disadvantage is that if you re-install the rules, you probably > > > flush the old ones first, and you leave a small opening. That is not > > > terrible but the ideal solution would address it. Argument FOR > > > keeping this "default" rule, IMHO. > > > > I disagree for support reasons. See above. > > And that is plain and simple bull. The problem is circumventable at that > level. Just use our heads and stick in a wide-open ipfw.conf. What's the point of having it then if it's open by default? > I *agree* we > can't ship something out the door that is network-dumb!!!! But if we can do > a simple wide-open configuration and SOLVE your support problem AND not > punch a needless hole in IPFW, LET'S DO IT. It's not punching any hole in the code. *ALL* of the firewall products I've used (not extensive by any means) are open by default and require the user to explicitly close them. If a user mis-configures the firewall it's their problem in all of the other products, why is it now FreeBSD's problem to make the users 'smarter'? > > > But your local machines are well known: > > > > > > ipfw addf pass all from nates.net/24 to nates.router > > > > > > You can run a script when your PPP link {goes up, comes down} that installs > > > further firewall entries to deal with your Internet connection, including > > > correct dynamic addresses, etc. > > > > Which I do. However, how do I filter out packets from machines that > > *appear* to be mine from external now that I've setup the above default > > rule? > > % cat /etc/ppp/ip-up > ipfw addf deny all from nates.net/24 to nates.net/25 via ${nates.dynamic.ppp.address} Ok, now all of my PPP machine are no longer able to speak to my local net, which have valid IP address in nates.net. :( Now I have to go re-write all of my rules and scripts and I've gained *NOTHING* because I have to explicitly disable the default rule anyway. You're making it *ALOT* more work for me than it needs to be. It *doesn't have to be* this hard. > > The old behavior was more flexible and made for less confusion. :) > > Less confusion, maybe. More confusion when it didn't work as > expected. I consider the 'didn't work as expected' to be bugs that are now fixed. I have problems with changing the default behavior, not with fixing bugs. > > Yep. I think we should make it really easy to add a default 'close' > > rule, but leave the stock behavior, because of the confusion. Make the > > user explicitly firewall everything rather than forcing him to open up > > things. This is the behavior all other firewalls take, so why should we > > be different? > > I wasn't aware that that's how other firewalls work. > > Really, it would be GREAT to be able to edit my "ipfw.conf" file and rerun > it, not having to worry about even small holes opening when "ipfw f" > runs. I like the way MorningStar's product works in this regard. It shuts down the link, when new entries are added, and depending on how extensive they are (I don't know what measure they use) it shuts down the link completely and re-connects. It reads a file which contains the IPFW entries, so if you modify the file you send the firewall program a HUP signal to re-read it. Unfortunately, this won't work in our case since we are using kernel code, but the general idea is sound. I'm not sure how this could be done in FreBSD though. Nate From owner-freebsd-current Mon Feb 26 13:19:36 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA17268 for current-outgoing; Mon, 26 Feb 1996 13:19:36 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA17260 Mon, 26 Feb 1996 13:19:26 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id PAA15987; Mon, 26 Feb 1996 15:17:53 -0600 From: Joe Greco Message-Id: <199602262117.PAA15987@brasil.moneng.mei.com> Subject: Re: -stable hangs at boot (fwd) To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Mon, 26 Feb 1996 15:17:53 -0600 (CST) Cc: imb@scgt.oz.au, stable@freebsd.org, current@freebsd.org In-Reply-To: <12319.825367454@critter.tfs.com> from "Poul-Henning Kamp" at Feb 26, 96 09:44:14 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org Precedence: bulk > > for byte count rollover, I don't know if it's a 32-bit or 64-bit quantity. > > I would like to be able to leave a "cumulative" counter running... > yes, I would really love to make them 64 instead of 32, but right now > the structure is 64bytes, and I'd hate to increase it to 128 :-( Ummm. :-/ Some of us wouldn't mind :-) (but some would, I know). > > > 2. are you going to miss "bidir" much ? > > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > > Owwwww. See below. I use it a lot :-( > > I thought so, it's just that we need a lot of special code to do it, > and I think it is kind of messy anyway... It is. But on the other hand, tracking two separate filters isn't always optimum. > > The problem is, I handle multiple CIDR blocks. If I had a single CIDR > > block, I could do > CIDR ? Uhm, Canned Indian Doughnut Rolls ? no, hmm, I guess, > Contiguous Internet something ? Classless Inter-Domain Routing. Basically classed routing is obsolete, has been for a while. You get assigned BLOCKS of address space and rather than having to route 8 class-C addresses separately, you route an entire group of addresses with a single routing table entry. For example, I "own" 206.55.64.0/20, which is composed of the sixteen "Class C" networks 206.55.64.0-206.55.79.255. However I also route some other blocks, too. This makes it a real pain to do conceptually simple filters like "How much traffic is going over my T1?" See http://www.rain.net/faq/cidr.faq.html. > Check out the strawman I just emailed, and actually you can do that in > the present code: > > ipfw add count from any to any in via 204.95.219.1 > ipfw add count from any to any out via 204.95.219.1 > > :-) !!!!! :-) I am very thrilled! > > Is it possible to fill in the byte/packets dropped by a particular filter? > > (the fields in ipfw -s -a -n l are always 0) > It is :-) I can see that I'm about two days ahead of you still :-) I'm impressed :-) > > Last time I checked (2.0.5R), the "reject" keyword didn't produce a > > ICMP HOST_UNREACHABLE. > It only does in some cases, I'll have to check it out a bit. It's a mine- > field, so I'm very careful. Yes, I can imagine :-) I just want my firewalls to do something mildly more social - like return a HOST_UNREACHABLE :-) It's not necessary, but it is cooler. > Sounds like you should take a peek on the ipfw.8 manpage of -stable or > -current, you may just like it :-) Q: Are there any differences that would prevent me from taking it and dropping it into a 2.0.5R or 2.1.0R based box (preferably with as little effort as humanly possible)?? > > Obviously I know you can't possibly address all of the above, but these are > try me :-) Please forgive me for underestimating you :-) ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-current Mon Feb 26 13:30:43 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA18468 for current-outgoing; Mon, 26 Feb 1996 13:30:43 -0800 (PST) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA18461 for ; Mon, 26 Feb 1996 13:30:38 -0800 (PST) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) id WAA01548; Mon, 26 Feb 1996 22:15:18 +0100 (MET) Received: (from andreas@localhost) by knobel.gun.de (8.7.4/8.7.3) id WAA02249; Mon, 26 Feb 1996 22:11:06 +0100 (MET) From: Andreas Klemm Message-Id: <199602262111.WAA02249@knobel.gun.de> Subject: Re: -current breaks shell and tset To: dbaker@cocoa.ops.neosoft.com (Daniel Baker) Date: Mon, 26 Feb 1996 22:11:05 +0100 (MET) Cc: current@freebsd.org In-Reply-To: from "Daniel Baker" at Feb 25, 96 10:40:23 pm X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk > I had the same problem with tset, and termcap and stuff. > > I fixed it by adding > > setenv TERMCAP /etc/termcap > > to my .cshrc file. > > Daniel Thanks Daniel. In the meantime I got my system working properly again after an odysse of making things... All evil started when I tried to fix hash.c with the version from -stable. The make world stopped at the point, where a missing __hash_init (if I remember right) in libc.so.3.0 broke everything. After that I carefully copied /usr/bin, /usr/lib and /usr/libexec from the 2nd FreeBSD-2.1 CD-Rom (life file system) to the system in single user mode. After that I could re-make libc and sup (which failed after writing exactly one file, hash.c). After getting the correct hash.c, rebuilding libc and sup everything went on smoothly. And after a make world I'm up again, puh. I had no backup and feared, that I probably had to reinstall the system. But finally it worked everything as I expected ;-) BTW: Who was the lucky one who didn't test the hash.c modification ?! ;-)) Andreas /// -- andreas@knobel.gun.de /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ $$ Support Unix - aklemm@wup.de $$ pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< "Ich bleibe bei der Aussage und trotze den Flames. :-)" Ulli Horlacher 02/96 From owner-freebsd-current Mon Feb 26 13:58:33 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA20789 for current-outgoing; Mon, 26 Feb 1996 13:58:33 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA20755 Mon, 26 Feb 1996 13:57:58 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id PAA16062; Mon, 26 Feb 1996 15:53:56 -0600 From: Joe Greco Message-Id: <199602262153.PAA16062@brasil.moneng.mei.com> Subject: Re: -stable hangs at boot (fwd) To: nate@sri.MT.net (Nate Williams) Date: Mon, 26 Feb 1996 15:53:55 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, nate@sri.MT.net, phk@critter.tfs.com, stable@freebsd.org, current@freebsd.org In-Reply-To: <199602262112.OAA00842@rocky.sri.MT.net> from "Nate Williams" at Feb 26, 96 02:12:45 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org Precedence: bulk > Joe Greco writes: > > > I can't do this on my box, since I don't know which interface is going > > > to be used for my outgoing PPP connections until after the interface is > > > completely up. That's the disadvantage of keeping the system running > > > all the time no matter what the network affair is. The current system > > > won't allow me to do this now. > > > > Why not? Stick a few rules with a variable in a script that is called when > > the interface is started. > > When I start, I don't know that it will succeed? When my link goes > down, it usually means my ISP is having problem and will continue to > have problems for a couple hours. During that time, a home user will > dial in to the system. This user may take the ppp0 slot since the > outside connection isn't used. So.... I must be missing something. You don't (or shouldn't) CARE if someone takes the ppp0 slot. You have the flexibility to do it by address, and you have BOTH the address AND the interface in /etc/ppp/ip-up, as I recall. > > This can be driven from sysconfig, OR manually by > > startslip/ppp/etc. I do this all the time for routing purposes. > > I won't know until the PPP link is successful which interface to use. > Now, the first thing that happens (/etc/ppp/ip-up) is that the ipfw > entries are added, but there is still that window of opportunity (which > is acceptable to me) between the time the link goes up but before ip-up > is run where packets can get into my machine. I consider this > acceptable for me. And if it's not, you should still be able to write some rules that solve your problem. I guess I'm not seeing why you think this is such a problem. > > > Now, I can explicitly force the old behavior by adding a rule to open up > > > the world, but I haven't gained anything. > > > > YOU haven't, but you haven't lost anything either. On the other hand, it's > > fixed a loophole in ipfw, and OTHERS have gained something. > > See my comment. Since we have the ability to close the loophole, my > concern is to minimize support headaches now. Make the default behavior > less likely to bit the casual user, and make them shoot themselves in > the foot by enabling it so they don't ask me questions. :) I think we agree, but you are "solving" the problem by breaking the tool. > > > The reason I think it should be open is because of support. Making the > > > system unable to talk to *anything* at bootup is going to cause more > > > support headaches than it's worth. If we add a line to /etc/sysconfig > > > similar to: > > > > Why not just put in the sample ipfw.conf I gave at the end of the last > > message... > > Support. If we're going to disable it by default, then why have it > enabled in the first place? Because!!!! It DOESN'T break the tool to do so. You simply "change your mind" and allow everything to be routed. You introduce a HOLE in the wall if you do it the other way around! > > > # Set this to yes if you want to avoid *any* possibiity of un-authorized > > > # packets from getting into your system. > > > # Note: > > > # By setting this to YES, *NO* network data will be allowed into your > > > # system, which may cause mis-configured firewalls to take a *very* > > > # long # time to boot if they rely on external networking services. > > > SECURE_IPFW=NO > > > > > > > The disadvantage is that if you re-install the rules, you probably > > > > flush the old ones first, and you leave a small opening. That is not > > > > terrible but the ideal solution would address it. Argument FOR > > > > keeping this "default" rule, IMHO. > > > > > > I disagree for support reasons. See above. > > > > And that is plain and simple bull. The problem is circumventable at that > > level. Just use our heads and stick in a wide-open ipfw.conf. > > What's the point of having it then if it's open by default? Because you're bitching about support issues and how confused people will be. If we provide a default that is wide open, and samples that are not, people have the flexibility to choose what they want to do. This is what you have been arguing FOR!!! Doing it in this manner allows us to ship a perfect brick wall IPFW that doesn't suffer from "minor instances of forgetfulness" while rules are being reloaded, but also doesn't break all the networking services and cause users to scratch their heads. > > I *agree* we > > can't ship something out the door that is network-dumb!!!! But if we can do > > a simple wide-open configuration and SOLVE your support problem AND not > > punch a needless hole in IPFW, LET'S DO IT. > > It's not punching any hole in the code. *ALL* of the firewall products > I've used (not extensive by any means) are open by default and require > the user to explicitly close them. If a user mis-configures the > firewall it's their problem in all of the other products, why is it now > FreeBSD's problem to make the users 'smarter'? I've never seen a firewall product that is open by default. That is an oxymoron. But what's the objection to a simple reversal of logic? IF what you say is true, why can't we build a BETTER firewall than the next guy by reversing the logic, dealing with the immediate "learning curve" problem that network administrators may have by putting in a default rule that makes it "magically work"? Then, when they understand the deal, they can stick in whatever rules they want. AND those of us who want real firewalling don't have to contend with a hole in the wall. > > > > But your local machines are well known: > > > > > > > > ipfw addf pass all from nates.net/24 to nates.router > > > > > > > > You can run a script when your PPP link {goes up, comes down} that installs > > > > further firewall entries to deal with your Internet connection, including > > > > correct dynamic addresses, etc. > > > > > Which I do. However, how do I filter out packets from machines that > > > *appear* to be mine from external now that I've setup the above default > > > rule? > > > > % cat /etc/ppp/ip-up > > ipfw addf deny all from nates.net/24 to nates.net/25 via ${nates.dynamic.ppp.address} > > Ok, now all of my PPP machine are no longer able to speak to my local > net, which have valid IP address in nates.net. :( Maybe I don't get what you're trying to accomplish. > Now I have to go re-write all of my rules and scripts and I've gained > *NOTHING* because I have to explicitly disable the default rule anyway. > You're making it *ALOT* more work for me than it needs to be. It > *doesn't have to be* this hard. No, you can go to CVS and extract ipfw1.0 and install it and keep your head in the sand. That seems silly. IPFW needs some changes in order to be taken seriously. With some changes comes some pain. That is unfortunate. I agree. > > > The old behavior was more flexible and made for less confusion. :) > > > > Less confusion, maybe. More confusion when it didn't work as > > expected. > > I consider the 'didn't work as expected' to be bugs that are now fixed. > I have problems with changing the default behavior, not with fixing > bugs. So let me stick my "default reversing" line in your ipfw.conf, and you are once again happy. The rest of us are happy because we have a SOLID firewall. Life is good. > > > Yep. I think we should make it really easy to add a default 'close' > > > rule, but leave the stock behavior, because of the confusion. Make the > > > user explicitly firewall everything rather than forcing him to open up > > > things. This is the behavior all other firewalls take, so why should we > > > be different? > > > > I wasn't aware that that's how other firewalls work. > > > > Really, it would be GREAT to be able to edit my "ipfw.conf" file and rerun > > it, not having to worry about even small holes opening when "ipfw f" > > runs. > > I like the way MorningStar's product works in this regard. It shuts > down the link, when new entries are added, and depending on how > extensive they are (I don't know what measure they use) it shuts down > the link completely and re-connects. It reads a file which contains the > IPFW entries, so if you modify the file you send the firewall program a > HUP signal to re-read it. Unfortunately, this won't work in our case > since we are using kernel code, but the general idea is sound. I'm not > sure how this could be done in FreBSD though. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-current Mon Feb 26 14:02:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA21108 for current-outgoing; Mon, 26 Feb 1996 14:02:54 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA21089 Mon, 26 Feb 1996 14:02:38 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id PAA01109; Mon, 26 Feb 1996 15:04:06 -0700 Date: Mon, 26 Feb 1996 15:04:06 -0700 From: Nate Williams Message-Id: <199602262204.PAA01109@rocky.sri.MT.net> To: Joe Greco Cc: nate@sri.MT.net (Nate Williams), phk@critter.tfs.com, stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-Reply-To: <199602262153.PAA16062@brasil.moneng.mei.com> References: <199602262112.OAA00842@rocky.sri.MT.net> <199602262153.PAA16062@brasil.moneng.mei.com> Sender: owner-current@freebsd.org Precedence: bulk > > > > I can't do this on my box, since I don't know which interface is going > > > > to be used for my outgoing PPP connections until after the interface is > > > > completely up. That's the disadvantage of keeping the system running > > > > all the time no matter what the network affair is. The current system > > > > won't allow me to do this now. > > > > > > Why not? Stick a few rules with a variable in a script that is called when > > > the interface is started. > > > > When I start, I don't know that it will succeed? When my link goes > > down, it usually means my ISP is having problem and will continue to > > have problems for a couple hours. During that time, a home user will > > dial in to the system. This user may take the ppp0 slot since the > > outside connection isn't used. > > So.... I must be missing something. You don't (or shouldn't) CARE if > someone takes the ppp0 slot. You have the flexibility to do it by address, > and you have BOTH the address AND the interface in /etc/ppp/ip-up, as I > recall. I admitted this below. But, it's *much* harder than it needs to be for now gain now. > And if it's not, you should still be able to write some rules that solve > your problem. I guess I'm not seeing why you think this is such a problem. It's more work. But, in retrospect I could have solved the problem with the time I spent answering email. :) > > See my comment. Since we have the ability to close the loophole, my > > concern is to minimize support headaches now. Make the default behavior > > less likely to bit the casual user, and make them shoot themselves in > > the foot by enabling it so they don't ask me questions. :) > > I think we agree, but you are "solving" the problem by breaking the tool. We aren't breaking anything. The tool simply blocks packets based on what you want it to do. If you want it to block *all* packets, then tell it to. I don't want it to do anything unless I tell it to. That's the purpose of the tool. > > It's not punching any hole in the code. *ALL* of the firewall products > > I've used (not extensive by any means) are open by default and require > > the user to explicitly close them. If a user mis-configures the > > firewall it's their problem in all of the other products, why is it now > > FreeBSD's problem to make the users 'smarter'? > > I've never seen a firewall product that is open by default. That is an > oxymoron. A firewall is *always* open by default. You determine what it is to firewall against. All of them haven't told me how to make policy, or force me to 'revert' behavior. Firewalls don't make policy, they enforce policy. Nate From owner-freebsd-current Mon Feb 26 14:41:08 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA23596 for current-outgoing; Mon, 26 Feb 1996 14:41:08 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA23579 Mon, 26 Feb 1996 14:41:04 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id OAA02654 ; Mon, 26 Feb 1996 14:41:01 -0800 Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id OAA14871; Mon, 26 Feb 1996 14:38:22 -0800 From: "Rodney W. Grimes" Message-Id: <199602262238.OAA14871@GndRsh.aac.dev.com> Subject: Re: IPFW (was: Re: -stable hangs at boot) To: nate@sri.MT.net (Nate Williams) Date: Mon, 26 Feb 1996 14:38:22 -0800 (PST) Cc: phk@critter.tfs.com, stable@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: <199602261926.MAA00360@rocky.sri.MT.net> from "Nate Williams" at Feb 26, 96 12:26:22 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG Precedence: bulk ... > > Nate: 3) The code -stable is un-documented and incomplete w/regard to > > Nate: -current. The documentation in -stable hasn't been updated yet. Here > > Nate: is the last entry for the ipfw.8 man-page. > > > > Reality has overtaken you again. A couple of hours ago I committed a almost > > complete synopsis and description to the man page. > > Glad to hear it, but it happened after I sup'd the CVS tree. It also > appears that you need to add the patch you just made to -current into > -stable as well. Don't you just hate having to keep two trees in sync > sometimes? (Though the advantages outweigh the disadvantages). That is why I raised the little protest the other day, this should have all been done in -current, stabalized, tested, hashed out, etc, then and ONLY then should have it been brought over to -stable. As it stands now I have ``Frozen'' my stable sources until this work is done, which means I can not take advantage of several other nice fixes that just recently went in to -stable :-( :-(. Work should really be done in one branch only until it is _complete_. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Mon Feb 26 15:57:33 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA28392 for current-outgoing; Mon, 26 Feb 1996 15:57:33 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA28385 Mon, 26 Feb 1996 15:57:27 -0800 (PST) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id PAA15114; Mon, 26 Feb 1996 15:55:33 -0800 From: "Rodney W. Grimes" Message-Id: <199602262355.PAA15114@GndRsh.aac.dev.com> Subject: Re: -stable hangs at boot (fwd) To: nate@sri.MT.net (Nate Williams) Date: Mon, 26 Feb 1996 15:55:33 -0800 (PST) Cc: jgreco@brasil.moneng.mei.com, nate@sri.MT.net, phk@critter.tfs.com, stable@freebsd.org, current@freebsd.org In-Reply-To: <199602262204.PAA01109@rocky.sri.MT.net> from "Nate Williams" at Feb 26, 96 03:04:06 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk .... > > > It's not punching any hole in the code. *ALL* of the firewall products > > > I've used (not extensive by any means) are open by default and require > > > the user to explicitly close them. If a user mis-configures the > > > firewall it's their problem in all of the other products, why is it now > > > FreeBSD's problem to make the users 'smarter'? > > > > I've never seen a firewall product that is open by default. That is an > > oxymoron. > > A firewall is *always* open by default. You determine what it is to > firewall against. All of them haven't told me how to make policy, or > force me to 'revert' behavior. Firewalls don't make policy, they > enforce policy. It is not a firewall if it is always open, it is just a plain old router :-) And per the RFC's FreeBSD can not, and does not, ship with even IP forwarding turned on. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Mon Feb 26 15:58:03 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA28477 for current-outgoing; Mon, 26 Feb 1996 15:58:03 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA28453 Mon, 26 Feb 1996 15:57:58 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id RAA01738; Mon, 26 Feb 1996 17:00:33 -0700 Date: Mon, 26 Feb 1996 17:00:33 -0700 From: Nate Williams Message-Id: <199602270000.RAA01738@rocky.sri.MT.net> To: "Rodney W. Grimes" Cc: nate@sri.MT.net (Nate Williams), stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-Reply-To: <199602262355.PAA15114@GndRsh.aac.dev.com> References: <199602262204.PAA01109@rocky.sri.MT.net> <199602262355.PAA15114@GndRsh.aac.dev.com> Sender: owner-current@freebsd.org Precedence: bulk Rodney W. Grimes writes: > > > > It's not punching any hole in the code. *ALL* of the firewall products > > > > I've used (not extensive by any means) are open by default and require > > > > the user to explicitly close them. If a user mis-configures the > > > > firewall it's their problem in all of the other products, why is it now > > > > FreeBSD's problem to make the users 'smarter'? > > > > > > I've never seen a firewall product that is open by default. That is an > > > oxymoron. > > > > A firewall is *always* open by default. You determine what it is to > > firewall against. All of them haven't told me how to make policy, or > > force me to 'revert' behavior. Firewalls don't make policy, they > > enforce policy. > > It is not a firewall if it is always open, it is just a plain old router :-) It's not a configured firewall if it's wide open. ;) Let me re-phrase. All of the firewall products I've used are configured 'wide-open' by default. Now, if you leave it that way you don't have much of a firewall, but that's a configuration problem. Nate From owner-freebsd-current Mon Feb 26 18:15:22 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA09532 for current-outgoing; Mon, 26 Feb 1996 18:15:22 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id SAA09522 Mon, 26 Feb 1996 18:15:20 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id UAA16377; Mon, 26 Feb 1996 20:14:31 -0600 From: Joe Greco Message-Id: <199602270214.UAA16377@brasil.moneng.mei.com> Subject: Re: -stable hangs at boot (fwd) To: nate@sri.MT.net (Nate Williams) Date: Mon, 26 Feb 1996 20:14:31 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, nate@sri.MT.net, phk@critter.tfs.com, stable@freebsd.org, current@freebsd.org In-Reply-To: <199602262204.PAA01109@rocky.sri.MT.net> from "Nate Williams" at Feb 26, 96 03:04:06 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org Precedence: bulk > It's more work. But, in retrospect I could have solved the problem with > the time I spent answering email. :) Isn't that always the case though :-) > > I think we agree, but you are "solving" the problem by breaking the tool. > > We aren't breaking anything. The tool simply blocks packets based on > what you want it to do. If you want it to block *all* packets, then > tell it to. I don't want it to do anything unless I tell it to. That's > the purpose of the tool. I want the tool to enforce my policies. As a firewall, I interpret the purpose of the tool as being a policy enforcement tool. One of them is that I want to prevent ANY "bad packets" from entering my networks. That policy cannot be enforced by an IPFW implementation that periodically chooses to allow all packets through just because somebody flushed all the rules while reloading them. That policy CAN be enforced by an IPFW implementation that periodically chooses to allow NO packets through. Since the basic purpose of IPFW is to provide a tool to enforce policies, I submit that an implementation that knowingly and by design allows policies to be violated is inherently flawed and dangerous, even if the policy violations are only momentary at best. This is the way you would have the implementation work. The way I would like it implemented, this would not be a problem. > > I've never seen a firewall product that is open by default. That is an > > oxymoron. > > A firewall is *always* open by default. You determine what it is to > firewall against. All of them haven't told me how to make policy, or > force me to 'revert' behavior. Firewalls don't make policy, they > enforce policy. I disagree with that analysis of a firewall, but that is semantics, and irrelevant to this discussion. You can build your house from the ground up and wind up with your dream house. You can start with a prefab house and remodel it and wind up with your dream house. I think we agree that either method yields the desired "dream house". However, my point is that when you start from the ground up, you have to worry about the rain getting in the unfinished house and ruining the structure... you just don't have those sorts of problems when you're just remodeling. :-) THAT is what _I_ am trying to argue! Good night, ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-current Mon Feb 26 18:30:21 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA10779 for current-outgoing; Mon, 26 Feb 1996 18:30:21 -0800 (PST) Received: from moonpie.w8hd.org (moonpie.w8hd.org [198.252.159.14]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id SAA10767 for ; Mon, 26 Feb 1996 18:30:13 -0800 (PST) Received: (from kimc@localhost) by moonpie.w8hd.org (8.7.4/8.6.12) id VAA00234; Mon, 26 Feb 1996 21:29:31 -0500 (EST) Date: Mon, 26 Feb 1996 21:29:30 -0500 (EST) From: Kim Culhan To: freebsd-current@freebsd.org Subject: kernel compile on recent -current Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk This compile failure on -current: cc -c -O -W -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Winline -nostdinc -I. -I../.. -I../../sys -I../../../include -DI386_CPU -DI486_CPU -DI586_CPU -DPROBE_VERBOSE -DXSERVER -DMROUTING -DUCONSOLE -DCOMPAT_43 -DCD9660 -DMSDOSFS -DNFS -DFFS -DINET -DKERNEL ../../netinet/tcp_input.c ../../netinet/tcp_input.c: In function `tcp_input': ../../netinet/tcp_input.c:400: structure has no member named `tcps_listendrop' *** Error code 1 Any help here is greatly appreciated. regards kim -- kimc@w8hd.org From owner-freebsd-current Mon Feb 26 18:36:12 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA11274 for current-outgoing; Mon, 26 Feb 1996 18:36:12 -0800 (PST) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id SAA11269 Mon, 26 Feb 1996 18:36:10 -0800 (PST) Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.8+c/8.6.5) with SMTP id SAA25831; Mon, 26 Feb 1996 18:35:39 -0800 Message-Id: <199602270235.SAA25831@puli.cisco.com> To: julian@freebsd.org, hsu@freebsd.org Cc: hackers@freebsd.org, current@freebsd.org Subject: gratuitous changes to db/hash.c for threadsafe operation? Date: Mon, 26 Feb 1996 18:35:39 -0800 From: Paul Traina Sender: owner-current@freebsd.org Precedence: bulk Does anyone know why the "errno" value in the hash structure was renamed to "error"? This seems to be a gratuitous change that was made to the hash code, and I'd like to reverse it out if no one has a particularly good reason for its existance. You two show up as reviewers of this code, so perhaps you can explain it to me? I've incorporated the latest version of the db code into the csrg branch and would like to bring it into the mainline. I'll preserve these changes if they serve a purpose, but I see none served here after looking at this pretty closely, so my default inclination is to revert the code to match the original author's. Paul From owner-freebsd-current Mon Feb 26 19:24:06 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA15706 for current-outgoing; Mon, 26 Feb 1996 19:24:06 -0800 (PST) Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id TAA15660 Mon, 26 Feb 1996 19:23:59 -0800 (PST) Received: (from julian@localhost) by ref.tfs.com (8.7.3/8.6.9) id TAA14264; Mon, 26 Feb 1996 19:23:30 -0800 (PST) Message-Id: <199602270323.TAA14264@ref.tfs.com> Subject: Re: gratuitous changes to db/hash.c for threadsafe operation? To: pst@cisco.com (Paul Traina) Date: Mon, 26 Feb 1996 19:23:29 -0800 (PST) From: "JULIAN Elischer" Cc: julian@freebsd.org, hsu@freebsd.org, hackers@freebsd.org, current@freebsd.org In-Reply-To: <199602270235.SAA25831@puli.cisco.com> from "Paul Traina" at Feb 26, 96 06:35:39 pm X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk It clashes with the errno in the thread_safe libc which is a MACRO #define errno (*__errno(current_thread)) or something similar this is true in almost every threads package in the world... > > > Does anyone know why the "errno" value in the hash structure was renamed > to "error"? This seems to be a gratuitous change that was made to the > hash code, and I'd like to reverse it out if no one has a particularly > good reason for its existance. > > You two show up as reviewers of this code, so perhaps you can explain > it to me? > > I've incorporated the latest version of the db code into the csrg branch > and would like to bring it into the mainline. I'll preserve these changes > if they serve a purpose, but I see none served here after looking at this > pretty closely, so my default inclination is to revert the code to match > the original author's. > > Paul > From owner-freebsd-current Mon Feb 26 20:02:11 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA19194 for current-outgoing; Mon, 26 Feb 1996 20:02:11 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id UAA19185 Mon, 26 Feb 1996 20:02:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id UAA10130; Mon, 26 Feb 1996 20:00:06 -0800 (PST) To: Joe Greco cc: nate@sri.MT.net (Nate Williams), phk@critter.tfs.com, stable@freebsd.org, current@freebsd.org Followup-To: security@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-reply-to: Your message of "Mon, 26 Feb 1996 15:53:55 CST." <199602262153.PAA16062@brasil.moneng.mei.com> Date: Mon, 26 Feb 1996 20:00:05 -0800 Message-ID: <10128.825393605@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org Precedence: bulk ARGH! Stop, please!! Uh. Most kindly, guys, can you perhaps take this topic to freebsd-security, where it truly and honestly belongs? This may be heretical, but I personally don't CARE about firewalls! There are enough people in the world who do care about them that I don't have to, and I rather like it that way. This thread has virtually taken over both -stable and -current, and I think that 24 messages in this thread is reasonable grounds to call for a closed discussion or, at the minimum, revectoring it to the proper place already! What kind of firewall can I install which will redirect discussions about firewalls from -current to -security, now that's something I'd like to know! :-) Jordan From owner-freebsd-current Mon Feb 26 21:04:14 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA24313 for current-outgoing; Mon, 26 Feb 1996 21:04:14 -0800 (PST) Received: from netrail.net (nathan@netrail.net [205.215.6.3]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id VAA24306 for ; Mon, 26 Feb 1996 21:04:11 -0800 (PST) Received: (from nathan@localhost) by netrail.net (8.7.3/8.6.12) id AAA31982; Tue, 27 Feb 1996 00:03:54 -0500 Date: Tue, 27 Feb 1996 00:03:54 -0500 (EST) From: Nathan Stratton To: current@freebsd.org Subject: IPv6 In-Reply-To: <11931.825357016@critter.tfs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk Does/will FreeBSD work with IPv6? Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite 5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- "Therefore do not worry about tomorrow, for tomorrow will worry about itself" Matthew 6:34 From owner-freebsd-current Mon Feb 26 21:53:00 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA29472 for current-outgoing; Mon, 26 Feb 1996 21:53:00 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA29455 for ; Mon, 26 Feb 1996 21:52:50 -0800 (PST) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id VAA15448; Mon, 26 Feb 1996 21:52:40 -0800 From: "Rodney W. Grimes" Message-Id: <199602270552.VAA15448@GndRsh.aac.dev.com> Subject: Re: IPv6 To: nathan@netrail.net (Nathan Stratton) Date: Mon, 26 Feb 1996 21:52:39 -0800 (PST) Cc: current@freebsd.org In-Reply-To: from "Nathan Stratton" at Feb 27, 96 00:03:54 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk > > > Does/will FreeBSD work with IPv6? It will, when is the real question. It takes a kernel hacker about 4 hours to intergrate the current NetBSD IPv6 stuff, or at least that is what it took me last time I did it just to see what had been completed and how hard it would be to bring in once it was a completed work. Any one else out there working on IPV6 under FreeBSD? -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Mon Feb 26 22:20:35 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA01257 for current-outgoing; Mon, 26 Feb 1996 22:20:35 -0800 (PST) Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id WAA01250 for ; Mon, 26 Feb 1996 22:20:33 -0800 (PST) Received: (from julian@localhost) by ref.tfs.com (8.7.3/8.6.9) id WAA14556; Mon, 26 Feb 1996 22:20:07 -0800 (PST) Message-Id: <199602270620.WAA14556@ref.tfs.com> Subject: Re: IPv6 To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Date: Mon, 26 Feb 1996 22:20:06 -0800 (PST) From: "JULIAN Elischer" Cc: nathan@netrail.net, current@freebsd.org In-Reply-To: <199602270552.VAA15448@GndRsh.aac.dev.com> from "Rodney W. Grimes" at Feb 26, 96 09:52:39 pm X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk > > > > > > > Does/will FreeBSD work with IPv6? > > It will, when is the real question. > > It takes a kernel hacker about 4 hours to intergrate the current NetBSD > IPv6 stuff, or at least that is what it took me last time I did it just > to see what had been completed and how hard it would be to bring in once > it was a completed work. Inria are now releasing the code in both NetBSD and FreeBSD forms.. ( 0 hour integration.. but I don't know for which version FreeBSD :) > > Any one else out there working on IPV6 under FreeBSD? > > -- > Rod Grimes rgrimes@gndrsh.aac.dev.com > Accurate Automation Company Reliable computers for FreeBSD > From owner-freebsd-current Mon Feb 26 22:23:16 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA01473 for current-outgoing; Mon, 26 Feb 1996 22:23:16 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id WAA01370 Mon, 26 Feb 1996 22:22:14 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id RAA14236; Tue, 27 Feb 1996 17:17:44 +1100 Date: Tue, 27 Feb 1996 17:17:44 +1100 From: Bruce Evans Message-Id: <199602270617.RAA14236@godzilla.zeta.org.au> To: julian@ref.tfs.com, pst@cisco.com Subject: Re: gratuitous changes to db/hash.c for threadsafe operation? Cc: current@FreeBSD.org, hackers@FreeBSD.org, hsu@FreeBSD.org, julian@FreeBSD.org Sender: owner-current@FreeBSD.org Precedence: bulk >It clashes with the errno in the thread_safe libc >which is a MACRO >#define errno (*__errno(current_thread)) >or something similar >this is true in almost every threads package in the world... ANSI permits errno to be a macro (to allow thngs like the above), so it shouldn't be used in portable code to mean anything other than the ANSI errno. Similarly for almost all ANSI names, e.g., sin. Bruce From owner-freebsd-current Mon Feb 26 22:32:49 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA02317 for current-outgoing; Mon, 26 Feb 1996 22:32:49 -0800 (PST) Received: from metal.ops.neosoft.com (root@metal.ops.neosoft.com [206.109.5.25]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id WAA02311 for ; Mon, 26 Feb 1996 22:32:45 -0800 (PST) Received: (from smace@localhost) by metal.ops.neosoft.com (8.7.3/8.6.10) id AAA17749; Tue, 27 Feb 1996 00:32:14 -0600 (CST) From: Scott Mace Message-Id: <199602270632.AAA17749@metal.ops.neosoft.com> Subject: Re: IPv6 To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Date: Tue, 27 Feb 1996 00:32:13 -0600 (CST) Cc: nathan@netrail.net, current@freebsd.org In-Reply-To: <199602270552.VAA15448@GndRsh.aac.dev.com> from "Rodney W. Grimes" at Feb 26, 96 09:52:39 pm X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-current@freebsd.org Precedence: bulk > > > > > > > Does/will FreeBSD work with IPv6? > > It will, when is the real question. > > It takes a kernel hacker about 4 hours to intergrate the current NetBSD > IPv6 stuff, or at least that is what it took me last time I did it just > to see what had been completed and how hard it would be to bring in once > it was a completed work. > > Any one else out there working on IPV6 under FreeBSD? > I have had an urge to mess with IPv6 under FreeBSD, but as of yet, it really doesn't solve any real problems :-). Scott From owner-freebsd-current Tue Feb 27 00:02:39 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA12334 for current-outgoing; Tue, 27 Feb 1996 00:02:39 -0800 (PST) Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA12317 for ; Tue, 27 Feb 1996 00:02:28 -0800 (PST) Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id JAA19864 for ; Tue, 27 Feb 1996 09:02:21 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id JAA03474 for current@freebsd.org; Tue, 27 Feb 1996 09:02:20 +0100 Received: (uucp@localhost) by fasterix.frmug.fr.net (8.6.11/fasterix-941011) with UUCP id CAA16783 for current@freebsd.org; Tue, 27 Feb 1996 02:30:25 +0100 Received: (from regnauld@localhost) by tetard.frmug.fr.net (8.7.3/8.7.3/tetard-uucp-2.7) id BAA01687 for current@freebsd.org; Tue, 27 Feb 1996 01:13:03 +0100 (MET) From: Philippe Regnauld Message-Id: <199602270013.BAA01687@tetard.frmug.fr.net> Subject: Strange Memory Fault problem with make world To: current@freebsd.org (current) Date: Tue, 27 Feb 1996 01:13:02 +0100 (MET) X-rene: Tu dois pas les avoir perdues, normalement. X-wing-fighter: et puis X-men, X-open, X-ta-mere... X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org Precedence: bulk Problem is as following: in /usr/src/gnu/usr.bin/perl/x2p, make install generates the following: (root)[perl/x2p]# make install install -c -o bin -g bin -m 555 /usr/src/gnu/usr.bin/perl/x2p/s2p /usr/bin install -c -o bin -g bin -m 555 /usr/src/gnu/usr.bin/perl/x2p/h2ph /usr/bin install -c -s -o bin -g bin -m 555 a2p /usr/bin install -c -o bin -g bin -m 444 a2p.1.gz s2p.1.gz h2ph.1.gz /usr/share/man/man1 (DESTDIR=; cd /usr/include; h2ph * sys/*) Memory fault *** Error code 139 The memory fault is from sh: Feb 27 01:10:06 tetard /kernel: pid 1681 (sh), uid 0: exited on signal 11 Haven't gotten around to tracing it though. Strange thing is: if I type in the command manually, no problem -- when MAKE runs it, it barfs... -- Phil -- - [ regnauld@tetard.frmug.fr.net / +48.8N+2.3E / +33 1 4507 9391 / Sol 3 ] - - [ regnauld@freenix.fr / FreeBSD 2.x / ] - "Le schtroumpf est à l'homme ce que le bleu est au billard" - F.Berjon From owner-freebsd-current Tue Feb 27 00:11:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA13656 for current-outgoing; Tue, 27 Feb 1996 00:11:38 -0800 (PST) Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA13638 for ; Tue, 27 Feb 1996 00:11:31 -0800 (PST) Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id JAA19944 ; Tue, 27 Feb 1996 09:09:40 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id JAA03519 ; Tue, 27 Feb 1996 09:09:39 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.3/keltia-uucp-2.7) id IAA01109; Tue, 27 Feb 1996 08:42:37 +0100 (MET) From: Ollivier Robert Message-Id: <199602270742.IAA01109@keltia.freenix.fr> Subject: Re: IPv6 To: rgrimes@GndRsh.aac.dev.com (Rodney W. Grimes) Date: Tue, 27 Feb 1996 08:42:37 +0100 (MET) Cc: nathan@netrail.net, current@FreeBSD.ORG In-Reply-To: <199602270552.VAA15448@GndRsh.aac.dev.com> from "Rodney W. Grimes" at "Feb 26, 96 09:52:39 pm" X-Operating-System: FreeBSD 2.2-CURRENT ctm#1688 X-Mailer: ELM [version 2.4ME+ PL7 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG Precedence: bulk It seems that Rodney W. Grimes said: > Any one else out there working on IPV6 under FreeBSD? Francis Dupont, the author of the NetBSD stuff, is working on integrating in FreeBSD. I haven't looked at the NRL one yet. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #1: Tue Feb 20 01:16:51 MET 1996 From owner-freebsd-current Tue Feb 27 04:11:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA12615 for current-outgoing; Tue, 27 Feb 1996 04:11:38 -0800 (PST) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA12588 for ; Tue, 27 Feb 1996 04:11:33 -0800 (PST) Received: from myrtilos.cs.utwente.nl by utrhcs.cs.utwente.nl (SMI-8.6/csrelay-SVR4_1.3/RBCS) id NAA13050; Tue, 27 Feb 1996 13:11:30 +0100 Received: from curie.cs.utwente.nl by myrtilos.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id NAA10293; Tue, 27 Feb 1996 13:11:27 +0100 Received: from localhost by curie.cs.utwente.nl (SMI-8.6/SMI-SVR4) id NAA07670; Tue, 27 Feb 1996 13:11:26 +0100 To: current@freebsd.org Subject: Re: IPv6 In-reply-to: <199602270742.IAA01109@keltia.freenix.fr> Date: Tue, 27 Feb 1996 13:11:25 +0100 Message-ID: <7669.825423085@curie.cs.utwente.nl> From: Andras Olah Sender: owner-current@freebsd.org Precedence: bulk On Tue, 27 Feb 1996 08:42:37 +0100, Ollivier Robert wrote: > It seems that Rodney W. Grimes said: > > Any one else out there working on IPV6 under FreeBSD? > > Francis Dupont, the author of the NetBSD stuff, is working on integrating > in FreeBSD. I haven't looked at the NRL one yet. I took a quick look at the IPng home page at http://playground.sun.com/pub/ipng/html/ipng-implementations.html According to the info there Ipsilon is working on a FreeBSD-based IPv6 router implementation. The ftp site of Inria already has a release of their IPv6 host code for FreeBSD 2.1R (explicitly stated in the readme). Andras From owner-freebsd-current Tue Feb 27 05:02:06 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA16880 for current-outgoing; Tue, 27 Feb 1996 05:02:06 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA16875 Tue, 27 Feb 1996 05:02:04 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0trP1J-0003wXC; Tue, 27 Feb 96 05:00 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id OAA13804; Tue, 27 Feb 1996 14:00:40 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: "Rodney W. Grimes" cc: nate@sri.MT.net (Nate Williams), jgreco@brasil.moneng.mei.com, stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-reply-to: Your message of "Mon, 26 Feb 1996 15:55:33 PST." <199602262355.PAA15114@GndRsh.aac.dev.com> Date: Tue, 27 Feb 1996 14:00:40 +0100 Message-ID: <13802.825426040@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org Precedence: bulk > > > > It's not punching any hole in the code. *ALL* of the firewall products > > > > I've used (not extensive by any means) are open by default and require > > > > the user to explicitly close them. If a user mis-configures the > > > > firewall it's their problem in all of the other products, why is it now > > > > FreeBSD's problem to make the users 'smarter'? > > > > > > I've never seen a firewall product that is open by default. That is an > > > oxymoron. > > > > A firewall is *always* open by default. You determine what it is to > > firewall against. All of them haven't told me how to make policy, or > > force me to 'revert' behavior. Firewalls don't make policy, they > > enforce policy. > > It is not a firewall if it is always open, it is just a plain old router :-) > And per the RFC's FreeBSD can not, and does not, ship with even IP forwarding > turned on. Amen. By doing it so the default is "deny all", we solve a couple of nasty corner cases: 1. You can "ipfw flush" and then add your rules, without leaving the door open in the meantime. 2. If you get your rules wrong you wont by accident leave some crap through. 3. It is clearly visible for the user what will happen if nothing is explicitly defined before. 4. Statistics are gathered on this policy rule, just like for the rest of the rules, so you can see if they do what you want. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Tue Feb 27 05:29:39 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA17849 for current-outgoing; Tue, 27 Feb 1996 05:29:39 -0800 (PST) Received: from moonpie.w8hd.org (moonpie.w8hd.org [198.252.159.14]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id FAA17844 for ; Tue, 27 Feb 1996 05:29:37 -0800 (PST) Received: (from kimc@localhost) by moonpie.w8hd.org (8.7.4/8.6.12) id IAA01327; Tue, 27 Feb 1996 08:29:21 -0500 (EST) Date: Tue, 27 Feb 1996 08:29:21 -0500 (EST) From: Kim Culhan To: current@freebsd.org Subject: current build fails Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk Current fails as follows from sup of ~0100 UTC this date: cc -O -I/sys -c /usr/src/usr.bin/netstat/inet.c /usr/src/usr.bin/netstat/inet.c: In function `tcp_stats': /usr/src/usr.bin/netstat/inet.c:221: structure has no member named `tcps_listendrop' /usr/src/usr.bin/netstat/inet.c:221: structure has no member named `tcps_listendrop' /usr/src/usr.bin/netstat/inet.c:221: structure has no member named `tcps_listendrop' *** Error code 1 regards kim -- kimc@w8hd.org From owner-freebsd-current Tue Feb 27 07:06:47 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA24487 for current-outgoing; Tue, 27 Feb 1996 07:06:47 -0800 (PST) Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA24459 for ; Tue, 27 Feb 1996 07:06:36 -0800 (PST) Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD4.4) id CAA00676; Wed, 28 Feb 1996 02:05:55 +1100 From: michael butler Message-Id: <199602271505.CAA00676@asstdc.scgt.oz.au> Subject: Re: Opti 82C895 cache coherency ? To: terry@lambert.org (Terry Lambert) Date: Wed, 28 Feb 1996 02:05:55 +1100 (EST) Cc: current@FreeBSD.ORG In-Reply-To: <199602262055.NAA02567@phaeton.artisoft.com> from "Terry Lambert" at Feb 26, 96 01:55:57 pm X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG Precedence: bulk Terry Lambert writes: > > I wonder if anyone can vouch for an Opti 82C895/82C602 motherboard with > > an AMD 486DX4/100 in respect of cache coherency. Specifically, in > > combination with an Adaptec 2842 (VLB) controller. Just trying to track > > down a "quirk" with a (sort of working) -stable .. I don't know if it's > > -stable or the motherboard :-( > Does it work with cache disabled? Nope. > If so, I suspect the VLB slot the controller is in is not a master slot. Fortunately, there are three documented (!) in the manual but, of course, I only want one. If I use "master slot 1" it won't boot. If I use either slot labelled "master slot 0", it will but then it won't talk to the ethernet card (WD8013EPC, 0x280, 5, 0xd8000) :-( It simply hangs in (NFS) mounting some shared directories. If, however, I replace the 2842 with a Buslogic 542B (ISA) and reboot with an older version of -stable, it will fly quite happily even if strangled on disk I/O. I am assuming that a cache problem would exhibit some symptoms with this card as well. I'm just about to build a "new" version of -stable with the aha driver in it to see if it exhibits the same symptoms .. michael From owner-freebsd-current Tue Feb 27 09:00:46 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA03466 for current-outgoing; Tue, 27 Feb 1996 09:00:46 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA03461 for ; Tue, 27 Feb 1996 09:00:43 -0800 (PST) Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA00681; Tue, 27 Feb 1996 12:00:40 -0500 Date: Tue, 27 Feb 1996 12:00:40 -0500 From: "Garrett A. Wollman" Message-Id: <9602271700.AA00681@halloran-eldar.lcs.mit.edu> To: Nathan Stratton Cc: current@FreeBSD.org Subject: IPv6 In-Reply-To: References: <11931.825357016@critter.tfs.com> Sender: owner-current@FreeBSD.org Precedence: bulk < said: > Does/will FreeBSD work with IPv6? Does it work /with/ IPv6? Certainly. You can send IPv6 packets past it on a network, and it will happily ignore them. Does it include an IPv6 implementation? No. At present, there are at least three different IPv6 implementations, and at least one IPv6 stack that also includes IPSEC for v4. Because the situation is in so much flux at the moment, and I'm not at all happy with the stability or the substance of the code that /I've/ looked at, I do not plan on including IPv6 in the near future. Sometime later on this year, I will be re-evaluating the situation, and hopefully will have more to say on the subject at that time. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Tue Feb 27 09:18:40 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA04676 for current-outgoing; Tue, 27 Feb 1996 09:18:40 -0800 (PST) Received: from ham.mics.msu.su (ham.mics.msu.su [158.250.28.66]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA04666 Tue, 27 Feb 1996 09:18:29 -0800 (PST) Received: from mics.msu.su (mics.msu.su [158.250.28.65]) by ham.mics.msu.su (8.6.4/8.6.4) with ESMTP id UAA24693; Tue, 27 Feb 1996 20:18:13 +0300 Received: from MICS/SpoolDir by mics.msu.su (Mercury 1.21); 27 Feb 96 20:18:19 +0300 Received: from SpoolDir by MICS (Mercury 1.21); 27 Feb 96 20:17:05 +0300 From: "Mad Phantom" Organization: Microelectronics Center To: hackers@freebsd.org, current@freebsd.org Date: Tue, 27 Feb 1996 20:17:03 GMT+3 Subject: FIFO question X-Confirm-Reading-To: "Mad Phantom" X-pmrqc: 1 Priority: normal X-mailer: Pegasus Mail v3.22 Message-ID: <1DF27873BE4@mics.msu.su> Sender: owner-current@freebsd.org Precedence: bulk Hi there, I have problems with config. my fifo io card (startech 16650A). If I type "cat /dev/cuaa1" (on other cu* cat write "operation not permitted"..or something like it) and calling modem, I see only trash on screen. "cat /dev/ttyd1" looks like big hole - nothing write back. Does anyone know how can I config my FIFO? Max. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Drogajtcev Maxim Valerievich | System Administrator. Fax: 7 (095) 932 8997 | System Developer. Voice: 7 (095) 939 2307 | Moscow State University, Russia. e-mail: max@mics.msu.su | Microelectronic Center. UUDECODE, MIME, PGP and etc. | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From owner-freebsd-current Tue Feb 27 09:51:16 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA07239 for current-outgoing; Tue, 27 Feb 1996 09:51:16 -0800 (PST) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA07230 Tue, 27 Feb 1996 09:51:13 -0800 (PST) Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.8+c/8.6.5) with SMTP id JAA10649; Tue, 27 Feb 1996 09:50:05 -0800 Message-Id: <199602271750.JAA10649@puli.cisco.com> To: "JULIAN Elischer" Cc: julian@freebsd.org, hsu@freebsd.org, hackers@freebsd.org, current@freebsd.org Subject: Re: gratuitous changes to db/hash.c for threadsafe operation? In-Reply-To: Your message of "Mon, 26 Feb 1996 19:23:29 PST." <199602270323.TAA14264@ref.tfs.com> Date: Tue, 27 Feb 1996 09:50:05 -0800 From: Paul Traina Sender: owner-current@freebsd.org Precedence: bulk Damn, yuck. OK, thanks. From: "JULIAN Elischer" Subject: Re: gratuitous changes to db/hash.c for threadsafe operation? It clashes with the errno in the thread_safe libc which is a MACRO #define errno (*__errno(current_thread)) or something similar this is true in almost every threads package in the world... > > > Does anyone know why the "errno" value in the hash structure was renamed > to "error"? This seems to be a gratuitous change that was made to the > hash code, and I'd like to reverse it out if no one has a particularly > good reason for its existance. > > You two show up as reviewers of this code, so perhaps you can explain > it to me? > > I've incorporated the latest version of the db code into the csrg branch > and would like to bring it into the mainline. I'll preserve these changes > if they serve a purpose, but I see none served here after looking at this > pretty closely, so my default inclination is to revert the code to match > the original author's. > > Paul > From owner-freebsd-current Tue Feb 27 10:09:52 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA09002 for current-outgoing; Tue, 27 Feb 1996 10:09:52 -0800 (PST) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA08994 for ; Tue, 27 Feb 1996 10:09:50 -0800 (PST) Received: from localhost.shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.4/8.7.3) with SMTP id KAA00459; Tue, 27 Feb 1996 10:06:00 -0800 (PST) Message-Id: <199602271806.KAA00459@precipice.shockwave.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Andreas Klemm cc: dbaker@cocoa.ops.neosoft.com (Daniel Baker), current@freebsd.org Subject: Re: -current breaks shell and tset In-reply-to: Your message of "Mon, 26 Feb 1996 22:11:05 +0100." <199602262111.WAA02249@knobel.gun.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Feb 1996 10:05:59 -0800 From: Paul Traina Sender: owner-current@freebsd.org Precedence: bulk > BTW: Who was the lucky one who didn't test the hash.c > modification ?! ;-)) I was the one who did the mod, but I didn't do a make world after making the mod, rather I just tested a bunch of things that did dbm accesses, which all worked just fine. The problem is that cap_mkdb is a broken evil bit of code, but I'll still take the blame on this one. From owner-freebsd-current Tue Feb 27 11:48:59 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA17950 for current-outgoing; Tue, 27 Feb 1996 11:48:59 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA17935 for ; Tue, 27 Feb 1996 11:48:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id LAA13457 for ; Tue, 27 Feb 1996 11:48:30 -0800 (PST) To: current@freebsd.org Subject: 2.2-960226-SNAP now on ftp.freebsd.org Date: Tue, 27 Feb 1996 11:48:27 -0800 Message-ID: <13453.825450507@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org Precedence: bulk I've just popped a new 2.2-CURRENT snapshot up on the FTP site: ftp://ftp.freebsd.org/pub/FreeBSD/2.2-960226-SNAP/ All the basics seem to work in this release, though I had to disable all the ethernet cards I wasn't using before my test system would come up (it hung in the ep0 driver probe). It also seems to work without the DES distribution, so that problem (from the last snap) would appear to be gone. I'm still not happy enough with this snapshot to put on CD, there being a number of fixes I still need to merge into the installation code (and since I make these snaps so that you can be MY guinea pigs, I reserve the right to decide which snaps are better than others :-). I'll probably roll another one as early as next week, so if you're in no particular hurry you might just want to wait. Otherwise, come and get it! Jordan From owner-freebsd-current Tue Feb 27 12:05:14 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA19761 for current-outgoing; Tue, 27 Feb 1996 12:05:14 -0800 (PST) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA19750 for ; Tue, 27 Feb 1996 12:05:12 -0800 (PST) Received: from localhost.shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.4/8.7.3) with SMTP id MAA04071; Tue, 27 Feb 1996 12:02:45 -0800 (PST) Message-Id: <199602272002.MAA04071@precipice.shockwave.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Ollivier Robert cc: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes), nathan@netrail.net, current@FreeBSD.ORG Subject: Re: IPv6 In-reply-to: Your message of "Tue, 27 Feb 1996 08:42:37 +0100." <199602270742.IAA01109@keltia.freenix.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Feb 1996 12:02:44 -0800 From: Paul Traina Sender: owner-current@FreeBSD.ORG Precedence: bulk I've heard very good thinks about the NRL implementation (over Mr. Dupont's), and I believe that Garrett has the current code). Please, this is all third- hand, I intend no criticism towards Mr. Dupont's code, I'm just relaying additional info. I think that someone should do an evaluation of "which is better" before taking the first one. (Actually, I guess the criteria should be, which is the one the other BSD's are taking. BSDI appears to be going with NRL, and I'm not sure about NetBSD's). From owner-freebsd-current Tue Feb 27 13:06:29 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA03354 for current-outgoing; Tue, 27 Feb 1996 13:06:29 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA03349 for ; Tue, 27 Feb 1996 13:06:27 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA05791; Tue, 27 Feb 1996 13:59:01 -0700 From: Terry Lambert Message-Id: <199602272059.NAA05791@phaeton.artisoft.com> Subject: Re: Opti 82C895 cache coherency ? To: imb@scgt.oz.au (michael butler) Date: Tue, 27 Feb 1996 13:59:01 -0700 (MST) Cc: terry@lambert.org, current@FreeBSD.ORG In-Reply-To: <199602271505.CAA00676@asstdc.scgt.oz.au> from "michael butler" at Feb 28, 96 02:05:55 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG Precedence: bulk > > Does it work with cache disabled? > > Nope. L1 an L2 both disabled? Peculiar... > > If so, I suspect the VLB slot the controller is in is not a master slot. > > Fortunately, there are three documented (!) in the manual but, of course, I > only want one. If I use "master slot 1" it won't boot. If I use either slot > labelled "master slot 0", it will but then it won't talk to the ethernet > card (WD8013EPC, 0x280, 5, 0xd8000) :-( It simply hangs in (NFS) mounting > some shared directories. Clearly, you only have one master slot. The ethernet card needs to be relocated. Try jumpering additional wait states and see if it is a DRAM refresh problem. > If, however, I replace the 2842 with a Buslogic 542B (ISA) and reboot with > an older version of -stable, it will fly quite happily even if strangled on > disk I/O. I am assuming that a cache problem would exhibit some symptoms > with this card as well. No. The problem is specific to the cache notification pin of the VLB. ISA will work correctly. Even on the old Gateway/Dell 60MHz Pentium (with math bug) and the old Saturn I chipset worked correctly with ISA (the Saturn I differs from the Saturn II in that the PCI DMA notification was left disconnected in the I -- that's why you have to turn of the cache in those machines when using bus mastering DMA PCI cards). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Feb 27 13:07:39 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA03546 for current-outgoing; Tue, 27 Feb 1996 13:07:39 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA03501 for ; Tue, 27 Feb 1996 13:07:33 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA05805; Tue, 27 Feb 1996 14:00:16 -0700 From: Terry Lambert Message-Id: <199602272100.OAA05805@phaeton.artisoft.com> Subject: Re: IPv6 To: wollman@lcs.mit.edu (Garrett A. Wollman) Date: Tue, 27 Feb 1996 14:00:16 -0700 (MST) Cc: nathan@netrail.net, current@FreeBSD.ORG In-Reply-To: <9602271700.AA00681@halloran-eldar.lcs.mit.edu> from "Garrett A. Wollman" at Feb 27, 96 12:00:40 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG Precedence: bulk > Does it include an IPv6 implementation? No. At present, there are at > least three different IPv6 implementations, and at least one IPv6 > stack that also includes IPSEC for v4. Which one is this? It seems to be the one people would want to play with. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Feb 27 14:39:31 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA14228 for current-outgoing; Tue, 27 Feb 1996 14:39:31 -0800 (PST) Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id OAA14134 for ; Tue, 27 Feb 1996 14:39:01 -0800 (PST) Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id XAA09703 ; Tue, 27 Feb 1996 23:38:30 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id XAA07488 ; Tue, 27 Feb 1996 23:38:30 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.3/keltia-uucp-2.7) id XAA00739; Tue, 27 Feb 1996 23:07:23 +0100 (MET) From: Ollivier Robert Message-Id: <199602272207.XAA00739@keltia.freenix.fr> Subject: Re: IPv6 To: pst@shockwave.com (Paul Traina) Date: Tue, 27 Feb 1996 23:07:23 +0100 (MET) Cc: rgrimes@gndrsh.aac.dev.com, nathan@netrail.net, current@FreeBSD.ORG In-Reply-To: <199602272002.MAA04071@precipice.shockwave.com> from Paul Traina at "Feb 27, 96 12:02:44 pm" X-Operating-System: FreeBSD 2.2-CURRENT ctm#1688 X-Mailer: ELM [version 2.4ME+ PL7 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG Precedence: bulk It seems that Paul Traina said: > I've heard very good thinks about the NRL implementation (over Mr. Dupont's), > and I believe that Garrett has the current code). Please, this is all third- > hand, I intend no criticism towards Mr. Dupont's code, I'm just relaying > additional info. One of the big problems with Francis' code is that it does not include any cryptographic material, due to the stupidity of the french laws (we're more restrictive than the USA and that speaks a lot...). > I think that someone should do an evaluation of "which is better" before > taking the first one. (Actually, I guess the criteria should be, which > is the one the other BSD's are taking. BSDI appears to be going with > NRL, and I'm not sure about NetBSD's). NRL has been done on pure 4.4BSD I think whereas Francis' code runs on both NetBSD and FreeBSD 2.1.0. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #1: Tue Feb 20 01:16:51 MET 1996 From owner-freebsd-current Tue Feb 27 17:54:11 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA03874 for current-outgoing; Tue, 27 Feb 1996 17:54:11 -0800 (PST) Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id RAA03865 for ; Tue, 27 Feb 1996 17:54:05 -0800 (PST) Received: (from julian@localhost) by ref.tfs.com (8.7.3/8.6.9) id RAA16512; Tue, 27 Feb 1996 17:53:03 -0800 (PST) Message-Id: <199602280153.RAA16512@ref.tfs.com> Subject: Re: IPv6 To: roberto@keltia.freenix.fr (Ollivier Robert) Date: Tue, 27 Feb 1996 17:53:03 -0800 (PST) From: "JULIAN Elischer" Cc: pst@Shockwave.COM, rgrimes@gndrsh.aac.dev.com, nathan@netrail.net, current@FreeBSD.ORG In-Reply-To: <199602272207.XAA00739@keltia.freenix.fr> from "Ollivier Robert" at Feb 27, 96 11:07:23 pm X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG Precedence: bulk > > One of the big problems with Francis' code is that it does not include any > cryptographic material, due to the stupidity of the french laws (we're more > restrictive than the USA and that speaks a lot...). That doesn't say how difficult it would be to plug in such a mudule however. > > > I think that someone should do an evaluation of "which is better" before > > taking the first one. (Actually, I guess the criteria should be, which > > is the one the other BSD's are taking. BSDI appears to be going with > > NRL, and I'm not sure about NetBSD's). There are 4 implimentations for BSDI if you include the WIDE project from japan. > > NRL has been done on pure 4.4BSD I think whereas Francis' code runs on both > NetBSD and FreeBSD 2.1.0. If they have done the right thing, and discussed things, then I hope the best ideas from each implimentation wil be taken from port to port. Francis' code is being used for the AIX implimentation.. I think it's early days to start saying which is better.. Matt, how did the IPv6 bakeoff go? I'm betting that the Digital Unix version of IPv6 is going to be kept under wraps... julian From owner-freebsd-current Tue Feb 27 21:21:13 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA12749 for current-outgoing; Tue, 27 Feb 1996 21:21:13 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA12744 for ; Tue, 27 Feb 1996 21:21:12 -0800 (PST) Received: from greatdane.cisco.com (greatdane.cisco.com [171.69.1.141]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id VAA22050 for ; Tue, 27 Feb 1996 21:21:11 -0800 Received: from cisco.com (localhost.cisco.com [127.0.0.1]) by greatdane.cisco.com (8.6.8+c/8.6.5) with ESMTP id VAA02320; Tue, 27 Feb 1996 21:16:49 -0800 Message-Id: <199602280516.VAA02320@greatdane.cisco.com> To: jkh@time.cdrom.com ("Jordan K. Hubbard") Cc: current@freebsd.org, bcole@cisco.com Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org - 3c509 problem In-Reply-To: Your message of "Tue, 27 Feb 1996 21:09:51 PST." <199602280509.VAA11819@bcole-ss20.cisco.com> Date: Tue, 27 Feb 1996 21:16:49 -0800 From: Bruce Cole Sender: owner-current@freebsd.org Precedence: bulk First problem: My 3c509 card did not come up in UTP mode as it should have. It interrupted with: 1 3C5x9 board(s) on ISA found at 0x300 ep0 at 0x300-0x30f irq 10 on isa ep0: irq 10 ep0: aui/utp[*UTP*] address 00:60:8c:b8:77:84 but then went on to report: ep0: strange connector type in EEPROM: assuming AUI and failed to pass traffic over its UTP connection. I fixed this with: *** if_ep.c.orig Sun Feb 25 17:05:34 1996 --- if_ep.c Tue Feb 27 21:08:29 1996 *************** *** 655,661 **** GO_WINDOW(1); } else { GO_WINDOW(1); ! switch(sc->ep_connector) { case ACF_CONNECTOR_UTP: if(sc->ep_connectors & UTP) { GO_WINDOW(4); --- 655,661 ---- GO_WINDOW(1); } else { GO_WINDOW(1); ! switch(sc->ep_connector >> ACF_CONNECTOR_BITS) { case ACF_CONNECTOR_UTP: if(sc->ep_connectors & UTP) { GO_WINDOW(4); From owner-freebsd-current Tue Feb 27 22:05:46 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA13205 for current-outgoing; Tue, 27 Feb 1996 22:05:46 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id WAA13200 for ; Tue, 27 Feb 1996 22:05:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id WAA00499; Tue, 27 Feb 1996 22:03:09 -0800 (PST) To: Bruce Cole cc: current@freebsd.org Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org - 3c509 problem In-reply-to: Your message of "Tue, 27 Feb 1996 21:16:49 PST." <199602280516.VAA02320@greatdane.cisco.com> Date: Tue, 27 Feb 1996 22:03:09 -0800 Message-ID: <497.825487389@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org Precedence: bulk > ep0: strange connector type in EEPROM: assuming AUI > > and failed to pass traffic over its UTP connection. I fixed this with: Hmmm, this one appears to have been fixed in -current on the exact same day that I rolled the snapshot - we probably missed it by mere hours! :-) Aw well, it'll be in the next snapshot - sorry about that! Luck of the draw. Jordan From owner-freebsd-current Tue Feb 27 23:35:56 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA19073 for current-outgoing; Tue, 27 Feb 1996 23:35:56 -0800 (PST) Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id XAA19067 for ; Tue, 27 Feb 1996 23:35:50 -0800 (PST) Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id IAA12982 ; Wed, 28 Feb 1996 08:35:28 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id IAA09166 ; Wed, 28 Feb 1996 08:35:27 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.3/keltia-uucp-2.7) id IAA02709; Wed, 28 Feb 1996 08:01:41 +0100 (MET) From: Ollivier Robert Message-Id: <199602280701.IAA02709@keltia.freenix.fr> Subject: Re: IPv6 To: terry@lambert.org (Terry Lambert) Date: Wed, 28 Feb 1996 08:01:41 +0100 (MET) Cc: wollman@lcs.mit.edu, nathan@netrail.net, current@freebsd.org In-Reply-To: <199602272100.OAA05805@phaeton.artisoft.com> from Terry Lambert at "Feb 27, 96 02:00:16 pm" X-Operating-System: FreeBSD 2.2-CURRENT ctm#1688 X-Mailer: ELM [version 2.4ME+ PL10 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk It seems that Terry Lambert said: > > least three different IPv6 implementations, and at least one IPv6 > > stack that also includes IPSEC for v4. > > Which one is this? It seems to be the one people would want to play with. Probably the NRL one which is supposed to be complete in this respect. It "mysteriously appeared" (FTP maintainer dixit) on hacktik.nl... It is called "IPv6-Domestic". -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #1: Tue Feb 20 01:16:51 MET 1996 From owner-freebsd-current Tue Feb 27 23:43:43 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA19539 for current-outgoing; Tue, 27 Feb 1996 23:43:43 -0800 (PST) Received: from greatdane.cisco.com (greatdane.cisco.com [171.69.1.141]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA19534 for ; Tue, 27 Feb 1996 23:43:39 -0800 (PST) Received: from cisco.com (localhost.cisco.com [127.0.0.1]) by greatdane.cisco.com (8.6.8+c/8.6.5) with ESMTP id XAA04948; Tue, 27 Feb 1996 23:42:36 -0800 Message-Id: <199602280742.XAA04948@greatdane.cisco.com> To: "Jordan K. Hubbard" Cc: Bruce Cole , current@freebsd.org Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org - 3c509 problem In-Reply-To: Your message of "Tue, 27 Feb 1996 22:03:09 PST." <497.825487389@time.cdrom.com> Date: Tue, 27 Feb 1996 23:42:36 -0800 From: Bruce Cole Sender: owner-current@freebsd.org Precedence: bulk > > ep0: strange connector type in EEPROM: assuming AUI > > > > and failed to pass traffic over its UTP connection. I fixed this with: > > Hmmm, this one appears to have been fixed in -current on the exact > same day that I rolled the snapshot - we probably missed it by mere > hours! :-) The copy in: ftp.freebsd.org:pub/FreeBSD/FreeBSD-current/src/sys/i386/isa/if_ep.c doesn't have this fix. Should I be looking elsewhere? From owner-freebsd-current Wed Feb 28 00:46:32 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA23334 for current-outgoing; Wed, 28 Feb 1996 00:46:32 -0800 (PST) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA23328 for ; Wed, 28 Feb 1996 00:46:28 -0800 (PST) Received: from myrtilos.cs.utwente.nl by utrhcs.cs.utwente.nl (SMI-8.6/csrelay-SVR4_1.3/RBCS) id JAA18254; Wed, 28 Feb 1996 09:46:21 +0100 Received: from curie.cs.utwente.nl by myrtilos.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id JAA16117; Wed, 28 Feb 1996 09:46:17 +0100 Received: from localhost by curie.cs.utwente.nl (SMI-8.6/SMI-SVR4) id JAA09415; Wed, 28 Feb 1996 09:46:17 +0100 To: Ollivier Robert cc: current@freebsd.org Subject: Re: IPv6 In-reply-to: Your message of "Wed, 28 Feb 1996 08:01:41 +0100." <199602280701.IAA02709@keltia.freenix.fr> Date: Wed, 28 Feb 1996 09:46:15 +0100 Message-ID: <9414.825497175@curie.cs.utwente.nl> From: Andras Olah Sender: owner-current@freebsd.org Precedence: bulk On Wed, 28 Feb 1996 08:01:41 +0100, Ollivier Robert wrote: > It seems that Terry Lambert said: > > > least three different IPv6 implementations, and at least one IPv6 > > > stack that also includes IPSEC for v4. > > > > Which one is this? It seems to be the one people would want to play with. > > Probably the NRL one which is supposed to be complete in this respect. It > "mysteriously appeared" (FTP maintainer dixit) on hacktik.nl... It is > called "IPv6-Domestic". FYI: ftp.ripe.net and ftp.hacktic.nl are listed as the official ftp sites of the NRL implementation on the IPng home page. Thus no mystery, IMHO. Andras From owner-freebsd-current Wed Feb 28 01:50:31 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA27027 for current-outgoing; Wed, 28 Feb 1996 01:50:31 -0800 (PST) Received: from blob.best.net ([204.156.128.88]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA26970 Wed, 28 Feb 1996 01:50:17 -0800 (PST) Received: (root@localhost) by blob.best.net (8.6.12/8.6.5) id BAA02908; Wed, 28 Feb 1996 01:50:16 -0800 Received: from dns2.noc.best.net (dns2.noc.best.net [206.86.0.21]) by dns1.noc.best.net (8.6.12/8.6.5) with ESMTP id QAA07718 for ; Tue, 27 Feb 1996 16:35:32 -0800 Received: from dns1.noc.best.net (dns1.noc.best.net [206.86.8.69]) by dns2.noc.best.net (8.6.12/8.6.5) with ESMTP id QAA00806 for ; Tue, 27 Feb 1996 16:34:46 -0800 Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [192.216.222.4]) by dns1.noc.best.net (8.6.12/8.6.5) with ESMTP id QAA07650 for ; Tue, 27 Feb 1996 16:35:00 -0800 Received: from localhost (daemon@localhost) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA04869 Tue, 27 Feb 1996 09:20:09 -0800 (PST) Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA04692 for hackers-outgoing; Tue, 27 Feb 1996 09:18:43 -0800 (PST) Received: from ham.mics.msu.su (ham.mics.msu.su [158.250.28.66]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA04666 Tue, 27 Feb 1996 09:18:29 -0800 (PST) Received: from mics.msu.su (mics.msu.su [158.250.28.65]) by ham.mics.msu.su (8.6.4/8.6.4) with ESMTP id UAA24693; Tue, 27 Feb 1996 20:18:13 +0300 Received: from MICS/SpoolDir by mics.msu.su (Mercury 1.21); 27 Feb 96 20:18:19 +0300 Received: from SpoolDir by MICS (Mercury 1.21); 27 Feb 96 20:17:05 +0300 From: "Mad Phantom" Organization: Microelectronics Center To: hackers@FreeBSD.ORG, current@FreeBSD.ORG Date: Tue, 27 Feb 1996 20:17:03 GMT+3 Subject: FIFO question X-Confirm-Reading-To: "Mad Phantom" X-pmrqc: 1 Priority: normal X-mailer: Pegasus Mail v3.22 Message-ID: <1DF27873BE4@mics.msu.su> Sender: owner-current@FreeBSD.ORG Precedence: bulk ----- Message body suppressed ----- --QAA07726.825467736/dns1.noc.best.net-- ** NOTICE **: A mailer error at BEST caused this ** message to get messed up. If the body of the message contains only '----- Message body suppressed -----', then we were unable to recover the entire message and you will have to email the person sending you this message asking him or her to resend it. BEST apologizes for the inconvenience. From owner-freebsd-current Wed Feb 28 06:14:20 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA10560 for current-outgoing; Wed, 28 Feb 1996 06:14:20 -0800 (PST) Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA10555 for ; Wed, 28 Feb 1996 06:14:14 -0800 (PST) Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD4.4) id BAA01656; Thu, 29 Feb 1996 01:13:38 +1100 From: michael butler Message-Id: <199602281413.BAA01656@asstdc.scgt.oz.au> Subject: Re: Opti 82C895 cache coherency ? To: terry@lambert.org (Terry Lambert) Date: Thu, 29 Feb 1996 01:13:36 +1100 (EST) Cc: current@freebsd.org In-Reply-To: <199602272059.NAA05791@phaeton.artisoft.com> from "Terry Lambert" at Feb 27, 96 01:59:01 pm X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk Terry Lambert writes: > > > Does it work with cache disabled? > > Nope. > L1 an L2 both disabled? > Peculiar... Yup .. either or both :-( > > Fortunately, there are three documented (!) in the manual but, of > > course, I only want one. If I use "master slot 1" it won't boot. If I > > use either slot labelled "master slot 0", it will but then it won't talk > > to the ethernet card (WD8013EPC, 0x280, 5, 0xd8000) :-( It simply hangs > > in (NFS) mounting some shared directories. > Clearly, you only have one master slot. The ethernet card needs to be > relocated. Sorry ? I don't follow the "ethernet .. relocated", it's ISA and works with the BT542B it doesn't matter which slot it's in. I've moved every card to different slots .. no joy. It appears as if it is transmitting packets but not hearing the responses. I can see the little yellow TX led blink every now and again when it's trying to talk. > Try jumpering additional wait states and see if it is a DRAM refresh > problem. I've tried everything available on the board(s) and BIOS .. it simply will not fly :-( :-(. There are a couple of jumpers for VESA timing (marked 0/1 wait states and <=33MHz/>33MHz), they make no impact on the problem. > > If, however, I replace the 2842 with a Buslogic 542B (ISA) and reboot > > with an older version of -stable, it will fly quite happily even if > > strangled on disk I/O. I am assuming that a cache problem would exhibit > > some symptoms with this card as well. > No. The problem is specific to the cache notification pin of the VLB. ISA > will work correctly. >From the looks of it, it's not a cache problem but some other interaction between the 2842 and the WD8013EPC in this design of this board .. it's going back to the people I got it from :-( Another "bad" board for the (SCSI) FAQ .. michael From owner-freebsd-current Wed Feb 28 08:19:21 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA18796 for current-outgoing; Wed, 28 Feb 1996 08:19:21 -0800 (PST) Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA18784 Wed, 28 Feb 1996 08:19:16 -0800 (PST) Message-Id: <199602281619.IAA18784@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol To: Bruce Cole cc: "Jordan K. Hubbard" , current@freebsd.org Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org - 3c509 problem In-reply-to: Your message of "Tue, 27 Feb 1996 23:42:36 PST." <199602280742.XAA04948@greatdane.cisco.com> Date: Wed, 28 Feb 1996 08:19:15 -0800 From: "Justin T. Gibbs" Sender: owner-current@freebsd.org Precedence: bulk >> > ep0: strange connector type in EEPROM: assuming AUI >> > >> > and failed to pass traffic over its UTP connection. I fixed this with: >> >> Hmmm, this one appears to have been fixed in -current on the exact >> same day that I rolled the snapshot - we probably missed it by mere >> hours! :-) > >The copy in: > ftp.freebsd.org:pub/FreeBSD/FreeBSD-current/src/sys/i386/isa/if_ep.c >doesn't have this fix. Should I be looking elsewhere? Jordan was wrong in thinking that the patch is already in the tree. I'll be committing a similar fix in a moment. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Wed Feb 28 09:30:11 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA24737 for current-outgoing; Wed, 28 Feb 1996 09:30:11 -0800 (PST) Received: from gw2.att.com (gw2.att.com [192.20.239.134]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA24693 for ; Wed, 28 Feb 1996 09:30:01 -0800 (PST) From: ejc@nasvr1.cb.att.com Received: from nasvr1.cb.att.com (naserver1.cb.att.com) by ig1.att.att.com id AA16199; Wed, 28 Feb 96 08:11:05 EST Received: by nasvr1.cb.att.com (5.x/EMS-1.1 Sol2) id AA27012; Wed, 28 Feb 1996 08:13:29 -0500 Cc: dob@nasvr1.cb.att.com Received: from ginger.cb.att.com by nasvr1.cb.att.com (5.x/EMS-1.1 Sol2) id AA27003; Wed, 28 Feb 1996 08:13:24 -0500 Received: by ginger.cb.att.com (5.x/EMS-1.1 Sol2) id AA14142; Wed, 28 Feb 1996 08:16:57 -0500 Date: Wed, 28 Feb 1996 08:16:57 -0500 Message-Id: <9602281316.AA14142@ginger.cb.att.com> To: freebsd-current@freebsd.org Subject: -current submitting policys Original-Cc: dob@nasvr1 X-Sun-Charset: US-ASCII Sender: owner-current@freebsd.org Precedence: bulk Hello I supped -current on 2-27-96, to bring my tree up to date. Building of libc failed in libc/db also libutil died because the Makefile had a '-C' not a '-c'. I have my -current build env chroot'ed so instabilities in -current won't bring down my whole system. This brings up a few questions at least for me. Should the code be buildable and installable on the developers machine with the latest -current before submitting? Should a code diff be inspected by another peer before submitting? Is there a policy about unit testing? What is the policy on submiting changes into the -current tree for alpha and beta testing by the masses? Peace, ejc Disclaimer: I do understand what current is, I have rtfm. Just looking for constructive development ideas. From owner-freebsd-current Wed Feb 28 09:54:53 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA26703 for current-outgoing; Wed, 28 Feb 1996 09:54:53 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA26696 for ; Wed, 28 Feb 1996 09:54:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id JAA02609; Wed, 28 Feb 1996 09:54:41 -0800 (PST) To: Bruce Cole cc: current@freebsd.org Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org - 3c509 problem In-reply-to: Your message of "Tue, 27 Feb 1996 23:42:36 PST." <199602280742.XAA04948@greatdane.cisco.com> Date: Wed, 28 Feb 1996 09:54:41 -0800 Message-ID: <2607.825530081@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org Precedence: bulk > The copy in: > ftp.freebsd.org:pub/FreeBSD/FreeBSD-current/src/sys/i386/isa/if_ep.c > doesn't have this fix. Should I be looking elsewhere? Hmmmm. Maybe the sup to wcarchive has broken down - it's certainly in freefall's /usr/src copy (and my own). I'll look into it! Jordan From owner-freebsd-current Wed Feb 28 10:56:56 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA02067 for current-outgoing; Wed, 28 Feb 1996 10:56:56 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA02056 for ; Wed, 28 Feb 1996 10:56:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id KAA02861; Wed, 28 Feb 1996 10:56:43 -0800 (PST) To: "Justin T. Gibbs" cc: Bruce Cole , current@freebsd.org Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org - 3c509 problem In-reply-to: Your message of "Wed, 28 Feb 1996 08:19:15 PST." <199602281619.IAA18784@freefall.freebsd.org> Date: Wed, 28 Feb 1996 10:56:43 -0800 Message-ID: <2859.825533803@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org Precedence: bulk > Jordan was wrong in thinking that the patch is already in the tree. > I'll be committing a similar fix in a moment. Huh? Are you SURE, Justin? I did check through the code, and on freefall that error is *gone*! Jordan From owner-freebsd-current Wed Feb 28 11:06:26 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA02816 for current-outgoing; Wed, 28 Feb 1996 11:06:26 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA02793 Wed, 28 Feb 1996 11:06:21 -0800 (PST) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16022(2)>; Wed, 28 Feb 1996 11:05:39 PST Received: from localhost ([127.0.0.1]) by crevenia.parc.xerox.com with SMTP id <177480>; Wed, 28 Feb 1996 11:05:30 -0800 X-Mailer: exmh version 1.6.4 10/10/95 To: Nate Williams cc: Poul-Henning Kamp , stable@freebsd.org, current@freebsd.org Subject: Re: IPFW (was: Re: -stable hangs at boot) In-reply-to: Your message of "Mon, 26 Feb 1996 11:26:22 PST." <199602261926.MAA00360@rocky.sri.MT.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Feb 1996 11:05:24 PST From: Bill Fenner Message-Id: <96Feb28.110530pst.177480@crevenia.parc.xerox.com> Sender: owner-current@freebsd.org Precedence: bulk In message <199602261926.MAA00360@rocky.sri.MT.net> Nate wrote: >I'm not sure I could >see the need for filtering differently for incoming vs. outgoing (except >in the case of syn. packets). You can prevent many IP spoofing attacks by disallowing packets with IP source addresses that match your internal network addresses from coming in your external connection (e.g. Xerox does access-list N deny 13.0.0.0 0.255.255.255 any on its incoming interface on the Cisco) >That reminds me. I haven't looked yet, but does the new code also >filter out routing information? The old code didn't (and other firewall >code I have used does). Sorry, this doesn't make much sense to me -- shouldn't "filtering routing information" just be another firewall rule? Seems like policy to me. Bill From owner-freebsd-current Wed Feb 28 11:08:07 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA03011 for current-outgoing; Wed, 28 Feb 1996 11:08:07 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA02881 Wed, 28 Feb 1996 11:07:57 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id MAA08395; Wed, 28 Feb 1996 12:10:42 -0700 Date: Wed, 28 Feb 1996 12:10:42 -0700 From: Nate Williams Message-Id: <199602281910.MAA08395@rocky.sri.MT.net> To: Bill Fenner Cc: Nate Williams , Poul-Henning Kamp , stable@freebsd.org, current@freebsd.org Subject: Re: IPFW (was: Re: -stable hangs at boot) In-Reply-To: <96Feb28.110530pst.177480@crevenia.parc.xerox.com> References: <199602261926.MAA00360@rocky.sri.MT.net> <96Feb28.110530pst.177480@crevenia.parc.xerox.com> Sender: owner-current@freebsd.org Precedence: bulk > >That reminds me. I haven't looked yet, but does the new code also > >filter out routing information? The old code didn't (and other firewall > >code I have used does). > > Sorry, this doesn't make much sense to me -- shouldn't "filtering routing > information" just be another firewall rule? Seems like policy to me. The routing code didn't go through the firewall code in the previous implementation, so there was no way for it to filter out routing information. Nate From owner-freebsd-current Wed Feb 28 11:11:28 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA03281 for current-outgoing; Wed, 28 Feb 1996 11:11:28 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA03235 Wed, 28 Feb 1996 11:10:48 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id MAA08403; Wed, 28 Feb 1996 12:13:34 -0700 Date: Wed, 28 Feb 1996 12:13:34 -0700 From: Nate Williams Message-Id: <199602281913.MAA08403@rocky.sri.MT.net> To: Nate Williams Cc: Bill Fenner , stable@freebsd.org, current@freebsd.org Subject: Re: IPFW (was: Re: -stable hangs at boot) In-Reply-To: <199602281910.MAA08395@rocky.sri.MT.net> References: <199602261926.MAA00360@rocky.sri.MT.net> <96Feb28.110530pst.177480@crevenia.parc.xerox.com> <199602281910.MAA08395@rocky.sri.MT.net> Sender: owner-current@freebsd.org Precedence: bulk Nate Williams writes: > > >That reminds me. I haven't looked yet, but does the new code also > > >filter out routing information? The old code didn't (and other firewall > > >code I have used does). > > > > Sorry, this doesn't make much sense to me -- shouldn't "filtering routing > > information" just be another firewall rule? Seems like policy to me. > > The routing code didn't go through the firewall code in the previous > implementation, so there was no way for it to filter out routing > information. Man, I think I'm going to crawl into a hole today. I can't communicate at all effectively. What that should have said is: Routing packets didn't pass through the firewall code previously, so there was no way to filter it out. Sorry, Nate From owner-freebsd-current Wed Feb 28 11:15:32 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA03637 for current-outgoing; Wed, 28 Feb 1996 11:15:32 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA03616 Wed, 28 Feb 1996 11:15:27 -0800 (PST) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16153(2)>; Wed, 28 Feb 1996 11:14:39 PST Received: from localhost ([127.0.0.1]) by crevenia.parc.xerox.com with SMTP id <177480>; Wed, 28 Feb 1996 11:14:37 -0800 X-Mailer: exmh version 1.6.4 10/10/95 To: Joe Greco cc: phk@critter.tfs.com (Poul-Henning Kamp), stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-reply-to: Your message of "Mon, 26 Feb 1996 13:17:53 PST." <199602262117.PAA15987@brasil.moneng.mei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Feb 1996 11:14:21 PST From: Bill Fenner Message-Id: <96Feb28.111437pst.177480@crevenia.parc.xerox.com> Sender: owner-current@freebsd.org Precedence: bulk In message <199602262117.PAA15987@brasil.moneng.mei.com>you write: >Yes, I can imagine :-) I just want my firewalls to do something mildly >more social - like return a HOST_UNREACHABLE How about "Communication Administratively Prohibited" (code 13, see RFC1812 section 5.3.9) Bill From owner-freebsd-current Wed Feb 28 11:40:55 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA05923 for current-outgoing; Wed, 28 Feb 1996 11:40:55 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA05910 Wed, 28 Feb 1996 11:40:50 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id NAA03192; Wed, 28 Feb 1996 13:39:56 -0600 From: Joe Greco Message-Id: <199602281939.NAA03192@brasil.moneng.mei.com> Subject: Re: -stable hangs at boot (fwd) To: fenner@parc.xerox.com (Bill Fenner) Date: Wed, 28 Feb 1996 13:39:55 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, phk@critter.tfs.com, stable@freebsd.org, current@freebsd.org In-Reply-To: <96Feb28.111437pst.177480@crevenia.parc.xerox.com> from "Bill Fenner" at Feb 28, 96 11:14:21 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org Precedence: bulk > In message <199602262117.PAA15987@brasil.moneng.mei.com>you write: > >Yes, I can imagine :-) I just want my firewalls to do something mildly > >more social - like return a HOST_UNREACHABLE > > How about "Communication Administratively Prohibited" (code 13, see RFC1812 > section 5.3.9) > > Bill The hell if I care :-) My only concern would be making sure the right thing happened. ... JG From owner-freebsd-current Wed Feb 28 14:07:46 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA18925 for current-outgoing; Wed, 28 Feb 1996 14:07:46 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id OAA18909 Wed, 28 Feb 1996 14:07:41 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id QAA03415; Wed, 28 Feb 1996 16:05:27 -0600 From: Joe Greco Message-Id: <199602282205.QAA03415@brasil.moneng.mei.com> Subject: Re: IPFW (was: Re: -stable hangs at boot) To: fenner@parc.xerox.com (Bill Fenner) Date: Wed, 28 Feb 1996 16:05:26 -0600 (CST) Cc: nate@sri.MT.net, phk@critter.tfs.com, stable@freebsd.org, current@freebsd.org In-Reply-To: <96Feb28.110530pst.177480@crevenia.parc.xerox.com> from "Bill Fenner" at Feb 28, 96 11:05:24 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org Precedence: bulk > In message <199602261926.MAA00360@rocky.sri.MT.net> Nate wrote: > >I'm not sure I could > >see the need for filtering differently for incoming vs. outgoing (except > >in the case of syn. packets). > > You can prevent many IP spoofing attacks by disallowing packets with IP source > addresses that match your internal network addresses from coming in your > external connection (e.g. Xerox does > > access-list N deny 13.0.0.0 0.255.255.255 any > > on its incoming interface on the Cisco) Technically, one might want to place it's much-less-often-considered brother in the firewall too... the one that prevents OUTgoing packets that do NOT have a 13.0.0.0 address... (no I don't do this either but I should). ... JG From owner-freebsd-current Wed Feb 28 14:56:11 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA23877 for current-outgoing; Wed, 28 Feb 1996 14:56:11 -0800 (PST) Received: from nervosa.com (root@nervosa.com [192.187.228.86]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id OAA23872 for ; Wed, 28 Feb 1996 14:56:06 -0800 (PST) Received: from nervosa.com (coredump@onyx.nervosa.com [10.0.0.1]) by nervosa.com (8.7.4/nervosa.com.2) with SMTP id OAA21509 for ; Wed, 28 Feb 1996 14:55:59 -0800 (PST) Date: Wed, 28 Feb 1996 14:55:58 -0800 (PST) From: invalid opcode To: current@freebsd.org Subject: is it just me Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk Or does all mail to freebsd-stable end up in freebsd-current? == Chris Layne ============================================================== == coredump@nervosa.com ================= http://www.nervosa.com/~coredump == From owner-freebsd-current Wed Feb 28 16:56:09 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA02102 for current-outgoing; Wed, 28 Feb 1996 16:56:09 -0800 (PST) Received: from bunyip.cc.uq.oz.au (bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA02092 for ; Wed, 28 Feb 1996 16:56:06 -0800 (PST) Received: from bunyip.cc.uq.oz.au by bunyip.cc.uq.oz.au id <24119-0@bunyip.cc.uq.oz.au>; Thu, 29 Feb 1996 10:00:59 +1000 Received: from netfl15a.devetir.qld.gov.au by pandora.devetir.qld.gov.au (8.6.10/DEVETIR-E0.3a) with ESMTP id JAA10967 for ; Thu, 29 Feb 1996 09:17:23 +1000 Received: from localhost by netfl15a.devetir.qld.gov.au (8.6.8.1/DEVETIR-0.1) id XAA28189 for ; Wed, 28 Feb 1996 23:20:21 GMT Message-Id: <199602282320.XAA28189@netfl15a.devetir.qld.gov.au> X-Mailer: exmh version 1.6.5 12/11/95 To: current@freebsd.org Subject: libc/db/mpool/mpool.c still blows chunks X-Face: 3}heU+2?b->-GSF-G4T4>jEB9~FR(V9lo&o>kAy=Pj&;oVOc<|pr%I/VSG"ZD32J>5gGC0N 7gj]^GI@M:LlqNd]|(2OxOxy@$6@/!,";-!OlucF^=jq8s57$%qXd/ieC8DhWmIy@J1AcnvSGV\|*! >Bvu7+0h4zCY^]{AxXKsDTlgA2m]fX$W@'8ev-Qi+-;%L'CcZ'NBL!@n?}q!M&Em3*eW7,093nOeV8 M)(u+6D;%B7j\XA/9j4!Gj~&jYzflG[#)E9sI&Xe9~y~Gn%fA7>F:YKr"Wx4cZU*6{^2ocZ!YyR Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 Feb 1996 09:20:20 +1000 From: Stephen Hocking Sender: owner-current@freebsd.org Precedence: bulk When were the fixes for the hash stuff being committed again? Stephen -- I do not speak for the Worker's Compensation Board of Queensland - They don't pay me enough for that! From owner-freebsd-current Wed Feb 28 17:54:55 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA06844 for current-outgoing; Wed, 28 Feb 1996 17:54:55 -0800 (PST) Received: from veda.is (root@veda.is [193.4.230.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id RAA06833 for ; Wed, 28 Feb 1996 17:54:48 -0800 (PST) Received: (from adam@localhost) by veda.is (8.7.4/8.7.3) id BAA23248; Thu, 29 Feb 1996 01:53:39 GMT Date: Thu, 29 Feb 1996 01:53:39 GMT From: Adam David Message-Id: <199602290153.BAA23248@veda.is> To: mark@grondar.ZA (Mark Murray) Cc: freebsd-current@freebsd.org Subject: Re: New Dual-personality crypt References: <199602250807.KAA20978@grumble.grondar.za> X-Newsreader: NN version 6.5.0 #2 (NOV) Sender: owner-current@freebsd.org Precedence: bulk >Nate Williams wrote: >> How can I force my passwords to be the old DES crypt function on a box >> that previously used MD5 crypt? There are only two accounts on it (mine >> and root), but I'd like it to use DES like all of the other machines in >> the group. >This was a design point that I could not quite decide on. I decided >to go the route-of-least-change and keep the encryption algorithm that >was used to make the entry in the first place. >> Even after I've re-run passwd after installing the new libraries and >> binaries, it's still generating MD5 passwords instead of DES passwords. >I have been slowly getting round to putting a option in passwd(1) >to allow the user to select the encryption algorithm, but I am not >too sure how to deal with the case of the system without DES. I'm >sure I can come up with something. >> How do I force it to generate old-style DES passwords in spite of what >> the old passwords were, short of removing the password completely and >> then re-generating passwords? Shouldn't the new routine 'generate' >> passwords using the default routines, but read passwords from both? >See above. I'd greatly appreciate some input on this. I'm kinda >prepared to go either way once I have some sort of idea what the >group would prefer. In the meanwhile, it is unfortunately only >possible to force DES by removing the old MD5 password. The encryption methods and default behaviour are site-admin decisions. Therefore it would be useful to see the following as possibilities: Admins to specify which encrytion methods are available for passwords, and set the default to one of { same_as_previous, DES, MD5, ...... } If users are allowed to select which method, admins should be able to restrict the choices to any subset of the methods recognised and handled by the site, thus providing a means of transparent migration from one set of encryption methods to another. I understood the original dual-personality crypt announcement essentially to mean the same as I have stated here, except with the enforcement of {DES, MD5} as the available set, and that ordinary users would typically have no choice over which method is used to generate the new password. -- Adam David From owner-freebsd-current Wed Feb 28 21:33:42 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA28112 for current-outgoing; Wed, 28 Feb 1996 21:33:42 -0800 (PST) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id VAA28104 for ; Wed, 28 Feb 1996 21:33:38 -0800 (PST) Received: from localhost.shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.4/8.7.3) with SMTP id VAA01367; Wed, 28 Feb 1996 21:31:31 -0800 (PST) Message-Id: <199602290531.VAA01367@precipice.shockwave.com> To: Adam David cc: mark@grondar.ZA (Mark Murray), freebsd-current@freebsd.org Subject: Re: New Dual-personality crypt In-reply-to: Your message of "Thu, 29 Feb 1996 01:53:39 GMT." <199602290153.BAA23248@veda.is> Date: Wed, 28 Feb 1996 21:31:25 -0800 From: Paul Traina Sender: owner-current@freebsd.org Precedence: bulk I would strongly suggest that users NOT be allowed to select their method unless the sysadmin explicitly enables it... and I think a sysadmin would be a fool to enable it (so I wouldn't even write the code to allow this, however if someone has too much time on their hands, why not bloat out the system further :-( ). In any case, we should not ship with this mode enabled. From: Adam David Subject: Re: New Dual-personality crypt >Nate Williams wrote: >> How can I force my passwords to be the old DES crypt function on a box >> that previously used MD5 crypt? There are only two accounts on it (mine >> and root), but I'd like it to use DES like all of the other machines in >> the group. >This was a design point that I could not quite decide on. I decided >to go the route-of-least-change and keep the encryption algorithm that >was used to make the entry in the first place. >> Even after I've re-run passwd after installing the new libraries and >> binaries, it's still generating MD5 passwords instead of DES passwords. >I have been slowly getting round to putting a option in passwd(1) >to allow the user to select the encryption algorithm, but I am not >too sure how to deal with the case of the system without DES. I'm >sure I can come up with something. >> How do I force it to generate old-style DES passwords in spite of what >> the old passwords were, short of removing the password completely and >> then re-generating passwords? Shouldn't the new routine 'generate' >> passwords using the default routines, but read passwords from both? >See above. I'd greatly appreciate some input on this. I'm kinda >prepared to go either way once I have some sort of idea what the >group would prefer. In the meanwhile, it is unfortunately only >possible to force DES by removing the old MD5 password. The encryption methods and default behaviour are site-admin decisions. Therefore it would be useful to see the following as possibilities: Admins to specify which encrytion methods are available for passwords, and se >>t the default to one of { same_as_previous, DES, MD5, ...... >>} If users are allowed to select which method, admins should be able to restric >>t the choices to any subset of the methods recognised and handled by the site >>, thus providing a means of transparent migration from one set of encryption methods to another. I understood the original dual-personality crypt announcement essentially to mean the same as I have stated here, except with the enforcement of {DES, MD5 >>} as the available set, and that ordinary users would typically have no choice over which method is used to generate the new password. -- Adam David From owner-freebsd-current Wed Feb 28 21:59:44 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA00614 for current-outgoing; Wed, 28 Feb 1996 21:59:44 -0800 (PST) Received: from grumble.grondar.za (root@grumble.grondar.za [196.7.18.130]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id VAA00607 for ; Wed, 28 Feb 1996 21:59:39 -0800 (PST) Received: from grumble.grondar.za (mark@localhost [127.0.0.1]) by grumble.grondar.za (8.7.3/8.7.3) with ESMTP id HAA02484; Thu, 29 Feb 1996 07:59:07 +0200 (SAT) Message-Id: <199602290559.HAA02484@grumble.grondar.za> To: Adam David cc: freebsd-current@freebsd.org Subject: Re: New Dual-personality crypt Date: Thu, 29 Feb 1996 07:59:07 +0200 From: Mark Murray Sender: owner-current@freebsd.org Precedence: bulk Adam David wrote: > The encryption methods and default behaviour are site-admin decisions. > Therefore it would be useful to see the following as possibilities: > > Admins to specify which encrytion methods are available for passwords, > and set the default to one of { same_as_previous, DES, MD5, > ...... } If users are allowed to select which > method, admins should be able to restrict the choices to any subset > of the methods recognised and handled by the site, thus providing > a means of transparent migration from one set of encryption methods > to another. I agree 100% - and sort of had this in mind. > I understood the original dual-personality crypt announcement > essentially to mean the same as I have stated here, except with > the enforcement of {DES, MD5} as the available set, and that ordinary > users would typically have no choice over which method is used to > generate the new password. Right. I am looking for a decent metthod to implement this. Someone has already suggested something like an /etc/passwd.conf that has some rules to cover this. So far I like this seems like the way I will go. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grondar.za for PGP key From owner-freebsd-current Wed Feb 28 22:02:49 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA00940 for current-outgoing; Wed, 28 Feb 1996 22:02:49 -0800 (PST) Received: from grumble.grondar.za (root@grumble.grondar.za [196.7.18.130]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id WAA00933 for ; Wed, 28 Feb 1996 22:02:40 -0800 (PST) Received: from grumble.grondar.za (mark@localhost [127.0.0.1]) by grumble.grondar.za (8.7.3/8.7.3) with ESMTP id IAA02511; Thu, 29 Feb 1996 08:01:44 +0200 (SAT) Message-Id: <199602290601.IAA02511@grumble.grondar.za> To: Paul Traina cc: Adam David , freebsd-current@freebsd.org Subject: Re: New Dual-personality crypt Date: Thu, 29 Feb 1996 08:01:43 +0200 From: Mark Murray Sender: owner-current@freebsd.org Precedence: bulk Paul Traina wrote: > I would strongly suggest that users NOT be allowed to select their method > unless the sysadmin explicitly enables it... and I think a sysadmin would > be a fool to enable it (so I wouldn't even write the code to allow this, > however if someone has too much time on their hands, why not bloat out the > system further :-( ). Agreed. The current system it to keep the existing method. > In any case, we should not ship with this mode enabled. Sure. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grondar.za for PGP key From owner-freebsd-current Wed Feb 28 23:25:34 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA11492 for current-outgoing; Wed, 28 Feb 1996 23:25:34 -0800 (PST) Received: from nervosa.com (root@nervosa.com [192.187.228.86]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id XAA11477 for ; Wed, 28 Feb 1996 23:25:31 -0800 (PST) Received: from nervosa.com (coredump@onyx.nervosa.com [10.0.0.1]) by nervosa.com (8.7.4/nervosa.com.2) with SMTP id XAA23182; Wed, 28 Feb 1996 23:24:37 -0800 (PST) Date: Wed, 28 Feb 1996 23:24:37 -0800 (PST) From: invalid opcode To: Paul Traina cc: Adam David , Mark Murray , freebsd-current@freebsd.org Subject: Re: New Dual-personality crypt In-Reply-To: <199602290531.VAA01367@precipice.shockwave.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk On Wed, 28 Feb 1996, Paul Traina wrote: > I would strongly suggest that users NOT be allowed to select their method > unless the sysadmin explicitly enables it... and I think a sysadmin would I strongly agree with this also. a: what do users' care what encryption algorithim is used, it's not something that will make any kind of difference for them. b: We could make passwd(8) generate md5 passwords by default, and have, for instance, a "-e" flag to change the encryption method; or we could add another file to /etc for instance "passwd.conf" that has the configuration information stored there. I would opt for passwd.conf. == Chris Layne ============================================================== == coredump@nervosa.com ================= http://www.nervosa.com/~coredump == From owner-freebsd-current Wed Feb 28 23:37:39 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA13576 for current-outgoing; Wed, 28 Feb 1996 23:37:39 -0800 (PST) Received: from nervosa.com (root@nervosa.com [192.187.228.86]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id XAA13556 for ; Wed, 28 Feb 1996 23:37:34 -0800 (PST) Received: from nervosa.com (coredump@onyx.nervosa.com [10.0.0.1]) by nervosa.com (8.7.4/nervosa.com.2) with SMTP id XAA23291; Wed, 28 Feb 1996 23:37:00 -0800 (PST) Date: Wed, 28 Feb 1996 23:36:54 -0800 (PST) From: invalid opcode To: Paul Traina cc: Adam David , Mark Murray , freebsd-current@freebsd.org Subject: Re: New Dual-personality crypt In-Reply-To: <199602290531.VAA01367@precipice.shockwave.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org Precedence: bulk On Wed, 28 Feb 1996, Paul Traina wrote: > In any case, we should not ship with this mode enabled. Ahh, ignore some of my previous post, I say we should check which method root's password has been encrypted with and use that as passwd(8)'s base. Seeing as root is the only one who can change root's password, this will effectively limit the policy setting to root only. I opt for an extra flag to passwd(8) of which will only take effect if the user is root, i.e. users can specify the flag, but it will have no effect. /etc/passwd: root:YZrx4tbVBxKLI:0:0:root:/root:/bin/sh Obviously this is DES, so passwd(8) will use DES as the default for all password's being changed or added. /etc/passwd: root:$1$5Srrllqi$ee22rrbdqXAwnyyeahright:0:0::0:0:root:/root:/bin/sh Obviously this is md5, so passwd(8) will use md5 as the default from now on. This also has the added option of being able to change your policy globally by just changing the root password with the extra passwd(8) flag. == Chris Layne ============================================================== == coredump@nervosa.com ================= http://www.nervosa.com/~coredump == From owner-freebsd-current Thu Feb 29 00:55:03 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA23150 for current-outgoing; Thu, 29 Feb 1996 00:55:03 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA23127 Thu, 29 Feb 1996 00:54:57 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0ts47H-0003vmC; Thu, 29 Feb 96 00:53 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id JAA02614; Thu, 29 Feb 1996 09:53:35 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: Joe Greco cc: fenner@parc.xerox.com (Bill Fenner), nate@sri.MT.net, stable@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: IPFW (was: Re: -stable hangs at boot) In-reply-to: Your message of "Wed, 28 Feb 1996 16:05:26 CST." <199602282205.QAA03415@brasil.moneng.mei.com> Date: Thu, 29 Feb 1996 09:53:35 +0100 Message-ID: <2612.825584015@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.ORG Precedence: bulk > > In message <199602261926.MAA00360@rocky.sri.MT.net> Nate wrote: > > >I'm not sure I could > > >see the need for filtering differently for incoming vs. outgoing (except > > >in the case of syn. packets). > > > > You can prevent many IP spoofing attacks by disallowing packets with IP sou rce > > addresses that match your internal network addresses from coming in your > > external connection (e.g. Xerox does > > > > access-list N deny 13.0.0.0 0.255.255.255 any > > > > on its incoming interface on the Cisco) > > Technically, one might want to place it's much-less-often-considered brother > in the firewall too... the one that prevents OUTgoing packets that do NOT > have a 13.0.0.0 address... > > (no I don't do this either but I should). And if you're on a lousy ISP, also a filter to block all of the "private" networks, 192.168.x.x and so on, (RFC 1596 ?) -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Thu Feb 29 02:11:00 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA28944 for current-outgoing; Thu, 29 Feb 1996 02:11:00 -0800 (PST) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA28938 for ; Thu, 29 Feb 1996 02:10:54 -0800 (PST) Received: from myrtilos.cs.utwente.nl by utrhcs.cs.utwente.nl (SMI-8.6/csrelay-SVR4_1.3/RBCS) id LAA02668; Thu, 29 Feb 1996 11:10:47 +0100 Received: from curie.cs.utwente.nl by myrtilos.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id LAA24686; Thu, 29 Feb 1996 11:10:45 +0100 Received: from localhost by curie.cs.utwente.nl (SMI-8.6/SMI-SVR4) id LAA11767; Thu, 29 Feb 1996 11:10:44 +0100 To: current@freebsd.org Subject: Processing ICMP packets (was: -stable hangs at boot (fwd)) In-reply-to: Your message of "Wed, 28 Feb 1996 11:14:21 PST." <96Feb28.111437pst.177480@crevenia.parc.xerox.com> Date: Thu, 29 Feb 1996 11:10:43 +0100 Message-ID: <11766.825588643@curie.cs.utwente.nl> From: Andras Olah Sender: owner-current@freebsd.org Precedence: bulk On Wed, 28 Feb 1996 11:14:21 PST, Bill Fenner wrote: > In message <199602262117.PAA15987@brasil.moneng.mei.com>you write: > >Yes, I can imagine :-) I just want my firewalls to do something mildly > >more social - like return a HOST_UNREACHABLE > > How about "Communication Administratively Prohibited" (code 13, see RFC1812 > section 5.3.9) I've got two questions related to the handling of ICMP packets: 1. Shouldn't icmp_input() map ICMP type 3, code 13 packets to PRC_UNREACH* error codes, instead of discarding them? 2. Background info: What's the difference between codes 9, 10 (ICMP_UNREACH_{NET,HOST_PROHIB) and 13? Is 13 a code which covers both 9 and 10, or does it have a special meaning? Thanks, Andras From owner-freebsd-current Thu Feb 29 08:55:25 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA22290 for current-outgoing; Thu, 29 Feb 1996 08:55:25 -0800 (PST) Received: from grumble.grondar.za (root@grumble.grondar.za [196.7.18.130]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id IAA22281 for ; Thu, 29 Feb 1996 08:55:11 -0800 (PST) Received: from grumble.grondar.za (mark@localhost [127.0.0.1]) by grumble.grondar.za (8.7.3/8.7.3) with ESMTP id SAA05200; Thu, 29 Feb 1996 18:52:57 +0200 (SAT) Message-Id: <199602291652.SAA05200@grumble.grondar.za> To: invalid opcode cc: Paul Traina , Adam David , Mark Murray , freebsd-current@FreeBSD.org Subject: Re: New Dual-personality crypt Date: Thu, 29 Feb 1996 18:52:56 +0200 From: Mark Murray Sender: owner-current@FreeBSD.org Precedence: bulk invalid opcode wrote: > On Wed, 28 Feb 1996, Paul Traina wrote: > > > I would strongly suggest that users NOT be allowed to select their method > > unless the sysadmin explicitly enables it... and I think a sysadmin would > > I strongly agree with this also. a: what do users' care what encryption > algorithim is used, it's not something that will make any kind of > difference for them. b: We could make passwd(8) generate md5 passwords by > default, and have, for instance, a "-e" flag to change the encryption > method; or we could add another file to /etc for instance "passwd.conf" > that has the configuration information stored there. I would opt for > passwd.conf. This is what I would like, too. I do not beleive that it is at all valid for a sysadmin to allow users to choose their encryption type - this is quite frankly none of the users' business. I'll get to it. (Read: I'll add it to my list) M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grondar.za for PGP key From owner-freebsd-current Thu Feb 29 09:05:10 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA22881 for current-outgoing; Thu, 29 Feb 1996 09:05:10 -0800 (PST) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA22872 for ; Thu, 29 Feb 1996 09:05:07 -0800 (PST) Received: from localhost.shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.4/8.7.3) with SMTP id JAA05822; Thu, 29 Feb 1996 09:04:22 -0800 (PST) Message-Id: <199602291704.JAA05822@precipice.shockwave.com> To: Andras Olah cc: current@freebsd.org Subject: Re: Processing ICMP packets (was: -stable hangs at boot (fwd)) In-reply-to: Your message of "Thu, 29 Feb 1996 11:10:43 +0100." <11766.825588643@curie.cs.utwente.nl> Date: Thu, 29 Feb 1996 09:04:21 -0800 From: Paul Traina Sender: owner-current@freebsd.org Precedence: bulk From: Andras Olah Subject: Processing ICMP packets (was: -stable hangs at boot (fwd)) On Wed, 28 Feb 1996 11:14:21 PST, Bill Fenner wrote: > In message <199602262117.PAA15987@brasil.moneng.mei.com>you write: > >Yes, I can imagine :-) I just want my firewalls to do something mildly > >more social - like return a HOST_UNREACHABLE > > How about "Communication Administratively Prohibited" (code 13, see RFC1812 >> > section 5.3.9) I've got two questions related to the handling of ICMP packets: 1. Shouldn't icmp_input() map ICMP type 3, code 13 packets to PRC_UNREACH* error codes, instead of discarding them? Yes (!!!) Please fix. 2. Background info: What's the difference between codes 9, 10 (ICMP_UNREACH_{NET,HOST_PROHIB) and 13? Is 13 a code which covers both 9 and 10, or does it have a special meaning? It does have special meaning. Theoretically, you SHOULD be able to say "if I get 9 (or 10) I cannot reach that net (or host), period." However, many firewalls generate 9 or 10 (which was obsoleted by 13 for just this reason). 13 says "don't assume anything other than this connection attempt was refused for administrative reasons." Thanks, Andras From owner-freebsd-current Thu Feb 29 09:09:13 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA23154 for current-outgoing; Thu, 29 Feb 1996 09:09:13 -0800 (PST) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA23145 Thu, 29 Feb 1996 09:09:08 -0800 (PST) Received: from localhost.shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.4/8.7.3) with SMTP id JAA05845; Thu, 29 Feb 1996 09:07:06 -0800 (PST) Message-Id: <199602291707.JAA05845@precipice.shockwave.com> To: Poul-Henning Kamp cc: Joe Greco , fenner@parc.xerox.com (Bill Fenner), nate@sri.MT.net, stable@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: IPFW (was: Re: -stable hangs at boot) In-reply-to: Your message of "Thu, 29 Feb 1996 09:53:35 +0100." <2612.825584015@critter.tfs.com> Date: Thu, 29 Feb 1996 09:07:06 -0800 From: Paul Traina Sender: owner-current@FreeBSD.ORG Precedence: bulk On sites that I run, my filter rules -start- with: deny any deny any deny 127.0.0.0 0.255.255.255 any deny 0.0.0.0 0.255.255.255 any deny <1597 nets> any The idea is that you want to block off all source addresses that you should never expect to see. 127 is a favorite of mine, because a lot of people have localhost in their hosts.equiv files. Paul From owner-freebsd-current Thu Feb 29 09:32:46 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA24674 for current-outgoing; Thu, 29 Feb 1996 09:32:46 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA24669 Thu, 29 Feb 1996 09:32:41 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id LAA04770; Thu, 29 Feb 1996 11:31:53 -0600 From: Joe Greco Message-Id: <199602291731.LAA04770@brasil.moneng.mei.com> Subject: Re: IPFW (was: Re: -stable hangs at boot) To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Thu, 29 Feb 1996 11:31:52 -0600 (CST) Cc: stable@freebsd.org, current@freebsd.org In-Reply-To: <2612.825584015@critter.tfs.com> from "Poul-Henning Kamp" at Feb 29, 96 09:53:35 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org Precedence: bulk > > Technically, one might want to place it's much-less-often-considered brother > > in the firewall too... the one that prevents OUTgoing packets that do NOT > > have a 13.0.0.0 address... > > > > (no I don't do this either but I should). > > And if you're on a lousy ISP, also a filter to block all of the "private" > networks, 192.168.x.x and so on, (RFC 1596 ?) RFC1597: 10.0.0.0 - 10.255.255.255 172.16.0.0 - 172.31.255.255 192.168.0.0 - 192.168.255.255 That's a real good point, actually. Also 127.*, I would think... (actually, some non-lousy ISP's assign space out of this address range as it serves as a very "gross" firewall. And even if you don't, your customers might use it as described in 1597 and have a misconfigured router that doesn't prevent outbound packets. This implies you want to stop traffic in BOTH directions). Gosh, this gets complex quickly :-) ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-current Thu Feb 29 10:00:26 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA26112 for current-outgoing; Thu, 29 Feb 1996 10:00:26 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA26107 for ; Thu, 29 Feb 1996 10:00:23 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id KAA00882 for ; Fri, 1 Mar 1996 10:00:15 -0800 Received: from localhost (localhost [127.0.0.1]) by rover.village.org (8.6.11/8.6.6) with SMTP id KAA03050; Thu, 29 Feb 1996 10:57:55 -0700 Message-Id: <199602291757.KAA03050@rover.village.org> To: Paul Traina Subject: Re: Processing ICMP packets (was: -stable hangs at boot (fwd)) Cc: Andras Olah , current@freebsd.org In-reply-to: Your message of Thu, 29 Feb 1996 09:04:21 PST Date: Thu, 29 Feb 1996 10:57:55 -0700 From: Warner Losh Sender: owner-current@freebsd.org Precedence: bulk : It does have special meaning. Theoretically, you SHOULD be able to say : "if I get 9 (or 10) I cannot reach that net (or host), period." However, : many firewalls generate 9 or 10 (which was obsoleted by 13 for just this : reason). 13 says "don't assume anything other than this connection attempt : was refused for administrative reasons." Just so long as you don't wind up triggering the old 4.2 TCP bug. Namely, when a port is unreachible, then *ALL* connections to that host are discarded. It is safer to silently discard packets in a packet filter than to send back ICMP messages since it won't trigger these bugs and will be treateed as if it was lost and retransmitted or timed out. If people feel strongly that they want it, then it should be an option that can be turned off since we have to deal with said 4.2 TCP implementations from time to time and an accidental connection could cause us great grief. If someone has the old TCP code from then, and can assure me that this won't be a problem because it doesn't understand type 13 packets, then never mind. Warner From owner-freebsd-current Thu Feb 29 10:02:16 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA26185 for current-outgoing; Thu, 29 Feb 1996 10:02:16 -0800 (PST) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA26180 for ; Thu, 29 Feb 1996 10:02:14 -0800 (PST) Received: from localhost.shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.4/8.7.3) with SMTP id KAA00600; Thu, 29 Feb 1996 10:01:21 -0800 (PST) Message-Id: <199602291801.KAA00600@precipice.shockwave.com> To: Warner Losh cc: Andras Olah , current@freebsd.org Subject: Re: Processing ICMP packets (was: -stable hangs at boot (fwd)) In-reply-to: Your message of "Thu, 29 Feb 1996 10:57:55 MST." <199602291757.KAA03050@rover.village.org> Date: Thu, 29 Feb 1996 10:01:21 -0800 From: Paul Traina Sender: owner-current@freebsd.org Precedence: bulk the old tcp code does not understand type 13 packets From: Warner Losh Subject: Re: Processing ICMP packets (was: -stable hangs at boot (fwd)) : It does have special meaning. Theoretically, you SHOULD be able to say : "if I get 9 (or 10) I cannot reach that net (or host), period." However, : many firewalls generate 9 or 10 (which was obsoleted by 13 for just this : reason). 13 says "don't assume anything other than this connection attempt : was refused for administrative reasons." Just so long as you don't wind up triggering the old 4.2 TCP bug. Namely, when a port is unreachible, then *ALL* connections to that host are discarded. It is safer to silently discard packets in a packet filter than to send back ICMP messages since it won't trigger these bugs and will be treateed as if it was lost and retransmitted or timed out. If people feel strongly that they want it, then it should be an option that can be turned off since we have to deal with said 4.2 TCP implementations from time to time and an accidental connection could cause us great grief. If someone has the old TCP code from then, and can assure me that this won't be a problem because it doesn't understand type 13 packets, then never mind. Warner From owner-freebsd-current Thu Feb 29 10:22:13 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA27654 for current-outgoing; Thu, 29 Feb 1996 10:22:13 -0800 (PST) Received: from godzilla.zeta.org.au ([203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA27638 Thu, 29 Feb 1996 10:22:06 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id FAA27306; Fri, 1 Mar 1996 05:17:42 +1100 Date: Fri, 1 Mar 1996 05:17:42 +1100 From: Bruce Evans Message-Id: <199602291817.FAA27306@godzilla.zeta.org.au> To: current@freefall.freebsd.org, gpalmer@freefall.freebsd.org Subject: Re: cvs commit: src/sys/i386/conf LINT src/sys/kern subr_prf.c Sender: owner-current@FreeBSD.ORG Precedence: bulk > Modified: sys/i386/conf LINT > sys/kern subr_prf.c > Log: > Add a new option: DDB_UNATTENDED. Stops machine dropping into DDB > when it panics, but leaving activation of DDB from the console > unaffected. `grep -l Debugger LINT/*.o' shows 15 modules other than subr_prf.o, syscons.o and pcvt_kbd.o that may need the DDB_UNATTENDED ifdef. The one in sd.o bit me the other day when a swapped a disk while running X. It should go away along with many warnings from the upper SCSI layer. Please don't add new options without putting them in the options file. Bruce From owner-freebsd-current Thu Feb 29 11:01:57 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA00212 for current-outgoing; Thu, 29 Feb 1996 11:01:57 -0800 (PST) Received: from skiddaw.elsevier.co.uk (skiddaw.elsevier.co.uk [193.131.222.60]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA00194 for ; Thu, 29 Feb 1996 11:01:42 -0800 (PST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by skiddaw.elsevier.co.uk (8.6.12/8.6.12) with ESMTP id SAA29125 for ; Thu, 29 Feb 1996 18:59:12 GMT Received: from tees by snowdon with SMTP (PP); Thu, 29 Feb 1996 18:57:27 +0000 Received: (from dpr@localhost) by tees (SMI-8.6/8.6.12) id SAA17390; Thu, 29 Feb 1996 18:59:15 GMT Date: Thu, 29 Feb 1996 18:59:15 GMT From: Paul Richards Message-Id: <199602291859.SAA17390@tees> To: olah@cs.utwente.nl, pst@shockwave.com Subject: Re: Processing ICMP packets (was: -stable hangs at boot (fwd)) Cc: current@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: Y4mk3oW/lJtG5AY0P5jcYQ== Sender: owner-current@FreeBSD.ORG Precedence: bulk > > It does have special meaning. Theoretically, you SHOULD be able to say > "if I get 9 (or 10) I cannot reach that net (or host), period." However, > many firewalls generate 9 or 10 (which was obsoleted by 13 for just this > reason). 13 says "don't assume anything other than this connection attempt > was refused for administrative reasons." > > Thanks, > Andras > Trouble is, if you're a paranoid firewall maintainer, like most are (and should be), then you don't want to tell the world that you're a firewall and you're denying access, you want to say, there's no such address as the one you're trying so stop wasting your time. From owner-freebsd-current Thu Feb 29 11:42:08 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA02322 for current-outgoing; Thu, 29 Feb 1996 11:42:08 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA02312 for ; Thu, 29 Feb 1996 11:42:06 -0800 (PST) Received: (from jkh@localhost) by time.cdrom.com (8.7.4/8.6.9) id LAA03838 for current@freebsd.org; Thu, 29 Feb 1996 11:42:04 -0800 (PST) Date: Thu, 29 Feb 1996 11:42:04 -0800 (PST) From: "Jordan K. Hubbard" Message-Id: <199602291942.LAA03838@time.cdrom.com> To: current@freebsd.org Subject: pstat: cannot read swaplist: kvm_read: Bad address Sender: owner-current@freebsd.org Precedence: bulk I now get this for pstat all the time, and I've recompiled all the libs it depends on. Anyone seeing the same thing? Jordan From owner-freebsd-current Thu Feb 29 11:46:25 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA02566 for current-outgoing; Thu, 29 Feb 1996 11:46:25 -0800 (PST) Received: from veda.is (root@veda.is [193.4.230.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA02560 for ; Thu, 29 Feb 1996 11:46:21 -0800 (PST) Received: (from adam@localhost) by veda.is (8.7.4/8.7.3) id TAA11702; Thu, 29 Feb 1996 19:45:45 GMT Message-Id: <199602291945.TAA11702@veda.is> Subject: ypserv: ypproc_master To: wpaul@ctr.columbia.edu Date: Thu, 29 Feb 1996 19:45:40 +0000 (GMT) From: "Adam David" Cc: freebsd-current@freebsd.org X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk Currently, ypserv dumps core while replying to a ypproc_master request if access is being denied to the remote host. This results from xdr_string() not being designed to handle NULL strings. There seem to be vestiges of an attempt to represent a NULL string by a size of -1, but this could be my imagination. Looks like ypserv and rpc.yppasswdd need to adjusted to the limitations of xdr. -- Adam David From owner-freebsd-current Thu Feb 29 12:11:12 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA03958 for current-outgoing; Thu, 29 Feb 1996 12:11:12 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA03953 for ; Thu, 29 Feb 1996 12:11:09 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id NAA12375; Thu, 29 Feb 1996 13:12:30 -0700 Date: Thu, 29 Feb 1996 13:12:30 -0700 From: Nate Williams Message-Id: <199602292012.NAA12375@rocky.sri.MT.net> To: Paul Richards Cc: current@FreeBSD.ORG Subject: Re: Processing ICMP packets (was: -stable hangs at boot (fwd)) In-Reply-To: <199602291859.SAA17390@tees> References: <199602291859.SAA17390@tees> Sender: owner-current@FreeBSD.ORG Precedence: bulk > > It does have special meaning. Theoretically, you SHOULD be able to say > > "if I get 9 (or 10) I cannot reach that net (or host), period." However, > > many firewalls generate 9 or 10 (which was obsoleted by 13 for just this > > reason). 13 says "don't assume anything other than this connection attempt > > was refused for administrative reasons." > > Trouble is, if you're a paranoid firewall maintainer, like most are > (and should be), then you don't want to tell the world that you're a > firewall and you're denying access, you want to say, there's no such > address as the one you're trying so stop wasting your time. I disagree. This is security through obscurity, and any hacker worth their salt is going to see right through this. If they trying to access a host behind a firewall, they already know it exists, so if you think telling them otherwise is going to matter then you're simply fooling yourself. Nate p.s. Paul, I'm still waiting for a review of my handbook entries. :) From owner-freebsd-current Thu Feb 29 12:17:44 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA04327 for current-outgoing; Thu, 29 Feb 1996 12:17:44 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA04305 Thu, 29 Feb 1996 12:17:35 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id OAA06433; Thu, 29 Feb 1996 14:16:15 -0600 From: Joe Greco Message-Id: <199602292016.OAA06433@brasil.moneng.mei.com> Subject: Re: IPFW (was: Re: -stable hangs at boot) To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Thu, 29 Feb 1996 14:16:15 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, fenner@parc.xerox.com, nate@sri.MT.net, stable@freebsd.org, current@freebsd.org In-Reply-To: <2612.825584015@critter.tfs.com> from "Poul-Henning Kamp" at Feb 29, 96 09:53:35 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org Precedence: bulk > > Technically, one might want to place it's much-less-often-considered brother > > in the firewall too... the one that prevents OUTgoing packets that do NOT > > have a 13.0.0.0 address... > > > > (no I don't do this either but I should). > > And if you're on a lousy ISP, also a filter to block all of the "private" > networks, 192.168.x.x and so on, (RFC 1596 ?) Okay, firewall debaters. Here's what I've done on gateway.inr.sol.net. 204.95.219.1 is the local address of my T1 interface. 206.55.64.17 is the address of the router on my backbone Ethernet. Commentary in curly braces. #! /bin/sh - PATH=/sbin; export PATH ipfw f echo "Installing Firewall" # # ----- IP Bad Address Prevention Section ----- # { Packets from these addresses should never be coming in } # Block RFC1597 "Private Internets" (inbound) ipfw addf deny all from 10.0.0.0/8 to 0/0 via 204.95.219.1 ipfw addf deny all from 172.16.0.0/16 to 0/0 via 204.95.219.1 ipfw addf deny all from 192.168.0.0/16 to 0/0 via 204.95.219.1 # Block other "Shouldn't Exist" Internets (inbound) ipfw addf deny all from 127.0.0.0/8 to 0/0 via 204.95.219.1 ipfw addf deny all from 0.0.0.0/8 to 0/0 via 204.95.219.1 # { Likewise, we should never allow packets with these addresses } # { as source or destination to go out onto the Big Net } # Block RFC1597 "Private Internets" as Source Address (outbound) ipfw addf deny all from 10.0.0.0/8 to 0/0 via 206.55.64.17 ipfw addf deny all from 172.16.0.0/16 to 0/0 via 206.55.64.17 ipfw addf deny all from 192.168.0.0/16 to 0/0 via 206.55.64.17 # Block RFC1597 "Private Internets" as Destination Address (outbound) ipfw addf deny all from 0/0 to 10.0.0.0/8 via 206.55.64.17 ipfw addf deny all from 0/0 to 172.16.0.0/16 via 206.55.64.17 ipfw addf deny all from 0/0 to 192.168.0.0/16 via 206.55.64.17 # Block other "Shouldn't Exist" Internets as Source Address (outbound) ipfw addf deny all from 0/0 to 127.0.0.0/8 via 206.55.64.17 ipfw addf deny all from 0/0 to 0.0.0.0/8 via 206.55.64.17 # Block other "Shouldn't Exist" Internets as Destination Address (outbound) ipfw addf deny all from 127.0.0.0/8 to 0/0 via 206.55.64.17 ipfw addf deny all from 0.0.0.0/8 to 0/0 via 206.55.64.17 # # ----- IP Spoofing Prevention Section ----- # { Prevent packets that claim to have source addresses on our networks } # { from entering from outside our networks } # Block SOLNET-BLK-1 (inbound) ipfw addf deny all from 206.55.64.0/20 to 0/0 via 204.95.219.1 # Block INCNET-172 (inbound) ipfw addf deny all from 204.95.172.0/24 to 0/0 via 204.95.219.1 # Block INCNET-219 (inbound) ipfw addf deny all from 204.95.219.0/24 to 0/0 via 204.95.219.1 # { Now do something funny. Block *every* outbound source address and } # { then re-allow JUST those that could potentially be generated on our } # { networks. Yes this means that the above checks for "Private } # { Internets" as Source Address checks are not strictly necessary. } # # Disallow all Source Addresses (outbound) ipfw addf deny all from 0/0 to 0/0 via 206.55.64.17 # Allow SOLNET-BLK-1 (outbound) ipfw addf accept all from 206.55.64.0/20 to 0/0 via 206.55.64.17 # Allow INCNET-172 (outbound) ipfw addf accept all from 204.95.172.0/24 to 0/0 via 206.55.64.17 # Allow INCNET-219 (outbound) ipfw addf accept all from 204.95.219.0/24 to 0/0 via 206.55.64.17 What have I forgotten, if anything? :-) ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-current Thu Feb 29 12:35:25 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA05442 for current-outgoing; Thu, 29 Feb 1996 12:35:25 -0800 (PST) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA05437 for ; Thu, 29 Feb 1996 12:35:22 -0800 (PST) Received: from localhost.shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.4/8.7.3) with SMTP id LAA01108; Thu, 29 Feb 1996 11:14:44 -0800 (PST) Message-Id: <199602291914.LAA01108@precipice.shockwave.com> To: Paul Richards cc: olah@cs.utwente.nl, current@FreeBSD.ORG Subject: Re: Processing ICMP packets (was: -stable hangs at boot (fwd)) In-reply-to: Your message of "Thu, 29 Feb 1996 18:59:15 GMT." <199602291859.SAA17390@tees> Date: Thu, 29 Feb 1996 11:14:43 -0800 From: Paul Traina Sender: owner-current@FreeBSD.ORG Precedence: bulk From: Paul Richards Subject: Re: Processing ICMP packets (was: -stable hangs at boot (fwd)) Trouble is, if you're a paranoid firewall maintainer, like most are (and shou be), then you don't want to tell the world that you're a firewall and you're denying access, you want to say, there's no such address as the one you're trying so stop wasting your time. (a) this belongs on security, not current (b) if someone doesn't LIKE the standard, they have the source code (c) one could debate whether the IETF made the correct choice or not until the cows come home. that's not the issue here. the issue is how we respond to one of these messages. we should treat them as an unreachable whether we like it or not, because it is an unreachable. From owner-freebsd-current Thu Feb 29 12:40:21 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA05863 for current-outgoing; Thu, 29 Feb 1996 12:40:21 -0800 (PST) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA05853 Thu, 29 Feb 1996 12:40:13 -0800 (PST) Received: from localhost.shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.4/8.7.3) with SMTP id MAA00408; Thu, 29 Feb 1996 12:38:13 -0800 (PST) Message-Id: <199602292038.MAA00408@precipice.shockwave.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Joe Greco cc: phk@critter.tfs.com (Poul-Henning Kamp), stable@freebsd.org, current@freebsd.org Subject: Re: IPFW (was: Re: -stable hangs at boot) In-reply-to: Your message of "Thu, 29 Feb 1996 11:31:52 CST." <199602291731.LAA04770@brasil.moneng.mei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 Feb 1996 12:38:13 -0800 From: Paul Traina Sender: owner-current@freebsd.org Precedence: bulk Obligatory comment: 1597 space should *NEVER* be considered "more secure." The only difference between 1597 space and non-1597 space is that 1597 space is not guaranteed to be unique across the internet. I can still get my packets through to (and often received from) a 1597 based machine. From owner-freebsd-current Thu Feb 29 12:51:25 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA06972 for current-outgoing; Thu, 29 Feb 1996 12:51:25 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA06967 Thu, 29 Feb 1996 12:51:22 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id OAA06496; Thu, 29 Feb 1996 14:50:08 -0600 From: Joe Greco Message-Id: <199602292050.OAA06496@brasil.moneng.mei.com> Subject: Re: IPFW (was: Re: -stable hangs at boot) To: pst@shockwave.com (Paul Traina) Date: Thu, 29 Feb 1996 14:50:07 -0600 (CST) Cc: jgreco@brasil.moneng.mei.com, phk@critter.tfs.com, stable@freebsd.org, current@freebsd.org In-Reply-To: <199602292038.MAA00408@precipice.shockwave.com> from "Paul Traina" at Feb 29, 96 12:38:13 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org Precedence: bulk > Obligatory comment: > > 1597 space should *NEVER* be considered "more secure." > > The only difference between 1597 space and non-1597 space is that 1597 space > is not guaranteed to be unique across the internet. > > I can still get my packets through to (and often received from) a 1597 based > machine. Of course that is true. However, it IS inherently more difficult for you to get a packet routed to a 1597 network that is local, here, because there aren't any routes to help you, and in my opinion that does count as being "more secure". I am BY NO MEANS advocating the use of 1597 networks instead of firewalls and other traditional security tools. Paranoia and politics simply suggests that a 1597 network is yet another tool that helps keep trouble away. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-current Thu Feb 29 12:59:59 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA07657 for current-outgoing; Thu, 29 Feb 1996 12:59:59 -0800 (PST) Received: from sirius.ctr.columbia.edu (root@sirius.ctr.columbia.edu [128.59.64.60]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA07650 for ; Thu, 29 Feb 1996 12:59:51 -0800 (PST) Received: from startide.ctr.columbia.edu (wpaul@startide.ctr.columbia.edu [128.59.64.52]) by sirius.ctr.columbia.edu (8.7.4/8.6.4.287) with ESMTP id PAA27350; Thu, 29 Feb 1996 15:59:44 -0500 (EST) From: wpaul@ctr.columbia.edu (Bill Paul) Received: (wpaul@localhost) by startide.ctr.columbia.edu (8.7.4/8.6.4.788743) id PAA08014; Thu, 29 Feb 1996 15:52:57 -0500 (EST) Message-Id: <199602292052.PAA08014@startide.ctr.columbia.edu> Subject: Re: ypserv: ypproc_master To: adam@veda.is (Adam David) Date: Thu, 29 Feb 1996 15:52:57 -0500 (EST) Cc: current@freebsd.org In-Reply-To: <199602291945.TAA11702@veda.is> from "Adam David" at Feb 29, 96 07:45:40 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk Of all the gin joints in all the towns in all the world, Adam David had to walk into mine and say: > Currently, ypserv dumps core while replying to a ypproc_master request if > access is being denied to the remote host. This results from xdr_string() > not being designed to handle NULL strings. There seem to be vestiges of an > attempt to represent a NULL string by a size of -1, but this could be my > imagination. Looks like ypserv and rpc.yppasswdd need to adjusted to the > limitations of xdr. Hmm. Odd: I can't seem to trip the bug on my development box. Even so, you're probably right about the NULL (or in this case, uninitialized) string. If you would be so kind as to try the following patch on yp_server.c and let me know if it cures the SEGV, I would be very greatful: *** 1.3 1996/02/26 02:23:39 --- yp_server.c 1996/02/29 19:57:12 *************** *** 532,537 **** --- 532,539 ---- static ypresp_master result; DBT key,data; + result.peer = ""; + if (yp_access(NULL, (struct svc_req *)rqstp)) { result.stat = YP_YPERR; return(&result); Initializing the 'peer' member of the result to an empty string should be enough to pacify the XDR filters. As for rpc.yppasswdd, I'm not sure the problem is the same: the yppasswdproc_update procedure is supposed to return only a single integer as a response code, and this integer is initialized right at the start of the handler routine (it's set to return failure by default -- if the routine completes without errors, it's changed to success before returning). Thanks for testing the new ypserv, by the way. :) -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= License error: The license for this .sig file has expired. You must obtain a new license key before any more witty phrases will appear in this space. ============================================================================= From owner-freebsd-current Thu Feb 29 13:50:52 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA12765 for current-outgoing; Thu, 29 Feb 1996 13:50:52 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA12754 for ; Thu, 29 Feb 1996 13:50:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id NAA04516 for ; Thu, 29 Feb 1996 13:49:36 -0800 (PST) To: current@freebsd.org Subject: libdisk Date: Thu, 29 Feb 1996 13:49:36 -0800 Message-ID: <4514.825630576@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org Precedence: bulk As much as I've often wanted to point the finger at this library from time to time, I have to say that most bugs have generally been in my own code and the library itself is pretty robust. OK, so no one but phk can actually understand the code, but that's a small point. I'm thinking that in order to become a more general-purpose "slice abstraction" feature for us, libdisk needs to move out of the /usr/src/release hierarchy and take its rightful place amongst the other system libraries. It doesn't _just_ have to be for sysinstall, and I think that perhaps if it weren't so buried, the other disk frobulating utilities could take advantage of it. Comments? Jordan From owner-freebsd-current Thu Feb 29 14:49:46 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.FreeBSD.org (8.7.3/8.7.3) id OAA15901 for current-outgoing; Thu, 29 Feb 1996 14:49:46 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA15818 for ; Thu, 29 Feb 1996 14:47:44 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tsH81-0003xmC; Thu, 29 Feb 96 14:47 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id XAA00481; Thu, 29 Feb 1996 23:47:12 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: "Jordan K. Hubbard" cc: current@FreeBSD.ORG Subject: Re: libdisk In-reply-to: Your message of "Thu, 29 Feb 1996 13:49:36 PST." <4514.825630576@time.cdrom.com> Date: Thu, 29 Feb 1996 23:47:08 +0100 Message-ID: <479.825634028@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.ORG Precedence: bulk > As much as I've often wanted to point the finger at this library from > time to time, I have to say that most bugs have generally been in my > own code and the library itself is pretty robust. Does that mean I can take this silly hat of again ? <:-) -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Thu Feb 29 14:59:21 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA16537 for current-outgoing; Thu, 29 Feb 1996 14:59:21 -0800 (PST) Received: from veda.is (veda.is [193.4.230.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id OAA16203 for ; Thu, 29 Feb 1996 14:53:59 -0800 (PST) Received: (from adam@localhost) by veda.is (8.7.4/8.7.3) id WAA03149; Thu, 29 Feb 1996 22:41:32 GMT From: Adam David Message-Id: <199602292241.WAA03149@veda.is> Subject: Re: ypserv: ypproc_master To: wpaul@ctr.columbia.edu (Bill Paul) Date: Thu, 29 Feb 1996 22:41:29 +0000 (GMT) Cc: current@freebsd.org In-Reply-To: <199602292052.PAA08014@startide.ctr.columbia.edu> from Bill Paul at "Feb 29, 96 03:52:57 pm" X-Mailer: ELM [version 2.4ME+ PL10 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk > Hmm. Odd: I can't seem to trip the bug on my development box. Even so, > you're probably right about the NULL (or in this case, uninitialized) > string. It only shows up when yp_access() denies access, or if some other error occurs before the master server name is determined. > *** 1.3 1996/02/26 02:23:39 > --- yp_server.c 1996/02/29 19:57:12 > *************** > *** 532,537 **** > --- 532,539 ---- > static ypresp_master result; > DBT key,data; > > + result.peer = ""; > + > Initializing the 'peer' member of the result to an empty string should > be enough to pacify the XDR filters. Yes, it cures the SEGV. In rpc.yppasswdd however, ypxfr_get_master() frees the string sent in response, so it would seem better to have sent a malloc'd string in the first place. -- Adam David From owner-freebsd-current Thu Feb 29 15:43:29 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA20271 for current-outgoing; Thu, 29 Feb 1996 15:43:29 -0800 (PST) Received: from snake.hut.fi (root@[193.167.6.99]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id PAA20253 for ; Thu, 29 Feb 1996 15:43:16 -0800 (PST) Received: from lk-hp-20.hut.fi (lk-hp-20.hut.fi [130.233.247.33]) by snake.hut.fi (8.7.3/8.7.3) with ESMTP id BAA29555 for ; Fri, 1 Mar 1996 01:42:13 +0200 (EET) From: Juha Inkari Received: (inkari@localhost) by lk-hp-20.hut.fi (8.6.12/8.6.7) id BAA03741 for freebsd-current@freebsd.org; Fri, 1 Mar 1996 01:42:12 +0200 Message-Id: <199602292342.BAA03741@lk-hp-20.hut.fi> Subject: rename panics To: freebsd-current@freebsd.org Date: Fri, 1 Mar 1996 01:42:11 +5000 (EET) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk Resently I got a "panic : vrele : negative reference count". The vrele() was called from rename(). I tried a simple script to exercise rename (attached below) and a current system seems to panic (trapped in ufs_rename). There's a race condition lurking, it seems. I havent tried other than the sticky /tmp directory as the source and target files parent directory. Also the test was run under root's account, if it matters. Rename exercise: ------ #!/bin/sh a=/tmp/foo.now b=/tmp/foo.prev while true do for n in 1 2 3 4 5 6 7 8 9 0 do (mv $a $b ; touch $a) & done wait done ------ From owner-freebsd-current Thu Feb 29 15:45:51 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA20557 for current-outgoing; Thu, 29 Feb 1996 15:45:51 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA15818 for ; Thu, 29 Feb 1996 14:47:44 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tsH81-0003xmC; Thu, 29 Feb 96 14:47 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id XAA00481; Thu, 29 Feb 1996 23:47:12 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: "Jordan K. Hubbard" cc: current@FreeBSD.ORG Subject: Re: libdisk In-reply-to: Your message of "Thu, 29 Feb 1996 13:49:36 PST." <4514.825630576@time.cdrom.com> Date: Thu, 29 Feb 1996 23:47:08 +0100 Message-ID: <479.825634028@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@FreeBSD.ORG Precedence: bulk > As much as I've often wanted to point the finger at this library from > time to time, I have to say that most bugs have generally been in my > own code and the library itself is pretty robust. Does that mean I can take this silly hat of again ? <:-) -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Thu Feb 29 16:20:41 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA23310 for current-outgoing; Thu, 29 Feb 1996 16:20:41 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA15818 for ; Thu, 29 Feb 1996 14:47:44 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tsH81-0003xmC; Thu, 29 Feb 96 14:47 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id XAA00481; Thu, 29 Feb 1996 23:47:12 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: "Jordan K. Hubbard" cc: current@freebsd.org Subject: Re: libdisk In-reply-to: Your message of "Thu, 29 Feb 1996 13:49:36 PST." <4514.825630576@time.cdrom.com> Date: Thu, 29 Feb 1996 23:47:08 +0100 Message-ID: <479.825634028@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org Precedence: bulk > As much as I've often wanted to point the finger at this library from > time to time, I have to say that most bugs have generally been in my > own code and the library itself is pretty robust. Does that mean I can take this silly hat of again ? <:-) -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Thu Feb 29 17:11:01 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA26973 for current-outgoing; Thu, 29 Feb 1996 17:11:01 -0800 (PST) Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA26927 for ; Thu, 29 Feb 1996 17:10:29 -0800 (PST) Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD4.4) id MAA21826; Fri, 1 Mar 1996 12:09:32 +1100 From: michael butler Message-Id: <199603010109.MAA21826@asstdc.scgt.oz.au> Subject: Re: Processing ICMP packets (was: -stable hangs at boot (fwd)) To: pst@shockwave.com (Paul Traina) Date: Fri, 1 Mar 1996 12:09:31 +1100 (EST) Cc: current@freebsd.org In-Reply-To: <199602291801.KAA00600@precipice.shockwave.com> from "Paul Traina" at Feb 29, 96 10:01:21 am X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk Paul Traina writes: > Just so long as you don't wind up triggering the old 4.2 TCP bug. > Namely, when a port is unreachible, then *ALL* connections to that host > are discarded. It is safer to silently discard packets in a packet > filter than to send back ICMP messages since it won't trigger these bugs > and will be treateed as if it was lost and retransmitted or timed out. Just FYI .. Interactive SVR3.2 version 4.1, the current release - although I haven't tested the last maintenance update, _still_ has this problem rendering sendmail incapable of receiving mail from hosts whose identd port is unreachable :-( SunSoft's tardiness about fixing this (and more than a few other things) was a major reason why I switched to FreeBSD .. it works, michael From owner-freebsd-current Thu Feb 29 18:00:44 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA00208 for current-outgoing; Thu, 29 Feb 1996 18:00:44 -0800 (PST) Received: from veda.is (veda.is [193.4.230.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id SAA00196 for ; Thu, 29 Feb 1996 18:00:19 -0800 (PST) Received: (from adam@localhost) by veda.is (8.7.4/8.7.3) id BAA08622 for freebsd-current@freebsd.org; Fri, 1 Mar 1996 01:59:30 GMT From: Adam David Message-Id: <199603010159.BAA08622@veda.is> Subject: /etc/netstart and NFS /usr To: freebsd-current@freebsd.org Date: Fri, 1 Mar 1996 01:59:28 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL10 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk Quoting from /etc/netstart: # XXX This is known to cause an error if /usr is nfs mounted since it # will not be available until after the network is up :-(. Once the # relocation of sysctl to /sbin is done that problem will go away. This comment has been there for a long time. Does it mean that sysctl is destined for /sbin (and overdue for the move), or should it be independently copied there on hosts which have /usr mounted by NFS? There is a similar problem with routed(8) if it is used. -- Adam David From owner-freebsd-current Fri Mar 1 02:11:36 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA01754 for current-outgoing; Fri, 1 Mar 1996 02:11:36 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA01749 for ; Fri, 1 Mar 1996 02:11:33 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tsRoB-0003vrC; Fri, 1 Mar 96 02:11 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id LAA02197; Fri, 1 Mar 1996 11:11:17 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: Adam David cc: freebsd-current@freebsd.org Subject: Re: /etc/netstart and NFS /usr In-reply-to: Your message of "Fri, 01 Mar 1996 01:59:28 GMT." <199603010159.BAA08622@veda.is> Date: Fri, 01 Mar 1996 11:11:16 +0100 Message-ID: <2195.825675076@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org Precedence: bulk > Quoting from /etc/netstart: > > # XXX This is known to cause an error if /usr is nfs mounted since it > # will not be available until after the network is up :-(. Once the > # relocation of sysctl to /sbin is done that problem will go away. > > This comment has been there for a long time. Does it mean that sysctl is > destined for /sbin (and overdue for the move), or should it be independently > copied there on hosts which have /usr mounted by NFS? > > There is a similar problem with routed(8) if it is used. at least sysctl should probably be moved yes. Herr CVS-meister ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-current Fri Mar 1 04:06:26 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA07672 for current-outgoing; Fri, 1 Mar 1996 04:06:26 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA07662 for ; Fri, 1 Mar 1996 04:06:10 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id WAA11048; Fri, 1 Mar 1996 22:49:53 +1100 Date: Fri, 1 Mar 1996 22:49:53 +1100 From: Bruce Evans Message-Id: <199603011149.WAA11048@godzilla.zeta.org.au> To: adam@veda.is, phk@critter.tfs.com Subject: Re: /etc/netstart and NFS /usr Cc: freebsd-current@FreeBSD.ORG Sender: owner-current@FreeBSD.ORG Precedence: bulk >at least sysctl should probably be moved yes. >Herr CVS-meister ? Just move the binary. Bruce From owner-freebsd-current Fri Mar 1 05:36:56 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA11199 for current-outgoing; Fri, 1 Mar 1996 05:36:56 -0800 (PST) Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id FAA11179 Fri, 1 Mar 1996 05:36:30 -0800 (PST) Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id OAA14542 ; Fri, 1 Mar 1996 14:35:43 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id OAA21683 ; Fri, 1 Mar 1996 14:35:42 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7.3/keltia-uucp-2.7) id NAA11058; Fri, 1 Mar 1996 13:14:36 +0100 (MET) From: Ollivier Robert Message-Id: <199603011214.NAA11058@keltia.freenix.fr> Subject: Re: IPFW (was: Re: -stable hangs at boot) To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Fri, 1 Mar 1996 13:14:36 +0100 (MET) Cc: jgreco@brasil.moneng.mei.com, fenner@parc.xerox.com, nate@sri.MT.net, stable@freebsd.org, current@freebsd.org In-Reply-To: <2612.825584015@critter.tfs.com> from Poul-Henning Kamp at "Feb 29, 96 09:53:35 am" X-Operating-System: FreeBSD 2.2-CURRENT ctm#1688 X-Mailer: ELM [version 2.4ME+ PL10 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk It seems that Poul-Henning Kamp said: > And if you're on a lousy ISP, also a filter to block all of the "private" > networks, 192.168.x.x and so on, (RFC 1596 ?) It is RFC-1918 now. It supersedes both 1597 and 1620. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #1: Tue Feb 20 01:16:51 MET 1996 From owner-freebsd-current Fri Mar 1 06:16:47 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA12871 for current-outgoing; Fri, 1 Mar 1996 06:16:47 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA12866 for ; Fri, 1 Mar 1996 06:16:44 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id BAA17568 for current@freebsd.org; Sat, 2 Mar 1996 01:12:14 +1100 Date: Sat, 2 Mar 1996 01:12:14 +1100 From: Bruce Evans Message-Id: <199603011412.BAA17568@godzilla.zeta.org.au> To: current@freebsd.org Subject: clock going backwards on Pentiums Sender: owner-current@freebsd.org Precedence: bulk Clock interrupts are sometimes blocked for a very long time. On Pentiums all clock interrupt latency causes anomalous results from microtime(), e.g., times going backwards. Blocking clock interrupts for longer than one clock tick causes the clock to run slow on all machines. I just got the following log messages when I started up `cvs co src' on a P133: mi_switch: negative time: -88501 usec current = 825686718.054236, microtime = 825686718.054234, runtime = 825686718.142735, rtime = 0.326348 mi_switch: negative time: -55619 usec current = 825686809.271253, microtime = 825686809.271250, runtime = 825686809.326869, rtime = 0.0 calcru: negative time: -42726 usec current = 825686809.409137, microtime = 825686809.409134, runtime = 825686809.408070, rtime = -1.956210 `runtime' somehow got 88501 usec ahead of the current time. This can happen if 8 or 9 clock interrupts are missed, e.g. for the following sequence of events: 1) all initially clocks correct. 2) s = splhigh(). 3) don't lower ipl for 9 clock ticks. 4) microtime(&runtime) stores the correct time into `runtime'. 5) splx(s). 6) clock interrupt occurs. Synchronizing between the Pentium clock and the scheduling clock in effect forgets between 8 and 9 clock ticks. On non- Pentiums they've already been forgotten and the time in 4) was wrong. 7) microtime(&tv) gives a time between 8 and 9 clock ticks before `runtime'. I don't know of any other ways that it can happen. I'm also measuring the clock interrupt latency directly but wasn't logging it when the above occurred. The maximum measured latency is currently 9624 usec. However, the measuring method only works for latencies of less than 10000 usec. I sometimes run an lkm to measure timeout latency. Timeout latencies in the 2000-5000 usec range are quite common. This isn't surprising but isnt very good. How did 1980's machines that were 50-500 times slower finish anything? :-) Bruce From owner-freebsd-current Fri Mar 1 06:21:42 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA13138 for current-outgoing; Fri, 1 Mar 1996 06:21:42 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA13130 for ; Fri, 1 Mar 1996 06:21:39 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id BAA17909; Sat, 2 Mar 1996 01:19:51 +1100 Date: Sat, 2 Mar 1996 01:19:51 +1100 From: Bruce Evans Message-Id: <199603011419.BAA17909@godzilla.zeta.org.au> To: current@FreeBSD.org, jkh@time.cdrom.com Subject: Re: pstat: cannot read swaplist: kvm_read: Bad address Sender: owner-current@FreeBSD.org Precedence: bulk >I now get this for pstat all the time, and I've recompiled all the >libs it depends on. The problem seems to be that /dev/kmem isn't all readable. Only the resident parts of it are. This is enforced by the following code in the memory driver: /* * Make sure that all of the pages are currently resident so * that we don't create any zero-fill pages. */ addr = trunc_page(uio->uio_offset); eaddr = round_page(uio->uio_offset + c); for (; addr < eaddr; addr += PAGE_SIZE) if (pmap_extract(kernel_pmap, addr) == 0) return EFAULT; The pages that I looked at could be read from kmem after I looked at them using ddb. The ones for the swap list seemed to be normal under ddb. Apparently looking at them right faults them in. Bruce From owner-freebsd-current Fri Mar 1 06:57:12 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA15996 for current-outgoing; Fri, 1 Mar 1996 06:57:12 -0800 (PST) Received: from cabri.obs-besancon.fr (cabri.obs-besancon.fr [193.52.184.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA15988 for ; Fri, 1 Mar 1996 06:57:06 -0800 (PST) Received: by cabri.obs-besancon.fr (5.57/Ultrix3.0-C) id AA23075; Fri, 1 Mar 96 15:58:39 +0100 Date: Fri, 1 Mar 96 15:58:39 +0100 Message-Id: <9603011458.AA23075@cabri.obs-besancon.fr> From: Jean-Marc Zucconi To: current@freebsd.org Subject: aha0: Invalid bus phase/sequence X-Mailer: Emacs Sender: owner-current@freebsd.org Precedence: bulk Hi, I get the following error when trying to dump my disks on tape: Mar 1 14:33:59 qix /kernel: aha0: Invalid bus phase/sequence Mar 1 14:34:05 qix /kernel: st0(aha0:4:0): UNIT ATTENTION asc:29,0 Mar 1 14:34:05 qix /kernel: st0(aha0:4:0): Power on, reset, or bus device reset occurred Mar 1 14:34:05 qix /kernel: st0: oops not queued Mar 1 14:34:05 qix /kernel: st0(aha0:4:0): NOT READY asc:4,0 Mar 1 14:34:05 qix /kernel: st0(aha0:4:0): Logical unit not ready, cause not reportable The problem occur after about 1 hour of operation. The tape drive is the only device connected to the adaptec: Feb 29 02:57:05 qix /kernel: aha0 at 0x330-0x333 irq 11 drq 5 on isa Feb 29 02:57:05 qix /kernel: (aha0:4:0): "SONY SDT-5000 3.02" type 1 removable SCSI 2 Feb 29 02:57:05 qix /kernel: st0(aha0:4:0): Sequential-Access density code 0x13, drive empty Any idea? Jean-Marc _____________________________________________________________________________ Jean-Marc Zucconi Observatoire de Besancon F 25010 Besancon cedex PGP Key: finger jmz@cabri.obs-besancon.fr ============================================================================= From owner-freebsd-current Fri Mar 1 07:28:49 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA20093 for current-outgoing; Fri, 1 Mar 1996 07:28:49 -0800 (PST) Received: from s1.GANet.NET (s1.GANet.NET [199.18.201.2]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA20086 for ; Fri, 1 Mar 1996 07:28:46 -0800 (PST) Received: (from ec0@localhost) by s1.GANet.NET (8.6.11/8.6.11) id KAA24995; Fri, 1 Mar 1996 10:27:30 -0500 Date: Fri, 1 Mar 1996 10:27:29 -0500 (EST) From: Eric Chet To: "Jordan K. Hubbard" cc: current@FreeBSD.org Subject: Re: pstat: cannot read swaplist: kvm_read: Bad address In-Reply-To: <199602291942.LAA03838@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.org Precedence: bulk On Thu, 29 Feb 1996, Jordan K. Hubbard wrote: > I now get this for pstat all the time, and I've recompiled all the > libs it depends on. > > Anyone seeing the same thing? > > Jordan > Hello I supped Thursday night, made the world and kernel. Everything seems to be working okay here with top, pstat and vmstat. Peace, Eric ejc@nasvr1.cb.att.com ec0@ganet.net From owner-freebsd-current Fri Mar 1 12:08:52 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA05722 for current-outgoing; Fri, 1 Mar 1996 12:08:52 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA05716 for ; Fri, 1 Mar 1996 12:08:50 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tsb8C-0003xvC; Fri, 1 Mar 96 12:08 PST Received: from localhost.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.6.12/8.6.12) with SMTP id VAA03711 for ; Fri, 1 Mar 1996 21:08:47 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost.tfs.com didn't use HELO protocol To: current@freebsd.org Subject: kernel-ppp any good ? Date: Fri, 01 Mar 1996 21:08:45 +0100 Message-ID: <3709.825710925@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org Precedence: bulk Is anybody running the kernel-ppp in -current ? Should the new version be put in -stable too ? Poul-Henning From owner-freebsd-current Fri Mar 1 12:18:53 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA06256 for current-outgoing; Fri, 1 Mar 1996 12:18:53 -0800 (PST) Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA06250 for ; Fri, 1 Mar 1996 12:18:39 -0800 (PST) Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.6.12/8.6.9) id WAA17044 for freebsd-current@FreeBSD.ORG; Fri, 1 Mar 1996 22:17:58 +0200 From: John Hay Message-Id: <199603012017.WAA17044@zibbi.mikom.csir.co.za> Subject: Re: rename panics kernel To: freebsd-current@FreeBSD.ORG (FreeBSD-current) Date: Fri, 1 Mar 1996 22:17:58 +0200 (SAT) In-Reply-To: X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG Precedence: bulk > Resently I got a "panic : vrele : negative reference count". > The vrele() was called from rename(). > > I tried a simple script to exercise rename (attached below) and a > current system seems to panic (trapped in ufs_rename). There's a race > condition lurking, it seems. I havent tried other than the sticky /tmp > directory as the source and target files parent directory. Also the > test was run under root's account, if it matters. > > Rename exercise: > ------ > #!/bin/sh > a=/tmp/foo.now > b=/tmp/foo.prev > while true > do > for n in 1 2 3 4 5 6 7 8 9 0 > do > (mv $a $b ; touch $a) & > done > wait > done > ------ > Well I tried this on a -stable machine and one with -current. Both did panic. :-( The -current kernel is a week old. Here is its panic message: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x68 fault code = supervisor read, page not present instruction pointer = 0x8:0xf015ffb9 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 = 341 (mv) interrupt mask = panic: page fault f015feb4 t _ufs_chown f015ff78 T _ufs_ioctl f015ff84 T _ufs_select f015ff90 T _ufs_mmap f015ff9c T _ufs_seek f015ffa4 T _ufs_remove f0160028 T _ufs_link f01602b8 T _ufs_rename f0160cf8 T _ufs_mkdir f0160f70 T _ufs_rmdir f01610cc T _ufs_symlink John --- John Hay -- John.Hay@csir.co.za From owner-freebsd-current Fri Mar 1 13:21:13 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA10411 for current-outgoing; Fri, 1 Mar 1996 13:21:13 -0800 (PST) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA10402 for ; Fri, 1 Mar 1996 13:21:08 -0800 (PST) Received: from localhost.shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.4/8.7.3) with SMTP id NAA24288; Fri, 1 Mar 1996 13:19:49 -0800 (PST) Message-Id: <199603012119.NAA24288@precipice.shockwave.com> To: Poul-Henning Kamp cc: Adam David , freebsd-current@FreeBSD.org Subject: Re: /etc/netstart and NFS /usr In-reply-to: Your message of "Fri, 01 Mar 1996 11:11:16 +0100." <2195.825675076@critter.tfs.com> Date: Fri, 01 Mar 1996 13:19:46 -0800 From: Paul Traina Sender: owner-current@FreeBSD.org Precedence: bulk routed doesn't need to be moved because rdisc is already in /sbin. However, I had a "interesting" problem last night, and found that having a standalone version of "mt(1)" very very very important (thank god for /stand). If we're moving binaries, I'd suggest moving mt up too. From: Poul-Henning Kamp Subject: Re: /etc/netstart and NFS /usr > Quoting from /etc/netstart: > > # XXX This is known to cause an error if /usr is nfs mounted since it > # will not be available until after the network is up :-(. Once the > # relocation of sysctl to /sbin is done that problem will go away. > > This comment has been there for a long time. Does it mean that sysctl is > destined for /sbin (and overdue for the move), or should it be independentl >>y > copied there on hosts which have /usr mounted by NFS? > > There is a similar problem with routed(8) if it is used. at least sysctl should probably be moved yes. Herr CVS-meister ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, In >>c. Future will arrive by its own means, progress not so. From owner-freebsd-current Fri Mar 1 14:33:12 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA15189 for current-outgoing; Fri, 1 Mar 1996 14:33:12 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA15180 for ; Fri, 1 Mar 1996 14:33:07 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id PAA16038; Fri, 1 Mar 1996 15:35:21 -0700 Date: Fri, 1 Mar 1996 15:35:21 -0700 From: Nate Williams Message-Id: <199603012235.PAA16038@rocky.sri.MT.net> To: Poul-Henning Kamp Cc: current@freebsd.org Subject: Re: kernel-ppp any good ? In-Reply-To: <3709.825710925@critter.tfs.com> References: <3709.825710925@critter.tfs.com> Sender: owner-current@freebsd.org Precedence: bulk > Is anybody running the kernel-ppp in -current ? > > Should the new version be put in -stable too ? That is already something Peter was planning on doing, so I would talk to him before doing it. Nate From owner-freebsd-current Fri Mar 1 15:43:12 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA19502 for current-outgoing; Fri, 1 Mar 1996 15:43:12 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA19497 for ; Fri, 1 Mar 1996 15:43:10 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA21796; Fri, 1 Mar 1996 16:34:55 -0700 From: Terry Lambert Message-Id: <199603012334.QAA21796@phaeton.artisoft.com> Subject: Re: rename panics kernel To: jhay@mikom.csir.co.za (John Hay) Date: Fri, 1 Mar 1996 16:34:55 -0700 (MST) Cc: freebsd-current@FreeBSD.org In-Reply-To: <199603012017.WAA17044@zibbi.mikom.csir.co.za> from "John Hay" at Mar 1, 96 10:17:58 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org Precedence: bulk > > Resently I got a "panic : vrele : negative reference count". > > The vrele() was called from rename(). > > > > I tried a simple script to exercise rename (attached below) and a > > current system seems to panic (trapped in ufs_rename). There's a race > > condition lurking, it seems. I havent tried other than the sticky /tmp > > directory as the source and target files parent directory. Also the > > test was run under root's account, if it matters. > > > > Rename exercise: > > ------ > > #!/bin/sh > > a=/tmp/foo.now > > b=/tmp/foo.prev > > while true > > do > > for n in 1 2 3 4 5 6 7 8 9 0 > > do > > (mv $a $b ; touch $a) & > > done > > wait > > done > > ------ > > Well I tried this on a -stable machine and one with -current. Both did > panic. :-( The -current kernel is a week old. Here is its panic message: > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x68 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xf015ffb9 > 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 = 341 (mv) > interrupt mask = > panic: page fault > > f015feb4 t _ufs_chown > f015ff78 T _ufs_ioctl > f015ff84 T _ufs_select > f015ff90 T _ufs_mmap > f015ff9c T _ufs_seek > f015ffa4 T _ufs_remove > f0160028 T _ufs_link > f01602b8 T _ufs_rename > f0160cf8 T _ufs_mkdir > f0160f70 T _ufs_rmdir > f01610cc T _ufs_symlink Tee Hee Hee. I tried this on -current and my box panic'ed too. Then I installed my FS patches and tried it again. No panic... did get bored watching the messages scroll by, though. 8-) 8-) 8-) 8-) 8-) 8-) 8-) 8-) 8-) 8-) 8-) 8-) 8-) 8-) 8-) 8-) The fix is a side effect of my reordering for single-entry/single-exit and the semantic changes for the: /* * Fall through causes potentially bogus * semantic override. Test cases are: * * mkdir foo ; cd foo * mv . . * mv . .. * mv .. . * mv .. .. */ case. Here is my rename from my /sys/kern/vfs_syscalls.c (note: it won't work without the nameifree() changes; fix by deintegrating them to assume that the underlying FS is freeing the path buffer for you (ie: comment them out). This file is integrated with -current as of 29 Feb 96. Told you I fixed some race conditions. 8-P. ========================================================================= /* * Rename files. Source and destination must either both be directories, * or both not be directories. If target is a directory, it must be empty. * * XXX this code is broken (or is at the very least non-POSIX). See the * XXX semantic notes below. */ #ifndef _SYS_SYSPROTO_H_ struct rename_args { char *from; char *to; }; #endif /* ARGSUSED */ int rename(p, uap, retval) struct proc *p; register struct rename_args *uap; int *retval; { register struct vnode *tvp, *fvp, *tdvp; struct nameidata fromnd, tond; int error; NDINIT(&fromnd, DELETE, WANTPARENT | SAVESTART, UIO_USERSPACE, uap->from, p); if( !(error = namei(&fromnd))) { fvp = fromnd.ni_vp; NDINIT(&tond, RENAME, LOCKPARENT | LOCKLEAF | NOCACHE | SAVESTART, UIO_USERSPACE, uap->to, p); if (fromnd.ni_vp->v_type == VDIR) tond.ni_cnd.cn_flags |= WILLBEDIR; if( error = namei(&tond)) { /* Translate error code for rename("dir1", "dir2/."). */ if (error == EISDIR && fvp->v_type == VDIR) error = EINVAL; VOP_ABORTOP(fromnd.ni_dvp, &fromnd.ni_cnd); vrele(fromnd.ni_dvp); vrele(fvp); /* fall through to fromdir/path cleanup*/ } else { tdvp = tond.ni_dvp; tvp = tond.ni_vp; if (tvp != NULL) { if (fvp->v_type == VDIR && tvp->v_type != VDIR) { error = ENOTDIR; } else if (fvp->v_type != VDIR && tvp->v_type == VDIR) { error = EISDIR; } } /* * If no directory source/target errors, check * for semantic override for an identical * source and target. */ if( !error) { if (fvp == tdvp) error = EINVAL; /* * Fall through causes potentially bogus * semantic override. Test cases are: * * mkdir foo ; cd foo * mv . . * mv . .. * mv .. . * mv .. .. */ /* * If source is the same as the destination * (that is the same inode number with the * same name in the same directory), then * there is nothing to do. */ if (fvp == tvp && fromnd.ni_dvp == tdvp && fromnd.ni_cnd.cn_namelen == tond.ni_cnd.cn_namelen && !bcmp(fromnd.ni_cnd.cn_nameptr, tond.ni_cnd.cn_nameptr, fromnd.ni_cnd.cn_namelen)) error = -1; } if (!error) { LEASE_CHECK(tdvp, p, p->p_ucred, LEASE_WRITE); if (fromnd.ni_dvp != tdvp) { LEASE_CHECK(fromnd.ni_dvp, p, p->p_ucred, LEASE_WRITE); } if (tvp) { LEASE_CHECK(tvp, p, p->p_ucred, LEASE_WRITE); (void) vnode_pager_uncache(tvp); } error = VOP_RENAME(fromnd.ni_dvp, fromnd.ni_vp, &fromnd.ni_cnd, tond.ni_dvp, tond.ni_vp, &tond.ni_cnd); } else { VOP_ABORTOP(tond.ni_dvp, &tond.ni_cnd); if (tdvp == tvp) vrele(tdvp); else vput(tdvp); if (tvp) vput(tvp); VOP_ABORTOP(fromnd.ni_dvp, &fromnd.ni_cnd); vrele(fromnd.ni_dvp); vrele(fvp); } vrele(tond.ni_startdir); nameifree( &tond); } if (fromnd.ni_startdir) vrele(fromnd.ni_startdir); nameifree( &fromnd); if (error == -1) error = 0; } return (error); } ========================================================================= Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Fri Mar 1 16:07:16 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA21059 for current-outgoing; Fri, 1 Mar 1996 16:07:16 -0800 (PST) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA21054 for ; Fri, 1 Mar 1996 16:07:09 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.6.11/8.6.9) id TAA00720; Fri, 1 Mar 1996 19:02:46 GMT From: "John S. Dyson" Message-Id: <199603011902.TAA00720@dyson.iquest.net> Subject: Re: rename panics kernel To: jhay@mikom.csir.co.za (John Hay) Date: Fri, 1 Mar 1996 19:02:46 +0000 () Cc: freebsd-current@FreeBSD.ORG In-Reply-To: <199603012017.WAA17044@zibbi.mikom.csir.co.za> from "John Hay" at Mar 1, 96 10:17:58 pm X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG Precedence: bulk > > Resently I got a "panic : vrele : negative reference count". > > The vrele() was called from rename(). > > > > I tried a simple script to exercise rename (attached below) and a > > current system seems to panic (trapped in ufs_rename). There's a race > > condition lurking, it seems. I havent tried other than the sticky /tmp > > directory as the source and target files parent directory. Also the > > test was run under root's account, if it matters. > > I'll look at it this weekend (if Davidg or someone else) doesn't get to it first... This one is a real bummer... John From owner-freebsd-current Fri Mar 1 18:11:29 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA27854 for current-outgoing; Fri, 1 Mar 1996 18:11:29 -0800 (PST) Received: from mubo.augusta.de (mubo.augusta.de [193.175.25.25]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id SAA27844 for ; Fri, 1 Mar 1996 18:11:19 -0800 (PST) Received: from rabbit by mubo.augusta.de with uucp (Smail3.1.28.1 #1) id m0tsgms-00017SC; Sat, 2 Mar 96 03:11 MEZ Received: by rabbit.augusta.de (Smail3.1.29.1 #1) id m0tsZYs-0003OoC; Fri, 1 Mar 96 19:28 MET Message-Id: X-Mailer: exmh version 1.6.5 12/11/95 To: freebsd-current@FreeBSD.ORG Subject: What about my Filesystem? Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Fri, 01 Mar 1996 19:28:14 +0100 From: Andreas Kohout Sender: owner-current@FreeBSD.ORG Precedence: bulk Hi, since 2.2-current I have a problem with my fs. If I do a ll / I get this: rabbit:/home/shanee> ll / drwxr-xr-x 8 root wheel 2048 1.Mär.1996 etc/ drwxrwxrwx 2 root wheel 512 24.Dez.1995 floppy/ drwxrwxr-x 6 root wheel 512 19.Jan.1996 home/ -r-xr-xr-x 1 root wheel 1186057 20.Feb.1996 kernel* I think there should be some informations about the time! But sometimes it works: rabbit:/home/shanee> ll /usr drwxr-xr-x 3 bin bin 5632 20.Feb.1996 bin/ drwxr-xr-x 3 root wheel 512 23.Mär. 0:17 data/ The bin/ is eight days old, data/ one year?! rabbit:/home/shanee> date Fr 1 Mär 19:24:39 MET 1996 rabbit:/home/shanee> touch today rabbit:/home/shanee> ll today -rw-r--r-- 1 shanee wheel 0 1.Mär.1996 today I think there is somthing wrong ... maybe only in /etc which is, I think, from 2.0.5 ... I should update it sometimes :-) But may you help me quick, please -- Gruß, Andy -------------------------------------------------------------------------- Der Mensch hat die Atombombe erfunden, eine Maus würde niemals eine Mausefalle bauen! shanee@rabbit.augusta.de Zirbelnußtown __________________________________________________________________________ From owner-freebsd-current Fri Mar 1 19:09:24 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA01031 for current-outgoing; Fri, 1 Mar 1996 19:09:24 -0800 (PST) Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA01024 for ; Fri, 1 Mar 1996 19:09:18 -0800 (PST) Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD4.4) id OAA07840 for current@freebsd.org; Sat, 2 Mar 1996 14:09:14 +1100 From: michael butler Message-Id: <199603020309.OAA07840@asstdc.scgt.oz.au> Subject: Daylight Savings changes .. To: current@freebsd.org Date: Sat, 2 Mar 1996 14:09:13 +1100 (EST) X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk Only through watching the news last night did I discover that Daylight Savings for (at least) New South Wales had changed this year. I wish they'd make up their minds ! As yet, I have no idea what the actual ending date is so I'm taking a guess that the relevant patch to /usr/src/share/zoneinfo/australasia is something like the following but, on a Saturday, it's difficult to find anyone to ring that actually knows :-( *** australasia.save Sat Mar 2 13:56:13 1996 --- australasia Sat Mar 2 14:00:06 1996 *************** *** 125,131 **** Rule AN 1986 1989 - Mar Sun>=15 3:00 0 - Rule AN 1986 only - Oct 19 2:00 1:00 - Rule AN 1987 max - Oct lastSun 2:00 1:00 - ! Rule AN 1990 max - Mar Sun>=1 3:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/Sydney 10:04:52 - LMT 1895 Feb 10:00 - EST 1917 Jan 1 0:01 --- 125,132 ---- Rule AN 1986 1989 - Mar Sun>=15 3:00 0 - Rule AN 1986 only - Oct 19 2:00 1:00 - Rule AN 1987 max - Oct lastSun 2:00 1:00 - ! Rule AN 1990 1995 - Mar Sun>=1 3:00 0 - ! Rule AN 1996 max - Mar lastSun 3:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/Sydney 10:04:52 - LMT 1895 Feb 10:00 - EST 1917 Jan 1 0:01 From owner-freebsd-current Fri Mar 1 20:44:45 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA08549 for current-outgoing; Fri, 1 Mar 1996 20:44:45 -0800 (PST) Received: from freebsd.netcom.com (freebsd.netcom.com [198.211.79.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id UAA08544 for ; Fri, 1 Mar 1996 20:44:43 -0800 (PST) Received: by freebsd.netcom.com (8.6.12/SMI-4.1) id WAA26411; Fri, 1 Mar 1996 22:48:40 -0600 From: bugs@freebsd.netcom.com (Mark Hittinger) Message-Id: <199603020448.WAA26411@freebsd.netcom.com> Subject: Re: rename panics kernel (fwd) To: current@freebsd.org Date: Fri, 1 Mar 1996 22:48:39 -0600 (CST) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-current@freebsd.org Precedence: bulk Would this also come into play on a huge amount of 'rm' activity ala news expire? Regards, Mark Hittinger Netcom/Dallas bugs@freebsd.netcom.com From owner-freebsd-current Sat Mar 2 05:59:44 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA14379 for current-outgoing; Sat, 2 Mar 1996 05:59:44 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA14372 for ; Sat, 2 Mar 1996 05:59:41 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id AAA07828; Sun, 3 Mar 1996 00:51:52 +1100 Date: Sun, 3 Mar 1996 00:51:52 +1100 From: Bruce Evans Message-Id: <199603021351.AAA07828@godzilla.zeta.org.au> To: jhay@mikom.csir.co.za, terry@lambert.org Subject: Re: rename panics kernel Cc: freebsd-current@FreeBSD.ORG Sender: owner-current@FreeBSD.ORG Precedence: bulk >> > Resently I got a "panic : vrele : negative reference count". >> > The vrele() was called from rename(). >> > >> > I tried a simple script to exercise rename (attached below) and a >> > current system seems to panic (trapped in ufs_rename). There's a race >> > ... >Tee Hee Hee. >I tried this on -current and my box panic'ed too. I couldn't duplicate this with my version of -current, but plain -current on an 8MB system gave: panic: vm_fork: u_map allocation failed and after rebooting it paniced in savecore: panic: bremfree: removing a buffer when not on a queue and on a 16MB system the mv script trapped for a null pointer: Stopped at _ufs_remove+0x15: movl 0x68(%ecx),%edi [%ecx = 0; %ecx is ap->a_vp] The fix is a side effect of my reordering for single-entry/single-exit and the semantic changes for the: It must be a side effect of something I've changed too :-). In ufs_rename(), I only changed most of the IN_CHANGE's to IN_MODIFIED. This stops the directory ctimes from being updated for failed renames. I don't think this would affect the bug. Bruce From owner-freebsd-current Sat Mar 2 06:46:44 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA17125 for current-outgoing; Sat, 2 Mar 1996 06:46:44 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA17118 for ; Sat, 2 Mar 1996 06:46:39 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id BAA09381; Sun, 3 Mar 1996 01:41:53 +1100 Date: Sun, 3 Mar 1996 01:41:53 +1100 From: Bruce Evans Message-Id: <199603021441.BAA09381@godzilla.zeta.org.au> To: jhay@mikom.csir.co.za, terry@lambert.org Subject: Re: rename panics kernel Cc: freebsd-current@FreeBSD.ORG Sender: owner-current@FreeBSD.ORG Precedence: bulk >> > Resently I got a "panic : vrele : negative reference count". >> > The vrele() was called from rename(). >> > >> > I tried a simple script to exercise rename (attached below) and a >> > current system seems to panic (trapped in ufs_rename). There's a race I got this to cause problems in all versions of current by waiting a little longer. The console aborts are still broken (bde should fix this :-) The panic in savecore repeats until I run `savecore -c' to clear the core. Bruce Debugger("manual escape to debugger") Stopped at _Debugger+0x2b: movb $0,_in_Debugger.100 db> c panic: vm_fork: u_map allocation failed Debugger("panic") Stopped at _Debugger+0x2b: movb $0,_in_Debugger.100 db> t _Debugger(f01197fa,f01197f8,f01bbc40,efbffee4,f01197f0) at _Debugger+0x2b _panic(f01bbc40,f064fe00,f0687000,efbfff8c,14) at _panic+0x4e _vm_fork(f0687000,f064fe00) at _vm_fork+0x164 _fork1(f0687000,0,0,efbfff8c,efbfffb4) at _fork1+0x3c5 _fork(f0687000,efbfff94,efbfff8c,0,17250) at _fork+0x12 _syscall(efbf0027,efbf0027,1c7d0,17250,efbfd990) at _syscall+0x157 _Xsyscall() at _Xsyscall+0x2d --- syscall 2, eip = 0x8061395, ebp = 0xefbfd990 --- db> ps pid proc addr uid ppid pgrp flag stat wmesg wchan cmd 542 f064fe00 f3533000 15 241 241 000006 1 sh 241 f0687000 f351b000 15 224 241 00c006 2 sh 227 f0687600 f3519000 0 1 227 004082 3 ttyin f02265ec getty 226 f0689b00 f3517000 0 1 226 004082 3 ttyin f0226510 getty 225 f0687500 f34f5000 0 1 225 004082 3 ttyin f0226434 getty 224 f0689c00 f34f3000 15 1 224 004086 3 wait f0689c00 bash 184 f068c300 f3515000 0 1 184 000080 3 accept f0685322 sendmail 180 f0685d00 f3513000 0 1 180 000080 2 cron 173 f066ec00 f3509000 0 1 173 000080 3 select f022752c inetd 172 f066ee00 f3511000 0 1 164 000080 3 nfsidl f0227268 nfsiod 167 f066a200 f350f000 0 1 164 000080 3 nfsidl f022726c nfsiod 166 f066a400 f350d000 0 1 164 000080 3 nfsidl f0227260 nfsiod 165 f066a800 f350b000 0 1 164 000080 3 nfsidl f0227264 nfsiod 162 f066ae00 f3507000 0 157 157 000080 3 nfsd f0653600 nfsd 161 f0666000 f3505000 0 157 157 000080 3 nfsd f0653400 nfsd 160 f0666100 f3503000 0 157 157 000080 3 nfsd f0653800 nfsd 159 f0666a00 f3501000 0 157 157 000080 3 nfsd f0653a00 nfsd 157 f0666800 f34ff000 0 1 157 000080 3 accept f066a722 nfsd 155 f0666e00 f34fd000 0 1 155 000080 3 select f022752c mountd 148 f0664b00 f34fb000 1 1 148 000180 3 select f022752c portmap --More-- 142 f0661400 f34f9000 0 1 142 000084 2 syslogd 22 f063a100 f34f7000 0 1 22 000080 3 pause f34f7148 adjkerntz 4 f0632f00 f34f1000 0 0 0 000604 2 update 3 f061c000 f34ef000 0 0 0 000204 3 psleep f021f3a4 vmdaemon 2 f061c200 f34ed000 0 0 0 000204 3 psleep f0227854 pagedaemon 1 f061c400 f34eb000 0 0 1 004080 3 wait f061c400 init 0 f0236b24 f026f000 0 0 0 000204 2 swapper db> sh r cs 0xefbf0008 ds 0x10 es 0x10 ss 0x10 eax 0x12 ecx 0x3f9 edx 0xf01c8115 _db_write_bytes+0xd9 ebx 0x100 esp 0xefbffeac _kstack+0x1eac ebp 0xefbffeb4 _kstack+0x1eb4 esi 0xf01bbc40 _vsunlock+0x60 edi 0xefbfff8c _kstack+0x1f8c eip 0xf01c8143 _Debugger+0x2b efl 0x246 _Debugger+0x2b: movb $0,_in_Debugger.100 db> c syncing disks... 8 8 6 done dumping to dev 1, offset 50124 dump 7 6 5 4 3 2 1 0 succeeded Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... [reboot] checking for core dump...savecore: reboot after panic: bremfree: removing a buffer when not on a queue savecore: system went down at Sun Mar 3 01:32:04 1996 savecore: writing core to /var/crash/vmcore.0 8192Kpanic: bremfree: removing a buffer when not on a queue Debugger("panic") Stopped at _Debugger+0x2b: movb $0,_in_Debugger.100 db> t _Debugger(f01197fa,f01197f8,f012c881,efbffce8,f01197f0) at _Debugger+0x2b _panic(f012c881,f260b70c,c0004040,efbffd20,f012d678) at _panic+0x4e _bremfree(f260b70c) at _bremfree+0x5e _vfs_bio_awrite(f260b70c,0,80000000,c0004040,efbffd64) at _vfs_bio_awrite+0x120 _getnewbuf(0,0,1,0,f061a000) at _getnewbuf+0x143 _getblk(f0663d80,48,2000,0,0) at _getblk+0x210 _ffs_balloc(f065e100,48,2000,f0618180,efbffeb8) at _ffs_balloc+0x6aa _ffs_write(efbffee0,efbfff94,100000,efbfff94,0) at _ffs_write+0x2cd _vn_write(f065fcc0,efbfff2c,f0618180,efbfff94,f0656500) at _vn_write+0x93 _write(f0656500,efbfff94,efbfff8c,100000,807ed60) at _write+0x97 _syscall(27,27,6,807ed60,efbfde60) at _syscall+0x157 _Xsyscall() at _Xsyscall+0x2d --- syscall 4, eip = 0x8063f95, ebp = 0xefbfde60 --- db> ps pid proc addr uid ppid pgrp flag stat wmesg wchan cmd 138 f0656500 f34f5000 0 5 5 004006 2 savecore 22 f0632000 f34f7000 0 1 22 000084 3 pause f34f7148 adjkerntz 5 f0635900 f34f3000 0 1 5 004086 3 wait f0635900 sh 4 f0632f00 f34f1000 0 0 0 000204 3 update f0237d90 update 3 f061c000 f34ef000 0 0 0 000204 3 psleep f021f3a4 vmdaemon 2 f061c200 f34ed000 0 0 0 000204 3 psleep f0227854 pagedaemon 1 f061c400 f34eb000 0 0 1 004084 3 wait f061c400 init 0 f0236b24 f026f000 0 0 0 000204 3 sched f0236b24 swapper db> sh r cs 0xefbf0008 ds 0x10 es 0x10 ss 0x10 eax 0x12 ecx 0x3f9 edx 0xf01c8115 _db_write_bytes+0xd9 ebx 0x100 esp 0xefbffcb0 _kstack+0x1cb0 ebp 0xefbffcb8 _kstack+0x1cb8 esi 0xf012c881 _bufinit+0x1bd edi 0xf0620c80 eip 0xf01c8143 _Debugger+0x2b efl 0x246 _Debugger+0x2b: movb $0,_in_Debugger.100 db> c syncing disks... panic: bremfree: removing a buffer when not on a queue Debugger("panic") Stopped at _Debugger+0x2b: movb $0,_in_Debugger.100 db> c dumping to dev 1, offset 50124 dump 7 6 5 4 3 2 1 0 succeeded Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... From owner-freebsd-current Sat Mar 2 12:44:57 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA16403 for current-outgoing; Sat, 2 Mar 1996 12:44:57 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA16398 for ; Sat, 2 Mar 1996 12:44:55 -0800 (PST) Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA03142; Sat, 2 Mar 1996 15:44:44 -0500 Date: Sat, 2 Mar 1996 15:44:44 -0500 From: "Garrett A. Wollman" Message-Id: <9603022044.AA03142@halloran-eldar.lcs.mit.edu> To: michael butler Cc: current@freebsd.org Subject: Daylight Savings changes .. In-Reply-To: <199603020309.OAA07840@asstdc.scgt.oz.au> References: <199603020309.OAA07840@asstdc.scgt.oz.au> Sender: owner-current@freebsd.org Precedence: bulk < said: > Only through watching the news last night did I discover that Daylight > Savings for (at least) New South Wales had changed this year. I wish they'd > make up their minds ! This will be fixed soon (along with a lot of other changes in the state of the world's timekeeping) when I import the new timezone data files. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-current Sat Mar 2 13:28:15 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA18629 for current-outgoing; Sat, 2 Mar 1996 13:28:15 -0800 (PST) Received: from cray-ymp.acm.stuorg.vt.edu (root@cray-ymp.acm.stuorg.vt.edu [128.173.43.251]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA18619 for ; Sat, 2 Mar 1996 13:28:05 -0800 (PST) Received: (from kmitch@localhost) by cray-ymp.acm.stuorg.vt.edu (8.6.13/8.6.12) id QAA12577 for current@freebsd.org; Sat, 2 Mar 1996 16:29:30 -0500 From: Keith Mitchell Message-Id: <199603022129.QAA12577@cray-ymp.acm.stuorg.vt.edu> Subject: Sig 11's on current To: current@freebsd.org Date: Sat, 2 Mar 1996 16:29:29 -0500 (EST) Reply-To: kmitch@vt.edu X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk I just compiled current (3/2) (just after some vm changes) and now I get a bunch of SIG 10 and 11's, especially when compiling. -- Keith Mitchell | The real danger is not that computers will Chesapeake/Blacksburg VA | begin to think like men, but that men will kmitch@infi.net | begin to think like computers. kmitch@csugrad.cs.vt.edu | -- Sydney J. Harris From owner-freebsd-current Sat Mar 2 13:31:47 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA18796 for current-outgoing; Sat, 2 Mar 1996 13:31:47 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA18789 for ; Sat, 2 Mar 1996 13:31:41 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id HAA21506; Sun, 3 Mar 1996 07:26:55 +1000 Date: Sun, 3 Mar 1996 07:26:55 +1000 From: Bruce Evans Message-Id: <199603022126.HAA21506@godzilla.zeta.org.au> To: jhay@mikom.csir.co.za, terry@lambert.org Subject: Re: rename panics kernel Cc: freebsd-current@FreeBSD.ORG Sender: owner-current@FreeBSD.ORG Precedence: bulk Yet more on this... >> > Resently I got a "panic : vrele : negative reference count". >> > The vrele() was called from rename(). >> > >> > I tried a simple script to exercise rename (attached below) and a >> > current system seems to panic (trapped in ufs_rename). There's a race >> > condition lurking, it seems. I havent tried other than the sticky /tmp >> > directory as the source and target files parent directory. Also the >> > test was run under root's account, if it matters. >> > >> > Rename exercise: >> > ------ >> > #!/bin/sh >> > a=/tmp/foo.now >> > b=/tmp/foo.prev >> > while true >> > do >> > for n in 1 2 3 4 5 6 7 8 9 0 >> > do >> > (mv $a $b ; touch $a) & >> > done >> > wait >> > done >> > ------ This is a very versatile test :-). I still haven't got it to panic for rename with my own version of -current (my previous report about this was misleading), but it caused the following problems: On system b which has 16MB memory and 64MB swap, the script was killed after about 5 hours with a "swap_pager: out of swap space" error. The system was otherwise inactive apart from running standard daemons. On system c which has 8MB memory and 32MB swap, the script always causes a "vm_fork: u_map allocation failed" after about 1 minute. Bruce From owner-freebsd-current Sat Mar 2 16:24:54 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA27704 for current-outgoing; Sat, 2 Mar 1996 16:24:54 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA27697 for ; Sat, 2 Mar 1996 16:24:52 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA03039; Sat, 2 Mar 1996 17:23:32 -0700 From: Terry Lambert Message-Id: <199603030023.RAA03039@phaeton.artisoft.com> Subject: Re: rename panics kernel (fwd) To: bugs@freebsd.netcom.com (Mark Hittinger) Date: Sat, 2 Mar 1996 17:23:32 -0700 (MST) Cc: current@FreeBSD.ORG In-Reply-To: <199603020448.WAA26411@freebsd.netcom.com> from "Mark Hittinger" at Mar 1, 96 10:48:39 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG Precedence: bulk > Would this also come into play on a huge amount of 'rm' activity ala news > expire? Is that the "free vnode isn't" panic? If so, no, it shouldn't. Use the kludge I posted the other day for that one. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Sat Mar 2 16:26:26 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA27752 for current-outgoing; Sat, 2 Mar 1996 16:26:26 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA27747 for ; Sat, 2 Mar 1996 16:26:24 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA03030; Sat, 2 Mar 1996 17:22:44 -0700 From: Terry Lambert Message-Id: <199603030022.RAA03030@phaeton.artisoft.com> Subject: Re: rename panics kernel To: bde@zeta.org.au (Bruce Evans) Date: Sat, 2 Mar 1996 17:22:44 -0700 (MST) Cc: jhay@mikom.csir.co.za, terry@lambert.org, freebsd-current@FreeBSD.ORG In-Reply-To: <199603021351.AAA07828@godzilla.zeta.org.au> from "Bruce Evans" at Mar 3, 96 00:51:52 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG Precedence: bulk > I couldn't duplicate this with my version of -current, but plain -current > on an 8MB system gave: > > panic: vm_fork: u_map allocation failed Side effect of the fork/exec, I think. I haven't tracked it, but it looks like the page recovery is not happeneing for the environment space until the reap? I'd say this isn't really a problem. > and after rebooting it paniced in savecore: > > panic: bremfree: removing a buffer when not on a queue I never use savecore -- sorry. I rememebr something similar to this; is your swap in your /etc/fstab? That idea seems to tickle a memory. > and on a 16MB system the mv script trapped for a null pointer: > > Stopped at _ufs_remove+0x15: movl 0x68(%ecx),%edi > [%ecx = 0; %ecx is ap->a_vp] > > The fix is a side effect of my reordering for single-entry/single-exit > and the semantic changes for the: > > It must be a side effect of something I've changed too :-). In > ufs_rename(), I only changed most of the IN_CHANGE's to IN_MODIFIED. > This stops the directory ctimes from being updated for failed renames. > I don't think this would affect the bug. Hmmm... actually, it could. The allocation would have to rotor the vnodes through a list; if they were not inver LRU allocation order (ie: jumping between two of them, and it doesn), then you could fill up the total number of available vnodes before vclean go to them. This would be a serious border condition that I'd think would be near-impossible to reproduce reliably. Remember the "free vnode isn't" panic kludge I posted? Have you tried that? It may fix this problem as well. The other thing you might want to try is disabling async updates in the FFS code (per the sysctl debug variable)... I don't think that will do it for you, though. If either one of these does it for you, then I've just been lucky in not repeating the panic here. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Sat Mar 2 17:30:06 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA00952 for current-outgoing; Sat, 2 Mar 1996 17:30:06 -0800 (PST) Received: (from hsu@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA00943 Sat, 2 Mar 1996 17:30:04 -0800 (PST) Date: Sat, 2 Mar 1996 17:30:04 -0800 (PST) From: Jeffrey Hsu Message-Id: <199603030130.RAA00943@freefall.freebsd.org> To: bde Subject: new sio delays Cc: current Sender: owner-current@FreeBSD.ORG Precedence: bulk The 3 DELAY()s which were added last week to sio.c breaks the probe of my internal Boca 1440 modem. Does anyone else have problems finding serial ports with these DELAY()s? From owner-freebsd-current Sat Mar 2 23:41:08 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA23323 for current-outgoing; Sat, 2 Mar 1996 23:41:08 -0800 (PST) Received: from frig.mt.cs.keio.ac.jp (frig.mt.cs.keio.ac.jp [131.113.32.7]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA23306 Sat, 2 Mar 1996 23:41:00 -0800 (PST) Received: (from hosokawa@localhost) by frig.mt.cs.keio.ac.jp (8.6.12+2.4W/3.4Wbeta3) id QAA00912; Sun, 3 Mar 1996 16:40:46 +0900 Date: Sun, 3 Mar 1996 16:40:46 +0900 Message-Id: <199603030740.QAA00912@frig.mt.cs.keio.ac.jp> To: hsu@freefall.freebsd.org Cc: bde@freefall.freebsd.org, current@freefall.freebsd.org, hosokawa@mt.cs.keio.ac.jp Subject: Re: new sio delays In-Reply-To: Your message of Sat, 2 Mar 1996 17:30:04 -0800 (PST). <199603030130.RAA00943@freefall.freebsd.org> From: hosokawa@mt.cs.keio.ac.jp (HOSOKAWA Tatsumi) X-Mailer: mnews [version 1.18PL3] 1994-08/01(Mon) Sender: owner-current@FreeBSD.ORG Precedence: bulk In article <199603030130.RAA00943@freefall.freebsd.org> hsu@freefall.freebsd.org writes: >> The 3 DELAY()s which were added last week to sio.c breaks the probe of >> my internal Boca 1440 modem. Does anyone else have problems finding >> serial ports with these DELAY()s? I tested this patch with some PCMCIA modem cards that fails some of these tests, but it helps nothing. I want to know the means of this patch. -- HOSOKAWA, Tatsumi E-mail: hosokawa@mt.cs.keio.ac.jp WWW homepage: http://www.mt.cs.keio.ac.jp/person/hosokawa.html Department of Computer Science, Keio University, Yokohama, Japan