From owner-freebsd-current Sun Dec 15 01:16:33 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA06978 for current-outgoing; Sun, 15 Dec 1996 01:16:33 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id BAA06970 for ; Sun, 15 Dec 1996 01:16:31 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0vZCfM-0003w0C; Sun, 15 Dec 96 01:15 PST Received: from critter.tfs.com (localhost.phk.dk [127.0.0.1]) by critter.tfs.com (8.8.2/8.8.2) with ESMTP id KAA09143; Sun, 15 Dec 1996 10:18:47 +0100 (MET) To: "John S. Dyson" cc: current@freebsd.org Subject: Re: Warning -- Lite/2 merge coming up In-reply-to: Your message of "Sat, 14 Dec 1996 23:31:58 EST." <199612150431.XAA07652@dyson.iquest.net> Date: Sun, 15 Dec 1996 10:18:46 +0100 Message-ID: <9141.850641526@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199612150431.XAA07652@dyson.iquest.net>, "John S. Dyson" writes: >Fair warning: > >I am about 2/3's way through a merge of Lite/2 with -current (Jeffery Hsu >et. al. work.) By about Tue or Wed, I'll be committing the changes. > >It would be a good idea to assume that the system will be marginally stable >until next weekend. COOL! -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-current Sun Dec 15 01:51:52 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA11624 for current-outgoing; Sun, 15 Dec 1996 01:51:52 -0800 (PST) Received: from irz201.inf.tu-dresden.de (irz201.inf.tu-dresden.de [141.76.1.10]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id BAA11612 for ; Sun, 15 Dec 1996 01:51:48 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz201.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA00698 for ; Sun, 15 Dec 1996 10:51:46 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA19411 for freebsd-current@FreeBSD.org; Sun, 15 Dec 1996 10:51:46 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id KAA10272 for freebsd-current@FreeBSD.org; Sun, 15 Dec 1996 10:50:15 +0100 (MET) From: J Wunsch Message-Id: <199612150950.KAA10272@uriah.heep.sax.de> Subject: Re: Warning -- Lite/2 merge coming up To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 15 Dec 1996 10:50:15 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199612150431.XAA07652@dyson.iquest.net> from "John S. Dyson" at "Dec 14, 96 11:31:58 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As John S. Dyson wrote: > I am about 2/3's way through a merge of Lite/2 with -current (Jeffery Hsu > et. al. work.) By about Tue or Wed, I'll be committing the changes. You mean, changes concerning the /sys area, right? -- 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 Dec 15 01:52:04 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA11689 for current-outgoing; Sun, 15 Dec 1996 01:52:04 -0800 (PST) Received: from irz401.inf.tu-dresden.de (irz401.inf.tu-dresden.de [141.76.1.12]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id BAA11656 for ; Sun, 15 Dec 1996 01:51:59 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz401.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA29333; Sun, 15 Dec 1996 10:51:42 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA19403; Sun, 15 Dec 1996 10:51:41 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id KAA10099; Sun, 15 Dec 1996 10:36:38 +0100 (MET) From: J Wunsch Message-Id: <199612150936.KAA10099@uriah.heep.sax.de> Subject: Re: Huh?!? To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 15 Dec 1996 10:36:36 +0100 (MET) Cc: root@thud.freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from Ollivier Robert at "Dec 15, 96 01:33:57 am" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Ollivier Robert wrote: > > joerg p0 EL-SEGUNDO.MT.DD 12May61 - w > > ^^^^^^^^^^^^^^^^ ^^^^^^^ > > > > I'm logged in from uriah.heep.sax.de (via ssh), and i didn't even > > exist already in May, 1961. :-)) > > Neither did I :-) > > I noticed the same problem and sent a mail to root@thud about it. Thud is > post-utmp changes but even with a "converted" wtmp (look in /var/log) and a > Dec. 8th make world it still show this. sshd problem? -- 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 Dec 15 04:51:48 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id EAA24188 for current-outgoing; Sun, 15 Dec 1996 04:51:48 -0800 (PST) Received: from shadows.aeon.net (bsdcur@shadows.aeon.net [194.100.41.1]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id EAA24183 for ; Sun, 15 Dec 1996 04:51:44 -0800 (PST) Received: (from bsdcur@localhost) by shadows.aeon.net (8.8.4/8.8.3) id OAA24763 for freebsd-current@freebsd.org; Sun, 15 Dec 1996 14:51:10 +0200 (EET) From: mika ruohotie Message-Id: <199612151251.OAA24763@shadows.aeon.net> Subject: /usr/src/sys/i386/i386/userconfig.c To: freebsd-current@freebsd.org Date: Sun, 15 Dec 1996 14:51:10 +0200 (EET) X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk found this one while compiling kernel, supped last nite... the file id: $Id: userconfig.c,v 1.74 1996/12/14 22:18:43 jkh Exp $ on the line 2284 someone has been too sleepy... :p #incldue "eisa.h" =)))) mickey -- mika ruohotie mika@aeon.net From owner-freebsd-current Sun Dec 15 05:22:08 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA25272 for current-outgoing; Sun, 15 Dec 1996 05:22:08 -0800 (PST) Received: from irz401.inf.tu-dresden.de (irz401.inf.tu-dresden.de [141.76.1.12]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id FAA25267 for ; Sun, 15 Dec 1996 05:22:03 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz401.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id OAA03203 for ; Sun, 15 Dec 1996 14:22:01 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id OAA23280 for freebsd-current@FreeBSD.org; Sun, 15 Dec 1996 14:22:01 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.2/8.6.9) id OAA19098 for freebsd-current@FreeBSD.org; Sun, 15 Dec 1996 14:12:08 +0100 (MET) From: J Wunsch Message-Id: <199612151312.OAA19098@uriah.heep.sax.de> Subject: zlib doc? To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 15 Dec 1996 14:12:07 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I'm missing the man page for libz. Where is it? -- cheers, J"org ``An undocumented feature is a bug.'' Wunsch 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 Dec 15 05:24:15 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA25399 for current-outgoing; Sun, 15 Dec 1996 05:24:15 -0800 (PST) Received: from mail.tky007.tth.expo96.ad.jp (root@tokyo-01-061.gol.com [202.243.51.61]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id FAA25391 for ; Sun, 15 Dec 1996 05:24:11 -0800 (PST) Received: from tky007.tth.expo96.ad.jp (masafumi@localhost [127.0.0.1]) by mail.tky007.tth.expo96.ad.jp (8.8.4/3.4W4-SMTP) with ESMTP id WAA01789; Sun, 15 Dec 1996 22:24:11 +0900 (JST) Message-Id: <199612151324.WAA01789@mail.tky007.tth.expo96.ad.jp> To: freebsd-current@freebsd.org Cc: max@wide.ad.jp Subject: ed0 trouble with -current From: Masafumi NAKANE/=?ISO-2022-JP?B?GyRCQ2Y6LDJtSjgbKEI=?= X-Mailer: Mew version 1.54 on Emacs 19.28.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 15 Dec 1996 22:24:10 +0900 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I did `make world' today using current sources (ctm delta up to 2517 applied) and found out that ed0 driver doesn't work like it used to. It looks like ed0 can receive incoming packets without problems, but it can't send out outgoing packets. If I do ping to the local gateway router, it says `host is down' although it isn't. When I connect my machine to the network using PPP, I can communicate with machines outside the subnet without problem, and interestingly, machines on remote network can also communicate with my machine using the IP address assigned to ed0. (That's probably because they can receive ack packets as these packets can now go back there via tun0.) Any idea what I've done wrong? (Well, actually I didn't do anything, I'm just running the machine with settings that once was working.) Or any idea where I should look into? Thanks. ----------------------------------------------------------------------- Masafumi NAKANE, Keio Univ., Dept. of Environmental Information E-Mail : max@wide.ad.jp / max@FreeBSD.ORG [URL] : http://www.sfc.wide.ad.jp/~max/ From owner-freebsd-current Sun Dec 15 06:52:06 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA01276 for current-outgoing; Sun, 15 Dec 1996 06:52:06 -0800 (PST) Received: from irz201.inf.tu-dresden.de (irz201.inf.tu-dresden.de [141.76.1.10]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id GAA01255 for ; Sun, 15 Dec 1996 06:51:56 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz201.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id PAA05712 for ; Sun, 15 Dec 1996 15:51:13 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id PAA24677 for freebsd-current@FreeBSD.org; Sun, 15 Dec 1996 15:51:13 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id PAA24147 for freebsd-current@FreeBSD.org; Sun, 15 Dec 1996 15:31:56 +0100 (MET) From: J Wunsch Message-Id: <199612151431.PAA24147@uriah.heep.sax.de> Subject: cvt-wtmp To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 15 Dec 1996 15:31:55 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM850660315-20318-0_ Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk --ELM850660315-20318-0_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit For the curious, here is it. I'm still awaiting Jordan's proposal on the upgrade suite framework :), but since i'm afraid this will take quite a bit longer to complete, and people need to convert their wtmp's right now, i wrote the tool. (Yes, i've just upgraded my machine, or what do you believe why i wrote it? :) I might check it into CVS under tools/ until the upgrade framework is ready for prime-time. Objections? (If it's only in -current, but not in 2.2, it won't get a CVS tag anytime soon, so we could even repository copy it later.) -- 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. ;-) --ELM850660315-20318-0_ Content-Type: text/plain Content-Disposition: attachment; filename=cvt-wtmp.c Content-Description: /tmp/cvt-wtmp.c Content-Transfer-Encoding: 7bit /* * Copyright (c) 1996 Joerg Wunsch * * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE DEVELOPERS ``AS IS'' AND ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. * IN NO EVENT SHALL THE DEVELOPERS BE LIABLE FOR ANY DIRECT, INDIRECT, * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ /* * Heuristics to convert old wtmp format to new one. */ #include #include #include #include #include #include #include #include #include #include #include #define OUT_NAMESIZE 8 #define OUT_LINESIZE 8 #define OUT_HOSTSIZE 16 struct olastlog { time_t ll_time; char ll_line[OUT_LINESIZE]; char ll_host[OUT_HOSTSIZE]; }; struct outmp { char ut_line[OUT_LINESIZE]; char ut_name[OUT_NAMESIZE]; char ut_host[OUT_HOSTSIZE]; long ut_time; }; void usage(void); void convert(const char *, int); /* * NB: We cannot convert lastlog yet, but we don't need either. */ void usage(void) { errx(EX_USAGE, "usage: cvt-wtmp [-n] /var/log/wtmp*"); } int main(int argc, char **argv) { int errs, i, nflag, rv; errs = nflag = 0; while ((i = getopt(argc, argv, "n")) != EOF) switch (i) { case 'n': nflag++; break; default: errs++; } argc -= optind; argv += optind; if (argc <= 0 || errs) usage(); for (;argc > 0; argc--, argv++) convert(*argv, nflag); return 0; } void convert(const char *name, int nflag) { struct stat sb; struct timeval tv[2]; char xname[1024], yname[1024]; unsigned char buf[128]; /* large enough to hold one wtmp record */ int fd1, fd2; size_t off; int old, new; time_t now, early, t; struct tm tm; struct utmp u; struct outmp *ou; if (stat(name, &sb) == -1) { warn("Cannot stat file \"%s\", continuing.", name); return; } now = time(NULL); /* some point in time very early, before 386BSD 0.0 */ tm.tm_sec = 0; tm.tm_min = 0; tm.tm_hour = 0; tm.tm_mday = 1; tm.tm_mon = 2; tm.tm_year = 92; tm.tm_isdst = 0; early = mktime(&tm); tv[0].tv_sec = sb.st_atimespec.tv_sec; tv[0].tv_usec = sb.st_atimespec.tv_nsec / 1000; tv[1].tv_sec = sb.st_mtimespec.tv_sec; tv[1].tv_usec = sb.st_mtimespec.tv_nsec / 1000; /* unzipping is handled best externally */ if (strlen(name) > 3 && memcmp(&name[strlen(name) - 3], ".gz", 3) == 0) { warnx("Cannot handle gzipped files, ignoring \"%s\".", name); return; } (void) snprintf(xname, sizeof xname, "%s.new", name); if (!nflag && (fd1 = open(xname, O_WRONLY|O_CREAT|O_TRUNC, 0644)) == -1) err(EX_CANTCREAT, "Can't create new wtmp file"); if ((fd2 = open(name, O_RDONLY, 0)) == -1) err(EX_UNAVAILABLE, "input file magically disappeared, i'm confused"); old = new = 0; off = 0; while (read(fd2, &buf[off], sizeof(time_t)) == sizeof(time_t)) { t = *((time_t *)&buf[off]); off += sizeof(time_t); if (t < early || t > now) { /* unreasonable, collect another entry */ if (off > sizeof buf) { (void) unlink(xname); errx(EX_UNAVAILABLE, "I can't seem to make sense out of file \"%s\"", name); } continue; } /* time is reasonable, we seem to have collected a full entry */ if (off == sizeof(struct utmp)) { /* new wtmp record */ new++; if (!nflag) { if (write(fd1, buf, sizeof(struct utmp)) != sizeof(struct utmp)) err(EX_IOERR, "writing file \"%s\"", xname); } } else if (off == sizeof(struct outmp)) { /* old fart */ old++; if (!nflag) { ou = (struct outmp *)buf; memset(&u, 0, sizeof u); memcpy(&u.ut_line, ou->ut_line, OUT_LINESIZE); memcpy(&u.ut_name, ou->ut_name, OUT_NAMESIZE); memcpy(&u.ut_host, ou->ut_host, OUT_HOSTSIZE); memcpy(&u.ut_time, &ou->ut_time, sizeof u.ut_time); if (write(fd1, &u, sizeof(struct utmp)) != sizeof(struct utmp)) err(EX_IOERR, "writing file \"%s\"", xname); } } else { if (off < sizeof(struct outmp)) /* try again */ continue; warnx("Illegal record in file \"%s\", ignoring.", name); off = 0; continue; } off = 0; } close(fd2); /* * Since the wtmp file is chronologically increasing, we can move * the `early' time as we go. Allow for one hour time-of-day * adjustments. */ early = t - 3600; printf("File \"%s\": %d old and %d new records found.\n", name, old, new); if (nflag) return; (void) close(fd1); (void) snprintf(yname, sizeof yname, "%s.bak", name); if (rename(name, yname) == -1) err(EX_OSERR, "Cannot rename \"%s\" to \"%s\"", name, yname); if (rename(xname, name) == -1) err(EX_OSERR, "Cannot rename \"%s\" to \"%s\"", xname, name); if (utimes(name, tv) == -1) warn("Cannot adjust access and modification times for \"%s\"", name); } --ELM850660315-20318-0_-- From owner-freebsd-current Sun Dec 15 08:00:30 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA10653 for current-outgoing; Sun, 15 Dec 1996 08:00:30 -0800 (PST) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id IAA10644 for ; Sun, 15 Dec 1996 08:00:26 -0800 (PST) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id RAA29414; Sun, 15 Dec 1996 17:00:16 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id QAA07946; Sun, 15 Dec 1996 16:59:49 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.4/keltia-uucp-2.9) id QAA05549; Sun, 15 Dec 1996 16:07:28 +0100 (CET) Message-ID: Date: Sun, 15 Dec 1996 16:07:27 +0100 From: roberto@keltia.freenix.fr (Ollivier Robert) To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Cc: freebsd-current@FreeBSD.org (FreeBSD-current users), root@thud.freebsd.org Subject: Re: Huh?!? References: <199612150936.KAA10099@uriah.heep.sax.de> X-Mailer: Mutt 0.54 Mime-Version: 1.0 X-Operating-System: FreeBSD 3.0-CURRENT ctm#2768 In-Reply-To: <199612150936.KAA10099@uriah.heep.sax.de>; from J Wunsch on Dec 15, 1996 10:36:36 +0100 Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk According to J Wunsch: > > post-utmp changes but even with a "converted" wtmp (look in /var/log) and a > > Dec. 8th make world it still show this. > > sshd problem? Now that you mention it, it is probably that. I didn't looked at sshd's time. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #31: Tue Dec 3 23:52:58 CET 1996 From owner-freebsd-current Sun Dec 15 08:31:30 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA13809 for current-outgoing; Sun, 15 Dec 1996 08:31:30 -0800 (PST) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id IAA13797 for ; Sun, 15 Dec 1996 08:31:26 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id LAA05025; Sun, 15 Dec 1996 11:31:09 -0500 (EST) From: "John S. Dyson" Message-Id: <199612151631.LAA05025@dyson.iquest.net> Subject: Re: Warning -- Lite/2 merge coming up To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 15 Dec 1996 11:31:09 -0500 (EST) Cc: freebsd-current@FreeBSD.org In-Reply-To: <199612150950.KAA10272@uriah.heep.sax.de> from "J Wunsch" at Dec 15, 96 10:50:15 am 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 X-Loop: FreeBSD.org Precedence: bulk > As John S. Dyson wrote: > > > I am about 2/3's way through a merge of Lite/2 with -current (Jeffery Hsu > > et. al. work.) By about Tue or Wed, I'll be committing the changes. > > You mean, changes concerning the /sys area, right? > Yep, only the kernel -- sorry for the hyperbole!!! :-). I AM NOT trying to take anything from those that are doing the also difficult userland stuff. It is more likely however, that the kernel changes will transiently cause some instability due to either (1) bugs in the original Lite/2 work done by Hsu, et.al. Or (2) by my merging of their work. John dyson@freebsd.org From owner-freebsd-current Sun Dec 15 12:24:10 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA26056 for current-outgoing; Sun, 15 Dec 1996 12:24:10 -0800 (PST) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA25975 for ; Sun, 15 Dec 1996 12:23:46 -0800 (PST) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id PAA05216 for current@freebsd.org; Sun, 15 Dec 1996 15:22:40 -0500 From: Bill Paul Message-Id: <199612152022.PAA05216@skynet.ctr.columbia.edu> Subject: Plan for integrating Secure RPC -- comments wanted To: current@freebsd.org Date: Sun, 15 Dec 1996 15:22:39 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Okay, I've decided on a final plan for integrating Secure RPC into the main source tree. There were a couple of problems that had to be dealt with which didn't have easy solutions, so I'm going to outline them here to give people a chance to tell me they suck, call me a looney, or present alternate solutions. A couple things first. In the process of merging in the Secure RPC support to our existing library, I added a few extra useful bits from later versions of RPC released by Sun. The publickey and netname lookup functions are taken from TIRPCSRC 1.0, which was the first release of TI-RPC and was based on SunOS. Our library is based on RPCSRC 4.0, which is older; while it does have publickey and netname lookup code, it uses only YP whereas the newer versions can use either YP or local files (using the '+' hack). Also, in later versions of TI-RPC, there were some new clnt_control() commands added to the various transports. Some of these only work if you have TLI, hence they are no-ops, but the others work as expected. Also, I have also added support for a third transport called "unix" to go with the existing "tcp" and "udp" transports. This transport uses AF_UNIX SOCK_STREAM sockets and works just like the "tcp" transport, except it can only be used by local processes. This transport is useful mainly to support the keyserv(8) program: keyserv(8) should only communicate with local processes, but there's no 100% bulletproof way to guarantee this with the "tcp" and "udp" transports (thanks to IP spoofing). In TI-RPC, keyserv(8) uses the loopback transport for this; BSD has no loopback transport, so I opted to use AF_UNIX sockets instead. (Once this change goes in, I also plan to modify rpc.yppasswdd to use this transport instead of the hack it has now.) Lastly, I decided to add support for version 2 of the keyserv protocol. The keyserv(8) in TI-RPC 2.x uses this protocol, and it's necessary to make NIS+ work. I have modified the keyserv code from TI-RPC 2.3 and used that as well as the key_call.c module and the key_prot.x protocol definition from the same release. Anyway, those are relatively small issues. Here are the larger ones: Adding new authentication flavors --------------------------------- Authentication in RPC works by having the client create an AUTH structure containing credential and verifier data and attaching it to its CLIENT handle. The AUTH data is transmitted to the server whenever an RPC is made. Included in this data is an integer value that denotes the authentication 'flavor' being used. The flavors our library currently supports are AUTH_NONE (0), AUTH_UNIX (1) and AUTH_SHORT (2). (For all these flavors, there are _no_ verifiers, hence they're all insecure.) When an RPC server receives a request, it calls a wrapper function named _authenticate() to choose an appropriate authenticator function based on the flavor value. In RPCSRC 4.0, this is done using an array of functions called svcauthsw[]. The flavor value is used as an index into this array, much like a device major value is used as an index into the devsw[] array. If the flavor value is too high, _authenticate() rejects the credentials. Otherwise, the corresponding authenticator function is invoked and tries to decode the credentials and, if needed, the verifiers. The problem with this is that the svcauthsw[] array is hardcoded into the RPC library (and, consequently, into libc). While an RPC client can set up its AUTH structure independent of the RPC library, the only way to add new authentication flavors to an RPC server is to modify the array and recompile library. In TI-RPC, Sun fixed this by changing the array into a linked list and adding a new function called svc_auth_reg(), which RPC servers can use to register new flavors with the library. Now, when an RPC is received, the _authenticate() wrapper traverses the list looking for an entry with a flavor that matches the value sent by the client. What I want to do is use the svc_auth.c module from TI-RPC so that our library has this capability. The AUTH_DES support can then be imported as src/lib/libdesrpc, seperate from libc. Technically it doesn't have to be this way, but doing it like this provides a good example as to how new authentication modules should look. The desrpc library will contain the client side auth_des.c module, the server side svc_auth_des.c module, the xcrypt.c module (which usually goes in librpcsvc but which fits better here) and all the necessary glue code, including the interface to the DES encryption system (note that _no_ actual DES crypto code will actually be present here -- more on this in a minute). My other motivation for this is to allow the AUTH_GSSAPI authentication code in the Kerberos V distribution to be added without having to modify libc. The AUTH_GSSAPI implementation is provided as a completely seperate version of the RPCSRC 4.0 library. If the code is imported into the system as is, we will end up with two seperate RPC libraries in the tree. This is pretty wasteful, and unnecessary if the RPC code in libc allows new flavors to be added without modifying any code. Splitting out the DES code --------------------------- We obviously can't provide the DES support with the core OS since that would violate U.S. crypto export laws. (The Linux distributors don't seem to care and are happily exporting it anyway, but I think it's safe to say we don't want to follow their example. :) Consequently, the DES code has to be shipped seperately as part of the DES or secure distributions. The trick is to isolate the DES support in such a way that it can be provided seperately with a minimum of hassle to both us and the end users. In terms of the source code, everything ultimately boils down to a single function called _des_crypt(). The Secure RPC source distribution from Sun includes everything needed to implement Secure RPC _except_ this function. We need to maintain this separation. This is not as simple as it seems. For the moment, it is enough to supply a dummy libdes.so shared library with the core OS, but this is only because presently there are no programs in the core OS that need to use Secure RPC (the Secure RPC utilities such as keylogin, keylogout, keyserv, rpc.ypupdated, newkey and chkey will need it, but they're all going to be linked dynamically). However this will change once NIS+ support is integrated. Right now, there are several programs in /bin and /sbin which use NIS code as a side effect of calling libc functions that have NIS support in them. All the executables in these directories are linked static, hence each has a copy of the NIS support in them. This includes things like /bin/csh, /sbin/dump, /sbin/mountd, /sbin/mount_*, and many more. Right now, we deal with this problem by providing replacement executables in the DES distribution (/sbin/init and /bin/ed). But in this case there will be a _lot_ more programs affected, and replacing all of them just doesn't seem like a good solution to me. The question then is how to seperate out the DES code without actually changing any executables. There are actually three ways, all of which suck. It's a matter of choosing the least suckiest. The very suckiest is the solution that Sun uses in Solaris, namely the name service switch. The name service switch uses shared objects to contain the various kinds of lookup routines: files, DNS, NIS and NIS+. You can even create your own. The top-level lookup routines (gethostbyname(), getpwent(), etc...) call a stub which reads the /etc/nsswitch.conf file and dlopen()s the proper lookup modules depending on what it finds there. Using this trick, one can supply an NIS+ lookup module with no DES support in the core OS and a replacement module with real DES support in the encryption kit. The problem with this solution is that in the end, you really don't have any static executables anymore: all programs that use the name service switch must be linked with libdl.so. (The exception to this rule in Solaris is /sbin/sh, which is truly static.) (Note that it appears that Sun really doesn't take advantage of the name service switch to separate out DES support. In fact, I'm not really sure what they do.) The sucky part about all this is that I would have to implement my own name service switch and make all kinds of modifications to the system to support it. Also, if I understand things correctly, static executables can't call dlopen() and friends in 2.2 and 3.0 since those functions are in crt0.o, but not in scrt0.o. The second solution is to put the DES support in the kernel. It's possible to create a syscall LKM that implements the _des_crypt() function and have libdesrpc call this system call instead of a library function. A dummy LKM could be supplied with the core OS that does no DES at all (or uses some other cipher that is exportable), while a real DES LKM could be shipped with the secure dist. In this case, no executables would have to be changed at all. The sucky part about this is that it bloats the kernel. It also has 'kludge' written all over it in big red letters. The third solution, which is the one I've settled on, is to create a 'DES daemon,' i.e. a server program that does the encryption. Since Secure RPC needs keyserv(8) to be running anyway, I decided to (ab)use it as the encryption server. (This is another case where the "unix" transport comes in handy: only local processes can use the service.) Basically I turned the _des_crypt() function into a remote procedure call: the data block to be crypted/decrypted, the key, and other arguments are sent to keyserv, which does the work, then sends back the results. This way, the only program that needs to call _des_crypt() as a local function is keyserv. Also, to make the addition of DES support as easy as possible, I fixed keyserv so that it tries to dlopen() libdes.so in order to obtain DES support rather than linking it to libdes.so at compile time. At startup, keyserv, tries to dlopen() /usr/lib/libdes.so.3.x and looks for the '__des_crypt()' symbol. If it finds it, it uses that for its encryption and keyserv then operates in DES mode. If it fails, it falls back to RC4 encryption (with a 40 bit key, just like nutscrape). Since libdes.so is not supplied with the base OS, keyserv will always operate in RC4 mode until you install the secure dist. (The user can specify an alternate path for the shared lib with a command line switch as well.) The end result: you don't need to replace keyserv at all. To enable DES support, you just copy libdes.so.3.x to /usr/lib, then restart keyserv. Presto! You have real AUTH_DES support. No muss, no fuss, no recompiling, no switching keyserv executables. The sucky part is that calling _des_crypt() as an RPC is slower than calling it as a local function. Using an AF_UNIX socket helps a little since the kernel doesn't have to do any protocol processing, but it's still slower. (This also makes Secure RPC programs dependent on keyserv, but in fact they're already dependent on keyserv anyway because of how Secure RPC works.) Authenticating local connections -------------------------------- The last sticky issue has to do with the way keyserv(8) works. Keyserv's purpose is to store users' unencrypted secret keys. It keeps them in memory, and they're all lost when keyserv exits. (The exception is root's secret key, which can be stored in /etc/.rootkey. This is needed in case a system crashes and reboots while the system operator is away and can't reload root's secret key with keylogin(1). In some cases, system daemons (like rpc.ypupdated and rpc.nisd) need root's secret key to work correctly and will break if it's not available.) Utilities that call keyserv usually supply their UID as one of the arguments in the RPC call. They also supply their UID in their AUTH_UNIX credentials (keyserv requires clients to use AUTH_UNIX creds). The problem is that there's no way for keyserv to be sure that the client isn't lying, and it _needs_ to be sure, otherwise a user can fool it into revealing other users' secret keys. In RPCSRC 4.0, this was handled with the ugly and bletcherous keyenvoy(8) program. Keyserv was set up so that it would only accept requests from 127.0.0.1 on reserved ports, meaning that only root on the local host could talk to it. The keyenvoy(8) program was installed suid-root, and you had to use it as a middleman when communicating with keyserv. The RPC library would actually fork/exec keyenvoy and use it (via a pipe) to do its transcations with keyserv. This meant that all programs that used Secure RPC would do the same thing. This is disgusting for a number of reasons, the least of which is that it wrecks performance of programs that need to make many calls to keyserv (like rpc.nisd). Also, since keyserv was forced to use only the "tcp" and "udp" transports, there was a chance it could be fooled into handling remote requests using IP spoofing. This latter problem goes away if you use the "unix" transport, but the performance issue remains. In TI-RPC, Sun did away with keyenvoy and made keyserv use the loopback transport. They also took advantage of certain features in SysV networking that allow keyserv to learn the UID of the process on the other side of the transport endpoint. (I don't quite understand how it works, but it uses t_getinfo().) This credential information is set by the kernel, hence it's not possible for the client to falsify it (unless it has root privileges, but if this is the case then system security has already been compromised and you have bigger problems). Unfortunately, BSD doesn't have any equivalent mechanism for learning the UID of a process on the other side of an AF_UNIX socket, and we don't have STREAMS/TLI networking. This presents a serious problem since it is vital for keyserv to have such a mechanism in order for its security model to work. A workaround is to use SysV message queues. When a message queue is created, the kernel notes the UID and GID of the creator in its ipc_perms structure. Again, the client is not able to falsify this information. But while FreeBSD does have message queue support, it is optional and not part of the GENERIC kernel. It would therefore be a mistake to depend on it. The only way I've found to deal with this problem effectively is to create a special syscall LKM which can verify the identity of a process on the other side of an AF_UNIX socket. Keyserv calls this new system call with its socket descriptor and the PID of the remote process as arguments. (The remote process supplies its PID in the verifier in its AUTH_UNIX credentials. It's okay to let the client tell keyserv its PID since keyserv will know if it's lying, and it saves some work in the syscall.) The syscall uses the descriptor to find the socket structure for keyserv's side of the connection, then, using the protocol control block, it finds the socket on the other side. It then checks the descriptor table of the specified PID to see if it has a pointer to the same socket structure. If it does, then the syscall returns the UID of the other process, otherwise it returns an error. It's possible to add this code to the kernel directly, but I consider it a hack and not worthy of being added to the kernel source tree. Making it a loadable kernel module works just as well, and it can be easily loaded at the same time keyserv is launched at system startup. (It can be part of the same sysconfig knob that turns on keyserv.) So, sum up, these are the three main issues and how I solved them: - Adding new RPC authentication flavors: use svc_auth_reg() and supply the code in a seperate library. - Segregating the DES crypto code: move it all into keyserv(8) and access it via remote procedure calls. (Also support runtime dynamic loading of the libdes library and use RC4 as a replacement if DES is unavailable.) - Allowing keyserv to authenticate local clients: use a special system call supplied as a loadable kernel module. If nobody complains strenuously about any of this, I'm going to go ahead and start importing things using this plan in a few weeks. (I still need to finish rpc.ypupdated.) Comments, criticisms, screams of terror, or large bags of cash are welcome and encouraged. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= From owner-freebsd-current Sun Dec 15 13:05:08 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA00223 for current-outgoing; Sun, 15 Dec 1996 13:05:08 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id NAA00202; Sun, 15 Dec 1996 13:04:58 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.3/8.8.3) with ESMTP id NAA28986; Sun, 15 Dec 1996 13:04:37 -0800 (PST) Message-Id: <199612152104.NAA28986@austin.polstra.com> To: ernie@spooky.eis.net.au Subject: Re: SUP of current weird Newsgroups: polstra.freebsd.current In-Reply-To: <199612142219.IAA10425@spooky.eis.net.au> References: <199612142219.IAA10425@spooky.eis.net.au> Organization: Polstra & Co., Seattle, WA Cc: freebsd-current@freebsd.org, dima@burka.rdy.com, peter@freebsd.org Date: Sun, 15 Dec 1996 13:04:37 -0800 From: John Polstra Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199612142219.IAA10425@spooky.eis.net.au> you write: > I noticed over the last few days that there have been a few minor bugs that > stop a make world in -current so I simply run sup again to get the latest > fixed the next day. However every time I run sup it seems to want to > retreive most of the contrib directory again which is wastefull. > > Has there been major patches every day of the last week to the contrib dir > that forces sup to download it again? Or is there something odd going on? There have been very few commits to contrib lately. There is something odd going on. > It only seems to be the contrib dir the other just update changed files as > normal. > > Any suggestions? Your supfile line looks fine. I looked around a bit on sup.freebsd.org. The problem appears to be a bug in cvs-1.6.3, which is the version used there. Periodically (every day, I suppose) the source tree there is updated with "cvs update -APd". For some reason, this is causing the modtimes of the contrib files to be updated, even though the files haven't changed. (2554 files under contrib on sup.freebsd.org have been touched in the past 24 hours.) I tried some experiments on two machines here, one running cvs-1.6.3, and the other running cvs-1.8.1. Both times, I did this: cvs checkout contrib_libpcap cd contrib_libpcap ls -lt cvs update -APd ls -lt On the -1.6.3 machine, zillions of files got "updated", and their modtimes were touched. On the -1.8.1 machine, the "cvs update" did nothing. Peter: Is this a known bug? Dima: Could you update your cvs to the version from -current? Ernie: If you were using CVSup, this wouldn't be happening to you. (Sorry, I couldn't resist. :-) John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-current Sun Dec 15 14:05:33 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA04934 for current-outgoing; Sun, 15 Dec 1996 14:05:33 -0800 (PST) Received: from gw.muc.ditec.de (gw.muc.ditec.de [194.120.126.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA04929 for ; Sun, 15 Dec 1996 14:05:29 -0800 (PST) Received: (from nobody@localhost) by gw.muc.ditec.de (8.7.5/8.6.9) id XAA22174 for ; Sun, 15 Dec 1996 23:05:52 +0100 (MET) X-Authentication-Warning: gw.muc.ditec.de: nobody set sender to using -f Received: from tartufo.muc.ditec.de(134.98.18.2) by gw.muc.ditec.de via smap (V2.0alpha) id sma022170; Sun Dec 15 23:05:48 1996 Received: by tartufo.muc.ditec.de (/\=-/\ Smail3.1.16.1 #16.39) id ; Wed, 11 Dec 96 09:29 MEZ Message-Id: Date: Sun, 15 Dec 96 23:06 MEZ From: me@tartufo.muc.ditec.de (Michael Elbel) To: grog@lemis.de Cc: current@freebsd.org Subject: Re: It works! Solved my problem wih Etherlink III on AcerNote Light Newsgroups: lists.freebsd.current References: <199612101054.LAA18102@freebie.lemis.de> Reply-To: me@gw.muc.ditec.de X-Newsreader: NN version 6.5.0 #1 (NOV) Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In lists.freebsd.current you write: >For those of you who've been following my tribulations installing >-current on an AcerNote Light, the good news: finally it works. Ah, too bad I haven't seen this earlier. I've been through the same problems with a NEC Versa 6030X lately. The damned thing would just hang with the default settings of INT 10 IO 300 if the zp driver tried to probe it. No way to reconfigure with 3Com's diagnostic tools since it wouldn't find the card. At least I knew that the card itself wasn't broken since Win95% did work. I finally found out throught trial and error that the diagnostics would work if they were running under DOS <= 6.22. Then I could reconfigure the card, use the settings with the 2.2A boot disk, diddle link0 and link1 settings till packets went out and finally install FreeBSD. Now I'm using the PAO stuff with the ep driver which works fine except that the link0 and link1 options obviously are swapped in comparison with zp0 :) That 1024 * 768 display *really* is nice - works fine with the latest XFree86. Michael -- Michael Elbel, DITEC, Muenchen, Germany - me@muc.ditec.de Fermentation fault (coors dumped) From owner-freebsd-current Sun Dec 15 14:16:16 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA06374 for current-outgoing; Sun, 15 Dec 1996 14:16:16 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id OAA06361 for ; Sun, 15 Dec 1996 14:16:13 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA24022; Sun, 15 Dec 1996 14:52:15 -0700 From: Terry Lambert Message-Id: <199612152152.OAA24022@phaeton.artisoft.com> Subject: Re: Plan for integrating Secure RPC -- comments wanted To: wpaul@skynet.ctr.columbia.edu (Bill Paul) Date: Sun, 15 Dec 1996 14:52:15 -0700 (MST) Cc: current@freebsd.org In-Reply-To: <199612152022.PAA05216@skynet.ctr.columbia.edu> from "Bill Paul" at Dec 15, 96 03:22: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 X-Loop: FreeBSD.org Precedence: bulk > Okay, I've decided on a final plan for integrating Secure RPC into > the main source tree. There were a couple of problems that had to be > dealt with which didn't have easy solutions, so I'm going to outline > them here to give people a chance to tell me they suck, call me a looney, > or present alternate solutions. [ ... much deleted ... ] Bill, you great big stud, you! 8-). > loopback transport for this; BSD has no loopback transport, so I opted > to use AF_UNIX sockets instead. (Once this change goes in, I also plan > to modify rpc.yppasswdd to use this transport instead of the hack it > has now.) The "correct" name is AF_LOCAL, not AF_UNIX, I believe (I was surprised when I went looking... I thought it was AF_POSIX, not AF_LOCAL). > Splitting out the DES code > --------------------------- > > We obviously can't provide the DES support with the core OS since > that would violate U.S. crypto export laws. (The Linux distributors > don't seem to care and are happily exporting it anyway, but I think > it's safe to say we don't want to follow their example. :) Consequently, > the DES code has to be shipped seperately as part of the DES or secure > distributions. The trick is to isolate the DES support in such a way > that it can be provided seperately with a minimum of hassle to both > us and the end users. In terms of the source code, everything ultimately > boils down to a single function called _des_crypt(). The Secure RPC > source distribution from Sun includes everything needed to implement > Secure RPC _except_ this function. We need to maintain this separation. This is not so obvious. Specifically, there is an exportable DES in the 4.4 sources which is used for the password facility there (they don't use MD5, they use an exportable DES hasher). The code is a simplified hasher which is unidirectional. I didn't bother to look to see if the values it used were no longer table driven, but I suspect that it might be the case. Depnending on usage as hash *only*, you might be able to use this. Certainly, the password stuff should use it by default to get rid of the MD5 incompatability issues. > Right now, there are several programs in /bin and /sbin which use > NIS code as a side effect of calling libc functions that have NIS > support in them. All the executables in these directories are linked > static, hence each has a copy of the NIS support in them. This includes > things like /bin/csh, /sbin/dump, /sbin/mountd, /sbin/mount_*, and > many more. Right now, we deal with this problem by providing replacement > executables in the DES distribution (/sbin/init and /bin/ed). But > in this case there will be a _lot_ more programs affected, and replacing > all of them just doesn't seem like a good solution to me. > > The question then is how to seperate out the DES code without actually > changing any executables. There are actually three ways, all of which > suck. It's a matter of choosing the least suckiest. [ ... ] > The very suckiest is the solution that Sun uses in Solaris, namely > the name service switch. The name service switch uses shared objects > to contain the various kinds of lookup routines: files, DNS, NIS and > NIS+. You can even create your own. The top-level lookup routines > (gethostbyname(), getpwent(), etc...) call a stub which reads the > /etc/nsswitch.conf file and dlopen()s the proper lookup modules > depending on what it finds there. Using this trick, one can supply > an NIS+ lookup module with no DES support in the core OS and a replacement > module with real DES support in the encryption kit. The problem with > this solution is that in the end, you really don't have any static > executables anymore: all programs that use the name service switch > must be linked with libdl.so. (The exception to this rule in Solaris > is /sbin/sh, which is truly static.) I've been considering this type of approach for several months now for address family support. Specifically, I've been looking for a way to implement extensions to the address family support space such that correctly written generic programs are transport independent, while current programs could continue to use header-defines (and inline stub functions, if neceaary) to get to historical interfaces. Specifically, inet_aton, inet_addr, inet_network, inet_ntoa, inet_makeaddr, inet_lnaof, inet_netof. I've been looking for this ever since Garrett murdered ISO. It seems to me that this is an acceptable, if not ideal, method of solving the problem. In any case, it should be possible to make the interfaces more abstract so that you don't implement non-reusable code (or I don't implement non-reuasble code -- whatever) and define a method of specifying a generic object file and dlopen'able list of shared objects for any given interface. Maybe "name.i" or "name.in" in /usr/lib for an interface named "name"? [ ... #2 ... ] > The third solution, which is the one I've settled on, is to create > a 'DES daemon,' i.e. a server program that does the encryption. > Since Secure RPC needs keyserv(8) to be running anyway, I decided > to (ab)use it as the encryption server. (This is another case where > the "unix" transport comes in handy: only local processes can use > the service.) Basically I turned the _des_crypt() function into a > remote procedure call: the data block to be crypted/decrypted, the > key, and other arguments are sent to keyserv, which does the work, > then sends back the results. This way, the only program that needs > to call _des_crypt() as a local function is keyserv. I guess my problem with this is "how are the guys in England going the get one without a major reengineering effort of their own?". > fixed keyserv so that it tries to dlopen() libdes.so in order to > obtain DES support rather than linking it to libdes.so at compile > time. At startup, keyserv, tries to dlopen() /usr/lib/libdes.so.3.x > and looks for the '__des_crypt()' symbol. If it finds it, it uses > that for its encryption and keyserv then operates in DES mode. If > it fails, it falls back to RC4 encryption (with a 40 bit key, just > like nutscrape). Since libdes.so is not supplied with the base OS, > keyserv will always operate in RC4 mode until you install the secure > dist. (The user can specify an alternate path for the shared lib > with a command line switch as well.) This is clever. It's probably the way the libc crypt() should be implemented by default. Is there a reason you have not considered just taking the step of linking these programs shared (option 4?)? This would resolve all of the problems simply and effectively. I believe the reasons for not running with a shared world are now largely irrelevant: the shared library dirty page library clobber bug seems to have died more than a year ago, and there is no real good reason for it. The ld.so is mapped, and is therefore an open file reference, so overwriting it only affects programs started after the overwrite; clearly, there is a need to sync boot files over system instances so that you can back up in case of a screwup. On the other hand, anyone using mount-time loaded LKM's (either intentionally or unwittingly) faces exactly the same problems of the component being invalid (for whatever reason, including a kernel mismatch, as in a proc structure change). The need to use a .so for the DES in any case requires the dlopen() implementation. Arguably, the current implementation of seperate crt0's is not correct... once could easily claim from the SVR4 EABI start address base offset that the program loader (the kernel) should be mapping the ld.so into the process address space -- it is *not* the job of ctr0 to do this for you, it is the job of the kernel itself, in the abi-specific "exec". This doesn't help a.out, which has too little room at the front to do this, but it certainly is meaningful for ELF. [ ... ] > The last sticky issue has to do with the way keyserv(8) works. > Keyserv's purpose is to store users' unencrypted secret keys. It > keeps them in memory, and they're all lost when keyserv exits. > > (The exception is root's secret key, which can be stored in > /etc/.rootkey. This is needed in case a system crashes and reboots > while the system operator is away and can't reload root's secret > key with keylogin(1). In some cases, system daemons (like rpc.ypupdated > and rpc.nisd) need root's secret key to work correctly and will > break if it's not available.) I have been thinking along similar lines to allow for support of the password/kernel_object mapping for some types of advanced applications. Specifically, it seems to me that the user's credentials should be associated with the session, and not with the process, in the kernel space. Add to this that the credentials attached to a credential pointer should be extensible. What this basically means is that for a process which you grant root credentials, you have granted all of the associated credentials at the same time. Some applications include: o SMBFS per user credentials, as required by the Microsoft server security model o NDS (NetWare Directory Services) per user credentials so that an authenticated shell user is an authenticated NetWare user o Directory-level and file-level password protection. This is required for most B-level security in any case -- I refer interested parties to the relevent Books, and to Helen Custer's _Inside Windows NT_. In point of fact, if these credentials are associated with the session, then each user credential will be a member of the same session, by definition. This kind of implies (but does not require: there is always the possibility of preauthentication vs. denial of service) a session manager that can make requests of the user based on kernel events, like credential requests for non-existant, non-cached credentials ("please enter your NetWare login:", "please enter your NetWare password", "save this password as part of your account information?", etc.). This leads to a Windows95 or WindowsNT style password cache interface. For your example of a root credential, you would ensure a saved key as part of the cached root credentials that were loaded from the cache into the kernel credentials when a root session is instantiated. > Utilities that call keyserv usually supply their UID as one of the > arguments in the RPC call. They also supply their UID in their > AUTH_UNIX credentials (keyserv requires clients to use AUTH_UNIX > creds). The problem is that there's no way for keyserv to be sure > that the client isn't lying, and it _needs_ to be sure, otherwise > a user can fool it into revealing other users' secret keys. Using the method above, and exchange can be initiated by storing a keyserv credential as part of the user credential for all created processes, and changing it per request based on a callback event. Specifically: o process calls "get keyserv credential" o kernel saves current keyserv credential o kernel sends event to keyserv saying credential has been retrieved o keyserv events kernel telling it the new credential to store as the current keyserv credential o kernel returns current keyserv credential to caller o process uses current credential to authenticate to keyserv, after which credential is invalid for future instances because it is no longer current o credentials created tis way should "time out". Since the process can only retrieve "self" credentials, and the keyserv keeps these on a per process basis, spoofing of identity will fail because the credential/process pair is unique. Any attempt to spoof will not match the one-behind. Sort of like kerberos tickets. 8-). The more I think about it, the more I want a session manager so I can open /dev/session in xdm, and when I get events, put put nice credential requestors that the user has to reply to. 8-). Regards, 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 Sun Dec 15 14:53:24 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA10868 for current-outgoing; Sun, 15 Dec 1996 14:53:24 -0800 (PST) Received: from irz201.inf.tu-dresden.de (irz201.inf.tu-dresden.de [141.76.1.10]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id OAA10863 for ; Sun, 15 Dec 1996 14:53:14 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz201.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id XAA16273; Sun, 15 Dec 1996 23:51:40 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id XAA02619; Sun, 15 Dec 1996 23:51:34 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id XAA01252; Sun, 15 Dec 1996 23:40:31 +0100 (MET) From: J Wunsch Message-Id: <199612152240.XAA01252@uriah.heep.sax.de> Subject: Re: /usr/src/sys/i386/i386/userconfig.c To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 15 Dec 1996 23:40:31 +0100 (MET) Cc: bsdcur@shadows.aeon.net (mika ruohotie) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199612151251.OAA24763@shadows.aeon.net> from mika ruohotie at "Dec 15, 96 02:51:10 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As mika ruohotie wrote: > on the line 2284 someone has been too sleepy... :p > > #incldue "eisa.h" > > =)))) Already fixed (though by `max', not by me). Nothing with too sleepy, just trying to be helpful and committed an `obvious' fix without taking the time to upgrade my entire system to -current first, and recompile it there... (which would have taken yet another 24 hours turnaround 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 Dec 15 15:23:30 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA13825 for current-outgoing; Sun, 15 Dec 1996 15:23:30 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id PAA13783 for ; Sun, 15 Dec 1996 15:23:24 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id AAA23108; Mon, 16 Dec 1996 00:22:49 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA03219; Mon, 16 Dec 1996 00:22:48 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id AAA01712; Mon, 16 Dec 1996 00:15:43 +0100 (MET) From: J Wunsch Message-Id: <199612152315.AAA01712@uriah.heep.sax.de> Subject: Re: Plan for integrating Secure RPC -- comments wanted To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Mon, 16 Dec 1996 00:15:42 +0100 (MET) Cc: wpaul@skynet.ctr.columbia.edu (Bill Paul) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199612152022.PAA05216@skynet.ctr.columbia.edu> from Bill Paul at "Dec 15, 96 03:22:39 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Bill Paul wrote: > Splitting out the DES code > --------------------------- > Right now, there are several programs in /bin and /sbin which use > NIS code as a side effect of calling libc functions that have NIS > support in them. All the executables in these directories are linked > The question then is how to seperate out the DES code without actually > changing any executables. There are actually three ways, all of which > suck. It's a matter of choosing the least suckiest. Why not using explicit dynamic linking for this? (dlopen(3)) Since you can concentrate on a single library entry point, this should be not too complicated. The point is that you try to load the shared lib only if an actual call is made to it, rather then loading every- thing before the executable starts. -- 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 Dec 15 15:54:11 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA17233 for current-outgoing; Sun, 15 Dec 1996 15:54:11 -0800 (PST) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id PAA17214 for ; Sun, 15 Dec 1996 15:53:59 -0800 (PST) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id SAA05656; Sun, 15 Dec 1996 18:51:24 -0500 From: Bill Paul Message-Id: <199612152351.SAA05656@skynet.ctr.columbia.edu> Subject: Re: Plan for integrating Secure RPC -- comments wanted To: terry@lambert.org (Terry Lambert) Date: Sun, 15 Dec 1996 18:51:23 -0500 (EST) Cc: current@freebsd.org In-Reply-To: <199612152152.OAA24022@phaeton.artisoft.com> from "Terry Lambert" at Dec 15, 96 02:52:15 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Of all the gin joints in all the towns in all the world, Terry Lambert had to walk into mine and say: > > Okay, I've decided on a final plan for integrating Secure RPC into > > the main source tree. There were a couple of problems that had to be > > dealt with which didn't have easy solutions, so I'm going to outline > > them here to give people a chance to tell me they suck, call me a looney, > > or present alternate solutions. > > [ ... much deleted ... ] > > Bill, you great big stud, you! > > 8-). You mean I'm not a looney? I'm shocked, shocked I tell you. > > loopback transport for this; BSD has no loopback transport, so I opted > > to use AF_UNIX sockets instead. (Once this change goes in, I also plan > > to modify rpc.yppasswdd to use this transport instead of the hack it > > has now.) > > The "correct" name is AF_LOCAL, not AF_UNIX, I believe (I was surprised > when I went looking... I thought it was AF_POSIX, not AF_LOCAL). It says AF_UNIX in the headers. Those interested in changing the name just so they can avoid using the word 'UNIX' without the blessing of X/Open can bite me. > > Splitting out the DES code > > --------------------------- [chop] >. The trick is to isolate the DES support in such a way > > that it can be provided seperately with a minimum of hassle to both > > us and the end users. In terms of the source code, everything ultimately > > boils down to a single function called _des_crypt(). The Secure RPC > > source distribution from Sun includes everything needed to implement > > Secure RPC _except_ this function. We need to maintain this separation. > > This is not so obvious. Specifically, there is an exportable DES in the > 4.4 sources which is used for the password facility there (they don't > use MD5, they use an exportable DES hasher). The code is a simplified > hasher which is unidirectional. I didn't bother to look to see if the > values it used were no longer table driven, but I suspect that it > might be the case. No, that's an exportable DES crypt(3), which is not the same as exportable DES. The MIT DES library can't be exported. (Although, I discovered that my 4.4BSD-Lite CD from ORA at UNIX Expo a while back includes the Kerberos IV source and the MIT DES library source. I wonder if ORA has shipped any of those CDs overseas.) Luckily, Eric Young has written his own libdes in Australia that does what the MIT library does, and more. This is the library I use for testing: it happens to have a _des_crypt() interface specifically for Secure RPC, and it's included in the secure dist. > Depnending on usage as hash *only*, you might be able to use this. > Certainly, the password stuff should use it by default to get rid of > the MD5 incompatability issues. Sorry, Secure RPC needs crypt/decrypt capabilities. Hashing won't cut it. (Secure RPC works mainly by having one side send a timestamp encrypted with DES using a conversation key. The conversation key is encrypted with your secret key and sent with the rest of the AUTH info. The other side decrypts the conversation key with your public key, then decrypts the timestamp. If any of this fails to work, you aren't authenticated.) [chop] > > The very suckiest is the solution that Sun uses in Solaris, namely > > the name service switch. The name service switch uses shared objects > > to contain the various kinds of lookup routines: files, DNS, NIS and > > NIS+. You can even create your own. The top-level lookup routines > > (gethostbyname(), getpwent(), etc...) call a stub which reads the > > /etc/nsswitch.conf file and dlopen()s the proper lookup modules > > depending on what it finds there. Using this trick, one can supply > > an NIS+ lookup module with no DES support in the core OS and a replacement > > module with real DES support in the encryption kit. The problem with > > this solution is that in the end, you really don't have any static > > executables anymore: all programs that use the name service switch > > must be linked with libdl.so. (The exception to this rule in Solaris > > is /sbin/sh, which is truly static.) > > I've been considering this type of approach for several months now > for address family support. Specifically, I've been looking for a > way to implement extensions to the address family support space > such that correctly written generic programs are transport independent, > while current programs could continue to use header-defines (and > inline stub functions, if neceaary) to get to historical interfaces. > > Specifically, inet_aton, inet_addr, inet_network, inet_ntoa, inet_makeaddr, > inet_lnaof, inet_netof. > > I've been looking for this ever since Garrett murdered ISO. > > It seems to me that this is an acceptable, if not ideal, method of > solving the problem. > > In any case, it should be possible to make the interfaces more abstract > so that you don't implement non-reusable code (or I don't implement > non-reuasble code -- whatever) and define a method of specifying a > generic object file and dlopen'able list of shared objects for any > given interface. Maybe "name.i" or "name.in" in /usr/lib for an > interface named "name"? Solaris calls them /usr/lib/nss_foo.so, where foo is compat, nis, nisplus, dns or files. I think the name service switch may work for what you have in mind, except that the lookup function behavior is meant to be controlled on a system-wide basis using /etc/nsswitch.conf. Controlling it on a per-application basis may be harder. I still haven't decided what to do when I finish NIS+ to allow the admin to select which service to use. We use the '+' hack for NIS now; without a hack similar to the name service switch, I'll need to resort to something like choosing another magic character (maybe the asterix '*') which can be substituted for '+' to specify that we want NIS+ support instead of NIS v2. This will get messier if, by some strange quirk of fate, we also get NDS support. > [ ... #2 ... ] > > > The third solution, which is the one I've settled on, is to create > > a 'DES daemon,' i.e. a server program that does the encryption. > > Since Secure RPC needs keyserv(8) to be running anyway, I decided > > to (ab)use it as the encryption server. (This is another case where > > the "unix" transport comes in handy: only local processes can use > > the service.) Basically I turned the _des_crypt() function into a > > remote procedure call: the data block to be crypted/decrypted, the > > key, and other arguments are sent to keyserv, which does the work, > > then sends back the results. This way, the only program that needs > > to call _des_crypt() as a local function is keyserv. > > I guess my problem with this is "how are the guys in England going > the get one without a major reengineering effort of their own?". I don't understand. The over the wire RPC transactions are the same. It's just local processes that call the local keyserv to encrypt/decrypt data form them. Once you drop the DES library into place, FreeBSD's Secure RPC will be compatible with all the other implementations. The 'guys in England' can just load the non-US secure dist to get Eric Young's libdes.so, and they're all set. > > fixed keyserv so that it tries to dlopen() libdes.so in order to > > obtain DES support rather than linking it to libdes.so at compile > > time. At startup, keyserv, tries to dlopen() /usr/lib/libdes.so.3.x > > and looks for the '__des_crypt()' symbol. If it finds it, it uses > > that for its encryption and keyserv then operates in DES mode. If > > it fails, it falls back to RC4 encryption (with a 40 bit key, just > > like nutscrape). Since libdes.so is not supplied with the base OS, > > keyserv will always operate in RC4 mode until you install the secure > > dist. (The user can specify an alternate path for the shared lib > > with a command line switch as well.) > > This is clever. It's probably the way the libc crypt() should be > implemented by default. Again, there's an issue with our implementation of dlopen(): the actual dlopen() function lives in crt0.o, while static binaries are linked with scrt0.o, which _doesn't_ have them. So if you link static, I don't think this will work. That's why I made it a feature of keyserv rather than a feature of libdesrpc, since programs linked static with libdesrpc.a wouldn't work. > Is there a reason you have not considered just taking the step of > linking these programs shared (option 4?)? This would resolve all > of the problems simply and effectively. Yes: I _like_ the fact that /bin and /sbin are linked static (/bin mostly). The commands there keep working in the face of a corrupted or deleted libc.so. I'm not in a hurry to change this. > I believe the reasons for not running with a shared world are now > largely irrelevant: the shared library dirty page library clobber > bug seems to have died more than a year ago, and there is no real > good reason for it. That depends on your opinion. Again, I like having some purely static binaries around to help deal in a shared lib crisis. Also, consider fsck, which needs to be run on /usr (if /usr is not on the rootfs) before /usr is mounted. We would have to move libc.so to the rootfs in order for fsck to work if it was linked dynamic. > The ld.so is mapped, and is therefore an open file reference, so > overwriting it only affects programs started after the overwrite; > clearly, there is a need to sync boot files over system instances > so that you can back up in case of a screwup. On the other hand, > anyone using mount-time loaded LKM's (either intentionally or > unwittingly) faces exactly the same problems of the component being > invalid (for whatever reason, including a kernel mismatch, as in > a proc structure change). > > The need to use a .so for the DES in any case requires the dlopen() > implementation. > > > Arguably, the current implementation of seperate crt0's is not > correct... once could easily claim from the SVR4 EABI start address > base offset that the program loader (the kernel) should be mapping > the ld.so into the process address space -- it is *not* the job of > ctr0 to do this for you, it is the job of the kernel itself, in > the abi-specific "exec". This doesn't help a.out, which has too > little room at the front to do this, but it certainly is meaningful > for ELF. What I don't understand is that in FreeBSD 2.1.x, we don't have an scrt0.o (there's just crt0.o), yet we still have static binaries. In any case, my reason for making this dependent on keyserv alone (which will always be linked shared) was so that I could avoid getting embroiled in this whole issue. :) [session credential discussion chopped -- I don't want to get embroiled in this issue either :) ] > > Utilities that call keyserv usually supply their UID as one of the > > arguments in the RPC call. They also supply their UID in their > > AUTH_UNIX credentials (keyserv requires clients to use AUTH_UNIX > > creds). The problem is that there's no way for keyserv to be sure > > that the client isn't lying, and it _needs_ to be sure, otherwise > > a user can fool it into revealing other users' secret keys. > > Using the method above, and exchange can be initiated by storing a > keyserv credential as part of the user credential for all created > processes, and changing it per request based on a callback event. > > Specifically: > > o process calls "get keyserv credential" > o kernel saves current keyserv credential > o kernel sends event to keyserv saying credential has been > retrieved > o keyserv events kernel telling it the new credential to > store as the current keyserv credential > o kernel returns current keyserv credential to caller > o process uses current credential to authenticate to keyserv, > after which credential is invalid for future instances because > it is no longer current > o credentials created tis way should "time out". > > Since the process can only retrieve "self" credentials, and the > keyserv keeps these on a per process basis, spoofing of identity > will fail because the credential/process pair is unique. Any > attempt to spoof will not match the one-behind. > > Sort of like kerberos tickets. 8-). I tried to fake this sort of thing up with message queues, though I didn't try to have keyserv authenticate itself to the user. The sequence was: - Client calls msgget() to create a message queue with 0600 perms. The kernel creates the message queue with the client's UID and GID in the ipc_perms struct as credentials. - Client generates a random number and puts it in the message queue, along with some other data. - The client sends the message queue ID number to the server as part of its AUTH_UNIX verifier along with the random number it generated earlier. - The server looks in the message queue and reads the random number, comparing it to the one sent with the AUTH_UNIX verifier. It then does the following tests: o Are the creator and owner UIDs of the queue the same? o Do they match the AUTH_UNIX UID? o Were the perms on the queue really 0600? o Does the random number from the message match the one sent with the AUTH_UNIX verifier? If the answer to all these questions is yes, then the server considers the authentication successful. It also removes the message queue, so the client needs to make a new one for each call. Again, the problem with this is that we can't count on SysV message queue support being in the kernel for us to use. You can't count on my little LKM either, but it's easier to load the LKM than to recompile the kernel. (Unless someone makes a SysV IPC LKM.) -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= From owner-freebsd-current Sun Dec 15 16:05:19 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA19376 for current-outgoing; Sun, 15 Dec 1996 16:05:19 -0800 (PST) Received: from haywire.DIALix.COM (news@haywire.DIALix.COM [192.203.228.65]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA19347 for ; Sun, 15 Dec 1996 16:05:04 -0800 (PST) Received: (from news@localhost) by haywire.DIALix.COM (8.8.3/8.8.2) id IAA05456 for freebsd-current@freebsd.org; Mon, 16 Dec 1996 08:04:35 +0800 (WST) X-Authentication-Warning: haywire.DIALix.COM: news set sender to usenet-request@haywire.dialix.com using -f Received: from GATEWAY by haywire.DIALix.COM with netnews for freebsd-current@freebsd.org (problems to: usenet@haywire.dialix.com) To: freebsd-current@freebsd.org Date: 16 Dec 1996 00:04:33 GMT From: peter@spinner.DIALix.COM (Peter Wemm) Message-ID: <5923mi$1pj$1@haywire.DIALix.COM> Organization: DIALix Services, Perth, Australia. References: <199612152022.PAA05216@skynet.ctr.columbia.edu> Subject: Re: Plan for integrating Secure RPC -- comments wanted Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199612152022.PAA05216@skynet.ctr.columbia.edu>, wpaul@skynet.ctr.columbia.edu (Bill Paul) writes: [..] > The sucky part about all this is that I would have to implement > my own name service switch and make all kinds of modifications to > the system to support it. Also, if I understand things correctly, > static executables can't call dlopen() and friends in 2.2 and 3.0 > since those functions are in crt0.o, but not in scrt0.o. I kinda offered to fix that before but never got around to it. Perhaps I should.. On SVR4.0+ systems, there are several cc/ld options. -dn and -dy control whether crt0.o or scrt0.o is used. ie: you can link with all static libs, but still have the dynamic linker present for manual dlopen(). I can implement this fairly easily, as well as putting stubs in scrt0.o. > In TI-RPC, Sun did away with keyenvoy and made keyserv use the > loopback transport. They also took advantage of certain features > in SysV networking that allow keyserv to learn the UID of the process > on the other side of the transport endpoint. (I don't quite understand > how it works, but it uses t_getinfo().) This credential information > is set by the kernel, hence it's not possible for the client to > falsify it (unless it has root privileges, but if this is the case > then system security has already been compromised and you have bigger > problems). > > Unfortunately, BSD doesn't have any equivalent mechanism for learning > the UID of a process on the other side of an AF_UNIX socket, and > we don't have STREAMS/TLI networking. This presents a serious problem > since it is vital for keyserv to have such a mechanism in order for > its security model to work. Three more options spring to mind.. 1: extend sendmsg()/recvmsg() a little so that they can pass a "credentials" structure over a local domain socket that is "certified" by the kernel. check kern/uipc_usrreq.c:unp_externalize() etc. 2: Implement a aocket ioctl() to get the credentials of the remote partner (or creator) on an AF_LOCAL connection. 3: use fd passing over the AF_LOCAL socket and/or ticket files of some sort. eg: create a pipe() as user, pass fd keyserv via sendmsg(). keyserv does an fstat() on the fd and confirms that it's a pipe. It should be able to read the stat.st_uid to get the creator. -Peter From owner-freebsd-current Sun Dec 15 16:35:47 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA22617 for current-outgoing; Sun, 15 Dec 1996 16:35:47 -0800 (PST) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id QAA22611 for ; Sun, 15 Dec 1996 16:35:37 -0800 (PST) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id TAA05740; Sun, 15 Dec 1996 19:33:37 -0500 From: Bill Paul Message-Id: <199612160033.TAA05740@skynet.ctr.columbia.edu> Subject: Re: Plan for integrating Secure RPC -- comments wanted To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 15 Dec 1996 19:33:36 -0500 (EST) Cc: current@freebsd.org In-Reply-To: <199612152315.AAA01712@uriah.heep.sax.de> from "J Wunsch" at Dec 16, 96 00:15:42 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org X-Loop: 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: > As Bill Paul wrote: > > > Splitting out the DES code > > --------------------------- > > > Right now, there are several programs in /bin and /sbin which use > > NIS code as a side effect of calling libc functions that have NIS > > support in them. All the executables in these directories are linked > > > The question then is how to seperate out the DES code without actually > > changing any executables. There are actually three ways, all of which > > suck. It's a matter of choosing the least suckiest. > > Why not using explicit dynamic linking for this? (dlopen(3)) Since > you can concentrate on a single library entry point, this should be > not too complicated. The point is that you try to load the shared > lib only if an actual call is made to it, rather then loading every- > thing before the executable starts. Because that would put the dlopen() call in libdesrpc.{so,a} and that in turn would put it inside static binaries in /bin and /sbin, which doesn't currently work since dlopen() doesn't exist in scrt0.o. Putting it in keyserv works because I know keyserv will be dynamically linked. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= From owner-freebsd-current Sun Dec 15 17:04:34 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA25038 for current-outgoing; Sun, 15 Dec 1996 17:04:34 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA25027 for ; Sun, 15 Dec 1996 17:04:30 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.3/CET-v2.1) with SMTP id BAA24101; Mon, 16 Dec 1996 01:04:21 GMT Date: Mon, 16 Dec 1996 10:04:21 +0900 (JST) From: Michael Hancock To: "John S. Dyson" cc: current@freebsd.org Subject: Re: Warning -- Lite/2 merge coming up In-Reply-To: <199612150431.XAA07652@dyson.iquest.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 14 Dec 1996, John S. Dyson wrote: > Fair warning: > > I am about 2/3's way through a merge of Lite/2 with -current (Jeffery Hsu > et. al. work.) By about Tue or Wed, I'll be committing the changes. Does this include MSDOSFS? I don't remember any volunteering for this on the lite2 list. Mike From owner-freebsd-current Sun Dec 15 17:22:50 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA26633 for current-outgoing; Sun, 15 Dec 1996 17:22:50 -0800 (PST) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA26625 for ; Sun, 15 Dec 1996 17:22:44 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id UAA05850; Sun, 15 Dec 1996 20:22:43 -0500 (EST) From: "John S. Dyson" Message-Id: <199612160122.UAA05850@dyson.iquest.net> Subject: Re: Warning -- Lite/2 merge coming up To: michaelh@cet.co.jp (Michael Hancock) Date: Sun, 15 Dec 1996 20:22:43 -0500 (EST) Cc: toor@dyson.iquest.net, current@freebsd.org In-Reply-To: from "Michael Hancock" at Dec 16, 96 10:04:21 am 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 X-Loop: FreeBSD.org Precedence: bulk > On Sat, 14 Dec 1996, John S. Dyson wrote: > > > Fair warning: > > > > I am about 2/3's way through a merge of Lite/2 with -current (Jeffery Hsu > > et. al. work.) By about Tue or Wed, I'll be committing the changes. > > Does this include MSDOSFS? I don't remember any volunteering for this on > the lite2 list. > I am merging in Jeff Hsu's work on the tree. I am not doing anything special regarding MSDOSFS. Note that -current (and now 2.2-XXXXX) has the MSDOSFS (actually VFS) code fix. John From owner-freebsd-current Sun Dec 15 18:05:15 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id SAA29948 for current-outgoing; Sun, 15 Dec 1996 18:05:15 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id SAA29929 for ; Sun, 15 Dec 1996 18:05:12 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.3/CET-v2.1) with SMTP id CAA24509; Mon, 16 Dec 1996 02:05:04 GMT Date: Mon, 16 Dec 1996 11:05:04 +0900 (JST) From: Michael Hancock Reply-To: Michael Hancock To: "John S. Dyson" cc: current@freebsd.org Subject: Re: Warning -- Lite/2 merge coming up In-Reply-To: <199612160122.UAA05850@dyson.iquest.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 15 Dec 1996, John S. Dyson wrote: > > > I am about 2/3's way through a merge of Lite/2 with -current (Jeffery Hsu > > > et. al. work.) By about Tue or Wed, I'll be committing the changes. > > > > Does this include MSDOSFS? I don't remember any volunteering for this on > > the lite2 list. > > > I am merging in Jeff Hsu's work on the tree. I am not doing anything > special regarding MSDOSFS. Note that -current (and now 2.2-XXXXX) > has the MSDOSFS (actually VFS) code fix. Do the merges include lock_mgr and simple_lock, etc.? If so, then MSDOSFS would have to be changed to lite2 conventions. Doug posted some guidelines on the lite2 list. I guess I can forward these to Robert Nordier if he's around. Regards, Mike Hancock From owner-freebsd-current Sun Dec 15 18:46:08 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id SAA02311 for current-outgoing; Sun, 15 Dec 1996 18:46:08 -0800 (PST) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id SAA02306 for ; Sun, 15 Dec 1996 18:46:05 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id VAA06022; Sun, 15 Dec 1996 21:46:05 -0500 (EST) From: "John S. Dyson" Message-Id: <199612160246.VAA06022@dyson.iquest.net> Subject: Re: Warning -- Lite/2 merge coming up To: michaelh@cet.co.jp Date: Sun, 15 Dec 1996 21:46:05 -0500 (EST) Cc: toor@dyson.iquest.net, current@FreeBSD.ORG In-Reply-To: from "Michael Hancock" at Dec 16, 96 11:05:04 am 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 X-Loop: FreeBSD.org Precedence: bulk > On Sun, 15 Dec 1996, John S. Dyson wrote: > > > > > I am about 2/3's way through a merge of Lite/2 with -current (Jeffery Hsu > > > > et. al. work.) By about Tue or Wed, I'll be committing the changes. > > > > > > Does this include MSDOSFS? I don't remember any volunteering for this on > > > the lite2 list. > > > > > I am merging in Jeff Hsu's work on the tree. I am not doing anything > > special regarding MSDOSFS. Note that -current (and now 2.2-XXXXX) > > has the MSDOSFS (actually VFS) code fix. > > Do the merges include lock_mgr and simple_lock, etc.? > They will be in the code. However, not all of the code will be ported to use it yet (e.g. VM code -- since ours is new.) John From owner-freebsd-current Sun Dec 15 20:45:54 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA06361 for current-outgoing; Sun, 15 Dec 1996 20:45:54 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id UAA06356 for ; Sun, 15 Dec 1996 20:45:51 -0800 (PST) From: proff@suburbia.net Received: from suburbia.net ([203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id UAA01404 for ; Sun, 15 Dec 1996 20:46:19 -0800 (PST) Received: (qmail 3292 invoked by uid 110); 16 Dec 1996 04:45:20 -0000 Message-ID: <19961216044520.3291.qmail@suburbia.net> Subject: Re: ed0 trouble with -current In-Reply-To: <199612151324.WAA01789@mail.tky007.tth.expo96.ad.jp> from =?us-ascii?Q?Masafumi_NAKANE=2F=3D=3FISO=2D2022=2DJP=3FB=3FGy?= =?us-ascii?Q?RCQ2Y6LDJtSjgbKEI=3D=3F=3D?= at "Dec 15, 96 10:24:10 pm" To: max@wide.ad.jp (Masafumi NAKANE/=?ISO-2022-JP?B?GyRCQ2Y6LDJtSjgbKEI=?=) Date: Mon, 16 Dec 1996 15:45:20 +1100 (EST) Cc: current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I did `make world' today using current sources (ctm delta up to 2517 > applied) and found out that ed0 driver doesn't work like it used to. > > It looks like ed0 can receive incoming packets without problems, but > it can't send out outgoing packets. If I do ping to the local gateway > router, it says `host is down' although it isn't. > > ----------------------------------------------------------------------- > Masafumi NAKANE, Keio Univ., Dept. of Environmental Information > E-Mail : max@wide.ad.jp / max@FreeBSD.ORG > [URL] : http://www.sfc.wide.ad.jp/~max/ > This is because the machine is no-longer responsing to arp requests, though it is sending them ok. I've suffering the same problem with -current also. -Julian From owner-freebsd-current Sun Dec 15 20:55:00 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA06638 for current-outgoing; Sun, 15 Dec 1996 20:55:00 -0800 (PST) Received: from eac.iafrica.com (196-7-192-100.iafrica.com [196.7.192.100]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id UAA06628 for ; Sun, 15 Dec 1996 20:54:53 -0800 (PST) Received: (from rnordier@localhost) by eac.iafrica.com (8.7.6/8.6.12) id GAA00822; Mon, 16 Dec 1996 06:50:07 +0200 (SAT) From: Robert Nordier Message-Id: <199612160450.GAA00822@eac.iafrica.com> Subject: Re: Warning -- Lite/2 merge coming up In-Reply-To: from Michael Hancock at "Dec 16, 96 11:05:04 am" To: michaelh@cet.co.jp Date: Mon, 16 Dec 1996 06:50:06 +0200 (SAT) Cc: toor@dyson.iquest.net, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Michael Hancock wrote: > > I am merging in Jeff Hsu's work on the tree. I am not doing anything > > special regarding MSDOSFS. Note that -current (and now 2.2-XXXXX) > > has the MSDOSFS (actually VFS) code fix. > > Do the merges include lock_mgr and simple_lock, etc.? > > If so, then MSDOSFS would have to be changed to lite2 conventions. Doug > posted some guidelines on the lite2 list. I guess I can forward these to > Robert Nordier if he's around. Thanks. I've done the lock changes in the new DOS FS (vfatfs). If necessary, I don't mind adding these to the MSDOSFS. -- Robert Nordier From owner-freebsd-current Sun Dec 15 21:06:35 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id VAA06898 for current-outgoing; Sun, 15 Dec 1996 21:06:35 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id VAA06893 for ; Sun, 15 Dec 1996 21:06:32 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.3/CET-v2.1) with SMTP id FAA25471; Mon, 16 Dec 1996 05:06:19 GMT Date: Mon, 16 Dec 1996 14:06:19 +0900 (JST) From: Michael Hancock To: Robert Nordier cc: toor@dyson.iquest.net, current@FreeBSD.ORG Subject: Re: Warning -- Lite/2 merge coming up In-Reply-To: <199612160450.GAA00822@eac.iafrica.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 16 Dec 1996, Robert Nordier wrote: > > Do the merges include lock_mgr and simple_lock, etc.? > > > > If so, then MSDOSFS would have to be changed to lite2 conventions. Doug > > posted some guidelines on the lite2 list. I guess I can forward these to > > Robert Nordier if he's around. > > Thanks. I've done the lock changes in the new DOS FS (vfatfs). If > necessary, I don't mind adding these to the MSDOSFS. Umm. Almost sounds like we can nuke MSDOSFS. Just thinking out loud, Mike Hancock From owner-freebsd-current Sun Dec 15 22:35:08 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA09783 for current-outgoing; Sun, 15 Dec 1996 22:35:08 -0800 (PST) Received: from grackle.grondar.za (uHq6EUhKSuvDWDvox30OxnT4CaPZhu8f@grackle.grondar.za [196.7.18.131]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id WAA09771 for ; Sun, 15 Dec 1996 22:35:02 -0800 (PST) Received: from grackle.grondar.za (s5a3QyM3xdro7JMmLhBhtz6TYyDRMIq/@localhost [127.0.0.1]) by grackle.grondar.za (8.8.4/8.8.4) with ESMTP id IAA24158; Mon, 16 Dec 1996 08:34:26 +0200 (SAT) Message-Id: <199612160634.IAA24158@grackle.grondar.za> To: Bill Paul cc: current@freebsd.org Subject: Re: Plan for integrating Secure RPC -- comments wanted Date: Mon, 16 Dec 1996 08:34:25 +0200 From: Mark Murray Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Okay, I've decided on a final plan for integrating Secure RPC into > the main source tree. There were a couple of problems that had to be > dealt with which didn't have easy solutions, so I'm going to outline > them here to give people a chance to tell me they suck, call me a looney, > or present alternate solutions. YeeeeHaaaa! [snip] > Adding new authentication flavors > --------------------------------- [snip] > My other motivation for this is to allow the AUTH_GSSAPI authentication > code in the Kerberos V distribution to be added without having to > modify libc. The AUTH_GSSAPI implementation is provided as a completely > seperate version of the RPCSRC 4.0 library. If the code is imported > into the system as is, we will end up with two seperate RPC libraries > in the tree. This is pretty wasteful, and unnecessary if the RPC code > in libc allows new flavors to be added without modifying any code. Great! This will still allow that kluged AUTH struct in K5's RPC lib? Or does that have to be thrown out of the window? [snip] > The very suckiest is the solution that Sun uses in Solaris, namely > the name service switch. The name service switch uses shared objects > to contain the various kinds of lookup routines: files, DNS, NIS and > NIS+. You can even create your own. The top-level lookup routines Eugh... [snip] > The second solution is to put the DES support in the kernel. It's > possible to create a syscall LKM that implements the _des_crypt() > function and have libdesrpc call this system call instead of a > library function. A dummy LKM could be supplied with the core OS > that does no DES at all (or uses some other cipher that is exportable), > while a real DES LKM could be shipped with the secure dist. In this > case, no executables would have to be changed at all. Thus has distinct potential. A lightweight LKM that just xors the key to of the plaintext to generate a cipher (or something else that is weak and therefore both fast and exportable) would be OK. > The sucky part about this is that it bloats the kernel. It also has > 'kludge' written all over it in big red letters. I dunno - kernels can be made more secure than userland. > The third solution, which is the one I've settled on, is to create > a 'DES daemon,' i.e. a server program that does the encryption. [snip] Pretty good, but isn't it a little heavyweight? I could certainly live very happily with it, though. > The end result: you don't need to replace keyserv at all. To enable > DES support, you just copy libdes.so.3.x to /usr/lib, then restart > keyserv. Presto! You have real AUTH_DES support. No muss, no fuss, > no recompiling, no switching keyserv executables. :-) > The sucky part is that calling _des_crypt() as an RPC is slower > than calling it as a local function. Using an AF_UNIX socket helps > a little since the kernel doesn't have to do any protocol processing, > but it's still slower. (This also makes Secure RPC programs dependent > on keyserv, but in fact they're already dependent on keyserv anyway > because of how Secure RPC works.) Slowness helps prevent dictionary attacks - or am I talking crap in this instance? [snip] > - Adding new RPC authentication flavors: use svc_auth_reg() and supply > the code in a seperate library. Wonderful! > - Segregating the DES crypto code: move it all into keyserv(8) and > access it via remote procedure calls. (Also support runtime dynamic > loading of the libdes library and use RC4 as a replacement if DES > is unavailable.) My hero! > - Allowing keyserv to authenticate local clients: use a special system > call supplied as a loadable kernel module. Mumble - this sounds kinda klugy to me. I can live with it, though. > If nobody complains strenuously about any of this, I'm going to go > ahead and start importing things using this plan in a few weeks. (I > still need to finish rpc.ypupdated.) Comments, criticisms, screams > of terror, or large bags of cash are welcome and encouraged. I'm voting for you to go for it... M -- Mark Murray PGP key fingerprint = 80 36 6E 40 83 D6 8A 36 This .sig is umop ap!sdn. BC 06 EA 0E 7A F2 CE CE From owner-freebsd-current Sun Dec 15 23:13:30 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA10979 for current-outgoing; Sun, 15 Dec 1996 23:13:30 -0800 (PST) Received: from grackle.grondar.za (d2BcnkhvnsDPv5ObLKAJpP0JcyZbHI3/@grackle.grondar.za [196.7.18.131]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id XAA10972 for ; Sun, 15 Dec 1996 23:13:24 -0800 (PST) Received: from grackle.grondar.za (r4EHXi3hCC/wr9wQqxqAb9udE/AgbkHJ@localhost [127.0.0.1]) by grackle.grondar.za (8.8.4/8.8.4) with ESMTP id JAA24440; Mon, 16 Dec 1996 09:13:08 +0200 (SAT) Message-Id: <199612160713.JAA24440@grackle.grondar.za> To: "John S. Dyson" cc: current@freebsd.org Subject: Re: Warning -- Lite/2 merge coming up Date: Mon, 16 Dec 1996 09:13:06 +0200 From: Mark Murray Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "John S. Dyson" wrote: > > > I am about 2/3's way through a merge of Lite/2 with -current (Jeffery Hsu > > > et. al. work.) By about Tue or Wed, I'll be committing the changes. > > > > Does this include MSDOSFS? I don't remember any volunteering for this on > > the lite2 list. > > > I am merging in Jeff Hsu's work on the tree. I am not doing anything > special regarding MSDOSFS. Note that -current (and now 2.2-XXXXX) > has the MSDOSFS (actually VFS) code fix. What about the other broken FS's, like union and null? M -- Mark Murray PGP key fingerprint = 80 36 6E 40 83 D6 8A 36 This .sig is umop ap!sdn. BC 06 EA 0E 7A F2 CE CE From owner-freebsd-current Sun Dec 15 23:46:41 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA11734 for current-outgoing; Sun, 15 Dec 1996 23:46:41 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id XAA11728 for ; Sun, 15 Dec 1996 23:46:37 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.3/CET-v2.1) with SMTP id HAA26518; Mon, 16 Dec 1996 07:46:22 GMT Date: Mon, 16 Dec 1996 16:46:22 +0900 (JST) From: Michael Hancock To: Mark Murray cc: "John S. Dyson" , current@freebsd.org Subject: Re: Warning -- Lite/2 merge coming up In-Reply-To: <199612160713.JAA24440@grackle.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 16 Dec 1996, Mark Murray wrote: > "John S. Dyson" wrote: > > > > I am about 2/3's way through a merge of Lite/2 with -current (Jeffery Hsu > > > > et. al. work.) By about Tue or Wed, I'll be committing the changes. > > > > > > Does this include MSDOSFS? I don't remember any volunteering for this on > > > the lite2 list. > > > > > I am merging in Jeff Hsu's work on the tree. I am not doing anything > > special regarding MSDOSFS. Note that -current (and now 2.2-XXXXX) > > has the MSDOSFS (actually VFS) code fix. > > What about the other broken FS's, like union and null? > The problems aren't addressed by Lite2. Regards, Mike Hancock From owner-freebsd-current Mon Dec 16 00:36:19 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id AAA12851 for current-outgoing; Mon, 16 Dec 1996 00:36:19 -0800 (PST) Received: from btp1da.phy.uni-bayreuth.de (btp1da.phy.uni-bayreuth.de [132.180.20.32]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id AAA12846 for ; Mon, 16 Dec 1996 00:36:14 -0800 (PST) Received: (from root@localhost) by btp1da.phy.uni-bayreuth.de (8.8.4/8.7.3) id JAA00552 for current@freebsd.org; Mon, 16 Dec 1996 09:35:36 +0100 (MET) From: Werner Griessl Message-Id: <199612160835.JAA00552@btp1da.phy.uni-bayreuth.de> Subject: boot hangs To: current@freebsd.org Date: Mon, 16 Dec 1996 09:35:35 +0100 (MET) X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Boot on newest current from today (Mon Dec 16) hangs: Probing for devices on PCI bus 0: chip0 rev 1 on pci0:0 chip1 rev 1 on pci0:7:0 chip2 rev 0 on pci0:7:1 vga0 rev 84 int a irq 11 on pci0:14 ncr0 rev 17 int a irq 10 on pci0:15 (ncr0:0:0): 200ns (5 Mb/sec) offset 8. should continue with: (ncr0:0:0): "IBM OEM 0664M1H 7 70" type 0 fixed SCSI 2 sd0(ncr0:0:0): Direct-Access sd0(ncr0:0:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. 1920MB (3933040 512 byte sectors) System is working with kernel from last Friday. Werner From owner-freebsd-current Mon Dec 16 02:45:26 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id CAA17986 for current-outgoing; Mon, 16 Dec 1996 02:45:26 -0800 (PST) Received: from mail.tky007.tth.expo96.ad.jp (root@tky007.tth.expo96.ad.jp [133.246.32.58]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id CAA17981 for ; Mon, 16 Dec 1996 02:45:22 -0800 (PST) Received: from tky007.tth.expo96.ad.jp (masafumi@localhost [127.0.0.1]) by mail.tky007.tth.expo96.ad.jp (8.8.4/3.4W4-SMTP) with ESMTP id TAA00447; Mon, 16 Dec 1996 19:43:26 +0900 (JST) Message-Id: <199612161043.TAA00447@mail.tky007.tth.expo96.ad.jp> To: proff@suburbia.net Cc: max@wide.ad.jp, current@freebsd.org Subject: Re: ed0 trouble with -current From: Masafumi NAKANE/=?ISO-2022-JP?B?GyRCQ2Y6LDJtSjgbKEI=?= In-Reply-To: Your message of "Mon, 16 Dec 1996 15:45:20 +1100 (EST)" References: <19961216044520.3291.qmail@suburbia.net> X-Mailer: Mew version 1.54 on Emacs 19.28.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 16 Dec 1996 19:43:23 +0900 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk proff> This is because the machine is no-longer responsing to arp proff> requests, though it is sending them ok. I've suffering the proff> same problem with -current also. Try the latest sources. This has been fixed. Max From owner-freebsd-current Mon Dec 16 03:40:28 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id DAA20393 for current-outgoing; Mon, 16 Dec 1996 03:40:28 -0800 (PST) Received: from mail.tky007.tth.expo96.ad.jp (root@tky007.tth.expo96.ad.jp [133.246.32.58]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id DAA20379 for ; Mon, 16 Dec 1996 03:40:23 -0800 (PST) Received: from tky007.tth.expo96.ad.jp (masafumi@localhost [127.0.0.1]) by mail.tky007.tth.expo96.ad.jp (8.8.4/3.4W4-SMTP) with ESMTP id UAA07523; Mon, 16 Dec 1996 20:40:24 +0900 (JST) Message-Id: <199612161140.UAA07523@mail.tky007.tth.expo96.ad.jp> To: current@freebsd.org Cc: max@wide.ad.jp Subject: Error with current ncr.c From: Masafumi NAKANE/=?ISO-2022-JP?B?GyRCQ2Y6LDJtSjgbKEI=?= X-Mailer: Mew version 1.54 on Emacs 19.28.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 16 Dec 1996 20:40:23 +0900 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk /sys/pci/ncr.c attempts to include opt_ncr.h which seems to be nonexistent. Please check on this. Max From owner-freebsd-current Mon Dec 16 03:49:48 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id DAA20823 for current-outgoing; Mon, 16 Dec 1996 03:49:48 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id DAA20818 for ; Mon, 16 Dec 1996 03:49:45 -0800 (PST) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id DAA07910 for ; Mon, 16 Dec 1996 03:50:09 -0800 (PST) Received: (qmail 9980 invoked by uid 110); 16 Dec 1996 11:49:05 -0000 Message-ID: <19961216114905.9979.qmail@suburbia.net> Subject: Re: ed0 trouble with -current In-Reply-To: <199612161043.TAA00447@mail.tky007.tth.expo96.ad.jp> from =?us-ascii?Q?Masafumi_NAKANE=2F=3D=3FISO=2D2022=2DJP=3FB=3FGy?= =?us-ascii?Q?RCQ2Y6LDJtSjgbKEI=3D=3F=3D?= at "Dec 16, 96 07:43:23 pm" To: max@wide.ad.jp (Masafumi NAKANE/=?ISO-2022-JP?B?GyRCQ2Y6LDJtSjgbKEI=?=) Date: Mon, 16 Dec 1996 22:49:05 +1100 (EST) Cc: current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > proff> This is because the machine is no-longer responsing to arp > proff> requests, though it is sending them ok. I've suffering the > proff> same problem with -current also. > > Try the latest sources. This has been fixed. > > Max > Unfortunately at the expense of all host based traffic. Not even loopback. Forwarding still works though ;) Cheers, Julian. From owner-freebsd-current Mon Dec 16 04:26:40 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id EAA23124 for current-outgoing; Mon, 16 Dec 1996 04:26:40 -0800 (PST) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id EAA23112 for ; Mon, 16 Dec 1996 04:26:37 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr2-37.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA07462 (5.67b/IDA-1.5 for ); Mon, 16 Dec 1996 13:25:18 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.4/8.6.9) id NAA00660; Mon, 16 Dec 1996 13:25:15 +0100 (CET) Message-Id: Date: Mon, 16 Dec 1996 13:25:15 +0100 From: se@freebsd.org (Stefan Esser) To: croot@btp1da.phy.uni-bayreuth.de (Werner Griessl) Cc: current@freebsd.org Subject: Re: boot hangs References: <199612160835.JAA00552@btp1da.phy.uni-bayreuth.de> X-Mailer: Mutt 0.53 Mime-Version: 1.0 In-Reply-To: <199612160835.JAA00552@btp1da.phy.uni-bayreuth.de>; from Werner Griessl on Dec 16, 1996 09:35:35 +0100 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Dec 16, croot@btp1da.phy.uni-bayreuth.de (Werner Griessl) wrote: > > Boot on newest current from today (Mon Dec 16) hangs: > > Probing for devices on PCI bus 0: > chip0 rev 1 on pci0:0 > chip1 rev 1 on pci0:7:0 > chip2 rev 0 on pci0:7:1 > vga0 rev 84 int a irq 11 on pci0:14 > ncr0 rev 17 int a irq 10 on pci0:15 > (ncr0:0:0): 200ns (5 Mb/sec) offset 8. > > > should continue with: > (ncr0:0:0): "IBM OEM 0664M1H 7 70" type 0 fixed SCSI 2 > sd0(ncr0:0:0): Direct-Access > sd0(ncr0:0:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. > 1920MB (3933040 512 byte sectors) > > System is working with kernel from last Friday. > Werner Hmmm, that is definitely bad news ... I commited a few patches a few days ago, and those seem to affect you ... (But they were tested, I'm writing this reply on a system with exactly that NCR driver with one Quantum Atlas and one IBM DORS drive connected to two NCR cards ...) I'll re-check the patches immediately. Please let me know, if anybody else is affected! Regards, STefan From owner-freebsd-current Mon Dec 16 05:04:49 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA26862 for current-outgoing; Mon, 16 Dec 1996 05:04:49 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id FAA26850 for ; Mon, 16 Dec 1996 05:04:46 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0vZci4-0003vuC; Mon, 16 Dec 96 05:03 PST Received: from critter.tfs.com (localhost [127.0.0.1]) by critter.tfs.com (8.8.2/8.8.2) with ESMTP id NAA11682; Mon, 16 Dec 1996 13:48:06 +0100 (MET) To: Bill Paul cc: current@freebsd.org Subject: Re: Plan for integrating Secure RPC -- comments wanted In-reply-to: Your message of "Sun, 15 Dec 1996 15:22:39 EST." <199612152022.PAA05216@skynet.ctr.columbia.edu> Date: Mon, 16 Dec 1996 13:48:06 +0100 Message-ID: <11680.850740486@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199612152022.PAA05216@skynet.ctr.columbia.edu>, Bill Paul writes: Hi Bill, Thanks for sharing your thoughts on this. I finally found time to read it, and here are my comments: For the DES pollution: Put DES in the kernel. This could be as an LKM, which would be the easiest, or as a proper kernel-source file, which would be slightly harder to manage distributions-wise. Result: * You avoid your planned hack. * We could do away with the two versions if libcrypt we have now, and collapse them into one. * Which makes the dual versions of /bin/ed, /sbin/init ... unneeded. * Our secure dist would consist of only the LKM file. Drawback: * Minor optional kernel bloat. For the issue of a secure local transport: Wouldn't it be pretty easy to fortify our IP implementation a bit ? 1. reject anything with source/dest 127.0.0.0/8 on anything but the lo0 interface. (Add a interface flag for this and only set that flag in if_lo.c) 2. In the case of a destination of 0.0.0.0, Instead of the first interface we happen to find, use the lo0 interface and the 127.0.0.1 address. This way you could use tcp/udp and be safe I belive. For the issue of authenticated local transport: Instead of an LKM, put the code in the kernel. It shouldn't be too hard to make it a getsockopt() instead of a LKM. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-current Mon Dec 16 05:06:51 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA27123 for current-outgoing; Mon, 16 Dec 1996 05:06:51 -0800 (PST) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id FAA27091 for ; Mon, 16 Dec 1996 05:06:39 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr2-37.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA09165 (5.67b/IDA-1.5 for ); Mon, 16 Dec 1996 14:06:36 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.4/8.6.9) id OAA02157; Mon, 16 Dec 1996 14:06:34 +0100 (CET) Message-Id: Date: Mon, 16 Dec 1996 14:06:33 +0100 From: se@freebsd.org (Stefan Esser) To: max@wide.ad.jp (Masafumi NAKANE/=?ISO-2022-JP?B?GyRCQ2Y6LDJtSjgbKEI=?=) Cc: current@freebsd.org, max@wide.ad.jp Subject: Re: Error with current ncr.c References: <199612161140.UAA07523@mail.tky007.tth.expo96.ad.jp> X-Mailer: Mutt 0.53 Mime-Version: 1.0 In-Reply-To: <199612161140.UAA07523@mail.tky007.tth.expo96.ad.jp>; from Masafumi NAKANE/=?ISO-2022-JP?B?GyRCQ2Y6LDJtSjgbKEI=?= on Dec 16, 1996 20:40:23 +0900 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Dec 16, max@wide.ad.jp (Masafumi NAKANE/=?ISO-2022-JP?B?GyRCQ2Y6LDJtSjgbKEI=?=) wrote: > /sys/pci/ncr.c attempts to include opt_ncr.h which seems to be > nonexistent. Please check on this. Did you remember to rerun "config " ? Regards, STefan From owner-freebsd-current Mon Dec 16 05:20:39 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA28518 for current-outgoing; Mon, 16 Dec 1996 05:20:39 -0800 (PST) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id FAA28512 for ; Mon, 16 Dec 1996 05:20:35 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id IAA06815; Mon, 16 Dec 1996 08:20:27 -0500 (EST) From: "John S. Dyson" Message-Id: <199612161320.IAA06815@dyson.iquest.net> Subject: Re: Warning -- Lite/2 merge coming up To: mark@grondar.za (Mark Murray) Date: Mon, 16 Dec 1996 08:20:27 -0500 (EST) Cc: toor@dyson.iquest.net, current@freebsd.org In-Reply-To: <199612160713.JAA24440@grackle.grondar.za> from "Mark Murray" at Dec 16, 96 09:13:06 am 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 X-Loop: FreeBSD.org Precedence: bulk > > "John S. Dyson" wrote: > > > > I am about 2/3's way through a merge of Lite/2 with -current (Jeffery Hsu > > > > et. al. work.) By about Tue or Wed, I'll be committing the changes. > > > > > > Does this include MSDOSFS? I don't remember any volunteering for this on > > > the lite2 list. > > > > > I am merging in Jeff Hsu's work on the tree. I am not doing anything > > special regarding MSDOSFS. Note that -current (and now 2.2-XXXXX) > > has the MSDOSFS (actually VFS) code fix. > > What about the other broken FS's, like union and null? > We have been holding off until the Lite/2 merge. Lite/2 might fix some of the problems. John From owner-freebsd-current Mon Dec 16 05:23:37 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA28748 for current-outgoing; Mon, 16 Dec 1996 05:23:37 -0800 (PST) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id FAA28740 for ; Mon, 16 Dec 1996 05:23:34 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id IAA06838; Mon, 16 Dec 1996 08:23:31 -0500 (EST) From: "John S. Dyson" Message-Id: <199612161323.IAA06838@dyson.iquest.net> Subject: Re: Warning -- Lite/2 merge coming up To: michaelh@cet.co.jp (Michael Hancock) Date: Mon, 16 Dec 1996 08:23:31 -0500 (EST) Cc: rnordier@iafrica.com, toor@dyson.iquest.net, current@FreeBSD.ORG In-Reply-To: from "Michael Hancock" at Dec 16, 96 02:06:19 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 X-Loop: FreeBSD.org Precedence: bulk > On Mon, 16 Dec 1996, Robert Nordier wrote: > > > > Do the merges include lock_mgr and simple_lock, etc.? > > > > > > If so, then MSDOSFS would have to be changed to lite2 conventions. Doug > > > posted some guidelines on the lite2 list. I guess I can forward these to > > > Robert Nordier if he's around. > > > > Thanks. I've done the lock changes in the new DOS FS (vfatfs). If > > necessary, I don't mind adding these to the MSDOSFS. > > Umm. Almost sounds like we can nuke MSDOSFS. > > Just thinking out loud, > Once I get Lite/2 committed, I suggest that we put Robert's filesystem in parallel with MSDOSFS (so that we can test AND continue to have the old filesystem.) Eventually, in a few weeks we could probably drop MSDOSFS and keep Robert's new one. John From owner-freebsd-current Mon Dec 16 05:45:12 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA01420 for current-outgoing; Mon, 16 Dec 1996 05:45:12 -0800 (PST) Received: from mail.tky007.tth.expo96.ad.jp (root@tky007.tth.expo96.ad.jp [133.246.32.58]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id FAA01092; Mon, 16 Dec 1996 05:42:55 -0800 (PST) Received: from tky007.tth.expo96.ad.jp (masafumi@localhost [127.0.0.1]) by mail.tky007.tth.expo96.ad.jp (8.8.4/3.4W4-SMTP) with ESMTP id WAA08571; Mon, 16 Dec 1996 22:42:55 +0900 (JST) Message-Id: <199612161342.WAA08571@mail.tky007.tth.expo96.ad.jp> To: se@freebsd.org Cc: max@wide.ad.jp, current@freebsd.org Subject: Re: Error with current ncr.c From: Masafumi NAKANE/=?ISO-2022-JP?B?GyRCQ2Y6LDJtSjgbKEI=?= In-Reply-To: Your message of "Mon, 16 Dec 1996 14:06:33 +0100" References: X-Mailer: Mew version 1.54 on Emacs 19.28.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 16 Dec 1996 22:42:55 +0900 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> /sys/pci/ncr.c attempts to include opt_ncr.h which seems to be >> nonexistent. Please check on this. se> Did you remember to rerun "config " ? Oops, I didn't probably run config. However, even having run config, make in /usr/src/usr.sbin/ncrcontrol would fail as cpp can't find opt_ncr.h in /sys/compile/WHATEVER. This of course makes `make world' break. We need some workaround for this. Cheers, Max From owner-freebsd-current Mon Dec 16 06:14:50 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA05096 for current-outgoing; Mon, 16 Dec 1996 06:14:50 -0800 (PST) Received: from grackle.grondar.za (ccXkq0rFg6DHY+73Ek2+wOZiCa855UvR@grackle.grondar.za [196.7.18.131]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id GAA05085 for ; Mon, 16 Dec 1996 06:14:46 -0800 (PST) Received: from grackle.grondar.za (ls04KsIIj/4WqlsG6UTt+vuRVN7L6H4H@localhost [127.0.0.1]) by grackle.grondar.za (8.8.4/8.8.4) with ESMTP id QAA20372; Mon, 16 Dec 1996 16:14:28 +0200 (SAT) Message-Id: <199612161414.QAA20372@grackle.grondar.za> To: "John S. Dyson" cc: current@FreeBSD.ORG Subject: Re: Warning -- Lite/2 merge coming up Date: Mon, 16 Dec 1996 16:14:25 +0200 From: Mark Murray Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk "John S. Dyson" wrote: > > What about the other broken FS's, like union and null? > > > We have been holding off until the Lite/2 merge. Lite/2 might fix > some of the problems. Thanks! (These broken FS's are our oldest bug, I believe) -- Mark Murray PGP key fingerprint = 80 36 6E 40 83 D6 8A 36 This .sig is umop ap!sdn. BC 06 EA 0E 7A F2 CE CE From owner-freebsd-current Mon Dec 16 06:16:26 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA05298 for current-outgoing; Mon, 16 Dec 1996 06:16:26 -0800 (PST) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id GAA04878; Mon, 16 Dec 1996 06:13:19 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr2-41.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA11746 (5.67b/IDA-1.5); Mon, 16 Dec 1996 15:08:10 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.4/8.6.9) id PAA02771; Mon, 16 Dec 1996 15:08:08 +0100 (CET) Message-Id: Date: Mon, 16 Dec 1996 15:08:08 +0100 From: se@freebsd.org (Stefan Esser) To: max@wide.ad.jp (Masafumi NAKANE/=?ISO-2022-JP?B?GyRCQ2Y6LDJtSjgbKEI=?=) Cc: se@freebsd.org, max@wide.ad.jp, current@freebsd.org Subject: Re: Error with current ncr.c References: <199612161342.WAA08571@mail.tky007.tth.expo96.ad.jp> X-Mailer: Mutt 0.53 Mime-Version: 1.0 In-Reply-To: <199612161342.WAA08571@mail.tky007.tth.expo96.ad.jp>; from Masafumi NAKANE/=?ISO-2022-JP?B?GyRCQ2Y6LDJtSjgbKEI=?= on Dec 16, 1996 22:42:55 +0900 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Dec 16, max@wide.ad.jp (Masafumi NAKANE/=?ISO-2022-JP?B?GyRCQ2Y6LDJtSjgbKEI=?=) wrote: > >> /sys/pci/ncr.c attempts to include opt_ncr.h which seems to be > >> nonexistent. Please check on this. > > se> Did you remember to rerun "config " ? > > Oops, I didn't probably run config. However, even having run config, > make in /usr/src/usr.sbin/ncrcontrol would fail as cpp can't find > opt_ncr.h in /sys/compile/WHATEVER. This of course makes `make world' > break. We need some workaround for this. Oh, you are of course right ! I'll make sure that the #include is ignored in the ncrcontrol build ... Thanks for sending the problem report! Regards, STefan From owner-freebsd-current Mon Dec 16 06:42:45 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA08781 for current-outgoing; Mon, 16 Dec 1996 06:42:45 -0800 (PST) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id GAA08703 for ; Mon, 16 Dec 1996 06:42:17 -0800 (PST) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id JAA07129; Mon, 16 Dec 1996 09:40:00 -0500 From: Bill Paul Message-Id: <199612161440.JAA07129@skynet.ctr.columbia.edu> Subject: Re: Plan for integrating Secure RPC -- comments wanted To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Mon, 16 Dec 1996 09:39:59 -0500 (EST) Cc: current@freebsd.org In-Reply-To: <11680.850740486@critter.tfs.com> from "Poul-Henning Kamp" at Dec 16, 96 01:48:06 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Of all the gin joints in all the towns in all the world, Poul-Henning Kamp had to walk into mine and say: > In message <199612152022.PAA05216@skynet.ctr.columbia.edu>, Bill Paul writes: > > Hi Bill, > > Thanks for sharing your thoughts on this. I finally found time to > read it, and here are my comments: > > For the DES pollution: > > Put DES in the kernel. > > This could be as an LKM, which would be the easiest, or as > a proper kernel-source file, which would be slightly harder > to manage distributions-wise. > > Result: > * You avoid your planned hack. > * We could do away with the two versions if libcrypt we have > now, and collapse them into one. > * Which makes the dual versions of /bin/ed, /sbin/init ... > unneeded. > * Our secure dist would consist of only the LKM file. > > Drawback: > * Minor optional kernel bloat. Mmm... lemme think. We have to consider all the possible ways this can fail. Urk: just thought of one. If the crypt(3) function is an LKM, then it has to be loaded by the rc scripts, right? Well supposing you take away the 'secure' keyword from /etc/ttys for the console, then try to boot single user. /sbin/init will want to ask you for the root password before it'll give you a shell. Then you're stuck: it hasn't loaded the LKM yet, so it can't verify your password. If crypt(3) and _des_crypt() were static parts of the kernel, then you wouldn't have this problem I suppose. But then you'd have to recompile the kernel to add DES support. Hm. Then again, maybe not... I think what might work is if we have both. The kernel source contains static syscall code that implements the MD5 crypt(3) and a fake _des_crypt() that does RC4 (which I gather is exportable, if you stick to 40 bits for the key). Then we have an LKM which contains the true DES versions of these calls, and when you load it, it overrides the vectors to the dummy syscalls with vectors to its own calls. That way you always have some version of the functions present. Oh wait, no no... that still won't work. Taking the example I gave before, if I set the root password using the DES crypt(3), then I boot in single user mode, /sbin/init will again ask me to enter the root password before it gives me a shell, and now it'll try to verify my password using the MD5 crypt(), which will never match the output of the DES crypt(), and I'm stuck again. Crap. Do we really want to make people recompile the kernel to get DES support? > For the issue of a secure local transport: > > Wouldn't it be pretty easy to fortify our IP implementation a bit ? > > 1. reject anything with source/dest 127.0.0.0/8 on anything > but the lo0 interface. (Add a interface flag for this and > only set that flag in if_lo.c) > > 2. In the case of a destination of 0.0.0.0, Instead of the > first interface we happen to find, use the lo0 interface > and the 127.0.0.1 address. > > This way you could use tcp/udp and be safe I belive. Well, there's another neat thing about the "unix" transport, which is that since it's not AF_INET, you avoid all the usual IP protocol processing. Also, the server can set the permissions on the socket special file that it creates so that only certain clients can access the service. If someone really wants to fix the IP layer as you suggest then that's fine, but it's not strictly necessary. > For the issue of authenticated local transport: > > Instead of an LKM, put the code in the kernel. It shouldn't be too > hard to make it a getsockopt() instead of a LKM. I'll check into this. I don't really consider myself an advanced enough kernel hacker for this, but maybe I'll get lucky. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= From owner-freebsd-current Mon Dec 16 07:04:15 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA10913 for current-outgoing; Mon, 16 Dec 1996 07:04:15 -0800 (PST) Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id HAA10874 for ; Mon, 16 Dec 1996 07:03:41 -0800 (PST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id PAA02134 for ; Mon, 16 Dec 1996 15:02:45 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Mon, 16 Dec 1996 15:02:26 +0000 Received: from tees.elsevier.co.uk (tees.elsevier.co.uk [193.131.197.60]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id PAA13112; Mon, 16 Dec 1996 15:02:18 GMT Received: (from dpr@localhost) by tees.elsevier.co.uk (8.8.3/8.8.3) id PAA00573; Mon, 16 Dec 1996 15:00:59 GMT To: Bill Paul Cc: terry@lambert.org (Terry Lambert), current@FreeBSD.ORG Subject: Re: Plan for integrating Secure RPC -- comments wanted References: <199612152351.SAA05656@skynet.ctr.columbia.edu> From: Paul Richards Date: 16 Dec 1996 15:00:58 +0000 In-Reply-To: Bill Paul's message of Sun, 15 Dec 1996 18:51:23 -0500 (EST) Message-ID: <57ohfubkk5.fsf@tees.elsevier.co.uk> Lines: 24 X-Mailer: Gnus v5.3/Emacs 19.30 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Bill Paul writes: > No, that's an exportable DES crypt(3), which is not the same as > exportable DES. The MIT DES library can't be exported. (Although, I > discovered that my 4.4BSD-Lite CD from ORA at UNIX Expo a while back > includes the Kerberos IV source and the MIT DES library source. I > wonder if ORA has shipped any of those CDs overseas.) Luckily, I had a discussion with someone in the Perl group who was from ORA. He claimed FreeBSD was being overly restrictive in it's lack of DES code. He cited NetBSD and 4.4 claiming that both were exportable because the DES code was only being used for authentication and not encryption. I'm wondering if there may be some confusion at ORA due to the fact that 4.4 has a unidirectional DES based hashing function (which I was not aware of). I'm not sure that would be exportable anyway, isn't it still encryption technology even if it's not used as such. I suspect that the CD you have is exactly what is being exported since this person stated that was what they were in fact doing. -- Paul Richards. Originative Solutions Ltd. (Netcraft Ltd. contractor) Elsevier Science TIS online journal project. Email: p.richards@elsevier.co.uk Phone: 0370 462071 (Mobile), +44 (0)1865 843155 From owner-freebsd-current Mon Dec 16 07:20:48 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA11705 for current-outgoing; Mon, 16 Dec 1996 07:20:48 -0800 (PST) Received: from haywire.DIALix.COM (news@haywire.DIALix.COM [192.203.228.65]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id HAA11698 for ; Mon, 16 Dec 1996 07:20:43 -0800 (PST) Received: (from news@localhost) by haywire.DIALix.COM (8.8.4/8.8.2) id XAA21550 for freebsd-current@freebsd.org; Mon, 16 Dec 1996 23:20:34 +0800 (WST) X-Authentication-Warning: haywire.DIALix.COM: news set sender to usenet-request@haywire.dialix.com using -f Received: from GATEWAY by haywire.DIALix.COM with netnews for freebsd-current@freebsd.org (problems to: usenet@haywire.dialix.com) To: freebsd-current@freebsd.org Date: 16 Dec 1996 15:20:33 GMT From: peter@spinner.DIALix.COM (Peter Wemm) Message-ID: <593pc1$k40$1@haywire.DIALix.COM> Organization: DIALix Services, Perth, Australia. References: <199612152022.PAA05216@skynet.ctr.columbia.edu> Subject: Re: Plan for integrating Secure RPC -- comments wanted Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <11680.850740486@critter.tfs.com>, phk@critter.tfs.com (Poul-Henning Kamp) writes: > Put DES in the kernel. > > This could be as an LKM, which would be the easiest, or as > a proper kernel-source file, which would be slightly harder > to manage distributions-wise. > > Result: > * You avoid your planned hack. > * We could do away with the two versions if libcrypt we have > now, and collapse them into one. > * Which makes the dual versions of /bin/ed, /sbin/init ... > unneeded. > * Our secure dist would consist of only the LKM file. Why don't we just give in and make a dual-mode libcrypt with the exportable des one-way hash code like all the other vendors are doing? (and of course, the MD5 hash code) For the spectators.. The original implementation of password encryption used DES to encrypt block of data (8 zero's from memory) 25 times using the text password as a key. The problem was that this code used the generic DES routines which were full encryption/decryption code. Somebody designed a "broken" version of DES that purely became a 1-way hash function (exportable, just like md5) that had no chance of being "converted" to encrypt/decypt data (which would make it export restricted). There is a difference between encrypting a known block of data to a result that can be decoded back to the original data, and irreversibly hashing a key (ie: password) in a way that comes up with the same results as the "encrypt a block of nulls" method. Anyway, the problem then becomes.. How do you choose the default encryption type for the new merged crypt() when it doesn't have a precedent to go on? I know this doesn't have much to do with Secure RPC, but it would get rid of the dual versions of /sbin/init, /bin/ed, libcrypt etc. I would like libcrypt to go away and become a stub library just like libresolv/libgnumalloc. -Peter From owner-freebsd-current Mon Dec 16 07:22:21 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA11809 for current-outgoing; Mon, 16 Dec 1996 07:22:21 -0800 (PST) Received: from mail.tky007.tth.expo96.ad.jp (root@tky007.tth.expo96.ad.jp [133.246.32.58]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id HAA11800 for ; Mon, 16 Dec 1996 07:22:18 -0800 (PST) Received: from tky007.tth.expo96.ad.jp (masafumi@localhost [127.0.0.1]) by mail.tky007.tth.expo96.ad.jp (8.8.4/3.4W4-SMTP) with ESMTP id AAA09592; Tue, 17 Dec 1996 00:21:02 +0900 (JST) Message-Id: <199612161521.AAA09592@mail.tky007.tth.expo96.ad.jp> To: proff@suburbia.net Cc: max@wide.ad.jp, current@freebsd.org Subject: Re: ed0 trouble with -current From: Masafumi NAKANE/=?ISO-2022-JP?B?GyRCQ2Y6LDJtSjgbKEI=?= In-Reply-To: Your message of "Mon, 16 Dec 1996 22:49:05 +1100 (EST)" References: <19961216114905.9979.qmail@suburbia.net> X-Mailer: Mew version 1.54 on Emacs 19.28.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 17 Dec 1996 00:21:02 +0900 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> Try the latest sources. This has been fixed. >> >> Max >> proff> Unfortunately at the expense of all host based traffic. Not proff> even loopback. proff> Forwarding still works though ;) Are you sure the file /usr/src/sys/netinet/if_ether.c is the latest? With the latest version, things seem to be working OK. The latest version is: * $Id: if_ether.c,v 1.37 1996/12/15 20:38:30 bde Exp $ Masafumi From owner-freebsd-current Mon Dec 16 07:43:36 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA13029 for current-outgoing; Mon, 16 Dec 1996 07:43:36 -0800 (PST) Received: from mail.netvision.net.il (mail.NetVision.net.il [194.90.1.6]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id HAA13020 for ; Mon, 16 Dec 1996 07:43:29 -0800 (PST) Received: from Burka.NetVision.net.il (gena@burka.NetVision.net.il [194.90.6.15]) by mail.netvision.net.il (8.7.5/8.7.3) with SMTP id RAA08238 for ; Mon, 16 Dec 1996 17:43:19 +0200 (IST) Message-ID: X-Mailer: XFMail 0.5-beta [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Mon, 16 Dec 1996 17:39:08 +0200 (IST) X-Face: #v>4HN>#D_"[olq9y`HqTYkLVB89Xy|3')Vs9v58JQ*u-xEJVKY`xa.}E?z0RkLI/P&;BJmi0#u=W0).-Y'J4(dw{"54NhSG|YYZG@[)(`e! >jN#L!~qI5fE-JHS+< Organization: NetVision Ltd. From: Gennady Sorokopud To: current@freebsd.org Subject: -current and vx0 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello! I just recompiled today's -current kernel (CVSupped about 10 hours ago) and find out that my 3C590 PCI Ethernet no longer works. No packets can be sent from/to the system. The kernel from 12/12/96 worked just fine. This is how my card is being identified by kernel: vx0 <3COM 3C590 Etherlink III PCI> rev 0 int a irq 9 on pci0:11 utp[*utp*] address 00:20:af:f7:f2:dd Warning! Defective early revision adapter! (it was always identified as "defective", but worked just fine until now). Best regards. -------- Gennady B. Sorokopud - System programmer at NetVision Israel. E-Mail: Gennady Sorokopud Homepage: http://www.netvision.net.il/~gena PGP public key is available by fingering gena@netvision.net.il This message was sent at 16-Dec-96 17:39:08 by XF-Mail From owner-freebsd-current Mon Dec 16 08:15:06 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA14856 for current-outgoing; Mon, 16 Dec 1996 08:15:06 -0800 (PST) Received: from grackle.grondar.za (TwPE4gNmGruBb9JRk/3uAWYLP8WVhf+9@grackle.grondar.za [196.7.18.131]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id IAA14841 for ; Mon, 16 Dec 1996 08:14:59 -0800 (PST) Received: from grackle.grondar.za (SUcxkdBlIF+gKr0qZLll9VsxjJYBSW5Z@localhost [127.0.0.1]) by grackle.grondar.za (8.8.4/8.8.4) with ESMTP id SAA22536; Mon, 16 Dec 1996 18:12:58 +0200 (SAT) Message-Id: <199612161612.SAA22536@grackle.grondar.za> To: Paul Richards cc: Bill Paul , terry@lambert.org (Terry Lambert), current@FreeBSD.ORG Subject: Re: Plan for integrating Secure RPC -- comments wanted Date: Mon, 16 Dec 1996 18:12:56 +0200 From: Mark Murray Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Paul Richards wrote: > I had a discussion with someone in the Perl group who was from ORA. He > claimed FreeBSD was being overly restrictive in it's lack of DES > code. He cited NetBSD and 4.4 claiming that both were exportable > because the DES code was only being used for authentication and not > encryption. I'm wondering if there may be some confusion at ORA due to > the fact that 4.4 has a unidirectional DES based hashing function > (which I was not aware of). I'm not sure that would be exportable > anyway, isn't it still encryption technology even if it's not used as > such. I suspect that the CD you have is exactly what is being exported > since this person stated that was what they were in fact doing. There are _two_ things called `DES': 1) contents of libdescrypt AKA libcrypt, which is the one-way hash. (AKA crypt() (3)) 2) contents of libdes. 2-way stuff. DEFINITELY unexportable. M -- Mark Murray PGP key fingerprint = 80 36 6E 40 83 D6 8A 36 This .sig is umop ap!sdn. BC 06 EA 0E 7A F2 CE CE From owner-freebsd-current Mon Dec 16 08:24:28 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA15596 for current-outgoing; Mon, 16 Dec 1996 08:24:28 -0800 (PST) Received: from grackle.grondar.za (LOKGfoLq8ZM2cgLEuJdJOYOlw28fQJg1@grackle.grondar.za [196.7.18.131]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id IAA15589 for ; Mon, 16 Dec 1996 08:24:22 -0800 (PST) Received: from grackle.grondar.za (PSCAJjOaHdsAiGhxBAxrrMKZX/ghjkeW@localhost [127.0.0.1]) by grackle.grondar.za (8.8.4/8.8.4) with ESMTP id SAA22596; Mon, 16 Dec 1996 18:23:52 +0200 (SAT) Message-Id: <199612161623.SAA22596@grackle.grondar.za> To: peter@spinner.DIALix.COM (Peter Wemm) cc: freebsd-current@freebsd.org Subject: Crypto (Was: Re: Plan for integrating Secure RPC -- comments wanted) Date: Mon, 16 Dec 1996 18:23:51 +0200 From: Mark Murray Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Somebody designed a "broken" version of DES that purely became a 1-way hash > function (exportable, just like md5) that had no chance of being "converted" > to encrypt/decypt data (which would make it export restricted). Gnu's libcrypt has an export license. I don't se why we shouldn't. > There is a difference between encrypting a known block of data to a result > that can be decoded back to the original data, and irreversibly hashing a > key (ie: password) in a way that comes up with the same results as the > "encrypt a block of nulls" method. > > Anyway, the problem then becomes.. How do you choose the default encryption > type for the new merged crypt() when it doesn't have a precedent to go on? I have some ideas: 1) a config file (say): /etc/crypt.conf if a line in it says "method: DES" or "method: MD5", the appropriate format is chosen. 2) Environment variable (EUGH :-() 3) PHKMalloc method: make a symlink to a an appropriate name: /etc/crypt.method -> /etc/Do_MD5 (or -> /etc/Do_DES). I like #1. It shouldn't take me long to do it. > I know this doesn't have much to do with Secure RPC, but it would get rid of > the dual versions of /sbin/init, /bin/ed, libcrypt etc. I would like Er, wait - init and ed use libcipher, which is two-way :-( :-( :-( > libcrypt to go away and become a stub library just like > libresolv/libgnumalloc. Hear, hear! M -- Mark Murray PGP key fingerprint = 80 36 6E 40 83 D6 8A 36 This .sig is umop ap!sdn. BC 06 EA 0E 7A F2 CE CE From owner-freebsd-current Mon Dec 16 08:30:59 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA15930 for current-outgoing; Mon, 16 Dec 1996 08:30:59 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id IAA15920 for ; Mon, 16 Dec 1996 08:30:55 -0800 (PST) Received: by halloran-eldar.lcs.mit.edu; (5.65v3.2/1.1.8.2/19Aug95-0530PM) id AA18822; Mon, 16 Dec 1996 11:29:31 -0500 Date: Mon, 16 Dec 1996 11:29:31 -0500 From: Garrett Wollman Message-Id: <9612161629.AA18822@halloran-eldar.lcs.mit.edu> To: Paul Richards Cc: Bill Paul , terry@lambert.org (Terry Lambert), current@FreeBSD.ORG Subject: Re: Plan for integrating Secure RPC -- comments wanted In-Reply-To: <57ohfubkk5.fsf@tees.elsevier.co.uk> References: <199612152351.SAA05656@skynet.ctr.columbia.edu> <57ohfubkk5.fsf@tees.elsevier.co.uk> Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk < said: > I had a discussion with someone in the Perl group who was from ORA. He > claimed FreeBSD was being overly restrictive in it's lack of DES > code. He cited NetBSD and 4.4 claiming that both were exportable > because the DES code was only being used for authentication and not > encryption. He is wrong, mostly. We /could/ export libdescrypt, but IN BINARY FORM ONLY. (We'd probably have to get a CJ and a license ruling from the Commerce Department first, just to be safe.) Exporting the source code is problematic, because it could easily be turned back into an ordinary encryption/decryption engine. (The libcrypt/libcipher split was done in this way under my guidance specifically to make it easier for someone to get an export license for a binary distribution containing libdescrypt.) The exception the ORA person was thinking of is how DEC is able to export Kerberos in binary form. They in-line the DES code into libkrb where it's called, and don't provide the krb_*_priv() functions which provide indirect access to the encryption mechanism. This allows them to create a library which is only capable of performing authentication, not providing privacy, and so the government allows them to export it. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, ANA, or NSA| - Susan Aglukark and Chad Irschick From owner-freebsd-current Mon Dec 16 08:40:42 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA16301 for current-outgoing; Mon, 16 Dec 1996 08:40:42 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id IAA16296 for ; Mon, 16 Dec 1996 08:40:39 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0vZg52-0003w4C; Mon, 16 Dec 96 08:39 PST Received: from critter.tfs.com (localhost [127.0.0.1]) by critter.tfs.com (8.8.2/8.8.2) with ESMTP id RAA12327; Mon, 16 Dec 1996 17:40:03 +0100 (MET) To: peter@spinner.DIALix.COM (Peter Wemm) cc: freebsd-current@freebsd.org Subject: Re: Plan for integrating Secure RPC -- comments wanted In-reply-to: Your message of "16 Dec 1996 15:20:33 GMT." <593pc1$k40$1@haywire.DIALix.COM> Date: Mon, 16 Dec 1996 17:40:02 +0100 Message-ID: <12325.850754402@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Why don't we just give in and make a dual-mode libcrypt with the >exportable des one-way hash code like all the other vendors are doing? >(and of course, the MD5 hash code) I'm game. Although this doesn't solve the problem with /bin/ed and other legitimate users of DES, secure RPC for instance. >Anyway, the problem then becomes.. How do you choose the default encryption >type for the new merged crypt() when it doesn't have a precedent to go on? You check which one root used and use the same ? >I know this doesn't have much to do with Secure RPC, but it would get rid of >the dual versions of /sbin/init, /bin/ed, libcrypt etc. I would like libcrypt >to go away and become a stub library just like libresolv/libgnumalloc. I agree. But is the source for the DES-hash exportable ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-current Mon Dec 16 08:41:18 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA16335 for current-outgoing; Mon, 16 Dec 1996 08:41:18 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id IAA16324; Mon, 16 Dec 1996 08:41:05 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id DAA16927; Tue, 17 Dec 1996 03:39:29 +1100 Date: Tue, 17 Dec 1996 03:39:29 +1100 From: Bruce Evans Message-Id: <199612161639.DAA16927@godzilla.zeta.org.au> To: max@wide.ad.jp, se@FreeBSD.org Subject: Re: Error with current ncr.c Cc: current@FreeBSD.org Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >> Oops, I didn't probably run config. However, even having run config, >> make in /usr/src/usr.sbin/ncrcontrol would fail as cpp can't find >> opt_ncr.h in /sys/compile/WHATEVER. This of course makes `make world' >> break. We need some workaround for this. > >Oh, you are of course right ! > >I'll make sure that the #include is >ignored in the ncrcontrol build ... This doesn't work, since e.g. SCI_NCR_DFLT_TAGS affects MAX_START which affects `struct ncb' which must be the same in the kernel and ncrcontrol. This is the old FAILSAFE configuration bug. Bruce From owner-freebsd-current Mon Dec 16 08:54:32 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA16959 for current-outgoing; Mon, 16 Dec 1996 08:54:32 -0800 (PST) Received: from pegasus.my.domain (sole-25.ppp.hooked.net [206.80.9.217]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id IAA16933; Mon, 16 Dec 1996 08:54:26 -0800 (PST) From: dicen@hooked.net Received: from pegasus.my.domain (localhost.my.domain [127.0.0.1]) by pegasus.my.domain (8.8.4/8.7.3) with SMTP id IAA00446; Mon, 16 Dec 1996 08:54:40 GMT Message-ID: <32B50E50.41C67EA6@hooked.net> Date: Mon, 16 Dec 1996 08:54:40 +0000 X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: current@freebsd.org, ports@freebsd.org Subject: pkg_manage and ports Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have the latest current tree as of 12 hours ago or so. When I run pkg_manage under X in an xterm it now tries to run with color (in some sort of graphics mode?) and crashes displaying the following at the command prompt. ;1;1;112;112;1;0x^[[2;1;1;112;112;1;0x^[[2;1;1;112;112;1;0x^[[2;1;1;112;112;1;0x;1;1;112;112;1;0x;1;1;112;112;1;0x;1;1;112;112;1;0x;1;1;112;112;1;0x Has anyone messed with this code? It doesn't look like it has been touched in years. On a side note I am currently working on a better ports management system. Is anyone currently doing this? I don't want to duplicate work. I was thinking about rewriting the src/usr.sbin/pkg_install source but I am just writing some port management commands in bourne shell. It is much easier that way. dicen From owner-freebsd-current Mon Dec 16 08:58:25 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA17230 for current-outgoing; Mon, 16 Dec 1996 08:58:25 -0800 (PST) Received: from pegasus.my.domain (sole-25.ppp.hooked.net [206.80.9.217]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id IAA17221 for ; Mon, 16 Dec 1996 08:58:21 -0800 (PST) From: dicen@hooked.net Received: from pegasus.my.domain (localhost.my.domain [127.0.0.1]) by pegasus.my.domain (8.8.4/8.7.3) with SMTP id IAA00454 for ; Mon, 16 Dec 1996 08:58:35 GMT Message-ID: <32B50F3B.167EB0E7@hooked.net> Date: Mon, 16 Dec 1996 08:58:35 +0000 X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: current@freebsd.org Subject: strange dialup ppp beharvior Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am using the dialup ppp code with the tun0 device for my ppp connection. The funny thing is when I telnet to port 3000 to close my connection the prompt goes from PPP to ppp but the modem never hangs up. Actually no packets are tansmitted at all when I do this and it just stays on as if I didn't tell it to disconnect. It didn't use to do this. dicen From owner-freebsd-current Mon Dec 16 09:12:12 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA18104 for current-outgoing; Mon, 16 Dec 1996 09:12:12 -0800 (PST) Received: from pegasus.my.domain (sole-25.ppp.hooked.net [206.80.9.217]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id JAA18099 for ; Mon, 16 Dec 1996 09:12:07 -0800 (PST) From: dicen@hooked.net Received: from pegasus.my.domain (localhost.my.domain [127.0.0.1]) by pegasus.my.domain (8.8.4/8.7.3) with SMTP id JAA00471; Mon, 16 Dec 1996 09:09:55 GMT Message-ID: <32B511E3.2781E494@hooked.net> Date: Mon, 16 Dec 1996 09:09:55 +0000 X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: Garrett Wollman CC: Paul Richards , Bill Paul , Terry Lambert , current@freebsd.org Subject: Re: Plan for integrating Secure RPC -- comments wanted References: <199612152351.SAA05656@skynet.ctr.columbia.edu> <57ohfubkk5.fsf@tees.elsevier.co.uk> <9612161629.AA18822@halloran-eldar.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Garrett Wollman wrote: > > < said: > > > I had a discussion with someone in the Perl group who was from ORA. He > > claimed FreeBSD was being overly restrictive in it's lack of DES > > code. He cited NetBSD and 4.4 claiming that both were exportable > > because the DES code was only being used for authentication and not > > encryption. > > He is wrong, mostly. We /could/ export libdescrypt, but IN BINARY > FORM ONLY. (We'd probably have to get a CJ and a license ruling from > the Commerce Department first, just to be safe.) Exporting the source > code is problematic, because it could easily be turned back into an > ordinary encryption/decryption engine. (The libcrypt/libcipher split > was done in this way under my guidance specifically to make it easier > for someone to get an export license for a binary distribution > containing libdescrypt.) Am I missing something here? Why do we care if the DES is exportable or not? Someone in a foreign country can just go to ftp.freebsd.org and download the source to the DES code anyway can they not? If not I am sure they could go to funet.fi or some other server. Yes this person would be breaking US law if they downloaded it from ftp.freebsd.org but do they care? No. Does anyone care what the Commence Department or any of the government agencies say about encryption? No. Why do you all care if the US Government approves your exportable DES code? DES and other encryption code is prabobly on more foreign servers than US ones. I go to foreing servers all the time to get such code because the US Government seams to harass US servers. Short and simple: If someone in a foreign land wants to put DES in FreeBSD than just let him get the source code. This is what he does now anyway. > > The exception the ORA person was thinking of is how DEC is able to > export Kerberos in binary form. They in-line the DES code into libkrb > where it's called, and don't provide the krb_*_priv() functions which > provide indirect access to the encryption mechanism. This allows them > to create a library which is only capable of performing > authentication, not providing privacy, and so the government allows > them to export it. > > -GAWollman > > -- > Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same > wollman@lcs.mit.edu | O Siem / The fires of freedom > Opinions not those of| Dance in the burning flame > MIT, LCS, ANA, or NSA| - Susan Aglukark and Chad Irschick From owner-freebsd-current Mon Dec 16 09:32:29 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA19238 for current-outgoing; Mon, 16 Dec 1996 09:32:29 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id JAA19228 for ; Mon, 16 Dec 1996 09:32:27 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0vZg58-0003wgC; Mon, 16 Dec 96 08:39 PST Received: from critter.tfs.com (localhost [127.0.0.1]) by critter.tfs.com (8.8.2/8.8.2) with ESMTP id RAA12288; Mon, 16 Dec 1996 17:28:45 +0100 (MET) To: Paul Richards cc: Bill Paul , terry@lambert.org (Terry Lambert), current@freebsd.org Subject: Re: Plan for integrating Secure RPC -- comments wanted In-reply-to: Your message of "16 Dec 1996 15:00:58 GMT." <57ohfubkk5.fsf@tees.elsevier.co.uk> Date: Mon, 16 Dec 1996 17:28:43 +0100 Message-ID: <12286.850753723@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <57ohfubkk5.fsf@tees.elsevier.co.uk>, Paul Richards writes: >I had a discussion with someone in the Perl group who was from ORA. He >claimed FreeBSD was being overly restrictive in it's lack of DES >code. My personal reason for not having DES, is not the lack of code due to export regulations, but lack of trust on my part in the actual algorithm. :-) -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-current Mon Dec 16 09:35:23 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA19834 for current-outgoing; Mon, 16 Dec 1996 09:35:23 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id JAA19829 for ; Mon, 16 Dec 1996 09:35:21 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0vZg5A-0003wyC; Mon, 16 Dec 96 08:40 PST Received: from critter.tfs.com (localhost [127.0.0.1]) by critter.tfs.com (8.8.2/8.8.2) with ESMTP id QAA12151; Mon, 16 Dec 1996 16:44:20 +0100 (MET) To: Bill Paul cc: current@freebsd.org Subject: Re: Plan for integrating Secure RPC -- comments wanted In-reply-to: Your message of "Mon, 16 Dec 1996 09:39:59 EST." <199612161440.JAA07129@skynet.ctr.columbia.edu> Date: Mon, 16 Dec 1996 16:44:19 +0100 Message-ID: <12149.850751059@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199612161440.JAA07129@skynet.ctr.columbia.edu>, Bill Paul writes: >Do we really want to make people recompile the kernel to get DES support? Not really. The trouble is that we cannot load a LKM until we have a RW fs :-( I could live with it if /sbin/init did contain a static DES copy, that is still a lot less mess than we have now. Poul-Henning >> For the issue of authenticated local transport: >> >> Instead of an LKM, put the code in the kernel. It shouldn't be too >> hard to make it a getsockopt() instead of a LKM. > >I'll check into this. I don't really consider myself an advanced >enough kernel hacker for this, but maybe I'll get lucky. Hey, you're talking about makeing LKM's all the time :-) -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-current Mon Dec 16 09:48:02 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA20927 for current-outgoing; Mon, 16 Dec 1996 09:48:02 -0800 (PST) Received: from marble.eps.nagoya-u.ac.jp (marble.eps.nagoya-u.ac.jp [133.6.57.68]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id JAA20887 for ; Mon, 16 Dec 1996 09:47:59 -0800 (PST) Received: from marble.eps.nagoya-u.ac.jp (localhost [127.0.0.1]) by marble.eps.nagoya-u.ac.jp (8.7.6/3.4W4) with ESMTP id CAA00344; Tue, 17 Dec 1996 02:46:51 +0900 (JST) Message-Id: <199612161746.CAA00344@marble.eps.nagoya-u.ac.jp> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-current@FreeBSD.ORG, bsdcur@shadows.aeon.net Subject: Re: /usr/src/sys/i386/i386/userconfig.c In-Reply-To: Your message of "Sun, 15 Dec 1996 23:40:31 +0100 (MET)" References: <199612152240.XAA01252@uriah.heep.sax.de> X-Mailer: Mew version 1.06 on Emacs 19.28.1, Mule 2.3 X-PGP-Fingerprint: 03 72 85 36 62 46 23 03 52 B1 10 22 44 10 0D 9E Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Tue, 17 Dec 1996 02:46:51 +0900 From: KATO Takenori Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk From: J Wunsch Subject: Re: /usr/src/sys/i386/i386/userconfig.c Date: Sun, 15 Dec 1996 23:40:31 +0100 (MET) > Already fixed (though by `max', not by me). By me, `kato'. I found the typo when I compiled PC98 kernel. ---- KATO Takenori Dept. Earth Planet. Sci., Nagoya Univ., Nagoya, 464-01, Japan PGP public key: finger kato@eclogite.eps.nagoya-u.ac.jp From owner-freebsd-current Mon Dec 16 11:32:31 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA26647 for current-outgoing; Mon, 16 Dec 1996 11:32:31 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id LAA26634 for ; Mon, 16 Dec 1996 11:32:25 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.2/8.8.2) with SMTP id LAA02333; Mon, 16 Dec 1996 11:17:44 -0800 (PST) Message-ID: <32B5A02A.446B9B3D@whistle.com> Date: Mon, 16 Dec 1996 11:16:58 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Poul-Henning Kamp CC: Bill Paul , current@FreeBSD.ORG Subject: Re: Plan for integrating Secure RPC -- comments wanted References: <11680.850740486@critter.tfs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Poul-Henning Kamp wrote: > > In message <199612152022.PAA05216@skynet.ctr.columbia.edu>, Bill Paul writes: > > Hi Bill, > > Thanks for sharing your thoughts on this. I finally found time to > read it, and here are my comments: > > For the DES pollution: > > Put DES in the kernel. > > This could be as an LKM, which would be the easiest, or as > a proper kernel-source file, which would be slightly harder > to manage distributions-wise. > > Result: > * You avoid your planned hack. > * We could do away with the two versions if libcrypt we have > now, and collapse them into one. > * Which makes the dual versions of /bin/ed, /sbin/init ... > unneeded. > * Our secure dist would consist of only the LKM file. > > Drawback: > * Minor optional kernel bloat. > would be compatible with H/w solutions that I know some people have... From owner-freebsd-current Mon Dec 16 11:39:45 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA27223 for current-outgoing; Mon, 16 Dec 1996 11:39:45 -0800 (PST) Received: from pegasus.my.domain (bass-16.ppp.hooked.net [206.80.8.80]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id LAA27214; Mon, 16 Dec 1996 11:39:40 -0800 (PST) From: dicen@hooked.net Received: from pegasus.my.domain (localhost.my.domain [127.0.0.1]) by pegasus.my.domain (8.8.4/8.7.3) with SMTP id LAA00914; Mon, 16 Dec 1996 11:39:49 GMT Message-ID: <32B53505.41C67EA6@hooked.net> Date: Mon, 16 Dec 1996 11:39:49 +0000 X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: ports@freebsd.org, current@freebsd.org Subject: Re: pkg_manage and ports References: <1.5.4.32.19961216183856.006dcf90@infosel.net.mx> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I just got four messages from this guy! One message reply for every email sent. I would say SPAM! I don't care about your damn Mexicain (one country I would never go to) crappy hotel! I only vacation in Maui at either Walia or Lahina. sands wrote: > > DON´T SEND ME YOUR THINKS RONG ADDRESS > English Please! What the hell does this mean? > At 08:54 AM 16/12/96 +0000, you wrote: > >I have the latest current tree as of 12 hours ago or so. > >When I run pkg_manage under X in an xterm it now tries to run with > >color (in some sort of graphics mode?) and crashes displaying the > >following at the command prompt. > > > >;1;1;112;112;1;0x^[[2;1;1;112;112;1;0x^[[2;1;1;112;112;1;0x^[[2;1;1;112;112 > ;1;0x;1;1;112;112;1;0x;1;1;112;112;1;0x;1;1;112;112;1;0x;1;1;112;112;1;0x > > > >Has anyone messed with this code? It doesn't look like it has been > >touched in years. > > > >On a side note I am currently working on a better ports management > >system. Is anyone currently doing this? I don't want to duplicate work. > >I was thinking about rewriting the src/usr.sbin/pkg_install source but I > >am just writing some port management commands in bourne shell. It is > >much easier that way. > > > >dicen > > > ________________________________________________________________________ > Moises Bazbaz S.//sand's acapulco s.a. > Costera M. aleman 178 fracc.magallanes c.p. 39670 Acapulco gro > tel reservaciones 011 52 5 2593205,91800 09800 o 801 fax 011 52 74 841053 > home site :http://www.sands.com.mx email:sands@sands.com.mx Is this SPAM? This URL seams to be some sort of Mexicain Hotel. What a stupid web page too. From owner-freebsd-current Mon Dec 16 12:44:50 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA01121 for current-outgoing; Mon, 16 Dec 1996 12:44:50 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA01116; Mon, 16 Dec 1996 12:44:48 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0vZjtS-0003w3C; Mon, 16 Dec 96 12:44 PST Received: from critter.tfs.com (localhost.phk.dk [127.0.0.1]) by critter.tfs.com (8.8.2/8.8.2) with ESMTP id VAA13978; Mon, 16 Dec 1996 21:47:21 +0100 (MET) To: dicen@hooked.net cc: ports@freebsd.org, current@freebsd.org Subject: Re: pkg_manage and ports In-reply-to: Your message of "Mon, 16 Dec 1996 11:39:49 GMT." <32B53505.41C67EA6@hooked.net> Date: Mon, 16 Dec 1996 21:47:20 +0100 Message-ID: <13976.850769240@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <32B53505.41C67EA6@hooked.net>, dicen@hooked.net writes: >I just got four messages from this guy! >One message reply for every email sent. I would say SPAM! >I don't care about your damn Mexicain (one country I would never go to) >crappy hotel! I only vacation in Maui at either Walia or Lahina. > >sands wrote: >> >> DON´T SEND ME YOUR THINKS RONG ADDRESS >> > >English Please! What the hell does this mean? He is, to the best of his ability, trying to get removed from a mailing list that he has probably never subscribed to in the first place, a request that I forwarded to our postmaster the first time I saw it. While we're on the subject of unappropriate emails: Would it be too much trouble for >you< Mr "dicen" not to spam our lists with your badly contained lack of polite behaviour ? Unless you can behave yourself in civilized company, I would suggest you refrain from sending emails to the freebsd lists, but rather lurk around for a couple of years until you get the drift. For your information: You little "outburst" here, bothered at least 1002 direct receipients of the mailinglists in question, and amongst that thousand addresses are at least 150 mail-exploders, so I think a fair guess is that at least 2000 people think something along the lines of "I wonder how that mexican guy got on our list, and what a jerk that ``dicen'' guy is!" If you don't like this, you'd better unsubscribe instead of replying. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-current Mon Dec 16 13:05:21 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA02847 for current-outgoing; Mon, 16 Dec 1996 13:05:21 -0800 (PST) Received: from itsdsv1.enc.edu (itsdsv1.enc.edu [207.95.42.241]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id NAA02806; Mon, 16 Dec 1996 13:05:12 -0800 (PST) Received: from dingo.its.enc.edu (dingo.its.enc.edu [207.95.222.250]) by itsdsv1.enc.edu (8.7.5/8.7.3) with SMTP id QAA24504; Mon, 16 Dec 1996 16:02:00 -0500 (EST) Date: Mon, 16 Dec 1996 16:03:42 -0500 (EST) From: Charles Owens X-Sender: owensc@dingo.its.enc.edu To: Gary Roberts cc: DNEX , current@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: IP masquerading (for a LAN, _not_ PPP) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 8 Dec 1996, Gary Roberts wrote: > On Sun, 8 Dec 1996, DNEX wrote: > > > Does FreeBSD support IP masquerading or are there plans to implement it? > > > > Yes. It does. Charles Mott. Nice piece of software. Anyways, it's not > a program like linux uses, it uses the PPP program. Check it out at: > > http://www.srv.net/~cmott/alias.html This looks nifty, but I'm interested in doing masquerading on a firewall for users on a large LAN, not dialing in via PPP. What's the status of doing _this_ with FreeBSD? --- ------------------------------------------------------------------------- Charles Owens Email: owensc@enc.edu "I read somewhere to learn is to Information Technology Services remember... and I've learned that Eastern Nazarene College we've all forgot..." - King's X ------------------------------------------------------------------------- From owner-freebsd-current Mon Dec 16 13:21:49 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA04014 for current-outgoing; Mon, 16 Dec 1996 13:21:49 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA04002 for ; Mon, 16 Dec 1996 13:21:44 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA14106 for ; Mon, 16 Dec 1996 22:20:58 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA23176 for freebsd-current@FreeBSD.org; Mon, 16 Dec 1996 22:20:57 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id VAA08891 for freebsd-current@FreeBSD.org; Mon, 16 Dec 1996 21:54:53 +0100 (MET) From: J Wunsch Message-Id: <199612162054.VAA08891@uriah.heep.sax.de> Subject: Re: /usr/src/sys/i386/i386/userconfig.c To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Mon, 16 Dec 1996 21:54:53 +0100 (MET) In-Reply-To: <199612161746.CAA00344@marble.eps.nagoya-u.ac.jp> from KATO Takenori at "Dec 17, 96 02:46:51 am" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As KATO Takenori wrote: > > Already fixed (though by `max', not by me). > > By me, `kato'. Erm, sorry! > > I found the typo when I compiled PC98 kernel. It has been reported to -current before, but it's been during those few hours of the day where i used to sleep. :) That's why i haven't got 'round to fix it earlier. -- 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 Dec 16 13:57:43 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA06260 for current-outgoing; Mon, 16 Dec 1996 13:57:43 -0800 (PST) Received: from burka.rdy.com (burka.rdy.com [205.149.163.30]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id NAA06250; Mon, 16 Dec 1996 13:57:29 -0800 (PST) Received: by burka.rdy.com id NAA22783; (8.8.3/RDY) Mon, 16 Dec 1996 13:56:44 -0800 (PST) From: "Dima Ruban" Message-Id: <961216135643.ZM22781@burka.rdy.com> Date: Mon, 16 Dec 1996 13:56:43 -0800 In-Reply-To: John Polstra "Re: SUP of current weird" (Dec 15, 1:04pm) References: <199612142219.IAA10425@spooky.eis.net.au> <199612152104.NAA28986@austin.polstra.com> Reply-To: dima@best.net X-Class: Fast Organization: HackerDome X-Mailer: Z-Mail (4.0b.514 14may96) To: John Polstra , ernie@spooky.eis.net.au Subject: Re: SUP of current weird Cc: freebsd-current@freebsd.org, peter@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Dec 15, 1:04pm, John Polstra wrote: > Subject: Re: SUP of current weird > In article <199612142219.IAA10425@spooky.eis.net.au> you write: > > I noticed over the last few days that there have been a few minor bugs that > > stop a make world in -current so I simply run sup again to get the latest > > fixed the next day. However every time I run sup it seems to want to > > retreive most of the contrib directory again which is wastefull. > > > > Has there been major patches every day of the last week to the contrib dir > > that forces sup to download it again? Or is there something odd going on? > > There have been very few commits to contrib lately. There is something > odd going on. > > > It only seems to be the contrib dir the other just update changed files as > > normal. > > > > Any suggestions? > > Your supfile line looks fine. I looked around a bit on sup.freebsd.org. > The problem appears to be a bug in cvs-1.6.3, which is the version used > there. > > Periodically (every day, I suppose) the source tree there is updated > with "cvs update -APd". For some reason, this is causing the > modtimes of the contrib files to be updated, even though the files > haven't changed. (2554 files under contrib on sup.freebsd.org have > been touched in the past 24 hours.) > > I tried some experiments on two machines here, one running cvs-1.6.3, > and the other running cvs-1.8.1. Both times, I did this: > > cvs checkout contrib_libpcap > cd contrib_libpcap > ls -lt > cvs update -APd > ls -lt > > On the -1.6.3 machine, zillions of files got "updated", and their > modtimes were touched. On the -1.8.1 machine, the "cvs update" did > nothing. > > Peter: Is this a known bug? > > Dima: Could you update your cvs to the version from -current? Ugh ... actually I can, but I'm running -stable here, and every time I'm recompiling system - I'll have to recompile cvs stuff after that. The question is - how about to bring these changes from -current to -stable? (I know, -stable is almost dead, but this is a bug fix, so it should be realy usefull) > > Ernie: If you were using CVSup, this wouldn't be happening to you. > (Sorry, I couldn't resist. :-) > > John > -- > John Polstra jdp@polstra.com > John D. Polstra & Co., Inc. Seattle, Washington USA > "Self-knowledge is always bad news." -- John Barth >-- End of excerpt from John Polstra -- dima From owner-freebsd-current Mon Dec 16 14:10:02 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA07323 for current-outgoing; Mon, 16 Dec 1996 14:10:02 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA07292 for ; Mon, 16 Dec 1996 14:09:56 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id PAA04571; Mon, 16 Dec 1996 15:09:48 -0700 (MST) Date: Mon, 16 Dec 1996 15:09:48 -0700 (MST) Message-Id: <199612162209.PAA04571@rocky.mt.sri.com> From: Nate Williams To: current@freebsd.org Subject: libc_r broken in 2.2 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Something new got merged in the stdtime code but didn't get updated in the thread code that caused the threaded version to die. cc -O2 -m486 -pipe -DLIBC_RCS -DSYSLIBC_RCS -DPTHREAD_KERNEL -D_THREAD_SAFE -I/usr/src/lib/libc_r/uthread -D__DBINTERFACE_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc_r/../libc/locale -DYP -c /usr/src/lib/libc_r/../libc/stdtime/localtime.c -o localtime.o /usr/src/lib/libc_r/../libc/stdtime/localtime.c: In function `localtime': /usr/src/lib/libc_r/../libc/stdtime/localtime.c:1111: too few arguments to function `pthread_getspecific' /usr/src/lib/libc_r/../libc/stdtime/localtime.c:1111: warning: assignment makes pointer from integer without a cast /usr/src/lib/libc_r/../libc/stdtime/localtime.c: In function `gmtime': /usr/src/lib/libc_r/../libc/stdtime/localtime.c:1195: too few arguments to function `pthread_getspecific' /usr/src/lib/libc_r/../libc/stdtime/localtime.c:1195: warning: assignment makes pointer from integer without a cast *** Error code 1 I *think* the solution is to backout the 1.10 -> 1.11 changes to localtime.c from 2.2, since that seems to work for both the normal libc and the threaded version. Nate From owner-freebsd-current Mon Dec 16 14:22:21 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA08607 for current-outgoing; Mon, 16 Dec 1996 14:22:21 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA08579; Mon, 16 Dec 1996 14:22:09 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id OAA06168; Mon, 16 Dec 1996 14:22:08 -0800 (PST) To: dicen@hooked.net cc: current@FreeBSD.ORG, ports@FreeBSD.ORG Subject: Re: pkg_manage and ports In-reply-to: Your message of "Mon, 16 Dec 1996 08:54:40 GMT." <32B50E50.41C67EA6@hooked.net> Date: Mon, 16 Dec 1996 14:22:08 -0800 Message-ID: <6164.850774928@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Has anyone messed with this code? It doesn't look like it has been > touched in years. pkg_manage is dead and has been removed from the -current tree for awhile. > On a side note I am currently working on a better ports management > system. Is anyone currently doing this? I don't want to duplicate work. > I was thinking about rewriting the src/usr.sbin/pkg_install source but I > am just writing some port management commands in bourne shell. It is > much easier that way. Hmmm. :-) I think we will simply have to wait and see what you come up with. Jordan From owner-freebsd-current Mon Dec 16 14:37:39 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA09619 for current-outgoing; Mon, 16 Dec 1996 14:37:39 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA09614 for ; Mon, 16 Dec 1996 14:37:36 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id OAA06281; Mon, 16 Dec 1996 14:37:25 -0800 (PST) To: Poul-Henning Kamp cc: Bill Paul , current@freebsd.org Subject: Re: Plan for integrating Secure RPC -- comments wanted In-reply-to: Your message of "Mon, 16 Dec 1996 16:44:19 +0100." <12149.850751059@critter.tfs.com> Date: Mon, 16 Dec 1996 14:37:25 -0800 Message-ID: <6277.850775845@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Not really. > > The trouble is that we cannot load a LKM until we have a RW fs :-( What if a small MFS were mounted on /tmp, or wherever, so that ld could do the relink? Jordan From owner-freebsd-current Mon Dec 16 14:41:07 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA09908 for current-outgoing; Mon, 16 Dec 1996 14:41:07 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id OAA09899 for ; Mon, 16 Dec 1996 14:41:02 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA02197; Mon, 16 Dec 1996 15:37:43 -0700 From: Terry Lambert Message-Id: <199612162237.PAA02197@phaeton.artisoft.com> Subject: Re: Warning -- Lite/2 merge coming up To: michaelh@cet.co.jp (Michael Hancock) Date: Mon, 16 Dec 1996 15:37:43 -0700 (MST) Cc: mark@grondar.za, toor@dyson.iquest.net, current@freebsd.org In-Reply-To: from "Michael Hancock" at Dec 16, 96 04:46: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 X-Loop: FreeBSD.org Precedence: bulk > > What about the other broken FS's, like union and null? > > The problems aren't addressed by Lite2. See my revent article on -hackers for details; specifically, the Heidemann framework is still "pounded in" as it comes from CSRG. 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 Dec 16 14:46:56 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA10381 for current-outgoing; Mon, 16 Dec 1996 14:46:56 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id OAA10368 for ; Mon, 16 Dec 1996 14:46:52 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA02231; Mon, 16 Dec 1996 15:45:12 -0700 From: Terry Lambert Message-Id: <199612162245.PAA02231@phaeton.artisoft.com> Subject: Re: Plan for integrating Secure RPC -- comments wanted To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Mon, 16 Dec 1996 15:45:12 -0700 (MST) Cc: wpaul@skynet.ctr.columbia.edu, current@freebsd.org In-Reply-To: <11680.850740486@critter.tfs.com> from "Poul-Henning Kamp" at Dec 16, 96 01:48: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 X-Loop: FreeBSD.org Precedence: bulk > read it, and here are my comments: > > For the DES pollution: > > Put DES in the kernel. > > This could be as an LKM, which would be the easiest, or as > a proper kernel-source file, which would be slightly harder > to manage distributions-wise. > > Result: > * You avoid your planned hack. > * We could do away with the two versions if libcrypt we have > now, and collapse them into one. > * Which makes the dual versions of /bin/ed, /sbin/init ... > unneeded. > * Our secure dist would consist of only the LKM file. > > Drawback: > * Minor optional kernel bloat. If this becomes the "official" approach, then may I suggest /dev/des (ala SunOS) instead of a system call? This would: * Avoid system call space pollution * Allow use of DES hardware if you had it and had a driver 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 Dec 16 14:49:01 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA10576 for current-outgoing; Mon, 16 Dec 1996 14:49:01 -0800 (PST) Received: from Cypress.Com (janus.cypress.com [157.95.1.1]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id OAA10569; Mon, 16 Dec 1996 14:48:59 -0800 (PST) Received: from diamond.cadc.cypress.com by Cypress.Com; Mon, 16 Dec 1996 14:48:02 -0800 Received: from onyx.cadc (onyx.cadc.cypress.com [157.95.15.17]) by diamond.cadc.cypress.com (8.8.2/8.8.2) with SMTP id QAA17214; Mon, 16 Dec 1996 16:47:52 -0600 (CST) Received: by onyx.cadc (SMI-8.6/SMI-SVR4) id QAA17614; Mon, 16 Dec 1996 16:47:51 -0600 Date: Mon, 16 Dec 1996 16:47:51 -0600 Message-Id: <199612162247.QAA17614@onyx.cadc> From: Barry Boes/CADC Datacomm CAD To: owensc@enc.edu, current@freebsd.org, stable@freebsd.org Subject: Re: IP masquerading (for a LAN, _not_ PPP) In-Reply-To: References: Cc: bab@cypress.com Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I need to do the same thing. I'm looking at using the 2.2 divert sockets and code like (or maybe borrowed from) the PPP masquerading code. Does anyone know if this is what Linux does? Is there anyone else out there who has already done this or are we exploring new frontiers? > From: Charles Owens > > On Sun, 8 Dec 1996, Gary Roberts wrote: > > > On Sun, 8 Dec 1996, DNEX wrote: > > > > > Does FreeBSD support IP masquerading or are there plans to implement it? > > > > > > > Yes. It does. Charles Mott. Nice piece of software. Anyways, it's not > > a program like linux uses, it uses the PPP program. Check it out at: > > > > http://www.srv.net/~cmott/alias.html > > > This looks nifty, but I'm interested in doing masquerading on a firewall > for users on a large LAN, not dialing in via PPP. What's the status of > doing _this_ with FreeBSD? From owner-freebsd-current Mon Dec 16 14:52:21 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA11011 for current-outgoing; Mon, 16 Dec 1996 14:52:21 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id OAA11002 for ; Mon, 16 Dec 1996 14:52:16 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA02243; Mon, 16 Dec 1996 15:50:47 -0700 From: Terry Lambert Message-Id: <199612162250.PAA02243@phaeton.artisoft.com> Subject: Re: Plan for integrating Secure RPC -- comments wanted To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Mon, 16 Dec 1996 15:50:47 -0700 (MST) Cc: wpaul@skynet.ctr.columbia.edu, current@freebsd.org In-Reply-To: <12149.850751059@critter.tfs.com> from "Poul-Henning Kamp" at Dec 16, 96 04:44:19 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 X-Loop: FreeBSD.org Precedence: bulk > >Do we really want to make people recompile the kernel to get DES support? > > Not really. > > The trouble is that we cannot load a LKM until we have a RW fs :-( Because the kernel doesn't know its own symbols, and because the LKM external reference relocation is done in user space, when it should be done in system space. Not because the idea itself requires a RW FS, but because (my) broken implementation from early 1994 uses the user space ld to build an object. 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 Dec 16 14:54:55 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA11212 for current-outgoing; Mon, 16 Dec 1996 14:54:55 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id OAA11200 for ; Mon, 16 Dec 1996 14:54:52 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA02252; Mon, 16 Dec 1996 15:53:12 -0700 From: Terry Lambert Message-Id: <199612162253.PAA02252@phaeton.artisoft.com> Subject: Re: Plan for integrating Secure RPC -- comments wanted To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Mon, 16 Dec 1996 15:53:12 -0700 (MST) Cc: peter@spinner.DIALix.COM, freebsd-current@freebsd.org In-Reply-To: <12325.850754402@critter.tfs.com> from "Poul-Henning Kamp" at Dec 16, 96 05:40:02 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 X-Loop: FreeBSD.org Precedence: bulk > >Why don't we just give in and make a dual-mode libcrypt with the > >exportable des one-way hash code like all the other vendors are doing? > >(and of course, the MD5 hash code) > > I'm game. Although this doesn't solve the problem with /bin/ed and > other legitimate users of DES, secure RPC for instance. Heh. "Making RPC calls the government can't read is not legitimate use". 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 Dec 16 14:59:01 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA11570 for current-outgoing; Mon, 16 Dec 1996 14:59:01 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA11542; Mon, 16 Dec 1996 14:58:46 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.2/8.8.2) with SMTP id OAA06326; Mon, 16 Dec 1996 14:53:38 -0800 (PST) Message-ID: <32B5D2C4.41C67EA6@whistle.com> Date: Mon, 16 Dec 1996 14:52:52 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Charles Owens CC: Gary Roberts , DNEX , current@freebsd.org, stable@freebsd.org Subject: Re: IP masquerading (for a LAN, _not_ PPP) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Charles Owens wrote: > > On Sun, 8 Dec 1996, Gary Roberts wrote: > > > On Sun, 8 Dec 1996, DNEX wrote: > > > > > Does FreeBSD support IP masquerading or are there plans to implement it? > > > > > > > Yes. It does. Charles Mott. Nice piece of software. Anyways, it's not > > a program like linux uses, it uses the PPP program. Check it out at: > > > > http://www.srv.net/~cmott/alias.html > > This looks nifty, but I'm interested in doing masquerading on a firewall > for users on a large LAN, not dialing in via PPP. What's the status of > doing _this_ with FreeBSD? FreeBSD 2.2 includes the feature "DIVERT SOCKETS" these can be used in conjunction with the ipfw code to create a translation feature. Use the 'divert' keyword with the Ipfw to divert a packet to a 'divert socket' that is openned by the translation daemon. the daemon monitors incoming packets and 'fiddles' the headers accordingly. It also dynamically changes the firewall rules depending on the sessions being translated. We have that runing here but unfortunatly, while we were able to give the divert code out, we can'r give out the daemon.. julian > > --- > - From owner-freebsd-current Mon Dec 16 15:35:14 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA14024 for current-outgoing; Mon, 16 Dec 1996 15:35:14 -0800 (PST) Received: from gate.lustig.com (116.san-francisco-003.ca.dial-access.att.net [207.147.234.116]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id PAA13989; Mon, 16 Dec 1996 15:35:00 -0800 (PST) Received: from Lustig.COM (devious.lustig.com [192.168.1.3]) by gate.lustig.com (8.7.6/8.7.3) with ESMTP id PAA28983; Mon, 16 Dec 1996 15:34:45 -0800 (PST) Received: (from barry@localhost) by Lustig.COM (8.7.3/8.7.3) id PAA10158; Mon, 16 Dec 1996 15:34:50 -0800 (PST) Message-Id: <199612162334.PAA10158@Lustig.COM> MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: X-Nextstep-Mailer: Mail 3.3 (Enhance 1.2) Received: by NeXT.Mailer (1.118.2.RR) From: Barry Lustig Date: Mon, 16 Dec 96 15:34:48 -0800 To: Charles Owens Subject: Re: IP masquerading (for a LAN, _not_ PPP) cc: current@FreeBSD.ORG, stable@FreeBSD.ORG Reply-To: barry@Lustig.COM References: X-Organizations: Barry Lustig & Associates Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Take a look at IP Filter http://coombs.anu.edu.au/~avalon/. barry > X-POP3-Rcpt: barry@rmc1.crocker.com > Date: Mon, 16 Dec 1996 16:03:42 -0500 (EST) > From: Charles Owens > X-Sender: owensc@dingo.its.enc.edu > To: Gary Roberts > cc: DNEX , current@FreeBSD.ORG, stable@FreeBSD.ORG > Subject: Re: IP masquerading (for a LAN, _not_ PPP) > In-Reply-To: > > Sender: owner-current@FreeBSD.ORG > X-Loop: FreeBSD.org > > On Sun, 8 Dec 1996, Gary Roberts wrote: > > > On Sun, 8 Dec 1996, DNEX wrote: > > > > > Does FreeBSD support IP masquerading or are there plans to implement > it? > > > > > > Yes. It does. Charles Mott. Nice piece of software. Anyways, it's > not > a program like linux uses, it uses the PPP program. Check it out > at: > > > > http://www.srv.net/~cmott/alias.html > > > This looks nifty, but I'm interested in doing masquerading on a firewall > for users on a large LAN, not dialing in via PPP. What's the status of > doing _this_ with FreeBSD? > > --- > ------------------------------------------------------------------------- > Charles Owens Email: owensc@enc.edu > "I read somewhere to learn is to > Information Technology Services remember... and I've learned that > Eastern Nazarene College we've all forgot..." - King's X > ------------------------------------------------------------------------- > > From owner-freebsd-current Mon Dec 16 15:38:11 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA14439 for current-outgoing; Mon, 16 Dec 1996 15:38:11 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id PAA14425 for ; Mon, 16 Dec 1996 15:37:59 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id QAA05223; Mon, 16 Dec 1996 16:37:58 -0700 (MST) Date: Mon, 16 Dec 1996 16:37:58 -0700 (MST) Message-Id: <199612162337.QAA05223@rocky.mt.sri.com> From: Nate Williams To: current@freebsd.org Subject: More breakage in -current and 2.2 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk tclsh fails under 2.2 cc -O2 -m486 -pipe -static -o tclsh tclAppInit.o -ltcl -lm tclCmdIL.o: Undefined symbol `_TclGetLoadedPackages' referenced from text segment tclBasic.o: Undefined symbol `_Tcl_LoadCmd' referenced from data segment *** Error code 1 And, under current I can't get routed to build. nec:/usr/src/sbin/routed # make cc -O2 -m486 -pipe -c /usr/src/sbin/routed/input.c /usr/src/sbin/routed/input.c: In function `input': /usr/src/sbin/routed/input.c:403: `RIP_AUTH_MD5' undeclared (first use this function) /usr/src/sbin/routed/input.c:403: (Each undeclared identifier is reported only once /usr/src/sbin/routed/input.c:403: for each function it appears in.) /usr/src/sbin/routed/input.c:547: `RIP_AUTH_NONE' undeclared (first use this function) /usr/src/sbin/routed/input.c: In function `ck_passwd': /usr/src/sbin/routed/input.c:873: structure has no member named `rip_auths' /usr/src/sbin/routed/input.c:873: structure has no member named `rip_auths' /usr/src/sbin/routed/input.c:882: structure has no member named `rip_auths' /usr/src/sbin/routed/input.c:887: structure has no member named `rip_auths' /usr/src/sbin/routed/input.c:888: structure has no member named `rip_auths' /usr/src/sbin/routed/input.c:894: structure has no member named `rip_auths' /usr/src/sbin/routed/input.c:897: structure has no member named `rip_auths' /usr/src/sbin/routed/input.c:898: structure has no member named `rip_auths' /usr/src/sbin/routed/input.c:899: structure has no member named `rip_auths' /usr/src/sbin/routed/input.c:899: structure has no member named `rip_auths' /usr/src/sbin/routed/input.c:903: structure has no member named `rip_auths' /usr/src/sbin/routed/input.c:908: structure has no member named `rip_auths' /usr/src/sbin/routed/input.c:909: structure has no member named `rip_auths' /usr/src/sbin/routed/input.c:913: structure has no member named `a_family' /usr/src/sbin/routed/input.c:915: structure has no member named `rip_auths' *** Error code 1 Stop. From owner-freebsd-current Mon Dec 16 15:46:34 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA14960 for current-outgoing; Mon, 16 Dec 1996 15:46:34 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id PAA14951 for ; Mon, 16 Dec 1996 15:46:31 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id QAA05267; Mon, 16 Dec 1996 16:46:21 -0700 (MST) Date: Mon, 16 Dec 1996 16:46:21 -0700 (MST) Message-Id: <199612162346.QAA05267@rocky.mt.sri.com> From: Nate Williams To: Nate Williams Cc: current@freebsd.org Subject: Re: libc_r broken in 2.2 In-Reply-To: <199612162209.PAA04571@rocky.mt.sri.com> References: <199612162209.PAA04571@rocky.mt.sri.com> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Something new got merged in the stdtime code but didn't get updated in > the thread code that caused the threaded version to die. ... > I *think* the solution is to backout the 1.10 -> 1.11 changes to > localtime.c from 2.2, since that seems to work for both the normal libc > and the threaded version. This also requires backing out the 1.6 revision of include/time.h as well. Nate From owner-freebsd-current Mon Dec 16 15:51:14 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA15296 for current-outgoing; Mon, 16 Dec 1996 15:51:14 -0800 (PST) Received: from axis.axisnet.net (ali@axis.axisnet.net [206.54.226.1]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id PAA15289 for ; Mon, 16 Dec 1996 15:51:06 -0800 (PST) Received: from localhost (ali@localhost) by axis.axisnet.net (8.8.3/8.8.3) with SMTP id RAA10503 for ; Mon, 16 Dec 1996 17:52:14 -0600 Date: Mon, 16 Dec 1996 17:52:14 -0600 (CST) From: Ali Lomonaco To: current@freebsd.org Subject: Fetch Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have discoverd something wierd with fetch from a build of -CURRENT that I did 4 days ago. When trying to fetch something from deshaw.com I got "fetch: ftp.deshaw.com: Not logged in". I tried fetching manually and still I got that error. I even tried to fetch stuff that didn't exist and got that error. I don't know if this is libftpio specific or what. Just thought I would report it. From owner-freebsd-current Mon Dec 16 16:18:27 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA18185 for current-outgoing; Mon, 16 Dec 1996 16:18:27 -0800 (PST) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id QAA18138; Mon, 16 Dec 1996 16:17:54 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr2-41.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA02496 (5.67b/IDA-1.5); Tue, 17 Dec 1996 01:17:18 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.4/8.6.9) id BAA02886; Tue, 17 Dec 1996 01:17:15 +0100 (CET) Message-Id: Date: Tue, 17 Dec 1996 01:17:15 +0100 From: se@FreeBSD.org (Stefan Esser) To: bde@zeta.org.au (Bruce Evans) Cc: max@wide.ad.jp, se@FreeBSD.org, current@FreeBSD.org Subject: Re: Error with current ncr.c References: <199612161639.DAA16927@godzilla.zeta.org.au> X-Mailer: Mutt 0.53 Mime-Version: 1.0 In-Reply-To: <199612161639.DAA16927@godzilla.zeta.org.au>; from Bruce Evans on Dec 17, 1996 03:39:29 +1100 Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Dec 17, bde@zeta.org.au (Bruce Evans) wrote: > >I'll make sure that the #include is > >ignored in the ncrcontrol build ... > > This doesn't work, since e.g. SCI_NCR_DFLT_TAGS affects MAX_START which > affects `struct ncb' which must be the same in the kernel and ncrcontrol. > This is the old FAILSAFE configuration bug. Yes, I know about this. The best way to have a kernel and corresponding ncrcontrol with non-default settings of those defines is to put them at the start of /sys/pci/ncr.c, where both the driver and the ncrcontrol build will see them. This is in part a result of the fact, that "ncrcontrol" was mainly an internal test tool, which got features over time, some of which seemed nice to be generally available. I've planned other major changes to the driver, and won't spend time, now, to clean this up. My spare time is rather limited (whose isn't), and I think I should work on other things right now (eg. full Ultra-SCSI support and other driver improvements). Regards, STefan From owner-freebsd-current Mon Dec 16 16:52:59 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA20385 for current-outgoing; Mon, 16 Dec 1996 16:52:59 -0800 (PST) Received: from fools.ecpnet.com (moke@fools.winternet.com [204.246.64.101]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA20377 for ; Mon, 16 Dec 1996 16:52:52 -0800 (PST) Received: from localhost (moke@localhost) by fools.ecpnet.com (8.8.4/8.8.3) with SMTP id SAA02211 for ; Mon, 16 Dec 1996 18:51:41 -0600 (CST) Date: Mon, 16 Dec 1996 18:51:41 -0600 (CST) From: Jimbo Bahooli To: freebsd-current@freebsd.org Subject: cvsup clobbering local changes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Cvsup here clobbers all my local changes, even with the delete key taken out. Is there a way I can get it to stop doing this, or better yet is there a read-only cvs account that freebsd users can use? From owner-freebsd-current Mon Dec 16 16:56:08 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA20773 for current-outgoing; Mon, 16 Dec 1996 16:56:08 -0800 (PST) Received: (from pst@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA20759; Mon, 16 Dec 1996 16:56:05 -0800 (PST) Date: Mon, 16 Dec 1996 16:56:05 -0800 (PST) From: Paul Traina Message-Id: <199612170056.QAA20759@freefall.freebsd.org> To: committers, current Subject: cron Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I've got more work I want to do on cron when I get back into town in a few weeks. For now, I just put in the obviously "good" stuff from OpenBSD. From owner-freebsd-current Mon Dec 16 17:10:24 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA21563 for current-outgoing; Mon, 16 Dec 1996 17:10:24 -0800 (PST) Received: from research.gate.nec.co.jp (research.gate.nec.co.jp [202.32.8.49]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA21557 for ; Mon, 16 Dec 1996 17:10:21 -0800 (PST) Received: from sbl-gw.sbl.cl.nec.co.jp by research.gate.nec.co.jp (8.8.3p1+2.6Wbeta9/950912) with ESMTP id KAA26182; Tue, 17 Dec 1996 10:10:14 +0900 (JST) Received: from sirius.sbl.cl.nec.co.jp by sbl-gw.sbl.cl.nec.co.jp (8.7.6+2.6Wbeta7/3.3W6) with ESMTP id KAA20187; Tue, 17 Dec 1996 10:10:12 +0900 (JST) Received: by sirius.sbl.cl.nec.co.jp (8.7.5+2.6Wbeta6/3.3W6) with UUCP id KAA17775; Tue, 17 Dec 1996 10:10:12 +0900 (JST) Date: Tue, 17 Dec 1996 10:10:12 +0900 (JST) From: Naoki Hamada Message-Id: <199612170110.KAA17775@sirius.sbl.cl.nec.co.jp> References: To: gena@NetVision.net.il CC: current@freebsd.org In-reply-to: Gennady Sorokopud's message of "Mon, 16 Dec 1996 17:39:08 +0200 (IST)" Subject: Re: -current and vx0 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Gennady B. Sorokopud: >I just recompiled today's -current kernel (CVSupped about 10 hours ago) and >find out that my 3C590 PCI Ethernet no longer works. No packets can be sent >from/to the system. The kernel from 12/12/96 worked just fine. Hmm, anyone has an idea? Mine still works well. >(it was always identified as "defective", but worked just fine until now). Although 3COM says that defective adapters may cause overruns, they usually seem to work quite fine. -nao From owner-freebsd-current Mon Dec 16 17:14:43 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA21839 for current-outgoing; Mon, 16 Dec 1996 17:14:43 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA21833 for ; Mon, 16 Dec 1996 17:14:40 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id RAA14835; Mon, 16 Dec 1996 17:14:33 -0800 (PST) To: barry@Lustig.COM cc: Charles Owens , current@FreeBSD.ORG Subject: Re: IP masquerading (for a LAN, _not_ PPP) In-reply-to: Your message of "Mon, 16 Dec 1996 15:34:48 PST." <199612162334.PAA10158@Lustig.COM> Date: Mon, 16 Dec 1996 17:14:33 -0800 Message-ID: <14831.850785273@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Take a look at IP Filter http://coombs.anu.edu.au/~avalon/. We really should bring this into -current at some point, now that we've branched. C'mon, there must be someone out there in -current land who's a) into networking, b) on the committers list and c) wants to see this go in. ;) Jordan From owner-freebsd-current Mon Dec 16 17:18:32 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA22030 for current-outgoing; Mon, 16 Dec 1996 17:18:32 -0800 (PST) Received: from mule1.mindspring.com (mule1.mindspring.com [204.180.128.167]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA22025 for ; Mon, 16 Dec 1996 17:18:28 -0800 (PST) Received: from rlb.users.mindspring.com (user-168-121-25-139.dialup.mindspring.com [168.121.25.139]) by mule1.mindspring.com (8.8.2/8.7.3) with SMTP id BAA36608 for ; Tue, 17 Dec 1996 01:18:06 GMT Message-ID: <32B5F4D3.167EB0E7@mindspring.com> Date: Mon, 16 Dec 1996 20:18:16 -0500 From: Ron Bolin X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: /usr/sbin/lsdev in current? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I noticed that lsdev is not updated when I build from source. I tried to locate the source, but so far have not found it. Is lsdev supported in current? Ron -- **************************************************************************** Ron Bolin rlb@mindspring.com, http://www.mindspring.com/~rlb/ GSU: gs01rlb@panther.gsu.edu matrlbx@indigo4.cs.gsu.edu Home: 770-992-8877 **************************************************************************** From owner-freebsd-current Mon Dec 16 17:41:03 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA23270 for current-outgoing; Mon, 16 Dec 1996 17:41:03 -0800 (PST) Received: from gaia.coppe.ufrj.br (root@cisigw.coppe.ufrj.br [146.164.2.31]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA23265 for ; Mon, 16 Dec 1996 17:41:00 -0800 (PST) Received: (from jonny@localhost) by gaia.coppe.ufrj.br (8.8.3/8.7.3) id XAA02665; Mon, 16 Dec 1996 23:40:30 -0200 (EDT) From: Joao Carlos Mendes Luis Message-Id: <199612170140.XAA02665@gaia.coppe.ufrj.br> Subject: Re: Warning -- Lite/2 merge coming up To: mark@grondar.za (Mark Murray) Date: Mon, 16 Dec 1996 23:40:30 -0200 (EDT) Cc: toor@dyson.iquest.net, current@FreeBSD.ORG In-Reply-To: <199612161414.QAA20372@grackle.grondar.za> from Mark Murray at "Dec 16, 96 04:14:25 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk "John S. Dyson" wrote: > > What about the other broken FS's, like union and null? > > > We have been holding off until the Lite/2 merge. Lite/2 might fix > some of the problems. Sometime ago I was reading the unionfs algorithm on the 4.4 BSD book. One problem that came to my mind was about the deleted files. It says that if one file on the lower layer is deleted, as it shall not be really deleted, an entry on the upper layer directory is created with the I-node 1. Ok, when I dismount the union, how will this I-node 1 behave ? Is it valid ? Should it be ignored or deleted ? What's its type ? When I remount the union, shall the lower "deleted" file exist or not ? If I compare unionfs to linkdir, "dismounting" should give a ENOENT error to the syscall attempting to access the I-node 1 file. Also, both keeping or not the "deleted" file approaches can be obtained. And, the final problem: When making a copy from lower to upper layer (to permit a write access to some file) should this be done by the kernel ? Is it a good approach ? This could mean a very large operation, and I don't like to keep the kernel busy for such a long time. Maybe a daemon implementation (just like portal) should do this job better. Jonny BTW: Is this discussion better suited on -hackers ? -- Joao Carlos Mendes Luis jonny@gta.ufrj.br +55 21 290-4698 ( Job ) jonny@cisi.coppe.ufrj.br Network Manager UFRJ/COPPE/CISI Universidade Federal do Rio de Janeiro From owner-freebsd-current Mon Dec 16 17:42:01 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA23317 for current-outgoing; Mon, 16 Dec 1996 17:42:01 -0800 (PST) Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA23303 for ; Mon, 16 Dec 1996 17:41:56 -0800 (PST) Received: from campa.panke.de (anonymous214.ppp.cs.tu-berlin.de [130.149.17.214]) by mail.cs.tu-berlin.de (8.6.13/8.6.12) with ESMTP id CAA10294 for ; Tue, 17 Dec 1996 02:26:41 +0100 Received: (from wosch@localhost) by campa.panke.de (8.6.12/8.6.12) id CAA02231; Tue, 17 Dec 1996 02:24:34 +0100 Date: Tue, 17 Dec 1996 02:24:34 +0100 From: Wolfram Schneider Message-Id: <199612170124.CAA02231@campa.panke.de> To: current@freebsd.org cc: wpaul@frebsd.org.cs.tu-berlin.de Subject: group(5) limits MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The current limit is 200 members per group or maximum 1024 character per line. I changed getgrent(3) to use dynamic allocated buffers instead static buffers. No member or line length limit anymore - now 500 members or 5000 members are possible. For security group lines longer than 256K will be ignored. 256K should be enough for ~50000 users. --- 1.1 1996/12/13 23:57:21 +++ getgrent.c 1996/12/17 00:55:23 @@ -55,10 +55,19 @@ static int _nextypgroup(struct group *); #endif -#define MAXGRP 200 -static char *members[MAXGRP]; -#define MAXLINELENGTH 1024 -static char line[MAXLINELENGTH]; + +#define MAXGRP 64 +#define MAXLINELENGTH 256 + +static char **members; /* list of group members */ +static int maxgrp; /* current length of **mebers */ +static char *line; /* temp buffer for group line */ +static int maxlinelength; /* current length of *line */ + +/* < 0 disable check for maximum line length */ +/* 256K is enough for 64,000 uids */ +#define MAXLINELENGTHLIMIT (256*1024) + struct group * getgrent() @@ -176,6 +185,20 @@ rewind(_gr_fp); } #endif + + if (maxlinelength == 0) { + if ((line = (char *)malloc(sizeof(char) * + MAXLINELENGTH)) == NULL) + return(0); + maxlinelength += MAXLINELENGTH; + } + if (maxgrp == 0) { + if ((members = (char **)malloc(sizeof(char **) * + MAXGRP)) == NULL) + return(0); + maxgrp += MAXGRP; + } + return 1; } @@ -207,6 +230,9 @@ if (_gr_fp) { (void)fclose(_gr_fp); _gr_fp = NULL; + free(line); + free(members); + maxlinelength = maxgrp = 0; } } @@ -217,24 +243,53 @@ { register char *cp, **m; char *bp; + + #ifdef YP int _ypfound; -#endif; +#endif for (;;) { #ifdef YP _ypfound = 0; #endif - if (!fgets(line, sizeof(line), _gr_fp)) + if (fgets(line, maxlinelength, _gr_fp) == NULL) return(0); - bp = line; - /* skip lines that are too big */ + if (!index(line, '\n')) { - int ch; + do { + if (feof(_gr_fp)) + return(0); + + /* don't allocate infinite memory */ + if (MAXLINELENGTHLIMIT > 0 && + maxlinelength >= MAXLINELENGTHLIMIT) + return(0); - while ((ch = getc(_gr_fp)) != '\n' && ch != EOF) - ; - continue; + if ((line = (char *)realloc(line, + sizeof(char) * + (maxlinelength + MAXLINELENGTH))) == NULL) + return(0); + + if (fgets(line + maxlinelength - 1, + MAXLINELENGTH + 1, _gr_fp) == NULL) + return(0); + + maxlinelength += MAXLINELENGTH; + } while (!index(line + maxlinelength - + MAXLINELENGTH - 1, '\n')); } + +#if 1 + /* + * Ignore comments. A comment is a line which start + * with character `#'. + */ + if (*line == '#') + continue; +#endif + + bp = line; + if ((_gr_group.gr_name = strsep(&bp, ":\n")) == NULL) break; #ifdef YP @@ -290,9 +345,11 @@ break; #endif if (!(cp = strsep(&bp, ":\n"))) +#ifdef YP if (_ypfound) return(1); else +#endif /* YP */ continue; #ifdef YP /* @@ -318,9 +375,16 @@ bp = cp; cp = NULL; #endif - for (m = _gr_group.gr_mem = members;; bp++) { - if (m == &members[MAXGRP - 1]) - break; + for (m = members; ; bp++) { + if (m == (members + maxgrp - 1)) { + if ((members = (char **) + realloc(members, + sizeof(char **) * + (maxgrp + MAXGRP))) == NULL) + return(0); + m = members + maxgrp - 1; + maxgrp += MAXGRP; + } if (*bp == ',') { if (cp) { *bp = '\0'; @@ -331,11 +395,13 @@ if (cp) { *bp = '\0'; *m++ = cp; - } + } break; } else if (cp == NULL) cp = bp; + } + _gr_group.gr_mem = members; *m = NULL; return(1); } @@ -368,9 +434,13 @@ if ((s = result) == NULL) return 0; cp = 0; - for (m = _gr_group.gr_mem = members; /**/; s++) { - if (m == &members[MAXGRP - 1]) { - break; + for (m = members; ; s++) { + if (m == members + maxgrp - 1) { + if ((members = (char **)realloc(members, + sizeof(char **) * (maxgrp + MAXGRP))) == NULL) + return(0); + m = members + maxgrp - 1; + maxgrp += MAXGRP; } if (*s == ',') { if (cp) { @@ -388,6 +458,7 @@ cp = s; } } + _gr_group.gr_mem = members; *m = NULL; return 1; From owner-freebsd-current Mon Dec 16 18:05:25 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id SAA24755 for current-outgoing; Mon, 16 Dec 1996 18:05:25 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id SAA24748 for ; Mon, 16 Dec 1996 18:05:22 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA07434; Mon, 16 Dec 1996 19:03:52 -0700 From: Terry Lambert Message-Id: <199612170203.TAA07434@phaeton.artisoft.com> Subject: Re: cvsup clobbering local changes To: moke@fools.ecpnet.com (Jimbo Bahooli) Date: Mon, 16 Dec 1996 19:03:52 -0700 (MST) Cc: freebsd-current@freebsd.org In-Reply-To: from "Jimbo Bahooli" at Dec 16, 96 06:51:41 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 X-Loop: FreeBSD.org Precedence: bulk > Cvsup here clobbers all my local changes, even with the delete key taken > out. Is there a way I can get it to stop doing this, or better yet is > there a read-only cvs account that freebsd users can use? You need to set a local tag before you make local changes. Otherwise, your local changes will occur on the defualt tag, which is the one -current is using. If they conflict with yours, theirs wins. 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 Dec 16 20:06:56 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA24531 for current-outgoing; Mon, 16 Dec 1996 20:06:56 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id UAA24522; Mon, 16 Dec 1996 20:06:52 -0800 (PST) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14555(5)>; Mon, 16 Dec 1996 20:06:21 PST Received: by crevenia.parc.xerox.com id <177711>; Mon, 16 Dec 1996 20:06:19 -0800 From: Bill Fenner To: current@freebsd.org, jkh@freebsd.org Subject: sysinstall REALLY needs a "reset FTP state" option, or something Message-Id: <96Dec16.200619pst.177711@crevenia.parc.xerox.com> Date: Mon, 16 Dec 1996 20:06:15 PST Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I just spent about 15 minutes carefully choosing which distributions to install, and then said "go". I came back an hour later, and it was 87% done with bin. Another hour later, and it was still 87% done with bin. The FTP connection had hung somehow. It's *really* frustrating to have two choices: stay hung, or reboot. Is there any way that a control-C while ftp'ing could allow another option of disconnecting and reconnecting to the same server? (Or, even better, a keepalive so that a connection that hasn't transferred a byte in an hour times out and you get the ftp reselection menu...) Bill From owner-freebsd-current Mon Dec 16 20:18:22 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA24999 for current-outgoing; Mon, 16 Dec 1996 20:18:22 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id UAA24993 for ; Mon, 16 Dec 1996 20:18:18 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.2/8.8.2) with SMTP id UAA11594; Mon, 16 Dec 1996 20:11:27 -0800 (PST) Message-ID: <32B61D41.167EB0E7@whistle.com> Date: Mon, 16 Dec 1996 20:10:41 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: "Jordan K. Hubbard" CC: barry@Lustig.COM, Charles Owens , current@FreeBSD.ORG Subject: Re: IP masquerading (for a LAN, _not_ PPP) References: <14831.850785273@time.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard wrote: > > > Take a look at IP Filter http://coombs.anu.edu.au/~avalon/. > > We really should bring this into -current at some point, now that > we've branched. C'mon, there must be someone out there in -current > land who's a) into networking, b) on the committers list and c) wants > to see this go in. ;) welll there are some good things that ipfw does too.... > > Jordan From owner-freebsd-current Mon Dec 16 21:40:38 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id VAA00419 for current-outgoing; Mon, 16 Dec 1996 21:40:38 -0800 (PST) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id VAA00410 for ; Mon, 16 Dec 1996 21:40:31 -0800 (PST) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id AAA01464; Tue, 17 Dec 1996 00:38:32 -0500 From: Bill Paul Message-Id: <199612170538.AAA01464@skynet.ctr.columbia.edu> Subject: Re: Plan for integrating Secure RPC -- comments wanted To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Tue, 17 Dec 1996 00:38:30 -0500 (EST) Cc: current@freebsd.org In-Reply-To: <12149.850751059@critter.tfs.com> from "Poul-Henning Kamp" at Dec 16, 96 04:44:19 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Of all the gin joints in all the towns in all the world, Poul-Henning Kamp had to walk into mine and say: [chop] > >> For the issue of authenticated local transport: > >> > >> Instead of an LKM, put the code in the kernel. It shouldn't be too > >> hard to make it a getsockopt() instead of a LKM. > > > >I'll check into this. I don't really consider myself an advanced > >enough kernel hacker for this, but maybe I'll get lucky. > > Hey, you're talking about makeing LKM's all the time :-) Okay, on your advice, I tried this. I added a new option called SO_PEERUID and it works (I also made it scan the global list of open file descriptors to get the creds of the remote process so the caller doesn't need to specify the PID of the remote process). But while testing I noticed something which I think is a bug. For giggles, I tried calling getsockopt() like this: int optlen; int optval; int sock; int rval; optlen = sizeof(optval); rval = getsockopt(sock, SOL_SOCKET, SO_PEERUID, NULL, &optlen); /* ^^^^ */ /* deliberate bug: should be &optval */ According to the man page, getsockopt() should return EFAULT if optval or optlen aren't within the process's address space. Well, NULL is not within the process's address space, so I should get an error here, but I don't. If I do something equally silly like use -1 instead of NULL, then I get an EFAULT as expected. With NULL, the getsockopt() call doesn't do anything, but it returns an rval of 0 and doesn't set errno. Looking at the getsockopt() code, it seems like it short-circuits the uap->val (i.e. optval) == NULL case on purpose and doesn't return an error. Am I nuts, or is this a bug? -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= From owner-freebsd-current Mon Dec 16 21:59:46 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id VAA00943 for current-outgoing; Mon, 16 Dec 1996 21:59:46 -0800 (PST) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id VAA00936 for ; Mon, 16 Dec 1996 21:59:41 -0800 (PST) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id AAA01510; Tue, 17 Dec 1996 00:57:49 -0500 From: Bill Paul Message-Id: <199612170557.AAA01510@skynet.ctr.columbia.edu> Subject: Re: group(5) limits To: wosch@cs.tu-berlin.de (Wolfram Schneider) Date: Tue, 17 Dec 1996 00:57:48 -0500 (EST) Cc: current@freebsd.org In-Reply-To: <199612170124.CAA02231@campa.panke.de> from "Wolfram Schneider" at Dec 17, 96 02:24:34 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Of all the gin joints in all the towns in all the world, Wolfram Schneider had to walk into mine and say: > The current limit is 200 members per group or maximum 1024 character per > line. I changed getgrent(3) to use dynamic allocated buffers > instead static buffers. No member or line length limit anymore - > now 500 members or 5000 members are possible. > > For security group lines longer than 256K will be ignored. > 256K should be enough for ~50000 users. While removing the static membership limit of 200 is probably okay, NIS v2 is permanently saddled with a record limit of 1024 bytes. The yp_mkdb(8) utility enforces this. The limit is part of the yp.x protocol, consequently to change it would break compatibility with all other NIS implementations. This means these changes would be fine for local /etc/group files, but you'd still be stuck with a 1024 byte line limit if you choose to use NIS. NIS+ is a different story; I don't think the protocol definition imposes any limit on the size of an entry value buffer. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= From owner-freebsd-current Mon Dec 16 22:19:56 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA02028 for current-outgoing; Mon, 16 Dec 1996 22:19:56 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id WAA02023; Mon, 16 Dec 1996 22:19:52 -0800 (PST) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16974(1)>; Mon, 16 Dec 1996 22:19:21 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177711>; Mon, 16 Dec 1996 22:19:11 -0800 To: Bill Fenner cc: current@freebsd.org, jkh@freebsd.org Subject: Re: sysinstall REALLY needs a "reset FTP state" option, or something In-reply-to: Your message of "Mon, 16 Dec 96 20:06:15 PST." <96Dec16.200619pst.177711@crevenia.parc.xerox.com> Date: Mon, 16 Dec 1996 22:18:58 PST From: Bill Fenner Message-Id: <96Dec16.221911pst.177711@crevenia.parc.xerox.com> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk More on the sysinstall hang; I can't tell if this is an FTP proxy bug or a sysinstall bug, since I didn't get to snoop the control connection. I see: DEBUG: send DEBUG: received <200 ...> DEBUG: send DEBUG: Switching back to VTY1 Note no "received <150 ...>". When I tcpdump, I see window probes going from the FTP server to the client, on port 1331 aka 5,51: 22:07:01.538273 beta.3126 > fenestro.1331: . 1196817521:1196817522(1) ack 1117785547 win 24576 22:07:01.538509 fenestro.1331 > beta.3126: . ack 1196817521 win 0 (DF) 22:08:01.541976 beta.3126 > fenestro.1331: . 1196817521:1196817522(1) ack 1117785547 win 24576 22:08:01.542215 fenestro.1331 > beta.3126: . ack 1196817521 win 0 (DF) so it looks like sysinstall is hung waiting for the response to the "RETR" and not reading any of the data that's arriving on the data port. I guess I'll start another sysinstall and "tcpdump -w" the FTP control connection. (But of course the next one probably won't hang...) Bill From owner-freebsd-current Mon Dec 16 22:49:17 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA04041 for current-outgoing; Mon, 16 Dec 1996 22:49:17 -0800 (PST) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id WAA04036 for ; Mon, 16 Dec 1996 22:49:15 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id WAA22595; Mon, 16 Dec 1996 22:48:43 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma022593; Mon Dec 16 22:48:20 1996 Received: (from archie@localhost) by bubba.whistle.com (8.7.5/8.6.12) id WAA13466; Mon, 16 Dec 1996 22:48:20 -0800 (PST) From: Archie Cobbs Message-Id: <199612170648.WAA13466@bubba.whistle.com> Subject: Re: IP masquerading (for a LAN, _not_ PPP) In-Reply-To: <32B61D41.167EB0E7@whistle.com> from Julian Elischer at "Dec 16, 96 08:10:41 pm" To: julian@whistle.com (Julian Elischer) Date: Mon, 16 Dec 1996 22:48:19 -0800 (PST) Cc: jkh@time.cdrom.com, barry@Lustig.COM, owensc@enc.edu, current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk IMHO, the most useful way to implement ipfw is using divert sockets.. because it makes it a completely independent module that is easy to hack & develop from user mode. The disadvantage of course is that it's somewhat slower than a kernel-only implementation (we haven't found this to be a problem though). Although we can't release our code that does this right now, I'd be more than happy to "advise" anyone who is interested in porting any of the existing address translation code to use divert sockets... if it's written in a reasonably sane fashion, it shouldn't be very hard in any case. FWIW, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-current Mon Dec 16 22:57:12 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA04509 for current-outgoing; Mon, 16 Dec 1996 22:57:12 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id WAA04503; Mon, 16 Dec 1996 22:57:08 -0800 (PST) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <17035(8)>; Mon, 16 Dec 1996 22:56:35 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177711>; Mon, 16 Dec 1996 22:56:29 -0800 To: Bill Fenner cc: current@freebsd.org, jkh@freebsd.org Subject: Re: sysinstall REALLY needs a "reset FTP state" option, or something In-reply-to: Your message of "Mon, 16 Dec 96 20:06:15 PST." <96Dec16.200619pst.177711@crevenia.parc.xerox.com> Date: Mon, 16 Dec 1996 22:56:26 PST From: Bill Fenner Message-Id: <96Dec16.225629pst.177711@crevenia.parc.xerox.com> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <96Dec16.200619pst.177711@crevenia.parc.xerox.com> I wrote: >(Or, even better, a keepalive so that a connection that >hasn't transferred a byte in an hour times out and you get the ftp >reselection menu...) The problem is actually that the client sends "RETR foo" to the server and never receives a response. It'd be nice if sysinstall (ftplib?) had a timeout for responses from the server, so that things like this don't completely hose the install. (If it closed and reopened the connection, it could continue). Bill From owner-freebsd-current Mon Dec 16 22:58:25 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA04581 for current-outgoing; Mon, 16 Dec 1996 22:58:25 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id WAA04553; Mon, 16 Dec 1996 22:58:17 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id HAA03735; Tue, 17 Dec 1996 07:13:21 +0100 From: Luigi Rizzo Message-Id: <199612170613.HAA03735@labinfo.iet.unipi.it> Subject: Re: IP masquerading (for a LAN, _not_ PPP) To: julian@whistle.com (Julian Elischer) Date: Tue, 17 Dec 1996 07:13:21 +0100 (MET) Cc: owensc@enc.edu, wangel@wgrobez1.remote.louisville.edu, dnex@access.digex.net, current@freebsd.org, stable@freebsd.org In-Reply-To: <32B5D2C4.41C67EA6@whistle.com> from "Julian Elischer" at Dec 16, 96 02:52:33 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > FreeBSD 2.2 includes the feature "DIVERT SOCKETS" > these can be used in conjunction with the ipfw code to > create a translation feature. > > Use the 'divert' keyword with the Ipfw to divert a packet to > a 'divert socket' that is openned by the translation daemon. > the daemon monitors incoming packets and 'fiddles' the headers > accordingly. isn't it a bit expensive ? I mean, do all the packet go to userland where the daemon modifies them and then back to the kernel ? If this is the situation, it sounds like a significant overhead per packet, so you only want to do it at the slow side of a router. Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-current Mon Dec 16 23:16:15 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA05373 for current-outgoing; Mon, 16 Dec 1996 23:16:15 -0800 (PST) Received: from relay.internode.net (mail.internode.net [198.161.228.50]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id XAA05368 for ; Mon, 16 Dec 1996 23:16:12 -0800 (PST) Date: Mon, 16 Dec 1996 23:16:12 -0800 (PST) Received: from [198.161.228.111] by relay.internode.net (SMTPD32-3.02) id A63E96301B2; Tue, 17 Dec 1996 00:05:34 -0700 Message-Id: <1.5.4.16.19961217001848.34d7cec6@internode.net> X-Sender: drussell@internode.net X-Mailer: Windows Eudora Light Version 1.5.4 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Bill Fenner , current@freebsd.org From: Doug Russell Subject: Re: sysinstall REALLY needs a "reset FTP state" option, or something Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 08:06 PM 12/16/96 PST, Bill Fenner wrote: >I just spent about 15 minutes carefully choosing which distributions to >install, and then said "go". I came back an hour later, and it was 87% >done with bin. Another hour later, and it was still 87% done with bin. >The FTP connection had hung somehow. It's *really* frustrating to have >two choices: stay hung, or reboot. Is there any way that a control-C while >ftp'ing could allow another option of disconnecting and reconnecting to >the same server? (Or, even better, a keepalive so that a connection that >hasn't transferred a byte in an hour times out and you get the ftp >reselection menu...) That is a good suggestion, especially for people doing things over a (relatively) slow like, eg. a dialup PPP. While we are talking about the install program, I have found another little bug. (Oh, and I still haven't tried to upgrade to 2.2-ALPHA to test that possible partition table clobbering bug on other machines, by the way... Just like everyone else, as soon as I have a few free minutes I will... ) :-) I noticed this one because I store (part of) the FreeBSD tree on one of the machines in my house, which makes installing to a machine on the local network very fast and convenient. However, I currently don't have the entire packages directory for 2.2-ALPHA on that box, so, here's what happens. If I select an FTP install for my bin, XFree, etc. etc. (basic system) from my server machine, things install correctly. I get to the final config menu, and try to install a package which doesn't exist on my server, so I switch to, say ftp.freebsd.org on the media menu. When I try to install the package, it still tries to get it from my local server. The only way I could switch servers was to exit sysinstall and restart. It's really not THAT big of a deal anymore, since Sysinstall works pretty much correctly now (you can re-run it later and add a package, for example, and it actually works. Compared to the way things were back when I was running 1.x, this is pretty good! :-) Somethings just a little screwey in there. Sorry I can't give more detail, but it was a couple days ago, and I never really paid much attention to it, because it was fairly simple to work around. Somebody might want to look into it though. I also had a problem installing a package from the Networking menu on the final config/options menu. I inadvertantly tried to get Apache from my local server (which did not yet have the file at the time), before I switched ftp servers to ftp.freebsd.org. (the networking menu does seem to use the new FTP settings when you change them, it's just the "PACKAGES" one that doesn't work as far as I can tell...) I then installed a bunch of other packages off the network menu (from ftp.freebsd.org), but it would NOT let me re-try Apache, it would always pop up with a "can't fetch package" message, never even trying to fetch it from ftp.freebsd.org (the SD light on the outgoing modem never blinked). I don't know if it was still looking on server, or if it just assumed it couldn't find it. Maybe if I have a few minutes (ya, right) to myself I'll actually look into it myself. :-) Sorry for the long-winded message, I've been awake FAR too long. Hopefully you can understand what I'm trying to say. :-) Later...... From owner-freebsd-current Mon Dec 16 23:27:27 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA05756 for current-outgoing; Mon, 16 Dec 1996 23:27:27 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id XAA05751 for ; Mon, 16 Dec 1996 23:27:26 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0vZtvL-0003wLC; Mon, 16 Dec 96 23:26 PST Received: from critter.tfs.com (localhost.phk.dk [127.0.0.1]) by critter.tfs.com (8.8.2/8.8.2) with ESMTP id IAA14806; Tue, 17 Dec 1996 08:30:06 +0100 (MET) To: Bill Paul cc: current@freebsd.org Subject: Re: Plan for integrating Secure RPC -- comments wanted In-reply-to: Your message of "Tue, 17 Dec 1996 00:38:30 EST." <199612170538.AAA01464@skynet.ctr.columbia.edu> Date: Tue, 17 Dec 1996 08:30:05 +0100 Message-ID: <14804.850807805@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199612170538.AAA01464@skynet.ctr.columbia.edu>, Bill Paul writes: > int optlen; > int optval; > int sock; > int rval; > > optlen = sizeof(optval); > rval = getsockopt(sock, SOL_SOCKET, SO_PEERUID, NULL, &optlen); > /* ^^^^ */ > /* deliberate bug: should be &optval */ > >According to the man page, getsockopt() should return EFAULT if optval >or optlen aren't within the process's address space. Well, NULL is not >within the process's address space, so I should get an error here, but >I don't. If I do something equally silly like use -1 instead of NULL, >then I get an EFAULT as expected. With NULL, the getsockopt() call doesn't >do anything, but it returns an rval of 0 and doesn't set errno. > >Looking at the getsockopt() code, it seems like it short-circuits the >uap->val (i.e. optval) == NULL case on purpose and doesn't return an >error. > >Am I nuts, or is this a bug? I belive the point is to return the length, so you can malloc sufficient storage and call again. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-current Mon Dec 16 23:50:22 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA06938 for current-outgoing; Mon, 16 Dec 1996 23:50:22 -0800 (PST) Received: from dreamlabs.dreaming.org (root@dreamlabs.dreaming.org [207.107.8.200]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id XAA06932 for ; Mon, 16 Dec 1996 23:50:18 -0800 (PST) Received: from dreamlabs.dreaming.org (mitayai@dreamlabs.dreaming.org [207.107.8.200]) by dreamlabs.dreaming.org (8.8.4/8.6.12) with SMTP id CAA24380 for ; Tue, 17 Dec 1996 02:50:16 -0500 (EST) Date: Tue, 17 Dec 1996 02:50:13 -0500 (EST) From: Will Mitayai Keeso Rowe To: current@freebsd.org Subject: last Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by freefall.freebsd.org id XAA06934 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk First off, let me apologize for re-asking this question; i am *way* behind in my reading of this list, and from a web search on the list i know this question has been asked, and perhaps answered. A recent build (about a week ago) via make world is giving me weird data... invalid hostname úI¶2ttyp5 Wed Dec 31 19:00 still logged in 207.107.8.200 æI¶2ftp22773 Wed Dec 31 19:00 - 17:23 (79+22:23) 206.165.5.107 ÑH¶2ftp22773ftp Wed Dec 31 19:00 still logged in mitayai ftp Mon Sep 29 19:18 still logged in lucian ttyp5 130.63.122.106 Tue Dec 17 01:35 still logged in mitayai ttyp4 localhost Tue Dec 17 01:26 - 01:26 (00:00) wtmp begins Tue Dec 17 01:26 Already tried the newest utmp.h and recompiling a fresh last from the latest src tree. I can't seem to find a specificv mention of a fix in the lists... could anyone take a sec to point me to the right mssage, or re-send any message? Thx, Mit Will Mitayai Keeso Rowe The DreamLabs Network http://www.dreaming.org (705)741-1089 From owner-freebsd-current Tue Dec 17 00:47:13 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id AAA09005 for current-outgoing; Tue, 17 Dec 1996 00:47:13 -0800 (PST) Received: from ns2.franke.ch ([195.212.125.2]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id AAA09000 for ; Tue, 17 Dec 1996 00:47:09 -0800 (PST) Received: from ns2.franke.ch (localhost [127.0.0.1]) by ns2.franke.ch (8.7.5/8.7.3) with SMTP id JAA10048 for ; Tue, 17 Dec 1996 09:44:29 +0100 (MET) Message-ID: <32B65D6D.41C67EA6@ns2.franke.ch> Date: Tue, 17 Dec 1996 09:44:29 +0100 From: Josef Egloff Organization: Franke AG, Schweiz X-Mailer: Mozilla 2.02 (X11; I; FreeBSD 2.1.5-RELEASE i386) MIME-Version: 1.0 To: freebsd-current@FreeBSD.ORG Subject: subscribe X-URL: http://www.freebsd.org/handbook/handbook224.html#468 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk subscribe josef@webstat1.franke.ch From owner-freebsd-current Tue Dec 17 00:49:30 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id AAA09159 for current-outgoing; Tue, 17 Dec 1996 00:49:30 -0800 (PST) Received: from ravenock.cybercity.dk (ravenock.cybercity.dk [194.16.57.32]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id AAA09133; Tue, 17 Dec 1996 00:49:23 -0800 (PST) Received: (from sos@localhost) by ravenock.cybercity.dk (8.8.3/8.7.3) id JAA18610; Tue, 17 Dec 1996 09:44:55 +0100 (MET) Message-Id: <199612170844.JAA18610@ravenock.cybercity.dk> Subject: Re: IP masquerading (for a LAN, _not_ PPP) In-Reply-To: <199612170613.HAA03735@labinfo.iet.unipi.it> from Luigi Rizzo at "Dec 17, 96 07:13:21 am" To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Tue, 17 Dec 1996 09:44:55 +0100 (MET) Cc: julian@whistle.com, owensc@enc.edu, wangel@wgrobez1.remote.louisville.edu, dnex@access.digex.net, current@freebsd.org, stable@freebsd.org From: sos@freebsd.org Reply-to: sos@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply to Luigi Rizzo who wrote: > > FreeBSD 2.2 includes the feature "DIVERT SOCKETS" > > these can be used in conjunction with the ipfw code to > > create a translation feature. > > > > Use the 'divert' keyword with the Ipfw to divert a packet to > > a 'divert socket' that is openned by the translation daemon. > > the daemon monitors incoming packets and 'fiddles' the headers > > accordingly. > > isn't it a bit expensive ? I mean, do all the packet go to userland > where the daemon modifies them and then back to the kernel ? If this is > the situation, it sounds like a significant overhead per packet, so you > only want to do it at the slow side of a router. Exactly, thats why I did it in the kernel :) I've mesured the overhead long ago when I started this, and on my rusty old 25Mhz 386SX this works just dandy with 10MBps and multiple connections with kernel resident code. I tried a couple of simple attempts on a userland implementation, but it bailed out on ~100Kbps... (And for those wanting it, its not releasable, sorry) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-current Tue Dec 17 01:22:22 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA10561 for current-outgoing; Tue, 17 Dec 1996 01:22:22 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id BAA10550 for ; Tue, 17 Dec 1996 01:22:09 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA07974; Tue, 17 Dec 1996 10:21:18 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA02630; Tue, 17 Dec 1996 10:21:13 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id JAA14318; Tue, 17 Dec 1996 09:54:58 +0100 (MET) From: J Wunsch Message-Id: <199612170854.JAA14318@uriah.heep.sax.de> Subject: Re: /usr/sbin/lsdev in current? To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Tue, 17 Dec 1996 09:54:58 +0100 (MET) Cc: rlb@mindspring.com (Ron Bolin) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <32B5F4D3.167EB0E7@mindspring.com> from Ron Bolin at "Dec 16, 96 08:18:16 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Ron Bolin wrote: > Is lsdev supported in current? No, since the underlying device registry mechanism has never fully seen the light of the world. So after about one year or so of watching its birth attempt, it has finally been called an abortion, and removed. -- 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 Tue Dec 17 01:53:11 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA11997 for current-outgoing; Tue, 17 Dec 1996 01:53:11 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id BAA11966 for ; Tue, 17 Dec 1996 01:52:48 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA09488; Tue, 17 Dec 1996 10:51:46 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA02948; Tue, 17 Dec 1996 10:51:46 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id KAA15004; Tue, 17 Dec 1996 10:39:34 +0100 (MET) From: J Wunsch Message-Id: <199612170939.KAA15004@uriah.heep.sax.de> Subject: Re: libc_r broken in 2.2 To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Tue, 17 Dec 1996 10:39:34 +0100 (MET) Cc: nate@mt.sri.com Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199612162346.QAA05267@rocky.mt.sri.com> from Nate Williams at "Dec 16, 96 04:46:21 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Nate Williams wrote: > This also requires backing out the 1.6 revision of include/time.h as > well. This change looked ``too much like a bug fix'' to me, that's why i've pulled it, along with the function change itself. Ok, you prove me wrong, i'll back it out. Thanks for pointing it out. Curious, why used libc_r to have differing return types for them? -- 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 Tue Dec 17 01:54:08 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA12066 for current-outgoing; Tue, 17 Dec 1996 01:54:08 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id BAA12061 for ; Tue, 17 Dec 1996 01:54:05 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA09472; Tue, 17 Dec 1996 10:51:41 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA02944; Tue, 17 Dec 1996 10:51:41 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id KAA14925; Tue, 17 Dec 1996 10:33:24 +0100 (MET) From: J Wunsch Message-Id: <199612170933.KAA14925@uriah.heep.sax.de> Subject: Re: last To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Tue, 17 Dec 1996 10:33:24 +0100 (MET) Cc: mitayai@dreaming.org (Will Mitayai Keeso Rowe) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from Will Mitayai Keeso Rowe at "Dec 17, 96 02:50:13 am" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Will Mitayai Keeso Rowe wrote: > invalid hostname úI¶2ttyp5 Wed Dec 31 19:00 still logged in > 207.107.8.200 æI¶2ftp22773 Wed Dec 31 19:00 - 17:23 (79+22:23) ^^^ Are you running wuftpd? It needs recompilation as well. You might also give src/tools/3.0-upgrade/cvt-wtmp.c a try. It's supposed to convert your old wtmp file. Call with -n if you just wanna see whether it recognizes all records in the file. -- 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 Tue Dec 17 01:59:24 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA12380 for current-outgoing; Tue, 17 Dec 1996 01:59:24 -0800 (PST) Received: from dreamlabs.dreaming.org (root@dreamlabs.dreaming.org [207.107.8.200]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id BAA12375 for ; Tue, 17 Dec 1996 01:59:22 -0800 (PST) Received: from dreamlabs.dreaming.org (mitayai@dreamlabs.dreaming.org [207.107.8.200]) by dreamlabs.dreaming.org (8.8.4/8.6.12) with SMTP id EAA29078; Tue, 17 Dec 1996 04:57:20 -0500 (EST) Date: Tue, 17 Dec 1996 04:57:17 -0500 (EST) From: Will Mitayai Keeso Rowe To: Joerg Wunsch cc: FreeBSD-current users Subject: Re: last In-Reply-To: <199612170933.KAA14925@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by freefall.freebsd.org id BAA12376 Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 17 Dec 1996, J Wunsch wrote: > As Will Mitayai Keeso Rowe wrote: > > > invalid hostname úI¶2ttyp5 Wed Dec 31 19:00 still logged in > > 207.107.8.200 æI¶2ftp22773 Wed Dec 31 19:00 - 17:23 (79+22:23) > ^^^ > > Are you running wuftpd? It needs recompilation as well. Yep, and i did that once i realized most of the bad entries were from ftp, but that didn't help (gah.. i wish the virtual ftp patches where part of the wu-ftpd port and life would be much easier... :) > > You might also give src/tools/3.0-upgrade/cvt-wtmp.c a try. It's > supposed to convert your old wtmp file. Call with -n if you just > wanna see whether it recognizes all records in the file. *grin* i just noticed it 10 minutes ago in my cvsup output, and wondered what that was... :) Ran it, and it work great now. Thx! -Mit > > -- > 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. ;-) > Will Mitayai Keeso Rowe The DreamLabs Network http://www.dreaming.org (705)741-1089 From owner-freebsd-current Tue Dec 17 03:36:48 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id DAA16932 for current-outgoing; Tue, 17 Dec 1996 03:36:48 -0800 (PST) Received: from jalopeno.nixu.fi (jalopeno.nixu.fi [194.197.118.20]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id DAA16927 for ; Tue, 17 Dec 1996 03:36:44 -0800 (PST) Received: from flauta.nixu.fi (flauta.nixu.fi [194.197.118.35]) by jalopeno.nixu.fi (8.8.3/8.8.3) with ESMTP id NAA18609; Tue, 17 Dec 1996 13:35:22 +0200 (EET) Date: Tue, 17 Dec 1996 13:35:15 +0200 (EET) From: Marko Lamminen Reply-To: Marko Lamminen Subject: Re: IP masquerading (for a LAN, _not_ PPP) To: "Jordan K. Hubbard" cc: current@FreeBSD.ORG In-Reply-To: <14831.850785273@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > We really should bring this into -current at some point, now that > we've branched. C'mon, there must be someone out there in -current > land who's a) into networking, b) on the committers list and c) wants > to see this go in. ;) > I would also like to see this included, shouldn't be too hard since it has patches required to run in as lkm already and with minor (?) modifications might be integrated to -current quite easily. But using divert sockets? I don't know how much work this would be but I think I'll take a look at it anyway, once I find some time. Has anyone tested ip_filter, I'm mostly interested how does it perform against ipfw? - Marko From owner-freebsd-current Tue Dec 17 07:06:31 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA28029 for current-outgoing; Tue, 17 Dec 1996 07:06:31 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id HAA28015; Tue, 17 Dec 1996 07:06:24 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id HAA16794; Tue, 17 Dec 1996 07:06:24 -0800 (PST) To: Bill Fenner cc: current@freebsd.org, jkh@freebsd.org Subject: Re: sysinstall REALLY needs a "reset FTP state" option, or something In-reply-to: Your message of "Mon, 16 Dec 1996 20:06:15 PST." <96Dec16.200619pst.177711@crevenia.parc.xerox.com> Date: Tue, 17 Dec 1996 07:06:24 -0800 Message-ID: <16791.850835184@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I just spent about 15 minutes carefully choosing which distributions to > install, and then said "go". I came back an hour later, and it was 87% > done with bin. Another hour later, and it was still 87% done with bin. > The FTP connection had hung somehow. It's *really* frustrating to have > two choices: stay hung, or reboot. Is there any way that a control-C while > ftp'ing could allow another option of disconnecting and reconnecting to I just need to install different SIGINT handlers which know how to DTRT for various subsections of sysinstall - it's been on my TODO list for ages, so thanks for the reminder. I'll look at the FTP transfer issue as the first application of this and maybe get something hacked up today. Jordan From owner-freebsd-current Tue Dec 17 07:09:05 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA28178 for current-outgoing; Tue, 17 Dec 1996 07:09:05 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id HAA28171 for ; Tue, 17 Dec 1996 07:09:03 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id HAA16817; Tue, 17 Dec 1996 07:08:56 -0800 (PST) To: Julian Elischer cc: barry@Lustig.COM, Charles Owens , current@FreeBSD.ORG Subject: Re: IP masquerading (for a LAN, _not_ PPP) In-reply-to: Your message of "Mon, 16 Dec 1996 20:10:41 PST." <32B61D41.167EB0E7@whistle.com> Date: Tue, 17 Dec 1996 07:08:56 -0800 Message-ID: <16813.850835336@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Jordan K. Hubbard wrote: > > > > > Take a look at IP Filter http://coombs.anu.edu.au/~avalon/. > > > > We really should bring this into -current at some point, now that > > we've branched. C'mon, there must be someone out there in -current > > land who's a) into networking, b) on the committers list and c) wants > > to see this go in. ;) > > welll there are some good things that ipfw does too.... Do you see me suggesting ipfilter as a replacement? :-) I just said we should bring it into -current; I would expect both to be provided as an option until such time as one totally subsumed the other, feature for feature, then we'd have just one. Jordan From owner-freebsd-current Tue Dec 17 07:28:33 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA29078 for current-outgoing; Tue, 17 Dec 1996 07:28:33 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id HAA29071 for ; Tue, 17 Dec 1996 07:28:30 -0800 (PST) Received: by halloran-eldar.lcs.mit.edu; (5.65v3.2/1.1.8.2/19Aug95-0530PM) id AA02135; Tue, 17 Dec 1996 10:28:25 -0500 Date: Tue, 17 Dec 1996 10:28:25 -0500 From: Garrett Wollman Message-Id: <9612171528.AA02135@halloran-eldar.lcs.mit.edu> To: "Jordan K. Hubbard" Cc: current@freebsd.org Subject: Re: Plan for integrating Secure RPC -- comments wanted In-Reply-To: <6277.850775845@time.cdrom.com> References: <12149.850751059@critter.tfs.com> <6277.850775845@time.cdrom.com> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk < said: >> Not really. >> >> The trouble is that we cannot load a LKM until we have a RW fs :-( > What if a small MFS were mounted on /tmp, or wherever, so that ld > could do the relink? Better to just fix the LKM mechanism to not need it... There are ways to do this, but they are all sort of unappealing. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, ANA, or NSA| - Susan Aglukark and Chad Irschick From owner-freebsd-current Tue Dec 17 07:32:49 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA29559 for current-outgoing; Tue, 17 Dec 1996 07:32:49 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id HAA29554 for ; Tue, 17 Dec 1996 07:32:47 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id IAA08919; Tue, 17 Dec 1996 08:31:15 -0700 (MST) Date: Tue, 17 Dec 1996 08:31:15 -0700 (MST) Message-Id: <199612171531.IAA08919@rocky.mt.sri.com> From: Nate Williams To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Cc: freebsd-current@freebsd.org (FreeBSD-current users), nate@mt.sri.com Subject: Re: libc_r broken in 2.2 In-Reply-To: <199612170939.KAA15004@uriah.heep.sax.de> References: <199612162346.QAA05267@rocky.mt.sri.com> <199612170939.KAA15004@uriah.heep.sax.de> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > This also requires backing out the 1.6 revision of include/time.h as > > well. > > This change looked ``too much like a bug fix'' to me, that's why i've > pulled it, along with the function change itself. Oh, I agree it's a bugfix, but it's a non-trivial bug fix. Jeff would know all of the affected files. > Curious, why used libc_r to have differing return types for them? POSIX apparently changed the return types. Nate From owner-freebsd-current Tue Dec 17 07:35:46 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA29834 for current-outgoing; Tue, 17 Dec 1996 07:35:46 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id HAA29829 for ; Tue, 17 Dec 1996 07:35:44 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id HAA16975; Tue, 17 Dec 1996 07:35:45 -0800 (PST) To: Bill Fenner cc: current@freebsd.org Subject: Re: sysinstall REALLY needs a "reset FTP state" option, or something In-reply-to: Your message of "Mon, 16 Dec 1996 22:56:26 PST." <96Dec16.225629pst.177711@crevenia.parc.xerox.com> Date: Tue, 17 Dec 1996 07:35:45 -0800 Message-ID: <16971.850836945@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > The problem is actually that the client sends "RETR foo" to the > server and never receives a response. It'd be nice if sysinstall > (ftplib?) had a timeout for responses from the server, so that > things like this don't completely hose the install. (If it > closed and reopened the connection, it could continue). Yes, timeouts are supported in libftpio, but we never set one for this specific type of failure. This makes me even gladder that I finally converted sysinstall to use libftpio, since fixing this here will also now fix fetch(1). :-) Jordan From owner-freebsd-current Tue Dec 17 08:24:07 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA03672 for current-outgoing; Tue, 17 Dec 1996 08:24:07 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id IAA03661 for ; Tue, 17 Dec 1996 08:24:04 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id IAA17620; Tue, 17 Dec 1996 08:24:00 -0800 (PST) To: Garrett Wollman cc: current@freebsd.org Subject: Re: Plan for integrating Secure RPC -- comments wanted In-reply-to: Your message of "Tue, 17 Dec 1996 10:28:25 EST." <9612171528.AA02135@halloran-eldar.lcs.mit.edu> Date: Tue, 17 Dec 1996 08:24:00 -0800 Message-ID: <17616.850839840@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Better to just fix the LKM mechanism to not need it... There are ways > to do this, but they are all sort of unappealing. Yeah, I've heard the "move ld into the kernel" arguments too. That's why I was suggesting this as an interim work-around solution. Jordan From owner-freebsd-current Tue Dec 17 08:32:59 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA04370 for current-outgoing; Tue, 17 Dec 1996 08:32:59 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id IAA04365 for ; Tue, 17 Dec 1996 08:32:57 -0800 (PST) Received: by halloran-eldar.lcs.mit.edu; (5.65v3.2/1.1.8.2/19Aug95-0530PM) id AA02884; Tue, 17 Dec 1996 11:32:49 -0500 Date: Tue, 17 Dec 1996 11:32:49 -0500 From: Garrett Wollman Message-Id: <9612171632.AA02884@halloran-eldar.lcs.mit.edu> To: Nate Williams Cc: current@freebsd.org Subject: More breakage in -current and 2.2 In-Reply-To: <199612162337.QAA05223@rocky.mt.sri.com> References: <199612162337.QAA05223@rocky.mt.sri.com> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk < said: > And, under current I can't get routed to build. There is something wrong with your . -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, ANA, or NSA| - Susan Aglukark and Chad Irschick From owner-freebsd-current Tue Dec 17 08:58:10 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA05596 for current-outgoing; Tue, 17 Dec 1996 08:58:10 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id IAA05590 for ; Tue, 17 Dec 1996 08:58:08 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id JAA09396; Tue, 17 Dec 1996 09:57:49 -0700 (MST) Date: Tue, 17 Dec 1996 09:57:49 -0700 (MST) Message-Id: <199612171657.JAA09396@rocky.mt.sri.com> From: Nate Williams To: Garrett Wollman Cc: Nate Williams , current@freebsd.org Subject: Re: More breakage in -current and 2.2 In-Reply-To: <9612171632.AA02884@halloran-eldar.lcs.mit.edu> References: <199612162337.QAA05223@rocky.mt.sri.com> <9612171632.AA02884@halloran-eldar.lcs.mit.edu> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > And, under current I can't get routed to build. > > There is something wrong with your . Weirder and weirder. I ran 'make install' in /usr/src/include 2-3 times, and 'make includes' in /usr/src 2-3 times and it still didn't update the include file. I tried again today and watched it update routed.h, and it worked this time. *sigh* Nate From owner-freebsd-current Tue Dec 17 09:22:11 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA07710 for current-outgoing; Tue, 17 Dec 1996 09:22:11 -0800 (PST) Received: from acc0.elvisti.kiev.ua (acc0.elvisti.kiev.ua [193.125.28.132]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id JAA07662 for ; Tue, 17 Dec 1996 09:21:52 -0800 (PST) Received: from office.elvisti.kiev.ua (office.elvisti.kiev.ua [193.125.28.129]) by acc0.elvisti.kiev.ua (8.8.4-MVC/8.7.3) with ESMTP id TAA25773 for ; Tue, 17 Dec 1996 19:24:10 +0200 (EET) Received: from gw.elvisti.kiev.ua (gw.elvisti.kiev.ua [193.125.28.140]) by office.elvisti.kiev.ua (8.6.12/8.ElVisti) with ESMTP id TAA24250 for ; Tue, 17 Dec 1996 19:24:09 +0200 Received: from lab.elvisti.kiev.ua (lab.elvisti.kiev.ua [193.125.28.144]) by gw.elvisti.kiev.ua (8.8.4-MVC/8.6.12) with SMTP id TAA00750 for ; Tue, 17 Dec 1996 19:16:30 +0200 (EET) Message-ID: <32B6D685.500F9F30@elvisti.kiev.ua> Date: Tue, 17 Dec 1996 17:21:09 +0000 From: Alexander Kartsov Organization: IC Elvisti X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2-ALPHA i386) MIME-Version: 1.0 To: current@freebsd.org Subject: Re: IP masquerading (for a LAN, _not_ PPP) References: <14831.850785273@time.cdrom.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard wrote: > > > Take a look at IP Filter http://coombs.anu.edu.au/~avalon/. > > We really should bring this into -current at some point, now that > we've branched. C'mon, there must be someone out there in -current > land who's a) into networking, b) on the committers list and c) wants > to see this go in. ;) > > Jordan We work with this software for months. IP filtering works perfect. IP masquerading does not. It seems to work only for 1:1 mapping, otherwise system reboots often. We changed many versions of this IPNAT and many versions FreeBSD (and lot of hardware) and nothing has changed in this time. From owner-freebsd-current Tue Dec 17 12:24:49 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA16525 for current-outgoing; Tue, 17 Dec 1996 12:24:49 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA16436 for ; Tue, 17 Dec 1996 12:23:45 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA08756; Tue, 17 Dec 1996 13:20:40 -0700 From: Terry Lambert Message-Id: <199612172020.NAA08756@phaeton.artisoft.com> Subject: Re: Warning -- Lite/2 merge coming up To: jonny@mailhost.coppe.ufrj.br (Joao Carlos Mendes Luis) Date: Tue, 17 Dec 1996 13:20:40 -0700 (MST) Cc: mark@grondar.za, toor@dyson.iquest.net, current@freebsd.org In-Reply-To: <199612170140.XAA02665@gaia.coppe.ufrj.br> from "Joao Carlos Mendes Luis" at Dec 16, 96 11:40:30 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 X-Loop: FreeBSD.org Precedence: bulk > > > What about the other broken FS's, like union and null? > > > > > We have been holding off until the Lite/2 merge. Lite/2 might fix > > some of the problems. > > Sometime ago I was reading the unionfs algorithm on the 4.4 BSD book. > One problem that came to my mind was about the deleted files. > > It says that if one file on the lower layer is deleted, as it shall not > be really deleted, an entry on the upper layer directory is created with > the I-node 1. I believe you are confusing "whiteout" and "delete". The way it *should* behave is as a preemptive negative cache hit, assuming you are using the union FS as a translucent FS... ie: changes to the top level media look like changes to the agregate media even if the agregate media is read-only -- for instance, a CVS update of a CDROM source tree. By preemptive, it means that it returns "not found", and the search is not continued for the unioned media. But if you create the file, then it is deleted, but is pretended to be not found, so that it gets a valid inode allocated for it. For all intents and purposes, then, it's a special entry in a directory seperate from an allocated inode for a directory, which causes the search to exit prematurely until it is removed or replaced. As an overlay FS simply mounted instead of union mounted, the file will not show up; this is because inode 1 is historically reserved as a file entry marker for the bad block list on the drive. Note that this "whiteout" function requires that the FS support two ideas: (1) The directory entry and the inode are seperate things; this means it won't work for MSDOSFS, since in a FAT FS, the drictory entry *is* the on disk inode. (2) The FS type understands the historical reservation of inode 1 (ie: it won't work on ISO9660FS, but who cares, since it's read-only). > And, the final problem: When making a copy from lower to upper layer > (to permit a write access to some file) should this be done by the > kernel ? Is it a good approach ? This could mean a very large > operation, and I don't like to keep the kernel busy for such a long > time. Maybe a daemon implementation (just like portal) should do > this job better. You should use "copy to self". The first lookup for the target for read will get a lower FS entry; the second open for the write will get an upper FS entry by virtue of the open-for-write attribute. This is the one case where "cp foo foo" is meaningful and should not be trapped by the user space tools, but by the underlying FS instead. 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 Dec 17 12:31:15 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA16867 for current-outgoing; Tue, 17 Dec 1996 12:31:15 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA16846 for ; Tue, 17 Dec 1996 12:30:36 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA08796; Tue, 17 Dec 1996 13:28:23 -0700 From: Terry Lambert Message-Id: <199612172028.NAA08796@phaeton.artisoft.com> Subject: Re: Plan for integrating Secure RPC -- comments wanted To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Tue, 17 Dec 1996 13:28:23 -0700 (MST) Cc: wollman@lcs.mit.edu, current@freebsd.org In-Reply-To: <17616.850839840@time.cdrom.com> from "Jordan K. Hubbard" at Dec 17, 96 08:24:00 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 X-Loop: FreeBSD.org Precedence: bulk > > Better to just fix the LKM mechanism to not need it... There are ways > > to do this, but they are all sort of unappealing. > > Yeah, I've heard the "move ld into the kernel" arguments too. > > That's why I was suggesting this as an interim work-around solution. mmap() the loader into the address space of the moload process, and call it from kernel mode. The only real difference here is that PIC object file a.out headers aren't read by the kernel, still, so you can pretend the loader is still in user space if you are into ethnic purity... 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 Dec 17 12:37:16 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA17256 for current-outgoing; Tue, 17 Dec 1996 12:37:16 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id MAA17243 for ; Tue, 17 Dec 1996 12:36:38 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id MAA18609; Tue, 17 Dec 1996 12:31:51 -0800 (PST) To: Terry Lambert cc: wollman@lcs.mit.edu, current@freebsd.org Subject: Re: Plan for integrating Secure RPC -- comments wanted In-reply-to: Your message of "Tue, 17 Dec 1996 13:28:23 MST." <199612172028.NAA08796@phaeton.artisoft.com> Date: Tue, 17 Dec 1996 12:31:51 -0800 Message-ID: <18605.850854711@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > mmap() the loader into the address space of the moload process, and > call it from kernel mode. For some reason, this really strikes me as one of those "easier said than done" sorts of solutions. Jordan From owner-freebsd-current Tue Dec 17 13:39:37 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA21036 for current-outgoing; Tue, 17 Dec 1996 13:39:37 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id NAA21011 for ; Tue, 17 Dec 1996 13:39:03 -0800 (PST) Received: (from jdp@localhost) by austin.polstra.com (8.8.3/8.8.3) id NAA19560; Tue, 17 Dec 1996 13:38:27 -0800 (PST) To: freebsd-current@freebsd.org Path: not-for-mail From: jdp@polstra.com (John Polstra) Newsgroups: polstra.freebsd.current Subject: Re: zlib doc? Date: 17 Dec 1996 13:38:27 -0800 Organization: Polstra & Co., Seattle, WA Lines: 16 Distribution: local Message-ID: <5973sj$j35@austin.polstra.com> References: <199612151312.OAA19098@uriah.heep.sax.de> Fcc: outbox Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199612151312.OAA19098@uriah.heep.sax.de>, J Wunsch wrote: > I'm missing the man page for libz. Where is it? /usr/include/zlib.h :-) Seriously, that's about all there is. It has some big tutorial-style block comments, at least. > cheers, J"org ``An undocumented feature is a bug.'' Wunsch John ``An unfeatured document is a bug.'' Polstra -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-current Tue Dec 17 17:34:23 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA06939 for current-outgoing; Tue, 17 Dec 1996 17:34:23 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA06901 for ; Tue, 17 Dec 1996 17:34:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id RAA09636; Tue, 17 Dec 1996 17:32:45 -0800 (PST) Message-Id: <199612180132.RAA09636@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: jkh@time.cdrom.com (Jordan K. Hubbard), wollman@lcs.mit.edu, current@freebsd.org Subject: Re: Plan for integrating Secure RPC -- comments wanted In-reply-to: Your message of "Tue, 17 Dec 1996 13:28:23 MST." <199612172028.NAA08796@phaeton.artisoft.com> From: David Greenman Reply-To: dg@root.com Date: Tue, 17 Dec 1996 17:32:45 -0800 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> > Better to just fix the LKM mechanism to not need it... There are ways >> > to do this, but they are all sort of unappealing. >> >> Yeah, I've heard the "move ld into the kernel" arguments too. >> >> That's why I was suggesting this as an interim work-around solution. > >mmap() the loader into the address space of the moload process, and >call it from kernel mode. That won't work for a variety of reasons. For one thing, the kernel is not going to like demand paging (COW, zero-fill, regular page faults) in the context of the kernel. For another, the kernel stack is of finite size and can't deal with typical programs. Using the user's stack is "a major problem" in it's own right. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-current Tue Dec 17 18:25:15 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id SAA10142 for current-outgoing; Tue, 17 Dec 1996 18:25:15 -0800 (PST) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id SAA10134 for ; Tue, 17 Dec 1996 18:25:12 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr3-15.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA03697 (5.67b/IDA-1.5 for ); Wed, 18 Dec 1996 03:24:38 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.4/8.6.9) id CAA15722; Wed, 18 Dec 1996 02:48:03 +0100 (CET) Message-Id: Date: Wed, 18 Dec 1996 02:46:42 +0100 From: se@FreeBSD.ORG (Stefan Esser) To: se@freefall.freebsd.org (Stefan Esser) Cc: CVS-committers@freefall.freebsd.org, cvs-all@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf files References: <199612180125.RAA06399@freefall.freebsd.org> X-Mailer: Mutt 0.53 Mime-Version: 1.0 In-Reply-To: <199612180125.RAA06399@freefall.freebsd.org>; from Stefan Esser on Dec 17, 1996 17:25:01 -0800 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Dec 17, se@freefall.freebsd.org (Stefan Esser) wrote: > se 96/12/17 17:25:01 > > Modified: sys/conf files > Log: > Add driver for the Tekram DC390 and DC390F, believed to also work > with generic AMD 53c974 SCSI controllers, under the name of "amd". Ahemm, this driver supports the DC390 and DC390T, not F. (Is it possible to repair this typo in the repository ? The 390F is NCR 53c875 based, and I'd like to avoid any possible confusion.) Also: Could people with AMD 53c974 SCSI (the one PCI SCSI chip often found on motherboards, but not supported by any driver in FreeBSD before, please check out this driver ? I have added code to simulate the Tekram config EEPROM, but can't test whether this really makes the driver support all 53c974 controllers ... Regards, STefan From owner-freebsd-current Tue Dec 17 19:16:03 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id TAA12701 for current-outgoing; Tue, 17 Dec 1996 19:16:03 -0800 (PST) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id TAA12680 for ; Tue, 17 Dec 1996 19:16:01 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id UAA06134 for current@freebsd.org; Tue, 17 Dec 1996 20:15:53 -0700 (MST) Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id UAA19541 for ; Tue, 17 Dec 1996 20:15:45 -0700 (MST) Date: Tue, 17 Dec 1996 20:15:44 -0700 (MST) From: Marc Slemko X-Sender: marcs@alive.ampr.ab.ca To: current@freebsd.org Subject: can someone run a find on a -current system... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Can someone please run a: find / \( -perm -2000 -or -perm -4000 \) -ls on a system running -current for me and mail me the output privately. I want to make sure I don't miss any set[uid|gid] programs that aren't in -stable; is easier than picking through the source tree. Thanks. From owner-freebsd-current Wed Dec 18 05:00:11 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA05230 for current-outgoing; Wed, 18 Dec 1996 05:00:11 -0800 (PST) Received: from itsdsv1.enc.edu (itsdsv1.enc.edu [207.95.42.241]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id FAA05175; Wed, 18 Dec 1996 05:00:00 -0800 (PST) Received: from dingo.its.enc.edu (dingo.its.enc.edu [207.95.222.250]) by itsdsv1.enc.edu (8.7.5/8.7.3) with SMTP id HAA27324; Wed, 18 Dec 1996 07:57:51 -0500 (EST) Date: Wed, 18 Dec 1996 08:00:23 -0500 (EST) From: Charles Owens X-Sender: owensc@dingo.its.enc.edu To: sos@freebsd.org cc: Luigi Rizzo , julian@whistle.com, wangel@wgrobez1.remote.louisville.edu, dnex@access.digex.net, current@freebsd.org, stable@freebsd.org Subject: Re: IP masquerading (for a LAN, _not_ PPP) In-Reply-To: <199612170844.JAA18610@ravenock.cybercity.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by freefall.freebsd.org id FAA05209 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 17 Dec 1996 sos@freebsd.org wrote: > In reply to Luigi Rizzo who wrote: > > > FreeBSD 2.2 includes the feature "DIVERT SOCKETS" > > > these can be used in conjunction with the ipfw code to > > > create a translation feature. > > > > > > Use the 'divert' keyword with the Ipfw to divert a packet to > > > a 'divert socket' that is openned by the translation daemon. > > > the daemon monitors incoming packets and 'fiddles' the headers > > > accordingly. > > > > isn't it a bit expensive ? I mean, do all the packet go to userland > > where the daemon modifies them and then back to the kernel ? If this is > > the situation, it sounds like a significant overhead per packet, so you > > only want to do it at the slow side of a router. > > Exactly, thats why I did it in the kernel :) > I've mesured the overhead long ago when I started this, and on my > rusty old 25Mhz 386SX this works just dandy with 10MBps and > multiple connections with kernel resident code. I tried a > couple of simple attempts on a userland implementation, but > it bailed out on ~100Kbps... > (And for those wanting it, its not releasable, sorry) > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team > Even more code to hack -- will it ever end Ok... help me out here: the 'ipfilter' package is _not_ a userland implementation, right? (just trying to put all of the pieces to gether here...) Why do some folks consider the DIVERT sockets with userland daemon approach better than other existing options, such as ipfilter? Or, more directly, why might I not want to user ipfilter to build a firewall for a large (hundreds of users) LAN? (pssst... not trying to start a war here) I'm trying to discern which of the available options makes the most sense for me... at this instant ipfilter seems the best bet --- feature rich and good performance (I'm assuming... by virtue of it's kernel implementation... any testimonials?). I'd use the ipfw package but I really need NAT. If this should be moved out of -stable and -current then... sorry... :-) Thanks, --- ------------------------------------------------------------------------- Charles Owens Email: owensc@enc.edu "I read somewhere to learn is to Information Technology Services remember... and I've learned that Eastern Nazarene College we've all forgot..." - King's X ------------------------------------------------------------------------- From owner-freebsd-current Wed Dec 18 08:21:06 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA13464 for current-outgoing; Wed, 18 Dec 1996 08:21:06 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id IAA13459 for ; Wed, 18 Dec 1996 08:21:04 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA10100; Wed, 18 Dec 1996 09:17:57 -0700 From: Terry Lambert Message-Id: <199612181617.JAA10100@phaeton.artisoft.com> Subject: Re: Plan for integrating Secure RPC -- comments wanted To: dg@root.com Date: Wed, 18 Dec 1996 09:17:57 -0700 (MST) Cc: terry@lambert.org, jkh@time.cdrom.com, wollman@lcs.mit.edu, current@freebsd.org In-Reply-To: <199612180132.RAA09636@root.com> from "David Greenman" at Dec 17, 96 05:32:45 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 X-Loop: FreeBSD.org Precedence: bulk > >> > Better to just fix the LKM mechanism to not need it... There are ways > >> > to do this, but they are all sort of unappealing. > >> > >> Yeah, I've heard the "move ld into the kernel" arguments too. > >> > >> That's why I was suggesting this as an interim work-around solution. > > > >mmap() the loader into the address space of the moload process, and > >call it from kernel mode. > > That won't work for a variety of reasons. For one thing, the kernel is > not going to like demand paging (COW, zero-fill, regular page faults) in the > context of the kernel. For another, the kernel stack is of finite size and > can't deal with typical programs. Using the user's stack is "a major problem" > in it's own right. Heh. On the other hand, it could be forced to work using the user's stack. We were discussing interim workarounds anyway, not anything long term. If you issues "touches" on the code from the user stack after an initial vn_read, you could do it... 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 Wed Dec 18 11:33:31 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA23188 for current-outgoing; Wed, 18 Dec 1996 11:33:31 -0800 (PST) Received: from obelix.aa.ans.net (obelix.aa.ans.net [198.83.22.101]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id LAA23183 for ; Wed, 18 Dec 1996 11:33:28 -0800 (PST) Received: (from lpj@localhost) by obelix.aa.ans.net (8.7.5/8.7.3) id OAA13797 for current@freebsd.org; Wed, 18 Dec 1996 14:33:22 -0500 (EST) From: Laurent Joncheray Message-Id: <199612181933.OAA13797@obelix.aa.ans.net> Subject: microtime() resolution? To: current@freebsd.org Date: Wed, 18 Dec 1996 14:33:21 -0500 (EST) X-Mailer: ELM [version 2.4 PL25 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, do anyone know what is the resolution of the kernel's microtime() function, called from the IP driver? I mean, it is supposed to return the time in us, but is the timer updated every us, or more often, or less? Any help appreciated, -- lpj -- Laurent Joncheray, E-Mail: lpj@ans.net ANS Communications, Inc. Phone: +1 (313) 677 7378 100 Phoenix Drive, Ann Arbor, MI 48108, USA Fax: +1 (313) 677 7310 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM From owner-freebsd-current Wed Dec 18 12:07:58 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA24462 for current-outgoing; Wed, 18 Dec 1996 12:07:58 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA24457 for ; Wed, 18 Dec 1996 12:07:56 -0800 (PST) Received: by halloran-eldar.lcs.mit.edu; (5.65v3.2/1.1.8.2/19Aug95-0530PM) id AA08255; Wed, 18 Dec 1996 15:07:47 -0500 Date: Wed, 18 Dec 1996 15:07:47 -0500 From: Garrett Wollman Message-Id: <9612182007.AA08255@halloran-eldar.lcs.mit.edu> To: Laurent Joncheray Cc: current@freebsd.org Subject: microtime() resolution? In-Reply-To: <199612181933.OAA13797@obelix.aa.ans.net> References: <199612181933.OAA13797@obelix.aa.ans.net> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk < said: > function, called from the IP driver? I mean, it is supposed to return > the time in us, but is the timer updated every us, or more often, or less? The timer is updated `hz' times a second (i.e., every 10 msec). However, microtime() uses a hardware register to interpolate between clock ticks with potentially-sub-microsecond resolution. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, ANA, or NSA| - Susan Aglukark and Chad Irschick From owner-freebsd-current Wed Dec 18 12:39:07 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA25574 for current-outgoing; Wed, 18 Dec 1996 12:39:07 -0800 (PST) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id MAA25566; Wed, 18 Dec 1996 12:38:53 -0800 (PST) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id MAA03147; Wed, 18 Dec 1996 12:38:16 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma003145; Wed Dec 18 12:38:11 1996 Received: (from archie@localhost) by bubba.whistle.com (8.7.5/8.6.12) id MAA19182; Wed, 18 Dec 1996 12:38:11 -0800 (PST) From: Archie Cobbs Message-Id: <199612182038.MAA19182@bubba.whistle.com> Subject: Re: IP masquerading (for a LAN, _not_ PPP) In-Reply-To: from Charles Owens at "Dec 18, 96 08:00:23 am" To: owensc@enc.edu (Charles Owens) Date: Wed, 18 Dec 1996 12:38:11 -0800 (PST) Cc: sos@freebsd.org, luigi@labinfo.iet.unipi.it, julian@whistle.com, wangel@wgrobez1.remote.louisville.edu, dnex@access.digex.net, current@freebsd.org, stable@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Ok... help me out here: the 'ipfilter' package is _not_ a userland > implementation, right? (just trying to put all of the pieces to gether > here...) > > Why do some folks consider the DIVERT sockets with userland daemon > approach better than other existing options, such as ipfilter? Or, more > directly, why might I not want to user ipfilter to build a firewall for a > large (hundreds of users) LAN? (pssst... not trying to start a war here) It depends on what you're doing... if you're only going to use it, then an integrated, debugged, fully functional kernel level implementation is ideal. If you plan on doing development, debugging, adding custom features, etc., or don't need high performance, then a user land version is probably preferable... at least until you get it all stable and working. The only point I would argue is that putting the filter/translation stuff inside the (user-land) ppp daemon combines the worst of both worlds. Rather than doing this, it would make more sense to separate it out into a standalone process (via divert sockets) so it can be used more generally than just with PPP (cf. subject line of this thread). -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-current Wed Dec 18 13:21:17 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA28303 for current-outgoing; Wed, 18 Dec 1996 13:21:17 -0800 (PST) Received: from tau-ceti.isc-br.com (root@tau-ceti.isc-br.com [129.189.2.133]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA28298 for ; Wed, 18 Dec 1996 13:21:14 -0800 (PST) Received: by tau-ceti.isc-br.com (Smail3.1.28.1 #13) id m0vaTGc-0008pGC; Wed, 18 Dec 96 13:11 PST Received: from phobos.walker.org (localhost.walker.org [127.0.0.1]) by phobos.walker.org (8.8.4/8.8.4) with ESMTP id NAA00876 for ; Wed, 18 Dec 1996 13:01:14 -0800 (PST) Message-Id: <199612182101.NAA00876@phobos.walker.org> To: freebsd-current@freebsd.org Subject: Problem with /bin/sh's getopts builtin Date: Wed, 18 Dec 1996 13:01:13 -0800 From: Keith Walker Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk So, am I the only one who is having trouble with sh's getopts command not working? As of a couple of weeks ago, or at least somewhere between 2.2-SNAP-101496 and 3.0-Current, the getopts command stopped working correctly for me. As an offer of proof, I commented out the last line of the /usr/bin/lp command (*not* lpr, but lp, the POSIX compat command) so it wouldn't actually print anything, then did the following: Script started on Wed Dec 18 12:49:14 1996 phobos:/usr/bin# sh -x lp -o + ncopies= + symlink=-s + dest=lp + getopts cd:n:o: option + shift 0 phobos:/usr/bin# sh -x lp -c + ncopies= + symlink=-s + dest=lp + getopts cd:n:o: option + shift 0 phobos:/usr/bin# Script done on Wed Dec 18 12:49:58 1996 Notice the lack of any action on the part of getopts, including it not noticing that I didn't give the "-o" option an argument on the first try. Could someone try it out on their system? I don't know if I've got something misconfigured or maybe this is some strange POSIX compliancy issue. keith. From owner-freebsd-current Wed Dec 18 14:12:34 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA01243 for current-outgoing; Wed, 18 Dec 1996 14:12:34 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA01228; Wed, 18 Dec 1996 14:12:21 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id OAA16528; Wed, 18 Dec 1996 14:11:47 -0800 (PST) To: Archie Cobbs cc: owensc@enc.edu (Charles Owens), sos@FreeBSD.org, luigi@labinfo.iet.unipi.it, julian@whistle.com, wangel@wgrobez1.remote.louisville.edu, dnex@access.digex.net, current@FreeBSD.org, stable@FreeBSD.org Subject: Re: IP masquerading (for a LAN, _not_ PPP) In-reply-to: Your message of "Wed, 18 Dec 1996 12:38:11 PST." <199612182038.MAA19182@bubba.whistle.com> Date: Wed, 18 Dec 1996 14:11:46 -0800 Message-ID: <16515.850947106@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > The only point I would argue is that putting the filter/translation > stuff inside the (user-land) ppp daemon combines the worst of both > worlds. Rather than doing this, it would make more sense to separate > it out into a standalone process (via divert sockets) so it can be > used more generally than just with PPP (cf. subject line of this thread). I don't think anyone has ever argued otherwise (conceptually, pulling NAT out of ppp makes sense for a lot of reasons!). This didn't stop a lot of people from needing something which worked in an adequate number of cases right now. :) Jordan From owner-freebsd-current Wed Dec 18 14:54:49 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA04107 for current-outgoing; Wed, 18 Dec 1996 14:54:49 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id OAA04067 for ; Wed, 18 Dec 1996 14:54:31 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id XAA08510; Wed, 18 Dec 1996 23:51:26 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id XAA11264; Wed, 18 Dec 1996 23:51:21 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id XAA24426; Wed, 18 Dec 1996 23:47:30 +0100 (MET) From: J Wunsch Message-Id: <199612182247.XAA24426@uriah.heep.sax.de> Subject: Re: Problem with /bin/sh's getopts builtin To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Wed, 18 Dec 1996 23:47:30 +0100 (MET) Cc: kew@timesink.spk.wa.us (Keith Walker), sprice@hiwaay.net (Steve Price) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199612182101.NAA00876@phobos.walker.org> from Keith Walker at "Dec 18, 96 01:01:13 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Keith Walker wrote: > So, am I the only one who is having trouble with sh's getopts command > not working? As of a couple of weeks ago, or at least somewhere > between 2.2-SNAP-101496 and 3.0-Current, the getopts command stopped > working correctly for me. > Notice the lack of any action on the part of getopts, including it not > noticing that I didn't give the "-o" option an argument on the first > try. Umm, it seems you're right. :-( Steve, do you have any idea? This should definately be fixed before 2.2 leaves the factory... -- 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 Wed Dec 18 16:28:51 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA17663 for current-outgoing; Wed, 18 Dec 1996 16:28:51 -0800 (PST) Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA17617 for ; Wed, 18 Dec 1996 16:28:31 -0800 (PST) Received: from campa.panke.de (anonymous223.ppp.cs.tu-berlin.de [130.149.17.223]) by mail.cs.tu-berlin.de (8.8.4/8.8.4) with SMTP id BAA03614; Thu, 19 Dec 1996 01:18:50 +0100 (MET) Received: (from wosch@localhost) by campa.panke.de (8.6.12/8.6.12) id AAA00506; Thu, 19 Dec 1996 00:36:45 +0100 Date: Thu, 19 Dec 1996 00:36:45 +0100 From: Wolfram Schneider Message-Id: <199612182336.AAA00506@campa.panke.de> To: Bill Paul Cc: current@freebsd.org Subject: Re: group(5) limits In-Reply-To: <199612170557.AAA01510@skynet.ctr.columbia.edu> References: <199612170124.CAA02231@campa.panke.de> <199612170557.AAA01510@skynet.ctr.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Bill Paul writes: >While removing the static membership limit of 200 is probably okay, NIS v2 >is permanently saddled with a record limit of 1024 bytes. The yp_mkdb(8) >utility enforces this. The limit is part of the yp.x protocol, consequently >to change it would break compatibility with all other NIS implementations. >This means these changes would be fine for local /etc/group files, but >you'd still be stuck with a 1024 byte line limit if you choose to use NIS. I can reduce the limit from 256K to 1k. But didn't we already break NIS with increasing user name length from 8 characters to 16 characters? Wolfram From owner-freebsd-current Wed Dec 18 16:31:53 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA18125 for current-outgoing; Wed, 18 Dec 1996 16:31:53 -0800 (PST) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA18108 for ; Wed, 18 Dec 1996 16:31:47 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id TAA08463 for current@freebsd.org; Wed, 18 Dec 1996 19:31:38 -0500 (EST) From: "John S. Dyson" Message-Id: <199612190031.TAA08463@dyson.iquest.net> Subject: Update on kernel Lite/2 merge To: current@freebsd.org Date: Wed, 18 Dec 1996 19:31:38 -0500 (EST) 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 X-Loop: FreeBSD.org Precedence: bulk FYI, Not because of technical problems, but because of personal time limitations/conflicts my merge should be happening closer to Fri/Sat... If this causes anyone problems, just let me know -- I'm flexible... John From owner-freebsd-current Wed Dec 18 16:55:51 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA19720 for current-outgoing; Wed, 18 Dec 1996 16:55:51 -0800 (PST) Received: from bunyip.cc.uq.oz.au (daemon@bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA19715 for ; Wed, 18 Dec 1996 16:55:47 -0800 (PST) Received: (from daemon@localhost) by bunyip.cc.uq.oz.au (8.8.4/8.8.3) id KAA14759 for current@freebsd.org; Thu, 19 Dec 1996 10:55:43 +1000 Received: from pandora.devetir.qld.gov.au by ogre.devetir.qld.gov.au (8.7.5/DEVETIR-E0.3a) with ESMTP id KAA00921 for ; Thu, 19 Dec 1996 10:58:15 +1000 (EST) Received: from netfl15a.devetir.qld.gov.au (netfl15a.devetir.qld.gov.au [167.123.24.12]) by pandora.devetir.qld.gov.au (8.6.10/8.6.12) with ESMTP id KAA28781 for ; Thu, 19 Dec 1996 10:55:34 +1000 Received: from localhost by netfl15a.devetir.qld.gov.au (8.6.8.1/DEVETIR-0.1) id AAA07907 for ; Thu, 19 Dec 1996 00:53:37 GMT Message-Id: <199612190053.AAA07907@netfl15a.devetir.qld.gov.au> X-Mailer: exmh version 2.0alpha 12/3/96 To: current@freebsd.org Subject: Odd error in -current when making world 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, 19 Dec 1996 10:53:36 +1000 From: Stephen Hocking Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk During the "make cleandir" phase, it will rattle along for a while and then something like this will happen - ===> gnu/usr.bin/gdb/gdb ===> gnu/usr.bin/gdb/doc ===> gnu/usr.bin/genclass ===> gnu/usr.bin/gperf pwd: No such file or directory *** Error code 2 Stop. *** Error code 1 Bizarre. If one restarts the make cleandir, it will continue on a little further each time. Any clues before I bug this? Stephen -- The views expressed above are not those of the Worker's Compensation Board of Queensland, Australia. From owner-freebsd-current Wed Dec 18 17:02:34 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA20006 for current-outgoing; Wed, 18 Dec 1996 17:02:34 -0800 (PST) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id RAA20001 for ; Wed, 18 Dec 1996 17:02:26 -0800 (PST) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id UAA06326; Wed, 18 Dec 1996 20:00:13 -0500 From: Bill Paul Message-Id: <199612190100.UAA06326@skynet.ctr.columbia.edu> Subject: Re: group(5) limits To: wosch@cs.tu-berlin.de (Wolfram Schneider) Date: Wed, 18 Dec 1996 20:00:12 -0500 (EST) Cc: current@freebsd.org In-Reply-To: <199612182336.AAA00506@campa.panke.de> from "Wolfram Schneider" at Dec 19, 96 00:36:45 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Of all the gin joints in all the towns in all the world, Wolfram Schneider had to walk into mine and say: > Bill Paul writes: > >While removing the static membership limit of 200 is probably okay, NIS v2 > >is permanently saddled with a record limit of 1024 bytes. The yp_mkdb(8) > >utility enforces this. The limit is part of the yp.x protocol, consequently > >to change it would break compatibility with all other NIS implementations. > >This means these changes would be fine for local /etc/group files, but > >you'd still be stuck with a 1024 byte line limit if you choose to use > NIS. > > I can reduce the limit from 256K to 1k. Technically you can leave it at 256K, it's just that if you go to turn your /etc/group file into an NIS map the yp_mkdb(8) program and you have lines longer that 1024 bytes, it'll complain that the lines are too long and skip them. Whether or not this constitutes a reason for keeping the limit in getgrent(3) at 1024 bytes is debatable. It may be enough to put a warning in the man page that while the getgrent(3) code can handle line sizes up to 256K, they won't work with NIS. > But didn't we already break > NIS with increasing user name length from 8 characters to 16 > characters? No. NIS itself doesn't care about the size of the individual fields in the passwd or master.passwd records. In NIS, keys and data are essentially opaque buffers that can be at most 1024 bytes in size (in practice, the data in the buffers is usually limited to ASCII characters but it can really be anything). It's up to getpwent(3) or getpwent(3) to parse the data in the buffers and handle field overflows accordingly. In our case, the buffer returned from NIS is handled more or less in place: the username field is not copied to statically sized buffer that might overflow. The 1024 byte limitation in NIS v2 stems from Sun's decision to use ndbm as the database backend for their NIS implementation. The ndbm code is also limited to 1024 byte keys and data. When Sun wrote the NIS v2 protocol definition, they explicitly limited the size of keys and data to 1024 bytes to match the ndbm limit. Consequently, even though we use Berkeley DB (hash method) which can handle keys and data up to 4GB in size (in theory :), our NIS implementation still has to abide by the limit in the protocol definition if it is to be compliant with all the other NIS implementation currently in use. In other words: yes this sucks; blame Sun. :) NIS+ works entirely differently (as you might expect). It uses a new relational database backend (libnisdb) which does not have the same limitations as ndbm. Data is stored in tables that can have up to 64 columns (any one of which may be marked searchable) and and the columns themselves can be arbitrarily large (according to the protocol specification anyway -- the server or the database backend may choose to limit the size to keep resource usage from getting out of hand). The database backend also allows duplicate entries (where 'duplicate' means more than one entry that matches the same exact search conditions), though I haven't experimented with the server to see if it allows it as well. If it does, then you could have two entries for 'group=foo,uid=1234' with totally different group membership lists. Whether or not the client library can merge them back into a single grp struct I don't know. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= From owner-freebsd-current Wed Dec 18 17:51:24 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA22434 for current-outgoing; Wed, 18 Dec 1996 17:51:24 -0800 (PST) Received: from vader.cs.berkeley.edu (vader.CS.Berkeley.EDU [128.32.38.234]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA22425 for ; Wed, 18 Dec 1996 17:51:22 -0800 (PST) Received: (from asami@localhost) by vader.cs.berkeley.edu (8.8.4/8.7.3) id RAA04365; Wed, 18 Dec 1996 17:51:01 -0800 (PST) Date: Wed, 18 Dec 1996 17:51:01 -0800 (PST) Message-Id: <199612190151.RAA04365@vader.cs.berkeley.edu> To: sysseh@devetir.qld.gov.au CC: current@FreeBSD.ORG In-reply-to: <199612190053.AAA07907@netfl15a.devetir.qld.gov.au> (message from Stephen Hocking on Thu, 19 Dec 1996 10:53:36 +1000) Subject: Re: Odd error in -current when making world From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk * During the "make cleandir" phase, it will rattle along for a while and then * something like this will happen - * * ===> gnu/usr.bin/gdb/gdb * ===> gnu/usr.bin/gdb/doc * ===> gnu/usr.bin/genclass * ===> gnu/usr.bin/gperf * pwd: No such file or directory * *** Error code 2 * * Stop. * *** Error code 1 * * Bizarre. If one restarts the make cleandir, it will continue on a little * further each time. Any clues before I bug this? I have the exact same symptom, started last night (after I recompiled the kernel for the first time since the 10th). I thought it was a hardware problem! ;) I'll boot my old kernel and see if it improves the situation when i get home. Satoshi From owner-freebsd-current Wed Dec 18 18:46:07 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id SAA24775 for current-outgoing; Wed, 18 Dec 1996 18:46:07 -0800 (PST) Received: from mantar.slip.netcom.com (mantar.slip.netcom.com [192.187.167.134]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id SAA24760 for ; Wed, 18 Dec 1996 18:46:05 -0800 (PST) Received: from dual (DUAL [192.187.167.136]) by mantar.slip.netcom.com (8.8.4/8.6.9) with SMTP id SAA16177; Wed, 18 Dec 1996 18:45:45 -0800 (PST) Message-ID: <32B8AC52.2959@netcom.com> Date: Wed, 18 Dec 1996 18:45:38 -0800 From: Manfred Antar Reply-To: mantar@netcom.com Organization: NONE X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: Satoshi Asami CC: sysseh@devetir.qld.gov.au, current@freebsd.org Subject: Re: Odd error in -current when making world References: <199612190151.RAA04365@vader.cs.berkeley.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The same thing is happening to me and i can't figure it out. i'll try a week old kernel!! Manfred -- |==============================| | mantar@netcom.com | | Ph. (415) 681-6235 | |==============================| From owner-freebsd-current Wed Dec 18 19:40:08 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id TAA27317 for current-outgoing; Wed, 18 Dec 1996 19:40:08 -0800 (PST) Received: from dfw-ix2.ix.netcom.com (dfw-ix2.ix.netcom.com [206.214.98.2]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id TAA27298 for ; Wed, 18 Dec 1996 19:40:04 -0800 (PST) Received: from silvia.HIP.Berkeley.EDU (ala-ca13-06.ix.netcom.com [204.32.168.38]) by dfw-ix2.ix.netcom.com (8.6.13/8.6.12) with ESMTP id TAA17858; Wed, 18 Dec 1996 19:38:31 -0800 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.8.4/8.6.9) id TAA02712; Wed, 18 Dec 1996 19:38:20 -0800 (PST) Date: Wed, 18 Dec 1996 19:38:20 -0800 (PST) Message-Id: <199612190338.TAA02712@silvia.HIP.Berkeley.EDU> To: sysseh@devetir.qld.gov.au, current@FreeBSD.ORG In-reply-to: <199612190151.RAA04365@vader.cs.berkeley.edu> (asami@cs.berkeley.edu) Subject: Re: Odd error in -current when making world From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk * * pwd: No such file or directory * I have the exact same symptom, started last night (after I recompiled * the kernel for the first time since the 10th). I thought it was a * hardware problem! ;) * * I'll boot my old kernel and see if it improves the situation when i * get home. I tried the old kernel, it's still the same. However, I have successfully done a make world yesterday morning (about 34 hours ago), so it worked quite recently. Hmm. Satoshi From owner-freebsd-current Wed Dec 18 19:42:21 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id TAA27473 for current-outgoing; Wed, 18 Dec 1996 19:42:21 -0800 (PST) Received: from wgrobez1.remote.louisville.edu (wgrobez1.remote.louisville.edu [136.165.243.183]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id TAA27451; Wed, 18 Dec 1996 19:42:15 -0800 (PST) Received: from localhost (wangel@localhost) by wgrobez1.remote.louisville.edu (8.8.4/8.6.12) with SMTP id WAA14187; Wed, 18 Dec 1996 22:45:20 -0500 (EST) Date: Wed, 18 Dec 1996 22:45:19 -0500 (EST) From: Gary Roberts To: Charles Owens cc: DNEX , current@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: IP masquerading (for a LAN, _not_ PPP) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 16 Dec 1996, Charles Owens wrote: > On Sun, 8 Dec 1996, Gary Roberts wrote: > > > On Sun, 8 Dec 1996, DNEX wrote: > > > > > Does FreeBSD support IP masquerading or are there plans to implement it? > > > > > > > Yes. It does. Charles Mott. Nice piece of software. Anyways, it's not > > a program like linux uses, it uses the PPP program. Check it out at: > > > > http://www.srv.net/~cmott/alias.html > > > This looks nifty, but I'm interested in doing masquerading on a firewall > for users on a large LAN, not dialing in via PPP. What's the status of > doing _this_ with FreeBSD? > > --- > ------------------------------------------------------------------------- > Charles Owens Email: owensc@enc.edu > "I read somewhere to learn is to > Information Technology Services remember... and I've learned that > Eastern Nazarene College we've all forgot..." - King's X > ------------------------------------------------------------------------- > That's exactly what I'm doing. Except I 'dial' out to the net with PPP. So, on my ISDN, I have like 25 machines firewalled, all routed via the ppp program. Gary Roberts System Admin. -- Altered Reality. http://136.165.243.183 -- Main User Pages From owner-freebsd-current Wed Dec 18 20:55:46 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA29798 for current-outgoing; Wed, 18 Dec 1996 20:55:46 -0800 (PST) Received: from mantar.slip.netcom.com (mantar.slip.netcom.com [192.187.167.134]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id UAA29792 for ; Wed, 18 Dec 1996 20:55:43 -0800 (PST) Received: from dual (DUAL [192.187.167.136]) by mantar.slip.netcom.com (8.8.4/8.6.9) with SMTP id UAA10758; Wed, 18 Dec 1996 20:54:16 -0800 (PST) Message-ID: <32B8CA70.9BF@netcom.com> Date: Wed, 18 Dec 1996 20:54:08 -0800 From: Manfred Antar Reply-To: mantar@netcom.com Organization: NONE X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: Satoshi Asami CC: sysseh@devetir.qld.gov.au, current@freebsd.org Subject: Re: Odd error in -current when making world References: <199612190338.TAA02712@silvia.HIP.Berkeley.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I just restored /usr/src/bin/sh from 11/26 and rebuilt sh. doing a make world now and it is way farther along than i have been able to do.before i could not get through a make bootstrap.i noticed some changes to sh a day or two ago. more if and when make world finishes. Manfred -- |==============================| | mantar@netcom.com | | Ph. (415) 681-6235 | |==============================| From owner-freebsd-current Wed Dec 18 21:49:04 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id VAA01820 for current-outgoing; Wed, 18 Dec 1996 21:49:04 -0800 (PST) Received: from dfw-ix5.ix.netcom.com (dfw-ix5.ix.netcom.com [206.214.98.5]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id VAA01815 for ; Wed, 18 Dec 1996 21:49:02 -0800 (PST) Received: from silvia.HIP.Berkeley.EDU (ala-ca13-06.ix.netcom.com [204.32.168.38]) by dfw-ix5.ix.netcom.com (8.6.13/8.6.12) with ESMTP id VAA23104; Wed, 18 Dec 1996 21:47:03 -0800 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.8.4/8.6.9) id VAA10657; Wed, 18 Dec 1996 21:44:12 -0800 (PST) Date: Wed, 18 Dec 1996 21:44:12 -0800 (PST) Message-Id: <199612190544.VAA10657@silvia.HIP.Berkeley.EDU> To: mantar@netcom.com CC: sysseh@devetir.qld.gov.au, current@freebsd.org In-reply-to: <32B8CA70.9BF@netcom.com> (message from Manfred Antar on Wed, 18 Dec 1996 20:54:08 -0800) Subject: Re: Odd error in -current when making world From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk * I just restored /usr/src/bin/sh from 11/26 and rebuilt sh. doing a make * world now and it is way farther along than i have been able to do.before * i could not get through a make bootstrap.i noticed some changes to sh a * day or two ago. more if and when make world finishes. Let me confirm that I did the same (well I only rewound it one week) and with that sh, make cleandir completed successfully. I'm going to start a make world now. Satoshi From owner-freebsd-current Wed Dec 18 22:30:24 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA03628 for current-outgoing; Wed, 18 Dec 1996 22:30:24 -0800 (PST) Received: from dfw-ix1.ix.netcom.com (dfw-ix1.ix.netcom.com [206.214.98.1]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id WAA03619 for ; Wed, 18 Dec 1996 22:30:15 -0800 (PST) Received: from silvia.HIP.Berkeley.EDU (ala-ca13-06.ix.netcom.com [204.32.168.38]) by dfw-ix1.ix.netcom.com (8.6.13/8.6.12) with ESMTP id WAA10437 for ; Wed, 18 Dec 1996 22:29:31 -0800 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.8.4/8.6.9) id WAA04001; Wed, 18 Dec 1996 22:29:29 -0800 (PST) Date: Wed, 18 Dec 1996 22:29:29 -0800 (PST) Message-Id: <199612190629.WAA04001@silvia.HIP.Berkeley.EDU> To: current@freebsd.org Subject: thrashed dirs From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Yesterday, I had two SCSI-related failures: == Dec 18 03:10:37 silvia /kernel: sd0(ahc0:0:0): MEDIUM ERROR info:1fb34f asc:3,0 Peripheral device write fault Dec 18 03:10:37 silvia /kernel: , retries:4 === in the middle of the night, with not much load on the machine (other than me typing or reading mail), and === Dec 18 08:34:56 silvia /kernel: sd0(ahc0:0:0): timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Dec 18 08:35:11 silvia /kernel: SEQADDR == 0x7 Dec 18 08:35:11 silvia /kernel: Ordered Tag queued Dec 18 08:35:11 silvia /kernel: Ordered Tag sent Dec 18 08:35:11 silvia /kernel: sd0(ahc0:0:0): timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Dec 18 08:35:11 silvia /kernel: SEQADDR == 0xf Dec 18 08:35:11 silvia /kernel: sd0(ahc0:0:0): timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Dec 18 08:35:11 silvia /kernel: SEQADDR == 0xb Dec 18 08:35:11 silvia /kernel: ahc0: Issued Channel A Bus Reset. 3 SCBs aborted Dec 18 08:35:11 silvia /kernel: sd0(ahc0:0:0): UNIT ATTENTION asc:29,0 Dec 18 08:35:11 silvia /kernel: sd0(ahc0:0:0): Power on, reset, or bus device reset occurred Dec 18 08:35:11 silvia /kernel: , retries:3 Dec 18 08:35:11 silvia /kernel: sd1(ahc0:8:0): UNIT ATTENTION asc:29,2 Dec 18 08:35:11 silvia /kernel: , retries:4 Dec 18 08:35:11 silvia /kernel: sd1(ahc0:8:0): ABORTED COMMAND asc:4e,0 Overlapped commands attempted Dec 18 08:35:11 silvia /kernel: , retries:4 Dec 18 08:35:19 silvia /kernel: sd1(ahc0:8:0): timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Dec 18 08:35:19 silvia /kernel: SEQADDR == 0xc Dec 18 08:35:21 silvia /kernel: sd1(ahc0:8:0): timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Dec 18 08:35:22 silvia /kernel: SEQADDR == 0xb Dec 18 08:35:22 silvia /kernel: ahc0: Issued Channel A Bus Reset. 2 SCBs aborted Dec 18 08:35:22 silvia /kernel: sd0(ahc0:0:0): UNIT ATTENTION asc:29,0 Dec 18 08:35:22 silvia /kernel: sd0(ahc0:0:0): Power on, reset, or bus device reset occurred Dec 18 08:35:22 silvia /kernel: , retries:3 Dec 18 08:35:22 silvia /kernel: sd1(ahc0:8:0): UNIT ATTENTION asc:29,2 Dec 18 08:35:22 silvia /kernel: , retries:3 === followed by a whole lot of error messages, such as === Dec 18 08:36:35 silvia /kernel: sd_strategy: Negative block number: 0xd10c1e32 Dec 18 08:36:35 silvia /kernel: bad block 1753616153, ino 446144 Dec 18 08:36:35 silvia /kernel: pid 8771 (find), uid 1289717719 on /b: bad block Dec 18 08:36:35 silvia /kernel: sd_strategy: Negative block number: 0xede56988 Dec 18 08:36:35 silvia /kernel: bad block -151866172, ino 446144 Dec 18 08:36:35 silvia /kernel: pid 8771 (find), uid 1289717719 on /b: bad block Dec 18 08:36:35 silvia /kernel: sd_strategy: Negative block number: 0x9b686b14 Dec 18 08:36:35 silvia /kernel: bad block -843827830, ino 446144 Dec 18 08:36:35 silvia /kernel: pid 8771 (find), uid 1289717719 on /b: bad block Dec 18 08:36:35 silvia /kernel: bad block 2006773318, ino 446144 Dec 18 08:36:35 silvia /kernel: pid 8771 (find), uid 1289717719 on /b: bad block : Dec 18 08:43:05 silvia /kernel: pid 8851 (find), uid -426065323 on /b: bad block Dec 18 08:43:06 silvia /kernel: bad block -874381723, ino 446162 Dec 18 08:43:06 silvia /kernel: pid 8851 (find), uid -426065323 on /b: bad block Dec 18 08:43:06 silvia /kernel: bad block -1156341551, ino 446162 Dec 18 08:43:06 silvia /kernel: pid 8851 (find), uid -426065323 on /b: bad block Dec 18 08:43:06 silvia /kernel: bad block 345491637, ino 446162 Dec 18 08:43:06 silvia /kernel: pid 8851 (find), uid -426065323 on /b: bad block Dec 18 08:43:06 silvia /kernel: bad block -1239978271, ino 446162 Dec 18 08:43:06 silvia /kernel: pid 8851 (find), uid -426065323 on /b: bad block Dec 18 08:43:06 silvia /kernel: sd_strategy: Negative block number: 0x8faa640a Dec 18 08:45:57 silvia /kernel: sd_strategy: Negative block number: 0xc2dadedc === during the /etc/daily run. Whatever the cause was, seemed to have destroyed a few directories. There was a directory called "old" in my home directory, that gives a "bad file descriptor" whenever I try to do a "ls" with anything (even just "-i"). This is the relevant part of the directory in od -c format: === 0005500 020 \0 \b 007 f o o . a s c \0 013 ,AO(B 006 \0 0005520 ,A4(B \0 004 003 o l d \0 ,A1(B Z \0 \0 200 \0 \b \f 0005540 m i s s f o n t . l o g \0 ,A|(B ,A?(B ,Ao(B === and the same three lines from od -b for those of us who are more hip in octal: === 0005500 020 000 010 007 146 157 157 056 141 163 143 000 013 317 006 000 0005520 264 000 004 003 157 154 144 000 261 132 000 000 200 000 010 014 0005540 155 151 163 163 146 157 156 164 056 154 157 147 000 374 277 357 === There was another directory (one of my mail dir's) that was so completely thrashed that I can't even start quoting the bad parts here, and some source directories. I'll uuencode and upload them to somewhere if anyone is interested. These were all on an Adaptec 2940UW / Micropolis 3243W (sd0) combination. The machine also has a Quantum XP35300W (sd1: holds system dirs and stuff) and that disk doesn't seem to have suffered any damage. Satoshi From owner-freebsd-current Thu Dec 19 01:35:46 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA12594 for current-outgoing; Thu, 19 Dec 1996 01:35:46 -0800 (PST) Received: from btp1da.phy.uni-bayreuth.de (btp1da.phy.uni-bayreuth.de [132.180.20.32]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id BAA12249 for ; Thu, 19 Dec 1996 01:31:24 -0800 (PST) Received: (from root@localhost) by btp1da.phy.uni-bayreuth.de (8.8.4/8.7.3) id KAA07442 for current@freebsd.org; Thu, 19 Dec 1996 10:28:28 +0100 (MET) From: Werner Griessl Message-Id: <199612190928.KAA07442@btp1da.phy.uni-bayreuth.de> Subject: arp fails To: current@freebsd.org Date: Thu, 19 Dec 1996 10:28:27 +0100 (MET) X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Cannot compile arp in current from today (Thu Dec 19) because: ===> usr.sbin/arp cc -O -c /spare/F/src/usr.sbin/arp/arp.c /spare/F/src/usr.sbin/arp/arp.c:88: conflicting types for `ether_aton' /usr/include/net/ethernet.h:67: previous declaration of `ether_aton' *** Error code 1 Werner From owner-freebsd-current Thu Dec 19 03:17:56 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id DAA16267 for current-outgoing; Thu, 19 Dec 1996 03:17:56 -0800 (PST) Received: from hub.org (root@hub.org [207.107.138.200]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id DAA16262 for ; Thu, 19 Dec 1996 03:17:54 -0800 (PST) Received: from localhost (scrappy@localhost) by hub.org (8.8.2/8.7.5) with SMTP id FAA13596 for ; Thu, 19 Dec 1996 05:39:06 -0500 (EST) Date: Thu, 19 Dec 1996 05:39:05 -0500 (EST) From: "Marc G. Fournier" Reply-To: "Marc G. Fournier" To: current@freebsd.org Subject: CVSup binary with 3.x kernel Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi... Can someone tell me why I'm getting: fatal process exception: page fault, fault VA = 0x2944c4 fatal process exception: page fault, fault VA = 0x2944c4 fatal process exception: page fault, fault VA = 0x2944c4 all over my screen after upgrading my 2.2-ALPHA machine to 3.x? I picked up the static version of CVSup, but I seem to have incorrectly assumed that upgrading the system to 3.x wouldn't be a problem :( The first time I tried to run it with the 3.x kernel, it even brought the GUI interface up (am running X), while continually scrolling the above over my screen :( My first assumption is that the lkm's need recompiling or libs, or whatnot...not sure which needs recompiling though. And, I don't have 'src-contrib' yet, which was what I was trying to CVSup in, so if anyone can point out what I need to have recompiled "right now" to get it running so that I can get the missing sources...would be much appreciated :) Thanks... Marc G. Fournier scrappy@hub.org Systems Administrator @ hub.org scrappy@freebsd.org From owner-freebsd-current Thu Dec 19 04:35:16 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id EAA20451 for current-outgoing; Thu, 19 Dec 1996 04:35:16 -0800 (PST) Received: from friley216.res.iastate.edu (friley216.res.iastate.edu [129.186.78.216]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id EAA20446 for ; Thu, 19 Dec 1996 04:35:14 -0800 (PST) Received: from friley216.res.iastate.edu (loopback [127.0.0.1]) by friley216.res.iastate.edu (8.8.3/8.7.3) with ESMTP id GAA06779 for ; Thu, 19 Dec 1996 06:35:12 -0600 (CST) Message-Id: <199612191235.GAA06779@friley216.res.iastate.edu> X-Mailer: exmh version 1.6.9 8/22/96 To: current@freebsd.org Subject: which tag to use for 2.2? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Dec 1996 06:35:11 -0600 From: Chris Csanady Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I noticed both a RELENG_2_2 and a RELENG_2_2_BP in the current CVS tree, and was wondering which tag to use for what will be 2.2? Also, I remember something about the tags being sticky, and last time I checked out, I specified a date. Will just a 'cvs update -P -r RELENG_2_2 src' give me what I want? Thanks, Chris Csanady From owner-freebsd-current Thu Dec 19 04:38:17 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id EAA20544 for current-outgoing; Thu, 19 Dec 1996 04:38:17 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id EAA20537 for ; Thu, 19 Dec 1996 04:38:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id EAA15047; Thu, 19 Dec 1996 04:37:41 -0800 (PST) Message-Id: <199612191237.EAA15047@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: "Marc G. Fournier" cc: current@freebsd.org Subject: Re: CVSup binary with 3.x kernel In-reply-to: Your message of "Thu, 19 Dec 1996 05:39:05 EST." From: David Greenman Reply-To: dg@root.com Date: Thu, 19 Dec 1996 04:37:41 -0800 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Can someone tell me why I'm getting: > >fatal process exception: page fault, fault VA = 0x2944c4 >fatal process exception: page fault, fault VA = 0x2944c4 >fatal process exception: page fault, fault VA = 0x2944c4 > > all over my screen after upgrading my 2.2-ALPHA machine >to 3.x? I picked up the static version of CVSup, but I seem to >have incorrectly assumed that upgrading the system to 3.x >wouldn't be a problem :( > > The first time I tried to run it with the 3.x kernel, >it even brought the GUI interface up (am running X), while >continually scrolling the above over my screen :( > > My first assumption is that the lkm's need recompiling >or libs, or whatnot...not sure which needs recompiling though. >And, I don't have 'src-contrib' yet, which was what I was trying >to CVSup in, so if anyone can point out what I need to have >recompiled "right now" to get it running so that I can get >the missing sources...would be much appreciated :) You have options "DEBUG" in your kernel. Remove it. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-current Thu Dec 19 04:50:00 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id EAA20855 for current-outgoing; Thu, 19 Dec 1996 04:50:00 -0800 (PST) Received: from grackle.grondar.za (Ovggev6F733MCSTmNkfnoRZXi+jqIV4X@grackle.grondar.za [196.7.18.131]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id EAA20830 for ; Thu, 19 Dec 1996 04:49:33 -0800 (PST) Received: from grackle.grondar.za (vWfBfKIcmBw2pqyItgxUMyyJoTF3gDJ4@localhost [127.0.0.1]) by grackle.grondar.za (8.8.4/8.8.4) with ESMTP id OAA10899; Thu, 19 Dec 1996 14:47:02 +0200 (SAT) Message-Id: <199612191247.OAA10899@grackle.grondar.za> To: Chris Csanady cc: current@freebsd.org Subject: Re: which tag to use for 2.2? Date: Thu, 19 Dec 1996 14:47:02 +0200 From: Mark Murray Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Chris Csanady wrote: > I noticed both a RELENG_2_2 and a RELENG_2_2_BP in the current CVS tree, and > was wondering which tag to use for what will be 2.2? Also, I remember > something about the tags being sticky, and last time I checked out, I > specified a date. Will just a 'cvs update -P -r RELENG_2_2 src' give me what > I want? RELENG_2_2 is what you want. The *_BP is the "branch point" tag, marking a new branch in development. M -- Mark Murray PGP key fingerprint = 80 36 6E 40 83 D6 8A 36 This .sig is umop ap!sdn. BC 06 EA 0E 7A F2 CE CE From owner-freebsd-current Thu Dec 19 06:05:34 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA23318 for current-outgoing; Thu, 19 Dec 1996 06:05:34 -0800 (PST) Received: from vector.jhs.no_domain (slip139-92-4-122.mu.de.ibm.net [139.92.4.122]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id GAA23313 for ; Thu, 19 Dec 1996 06:05:20 -0800 (PST) Received: (from jhs@localhost) by vector.jhs.no_domain (8.7.5/8.6.9) id CAA16661; Thu, 19 Dec 1996 02:49:56 +0100 (MET) Date: Thu, 19 Dec 1996 02:49:56 +0100 (MET) Message-Id: <199612190149.CAA16661@vector.jhs.no_domain> To: current@freebsd.org Subject: 2.1.6 mandates a swap, I suggest it shouldn't From: "Julian H. Stacey" Reply-To: "Julian H. Stacey" X-Organization: Vector Systems Ltd. X-Mailer: EXMH 1.6.7, PGP available X-Address: Holz Strasse 27d, 80469 Munich, Germany X-Phone: +49.89.268616 X-Fax: +49.89.2608126 X-ISDN: +49.89.26023276 X-Web: http://www.freebsd.org/~jhs/ Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'd like to suggest that install is being un-necessarily strict in requiring a swap partition ... I suggest it should merely warn & encourage, like it does for /var & /usr (unless maybe swap is required during the install itself as raw disc for unpacking or something). Reason I suggest we not mandate a swap: space. I was installing a small disc without space for swap, as I needed a little system up, for diagnosing other problems. I've built small systems by hand without swap before, one just has to be modest in process launching. As I couldn't use 2.1.6 install to do this, I've abandoned 2.1.6 install, & am cloning my spare 80M scsi disc from a current system. I could imagine other candidates for FreeBSD might have their sizable discs in use already, & also like me, want to see if their hardware will boot etc, using a small spare old disc ... so a pity that swap is mandatory. Julian --- Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/ From owner-freebsd-current Thu Dec 19 08:40:00 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA29273 for current-outgoing; Thu, 19 Dec 1996 08:40:00 -0800 (PST) Received: from plains.nodak.edu (tinguely@plains.NoDak.edu [134.129.111.64]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id IAA29267 for ; Thu, 19 Dec 1996 08:39:58 -0800 (PST) Received: (from tinguely@localhost) by plains.nodak.edu (8.8.3/8.8.3) id KAA27627; Thu, 19 Dec 1996 10:39:42 -0600 (CST) Date: Thu, 19 Dec 1996 10:39:42 -0600 (CST) From: Mark Tinguely Message-Id: <199612191639.KAA27627@plains.nodak.edu> To: current@FreeBSD.ORG, karp@elvisti.kiev.ua Subject: Re: IP masquerading (for a LAN, _not_ PPP) Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk (talking about NAT from ip filter) > We work with this software for months. > IP filtering works perfect. IP masquerading does not. > It seems to work only for 1:1 mapping, otherwise system reboots > often. We changed many versions of this IPNAT and many versions > FreeBSD (and lot of hardware) and nothing has changed in this time. I had an aweful time trying to get NAT to run from the IP filter version 3.1.0 sources. I posted a couple "help" messages to the questions groups that got no helpful replies. I jumped to IP Filter 3.1.2beta and with a script that loads the loadable module, and rewrites the mapping rules to the new IP number, a a prof here is now happily remapping his home network through his kernel PPP line. maybe the user PPP mapping is easier, but it is nice to have the choice. --mark. From owner-freebsd-current Thu Dec 19 12:02:19 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA08183 for current-outgoing; Thu, 19 Dec 1996 12:02:19 -0800 (PST) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA08178 for ; Thu, 19 Dec 1996 12:02:14 -0800 (PST) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id PAA08082; Thu, 19 Dec 1996 15:00:10 -0500 From: Bill Paul Message-Id: <199612192000.PAA08082@skynet.ctr.columbia.edu> Subject: Re: tcsh NIS strangeness To: kuku@gilberto.physik.rwth-aachen.de Date: Thu, 19 Dec 1996 15:00:09 -0500 (EST) Cc: current@freebsd.org In-Reply-To: <199612191440.PAA29931@gilberto.physik.rwth-aachen.de> from "Christoph Kukulies" at Dec 19, 96 03:40:38 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Of all the gin joints in all the towns in all the world, Christoph Kukulies had to walk into mine and say: > > > Now with the just compiled tcsh-6.07-02 I get the follwomg strangeness: > > > > > > toots> ls ~jolitz > > > toots> > > > > > > Only when I once have done a cd ~jolitz ; ls then subsequent > > > ls ~jolitz deliver the expected ls listing. > > > > > > It appears to happen only on the NIS client machines, > > > not the server. The respective home dirs are NFS mounted BTW. > > > The behaviour looks like tcsh directory caching problem. Okay, well I just compiled tcsh 6.07.02 on my FreeBSD 2.2-ALPHA test box. It seems to work fine. For the record, I compiled it as follows: - Unpack archive - cd tcsh-6.07.02 - cp config/bsd4.4 config.h - vi Makefile.std (add -lcrypt to the LIBES line) - make -f Makefile.std That's it. I've always built tcsh this way and I've never had any trouble with it. My test system is configured as an NIS server and is bound to itself. (I also tried it as a client of my SunOS servers and that worked too.) I run ypserv, ypbind, rpc.ypxfrd and rpc.yppasswdd on it. All user passwd entries (except the usual system ones) are in NIS. Using cd ~user works, as does ls ~user. On top of everything else, I use amd to NFS mount all the home filesystems. > > Is the NIS server also the NFS server? What version of FreeBSD are > > the clients and server running? If you recompile the old version of > > The server is running some 2.2-current of 23rd Oct. > The clients are most 2.2 of same vintage, one client is 3.0 one week old. > I believe it wouldn't be possible to me to build an old > version of tcsh now (unless I take an old package of tcsh).. tcsh-6.06 is still easy to get. There's no magic required in compiling it. (The same instructrions I showed above should work.) Needless to say I'm a little confused. If you want to try the binary I compiled, it's at ftp.ctr.columbia.edu:/pub/misc/freebsd/tcsh.6.07.02.gz. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= From owner-freebsd-current Thu Dec 19 12:24:58 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA09294 for current-outgoing; Thu, 19 Dec 1996 12:24:58 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA08958; Thu, 19 Dec 1996 12:22:32 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id VAA16847; Thu, 19 Dec 1996 21:21:55 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id VAA01143; Thu, 19 Dec 1996 21:21:55 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id UAA00510; Thu, 19 Dec 1996 20:53:21 +0100 (MET) From: J Wunsch Message-Id: <199612191953.UAA00510@uriah.heep.sax.de> Subject: Re: 2.1.6 mandates a swap, I suggest it shouldn't To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Thu, 19 Dec 1996 20:53:20 +0100 (MET) Cc: jhs@FreeBSD.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199612190149.CAA16661@vector.jhs.no_domain> from "Julian H. Stacey" at "Dec 19, 96 02:49:56 am" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Julian H. Stacey wrote: > Reason I suggest we not mandate a swap: space. > I was installing a small disc without space for swap, > as I needed a little system up, for diagnosing other problems. Why didn't you simply put 100 KB or so swap only there? I don't think that running FreeBSD without swap makes any sense at all (i'm fairly confident that you'll experience randomly killed processes), but if you really think you should do this, then simply assign as few swap as you want. Of course, it would be better to devote the 80 MB disk entirely as swap space, and use another disk for the system. :) (My usual systems have between 100 and 200 MB swap for 32 MB RAM.) -- 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 Thu Dec 19 14:20:56 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA15916 for current-outgoing; Thu, 19 Dec 1996 14:20:56 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id OAA15907 for ; Thu, 19 Dec 1996 14:20:53 -0800 (PST) Received: by halloran-eldar.lcs.mit.edu; (5.65v3.2/1.1.8.2/19Aug95-0530PM) id AA20725; Thu, 19 Dec 1996 16:31:47 -0500 Date: Thu, 19 Dec 1996 16:31:47 -0500 From: Garrett Wollman Message-Id: <9612192131.AA20725@halloran-eldar.lcs.mit.edu> To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Cc: freebsd-current@freebsd.org (FreeBSD-current users) Subject: Re: 2.1.6 mandates a swap, I suggest it shouldn't In-Reply-To: <199612191953.UAA00510@uriah.heep.sax.de> References: <199612190149.CAA16661@vector.jhs.no_domain> <199612191953.UAA00510@uriah.heep.sax.de> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk < said: > Why didn't you simply put 100 KB or so swap only there? I don't think > that running FreeBSD without swap makes any sense at all (i'm fairly > confident that you'll experience randomly killed processes), but if > you really think you should do this, then simply assign as few swap as > you want. Depends on how much memory you have... wollman@khavrinen(44)$ swapinfo Device 1K-blocks Used Avail Capacity Type /dev/wd0b 36288 0 36224 0% Interleaved /dev/wd1b 49152 0 49088 0% Interleaved Total 85312 0 85312 0% Granted, the machine's not doing anything right now, but even when it does it rarely swaps since everything fits just fine in 40 MB of main memory. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, ANA, or NSA| - Susan Aglukark and Chad Irschick From owner-freebsd-current Thu Dec 19 15:51:37 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA20958 for current-outgoing; Thu, 19 Dec 1996 15:51:37 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id PAA20929 for ; Thu, 19 Dec 1996 15:51:08 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id AAA04209 for ; Fri, 20 Dec 1996 00:50:59 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA04672 for freebsd-current@FreeBSD.org; Fri, 20 Dec 1996 00:50:59 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id WAA01502 for freebsd-current@FreeBSD.org; Thu, 19 Dec 1996 22:23:12 +0100 (MET) From: J Wunsch Message-Id: <199612192123.WAA01502@uriah.heep.sax.de> Subject: Weird ARP behaviour? To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Thu, 19 Dec 1996 22:23:11 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Knowing that the `vx' driver in -current is supposed to be quite better operational than it used to be, i just tried to swap my Ethernet cards on the fly (on a totally non-busy) network. I've ifconfig delete'd the ed0 interface, and ifconfig'ed vx0. Seems i forgot to clear the old ARP entries, since when i tried to diskless boot my scratchbox (which used to stall immediately with the old vx driver), now i've got: Dec 19 21:32:28 uriah bootpd[1227]: set: can only proxy for 192.168.0.3 Dec 19 21:32:29 uriah bootpd[1227]: set: can only proxy for 192.168.0.3 Dec 19 21:32:29 uriah /kernel: arpresolve: can't allocate llinfo for 192.16 8.0.3 Dec 19 21:32:29 uriah /kernel: arpresolve: can't allocate llinfo for 192.16 8.0.3 Hmpf. Ok, revert everything to state 0, delete all ARP entries and other routes, delete all interfaces, and try to start over. Still nogo: tcpdump: listening on vx0 21:51:35.165310 0.0.0.0.0 > 255.255.255.255.bootps: (request) xid:0x23d51400 [|bootp] 21:51:35.166460 uriah.heep.sax.de.bootps > uncle.heep.sax.de.bootpc: xid:0x23d51400 Y:uncle.heep.sax.de S:uriah.heep.sax.de [|bootp] 21:51:35.242510 arp who-has uriah.heep.sax.de tell uncle.heep.sax.de 21:51:36.290547 arp who-has uriah.heep.sax.de tell uncle.heep.sax.de 21:51:37.389514 arp who-has uriah.heep.sax.de tell uncle.heep.sax.de For the curious who can interpret the following numbers: uriah # netstat -rAn Routing tables Internet: Address Destination Gateway Flags Refs Use Netif Expire f1477bcc (32) f1604218 : f14d4518 f1604218 (33) f1477bb4 : f1604200 f1477bb4 (root node) f1604200 127.0.0.1 127.0.0.1 UH 2 51 lo0 f14d4518 (34) f1494818 : f1477be4 f1494818 (62) f1555b18 : f1494800 mk = f14ce4c0 {(56), , (255) ffff ffff ff } f1555b18 (63) f14d4500 : f1555b00 f14d4500 192.168 link#1 UC 0 0 mask (255) ffff ffff ff mk = f14ce4c0 {(56), , (255) ffff ffff ff } f1555b00 192.168.0.1 127.0.0.1 UGHS 0 0 lo0 f1494800 192.168.0.3 0:0:c0:ac:d1:61 UHLW 1 5 vx0 1086 f1477be4 (root node) Seems i gotta reboot now. :-( -- 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 Fri Dec 20 11:55:08 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA05612 for current-outgoing; Fri, 20 Dec 1996 11:55:08 -0800 (PST) Received: from pegasus.my.domain (fish-13.ppp.hooked.net [206.80.10.13]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id LAA05560; Fri, 20 Dec 1996 11:54:57 -0800 (PST) From: dicen@hooked.net Received: from pegasus.my.domain (localhost.my.domain [127.0.0.1]) by pegasus.my.domain (8.8.4/8.7.3) with SMTP id LAA21794; Fri, 20 Dec 1996 11:55:10 GMT Message-ID: <32BA7E9E.41C67EA6@hooked.net> Date: Fri, 20 Dec 1996 11:55:10 +0000 X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Problems with make world. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk make world fails for me on both the 2.2 alpha release and the current release. Output..... cc -O2 -m486 -pipe -I/usr/src_stable/src/usr.bin/make -c /usr/src_stable/src/usr.bin/make/lst.lib/lstSucc.c cc -O2 -m486 -pipe -I/usr/src_stable/src/usr.bin/make -o make arch.o buf.o compat.o cond.o dir.o for.o hash.o job.o main.o make.o parse.o str.o suff.o targ.o var.o util.o lstAppend.o lstAtEnd.o lstAtFront.o lstClose.o lstConcat.o lstDatum.o lstDeQueue.o lstDestroy.o lstDupl.o lstEnQueue.o lstFind.o lstFindFrom.o lstFirst.o lstForEach.o lstForEachFrom.o lstInit.o lstInsert.o lstIsAtEnd.o lstIsEmpty.o lstLast.o lstMember.o lstNext.o lstOpen.o lstRemove.o lstReplace.o lstSucc.o install -c -s -o bin -g bin -m 555 make /usr/bin pwd: No such file or directory *** Error code 2 Stop. *** Error code 1 Stop. *** Error code 1 Stop. I have a link for /usr/src_stable/src to /usr/src. It would do this even when the source was in /usr/src so that is not the problem. There is no pattern when the "pwd: No such file or directory" shows up. My path includes /bin /usr/bin /sbin /usr/sbin /usr/local/bin /usr/local/sbin. I have looked through the mk files but this has stumped me for a while now. dicen From owner-freebsd-current Fri Dec 20 12:27:06 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA06689 for current-outgoing; Fri, 20 Dec 1996 12:27:06 -0800 (PST) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA06683 for ; Fri, 20 Dec 1996 12:27:01 -0800 (PST) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id PAA01194; Fri, 20 Dec 1996 15:24:39 -0500 From: Bill Paul Message-Id: <199612202024.PAA01194@skynet.ctr.columbia.edu> Subject: Re: tcsh NIS strangeness To: kuku@gilberto.physik.rwth-aachen.de Date: Fri, 20 Dec 1996 15:24:38 -0500 (EST) Cc: current@freebsd.org In-Reply-To: <199612200834.JAA03309@gilberto.physik.rwth-aachen.de> from "Christoph Kukulies" at Dec 20, 96 09:34:49 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Of all the gin joints in all the towns in all the world, Christoph Kukulies had to walk into mine and say: > > > > > Okay, well I just compiled tcsh 6.07.02 on my FreeBSD 2.2-ALPHA test > > box. It seems to work fine. For the record, I compiled it as follows: > > > > - Unpack archive > > - cd tcsh-6.07.02 > > - cp config/bsd4.4 config.h > > - vi Makefile.std (add -lcrypt to the LIBES line) > > - make -f Makefile.std > > I built it from ports, btw, and there are a bunch of patches, > most of them NLS related, one deals with .login .cshrc and one > with setpgrp/setpgid. Anyway, I'll try your binary. Yikes!!! I found the problem! Here's a patch: *** yplib.c.orig Fri Dec 20 14:37:49 1996 --- yplib.c Fri Dec 20 14:38:11 1996 *************** *** 79,84 **** --- 79,85 ---- int (*ypresp_allfn)(); void *ypresp_data; + static void _yp_unbind __P(( struct dom_binding * )); struct dom_binding *_ypbindlist; static char _yp_domain[MAXHOSTNAMELEN]; int _yplib_timeout = 10; *************** *** 230,236 **** ysd = _ypbindlist; while(ysd) { if(ysd->dom_client != NULL) ! clnt_destroy(ysd->dom_client); ysd2 = ysd->dom_pnext; free(ysd); ysd = ysd2; --- 231,237 ---- ysd = _ypbindlist; while(ysd) { if(ysd->dom_client != NULL) ! _yp_unbind(ysd); ysd2 = ysd->dom_pnext; free(ysd); ysd = ysd2; When ktracing ls, I noticed that the problem was that it couldn't write to stdout (descriptor 1). When you fork(), _yp_dobind() is supposed to invalidate all binding information in the child so as not to share descriptors with the parent. The trouble is that you have to be _very_ careful when you do this since the top level application may have have stepped on the cached socket descriptors. The _yp_unbind() function tests for this and deals with it, so that works, whereas summarily calling clnt_destroy() may destroy a descriptor that doesn't belong to us. I compiled a new tcsh with a replacment yplib.o that has this patch and put in in place of the old one on ftp.ctr.columbia.edu:/pub/misc/freebsd. If you can test it for me and confirm that it works, or apply the patch and build a new libc.so, I would appreciate it. I have already committed this patch to -current, but I want to make sure it fixes your problem before I put it in the 2.2 branch. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= From owner-freebsd-current Fri Dec 20 14:15:41 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA11741 for current-outgoing; Fri, 20 Dec 1996 14:15:41 -0800 (PST) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.116.240]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA11736 for ; Fri, 20 Dec 1996 14:15:36 -0800 (PST) Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-5/8.6.12) with ESMTP id XAA28532; Fri, 20 Dec 1996 23:17:20 +0100 (MET) Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.8.3/8.6.9) id XAA05368; Fri, 20 Dec 1996 23:31:02 +0100 (MET) From: Christoph Kukulies Message-Id: <199612202231.XAA05368@gilberto.physik.rwth-aachen.de> Subject: Re: tcsh NIS strangeness In-Reply-To: <199612202024.PAA01194@skynet.ctr.columbia.edu> from Bill Paul at "Dec 20, 96 03:24:38 pm" To: wpaul@skynet.ctr.columbia.edu (Bill Paul) Date: Fri, 20 Dec 1996 23:31:01 +0100 (MET) Cc: kuku@gilberto.physik.rwth-aachen.de, current@freebsd.org Reply-To: Christoph Kukulies X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [ yplib.c patch] > I compiled a new tcsh with a replacment yplib.o that has this patch and > put in in place of the old one on ftp.ctr.columbia.edu:/pub/misc/freebsd. > If you can test it for me and confirm that it works, or apply the patch I just downloaded it, and copied it over to the machine in question. Logged in (with old tcsh - the ports compiled one), ls ~jolitz - nothing. ./tcsh.6.07.02 bach> ls ~jolitz yep foo baz everything there. So did the 'un-ported' version of tcsh.6.07.02 as of yesterday which I grabbed from your site. > and build a new libc.so, I would appreciate it. I have already committed > this patch to -current, but I want to make sure it fixes your problem > before I put it in the 2.2 branch. I will build a new libc.so.3.0 right now and I'll put it up to the machine (which is 3.0 also and that NIX client machine I tested on). BTW, the tcsh.6.07.02 is a shared version, so it ran against the unpatched version of libc in the test above. > > -Bill > > -- > ============================================================================= > -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu > Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research > Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City > ============================================================================= > "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" > ============================================================================= > --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-current Fri Dec 20 15:00:08 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA13964 for current-outgoing; Fri, 20 Dec 1996 15:00:08 -0800 (PST) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id PAA13950 for ; Fri, 20 Dec 1996 15:00:02 -0800 (PST) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id RAA01382; Fri, 20 Dec 1996 17:57:45 -0500 From: Bill Paul Message-Id: <199612202257.RAA01382@skynet.ctr.columbia.edu> Subject: Re: tcsh NIS strangeness To: kuku@gilberto.physik.rwth-aachen.de Date: Fri, 20 Dec 1996 17:57:44 -0500 (EST) Cc: current@freebsd.org In-Reply-To: <199612202231.XAA05368@gilberto.physik.rwth-aachen.de> from "Christoph Kukulies" at Dec 20, 96 11:31:01 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Of all the gin joints in all the towns in all the world, Christoph Kukulies had to walk into mine and say: > [ yplib.c patch] > > > I compiled a new tcsh with a replacment yplib.o that has this patch and > > put in in place of the old one on ftp.ctr.columbia.edu:/pub/misc/freebsd. > > If you can test it for me and confirm that it works, or apply the patch > > I just downloaded it, and copied it over to the machine in question. > Logged in (with old tcsh - the ports compiled one), ls ~jolitz - nothing. > ./tcsh.6.07.02 > bach> ls ~jolitz > > yep foo baz > > everything there. So did the 'un-ported' version of tcsh.6.07.02 as of > yesterday which I grabbed from your site. Hm, I'm confused. Are you saying it works or are you saying it's still broken? :) The correct way to test it is to log in using the patched tcsh binary that I gave you as the default login shell. When I first reproduced the bug, I did it by logging in and typing ~ls someuser immediately before issuing any other commands. This pattern always held: each time I logged in, the bug would manifest. (As you noted, it goes away if you do a cd ~someuser later.) I tested the patched version by moving the broken /bin/tcsh to /bin/tcsh.bad and putting the new tcsh in place as /bin/tcsh. Then I logged out and logged back in again and tried to do an ls ~someuser again to duplicate the bug. With the patched version, the bug didn't show up and ls worked correctly. In other words, you need to really install the new tcsh and log in again in order to test the patch correctly: if you log in with the old broken tcsh and then run the same broken binary again, the bug will _appear_ to go away, but will really still be there and it will show up again the next time you log in. > > and build a new libc.so, I would appreciate it. I have already committed > > this patch to -current, but I want to make sure it fixes your problem > > before I put it in the 2.2 branch. > > I will build a new libc.so.3.0 right now and I'll put it up to the > machine (which is 3.0 also and that NIX client machine I tested on). > BTW, the tcsh.6.07.02 is a shared version, so it ran against the unpatched > version of libc in the test above. > In the patched version I gave you, I linked yplib.o directly into the executable which overrides the yplib.o in libc.so, so this binary should work no matter what. Once you generate a patched libc.so.3.0, then the other binary which you compiled (and the first binary I gave you via FTP) should also work correctly. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= From owner-freebsd-current Fri Dec 20 15:41:21 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA15536 for current-outgoing; Fri, 20 Dec 1996 15:41:21 -0800 (PST) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.116.240]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id PAA15531 for ; Fri, 20 Dec 1996 15:41:17 -0800 (PST) Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-5/8.6.12) with ESMTP id AAA29721; Sat, 21 Dec 1996 00:42:23 +0100 (MET) Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.8.3/8.6.9) id AAA00564; Sat, 21 Dec 1996 00:54:09 +0100 (MET) From: Christoph Kukulies Message-Id: <199612202354.AAA00564@gilberto.physik.rwth-aachen.de> Subject: Re: tcsh NIS strangeness In-Reply-To: <199612202257.RAA01382@skynet.ctr.columbia.edu> from Bill Paul at "Dec 20, 96 05:57:44 pm" To: wpaul@skynet.ctr.columbia.edu (Bill Paul) Date: Sat, 21 Dec 1996 00:54:08 +0100 (MET) Cc: kuku@gilberto.physik.rwth-aachen.de, current@freebsd.org Reply-To: Christoph Kukulies X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Of all the gin joints in all the towns in all the world, Christoph > Kukulies had to walk into mine and say: > > > [ yplib.c patch] > > > > > I compiled a new tcsh with a replacment yplib.o that has this patch and > > > put in in place of the old one on ftp.ctr.columbia.edu:/pub/misc/freebsd. > > > If you can test it for me and confirm that it works, or apply the patch > > > > I just downloaded it, and copied it over to the machine in question. > > Logged in (with old tcsh - the ports compiled one), ls ~jolitz - nothing. > > ./tcsh.6.07.02 > > bach> ls ~jolitz > > > > yep foo baz > > > > everything there. So did the 'un-ported' version of tcsh.6.07.02 as of > > yesterday which I grabbed from your site. > > Hm, I'm confused. Are you saying it works or are you saying it's still > broken? :) I mean - sorry - I tried both tcsh's (the one you compiled yesterday and the one with the same name I grabbed just a couple of hours before) And with both tcsh's I got correct behaviour. (That was befor I applied the libc patch) OTOH, I ,must say, I did not test it correctly. I sub spawned your tcsh from mine. That is - as you are saying - not correct. Say, is your tcsh compiled from ports? Or is it out of the box? > > The correct way to test it is to log in using the patched tcsh binary > that I gave you as the default login shell. When I first reproduced the > bug, I did it by logging in and typing ~ls someuser immediately before > issuing any other commands. This pattern always held: each time I logged > in, the bug would manifest. (As you noted, it goes away if you do a > cd ~someuser later.) > > I tested the patched version by moving the broken /bin/tcsh to /bin/tcsh.bad > and putting the new tcsh in place as /bin/tcsh. Then I logged out and > logged back in again and tried to do an ls ~someuser again to duplicate > the bug. With the patched version, the bug didn't show up and ls worked > correctly. > > In other words, you need to really install the new tcsh and log in > again in order to test the patch correctly: if you log in with the old > broken tcsh and then run the same broken binary again, the bug will _appear_ > to go away, but will really still be there and it will show up again > the next time you log in. > > > > and build a new libc.so, I would appreciate it. I have already committed > > > this patch to -current, but I want to make sure it fixes your problem > > > before I put it in the 2.2 branch. > > > > I will build a new libc.so.3.0 right now and I'll put it up to the > > machine (which is 3.0 also and that NIX client machine I tested on). > > BTW, the tcsh.6.07.02 is a shared version, so it ran against the unpatched > > version of libc in the test above. > > > > In the patched version I gave you, I linked yplib.o directly into the > executable which overrides the yplib.o in libc.so, so this binary should > work no matter what. Once you generate a patched libc.so.3.0, then the > other binary which you compiled (and the first binary I gave you via > FTP) should also work correctly. I see. > > -Bill > > -- > ============================================================================= > -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu > Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research > Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City > ============================================================================= > "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" > ============================================================================= > --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-current Fri Dec 20 16:38:09 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA17228 for current-outgoing; Fri, 20 Dec 1996 16:38:09 -0800 (PST) Received: from pegasus.my.domain (capt-4.ppp.hooked.net [206.80.9.132]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA17207; Fri, 20 Dec 1996 16:38:03 -0800 (PST) From: dicen@hooked.net Received: from pegasus.my.domain (localhost.my.domain [127.0.0.1]) by pegasus.my.domain (8.8.4/8.7.3) with SMTP id QAA24141; Fri, 20 Dec 1996 16:38:19 GMT Message-ID: <32BAC0FA.41C67EA6@hooked.net> Date: Fri, 20 Dec 1996 16:38:18 +0000 X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2-RELEASE i386) MIME-Version: 1.0 To: freebsd-questions@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Problems with make world. References: <32BA7E9E.41C67EA6@hooked.net> <32BAFADA.62D5@netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Manfred Antar wrote: > > i have the same problem.it started when /bin/sh was changed a few days > ago.if you have a backup over a week old of /bin/sh use it . > hope this helps > Manfred > -- > |==============================| > | mantar@netcom.com | > | Ph. (415) 681-6235 | > |==============================| Just wanted to let everyone know /bin/sh is why a make world in current fails. However, it seams to be okay in 2.2alpha now that I got a make world to work from current down to 2.2alpha. A simple fix is this. make -DSHELL=/usr/local/bin/bash world. dicen From owner-freebsd-current Fri Dec 20 16:41:54 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA17455 for current-outgoing; Fri, 20 Dec 1996 16:41:54 -0800 (PST) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA17447 for ; Fri, 20 Dec 1996 16:41:50 -0800 (PST) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id BAA16433 for ; Sat, 21 Dec 1996 01:41:41 +0100 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id BAA22303 for freebsd-current@freebsd.org; Sat, 21 Dec 1996 01:41:31 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.4/keltia-uucp-2.9) id BAA04513; Sat, 21 Dec 1996 01:38:04 +0100 (CET) Message-ID: Date: Sat, 21 Dec 1996 01:38:04 +0100 From: roberto@keltia.freenix.fr (Ollivier Robert) To: freebsd-current@freebsd.org Subject: Re: Problems with make world. References: <32BA7E9E.41C67EA6@hooked.net> X-Mailer: Mutt 0.54 Mime-Version: 1.0 X-Operating-System: FreeBSD 3.0-CURRENT ctm#2830 In-Reply-To: <32BA7E9E.41C67EA6@hooked.net>; from dicen@hooked.net on Dec 20, 1996 11:55:10 +0000 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to dicen@hooked.net: > pwd: No such file or directory > *** Error code 2 I think the problem is sh-related. The 4.4BSD-lite2 sh was merged a few days ago but it seems to cause more grief... -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #32: Thu Dec 19 20:47:10 CET 1996 From owner-freebsd-current Fri Dec 20 17:50:10 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA20179 for current-outgoing; Fri, 20 Dec 1996 17:50:10 -0800 (PST) Received: from fools.ecpnet.com (moke@fools.ecpnet.com [204.246.64.101]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA20174 for ; Fri, 20 Dec 1996 17:50:03 -0800 (PST) Received: from localhost (moke@localhost) by fools.ecpnet.com (8.8.4/8.8.4) with SMTP id TAA06765 for ; Fri, 20 Dec 1996 19:48:47 -0600 (CST) Date: Fri, 20 Dec 1996 19:48:47 -0600 (CST) From: Jimbo Bahooli To: freebsd-current@freebsd.org Subject: strange lpd related problem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am having a problem with lpd, when started from /etc/rc by saying lpd=YES in the sysconfig it refuses to print anything useful and leaves this log message: Dec 20 19:39:36 fools lpd[5755]: mail sent to user moke about job stdin on printer lp (FATALERR) But if I kill the lpd, or do not start it on boot up, and root starts it from a shell it works fine. Any ideas? anyone? From owner-freebsd-current Fri Dec 20 19:37:38 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id TAA23490 for current-outgoing; Fri, 20 Dec 1996 19:37:38 -0800 (PST) Received: from sdev.usn.blaze.net.au (sdev.usn.blaze.net.au [203.17.53.19]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id TAA23484 for ; Fri, 20 Dec 1996 19:37:29 -0800 (PST) Received: (from davidn@localhost) by sdev.usn.blaze.net.au (8.8.4/8.6.9) id OAA11485; Sat, 21 Dec 1996 14:36:51 +1100 (EST) Message-ID: Date: Sat, 21 Dec 1996 14:36:50 +1100 From: davidn@sdev.usn.blaze.net.au (David Nugent) To: wosch@cs.tu-berlin.de (Wolfram Schneider) Cc: current@freebsd.org, wpaul@frebsd.org.cs.tu-berlin.de Subject: Re: group(5) limits References: <199612170124.CAA02231@campa.panke.de> X-Mailer: Mutt 0.54 Mime-Version: 1.0 In-Reply-To: <199612170124.CAA02231@campa.panke.de>; from Wolfram Schneider on Dec 17, 1996 02:24:34 +0100 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Wolfram Schneider writes: > The current limit is 200 members per group or maximum 1024 character per > line. I changed getgrent(3) to use dynamic allocated buffers > instead static buffers. No member or line length limit anymore - > now 500 members or 5000 members are possible. Good (although it causes me some work too :-)). This was on my todo list. It would be nice if this supported line continuation as well, which I believe is already supported by NIS (at least in the netgroups file). Keeping lines below 1024 characters is kinder on manual management too. > @@ -207,6 +230,9 @@ > if (_gr_fp) { > (void)fclose(_gr_fp); > _gr_fp = NULL; > + free(line); > + free(members); > + maxlinelength = maxgrp = 0; > } > } After a brief glance (ie. nothing in depth and no testing), this however is broken. You can't deallocate that memory - it has to hang around because getgrnam() and getgruid() return group record with pointers to it AFTER calling endgrent(). Try running your code with /etc/malloc.conf -> AJ and using getgrent(). I fixed a similar bug in getttyent() a week ago. With these malloc options, getttynam() always returned junk, and without the usual side-effects when someone allocated/reused the freed block would appear. I'd suggest just leaving these three lines out. Subsequent calls to gr_start() will reuse the memory anyway and add a little to efficiency. Having the static array in spite of its limitations avoided this. BTW, is this a 2.2 candidate? Regards, David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freefall.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/ From owner-freebsd-current Fri Dec 20 22:39:20 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA28401 for current-outgoing; Fri, 20 Dec 1996 22:39:20 -0800 (PST) Received: from pegasus.my.domain (bass-23.ppp.hooked.net [206.80.8.87]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id WAA28377; Fri, 20 Dec 1996 22:39:13 -0800 (PST) From: dicen@hooked.net Received: from pegasus.my.domain (localhost.my.domain [127.0.0.1]) by pegasus.my.domain (8.8.4/8.7.3) with SMTP id WAA25823; Fri, 20 Dec 1996 22:39:30 GMT Message-ID: <32BB1559.41C67EA6@hooked.net> Date: Fri, 20 Dec 1996 22:39:30 +0000 X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2-RELEASE i386) MIME-Version: 1.0 To: freebsd-questions@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: User ppp not hanging up modem. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk User ppp not hanging up modem. This seams to be a real annoying problem that a number of people have in current and 2.2alpha. I have read some posts on usenet about it. In relase 2.10 and 2.1.5 user ppp would hang up my modem on either a timeout or when I did a close command. Now it does neither. My hardware is an external SupraFaxModem 14.4k V.32bis connected on com2 with a DB25 cable. The modem will hangup fine in Windoze 95 but not in current or 2.2alpha. Since my modem is externel I can just turn it off to close a connect. I can't imagine what people do with internel modems. My system is top of the line, no crappy motherboard here. I just spent nearly 3 hours debuging user ppp. I can't find anything wrong with it. In ppp/modem.c HangupModem is called with the right argument value (flag) and as far as I can tell it is executing the code in the if then else blocks. However, it does appear the code has been changed (since the author) to make -dedicated ppp, which doesn't seam to work when you turn it on. There are comments in the function /* XXX */. I have sean that in the kernel code. Must be a call sign. To close the modem connection HangupModem calls close() (of course) and a number of termios routines. Man I hate termios. I haven't look in my Advanced Programming in the .... (Stevens book), the bible yet to figure out what they do. Have the libraries been touched? The termios stuff could be bugged. I need to add here that some peoples modems may be hanging up like they should. According to the logs and my debugging, user ppp is closing the ppp connection it just isn't hanging up the modem. If you have an Isp (I don't, but I used to) that is nice enough to hangup it's modem then yours will hangup too. I feel that this is something critical. Users with internel modems will not be able to terminate a connection without unpluging the modem cable from the back of their computers. dicen From owner-freebsd-current Fri Dec 20 23:50:49 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA01058 for current-outgoing; Fri, 20 Dec 1996 23:50:49 -0800 (PST) Received: from sequent.kiae.su (sequent.kiae.su [193.125.152.6]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id XAA01053; Fri, 20 Dec 1996 23:50:45 -0800 (PST) Received: by sequent.kiae.su id AA22808 (5.65.kiae-2 ); Sat, 21 Dec 1996 11:39:21 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Sat, 21 Dec 96 11:39:20 +0400 Received: from localhost (nagual.ru [127.0.0.1]) by nagual.ru (8.8.4/8.8.4) with SMTP id KAA02210; Sat, 21 Dec 1996 10:38:46 +0300 (MSK) Date: Sat, 21 Dec 1996 10:38:45 +0300 (MSK) From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7=2C_Andrey_Chernov?= To: FreeBSD-current , fenner@freebsd.org Subject: mtest: overloaded name, name change request Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk There is too many 'mtest' programms in the world, could we rename recently commited one to something like 'mrtest' or 'mmtest'? We have conflict with both mtools and pine... -- Andrey A. Chernov http://www.nagual.ru/~ache/ From owner-freebsd-current Fri Dec 20 23:51:14 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA01120 for current-outgoing; Fri, 20 Dec 1996 23:51:14 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id XAA01113 for ; Fri, 20 Dec 1996 23:51:11 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA01559; Sat, 21 Dec 1996 08:51:01 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA00853; Sat, 21 Dec 1996 08:51:00 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id IAA10113; Sat, 21 Dec 1996 08:47:48 +0100 (MET) From: J Wunsch Message-Id: <199612210747.IAA10113@uriah.heep.sax.de> Subject: Re: Problems with make world. To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sat, 21 Dec 1996 08:47:48 +0100 (MET) Cc: dicen@hooked.net, sprice@hiwaay.net (Steve Price) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <32BAC0FA.41C67EA6@hooked.net> from "dicen@hooked.net" at "Dec 20, 96 04:38:18 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As dicen@hooked.net wrote: > Just wanted to let everyone know /bin/sh is why a make world in current > fails. However, it seams to be okay in 2.2alpha now that I got a make > world to work from current down to 2.2alpha. Can you verify that exchaning both shell binaries works? Or is it rather that swapping kernels was it? Btw., Steve, i think exec'ing /bin/pwd is a heavy overhead that gains nothing. The shell should call getcwd(3). That's basically what pwd(1) actually does. (I assume the reason why the shell wanted to be `smarter' is that getcwd(3) used to be implemented in terms of calling pwd(1) for quite many systems in the past.) -- 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 Sat Dec 21 01:12:12 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA02844 for current-outgoing; Sat, 21 Dec 1996 01:12:12 -0800 (PST) Received: from grackle.grondar.za (+aDOEBKxwRuJKt0PnCCEn966ba+0ILmg@grackle.grondar.za [196.7.18.131]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id BAA02833 for ; Sat, 21 Dec 1996 01:12:06 -0800 (PST) Received: from grackle.grondar.za (QRM7QW8PFDUkn68uYve2XS4BMmJoc0Ak@localhost [127.0.0.1]) by grackle.grondar.za (8.8.4/8.8.4) with ESMTP id LAA00719; Sat, 21 Dec 1996 11:11:51 +0200 (SAT) Message-Id: <199612210911.LAA00719@grackle.grondar.za> X-Mailer: exmh version 1.6.9 8/22/96 To: current@freebsd.org cc: mark@grondar.za Subject: Confused about locale X-Face: "=q0"STs_81w9y4&#}>]hpQ-VBL.1^,QB{9u[05?&^k1*y#*OpIkS7b?V0Rs8qg]`Z}LBTa JT}q{S+z%%SR{~1@;Ybho~Ck.)PC/#3$lceQZ`O Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi I am trying to "internationalise" my machine. Seeing that Andrey has his name in cyrillic,and various other people have ISO charaters in sigs, I thought I'd try to join the game. I'm having some luck, but not much. I use MH for mail, and in the body of mail items I can see the ISO charaters, and sometimes Cyrillic/Japanese get turned into ISO-chars-with-punctuation. There seems to be a lack of documentation and/or standards. I am utter confused as to the difference between locale and NLS, and the difference between the files in /usr/share/locale, /usr/local/share/nls and /usr/X11R6/lib/X11/locale I have the following environment variables set: LANG=en_US.ISO8859-1 LC_CTYPE=iso_8859_1 MM_CHARSET=iso-8859-1 (some of which I got from PST's patch for MIME headers in MH, and some of which I have just been playing with.) Problems: Various programs screw up with this, Ie Netscape: netscape.bin: locale `iso_8859_1' not supported by Xlib; trying `C'. (I've seen this on other programs, but I can't remember which right now). MH/EXMH - still do not translate MIME headers. (In the body I get an error that fonts are unavailable - which is BS) Any clues? M -- Mark Murray PGP key fingerprint = 80 36 6E 40 83 D6 8A 36 This .sig is umop ap!sdn. BC 06 EA 0E 7A F2 CE CE From owner-freebsd-current Sat Dec 21 03:19:32 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id DAA05253 for current-outgoing; Sat, 21 Dec 1996 03:19:32 -0800 (PST) Received: from vector.jhs.no_domain (slip139-92-4-200.mu.de.ibm.net [139.92.4.200]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id DAA05243; Sat, 21 Dec 1996 03:18:41 -0800 (PST) Received: from vector.jhs.no_domain (localhost [127.0.0.1]) by vector.jhs.no_domain (8.7.5/8.6.9) with ESMTP id PAA00882; Fri, 20 Dec 1996 15:07:57 +0100 (MET) Message-Id: <199612201407.PAA00882@vector.jhs.no_domain> To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: freebsd-current@FreeBSD.org (FreeBSD-current users) Subject: Re: 2.1.6 mandates a swap, I suggest it shouldn't From: "Julian H. Stacey" Reply-To: "Julian H. Stacey" X-Organization: Vector Systems Ltd. X-Mailer: EXMH 1.6.7, PGP available X-Address: Holz Strasse 27d, 80469 Munich, Germany X-Phone: +49.89.268616 X-Fax: +49.89.2608126 X-ISDN: +49.89.26023276 X-Web: http://www.freebsd.org/~jhs/ In-reply-to: Your message of "Thu, 19 Dec 1996 20:53:20 +0100." <199612191953.UAA00510@uriah.heep.sax.de> Date: Fri, 20 Dec 1996 15:07:57 +0100 Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi, Reference: > From: J Wunsch > Reply-to: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) > Subject: Re: 2.1.6 mandates a swap, I suggest it shouldn't > Date: Thu, 19 Dec 1996 20:53:20 +0100 (MET) > Message-id: <199612191953.UAA00510@uriah.heep.sax.de> > > As Julian H. Stacey wrote: > > > Reason I suggest we not mandate a swap: space. > > I was installing a small disc without space for swap, > > as I needed a little system up, for diagnosing other problems. > > Why didn't you simply put 100 KB or so swap only there? Tried, but failed, can't remember why, think it was too small for install's taste, or hit end of disk. > I don't think > that running FreeBSD without swap makes any sense at all Agreed for normal use , but it beats a Fixit Flop by 80M:1.4M :-) > (i'm fairly > confident that you'll experience randomly killed processes), but if > you really think you should do this, then simply assign as few swap as > you want. I did :-) I built an 80M disc with A partition = entire disc, & no FDISK stuff & no swap. Boots fine on my old box :-) ... But , fails to boot on the new box, meaning I have some hardware prob. to solve there :-( > Of course, it would be better to devote the 80 MB disk entirely as > swap space, and use another disk for the system. :) (My usual systems > have between 100 and 200 MB swap for 32 MB RAM.) Sure, in fact its a slow 80M drive so I won't even swap on it, it'll stay as a rescue Fixit Winch. I have a full Gig IDE drive waiting for the new box, but the problem is I can't boot off either SCSI or IDE on that box ... Dunno .. I'm thinking about it ... & there's another mail thread on it. Julian -- Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/ From owner-freebsd-current Sat Dec 21 06:04:32 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA10570 for current-outgoing; Sat, 21 Dec 1996 06:04:32 -0800 (PST) Received: from sovcom.kiae.su (sovcom.kiae.su [193.125.152.1]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id GAA10565 for ; Sat, 21 Dec 1996 06:04:27 -0800 (PST) Received: by sovcom.kiae.su id AA09727 (5.65.kiae-1 ); Sat, 21 Dec 1996 16:40:56 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Sat, 21 Dec 96 16:40:56 +0300 Received: from localhost (nagual.ru [127.0.0.1]) by nagual.ru (8.8.4/8.8.4) with SMTP id QAA00357; Sat, 21 Dec 1996 16:38:39 +0300 (MSK) Date: Sat, 21 Dec 1996 16:38:38 +0300 (MSK) From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7=2C_Andrey_Chernov?= To: Mark Murray Cc: current@freebsd.org Subject: Re: Confused about locale In-Reply-To: <199612210911.LAA00719@grackle.grondar.za> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 21 Dec 1996, Mark Murray wrote: > LANG=en_US.ISO8859-1 Wrong name, must be en_US.ISO_8859-1 > LC_CTYPE=iso_8859_1 Not needed when LANG is set. Wrong name, must be en_US.ISO_8859-1 too > MM_CHARSET=iso-8859-1 This one is right. > Netscape: > netscape.bin: locale `iso_8859_1' not supported by Xlib; trying `C'. > (I've seen this on other programs, but I can't remember which right now). Doesn't matter, netscape use X11R5 nls which is not supported anymore by X11. > MH/EXMH - still do not translate MIME headers. (In the body I get an error > that fonts are unavailable - which is BS) -- Andrey A. Chernov http://www.nagual.ru/~ache/ From owner-freebsd-current Sat Dec 21 06:49:29 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA11426 for current-outgoing; Sat, 21 Dec 1996 06:49:29 -0800 (PST) Received: from sdev.usn.blaze.net.au (sdev.usn.blaze.net.au [203.17.53.19]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id GAA11418 for ; Sat, 21 Dec 1996 06:49:24 -0800 (PST) Received: (from davidn@localhost) by sdev.usn.blaze.net.au (8.8.4/8.6.9) id BAA14805; Sun, 22 Dec 1996 01:49:10 +1100 (EST) Message-ID: Date: Sun, 22 Dec 1996 01:49:09 +1100 From: davidn@sdev.usn.blaze.net.au (David Nugent) To: ache@nagual.ru Cc: freebsd-current@freebsd.org Subject: Re: Confused about locale References: <199612210911.LAA00719@grackle.grondar.za> X-Mailer: Mutt 0.54 Mime-Version: 1.0 In-Reply-To: ; from ????????????????????????????? on Dec 21, 1996 16:38:38 +0300 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > LANG=en_US.ISO8859-1 > > Wrong name, must be en_US.ISO_8859-1 On the subject of locale, in an email discussion Joerg and I were having a couple of weeks back, the idea of a "system default" locale was raised (which, currently, FreeBSD does not have). I thought a simple solution may be a symlink or two in /etc (eg. /etc/LANG and /etc/NLS) pointing to the correct location under /usr/share/locale and /usr/share/nls may be the easiest way this could be implemented. These may be overridden by using the appropriate environment variables, but are the default when none is set (unlike now, where 'ascii' and 'C' are always the default). I think this would create a much better default environment for the system all 'round. I haven't yet looked into what changes may be involved, but they should be small and confined entirely (afaik) to libc. Regards, David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freefall.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/ From owner-freebsd-current Sat Dec 21 07:05:28 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA12143 for current-outgoing; Sat, 21 Dec 1996 07:05:28 -0800 (PST) Received: from po1.glue.umd.edu (root@po1.glue.umd.edu [129.2.128.44]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id HAA12123; Sat, 21 Dec 1996 07:05:24 -0800 (PST) Received: from professor.eng.umd.edu (professor.eng.umd.edu [129.2.103.23]) by po1.glue.umd.edu (8.8.3/8.7.3) with ESMTP id KAA00896; Sat, 21 Dec 1996 10:05:21 -0500 (EST) Received: from localhost (chuckr@localhost) by professor.eng.umd.edu (8.8.3/8.7.3) with SMTP id KAA07408; Sat, 21 Dec 1996 10:05:21 -0500 (EST) X-Authentication-Warning: professor.eng.umd.edu: chuckr owned process doing -bs Date: Sat, 21 Dec 1996 10:05:21 -0500 (EST) From: Chuck Robey X-Sender: chuckr@professor.eng.umd.edu To: dicen@hooked.net cc: freebsd-questions@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: User ppp not hanging up modem. In-Reply-To: <32BB1559.41C67EA6@hooked.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 20 Dec 1996 dicen@hooked.net wrote: > User ppp not hanging up modem. > > This seams to be a real annoying problem that a number of people have in > current and 2.2alpha. I have read some posts on usenet about it. In > relase 2.10 and 2.1.5 user ppp would hang up my modem on either a > timeout or when I did a close command. Now it does neither. > > My hardware is an external SupraFaxModem 14.4k V.32bis connected on com2 > with a DB25 cable. The modem will hangup fine in Windoze 95 but not in > current or 2.2alpha. Since my modem is externel I can just turn it off > to close a connect. I can't imagine what people do with internel modems. > My system is top of the line, no crappy motherboard here. > > I just spent nearly 3 hours debuging user ppp. I can't find anything > wrong with it. In ppp/modem.c HangupModem is called with the right > argument value (flag) and as far as I can tell it is executing the code > in the if then else blocks. However, it does appear the code has been > changed (since the author) to make -dedicated ppp, which doesn't seam to > work when you turn it on. There are comments in the function /* XXX */. > I have sean that in the kernel code. Must be a call sign. > > To close the modem connection HangupModem calls close() (of course) and > a number of termios routines. Man I hate termios. I haven't look in my > Advanced Programming in the .... (Stevens book), the bible yet to figure > out what they do. Have the libraries been touched? The termios stuff > could be bugged. > > I need to add here that some peoples modems may be hanging up like they > should. According to the logs and my debugging, user ppp is closing the > ppp connection it just isn't hanging up the modem. If you have an Isp (I > don't, but I used to) that is nice enough to hangup it's modem then > yours will hangup too. > > I feel that this is something critical. Users with internel modems will > not be able to terminate a connection without unpluging the modem cable > from the back of their computers. It hangs up fine for me, so what's the differences ... are you using DTR to hang up with? ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-current Sat Dec 21 07:07:18 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA12341 for current-outgoing; Sat, 21 Dec 1996 07:07:18 -0800 (PST) Received: from sdev.usn.blaze.net.au (sdev.usn.blaze.net.au [203.17.53.19]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id HAA12331 for ; Sat, 21 Dec 1996 07:07:10 -0800 (PST) Received: (from davidn@localhost) by sdev.usn.blaze.net.au (8.8.4/8.6.9) id CAA14903; Sun, 22 Dec 1996 02:07:08 +1100 (EST) Message-ID: Date: Sun, 22 Dec 1996 02:07:08 +1100 From: davidn@sdev.usn.blaze.net.au (David Nugent) To: freebsd-current@freebsd.org Subject: netstat -i X-Mailer: Mutt 0.54 Mime-Version: 1.0 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk -current as of last Wednesday: FreeBSD server.blaze.net.au 3.0-CURRENT FreeBSD 3.0-CURRENT #11: Wed Dec 18 20:52:46 EST 1996 davidn@server.blaze.net.au:/usr/src/sys/compile/SERVER i386 netstat -i reports: Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll ed0* 0 00.40.c7.21.ce.74 10000000 933493 0 965262 0 ed0* 0 255.255.255&0 server 10000000 933493 0 965262 0 sl0* 0 57600 15125 0 17320 0 sl0 0 0 0 0 0 0 sl0* 0 0 0 0 0 0 [...] ppp0* 0 38400 274592 0 253373 0 ppp0* 0 255.255.255&0 server 38400 274592 0 253373 0 ppp0 0 57600 249222 28 251743 0 ppp0 0 255.255.255&0 server 57600 249222 28 251743 0 ppp0* 0 57600 145389 22 131347 0 ppp0 0 57600 81476 5 77418 0 ppp0 0 255.255.255&0 server 57600 81476 5 77418 0 ppp0* 0 57600 98785 3 93338 0 ppp0 0 57600 39057 12 35701 0 ppp0* 0 57600 22623 1 20365 0 ppp0 0 57600 12720 1 12300 0 ppp0* 0 57600 15895 0 15328 0 ppp0 0 57600 5407 0 5563 0 ppp0* 0 57600 677 0 589 0 [....] lo0* 0 0 49156 0 49156 0 lo0* 0 your-net&0x7f local 0 49156 0 49156 0 This is running a kernel configured with an ethernet card, 4 slip units, 32 ppp units and loopback. Obviously the unit numbers are wrong, and why the lines are duplicated is a mystery. Certainly the statistics are way wrong, or at least in the wrong column. Perhaps the printf() statement is just misaligned? On another box, FreeBSD sdev.usn.blaze.net.au 3.0-CURRENT FreeBSD 3.0-CURRENT #0: Wed Dec 11 13:58:59 EST 1996 root@sdev.usn.blaze.net.au:/usr/src/sys/compile/SDEV i386 running a kernel a couple of weeks older configured with 4 ppp devices, 2 slip, ethernet, and loopback, netstat -i looks fine. Regards, David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freefall.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/ From owner-freebsd-current Sat Dec 21 08:02:43 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA14793 for current-outgoing; Sat, 21 Dec 1996 08:02:43 -0800 (PST) Received: from sovcom.kiae.su (sovcom.kiae.su [193.125.152.1]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id IAA14782 for ; Sat, 21 Dec 1996 08:02:39 -0800 (PST) Received: by sovcom.kiae.su id AA08941 (5.65.kiae-1 ); Sat, 21 Dec 1996 18:43:33 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Sat, 21 Dec 96 18:43:32 +0300 Received: from localhost (nagual.ru [127.0.0.1]) by nagual.ru (8.8.4/8.8.4) with SMTP id SAA00647; Sat, 21 Dec 1996 18:30:16 +0300 (MSK) Date: Sat, 21 Dec 1996 18:30:16 +0300 (MSK) From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7=2C_Andrey_Chernov?= To: David Nugent Cc: freebsd-current@freebsd.org Subject: Re: Confused about locale In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 22 Dec 1996, David Nugent wrote: > On the subject of locale, in an email discussion Joerg and I were > having a couple of weeks back, the idea of a "system default" > locale was raised (which, currently, FreeBSD does not have). > I thought a simple solution may be a symlink or two in /etc > (eg. /etc/LANG and /etc/NLS) pointing to the correct location > under /usr/share/locale and /usr/share/nls may be the easiest > way this could be implemented. These may be overridden by using > the appropriate environment variables, but are the default > when none is set (unlike now, where 'ascii' and 'C' are always > the default). About proposed implementation: /etc/LANG breaks POSIX. POSIX describes behaviour with and without environment variables exactly and specify default as "C" without env. variables, so env. variables must exists in any case. Moreover some shell scripts (nroff f.e.) especially test for certain locale env. variables presence, so no /etc/* things, env. variables only. About idea: I dislike idea of "system default" locale, I like idea of "user default" locale instead! It is no purpose to keep "system default" locale, all daemons must run at standard "C" locale. Basically you can have users from several countries in your system or maybe one country users with different tastes. There is bad thing to force them to "system default" locale. Of course, you can override that by "user default" locale, but I don't see a reason to keep "system default" locale in this case too. There must be some field into passwd which indicates current user startup locale which must be changeable by user via chpass. You can set default user locale in adduser or pw command to match majority of users on your machine. Login set LANG and MM_CHARSET env. variables according to passwd field. > I haven't yet looked into what changes may be involved, but > they should be small and confined entirely (afaik) to libc. It is a very big mistake to run daemons with any locale != "C", some of them can even call setlocale(...,"") or check "LANG", etc variables, X11 f.e. -- Andrey A. Chernov http://www.nagual.ru/~ache/ From owner-freebsd-current Sat Dec 21 08:48:11 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA15979 for current-outgoing; Sat, 21 Dec 1996 08:48:11 -0800 (PST) Received: from sdev.usn.blaze.net.au (sdev.usn.blaze.net.au [203.17.53.19]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id IAA15965 for ; Sat, 21 Dec 1996 08:47:59 -0800 (PST) Received: (from davidn@localhost) by sdev.usn.blaze.net.au (8.8.4/8.6.9) id DAA15004; Sun, 22 Dec 1996 03:47:44 +1100 (EST) Message-ID: Date: Sun, 22 Dec 1996 03:47:44 +1100 From: davidn@sdev.usn.blaze.net.au (David Nugent) To: ache@nagual.ru Cc: freebsd-current@freebsd.org Subject: Re: Confused about locale References: X-Mailer: Mutt 0.54 Mime-Version: 1.0 In-Reply-To: ; from ????????????????????????????? on Dec 21, 1996 18:30:16 +0300 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > About proposed implementation: > /etc/LANG breaks POSIX. POSIX describes behaviour with and without > environment variables exactly and specify default as "C" without > env. variables, so env. variables must exists in any case. Drats. :-) > About idea: > I dislike idea of "system default" locale, I like idea of "user > default" locale instead! Ok. There will be a way of achieving this shortly via login.conf. > There must be some field into passwd which indicates current user > startup locale which must be changeable by user via chpass. The last part is more difficult. But the field is already there in "class". > > I haven't yet looked into what changes may be involved, but > > they should be small and confined entirely (afaik) to libc. > > It is a very big mistake to run daemons with any locale != "C", > some of them can even call setlocale(...,"") or check "LANG", etc > variables, X11 f.e. Ok, thanks for the feedback. Regards, David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freefall.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/ From owner-freebsd-current Sat Dec 21 09:14:20 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA16548 for current-outgoing; Sat, 21 Dec 1996 09:14:20 -0800 (PST) Received: from pegasus.my.domain (tuna-41.ppp.hooked.net [206.80.8.169]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id JAA16523; Sat, 21 Dec 1996 09:14:14 -0800 (PST) From: dicen@hooked.net Received: from pegasus.my.domain (localhost.my.domain [127.0.0.1]) by pegasus.my.domain (8.8.4/8.7.3) with SMTP id JAA00210; Sat, 21 Dec 1996 09:05:35 GMT Message-ID: <32BBA85F.41C67EA6@hooked.net> Date: Sat, 21 Dec 1996 09:05:35 +0000 X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2-RELEASE i386) MIME-Version: 1.0 To: Chuck Robey CC: freebsd-questions@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: User ppp not hanging up modem. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Okay I have an update on the modem. My modem is a SupraFaxModem 14.4k V.32bis externel sold for Macs. I got it not because I used to have a mac but because I needed that type of cable it came with. This modem is set by default not to do anything on a DTR transition. To hang it up you do the correct thing which is escape with "+++" and then execute ATH. User ppp only seams to cut the DTR. So I have now set the modem to be a PC type which will go into command state with a DTR transition. This introduces other problems. Since cutting DTR now doesn't reset the state of the modem, it just hangs it up, doing a redial right after will not work. You have to wait a couple seconds. I can issue special commands to the modem to fix this but these commands are not standard. Actually my modem practicaly has an OS in it, it is so complex. This really needs to be put in the FAQ. I would rather have an escape done "+++" and the an ATH to hang up the modem but atleast it works now. Is this code in the termios library? I haven't look in my books yet. I am posting this to questions, current and stable becuase it applies to all of them. You can configure majordomo not to send duplicate emails for different mail lists. It isn't that hard. Thanks for the help. dicen From owner-freebsd-current Sat Dec 21 09:51:42 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA18115 for current-outgoing; Sat, 21 Dec 1996 09:51:42 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id JAA18096; Sat, 21 Dec 1996 09:51:36 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id KAA27123; Sat, 21 Dec 1996 10:51:29 -0700 (MST) Date: Sat, 21 Dec 1996 10:51:29 -0700 (MST) Message-Id: <199612211751.KAA27123@rocky.mt.sri.com> From: Nate Williams To: dicen@hooked.net Cc: Chuck Robey , freebsd-questions@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: User ppp not hanging up modem. In-Reply-To: <32BBA85F.41C67EA6@hooked.net> References: <32BBA85F.41C67EA6@hooked.net> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Okay I have an update on the modem. My modem is a SupraFaxModem 14.4k > V.32bis externel sold for Macs. I got it not because I used to have a > mac but because I needed that type of cable it came with. This modem is > set by default not to do anything on a DTR transition. To hang it up you > do the correct thing which is escape with "+++" and then execute ATH. > User ppp only seams to cut the DTR. That's *NOT* the correct thing. What happens when for some reason PPP happens to send the sequence '+++' to the modem? All of a sudden it'll drop into command mode and you're screwed. User-PPP (as well as all other PPP/SLIP implementations I've worked with) assumes that you've disabled the escape sequence at least temporarily. > So I have now set the modem to be a PC type which will go into command > state with a DTR transition. This introduces other problems. Since > cutting DTR now doesn't reset the state of the modem, it just hangs it > up, doing a redial right after will not work. You have to wait a couple > seconds. Umm, what's wrong with 'waiting' a couple of seconds? If the line goes down you should wait for the other end to clean up in any case, simply because you never know what caused the line to go down, and waiting 5-20 seconds might clear it up and allow you connect up the next time w/out having to retry. > I can issue special commands to the modem to fix this but these > commands are not standard. Actually my modem practicaly has an OS in > it, it is so complex. Umm, *every* modem that has been sold in the last couple years has the ability to reset itself when DTR goes low. That includes a *really* old Telebit modem from the late 80's or early 90's. > This really needs to be put in the FAQ. I would rather have an escape > done "+++" and the an ATH to hang up the modem but atleast it works now. > Is this code in the termios library? I haven't look in my books yet. This code isn't in any 'unix-like' system program that I'm aware of. The standard practice on unix machines 'since time began' has been to reset when DTR goes low. Most of this *is* already documented in the FreeBSD handbook. Nate From owner-freebsd-current Sat Dec 21 09:51:47 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA18149 for current-outgoing; Sat, 21 Dec 1996 09:51:47 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id JAA18094 for ; Sat, 21 Dec 1996 09:51:25 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id SAA22213; Sat, 21 Dec 1996 18:51:08 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id SAA09640; Sat, 21 Dec 1996 18:51:02 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id SAA11226; Sat, 21 Dec 1996 18:35:24 +0100 (MET) From: J Wunsch Message-Id: <199612211735.SAA11226@uriah.heep.sax.de> Subject: Re: User ppp not hanging up modem. To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sat, 21 Dec 1996 18:35:24 +0100 (MET) Cc: dicen@hooked.net Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <32BB1559.41C67EA6@hooked.net> from "dicen@hooked.net" at "Dec 20, 96 10:39:30 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As dicen@hooked.net wrote: > User ppp not hanging up modem. > > This seams to be a real annoying problem that a number of people have in > current and 2.2alpha. I have read some posts on usenet about it. In > relase 2.10 and 2.1.5 user ppp would hang up my modem on either a > timeout or when I did a close command. Now it does neither. Interesting. I'm using IIJPPP a lot (for dialout), and never experienced _this_ problem. (Don't get me wrong, IIJPPP is full of problems, i know it.) Maybe this is since i'm locking `hupcl' on the underlying tty device? j@uriah 350% cat /etc/rc.serial stty -f /dev/cuala1 crtscts hupcl stty -f /dev/cuaia1 crtscts stty -f /dev/ttyld1 crtscts hupcl stty -f /dev/ttyid1 crtscts Can you try this and see if it changes the behaviour? -- 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 Sat Dec 21 09:53:08 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA18257 for current-outgoing; Sat, 21 Dec 1996 09:53:08 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id JAA18247 for ; Sat, 21 Dec 1996 09:52:58 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id SAA22219 for ; Sat, 21 Dec 1996 18:51:09 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id SAA09650 for freebsd-current@FreeBSD.org; Sat, 21 Dec 1996 18:51:09 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id SAA11294 for freebsd-current@FreeBSD.org; Sat, 21 Dec 1996 18:44:39 +0100 (MET) From: J Wunsch Message-Id: <199612211744.SAA11294@uriah.heep.sax.de> Subject: Re: group(5) limits To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sat, 21 Dec 1996 18:44:39 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from David Nugent at "Dec 21, 96 02:36:50 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As David Nugent wrote: > Try running your code with /etc/malloc.conf -> AJ and using getgrent(). > I fixed a similar bug in getttyent() a week ago. With these malloc > options, getttynam() always returned junk, and without the usual > side-effects when someone allocated/reused the freed block would > appear. I should note that the getttyent() bug has been introduced by me on a similar occasion, when replacing the static line buffer for ttys(5) by a dynamically allocated one. (I.e., it's not a genuine 4.4BSD bug.) > I'd suggest just leaving these three lines out. This turned out to be the best sollution for ttyname() as well. Both files, ttys(5) and group(5) tend to change only slowly, so it's a win in the end to reuse the buffer. > BTW, is this a 2.2 candidate? Hardly. It's not even committed to the HEAD yet, and as you've just proven, still might experience bugs. The problem with this kind of fixes is that they are naturally rather bug fixes than feature enhancements, but for any release cycle, you gotta draw the line somewhere. The BETA is due on sunday, so this submission will likely miss the deadline for this time. Don't panic, the next release will come for sure, and it's certainly a candidate for 2.2-stable later. -- 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 Sat Dec 21 09:58:27 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA18586 for current-outgoing; Sat, 21 Dec 1996 09:58:27 -0800 (PST) Received: from pegasus.my.domain (tuna-41.ppp.hooked.net [206.80.8.169]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id JAA18566; Sat, 21 Dec 1996 09:58:21 -0800 (PST) From: dicen@hooked.net Received: from pegasus.my.domain (localhost.my.domain [127.0.0.1]) by pegasus.my.domain (8.8.4/8.7.3) with SMTP id JAA16625; Sat, 21 Dec 1996 09:58:25 GMT Message-ID: <32BBB4C1.794BDF32@hooked.net> Date: Sat, 21 Dec 1996 09:58:25 +0000 X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2-RELEASE i386) MIME-Version: 1.0 To: Nate Williams CC: Chuck Robey , freebsd-questions@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: User ppp not hanging up modem. References: <32BBA85F.41C67EA6@hooked.net> <199612211751.KAA27123@rocky.mt.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Nate Williams wrote: > > That's *NOT* the correct thing. What happens when for some reason > PPP happens to send the sequence '+++' to the modem? All of a sudden > it'll drop into command mode and you're screwed. User-PPP (as well as > all other PPP/SLIP implementations I've worked with) assumes that you've > disabled the escape sequence at least temporarily. > Interesting. But, what exactly is the prabobalitity of that? I will have think about this one. > Most of this *is* already documented in the FreeBSD handbook. > > Nate Nope. Nope. Nope. I have look through the entire /usr/share/doc tree and didn't find anything about ppp not hanging up modems, etc.. Someone please put this in the FAQ. I have read usenet posts about this one. Other people are going through the hell I did. I don't like spending hours debuging code only to discover the code is fine and my modem is misconfigured (sure I should have thought of it first). dicen From owner-freebsd-current Sat Dec 21 10:03:25 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA18992 for current-outgoing; Sat, 21 Dec 1996 10:03:25 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id KAA18987 for ; Sat, 21 Dec 1996 10:03:23 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id LAA27167; Sat, 21 Dec 1996 11:03:20 -0700 (MST) Date: Sat, 21 Dec 1996 11:03:20 -0700 (MST) Message-Id: <199612211803.LAA27167@rocky.mt.sri.com> From: Nate Williams To: dicen@hooked.net Cc: Nate Williams , freebsd-current@freebsd.org Subject: Re: User ppp not hanging up modem. In-Reply-To: <32BBB4C1.794BDF32@hooked.net> References: <32BBA85F.41C67EA6@hooked.net> <199612211751.KAA27123@rocky.mt.sri.com> <32BBB4C1.794BDF32@hooked.net> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [ Reduced the Cc list to one mailing list ] > > That's *NOT* the correct thing. What happens when for some reason > > PPP happens to send the sequence '+++' to the modem? All of a sudden > > it'll drop into command mode and you're screwed. User-PPP (as well as > > all other PPP/SLIP implementations I've worked with) assumes that you've > > disabled the escape sequence at least temporarily. > > Interesting. But, what exactly is the prabobalitity of that? I will have > think about this one. Not much, but if it happens it's a pain. > > Most of this *is* already documented in the FreeBSD handbook. > > Nope. Nope. Nope. I have look through the entire /usr/share/doc tree and > didn't find anything about ppp not hanging up modems, etc.. It discusses setting up the modems for PPP. If you don't follow the instructions then the behavior you see is undocumented. I don't ever remember seeing in my Chrysler manual an answer to a question that my car won't move because I forgot to stick oil in it and the engine locked up. You can't answer *every* question when the folks aren't willing to read the setup documentation. Nate From owner-freebsd-current Sat Dec 21 10:51:43 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA21856 for current-outgoing; Sat, 21 Dec 1996 10:51:43 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id KAA21844 for ; Sat, 21 Dec 1996 10:51:36 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id TAA26912 for ; Sat, 21 Dec 1996 19:51:34 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id TAA11543 for freebsd-current@FreeBSD.org; Sat, 21 Dec 1996 19:51:34 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id TAA11963 for freebsd-current@FreeBSD.org; Sat, 21 Dec 1996 19:43:08 +0100 (MET) From: J Wunsch Message-Id: <199612211843.TAA11963@uriah.heep.sax.de> Subject: sytem's default locale To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sat, 21 Dec 1996 19:43:07 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "[?KOI8-R?]" at "Dec 21, 96 06:30:16 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As [?KOI8-R?] wrote: > It is no purpose to keep "system default" locale, all daemons must run > at standard "C" locale. While i basically agree: Why that? Suppose we had a bunch of language catalogs (like AIX), and our daemons would understand where to use setlocale() and where not (unlike AIX :). There's IMHO no reason why a particular system administrator should not express his wish to see the syslog messages in his language -- after all, he is supposed to read them. cron doesn't run in UTC either (even though this would avoid the problem of specifying jobs between 0200 and 0300 on sunday, where they might be `eaten' or run twice on the DST/non-DST transition weekends). Of course, userland programs will always honor the environment, and a user wishing to override the system's locale can do this fine, as well as he can override the localtime setting with a TZ variable. (Both are good candidates for the login class implementation.) Again, i'm not at all convinced about the concept of a system's default locale either, but seeing you (as our i18n meister) putting down the idea in the very first round made me objecting. :) -- 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 Sat Dec 21 10:51:51 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA21880 for current-outgoing; Sat, 21 Dec 1996 10:51:51 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id KAA21861 for ; Sat, 21 Dec 1996 10:51:44 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id TAA26905; Sat, 21 Dec 1996 19:51:31 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id TAA11537; Sat, 21 Dec 1996 19:51:31 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id TAA11894; Sat, 21 Dec 1996 19:30:27 +0100 (MET) From: J Wunsch Message-Id: <199612211830.TAA11894@uriah.heep.sax.de> Subject: Re: User ppp not hanging up modem. To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sat, 21 Dec 1996 19:30:27 +0100 (MET) Cc: dicen@hooked.net Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <32BBA85F.41C67EA6@hooked.net> from "dicen@hooked.net" at "Dec 21, 96 09:05:35 am" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As dicen@hooked.net wrote: > This modem is > set by default not to do anything on a DTR transition. To hang it up you > do the correct thing which is escape with "+++" and then execute ATH. This is always wrong for Unix systems. You should configure your modem correctly. > User ppp only seams to cut the DTR. This is the correct behaviour. Who tells any program that your modem is using Hayes-style commands at all? > So I have now set the modem to be a PC type which will go into command > state with a DTR transition. This introduces other problems. Since > cutting DTR now doesn't reset the state of the modem, it just hangs it > up, doing a redial right after will not work. You have to wait a couple AT&D3 or AT&D4 are supposed to make the modem drop the connection, and reinitialize it as much as possible. Of course, there's no ``Hayes standard'', so you gotta verify with your modem manual. It's usual that many modems are not immediately ready to go again, that's why most dial scripts wait another couple of seconds. > This really needs to be put in the FAQ. I would rather have an escape > done "+++" and the an ATH to hang up the modem but atleast it works now. > Is this code in the termios library? No, and i hope nobody would ever get _that_ idea. :-) Or what would you say seeing +++ on your directly connected terminal since the computer was just telling you now that you should ``hangup''? ;-) Something that crucial (wrt. system security, phone costs etc.) should be left to the hardware. Working around this in software (some programs like mgetty, seyon do, in an attempt to cooperate with faulty hardware) is a crock only. > I am posting this to questions, current and stable becuase it applies to > all of them. No. It's probably most applicable to questions now :), but since i'm not subscribed there, i leave it to -current. > You can configure majordomo not to send duplicate emails > for different mail lists. It isn't that hard. And please, to which list should it decide to send the single copy then? Do you expect majordomo reading your mail first? Not bad. ``Hey, this mail contains a very basic question, i should best delete the Cc's for hackers and current.'' Or more like: ``Hey, this jerk has been sending a mail to twentyfive mailing lists, i will best send it to /dev/null instead.'' :-)) -- 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 Sat Dec 21 10:51:54 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id KAA21892 for current-outgoing; Sat, 21 Dec 1996 10:51:54 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id KAA21873 for ; Sat, 21 Dec 1996 10:51:49 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id TAA26922; Sat, 21 Dec 1996 19:51:37 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id TAA11545; Sat, 21 Dec 1996 19:51:36 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id TAA12073; Sat, 21 Dec 1996 19:49:58 +0100 (MET) From: J Wunsch Message-Id: <199612211849.TAA12073@uriah.heep.sax.de> Subject: Re: User ppp not hanging up modem. To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sat, 21 Dec 1996 19:49:58 +0100 (MET) Cc: dicen@hooked.net Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199612211751.KAA27123@rocky.mt.sri.com> from Nate Williams at "Dec 21, 96 10:51:29 am" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Nate Williams wrote: > That's *NOT* the correct thing. What happens when for some reason > PPP happens to send the sequence '+++' to the modem? All of a sudden > it'll drop into command mode and you're screwed. User-PPP (as well as > all other PPP/SLIP implementations I've worked with) assumes that you've > disabled the escape sequence at least temporarily. That's why they protect it by requiring 500 ms spaces before and after the +++. I think AT&T even has a patent on this escaping scheme. Still i don't agree that IIJPPP should send this sequence, though. The heavy preference of +++ ATH does IMHO only arise out of messy DOS poor DTR handling. Dropping DTR on each device close is a very much cleaner policy than messing around with the command set of a modem (which cannot be done by the kernel or a multipurpose library anyway since there is no `standard command set', and a tty device might as well end up in any other communication endpoint that doesn't have a command set at all). -- 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 Sat Dec 21 12:04:16 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA25573 for current-outgoing; Sat, 21 Dec 1996 12:04:16 -0800 (PST) Received: from moonpie.w8hd.org (root@moonpie.w8hd.org [198.252.159.14]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id MAA25563 for ; Sat, 21 Dec 1996 12:04:12 -0800 (PST) Received: from moonpie.w8hd.org (kimc@moonpie.w8hd.org [198.252.159.14]) by moonpie.w8hd.org (8.8.4/8.8.2) with SMTP id PAA02324 for ; Sat, 21 Dec 1996 15:04:11 -0500 (EST) Date: Sat, 21 Dec 1996 15:04:10 -0500 (EST) From: Kim Culhan To: current@freebsd.org Subject: cannot bootstrap to -current Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This error appears to happen at random times in the build process on -current when building on a machine which last built -current on 12-14. Here is one when 'make bootstrap': cc -O -I/usr/src/usr.bin/make -o make arch.o buf.o compat.o cond.o dir.o for.o hash.o job.o main.o make.o parse.o str.o suff.o targ.o var.o util.o lstAppend.o lstAtEnd.o lstAtFront.o lstClose.o lstConcat.o lstDatum.o lstDeQueue.o lstDestroy.o lstDupl.o lstEnQueue.o lstFind.o lstFindFrom.o lstFirst.o lstForEach.o lstForEachFrom.o lstInit.o lstInsert.o lstIsAtEnd.o lstIsEmpty.o lstLast.o lstMember.o lstNext.o lstOpen.o lstRemove.o lstReplace.o lstSucc.o install -c -s -o bin -g bin -m 555 make /usr/bin pwd: No such file or directory *** Error code 2 Stop. *** Error code 1 Stop. I've tried to recompile install, make and pwd, not clear where this is coming from. regards kim -- kimc@w8hd.org From owner-freebsd-current Sat Dec 21 12:41:03 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA26914 for current-outgoing; Sat, 21 Dec 1996 12:41:03 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id MAA26909 for ; Sat, 21 Dec 1996 12:41:00 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id MAA00303; Sat, 21 Dec 1996 12:40:55 -0800 (PST) To: Kim Culhan cc: current@freebsd.org Subject: Re: cannot bootstrap to -current In-reply-to: Your message of "Sat, 21 Dec 1996 15:04:10 EST." Date: Sat, 21 Dec 1996 12:40:55 -0800 Message-ID: <299.851200855@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > This error appears to happen at random times in the build process on > -current when building on a machine which last built -current on 12-14. > pwd: No such file or directory > *** Error code 2 This actually appears to be a bogon in sh, introduced by recent commits. I'm still trying to ascertain the situation myself. ;) Jordan From owner-freebsd-current Sat Dec 21 13:52:08 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA03160 for current-outgoing; Sat, 21 Dec 1996 13:52:08 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA03154 for ; Sat, 21 Dec 1996 13:52:05 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA12368; Sat, 21 Dec 1996 22:51:40 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA13682; Sat, 21 Dec 1996 22:51:40 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id WAA13478; Sat, 21 Dec 1996 22:49:39 +0100 (MET) From: J Wunsch Message-Id: <199612212149.WAA13478@uriah.heep.sax.de> Subject: Re: cannot bootstrap to -current To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sat, 21 Dec 1996 22:49:39 +0100 (MET) Cc: kimc@w8hd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <299.851200855@time.cdrom.com> from "Jordan K. Hubbard" at "Dec 21, 96 12:40:55 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Jordan K. Hubbard wrote: > > pwd: No such file or directory > > *** Error code 2 > > This actually appears to be a bogon in sh, introduced by recent commits. Actually^2, it appears to be a problem in /bin/pwd which the shell stupidly exec's. Steve Price has got a supposed fix for it, and i've just encouraged him to commit it without waiting for any confirmation from a `make world' on my machine. -- 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 Sat Dec 21 13:57:57 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA03416 for current-outgoing; Sat, 21 Dec 1996 13:57:57 -0800 (PST) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [204.214.4.2]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id NAA03411 for ; Sat, 21 Dec 1996 13:57:55 -0800 (PST) Received: from bonsai.hiwaay.net by fly.HiWAAY.net; (8.8.4/1.1.8.2/21Sep95-1003PM) id PAA03622; Sat, 21 Dec 1996 15:57:49 -0600 (CST) Message-ID: <32BC5D1F.2F1CF0FB@hiwaay.net> Date: Sat, 21 Dec 1996 15:56:47 -0600 From: Steve Price X-Mailer: Mozilla 3.01 (X11; I; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: freebsd-current@freefall.freebsd.org Subject: Re: cannot bootstrap to -current References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Howdy all, For all those having this problem, below is a patch that fixes the problem. Just for the record, the problem was not introduced with recent commits to sh(1), rather uncovered by recent changes elsewhere. Don't get me wrong sh(1) IS at fault and I have tried to correct the problem with the attached patch. The problem goes like this: Upon startup sh(1) tries to ascertain what directory it is being started in. If for some reason this directory does not exist, it bails with 'pwd: No such file of directory' It shouldn't do this (at least using the other shells as examples). I am waiting for feedback to make sure that this doesn't create anymore problems before I commit it. So for all those having problems, please try this patch and let me know how it goes. Yes, the patch is long. While I was in there I also made sh(1) use getcwd(3) instead of /bin/pwd (as suggested by Joerg), removed some unneeded #if SYMLINKS stuff, and cleaned up the format a little. Thanks, Steve Index: cd.c =================================================================== RCS file: /u/FreeBSD/cvs/src/bin/sh/cd.c,v retrieving revision 1.7 diff -u -r1.7 cd.c --- cd.c 1996/12/14 06:19:09 1.7 +++ cd.c 1996/12/21 19:43:50 @@ -46,6 +46,7 @@ #include #include #include +#include /* * The cd and pwd commands. @@ -120,16 +121,9 @@ /* - * Actually do the chdir. If the name refers to symbolic links, we - * compute the actual directory name before doing the cd. In an - * interactive shell, print the directory name if "print" is nonzero - * or if the name refers to a symbolic link. We also print the name - * if "/u/logname" was expanded in it, since this is similar to a - * symbolic link. (The check for this breaks if the user gives the - * cd command some additional, unused arguments.) + * Actually do the chdir. In an interactive shell, print the + * directory name if "print" is nonzero. */ - -#if SYMLINKS == 0 STATIC int docd(dest, print) char *dest; @@ -149,107 +143,14 @@ return 0; } -#else - - - -STATIC int -docd(dest, print) - char *dest; - int print; -{ - register char *p; - register char *q; - char *symlink; - char *component; - struct stat statb; - int first; - int i; - - TRACE(("docd(\"%s\", %d) called\n", dest, print)); - -top: - cdcomppath = dest; - STARTSTACKSTR(p); - if (*dest == '/') { - STPUTC('/', p); - cdcomppath++; - } - first = 1; - while ((q = getcomponent()) != NULL) { - if (q[0] == '\0' || (q[0] == '.' && q[1] == '\0')) - continue; - if (! first) - STPUTC('/', p); - first = 0; - component = q; - while (*q) - STPUTC(*q++, p); - if (equal(component, "..")) - continue; - STACKSTRNUL(p); - if (lstat(stackblock(), &statb) < 0) - error("lstat %s failed", stackblock()); - if (!S_ISLNK(statb.st_mode)) - continue; - - /* Hit a symbolic link. We have to start all over again. */ - print = 1; - STPUTC('\0', p); - symlink = grabstackstr(p); - i = (int)statb.st_size + 2; /* 2 for '/' and '\0' */ - if (cdcomppath != NULL) - i += strlen(cdcomppath); - p = stalloc(i); - if (readlink(symlink, p, (int)statb.st_size) < 0) { - error("readlink %s failed", stackblock()); - } - if (cdcomppath != NULL) { - p[(int)statb.st_size] = '/'; - scopy(cdcomppath, p + (int)statb.st_size + 1); - } else { - p[(int)statb.st_size] = '\0'; - } - if (p[0] != '/') { /* relative path name */ - char *r; - q = r = symlink; - while (*q) { - if (*q++ == '/') - r = q; - } - *r = '\0'; - dest = stalloc(strlen(symlink) + strlen(p) + 1); - scopy(symlink, dest); - strcat(dest, p); - } else { - dest = p; - } - goto top; - } - STPUTC('\0', p); - p = grabstackstr(p); - INTOFF; - if (chdir(*p ? p : ".") < 0) { - INTON; - return -1; - } - updatepwd(p); - INTON; - if (print && iflag) - out1fmt("%s\n", p); - return 0; -} -#endif /* SYMLINKS */ - - /* * Get the next component of the path name pointed to by cdcomppath. * This routine overwrites the string pointed to by cdcomppath. */ - STATIC char * -getcomponent() { +getcomponent() +{ register char *p; char *start; @@ -268,19 +169,15 @@ } - /* * Update curdir (the name of the current directory) in response to a * cd command. We also call hashcd to let the routines in exec.c know * that the current directory has changed. */ - -void hashcd(); - STATIC void updatepwd(dir) char *dir; - { +{ char *new; char *p; @@ -318,75 +215,31 @@ } - int pwdcmd(argc, argv) int argc; char **argv; { - getpwd(); + if(!getpwd()) + error("getcwd() failed: %s", strerror(errno)); out1str(curdir); out1c('\n'); return 0; } - - -#define MAXPWD 256 - /* - * Run /bin/pwd to find out what the current directory is. We suppress - * interrupts throughout most of this, but the user can still break out - * of it by killing the pwd program. If we already know the current + * Find out what the current directory is. If we already know the current * directory, this routine returns immediately. */ -void +char * getpwd() { - char buf[MAXPWD]; - char *p; - int i; - int status; - struct job *jp; - int pip[2]; - char *pwd_bin = "/bin/pwd"; + char buf[_POSIX_PATH_MAX]; if (curdir) - return; - INTOFF; - if (pipe(pip) < 0) - error("Pipe call failed"); - /* make a fall-back guess, otherwise we're simply screwed */ - if (access(pwd_bin, X_OK) == -1) - pwd_bin = "/stand/pwd"; - jp = makejob((union node *)NULL, 1); - if (forkshell(jp, (union node *)NULL, FORK_NOJOB) == 0) { - close(pip[0]); - if (pip[1] != 1) { - close(1); - copyfd(pip[1], 1); - close(pip[1]); - } - (void) execl(pwd_bin, "pwd", (char *)0); - error("Cannot exec %s", pwd_bin); - } - (void) close(pip[1]); - pip[1] = -1; - p = buf; - while ((i = read(pip[0], p, buf + MAXPWD - p)) > 0 - || (i == -1 && errno == EINTR)) { - if (i > 0) - p += i; - } - (void) close(pip[0]); - pip[0] = -1; - status = waitforjob(jp); - if (status != 0) - error((char *)0); - if (i < 0 || p == buf || p[-1] != '\n') - error("pwd command failed"); - p[-1] = '\0'; - curdir = savestr(buf); - INTON; + return (curdir); + if (getcwd(buf, sizeof(buf)) == NULL) + return (NULL); + return ((curdir = savestr(buf))); } Index: cd.h =================================================================== RCS file: /u/FreeBSD/cvs/src/bin/sh/cd.h,v retrieving revision 1.1 diff -u -r1.1 cd.h --- cd.h 1996/12/14 06:19:09 1.1 +++ cd.h 1996/12/21 19:22:30 @@ -31,4 +31,4 @@ * SUCH DAMAGE. */ -void getpwd __P((void)); +char *getpwd __P((void)); Index: main.c =================================================================== RCS file: /u/FreeBSD/cvs/src/bin/sh/main.c,v retrieving revision 1.10 diff -u -r1.10 main.c --- main.c 1996/12/14 06:19:19 1.10 +++ main.c 1996/12/21 19:40:33 @@ -171,7 +171,8 @@ init(); setstackmark(&smark); procargs(argc, argv); - getpwd(); + if (getpwd() == NULL && iflag) + out2str("sh: cannot determine working directory\n"); if (argv[0] && argv[0][0] == '-') { state = 1; read_profile("/etc/profile"); Index: shell.h =================================================================== RCS file: /u/FreeBSD/cvs/src/bin/sh/shell.h,v retrieving revision 1.7 diff -u -r1.7 shell.h --- shell.h 1996/12/14 06:19:30 1.7 +++ shell.h 1996/12/21 14:19:20 @@ -40,7 +40,6 @@ /* * The follow should be set to reflect the type of system you have: * JOBS -> 1 if you have Berkeley job control, 0 otherwise. - * SYMLINKS -> 1 if your system includes symbolic links, 0 otherwise. * SHORTNAMES -> 1 if your linker cannot handle long names. * define BSD if you are running 4.2 BSD or later. * define SYSV if you are running under System V. @@ -53,7 +52,6 @@ #define JOBS 1 -#define SYMLINKS 1 #ifndef BSD #define BSD 1 #endif From owner-freebsd-current Sat Dec 21 15:52:48 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA08417 for current-outgoing; Sat, 21 Dec 1996 15:52:48 -0800 (PST) Received: from po1.glue.umd.edu (root@po1.glue.umd.edu [129.2.128.44]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id PAA08393; Sat, 21 Dec 1996 15:52:42 -0800 (PST) Received: from packet.eng.umd.edu (packet.eng.umd.edu [129.2.98.184]) by po1.glue.umd.edu (8.8.3/8.7.3) with ESMTP id SAA06200; Sat, 21 Dec 1996 18:52:39 -0500 (EST) Received: from localhost (chuckr@localhost) by packet.eng.umd.edu (8.8.3/8.7.3) with SMTP id SAA24079; Sat, 21 Dec 1996 18:52:38 -0500 (EST) X-Authentication-Warning: packet.eng.umd.edu: chuckr owned process doing -bs Date: Sat, 21 Dec 1996 18:52:38 -0500 (EST) From: Chuck Robey X-Sender: chuckr@packet.eng.umd.edu To: dicen@hooked.net cc: Nate Williams , freebsd-questions@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: User ppp not hanging up modem. In-Reply-To: <32BBB4C1.794BDF32@hooked.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 21 Dec 1996 dicen@hooked.net wrote: > Nate Williams wrote: > > > > > That's *NOT* the correct thing. What happens when for some reason > > PPP happens to send the sequence '+++' to the modem? All of a sudden > > it'll drop into command mode and you're screwed. User-PPP (as well as > > all other PPP/SLIP implementations I've worked with) assumes that you've > > disabled the escape sequence at least temporarily. > > > Interesting. But, what exactly is the prabobalitity of that? I will have > think about this one. Note that the standard command "&D3" tells the modem to reset itself when DTR drops. Nate's right, this _is_ standard. What he missed was that Hayes modems (Hayes originated the protocol that's now a defacto standard) used to get around the +++ transparency issue by requiring a 2 second dead time (either before or after the +++ code, I forget which). Hayes patented that delay, I think, which is why modems don't use it anymore. > > > > Most of this *is* already documented in the FreeBSD handbook. > > > > Nate > Nope. Nope. Nope. Yes, section 11.3.6. Nate's right. I have look through the entire /usr/share/doc tree and > didn't find anything about ppp not hanging up modems, etc.. Someone > please put this in the FAQ. I have read usenet posts about this one. > Other people are going through the hell I did. I don't like spending > hours debuging code only to discover the code is fine and my modem is > misconfigured (sure I should have thought of it first). > > dicen > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-current Sat Dec 21 16:44:56 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA10371 for current-outgoing; Sat, 21 Dec 1996 16:44:56 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA10366 for ; Sat, 21 Dec 1996 16:44:53 -0800 (PST) Received: from moonpie.w8hd.org (root@moonpie.w8hd.org [198.252.159.14]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id QAA07524 for ; Sat, 21 Dec 1996 16:44:51 -0800 (PST) Received: from moonpie.w8hd.org (kimc@moonpie.w8hd.org [198.252.159.14]) by moonpie.w8hd.org (8.8.4/8.8.2) with SMTP id TAA17262 for ; Sat, 21 Dec 1996 19:43:35 -0500 (EST) Date: Sat, 21 Dec 1996 19:43:34 -0500 (EST) From: Kim Culhan To: current@freebsd.org Subject: How many worldstones ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The 'make world' is still running here with Steve's patch to /bin/sh. The make world run has been taking about 4.5 hours including everything, no arguments supplied to make, how does this compare with others ? kim -- kimc@w8hd.org From owner-freebsd-current Sat Dec 21 17:57:34 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA13271 for current-outgoing; Sat, 21 Dec 1996 17:57:34 -0800 (PST) Received: from eldorado.net-tel.co.uk ([193.122.171.253]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id RAA13252; Sat, 21 Dec 1996 17:57:27 -0800 (PST) From: Andrew.Gordon@net-tel.co.uk Received: (from root@localhost) by eldorado.net-tel.co.uk (8.6.12/8.6.10) id BAA23200; Sun, 22 Dec 1996 01:56:52 GMT Received: from "/PRMD=NET-TEL/ADMD=GOLD 400/C=GB/" by net-tel.co.uk (Route400-RFCGate); Sun, 22 Dec 96 1:55:15 +0000 X400-Received: by mta "eldorado" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Sun, 22 Dec 96 1:55:15 +0000 X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Sun, 22 Dec 96 1:55:13 +0000 X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed; Sun, 22 Dec 96 1:55:13 +0000 X400-MTS-Identifier: ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";hst:21271-961222015513-12AB] X400-Content-Type: P2-1984 (2) X400-Originator: Andrew.Gordon@net-tel.co.uk Original-Encoded-Information-Types: IA5-Text X400-Recipients: non-disclosure:; Date: Sun, 22 Dec 96 1:55:13 +0000 X400-Content-Identifier: Re(2): User ppp Message-Id: <"84a-961222015526-FEB1*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"@MHS> To: list:; Cc: freebsd-questions@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org In-Reply-To: Subject: Re(2): User ppp not hanging up modem. Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On Sat, 21 Dec 1996 dicen@hooked.net wrote: > > Nate Williams wrote: > > > That's *NOT* the correct thing. What happens when for some reason > > > PPP happens to send the sequence '+++' to the modem? All of a sudden > > > it'll drop into command mode and you're screwed. User-PPP (as well as > > > all other PPP/SLIP implementations I've worked with) assumes that > you've > > > disabled the escape sequence at least temporarily. > > > > > Interesting. But, what exactly is the prabobalitity of that? I will have > > think about this one. > > Note that the standard command "&D3" tells the modem to reset itself when > DTR drops. Nate's right, this _is_ standard. What he missed was that > Hayes modems (Hayes originated the protocol that's now a defacto standard) > used to get around the +++ transparency issue by requiring a 2 second dead > time (either before or after the +++ code, I forget which). Before _and_ after - hence you are safe even if a packet begins or ends with "+++". > Hayes > patented that delay, I think, which is why modems don't use it anymore. Good modems still do (USR Courier for example) - presumably having licenced with Hayes. Some junk modems don't..... From owner-freebsd-current Sat Dec 21 18:12:43 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id SAA13751 for current-outgoing; Sat, 21 Dec 1996 18:12:43 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id SAA13746 for ; Sat, 21 Dec 1996 18:12:40 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id MAA12745; Sun, 22 Dec 1996 12:42:28 +1030 (CST) From: Michael Smith Message-Id: <199612220212.MAA12745@genesis.atrad.adelaide.edu.au> Subject: Re: User ppp not hanging up modem. In-Reply-To: <199612211803.LAA27167@rocky.mt.sri.com> from Nate Williams at "Dec 21, 96 11:03:20 am" To: nate@mt.sri.com (Nate Williams) Date: Sun, 22 Dec 1996 12:42:27 +1030 (CST) Cc: dicen@hooked.net, nate@mt.sri.com, freebsd-current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Nate Williams stands accused of saying: [hayes escape occurring in PPP stream] > > Interesting. But, what exactly is the prabobalitity of that? I will have > > think about this one. > > Not much, but if it happens it's a pain. Try "effectively none". If you can show me how a PPP protocol engine can generate <500ms pause>+++<500ms pause> under normal operating conditions, I'll have a chew on my sandals for you. Regardless, I agree 100% with you; the use of an in-band control signal to hang up the modem is a complete abortion. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-current Sat Dec 21 18:14:22 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id SAA13813 for current-outgoing; Sat, 21 Dec 1996 18:14:22 -0800 (PST) Received: from broon.off.connect.com.au (broon.off.connect.com.au [203.63.69.1]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id SAA13807 for ; Sat, 21 Dec 1996 18:14:15 -0800 (PST) Received: (from ggm@localhost) by broon.off.connect.com.au id MAA27466 (8.7.6h/IDA-1.6 for current@freebsd.org); Sun, 22 Dec 1996 12:13:33 +1000 (EST) Date: Sun, 22 Dec 1996 12:13:33 +1000 (EST) From: George Michaelson Message-ID: <199612220213.MAA27466@broon.off.connect.com.au> To: current@freebsd.org Subject: successful build of 2.2-snap to current Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk After considering the responses I did a sup last night and remade with a make world (using a hack to use bash in place of sh as noted) This failed with the following diagnostic on gnu/usr.bin/cvs and I got over it by commenting out the cvs subdir in the Makefile for usr.bin. BTW I've had this happen every time for the last few months... Is this a side-effect of sup not cleaning up a shift to links into contrib/cvs or what? Anyway, 3-current is a nice easy build from 2.2, and runs fine on a no-name P100/16Mb. XFree86-3.2 depends on libgnumalloc and this requires a ln/ln-s from libfakegnumalloc to run. cheers -George ===> lib ===> cvs cc -O -I/usr/src/gnu/usr.bin/cvs/cvs -I/usr/src/gnu/usr.bin/cvs/cvs/../lib -I/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/src -I/usr/src/gnu/usr.bin/cvs/cvs/../../../../contrib/cvs/lib -DHAVE_CONFIG_H -o cvs add.o admin.o checkin.o checkout.o classify.o client.o commit.o create_adm.o cvsrc.o diff.o entries.o expand_path.o find_names.o history.o ignore.o import.o lock.o log.o login.o logmsg.o main.o modules.o no_diff.o parseinfo.o patch.o rcs.o rcscmds.o recurse.o release.o remove.o repos.o root.o rtag.o server.o status.o tag.o update.o vers_ts.o wrapper.o subr.o error.o filesubr.o version.o myndbm.o fileattr.o watch.o run.o hash.o edit.o mkmodules.o scramble.o -L/usr/obj/usr/src/gnu/usr.bin/cvs/cvs/../lib -lcvs -lgnuregex -lmd -lcrypt logmsg.o: Undefined symbol `_Popen' referenced from text segment release.o: Undefined symbol `_Popen' referenced from text segment error.o: Undefined symbol `_cvs_outerr' referenced from text segment watch.o: Undefined symbol `_send_to_server' referenced from text segment watch.o: Undefined symbol `_lock_tree_for_write' referenced from text segment watch.o: Undefined symbol `_lock_tree_cleanup' referenced from text segment watch.o: Undefined symbol `_send_to_server' referenced from text segment edit.o: Undefined symbol `_send_to_server' referenced from text segment edit.o: Undefined symbol `_lock_tree_for_write' referenced from text segment edit.o: Undefined symbol `_lock_tree_cleanup' referenced from text segment edit.o: Undefined symbol `_send_to_server' referenced from text segment edit.o: Undefined symbol `_lock_tree_for_write' referenced from text segment edit.o: Undefined symbol `_lock_tree_cleanup' referenced from text segment edit.o: Undefined symbol `_server_started' referenced from text segment edit.o: Undefined symbol `_client_notify' referenced from text segment edit.o: Undefined symbol `_send_to_server' referenced from text segment mkmodules.o: Undefined symbol `_send_init_command' referenced from text segment *** Error code 1 Stop. *** Error code 1 Stop. From owner-freebsd-current Sat Dec 21 19:17:27 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id TAA15701 for current-outgoing; Sat, 21 Dec 1996 19:17:27 -0800 (PST) Received: from sdev.usn.blaze.net.au (sdev.usn.blaze.net.au [203.17.53.19]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id TAA15678; Sat, 21 Dec 1996 19:17:18 -0800 (PST) Received: (from davidn@localhost) by sdev.usn.blaze.net.au (8.8.4/8.6.9) id OAA15734; Sun, 22 Dec 1996 14:17:00 +1100 (EST) Message-ID: Date: Sun, 22 Dec 1996 14:16:59 +1100 From: davidn@sdev.usn.blaze.net.au (David Nugent) To: dicen@hooked.net Cc: nate@mt.sri.com (Nate Williams), chuckr@glue.umd.edu (Chuck Robey), freebsd-questions@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: User ppp not hanging up modem. References: <32BBA85F.41C67EA6@hooked.net> <199612211751.KAA27123@rocky.mt.sri.com> <32BBB4C1.794BDF32@hooked.net> X-Mailer: Mutt 0.54 Mime-Version: 1.0 In-Reply-To: <32BBB4C1.794BDF32@hooked.net>; from dicen@hooked.net on Dec 21, 1996 09:58:25 +0000 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk dicen@hooked.net writes: >> That's *NOT* the correct thing. What happens when for some reason >> PPP happens to send the sequence '+++' to the modem? All of a sudden >> it'll drop into command mode and you're screwed. User-PPP (as well as >> all other PPP/SLIP implementations I've worked with) assumes that you've >> disabled the escape sequence at least temporarily. > > Interesting. But, what exactly is the prabobalitity of that? I will have > think about this one. The probability of it happening is very very small, given that there must also be a two minute "silence" from the DTE both before and after the '+++' sequence. The actual delay required is usually register configurable. David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freefall.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/ From owner-freebsd-current Sat Dec 21 19:50:29 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id TAA16591 for current-outgoing; Sat, 21 Dec 1996 19:50:29 -0800 (PST) Received: from sdev.usn.blaze.net.au (sdev.usn.blaze.net.au [203.17.53.19]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id TAA16570; Sat, 21 Dec 1996 19:50:20 -0800 (PST) Received: (from davidn@localhost) by sdev.usn.blaze.net.au (8.8.4/8.6.9) id OAA15781; Sun, 22 Dec 1996 14:50:10 +1100 (EST) Message-ID: Date: Sun, 22 Dec 1996 14:50:10 +1100 From: davidn@sdev.usn.blaze.net.au (David Nugent) To: davidn@sdev.usn.blaze.net.au (David Nugent) Cc: dicen@hooked.net, nate@mt.sri.com (Nate Williams), chuckr@glue.umd.edu (Chuck Robey), freebsd-questions@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: User ppp not hanging up modem. References: <32BBA85F.41C67EA6@hooked.net> <199612211751.KAA27123@rocky.mt.sri.com> <32BBB4C1.794BDF32@hooked.net> X-Mailer: Mutt 0.54 Mime-Version: 1.0 In-Reply-To: ; from David Nugent on Dec 22, 1996 14:16:59 +1100 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Following up my own post. :-) David Nugent writes: > > Interesting. But, what exactly is the prabobalitity of that? I will have > > think about this one. > > The probability of it happening is very very small, given that > there must also be a two minute "silence" from the DTE both before two /minute/? Sheesh, get off the tap water. I meant seconds. And I believe Michael is correct that 0.5 seconds is the standard setting - I've always raised it as a matter of course. Regards, David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freefall.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/ From owner-freebsd-current Sat Dec 21 21:25:51 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id VAA19894 for current-outgoing; Sat, 21 Dec 1996 21:25:51 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id VAA19885 for ; Sat, 21 Dec 1996 21:25:46 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id QAA08222; Sun, 22 Dec 1996 16:24:38 +1100 Date: Sun, 22 Dec 1996 16:24:38 +1100 From: Bruce Evans Message-Id: <199612220524.QAA08222@godzilla.zeta.org.au> To: freebsd-current@freefall.freebsd.org, sprice@hiwaay.net Subject: Re: cannot bootstrap to -current Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >I am waiting for feedback to make sure that this doesn't create >anymore problems before I commit it. >-#define MAXPWD 256 This was probably too small. >+ char buf[_POSIX_PATH_MAX]; This should probably not be used. Why not use getcwd(NULL, 0) like pwd(1) to avoid unnecessary failures in deep directories? _POSIX_PATH_MAX is even smaller than MAXPWD (255) and should only be used by POSIX programs that don't want to deal with dynamic allocation to handle systems where PATH_MAX is not defined. Bruce