From owner-freebsd-doc Sun Feb 20 1:13:50 2000 Delivered-To: freebsd-doc@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id DF69E37BE7D; Sun, 20 Feb 2000 01:13:47 -0800 (PST) (envelope-from jkh@FreeBSD.org) Received: (from jkh@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id BAA21479; Sun, 20 Feb 2000 01:13:47 -0800 (PST) (envelope-from jkh@FreeBSD.org) Date: Sun, 20 Feb 2000 01:13:47 -0800 (PST) From: Message-Id: <200002200913.BAA21479@freefall.freebsd.org> To: martti.kuparinen@nomadiclab.com, jkh@FreeBSD.org, freebsd-doc@FreeBSD.org Subject: Re: docs/16818: Documentation fixes for 4.0-CURRENT Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: Documentation fixes for 4.0-CURRENT State-Changed-From-To: open->closed State-Changed-By: jkh State-Changed-When: Sun Feb 20 01:13:34 PST 2000 State-Changed-Why: Fixed, thanks. . To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sun Feb 20 5:20: 4 2000 Delivered-To: freebsd-doc@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id CB3A337BDB3 for ; Sun, 20 Feb 2000 05:20:01 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id FAA49908; Sun, 20 Feb 2000 05:20:01 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from ares.maths.adelaide.edu.au (ares.maths.adelaide.edu.au [129.127.246.5]) by hub.freebsd.org (Postfix) with ESMTP id ED27937BD00 for ; Sun, 20 Feb 2000 05:12:37 -0800 (PST) (envelope-from glewis@ares.maths.adelaide.edu.au) Received: (from glewis@localhost) by ares.maths.adelaide.edu.au (8.9.3/8.9.3) id XAA23848; Sun, 20 Feb 2000 23:42:35 +1030 (CST) (envelope-from glewis) Message-Id: <200002201312.XAA23848@ares.maths.adelaide.edu.au> Date: Sun, 20 Feb 2000 23:42:35 +1030 (CST) From: Greg Lewis Reply-To: glewis@trc.adelaide.edu.au To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: docs/16834: [Patch] Missing underline in ctm(5) Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 16834 >Category: docs >Synopsis: [Patch] Missing underline in ctm(5) >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Sun Feb 20 05:20:01 PST 2000 >Closed-Date: >Last-Modified: >Originator: Greg Lewis >Release: FreeBSD 3.4-STABLE i386 >Organization: Teletraffic Research Centre >Environment: All versions appear to be affected. >Description: The ctm(5) man page appears to be missing an underline in part of the control lines documentation. >How-To-Repeat: man 5 ctm >Fix: Apply the following patch to /usr/src/usr.sbin/ctm/ctm/ctm.5 --- ctm.5.orig Sun Feb 20 23:36:08 2000 +++ ctm.5 Sun Feb 20 23:36:41 2000 @@ -152,7 +152,7 @@ and mode .Ar mode . -.It \&DR name +.It \&DR Ar name The directory .Ar name >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sun Feb 20 12:50:10 2000 Delivered-To: freebsd-doc@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 977F137BFBB for ; Sun, 20 Feb 2000 12:50:02 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id MAA36982; Sun, 20 Feb 2000 12:50:02 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from monsoon.mail.pipex.net (monsoon.mail.pipex.net [158.43.128.69]) by hub.freebsd.org (Postfix) with SMTP id 92C3237BF5D for ; Sun, 20 Feb 2000 12:49:59 -0800 (PST) (envelope-from mark@dogma.freebsd-uk.eu.org) Received: (qmail 25297 invoked from network); 20 Feb 2000 20:49:57 -0000 Received: from userab55.uk.uudial.com (HELO marder-1.) (62.188.130.154) by smtp.dial.pipex.com with SMTP; 20 Feb 2000 20:49:57 -0000 Received: (from root@localhost) by marder-1. (8.9.3/8.9.3) id UAA05248; Sun, 20 Feb 2000 20:49:55 GMT (envelope-from mark) Message-Id: <200002202049.UAA05248@marder-1.> Date: Sun, 20 Feb 2000 20:49:55 GMT From: Mark Ovens Reply-To: Mark Ovens To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: docs/16841: New FAQ entry describing use of "Windows(tm)" keys Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 16841 >Category: docs >Synopsis: New FAQ entry describing use of "Windows(tm)" keys >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Sun Feb 20 12:50:02 PST 2000 >Closed-Date: >Last-Modified: >Originator: Mark Ovens >Release: FreeBSD 3.4-STABLE i386 >Organization: >Environment: >Description: Add FAQ entry describing how to use the Windows(tm) keys >How-To-Repeat: >Fix: *** book.sgml.orig Sun Feb 20 19:39:04 2000 --- book.sgml Sun Feb 20 20:37:21 2000 *************** *** 5517,5523 **** --- 5517,5586 ---- Now all you need is a splash screen. For that you can surf on over to the gallery at http://www.cslab.vt.edu/~jobaldwi/splash/. + + + + Can I use the Windows(tm) keys on my keyboard in X? + + + Yes. All you need to do is use &man.xmodmap.1; to define what + function you wish them to perform. + + Assuming all "Windows(tm)" keyboards are standard then + the keycodes for the 3 keys are + + + + 115 - Windows(tm) key, between the left-hand Ctrl and + Alt keys + + + 116 - Windows(tm) key, to the right of the Alt-Gr key + + + 117 - Menu key, to the left of the right-hand Ctrl key + + + + The command + &prompt.root; xmodmap -e "keycode 115 = comma" + will make the left Windows(tm) key print a comma + (you will probably have to re-start X to see the result) + + To have the Windows(tm) key-mappings enabled automatically + everytime you start X either put the xmodmap commands + in your ~/.xinitrc file or, preferably, create a + file ~/.xmodmaprc and just include the + xmodmap options, one per line. + + For example, I have mapped the 3 keys to be F13, F14, and F15 + respectively. This makes it easy to map them to useful functions within + applications or your window manager. + + To do this put the following in ~/.xmodmaprc + + + keycode 115 = F13 + keycode 116 = F14 + keycode 117 = F15 + + I use fvwm2 and have mapped the keys so that + F13 iconifies (or de-iconifies) the window the cursor is in, F14 brings + the window the cursor is in to the front or, if it is already at the + front, pushes it to the back, and F15 pops up the main Workplace + (application) menu even if the cursor is not on the desktop, which is + useful if you don't have any part of the desktop visible (and the logo + on the key matches its functionality). + + The entries in my ~/.fvwmrc which map the + keys this way are: + + Key F13 FTIWS A Iconify + Key F14 FTIWS A RaiseLower + Key F15 A A Menu Workplace Nop + + + >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sun Feb 20 14:17:28 2000 Delivered-To: freebsd-doc@freebsd.org Received: from pop.idx.com.au (pop.idx.com.au [203.14.30.10]) by hub.freebsd.org (Postfix) with ESMTP id 18A6137BFD9; Sun, 20 Feb 2000 14:17:17 -0800 (PST) (envelope-from dannyh@idx.com.au) Received: from psych (idxwc04-150.idx.com.au [203.166.1.150]) by pop.idx.com.au (8.9.3/8.9.3) with SMTP id JAA15240; Mon, 21 Feb 2000 09:14:43 +1100 Message-Id: <3.0.32.20000221091533.0069ebc8@idx.com.au> X-Sender: dannyh@idx.com.au X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 21 Feb 2000 09:15:36 +1100 To: freebsd-doc@FreeBSD.org From: Danny Subject: How can I contribute to freebsd-docs? Cc: freebsd-questions@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, Situation I feel that being part of freebsd-doc will benefit my networking career and technical writing career. As employeers will see both my networking / FreeBSD knowledge and my technial writing skills online Question 1) I was wondering how I can be part of this freebsd-doc project? 2) What kind of prequsites do I need ? Looking forward to your feedback. danny dannyh@idx.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sun Feb 20 14:42:28 2000 Delivered-To: freebsd-doc@freebsd.org Received: from sanson.reyes.somos.net (freyes.static.inch.com [216.223.199.224]) by hub.freebsd.org (Postfix) with ESMTP id 096B737C0C9; Sun, 20 Feb 2000 14:42:20 -0800 (PST) (envelope-from fran@reyes.somos.net) Received: from tomasa (tomasa.reyes.somos.net [10.0.0.11]) by sanson.reyes.somos.net (8.9.3/8.9.3) with SMTP id RAA19202; Sun, 20 Feb 2000 17:20:10 -0500 (EST) (envelope-from fran@reyes.somos.net) Message-Id: <200002202220.RAA19202@sanson.reyes.somos.net> From: "Francisco Reyes" To: "Danny" , "freebsd-doc@FreeBSD.ORG" Cc: "freebsd-questions@FreeBSD.ORG" Date: Sun, 20 Feb 2000 17:24:17 -0500 Reply-To: "Francisco Reyes" X-Mailer: PMMail 2000 Professional (2.10.2010) For Windows 98 (4.10.2222) In-Reply-To: <3.0.32.20000221091533.0069ebc8@idx.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: How can I contribute to freebsd-docs? Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 21 Feb 2000 09:15:36 +1100, Danny wrote: >1) I was wondering how I can be part of this freebsd-doc project? >2) What kind of prequsites do I need ? Look at http://www.freebsd.org/tutorials/docproj-primer/ or if you prefer one large single HTML page then look at http://www.freebsd.org/tutorials/docproj-primer/book.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sun Feb 20 14:42:31 2000 Delivered-To: freebsd-doc@freebsd.org Received: from quark.pioneernet.net (pop3.pioneernet.net [208.240.196.25]) by hub.freebsd.org (Postfix) with ESMTP id AA8A637C0C1; Sun, 20 Feb 2000 14:42:15 -0800 (PST) (envelope-from chip@wiegand.org) Received: from wiegand.org (sb26.pioneernet.net [208.194.173.26]) by quark.pioneernet.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id F23CYSG5; Sun, 20 Feb 2000 14:38:38 -0800 Message-ID: <38B06D24.D6942E17@wiegand.org> Date: Sun, 20 Feb 2000 14:39:32 -0800 From: Chip Wiegand X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Danny Cc: freebsd-doc@FreeBSD.org, freebsd-questions@FreeBSD.org Subject: Re: How can I contribute to freebsd-docs? References: <3.0.32.20000221091533.0069ebc8@idx.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Check out this info, I copied it right from the freebsd.org documentation project page - If you are interested in helping with this project, send email to the the FreeBSD documentation project mailing list . Chip W. Danny wrote: > Hello, > > Situation > > I feel that being part of freebsd-doc will benefit my networking career and > technical writing career. As employeers will see both my networking / > FreeBSD knowledge and my technial writing skills online > > Question > > 1) I was wondering how I can be part of this freebsd-doc project? > 2) What kind of prequsites do I need ? > > Looking forward to your feedback. > > danny > > dannyh@idx.com.au > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sun Feb 20 14:43:26 2000 Delivered-To: freebsd-doc@freebsd.org Received: from quark.pioneernet.net (pop3.pioneernet.net [208.240.196.25]) by hub.freebsd.org (Postfix) with ESMTP id 807A537BD66; Sun, 20 Feb 2000 14:43:22 -0800 (PST) (envelope-from chip@wiegand.org) Received: from wiegand.org (sb26.pioneernet.net [208.194.173.26]) by quark.pioneernet.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id F23CYSJV; Sun, 20 Feb 2000 14:42:31 -0800 Message-ID: <38B06E12.CFCDCDDE@wiegand.org> Date: Sun, 20 Feb 2000 14:43:31 -0800 From: Chip Wiegand X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Danny Cc: freebsd-doc@FreeBSD.org, freebsd-questions@FreeBSD.org Subject: Re: How can I contribute to freebsd-docs? References: <3.0.32.20000221091533.0069ebc8@idx.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Here's another one I found after the previous one, this might be even more appropriate - http://www.freebsd.org/docproj/docproj.html Chip W. Danny wrote: > Hello, > > Situation > > I feel that being part of freebsd-doc will benefit my networking career and > technical writing career. As employeers will see both my networking / > FreeBSD knowledge and my technial writing skills online > > Question > > 1) I was wondering how I can be part of this freebsd-doc project? > 2) What kind of prequsites do I need ? > > Looking forward to your feedback. > > danny > > dannyh@idx.com.au > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sun Feb 20 21:20:14 2000 Delivered-To: freebsd-doc@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 78C5437C107 for ; Sun, 20 Feb 2000 21:20:03 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id VAA81801; Sun, 20 Feb 2000 21:20:03 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 8683137BE70 for ; Sun, 20 Feb 2000 21:14:36 -0800 (PST) (envelope-from nobody@FreeBSD.org) Received: (from nobody@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id VAA81625; Sun, 20 Feb 2000 21:14:36 -0800 (PST) (envelope-from nobody@FreeBSD.org) Message-Id: <200002210514.VAA81625@freefall.freebsd.org> Date: Sun, 20 Feb 2000 21:14:36 -0800 (PST) From: bobj@atlantic.net To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: docs/16854: Typos from Chapter 4 of FreeBSD Handbook Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 16854 >Category: docs >Synopsis: Typos from Chapter 4 of FreeBSD Handbook >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Sun Feb 20 21:20:03 PST 2000 >Closed-Date: >Last-Modified: >Originator: Bob Johnson >Release: www.freebsd.org as of 20 Feb 00 (P.M.) >Organization: >Environment: n/a >Description: Found the following typos and other problems in the HTML version of The FreeBSD Handbook as published on www.freebsd.org. URL references are to the web page in which a particular error is found (in this case they are all in http://www.freebsd.org/handbook/porting.html). ============ In URL http://www.freebsd.org/handbook/porting.html Section 4.4.5.1. ldconfig "Anybody who does this will be shot and cut in 65,536 pieces by a rusty knife and have is liver chopped out..." The word "is" should probably be "his", unless you want to be non-gender-specific, in which case "their" is commonly used. ------------- Same URL Section 4.4.6. ELF support "...we wish to unofficially support the 2.2 as long as possible." The 2.2 what? The 2.2 ports? The 2.2 binaries? I think a word is missing here. ------------- Same URL Section 4.4.9 Manpages "Additionally ${PREFIX}/man/man8/alt-name.8.gz may or may-not be installed by your port." Change "may-not" to "may not". ------------ Same URL Section 4.4.12. Info files "If your port installs any info documents, please follow this instructions so your port/package will correctly update the user's PREFIX/info/dir file." Change "this" to "these". ------------ Same URL Section 4.4.13.5. Changing the names of files in the pkg subdirectory "This is especially useful when you are sharing the same pkg subdirectory among several ports or have to write to one of the above files (see writing to places other than WRKDIR for why it is a bad idea to write directly in to the pkg subdirectory." Mismatched parentheses. Need a closing paren before the period. ----------- Same URL Section 4.4.16. Do's and Dont's "Here is a list of common do's and dont's that you encounter during the porting process." As mentioned in a previous typos submission, "Do's and Dont's" is not spelled correctly. It should be "Dos and Don'ts", but you have to play games with fonts for it to make sense. ----------- Same URL Section 4.4.16.5. Differentiating operating systems and OS versions 3.3-RELEASE 3.3-STABLE 3.3-STABLE after adding mkstemps() to libc ??--> 4.0-CURRENT after 3/4 branch 4.0-CURRENT after change in dynamic linker handling 4.0-CURRENT after C++ constructor/destructor order change The list of values for __FreeBSD_version does not include entries for 3.4-RELEASE or 3.4-STABLE. ----------- Same URL Section 4.4.16.6. Writing something after bsd.port.mk In the list of variables the entry for PORTOBJFORMAT "PORTOBJFORMAT The object format of the system (aout or elf " has no closing parenthesis. ----------- Same URL Same Section, 4.4.16.6. Writing something after bsd.port.mk "Here are some examples of things you can write after bsd.port.pre.mk; " I would end this with a colon instead of a semicolon. I'm pretty sure I would be correct in doing so... ----------- Same URL Section 4.4.16.22. If you are stuck... "Do look at existing examples and the bsd.port.mk file before asking us questions! ;) " Although it looks fine in plain text, this emoticon does not look right when rendered in italics on my browser. It needs a nose. In other places it is rendered as ;-) ----------- Same URL Section 4.4.17. A Sample Makefile "[maintainer; *mandatory*! This is the person (preferably with commit privileges) who a user can contact for questions and bug reports " "who" should be "whom", although few people care these days. ----------- Same URL Section 4.4.18. Automated package list creation "If your port honours PREFIX (which it should) you can then install the port and create the package list. " This uses the British spelling "honours". I haven't noticed British usage in earlier sections, although perhaps I wasn't looking. If consistency is considered important, someone should decide whether British or American spellings will be used, or perhaps create SGML tags that allow alternate spellings to be specified so that regional editions of the Handbook can be easily rendered. Creating a tool to automate the search for words so affected would then also be handy. ----------- Same URL Section 4.4.19. Package Names "2. The name part should be all lowercases, except for a really large package (with lots of programs in it)." I would say "all lowercase" rather than "all lowercases". ---------- Same URL Section 4.4.20.1. Current list of categories "afterstep* Ports to support AfterStep window manager " Reads better as "Ports to support the Afterstep...". Add the word "the". Also, there should be a period at the end to be consistent with other entries in the list. ----------- Same URL Same Section "devel Development utilities. Do not put libraries here just because they are libraries--unless they truly do not belong to anywhere else, they should not be in this category. " I would change "belong to anywhere else" to "belong anywhere else". ----------- Same URL Same Section "irc Internet Chat Relay utilities. " Should say "Internet Relay Chat", at least in my dialect. ----------- Same URL Same Section "misc Miscellaneous utilities--basically things that does not belong to anywhere else." "does" should be "do". Also, I would drop "to" so it says "...things that do not belong anywhere else." ----------- Same URL Section 4.4.20.2. Choosing the right category "Also, you do not need to list net when the port belongs to either of irc, mail, mbone, news, security, or www. " To me, "either" implies a choice between two options; either a or b. I would change "either" to "any". I'm not sure how the rest of the world feels about this. ----------- Same URL Same Section, 4.4.20.2. Choosing the right category "If you are not sure about the category, please put a comment to that effect in your send-pr submission so we can discuss it before import it." There should be a word between "before" and "import". Probably "we". Also, the parentheses around the next sentence should be removed (a sentence that consists of nothing but a parenthetical phrase doesn't seem quite right). >How-To-Repeat: See referenced URLs. >Fix: Implement my suggestions if you agree with them. >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sun Feb 20 23: 8:18 2000 Delivered-To: freebsd-doc@freebsd.org Received: from imo24.mx.aol.com (imo24.mx.aol.com [152.163.225.68]) by hub.freebsd.org (Postfix) with ESMTP id 0A99037C181 for ; Sun, 20 Feb 2000 23:08:15 -0800 (PST) (envelope-from Lrayvick@aol.com) Received: from Lrayvick@aol.com by imo24.mx.aol.com (mail_out_v25.3.) id n.7f.f674ac (4546) for ; Mon, 21 Feb 2000 02:08:06 -0500 (EST) From: Lrayvick@aol.com Message-ID: <7f.f674ac.25e23e56@aol.com> Date: Mon, 21 Feb 2000 02:08:06 EST Subject: msfroot To: freebsd-doc@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 44 Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Trying to download it but when I click on it the next screen is "FTP directory /pub/FreeBSD/releases/i386/3.4-RELEASE/floppies/mfsroot.flp at ftp.freebsd.org" which shows a bunch of other files none of which is msfroot.flp. The other file, kern.flp, downloaded fine. What's up? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sun Feb 20 23:10: 9 2000 Delivered-To: freebsd-doc@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id DDF9837C1A6 for ; Sun, 20 Feb 2000 23:10:00 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id XAA89802; Sun, 20 Feb 2000 23:10:00 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from mac.daddy.net (disco.cdrom.com [204.216.28.175]) by hub.freebsd.org (Postfix) with ESMTP id ADC7337BBD1 for ; Sun, 20 Feb 2000 23:01:25 -0800 (PST) (envelope-from murray@mac.daddy.net) Received: (from murray@localhost) by mac.daddy.net (8.9.3/8.9.2) id WAA79700; Sun, 20 Feb 2000 22:44:29 -0800 (PST) (envelope-from murray) Message-Id: <200002210644.WAA79700@mac.daddy.net> Date: Sun, 20 Feb 2000 22:44:29 -0800 (PST) From: murray@cdrom.com Reply-To: murray@cdrom.com To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: docs/16859: Update for Handbook/LinuxEmu/Mathematica Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 16859 >Category: docs >Synopsis: This section of the handbook is way out of date >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Sun Feb 20 23:10:00 PST 2000 >Closed-Date: >Last-Modified: >Originator: Murray Stokely >Release: FreeBSD 3.4-STABLE i386 >Organization: Walnut Creek CDROM >Environment: >Description: The current section of the handbook that talks about installing the Linux version of Mathematica is grossly outdated. The actual installation process for modern versions of Mathematica on FreeBSD 3.x systems is much different (easier) than the current method explained in the handbook. >How-To-Repeat: It looks like some sections of the handbook have a ugly "contributed by bla bla" line at the top and others do not. Is there a more centralized place for handbook contributors to be credited? >Fix: Index: chapter.sgml =================================================================== RCS file: /host/ares/usr/home/ncvs/doc/en_US.ISO_8859-1/books/handbook/linuxemu/chapter.sgml,v retrieving revision 1.26 diff -u -r1.26 chapter.sgml --- chapter.sgml 1999/12/04 06:19:20 1.26 +++ chapter.sgml 2000/02/21 06:27:57 @@ -692,35 +692,46 @@ How to Install Mathematica on FreeBSD - Contributed by &a.rich; and &a.chuck; - - This document shows how to install the Linux binary distribution of - Mathematica 2.2 on FreeBSD 2.1. - - Mathematica supports Linux but not FreeBSD as it stands. So once - you have configured your system for Linux compatibility you have most of - what you need to run Mathematica. - - For those who already have the student edition of Mathematica for - DOS the cost of upgrading to the Linux version at the time this was - written, March 1996, was $45.00. It can be ordered directly from - Wolfram at (217) 398-6500 and paid for by credit card. + This document describes the process of installing the Linux +version of Mathematica 4.0 onto a FreeBSD 3.X system. + + The Linux version of Mathematica runs perfectly under + FreeBSD however the binaries shipped by Wolfram need to be + branded so that FreeBSD knows to use the Linux ABI to execute + them. + The Linux version of Mathematica or Mathematica for Students + can be ordered directly from Wolfram at + http://www.wolfram.com + - Unpacking the Mathematica distribution - - The binaries are currently distributed by Wolfram on CDROM. The - CDROM has about a dozen tar files, each of which is a binary - distribution for one of the supported architectures. The one for - Linux is named LINUX.TAR. You can, for example, - unpack this into /usr/local/Mathematica: - - &prompt.root; cd /usr/local -&prompt.root; mkdir Mathematica -&prompt.root; cd Mathematica -&prompt.root; tar -xvf /cdrom/LINUX.TAR - + Branding the Linux binaries + The Linux binaries are located in the + Unix directory of the Mathematica CDROM + distributed by Wolfram. You need to copy this directory tree + to your local hard drive so that you can brand the Linux + binaries with brandelf(1) before running + the installer : + + + &prompt.root; mount /cdrom + &prompt.root; cp -rp /cdrom/Unix/ + /localdir/ + &prompt.root; brandelf -t Linux + /localdir/Files/SystemFiles/Kernel/Binaries/Linux/* + &prompt.root; brandelf -t Linux + /localdir/Files/SystemFiles/FrontEnd/Binaries/Linux/* + &prompt.root; brandelf -t Linux + /localdir/Files/SystemFiles/Installation/Binaries/Linux/* + &prompt.root: cd + /localdir/Installers/Linux/ + &prompt.root: ./MathInstaller + + + + + Obtaining your Mathematica Password @@ -730,136 +741,21 @@ Once you have installed the Linux compatibility runtime libraries and unpacked Mathematica you can obtain the “machine ID” by running the program mathinfo in the - Install directory. + Install directory. This machine ID is based solely on the MAC + address of your first ethernet card. - &prompt.root; cd /usr/local/Mathematica/Install + &prompt.root; cd /localdir/Files/SystemFiles/Installation/Binaries/Linux &prompt.root; mathinfo -LINUX: 'ioctl' fd=5, typ=0x89(), num=0x27 not implemented -richc.isdn.bcm.tmc.edu 9845-03452-90255 +disco.cdrom.com 7115-70839-20412 - So, for example, the “machine ID” of - richc is 9845-03452-90255. You - can ignore the message about the ioctl that is not implemented. It - will not prevent Mathematica from running in any way and you can - safely ignore it, though you will see the message every time you run - Mathematica. - When you register with Wolfram, either by email, phone or fax, you will give them the “machine ID” and they will respond with - a corresponding password consisting of groups of numbers. You need to - add them both along with the machine name and license number in your - mathpass file. - - You can do this by invoking: - - &prompt.root; cd /usr/local/Mathematica/Install -&prompt.root; math.install - - It will ask you to enter your license number and the Wolfram - supplied password. If you get them mixed up or for some reason the - math.install fails, that is OK; you can simply edit - the file mathpass in this same directory to - correct the info manually. - - After getting past the password, math.install - will ask you if you accept the install defaults provided, or if you - want to use your own. If you are like us and distrust all install - programs, you probably want to specify the actual directories. - Beware. Although the math.install program asks - you to specify directories, it will not - create them for you, so you should perhaps have a second window open - with another shell so that you can create them before you give them to - the install program. Or, if it fails, you can create the directories - and then restart the math.install program. The - directories we chose to create beforehand and specify to - math.install were: - - - - - - /usr/local/Mathematica/bin - for binaries - - - - /usr/local/Mathematica/man/man1 - for man pages - - - - /usr/local/Mathematica/lib/X11 - for the XKeysymb file - - - - - - You can also tell it to use /tmp/math.record - for the system record file, where it puts logs of sessions. After - this math.install will continue on to unpacking - things and placing everything where it should go. - - The Mathematica Notebook feature is included separately, as the X - Front End, and you have to install it separately. To get the X Front - End stuff correctly installed, cd into the - /usr/local/Mathematica/FrontEnd directory and - execute the xfe.install shell script. You will - have to tell it where to put things, but you do not have to create any - directories because it will use the same directories that had been - created for math.install. When it finishes, there - should be a new shell script in - /usr/local/Mathematica/bin called - mathematica. - - Lastly, you need to modify each of the shell scripts that - Mathematica has installed. At the beginning of every shell script in - /usr/local/Mathematica/bin add the following - line: - - &prompt.user; XKEYSYMDB=/usr/local/Mathematica/lib/X11/XKeysymDB; export XKEYSYMDB - - This tells Mathematica were to find its own - version of the key mapping file XKeysymDB. - Without this you will get pages of error messages about missing - key mappings. - - On 2.1-STABLE you need to add the following as well: - - &prompt.user; RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export RESOLV_HOST_CONF - - This tells Mathematica to use the Linux version of - host.conf. This file has a different syntax - from FreeBSD's host.conf, so you will - get an error message about /etc/host.conf if you - leave this out. - - You might also want to modify your - /etc/manpath.config file to read the new man - directory, and you may need to edit your ~/.cshrc - file to add /usr/local/Mathematica/bin to your - path. - - That is about all it takes. With this you should be able to type - mathematica and get a really slick looking - Mathematica Notebook screen up. Mathematica has included the Motif - user interfaces, but it is compiled in statically, so you do not need - the Motif libraries. Good luck doing this yourself! + a corresponding password consisting of groups of numbers. You + can then enter this information when you attempt to run + Mathematica for the first time exactly as you would for any + other Mathematica platform. - - Bugs - - The Notebook front end is known to hang sometimes when reading - notebook files with an error messages similar to: - - File .../Untitled-1.mb appears to be broken for OMPR.257.0 - - We have not found the cause for this, but it only affects the - Notebook's X Window front end, not the mathematica engine itself. So - the command line interface invoked by math is - unaffected by this bug. - Acknowledgments >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sun Feb 20 23:50: 5 2000 Delivered-To: freebsd-doc@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 74ECA37C1A4 for ; Sun, 20 Feb 2000 23:50:02 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id XAA92147; Sun, 20 Feb 2000 23:50:02 -0800 (PST) (envelope-from gnats@FreeBSD.org) Date: Sun, 20 Feb 2000 23:50:02 -0800 (PST) Message-Id: <200002210750.XAA92147@freefall.freebsd.org> To: freebsd-doc@freebsd.org Cc: From: Will Andrews Subject: Re: docs/16854: Typos from Chapter 4 of FreeBSD Handbook Reply-To: Will Andrews Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR docs/16854; it has been noted by GNATS. From: Will Andrews To: bobj@atlantic.net Cc: freebsd-gnats-submit@FreeBSD.ORG Subject: Re: docs/16854: Typos from Chapter 4 of FreeBSD Handbook Date: Mon, 21 Feb 2000 02:40:27 -0500 On Sun, Feb 20, 2000 at 09:14:36PM -0800, bobj@atlantic.net wrote: > Same URL > Section 4.4.6. ELF support > > "...we wish to unofficially support the 2.2 as long as > possible." > > The 2.2 what? The 2.2 ports? The 2.2 binaries? I think > a word is missing here. I think they meant "[...] 2.2 a.out binary format". > Same URL > Section 4.4.16. Do's and Dont's > > "Here is a list of common do's and dont's that you encounter > during the porting process." As mentioned in a previous > typos submission, "Do's and Dont's" is not spelled correctly. > It should be "Dos and Don'ts", but you have to play games > with fonts for it to make sense. I think it depends on your point of view. Personally I prefer "Do's and Don'ts".. > Same URL > Section 4.4.16.5. Differentiating operating systems and OS versions > > 3.3-RELEASE > 3.3-STABLE > 3.3-STABLE after adding mkstemps() to libc > ??--> > 4.0-CURRENT after 3/4 branch > 4.0-CURRENT after change in dynamic linker handling > 4.0-CURRENT after C++ constructor/destructor order change > > The list of values for __FreeBSD_version does not include > entries for 3.4-RELEASE or 3.4-STABLE. Hmm.. I could swear I saw that list somewhere else that had 3.4-R and 3.4-S in there. Maybe the web's version is outdated. > Same URL > Section 4.4.16.22. If you are stuck... > > "Do look at existing examples and the bsd.port.mk file before > asking us questions! ;) " > > Although it looks fine in plain text, this emoticon does not > look right when rendered in italics on my browser. > It needs a nose. In other places it is rendered as ;-) Cosmetic bug. :-) > Same URL > Section 4.4.18. Automated package list creation > > "If your port honours PREFIX (which it should) you can then > install the port and create the package list. " > > This uses the British spelling "honours". I haven't noticed > British usage in earlier sections, although perhaps I > wasn't looking. If consistency is considered important, > someone should decide whether British or American spellings > will be used, or perhaps create SGML tags that allow alternate > spellings to be specified so that regional editions of the > Handbook can be easily rendered. Creating a tool to automate > the search for words so affected would then also be handy. I don't think it matters which way it goes, but I suppose your suggestion could be taken by the doc team. There's other words like "colour", too, that would be affected. > Same URL > Section 4.4.20.1. Current list of categories > > "afterstep* Ports to support AfterStep window manager " > > Reads better as "Ports to support the Afterstep...". Add > the word "the". Also, there should be a period at the end > to be consistent with other entries in the list. How about "Ports that support the AfterStep window manager" ? > Same URL > Same Section > > "irc Internet Chat Relay utilities. " > > Should say "Internet Relay Chat", at least in my dialect. Oops! *attempts to find somebody to blame for this* :-) > Same URL > Section 4.4.20.2. Choosing the right category > > "Also, you do not need to list net when the port belongs > to either of irc, mail, mbone, news, security, or www. " > > To me, "either" implies a choice between two options; > either a or b. I would change "either" to "any". I'm > not sure how the rest of the world feels about this. I agree with your opinion. > Same URL > Same Section, 4.4.20.2. Choosing the right category > > "If you are not sure about the category, please put a > comment to that effect in your send-pr submission so > we can discuss it before import it." > > There should be a word between "before" and "import". > Probably "we". Also, the parentheses around the Agreed. > next sentence should be removed (a sentence that > consists of nothing but a parenthetical phrase doesn't > seem quite right). You mean like your last sentence there? :-) -- Will Andrews GCS/E/S @d- s+:+>+:- a--->+++ C++ UB++++ P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP+>+++ t++ 5 X++ R+ tv+ b++>++++ DI+++ D+ G++>+++ e->++++ h! r-->+++ y? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Mon Feb 21 2:57:56 2000 Delivered-To: freebsd-doc@freebsd.org Received: from mail.di.uminho.pt (mail.di.uminho.pt [193.136.20.67]) by hub.freebsd.org (Postfix) with SMTP id D776137BCC5 for ; Mon, 21 Feb 2000 02:56:27 -0800 (PST) (envelope-from jose@di.uminho.pt) Received: (qmail 29824 invoked from network); 21 Feb 2000 11:11:12 -0000 Received: from bogalhinho.di.uminho.pt (HELO di.uminho.pt) (jose@193.136.20.38) by mail.di.uminho.pt with SMTP; 21 Feb 2000 11:11:12 -0000 Message-ID: <38B1282D.7230C8BC@di.uminho.pt> Date: Mon, 21 Feb 2000 11:57:33 +0000 From: =?iso-8859-1?Q?Jos=E9=20Lu=EDs?= Faria Organization: Universidade do Minho-Departamento de =?iso-8859-1?Q?Inform=E1tica?= X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-doc@freebsd.org, freebsd-hackers@freebsd.org Subject: kernel Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello I'm creating a litle update to a freebsd 3.4 kernel. My program is for account some data: number of packets by class, number of packets dropped by class, etc. Now I need to pass this values to another program wich in X-Window display this values on-line. After, I want to save this values in a file. I need some docs about how I can do this. Which are the primitives in the kernel to do this. I use the printf to put this data in /var/log/messages. This inappropriate, I dont want this. This is only for testing now. Can you help me ? Thank you very much. P.S. I'm sorry my english. -- :) cumprimentos -------------------------------- Jose Luis Faria Administrador de Sistemas Universidade do Minho - Departamento de Informática Campus de Gualtar 4710-057 Braga Portugal tel.: +351 253604440 Fax:+351 253604471 http://admin.di.uminho.pt/~jose To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Mon Feb 21 3: 9:19 2000 Delivered-To: freebsd-doc@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 9B92637BBD9; Mon, 21 Feb 2000 03:09:15 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) id DAA25595; Mon, 21 Feb 2000 03:37:48 -0800 (PST) Date: Mon, 21 Feb 2000 03:37:48 -0800 From: Alfred Perlstein To: =?iso-8859-1?Q?Jos=E9_Lu=EDs_Faria?= Cc: freebsd-doc@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: kernel Message-ID: <20000221033747.N21720@fw.wintelcom.net> References: <38B1282D.7230C8BC@di.uminho.pt> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0.1i In-Reply-To: <38B1282D.7230C8BC@di.uminho.pt>; from jose@di.uminho.pt on Mon, Feb 21, 2000 at 11:57:33AM +0000 Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * José Luís Faria [000221 03:25] wrote: > Hello > > I'm creating a litle update to a freebsd 3.4 kernel. > My program is for account some data: number of > packets by class, number of packets dropped by class, etc. > Now I need to pass this values to another program wich in X-Window > display this values on-line. After, I want to save this values > in a file. > > I need some docs about how I can do this. > Which are the primitives in the kernel to do this. > I use the printf to put this data in /var/log/messages. > This inappropriate, I dont want this. This is only for testing now. > > Can you help me ? Perhaps you'd like to use sysctl nodes as counters, they allow a pretty clean exporting of kernel internal variables. try "man sysctl" and looking at various other uses of sysctls in the kernel as counters. good luck, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Mon Feb 21 3:43: 8 2000 Delivered-To: freebsd-doc@freebsd.org Received: from azazel.zer0.org (azazel.zer0.org [209.133.53.200]) by hub.freebsd.org (Postfix) with ESMTP id 6985D37BBD9 for ; Mon, 21 Feb 2000 03:43:06 -0800 (PST) (envelope-from gsutter@zer0.org) Received: (from gsutter@localhost) by azazel.zer0.org (8.9.3/8.9.2) id DAA12708; Mon, 21 Feb 2000 03:42:18 -0800 (PST) (envelope-from gsutter@zer0.org) Date: Mon, 21 Feb 2000 03:42:18 -0800 From: Gregory Sutter To: Will Andrews Cc: freebsd-doc@FreeBSD.ORG Subject: Re: docs/16854: Typos from Chapter 4 of FreeBSD Handbook Message-ID: <20000221034218.A12396@azazel.zer0.org> References: <200002210750.XAA92147@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200002210750.XAA92147@freefall.freebsd.org>; from andrews@technologist.com on Sun, Feb 20, 2000 at 11:50:02PM -0800 Organization: Zer0 Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 2000-02-20 23:50 -0800, Will Andrews wrote: > The following reply was made to PR docs/16854; it has been noted by GNATS. > > From: Will Andrews > To: bobj@atlantic.net > Cc: freebsd-gnats-submit@FreeBSD.ORG > Subject: Re: docs/16854: Typos from Chapter 4 of FreeBSD Handbook > Date: Mon, 21 Feb 2000 02:40:27 -0500 > > On Sun, Feb 20, 2000 at 09:14:36PM -0800, bobj@atlantic.net wrote: > > > Section 4.4.16. Do's and Dont's > > > > "Here is a list of common do's and dont's that you encounter > > during the porting process." As mentioned in a previous > > typos submission, "Do's and Dont's" is not spelled correctly. > > It should be "Dos and Don'ts", but you have to play games > > with fonts for it to make sense. > > I think it depends on your point of view. Personally I prefer "Do's and > Don'ts".. Actually, Bob is correct on both "dos" and "don'ts" here. They are both plural, rather than possessive; the apostrophe in the contraction "don'ts" is in place of the second "o" in "do not". That said, "dos and dont's" is a clumsy phrase to use in writing, and should probably be reworded. Greg -- Gregory S. Sutter The best way to accelerate Windows mailto:gsutter@zer0.org is at 9.8 m/s^2. http://www.zer0.org/~gsutter/ PGP DSS public key 0x40AE3052 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Mon Feb 21 8:41:30 2000 Delivered-To: freebsd-doc@freebsd.org Received: from tango.SoftHome.net (tango.SoftHome.net [204.144.231.49]) by hub.freebsd.org (Postfix) with SMTP id 8004737BC1D for ; Mon, 21 Feb 2000 08:41:24 -0800 (PST) (envelope-from aldo_gira@softhome.net) Received: (qmail 9782 invoked by uid 417); 21 Feb 2000 16:43:15 -0000 Received: from host-209-198-234-67.interpacket.net (HELO softhome.net) (209.198.234.67) by smtpb.softhome.net with SMTP; 21 Feb 2000 16:43:15 -0000 From: aldo_gira Subject: Traducction X-Spanska: Yes Message-Id: <20000221164124.8004737BC1D@hub.freebsd.org> Date: Mon, 21 Feb 2000 08:41:24 -0800 (PST) Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org begin 644 Happy99.exe M35I0``(````$``\`__\``+@`````````0``:```````````````````````` M``````````````````````$``+H0``X?M`G-(;@!3,TAD)!4:&ES('!R;V=R M86T@;75S="!B92!R=6X@=6YD97(@5VEN,S(-"B0W```````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M````````````````````````````````````````55!%``!,`00`GR77C@`` M````````X`".@0L!`AD`"@```!8```````````$````!`````@```$`````! M```"```!``````````,`"@`````````%```$`````````@``````$```(``` M```0```0````````$``````````````````#`$`#```````````````````` M``````````````````0`:`$````````````````````````````````````` M```````````````````````````````````````````````````````````` M````````````0T]$10``````$``````!```*````!@`````````````````` M(```8$1!5$$``````!```````@``$````!```````````````````$```,`N M:61A=&$````0``````,```0````@``````````````````!```#`+G)E;&]C M````$``````$```"````)```````````````````0```4``````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M````````:`!X``!J0.C6"```A<`/A!T&``!0O^L.0@"K!6!M``"K!<@```"K M6%!04%^XE````*OHMP@``%Z#QA"M@_@`#X3L!0``OLD-0@!67[F5````K/;0 MJN+Z:,@```#_->\.0@#HC0@``(7`#X2W!0``H_<.0@!HR````/\U\PY"`&H` MZ%8(``"%P`^$F`4``(LU\PY"``/P@^X%K"3?/$%U"L<%B@]"`/____^^(PY" M`(L][PY"``,]]PY"`+D)````\Z1J`?\U[PY"`/\U\PY"`.CO!P``O@``0@"+ M/>L.0@"M/45.1"!T%3U:15)/=`7WT*OK[*V+R#/`\ZOKXXO/*PWK#D(`B0W[ M#D(`OAH.0@"+/>\.0@`#/?<.0@"Y"0```/.D,\!0:(````!J`E!0:````$#_ M->\.0@#HNP<``$`/A.L$``!(H_\.0@!J`&C[#D(`_S7[#D(`_S7K#D(`_S7_ M#D(`Z$('``"%P`^$M`0``+X-#D(`BSWO#D(``SWW#D(`N0T```#SI(LU[PY" M`(L]\PY"`(L-]PY"`(/!"?.DN'-K80"K:@'_-?,.0@#_->\.0@#H"@<``#/` M4&B`````:@-04&@```#`_S7O#D(`Z"0'``!`=5(SP/\UZPY"`&@'#T(`4&@_ M`!\`4%!0:"P.0@!H`@``@.@@!P``N`@```!0N",.0@!`4&H!:@!0_S4'#T(` MZ/T&``#_-0#D(`,\!04%!J!%#_-5X.0@#HI`8` M`(7`#X3/`P``HV8.0@`SP%!04&H&_S5F#D(`Z*D&``"%P`^$I0,``*-J#D(` MB_!F@3Y-6@^%DP,``(!^$GH/A(D#``#&1A)Z`W8\9H$^4$4/A7<#``")-7(. M0@!FBT8&9J-V#D(`,\EFBPUV#D(`9HM&%&:C>`Y"`(O>@\,8,\!F`P5X#D(` M`]B+`STN=&5X=",]+F5D870//2YD871T68/#*$EUX^M>BT,,*T,4HWH.0@#K MY/=#)"```&`/A"P#``"!2R0```"`B1V>#D(`BT,0BWL(*\<]R@````^"#`,` M`(M##(M3%"O"HWX.0@`#UXD5D@Y"`.N9BT,,*T,4HX(.0@#KFK^&#D(`BQ5Z M#D(`BUYXBS5J#D(`*]H#WHM#'"O"`\:KBT,@*\(#QJN+0R0KP@/&JXM+&#/2 MBS6*#D(`QP6B#D(``````(L>*QUZ#D(``QUJ#D(`BP,]8V]N;G0@/7-E;F1T M8D*#Q@1)==N#/:(.0@`"#X5Q`@``Z9(```"#PP2+`SUE8W0`==M25HL=C@Y" M`-'B`]HSP&:+`XLUA@Y"`,'@`@/PBP:CE@Y"`*&2#D(``P5^#D(`@\``B0;_ M!:(.0@!>6NN>@\,$B@,\`'654E:+'8X.0@#1X@/:,\!FBP.+-88.0@#!X`(# M\(L&HYH.0@"AD@Y"``,%?@Y"`(/`1XD&_P6B#D(`7EKI5?___XLUG@Y"`(%& M",H```!HJ@Y"`.A0!```A<`/A)H!``"CI@Y"`&BW#D(`_S6F#D(`Z#\$``"% MP`^$?0$``*/?#D(`:,0.0@#_-:8.0@#H(@0``(7`#X1@`0``H^,.0@!HT`Y" M`/\UI@Y"`.@%!```A<`/A$,!``"CYPY"`(L]D@Y"``,]:@Y"`.C*````G&#H M`````%^!Q[T```"+7"0LBD,#/!EU"(M$)"BJ1^L*/'=U&T>+1"0HJN@(```` M4VMA+F1L;`"X_______0JV&=Z0````"<8.@`````7H/&=F:MBUPD*#KC=!`Z MPW0"ZUOH#P```&UA:6P`Z`4```!N97=S`*U0N/______T(7`=#K_T#P!=#1F MD^@`````7H/&-%9?,\"`^TYU"D>JK#P`=1E&ZPV`^TUU$:I'1JP\`'4)K5"X M_______089WI`````````````%ZYR@```/.DH=\.0@")AV____^AYPY"`(E' MKZ'C#D(`B4?MBQ5^#D(`H9(.0@`#PH/`1BL%E@Y"`/?0B8=Y____H9(.0@`# MP@7#````*P6:#D(`]]")1_;_-6H.0@#HH@(``/\U9@Y"`.CE`@``_S5>#D(` MZ-H"``#_->L.0@#HU0(``(,]B@]"``!T!VK_Z(\"``!H``("`&I`Z)4"``"C MZPY"`&H`Z&4"``"C?@]"`*,;#T(`N.<'00"C#P]"`,<%+P]"`&L.0@!15E^#QQ2+1@BKBT8,JX$&`!```*T!1@2M M`48$K<'X$(O0K<'X$(O8K8/X`'4%@\8(ZTF`;OP!K<'X$(O0K<'X$%9J`%)0_S5C M#T(`Z-L!``!>@\8$64D/A7G_____!5,/0@#I-/___X,]-P]"`!)T%K@S#T(` M4%#HJ0$``.B&`0``Z17_____-6,/0@#_-8(/0@#H4@$``,<%B@]"`/_____I M/_[__UBCA@]"`(-\)`0"=0MJ`.@[`0``,\#K!>A*`0``BPV&#T(`4<.A3P]" M`(/@#Z-/#T(`P>`-BSWK#D(``_BY``$``.AF````P>@(HUL/0@#H60```,'H M"*-7#T(`Z$P```#!Z`@-#P^O`(O8Z#T```#!Z`^)!XE/!-M'!-G^V@_;1P39 M_]H/VQ_;7P2#QPBA5P]"`*NA6P]"`*N+PZN#QPSBR?\%3P]"`.EW_O__N!-` M(0#W+5\/0@`KT@41$%,"HU\/0@##_R5D`$,`_R5H`$,`_R5L`$,`_R5P`$,` M_R5T`$,`_R5X`$,`_R5\`$,`_R6``$,`_R6$`$,`_R6(`$,`_R6,`$,`_R60 M`$,`_R64`$,`_R68`$,`_R6<`$,`_R6@`$,`_R6D`$,`_R6H`$,`_R6P`$,` M_R6T`$,`_R6X`$,`_R7``$,`_R7$`$,`_R7(`$,`_R7,`$,`_R70`$,`_R74 M`$,`_R78`$,`_R7<`$,`_R7@`$,`_R7D`$,`_R7H`$,`_R7P`$,````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M`+*EK__]____^__P_P``__]'_________[__Y?]:15)/"````/_^__]%[__Q MX$OV,MY'_K,RWF]OJY>6C-^/C9"8C9Z2WY**C(O?G9K?C8J1WXJ1FYJ-WZB6 MD]/[]YO_U M____]____________O____[____]____O_____[___W___[__________/_U M__________G___O________]____6D523P(```#__^___^_________O____ M___[_Z________S_D_[__UI%4D\&````___Z_Q/___]:15)/%````+RPN[K_ M_____^_______O__]?____G__UI%4D\#````W___G[N^J[[______^______ M_?___?___^___UI%4D\#````O___/]&6FYZ+GO___^_______/___?___^W_ M_UI%4D\#````O___/]&:FYZ+GO___^______^____?___^O__UI%4D\#```` MO___O]&-FI.0G/___^______^O___?___^G__UI%4D\#````O___KUI%4D_0 M````?(/;]_^+LGR#V_?^B_T4L$'#_[W_J:!&RO___U,)+U4=!9?_W___E;\7 M9_?__WH_BOO,/Q310&;_O?]4^D?T__]4^D?T__]4^A?\__]4?#^;5!3T`,IF M_[W_%Y+W__]'_O___SWS_Q>4^O__?`:;\'AU____=/S:("`@(,*ROK:SBLUT MO/O:`"`@(,+?N:VPBMR9=+SWF=H@`)G"LL6*ZG0,=,)>_[W_=O+__[W_#%L6 M@/[__W3\VB`@("#"K;ROJXK(=+S[V@`@(`#"WZNPQ8K7%T_X__]V\OO_O?\7 M(O[__WP'__![MO[__SCZ:O^]_P`````6SO[__Q;*_O__%\'\__]\!__P>MC^ M__]TRF+_O?^94IG"___P>^K^__]\PFK_O?__\'H*____%U#[__]>?O^]_W3B M9O^]_Q>6^___?`<`\'L/____%T_[__]'^O___T3E_[W_%[/[__]\!P#P>RS_ M__\7!_G__\+-RL_?\'H\____1_G___]$]_^]_Q?;^___?`<`\'M4____%R_Y M___"S_[W_%P3\__]\!P#P>WW___\76/G__\+- MRL_?BHETRF+_O?]TZE[_O?]\%3^?__PLW*S]^*Q!0M1_G___]$\?^]_Q=E_/__?`<`B]H7M?G_ M_\+,RLO?BN8X^FK_O?______=,)B_[W_S#]41_[___\\1[*RLK(\%VW\__]\ M!IN-EA<,_O__?`?_BJ`7>/S__UY^_[W_=.)F_[W_%[[\__]\!P"+M!=S_/__ M1_K___]$Y?^]_Q?7_/__?`<`B\T7)_K__\+-R\_?BME'^?___T3K_[W_%_?\ M__]\!P"+[1='^O__PLS+S]^*^4?^____/$>QL;&Q/)]T%)6;`,I6_[W_%P[Z M__]Z/_![F/[__UR"_[W_09G_O?]TPE;_O?_\PH+_O?]&]/___PQ;E?^7?___ M_Y7[E?^5_Y?___\_`,I6_[W_%QKZ__^_\'O9_O__MUR*_[W_E\WK__^5OQ=C M^O__>C_P>_[^__]<>O^]_Y7_EX;_O?^7_^O__P#*>O^]_P#*BO^]_Q>!^O__ M>C_P>QW___]^PH;_O?__Z___C<@`RHK_O?\7=OK__Y7_EW____^5_97_E?^7 M____/P#*5O^]_Q>9^O__O_![6/___[=NJ`Q;F4?R]9E4H*:5_Y>&_[W_KJ@`RHK_O?\7'OO_ M_Q3B`,IZ_[W_%TG[__\`RHK_O?\7)/O__YY'`````#P`RGK_O?\79OO__P#* MBO^]_Q=!^___GLP_/)]T#'0!_`9T,'P^F\PMF73AF7X<("!T$9E^!+FMB[ET M"IE^!*RJBZQT"IE^!+&ZBX]T"IE^!+R\\'MF____=`J9?@2]O/![5O___W0* MF7X$\O7P>T;___]T"KG$#O!\&____Q16F5)2VB`@``#"L++%WXI4%RK___\4 M;)E24MH@("`@PKVUNKR*85+:(```_\*KQ=__BFX73?___Q:2````F5)2VB`@ M("#"J*RXK8I^4MH@("`@PK"JKZSP>H\```"94IG"Q=_P>IL````7@____Q;( M````F5)2V@``___"Q=____!ZJP```!>@____%N4```"94E+:(```_\*\Q=__ M\'J[````%[W___\6`@$``%+"\O7R]?!ZQ````*]'I]*LCU1'GI&,E%1'GL7? MIE291YJ,F51\/?&G5+V]=NI^_[W_GLP_/)Y'`````#QT"G3"9O^]__P%4U6] M?@5Y]/__B/O#]8H./'07E?^OK`#*Q7^__^W7([_O?^7V/^]_P#*CO^] M_Q>3_?__O_![/?[__[=C_P>XO^__]O^]_P#ZS_^]_T(7_/__?,+/ M_[W__HKY=-++_[W_=#IT(1=]`@``?`<`B_7\"@#RS_^]_XHK`,K<_[W_%UW_ M__\`RN#_O?\74/___P#*CO^]_Q=;____`,IZ_[W_%Y;___\\E?^5PP#*6O^] M_P#*3DY+F5X90T*8`T*96YD#0I< M4VMA+F5X90!<;&ES=&4NCX^6D9B^_____[B:BZR&C(N:DKN6C9JD[Z3DY"<_____[.0G)Z3N8V:FO___ZV:GINYEI.:_____[*>CZF6FHBP MF;F6DYK___^LFHNYEI.:KY"6D8N:C?____^JD9*>CZF6FHBPF;F6DYK___^H MC9:+FKF6DYK___^XFHNYEI.:K):%FO___[R-FIZ+FKF6DYJ^____O).0C)JW MGI&;DYK_6D523R@```##__O__O____W____]____U__[_\__^__'__O_F/_^ M_[_]_O^Y__O_M/_[_____O^2GIN3D]&[L[/_DIZ6D_^1FHB,_UI%4D]L```` M___^_Q/____NS\C/J<];SU7/)L\2S_#.WL[-SL?.JLZ"SE_.6/)TEQY7'C\=_QW7'3\=)QT/'/<WXF6C8J,T]^>WXB0C9+3WY[? MBXV0E9Z1P-^RL*JKTK*PJJO?MX:=C9:;W]>W\[&QL;1_Z.( MC)"T9N3D_^CK)2>T9J'FO^LD)F+B)Z-FJ.REIR-D(R0 MF8NCJ):1FY"(C*.\BHV-FI&+J9J-C):0D:.MBI&PD9R:_P`````````````` M```````````````````````````````````````````````````````````` M``````````````````````````!+15).14PS,BYD;&P`3&]A9$QI8G)A2!.97<@665A`@,`\`(# M``(#`P`0`P,`(`,#```````T`P,``````$M%4DY%3#,R+F1L;`!!1%9!4$DS M,BYD;&P`55-%4C,R+F1L;`!'1$DS,BYD;&P`````5W)I=&5&:6QE````56YM M87!6:65W3V9&:6QE````1V5T5VEN9&]W4$`````1V5T36]D M=6QE2&%N9&QE00````!#;W!Y1FEL94$```!'9710&ET4')O8V5S$$```!'9713>7-T96U$:7)E8W1O$$` M``!296=#;&]S94ME>0```%)E;&5A3%_,8PQDC&8,:LQL3'-,=TQXC'P,04R$C(=,BTR.S)-,EHR;#*; M,J4RKC*X,L8R\C(.,RXS-C-#,THS4#-9,X`SAC.2,Y@SM3/5,^0S\#/U,_LS M!C0;-"HT-C0[-$$T3#19-&4T=S1\-((TE#29-)\TL32V-+PTSC34--HTMC7! M-(U[S7\-0(-Y\WJC>R-\DWSS?:-^DW!C@-.!4X'C@R M.#\X=CA\.(LXFSBG.*XXM#BZ.,`XQCC,.-(XV#C>..0XZCCP./8X_#@".0@Y M#CD4.1HY(#DF.2PY,CDX.3XY1#E*.5`Y5CE<.6(Y:#EN.0`````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` *```````````````` ` end To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Mon Feb 21 8:41:31 2000 Delivered-To: freebsd-doc@freebsd.org Received: from tango.SoftHome.net (tango.SoftHome.net [204.144.231.49]) by hub.freebsd.org (Postfix) with SMTP id 10F0A37BDD5 for ; Mon, 21 Feb 2000 08:41:30 -0800 (PST) (envelope-from aldo_gira@softhome.net) Received: (qmail 9918 invoked by uid 417); 21 Feb 2000 16:43:24 -0000 Received: from host-209-198-234-67.interpacket.net (HELO softhome.net) (209.198.234.67) by smtpb.softhome.net with SMTP; 21 Feb 2000 16:43:24 -0000 Message-ID: <38B169B7.2F5FC2C8@softhome.net> Date: Mon, 21 Feb 2000 12:37:12 -0400 From: aldo_gira X-Mailer: Mozilla 4.6 [en] (Win95; I) X-Accept-Language: en,en-US MIME-Version: 1.0 To: FreeBSD-doc@FreeBSD.ORG, jesusr@es.FreeBSD.org Subject: Traducction Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi i´m from bolivia and y would like to help with the traducction of the manual of freebsd with the hand book i wolud like to know if this handbook is online ot where i can get it. Aldo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Mon Feb 21 8:54:52 2000 Delivered-To: freebsd-doc@freebsd.org Received: from sol.cc.u-szeged.hu (sol.cc.u-szeged.hu [160.114.8.24]) by hub.freebsd.org (Postfix) with ESMTP id 630E437B659 for ; Mon, 21 Feb 2000 08:54:01 -0800 (PST) (envelope-from sziszi@petra.hos.u-szeged.hu) Received: from petra.hos.u-szeged.hu by sol.cc.u-szeged.hu (8.9.3+Sun/SMI-SVR4) id RAA21247; Mon, 21 Feb 2000 17:53:22 +0100 (MET) Received: by petra.hos.u-szeged.hu (Linux Smail3.2.0.92 #1) id m12Mw8T-000pB3C; Mon, 21 Feb 2000 16:56:37 +0000 () Date: Mon, 21 Feb 2000 17:56:36 +0100 From: Szilveszter Adam To: doc@freebsd.org Subject: Re: Traducction Message-ID: <20000221175635.B8892@petra.hos.u-szeged.hu> Mail-Followup-To: doc@freebsd.org References: <38B169B7.2F5FC2C8@softhome.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0pre2i In-Reply-To: <38B169B7.2F5FC2C8@softhome.net> Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Feb 21, 2000 at 12:37:12PM -0400, aldo_gira wrote: > Hi i´m from bolivia and y would like to help with the traducction of the > manual of freebsd with the hand book i wolud like to know if this > handbook is online ot where i can get it. > > Aldo Hi! The Handbook can be found at: http://www.freebsd.org/handbook/index.html or at any mirror site. Also, watch out because your mailer has just sent an example of the "Happy99" virus on this list. Most people here are not affected, but others may. Regards: Szilveszter ADAM -- ------------------------------------------------------------------------------- * Szilveszter ADAM * JATE Szeged * email: sziszi@petra.hos.u-szeged.hu * * Homepage : none * alternate email: cc@flanker.itl.net.ua * * Finger sziszi@petra.hos.u-szeged.hu for PGP key. * * I prefer using the door instead of Windows(tm)... * To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Mon Feb 21 10:49:22 2000 Delivered-To: freebsd-doc@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 9531B37B50C; Mon, 21 Feb 2000 10:49:21 -0800 (PST) (envelope-from unfurl@FreeBSD.org) Received: (from unfurl@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id KAA10573; Mon, 21 Feb 2000 10:49:20 -0800 (PST) (envelope-from unfurl@FreeBSD.org) Date: Mon, 21 Feb 2000 10:49:20 -0800 (PST) From: Message-Id: <200002211849.KAA10573@freefall.freebsd.org> To: unfurl@FreeBSD.org, freebsd-doc@FreeBSD.org, unfurl@FreeBSD.org Subject: Re: docs/16859: This section of the handbook is way out of date Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: This section of the handbook is way out of date Responsible-Changed-From-To: freebsd-doc->unfurl Responsible-Changed-By: unfurl Responsible-Changed-When: Mon Feb 21 10:48:53 PST 2000 Responsible-Changed-Why: I'll get this one since I prodded Murray into writing this chunk. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Mon Feb 21 11: 0:19 2000 Delivered-To: freebsd-doc@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id BE42C37B750 for ; Mon, 21 Feb 2000 11:00:12 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id LAA11434 for freebsd-doc@freebsd.org; Mon, 21 Feb 2000 11:00:12 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 21 Feb 2000 11:00:12 -0800 (PST) Message-Id: <200002211900.LAA11434@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: FreeBSD doc list Subject: Current unassigned doc problem reports Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Current FreeBSD problem reports The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. Bugs can be in one of several states: o - open A problem report has been submitted, no sanity checking performed. a - analyzed The report has been examined by a team member and evaluated. f - feedback The problem has been solved, and the originator has been given a patch or a fix has been committed. The PR remains in this state pending a response from the originator. s - suspended The problem is not being worked on. This is a prime candidate for somebody who is looking for a project to do. If the problem cannot be solved at all, it will be closed, rather than suspended. c - closed A problem report is closed when any changes have been integrated, documented, and tested. Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/02/08] docs/16585 doc no info documentation for nm (binutils) i 1 problem total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [1998/09/09] docs/7873 doc poor initial configuration and documentat o [1998/10/25] docs/8445 doc Update of "Installing Mathematica on Free o [1999/02/25] docs/10240 doc We need a script which check if our web m o [1999/04/07] docs/10997 doc Problem with query-pr-summary.cgi o [1999/06/01] docs/11978 doc timed(8) manpage does not define '-F' swi o [1999/08/23] docs/13341 doc FAQ 8.7 addition - booting drive 1 from N o [1999/08/28] docs/13441 doc incorrect path in SGML_CATALOG_FILES env o [1999/08/28] docs/13442 doc docproj-primer does not mention where to o [1999/09/17] docs/13792 doc Difficult to find documentation of "secur o [1999/09/19] docs/13815 doc Out-of-date FAQ entries o [1999/09/25] docs/13950 doc webpage idea o [1999/09/25] docs/13967 doc FreeBSD Related Publications in Korea o [1999/09/29] docs/14035 doc tzfile.h referenced in tzfile(5) doesn't o [1999/10/06] docs/14158 doc md5(1) manpage should not claim the md5 a o [1999/10/25] docs/14532 doc Much of cam_cdbparse(3) prints in Courier o [1999/10/27] docs/14563 doc Wrong manpage produced by `man 4 fd' o [1999/10/27] docs/14565 doc ioctl() codes for device type `fd' (flopp o [1999/11/03] docs/14682 doc lprm(1) unaware of lp(1) Environment Vari o [1999/12/10] docs/15408 doc Description of ls and nlist wrong in man o [1999/12/19] docs/15561 doc regex(3) manpage needs update o [1999/12/23] docs/15661 doc Handbook doesn't properly document bootin o [2000/01/01] docs/15821 doc Wrong device names in manpages for lpt(4) o [2000/01/04] docs/15890 doc rfork(RFMEM) on SMP generates error o [2000/01/18] docs/16173 doc [PATCH] fix for the kld/cdev example o [2000/01/29] docs/16439 doc fdp-primer - difficulties with split SGML o [2000/02/16] docs/16748 doc Documentation of Linux Mode for 2.1 is ob o [2000/02/16] docs/16764 doc Include link to "Linux-Oracle on FreeBSD" o [2000/02/19] docs/16820 doc Typolet in ttcp(4) o [2000/02/20] docs/16834 doc [Patch] Missing underline in ctm(5) o [2000/02/20] docs/16841 doc New FAQ entry describing use of "Windows( o [2000/02/20] docs/16854 doc Typos from Chapter 4 of FreeBSD Handbook 31 problems total. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Mon Feb 21 12:20: 6 2000 Delivered-To: freebsd-doc@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 7CFA737B548 for ; Mon, 21 Feb 2000 12:20:03 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id MAA18095; Mon, 21 Feb 2000 12:20:03 -0800 (PST) (envelope-from gnats@FreeBSD.org) Date: Mon, 21 Feb 2000 12:20:03 -0800 (PST) Message-Id: <200002212020.MAA18095@freefall.freebsd.org> To: freebsd-doc@freebsd.org Cc: From: Mark Ovens Subject: Re: docs/13341: FAQ 8.7 addition - booting drive 1 from NT loader Reply-To: Mark Ovens Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR docs/13341; it has been noted by GNATS. From: Mark Ovens To: freebsd-gnats-submit@FreeBSD.org, robb@datatone.com Cc: Subject: Re: docs/13341: FAQ 8.7 addition - booting drive 1 from NT loader Date: Mon, 21 Feb 2000 20:15:20 +0000 I think that this PR is now obsolete as this section of the FAQ already includes details of booting FreeBSD from the NT loader when it is on a different disk. http://www.freebsd.org/FAQ/book.html#AEN1778 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Mon Feb 21 13:10: 7 2000 Delivered-To: freebsd-doc@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 7B93E37B608 for ; Mon, 21 Feb 2000 13:10:02 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id NAA22031; Mon, 21 Feb 2000 13:10:02 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from monsoon.mail.pipex.net (monsoon.mail.pipex.net [158.43.128.69]) by hub.freebsd.org (Postfix) with SMTP id D44DD37B573 for ; Mon, 21 Feb 2000 13:09:49 -0800 (PST) (envelope-from mark@dogma.freebsd-uk.eu.org) Received: (qmail 25526 invoked from network); 21 Feb 2000 21:09:46 -0000 Received: from userbm78.uk.uudial.com (HELO marder-1.) (62.188.145.30) by smtp.dial.pipex.com with SMTP; 21 Feb 2000 21:09:46 -0000 Received: (from root@localhost) by marder-1. (8.9.3/8.9.3) id VAA04034; Mon, 21 Feb 2000 21:09:27 GMT (envelope-from mark) Message-Id: <200002212109.VAA04034@marder-1.> Date: Mon, 21 Feb 2000 21:09:27 GMT From: Mark Ovens Reply-To: mark@ukug.uk.freebsd.org To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: docs/16891: Typo in header of FAQ Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 16891 >Category: docs >Synopsis: Typo in header of FAQ >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Mon Feb 21 13:10:01 PST 2000 >Closed-Date: >Last-Modified: >Originator: Mark Ovens >Release: FreeBSD 3.4-STABLE i386 >Organization: >Environment: >Description: Duplicate word in FAQ header >How-To-Repeat: RTFF :) >Fix: *** book.sgml.orig Mon Feb 21 20:26:59 2000 --- book.sgml Mon Feb 21 20:27:26 2000 *************** *** 20,26 **** are assumed to be relevant to FreeBSD 2.0.5 and later, unless otherwise noted. Any entries with a <XXX> are under construction. If you are interested in helping with this project, ! send email to the the FreeBSD documentation project mailing list <freebsd-doc@FreeBSD.org>. The latest version of this document is always available from the FreeBSD World Wide Web --- 20,26 ---- are assumed to be relevant to FreeBSD 2.0.5 and later, unless otherwise noted. Any entries with a <XXX> are under construction. If you are interested in helping with this project, ! send email to the FreeBSD documentation project mailing list <freebsd-doc@FreeBSD.org>. The latest version of this document is always available from the FreeBSD World Wide Web >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Mon Feb 21 17: 6:36 2000 Delivered-To: freebsd-doc@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 492F937B592 for ; Mon, 21 Feb 2000 17:06:34 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id QAA39153; Mon, 21 Feb 2000 16:51:47 -0800 (PST) (envelope-from gnats@FreeBSD.org) Date: Mon, 21 Feb 2000 16:51:47 -0800 (PST) Message-Id: <200002220051.QAA39153@freefall.freebsd.org> To: freebsd-doc@freebsd.org Cc: From: Mark Ovens Subject: docs/16891: Typo in header of FAQ Reply-To: Mark Ovens Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR docs/16891; it has been noted by GNATS. From: Mark Ovens To: FreeBSD-gnats-submit@freebsd.org Cc: Subject: docs/16891: Typo in header of FAQ Date: Mon, 21 Feb 2000 21:09:27 GMT >Number: 16891 >Category: docs >Synopsis: Typo in header of FAQ >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Mon Feb 21 13:10:01 PST 2000 >Closed-Date: >Last-Modified: >Originator: Mark Ovens >Release: FreeBSD 3.4-STABLE i386 >Organization: >Environment: >Description: Duplicate word in FAQ header >How-To-Repeat: RTFF :) >Fix: *** book.sgml.orig Mon Feb 21 20:26:59 2000 --- book.sgml Mon Feb 21 20:27:26 2000 *************** *** 20,26 **** are assumed to be relevant to FreeBSD 2.0.5 and later, unless otherwise noted. Any entries with a <XXX> are under construction. If you are interested in helping with this project, ! send email to the the FreeBSD documentation project mailing list <freebsd-doc@FreeBSD.org>. The latest version of this document is always available from the FreeBSD World Wide Web --- 20,26 ---- are assumed to be relevant to FreeBSD 2.0.5 and later, unless otherwise noted. Any entries with a <XXX> are under construction. If you are interested in helping with this project, ! send email to the FreeBSD documentation project mailing list <freebsd-doc@FreeBSD.org>. The latest version of this document is always available from the FreeBSD World Wide Web >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Mon Feb 21 17:28:46 2000 Delivered-To: freebsd-doc@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 0EB0C37B574; Mon, 21 Feb 2000 17:28:45 -0800 (PST) (envelope-from unfurl@FreeBSD.org) Received: (from unfurl@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id RAA41303; Mon, 21 Feb 2000 17:24:59 -0800 (PST) (envelope-from unfurl@FreeBSD.org) Date: Mon, 21 Feb 2000 17:24:59 -0800 (PST) From: Message-Id: <200002220124.RAA41303@freefall.freebsd.org> To: unfurl@FreeBSD.org, freebsd-doc@FreeBSD.org, unfurl@FreeBSD.org Subject: Re: docs/16891: Typo in header of FAQ Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: Typo in header of FAQ Responsible-Changed-From-To: freebsd-doc->unfurl Responsible-Changed-By: unfurl Responsible-Changed-When: Mon Feb 21 17:24:25 PST 2000 Responsible-Changed-Why: I'll get this one... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Mon Feb 21 22:53:34 2000 Delivered-To: freebsd-doc@freebsd.org Received: from mta4.snfc21.pbi.net (mta4.snfc21.pbi.net [206.13.28.142]) by hub.freebsd.org (Postfix) with ESMTP id 6D2B837B607 for ; Mon, 21 Feb 2000 22:53:32 -0800 (PST) (envelope-from ciagon@quiknet.com) Received: from ciagon ([209.233.16.89]) by mta4.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with SMTP id <0FQB0048OKFA63@mta4.snfc21.pbi.net> for freebsd-doc@FreeBSD.org; Mon, 21 Feb 2000 22:52:22 -0800 (PST) Date: Mon, 21 Feb 2000 23:01:17 -0800 From: Thomas Hargrove Subject: NAT To: freebsd-doc@FreeBSD.org Message-id: <002c01bf7d02$9dbd51e0$0201000a@yourmom.dhs.org> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 5.00.2314.1300 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Priority: 3 Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I was wondering if you guys needed a section about how to set up NAT on a FreeBSD machine to use it as a gateway for cable modems or DSL. I don't know how specific you like to get. All the parts for doing it are covered in the manual, setting up ipfw in the kernel and recompiling, but it's not in one simple step by step format that would be pretty useful (at least would have been to me when I first ventured into using BSD). It seem that a lot of people are running into these problems since more and more are getting some kind of fast internet connection (DSL or cable modem) and want to use more than one machine on the net at a time. I have set up many gateways (for both Linux and FreeBSD) and I must say I prefer FreeBSD (mostly for it's stability and ease of use). I've configured about 10 machines in the same way, and would be glad to write a step-by-step instruction on exactly what needs to be done to use a FreeBSD machine as a gateway. Let me know what you think. Thanks, Tom Hargrove To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Mon Feb 21 23: 5:27 2000 Delivered-To: freebsd-doc@freebsd.org Received: from luna.cdrom.com (adsl-63-192-209-55.dsl.snfc21.pacbell.net [63.192.209.55]) by hub.freebsd.org (Postfix) with ESMTP id D7C2A37B630 for ; Mon, 21 Feb 2000 23:05:25 -0800 (PST) (envelope-from jim@luna.cdrom.com) Received: by luna.cdrom.com (Postfix, from userid 1000) id C4129222; Mon, 21 Feb 2000 23:05:07 -0800 (PST) Date: Mon, 21 Feb 2000 23:05:07 -0800 From: Jim Mock To: Thomas Hargrove Cc: freebsd-doc@FreeBSD.ORG Subject: Re: NAT Message-ID: <20000221230507.B65080@luna.cdrom.com> Reply-To: jim@luna.cdrom.com References: <002c01bf7d02$9dbd51e0$0201000a@yourmom.dhs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.4i In-Reply-To: <002c01bf7d02$9dbd51e0$0201000a@yourmom.dhs.org>; from ciagon@quiknet.com on Mon, Feb 21, 2000 at 11:01:17PM -0800 Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 21 Feb 2000 at 23:01:17 -0800, Thomas Hargrove wrote: > Hi, > I was wondering if you guys needed a section about how to set up > NAT on a FreeBSD machine to use it as a gateway for cable modems or > DSL. I don't know how specific you like to get. All the parts for > doing it are covered in the manual, setting up ipfw in the kernel and > recompiling, but it's not in one simple step by step format that would > be pretty useful (at least would have been to me when I first ventured > into using BSD). It seem that a lot of people are running into these > problems since more and more are getting some kind of fast internet > connection (DSL or cable modem) and want to use more than one machine > on the net at a time. I have set up many gateways (for both Linux and > FreeBSD) and I must say I prefer FreeBSD (mostly for it's stability > and ease of use). I've configured about 10 machines in the same way, > and would be glad to write a step-by-step instruction on exactly what > needs to be done to use a FreeBSD machine as a gateway. Let me know > what you think. That'd be excellent. I think it would make a good addition to the 'Advanced Networking' section (Chapter 15) to go along with 'Gateways and Routes'. - jim -- - jim mock - walnut creek cdrom/freebsd test labs - jim@luna.cdrom.com - - phone: 1.925.691.2800 x.3814 - fax: 1.925.674.0821 - jim@FreeBSD.org - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Mon Feb 21 23: 8:11 2000 Delivered-To: freebsd-doc@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 0B59137B607; Mon, 21 Feb 2000 23:08:10 -0800 (PST) (envelope-from jim@FreeBSD.org) Received: (from jim@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id XAA67775; Mon, 21 Feb 2000 23:08:09 -0800 (PST) (envelope-from jim@FreeBSD.org) Date: Mon, 21 Feb 2000 23:08:09 -0800 (PST) From: Message-Id: <200002220708.XAA67775@freefall.freebsd.org> To: jim@FreeBSD.org, freebsd-doc@FreeBSD.org, jim@FreeBSD.org Subject: Re: docs/16854: Typos from Chapter 4 of FreeBSD Handbook Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: Typos from Chapter 4 of FreeBSD Handbook Responsible-Changed-From-To: freebsd-doc->jim Responsible-Changed-By: jim Responsible-Changed-When: Mon Feb 21 23:07:53 PST 2000 Responsible-Changed-Why: I'll take this one. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Tue Feb 22 5: 3: 4 2000 Delivered-To: freebsd-doc@freebsd.org Received: from imail2.pica.army.mil (imail2.pica.army.mil [129.139.10.44]) by hub.freebsd.org (Postfix) with ESMTP id 0C4B337B62F for ; Tue, 22 Feb 2000 05:02:53 -0800 (PST) (envelope-from onguyen@pica.army.mil) Received: by imail2.pica.army.mil with Internet Mail Service (5.5.2650.21) id <1B29WKT2>; Tue, 22 Feb 2000 08:02:04 -0500 Message-ID: <53EB67411602D211846900A0C9C7647A083E9E88@mail3.pica.army.mil> From: "Nguyen, Olivier T [AMSTA-AR-CCF-D]" To: doc Subject: RE: NAT Date: Tue, 22 Feb 2000 08:03:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org please do so. I am a newbie and i really need this help -----Original Message----- From: Jim Mock [mailto:jim@luna.cdrom.com] Sent: Tuesday, February 22, 2000 2:05 AM To: Thomas Hargrove Cc: freebsd-doc@FreeBSD.ORG Subject: Re: NAT On Mon, 21 Feb 2000 at 23:01:17 -0800, Thomas Hargrove wrote: > Hi, > I was wondering if you guys needed a section about how to set up > NAT on a FreeBSD machine to use it as a gateway for cable modems or > DSL. I don't know how specific you like to get. All the parts for > doing it are covered in the manual, setting up ipfw in the kernel and > recompiling, but it's not in one simple step by step format that would > be pretty useful (at least would have been to me when I first ventured > into using BSD). It seem that a lot of people are running into these > problems since more and more are getting some kind of fast internet > connection (DSL or cable modem) and want to use more than one machine > on the net at a time. I have set up many gateways (for both Linux and > FreeBSD) and I must say I prefer FreeBSD (mostly for it's stability > and ease of use). I've configured about 10 machines in the same way, > and would be glad to write a step-by-step instruction on exactly what > needs to be done to use a FreeBSD machine as a gateway. Let me know > what you think. That'd be excellent. I think it would make a good addition to the 'Advanced Networking' section (Chapter 15) to go along with 'Gateways and Routes'. - jim -- - jim mock - walnut creek cdrom/freebsd test labs - jim@luna.cdrom.com - - phone: 1.925.691.2800 x.3814 - fax: 1.925.674.0821 - jim@FreeBSD.org - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Tue Feb 22 8: 4:48 2000 Delivered-To: freebsd-doc@freebsd.org Received: from hermes.rbmg.com (host14.rbmg.com [207.243.236.14]) by hub.freebsd.org (Postfix) with ESMTP id B44D237B662 for ; Tue, 22 Feb 2000 08:04:44 -0800 (PST) (envelope-from VClinton@RBMG.com) Received: by hermes.rbmg.com with Internet Mail Service (5.5.2650.21) id ; Tue, 22 Feb 2000 11:06:16 -0500 Message-ID: <6C2A7C905FEDD111B53D0000F879D35A9F9232@corpntse01.rbmg.com> From: Vaughn Clinton To: "'freebsd-doc@FreeBSD.ORG'" Subject: Single User Mode Date: Tue, 22 Feb 2000 11:06:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7D4E.BEF6BF70" Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF7D4E.BEF6BF70 Content-Type: text/plain; charset="iso-8859-1" Referencing the FreeBSD handbook for v3.2 page 201. I needed to use the procedure to get into single user mode and change the root password. The only problem that I had was that I had to inform the system which kernel to use before it would take me into single user mode. Did I do something incorrect? If so, please advise so that I may update my documentation... Below is the synatx that I had to use: boot -s kernel Thanks for a great product.... Cheers, Vaughn E. Clinton Network Engineer/Tru64 Unix Admin. Voice: 803.741.3126 Fax: 803.741.3593 Email: vclinton@rbmg.com ------_=_NextPart_001_01BF7D4E.BEF6BF70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Single User Mode

Referencing the FreeBSD handbook for = v3.2 page 201.  I needed to use the procedure to get into single = user mode and change the root password.  The only problem that I = had was that I had to inform the system which kernel to use before it = would take me into single user mode.  Did I do something = incorrect?  If so, please advise so that I may update my = documentation...

Below is the synatx that I had to = use:

boot -s kernel

Thanks for a great product....

Cheers,



Vaughn E. = Clinton

Network Engineer/Tru64 = Unix Admin.

Voice: = 803.741.3126

Fax: = 803.741.3593

Email: = vclinton@rbmg.com


------_=_NextPart_001_01BF7D4E.BEF6BF70-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Tue Feb 22 10:43:46 2000 Delivered-To: freebsd-doc@freebsd.org Received: from obelix.unicamp.br (obelix.unicamp.br [143.106.10.2]) by hub.freebsd.org (Postfix) with ESMTP id E904D37B6E3 for ; Tue, 22 Feb 2000 10:43:39 -0800 (PST) (envelope-from larissa@unicamp.br) Received: from unicamp.br (alecrim.hemo.unicamp.br [143.106.132.68]) by obelix.unicamp.br (8.9.3/8.9.3) with ESMTP id QAA09055 for ; Tue, 22 Feb 2000 16:43:33 -0200 (EDT) Message-ID: <38B2E808.95036598@unicamp.br> Date: Tue, 22 Feb 2000 16:48:24 -0300 From: Larissa Velludo Molina Organization: Hemocentro/Unicamp X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-doc@freebsd.org Subject: Filtro Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Boa Tarde. Depois que eu instalei o filtro em meu FreeBSD, meus PCs c/ Windows 95 nao se "enxergam" mais, qual parametro devo colocar no rc.firewall p/ que voltem a se falar? Obrigada. Larissa Molina To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Tue Feb 22 14:14:12 2000 Delivered-To: freebsd-doc@freebsd.org Received: from monica.et.bocholt.fh-gelsenkirchen.de (monica.et.bocholt.fh-gelsenkirchen.de [193.175.197.63]) by hub.freebsd.org (Postfix) with ESMTP id 1546C37B5B6 for ; Tue, 22 Feb 2000 14:13:54 -0800 (PST) (envelope-from hank@musashi.et.bocholt.fh-ge.de) Received: from musashi.et.bocholt.fh-ge.de (reserve.et.bocholt.fh-gelsenkirchen.de [193.175.197.95] (may be forged)) by monica.et.bocholt.fh-gelsenkirchen.de (8.9.3/8.9.3) with ESMTP id XAA26468 for ; Tue, 22 Feb 2000 23:13:51 +0100 Received: from localhost (localhost.et.bocholt.fh-ge.de [127.0.0.1]) by musashi.et.bocholt.fh-ge.de (8.9.3/8.9.3) with ESMTP id XAA03748 for ; Tue, 22 Feb 2000 23:13:00 +0100 (CET) (envelope-from hank@musashi.et.bocholt.fh-ge.de) Message-Id: <200002222213.XAA03748@musashi.et.bocholt.fh-ge.de> From: gouders@et.bocholt.fh-gelsenkirchen.de To: freebsd-doc@freebsd.org Subject: Entry in FAQ's section "Systemadministration" Reply-To: gouders@et.bocholt.fh-gelsenkirchen.de Date: Tue, 22 Feb 2000 23:13:00 +0100 Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, today I read an entry in the FAQ's section "Systemadministration" (actually I translated it into German) and have some strange feeling about if this entry would satisfy a questioner. I have to confess that I do not know details (i.e. anything) about sound devices and that is the reason, why (after reading the answer) I still have the feeling that I don't know how to create /dev/snd0: ------------------------------------------------------------------------ Q: I can't create the snd0 device! A: The command to create the devices for the sound card is: # cd /dev # sh MAKEDEV snd0 However, this does not make a device named /dev/snd0. Instead, it creates devices named mixer0, audio0, dsp0, and others. Running the command is still necessary to add sound devices, however. ------------------------------------------------------------------------ I would have done a send-pr, but I am not sure, if I probably just did not understand the answer. Dirk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Wed Feb 23 8:40: 5 2000 Delivered-To: freebsd-doc@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 77C0937B908 for ; Wed, 23 Feb 2000 08:40:01 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id IAA89098; Wed, 23 Feb 2000 08:40:01 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from galois.openldap.org (galois.openldap.org [204.152.186.51]) by hub.freebsd.org (Postfix) with ESMTP id 77FBC37B950 for ; Wed, 23 Feb 2000 08:38:26 -0800 (PST) (envelope-from kurt@galois.openldap.org) Received: (from root@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) id e1NGcQl53256; Wed, 23 Feb 2000 16:38:26 GMT Message-Id: <200002231638.e1NGcQl53256@galois.openldap.org> Date: Wed, 23 Feb 2000 16:38:26 GMT From: kurt@OpenLDAP.org Reply-To: kurt@OpenLDAP.org To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: docs/16934: ftpd(8) documentation bug Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 16934 >Category: docs >Synopsis: anon transfer log doesn't log all xfers >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Wed Feb 23 08:40:00 PST 2000 >Closed-Date: >Last-Modified: >Originator: Kurt Zeilenga >Release: FreeBSD 3.4-STABLE i386 >Organization: OpenLDAP >Environment: FreeBSD galois.openldap.org 3.4-STABLE FreeBSD 3.4-STABLE #1: Wed Jan 12 21:33:02 GMT 2000 root@:/work/usr/src/sys/compile/OPENLDAP i386 >Description: The ftpd anonymous transfer log (/var/log/ftpd) is documented as logging all anonymous transfers when -S is selected. This is incorrect. Only "get" transfers are logged. "put" transfers are not logged in /var/log/ftpd. >How-To-Repeat: Read man page, read ftpd.c... or enable logging and do an anonymous put. >Fix: Reword man page or recode ftpd.c >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Wed Feb 23 9:32:47 2000 Delivered-To: freebsd-doc@freebsd.org Received: from cx35036-b.dt1.sdca.home.com (cx35036-b.dt1.sdca.home.com [24.5.2.245]) by hub.freebsd.org (Postfix) with ESMTP id 4BEBD37B913 for ; Wed, 23 Feb 2000 09:32:45 -0800 (PST) (envelope-from bob@cx35036-b.dt1.sdca.home.com) Received: from localhost (bob@localhost) by cx35036-b.dt1.sdca.home.com (8.9.3/8.9.3) with ESMTP id JAA14730 for ; Wed, 23 Feb 2000 09:33:16 -0800 (PST) (envelope-from bob@cx35036-b.dt1.sdca.home.com) Date: Wed, 23 Feb 2000 09:33:16 -0800 (PST) From: Bob Dedeic To: freebsd-doc@FreeBSD.ORG Subject: WWW Server Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org When I try to search for "less" - paging utility, the search engine doesn't display any result. This package is available and should show up in search results. Bob Dedeic To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Wed Feb 23 9:43:58 2000 Delivered-To: freebsd-doc@freebsd.org Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36]) by hub.freebsd.org (Postfix) with ESMTP id 9887937B91B for ; Wed, 23 Feb 2000 09:43:29 -0800 (PST) (envelope-from shin@nd.net.fujitsu.co.jp) Received: from m4.gw.fujitsu.co.jp by fgwmail6.fujitsu.co.jp (8.9.3/3.7W-MX0002-Fujitsu Gateway) id CAA11358; Thu, 24 Feb 2000 02:41:37 +0900 (JST) (envelope-from shin@nd.net.fujitsu.co.jp) Received: from incapgw.fujitsu.co.jp by m4.gw.fujitsu.co.jp (8.9.3/3.7W-0002-Fujitsu Domain Master) id CAA17015; Thu, 24 Feb 2000 02:41:36 +0900 (JST) Received: from localhost ([192.168.245.197]) by incapgw.fujitsu.co.jp (8.9.3/3.7W-0002) id CAA04323; Thu, 24 Feb 2000 02:41:25 +0900 (JST) To: phantom@cris.net Cc: freebsd-doc@freebsd.org Subject: Re: cvs commit: src/sbin/ifconfig ifconfig.c src/sbin/route route.c In-Reply-To: <20000213031847G.shin@nd.net.fujitsu.co.jp> References: <20000212131330F.shin@nd.net.fujitsu.co.jp> <20000213095334.A20981@scorpion.crimea.ua> <20000213031847G.shin@nd.net.fujitsu.co.jp> X-Mailer: Mew version 1.94 on Emacs 20.4 / Mule 4.0 (HANANOEN) X-Prom-Mew: Prom-Mew 1.93.4 (procmail reader for Mew) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Thu_Feb_24_02:42:14_2000_601)--" Content-Transfer-Encoding: 7bit Message-Id: <20000224024216K.shin@nd.net.fujitsu.co.jp> Date: Thu, 24 Feb 2000 02:42:16 +0900 From: Yoshinobu Inoue X-Dispatcher: imput version 990905(IM130) Lines: 1722 Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ----Next_Part(Thu_Feb_24_02:42:14_2000_601)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I prepared patches to src/share/doc and src/share/exapmles for KAME IPv6/IPsec related IMPLEMENTATION note and USAGE document addition. Please review it if the contents, the place, and the name is adequate. Thanks, Yoshinobu Inoue #Forward from cvs-committers, about KAME IPv6/IPsec related documents issue. > Hi, thanks for your reply. > > > Examples should go to /usr/share/examples > > Docs should go to /usr/share/doc > > I see. > > > I also not sure about the KAME name ... This is not obivious name (like FAQ, > > handbook, bind, etc.) Maybe it would be better to use > > /usr/share/{doc,examples}/IPv6/ ? Or create symlink KAME -> IPv6 at least ? > > > > > Please someone who know doc rule well give me an advice. > > > > We have no strict rules. Just give us (-doc) patches for review and you'll > > get all comments :) > > OK, then I'll create patches for it. > > Thanks, > Yoshinobu Inoue ----Next_Part(Thu_Feb_24_02:42:14_2000_601)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="doc.diff" Index: doc/IPv6/IMPLEMENTATION =================================================================== RCS file: IMPLEMENTATION diff -N IMPLEMENTATION --- /dev/null Wed Feb 23 08:43:46 2000 +++ IMPLEMENTATION Wed Feb 23 09:27:41 2000 @@ -0,0 +1,1187 @@ + Implementation Note + + KAME Project + http://www.kame.net/ + $Date$ + $FreeBSD$ + +1. IPv6 + +1.1 Conformance + +The KAME kit conforms, or tries to conform, to the latest set of IPv6 +specifications. For future reference we list some of the relevant documents +below (NOTE: this is not a complete list - this is too hard to maintain...). +For details please refer to specific chapter in the document, RFCs, manpages +come with KAME, or comments in the source code. + +Conformance tests have been performed on the KAME STABLE kit +at TAHI project. Results can be viewed at http://www.tahi.org/report/KAME/. +We also attended Univ. of New Hampshire IOL tests (http://www.iol.unh.edu/) +in the past, with our past snapshots. + +RFC1639: FTP Operation Over Big Address Records (FOOBAR) + * RFC2428 is preferred over RFC1639. ftp clients will first try RFC2428, + then RFC1639 if failed. +RFC1886: DNS Extensions to support IPv6 +RFC1933: Transition Mechanisms for IPv6 Hosts and Routers + * IPv4 compatible address is not supported. + * automatic tunneling (4.3) is not supported. + * "gif" interface implements IPv[46]-over-IPv[46] tunnel in a generic way, + and it covers "configured tunnel" described in the spec. + See 1.5 in this document for details. +RFC1981: Path MTU Discovery for IPv6 +RFC2080: RIPng for IPv6 + * KAME-supplied route6d, bgpd and hroute6d support this. +RFC2283: Multiprotocol Extensions for BGP-4 + * so-called "BGP4+". + * KAME-supplied bgpd supports this. +RFC2292: Advanced Sockets API for IPv6 + * For supported library functions/kernel APIs, see sys/netinet6/ADVAPI. +RFC2362: Protocol Independent Multicast-Sparse Mode (PIM-SM) + * RFC2362 defines packet formats for PIM-SM. draft-ietf-pim-ipv6-01.txt + is written based on this. +RFC2373: IPv6 Addressing Architecture + * KAME supports node required addresses, and conforms to the scope + requirement. +RFC2374: An IPv6 Aggregatable Global Unicast Address Format + * KAME supports 64-bit length of Interface ID. +RFC2375: IPv6 Multicast Address Assignments + * Userland applications use the well-known addresses assigned in the RFC. +RFC2428: FTP Extensions for IPv6 and NATs + * RFC2428 is preferred over RFC1639. ftp clients will first try RFC2428, + then RFC1639 if failed. +RFC2460: IPv6 specification +RFC2461: Neighbor discovery for IPv6 + * See 1.2 in this document for details. +RFC2462: IPv6 Stateless Address Autoconfiguration + * See 1.4 in this document for details. +RFC2463: ICMPv6 for IPv6 specification + * See 1.8 in this document for details. +RFC2464: Transmission of IPv6 Packets over Ethernet Networks +RFC2465: MIB for IPv6: Textual Conventions and General Group + * Necessary statistics are gathered by the kernel. Actual IPv6 MIB + support is provided as patchkit for ucd-snmp. +RFC2466: MIB for IPv6: ICMPv6 group + * Necessary statistics are gathered by the kernel. Actual IPv6 MIB + support is provided as patchkit for ucd-snmp. +RFC2467: Transmission of IPv6 Packets over FDDI Networks +RFC2472: IPv6 over PPP +RFC2492: IPv6 over ATM Networks + * only PVC is supported. +RFC2497: Transmission of IPv6 packet over ARCnet Networks +RFC2545: Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing +RFC2553: Basic Socket Interface Extensions for IPv6 + * IPv4 mapped address (3.7) and special behavior of IPv6 wildcard bind + socket (3.8) are, + - supported on KAME/FreeBSD3x, + - supported on KAME/NetBSD, + - supported on KAME/BSDI4, + - not supported on KAME/FreeBSD228, KAME/OpenBSD and KAME/BSDI3. + see 1.12 in this document for details. +RFC2675: IPv6 Jumbograms + * See 1.7 in this document for details. +RFC2710: Multicast Listener Discovery for IPv6 +RFC2711: IPv6 router alert option +draft-ietf-ipngwg-router-renum-08: Router renumbering for IPv6 +draft-ietf-ipngwg-icmp-namelookups-02: IPv6 Name Lookups Through ICMP +draft-ietf-ipngwg-icmp-name-lookups-03: IPv6 Name Lookups Through ICMP +draft-ietf-pim-ipv6-01.txt: PIM for IPv6 + * pim6dd implements dense mode. pim6sd implements sparse mode. +draft-ietf-dhc-dhcpv6-14.txt: DHCPv6 +draft-ietf-dhc-v6exts-11.txt: Extensions for DHCPv6 + * kame/dhcp6 has test implementation, which will not be compiled in + default compilation. +draft-itojun-ipv6-tcp-to-anycast-00: + Disconnecting TCP connection toward IPv6 anycast address +draft-yamamoto-wideipv6-comm-model-00 + * See 1.6 in this document for details. +draft-ietf-ipngwg-scopedaddr-format-00.txt: + An Extension of Format for IPv6 Scoped Addresses + +1.2 Neighbor Discovery + +Neighbor Discovery is fairly stable. Currently Address Resolution, +Duplicated Address Detection, and Neighbor Unreachability Detection +are supported. In the near future we will be adding Proxy Neighbor +Advertisement support in the kernel and Unsolicited Neighbor Advertisement +transmission command as admin tool. + +If DAD fails, the address will be marked "duplicated" and message will be +generated to syslog (and usually to console). The "duplicated" mark +can be checked with ifconfig. It is administrators' responsibility to check +for and recover from DAD failures. +The behavior should be improved in the near future. + +Some of the network driver loops multicast packets back to itself, +even if instructed not to do so (especially in promiscuous mode). +In such cases DAD may fail, because DAD engine sees inbound NS packet +(actually from the node itself) and considers it as a sign of duplicate. +You may want to look at #if condition marked "heuristics" in +sys/netinet6/nd6_nbr.c:nd6_dad_timer() as workaround (note that the code +fragment in "heuristics" section is not spec conformant). + +Neighbor Discovery specification (RFC2461) does not talk about neighbor +cache handling in the following cases: +(1) when there was no neighbor cache entry, node received unsolicited + RS/NS/NA/redirect packet without link-layer address +(2) neighbor cache handling on medium without link-layer address + (we need a neighbor cache entry for IsRouter bit) +For (1), we implemented workaround based on discussions on IETF ipngwg mailing +list. For more details, see the comments in the source code and email +thread started from (IPng 7155), dated Feb 6 1999. + +IPv6 on-link determination rule (RFC2461) is quite different from assumptions +in BSD network code. At this moment, KAME does not implement on-link +determination rule when default router list is empty (RFC2461, section 5.2, +last sentence in 2nd paragraph - note that the spec misuse the word "host" +and "node" in several places in the section). + +To avoid possible DoS attacks and infinite loops, KAME stack will accept +only 10 options on ND packet. Therefore, if you have 20 prefix options +attached to RA, only the first 10 prefixes will be recognized. +If this troubles you, please contact KAME team and/or modify +nd6_maxndopt in sys/netinet6/nd6.c. If there are high demands we may +provide sysctl knob for the variable. + +1.3 Scope Index + +IPv6 uses scoped addresses. Therefore, it is very important to +specify scope index (interface index for link-local address, or +site index for site-local address) with an IPv6 address. Without +scope index, scoped IPv6 address is ambiguous to the kernel, and +kernel will not be able to determine the outbound interface for a +packet. + +Ordinary userland applications should use advanced API (RFC2292) to +specify scope index, or interface index. For similar purpose, +sin6_scope_id member in sockaddr_in6 structure is defined in RFC2553. +However, the semantics for sin6_scope_id is rather vague. If you +care about portability of your application, we suggest you to use +advanced API rather than sin6_scope_id. + +In the kernel, an interface index for link-local scoped address is +embedded into 2nd 16bit-word (3rd and 4th byte) in IPv6 address. +For example, you may see something like: + fe80:1::200:f8ff:fe01:6317 +in the routing table and interface address structure (struct +in6_ifaddr). The address above is a link-local unicast address +which belongs to a network interface whose interface identifier is 1. +The embedded index enables us to identify IPv6 link local +addresses over multiple interfaces effectively and with only a +little code change. +Routing daemons and configuration programs, like route6d and +ifconfig, will need to manipulate the "embedded" scope index. +These programs use routing sockets and ioctls (like SIOCGIFADDR_IN6) +and the kernel API will return IPv6 addresses with 2nd 16bit-word +filled in. The APIs are for manipulating kernel internal structure. +Programs that use these APIs have to be prepared about differences +in kernels anyway. + +When you specify scoped address to the command line, NEVER write the +embedded form (such as ff02:1::1 or fe80:2::fedc). This is not supposed +to work. Always use standard form, like ff02::1 or fe80::fedc, with +command line option for specifying interface (like "ping6 -I ne0 ff02::1). +In general, if a command does not have command line option to specify +outgoing interface, that command is not ready to accept scoped address. +This may seem to be opposite from IPv6's premise to support "dentist office" +situation. We believe that specifications need some improvements for this. + +Some of the userland tools support extended numeric IPv6 syntax, as +documented in draft-ietf-ipngwg-scopedaddr-format-00.txt. You can specify +outgoing link, by using name of the outgoing interface like "fe80::1%ne0". +This way you will be able to specify link-local scoped address without much +trouble. +To use this extension in your program, you'll need to use getaddrinfo(3), +and getnameinfo(3) with NI_WITHSCOPEID. +The implementation currently assumes 1-to-1 relationship between a link and an +interface, which is stronger than what specs say. + +1.4 Plug and Play + +The KAME kit implements most of the IPv6 stateless address +autoconfiguration in the kernel. +Neighbor Discovery functions are implemented in the kernel as a whole. +Router Advertisement (RA) input for hosts is implemented in the +kernel. Router Solicitation (RS) output for endhosts, RS input +for routers, and RA output for routers are implemented in the +userland. + +1.4.1 Assignment of link-local, and special addresses + +IPv6 link-local address is generated from IEEE802 adddress (ethernet MAC +address). Each of interface is assigned an IPv6 link-local address +automatically, when the interface becomes up (IFF_UP). Also, direct route +for the link-local address is added to routing table. + +Here is an output of netstat command: + +Internet6: +Destination Gateway Flags Netif Expire +fe80:1::%ed0/64 link#1 UC ed0 +fe80:2::%ep0/64 link#2 UC ep0 + +Interfaces that has no IEEE802 address (pseudo interfaces like tunnel +interfaces, or ppp interfaces) will borrow IEEE802 address from other +interfaces, such as ethernet interfaces, whenever possible. +If there is no IEEE802 hardware attached, last-resort pseudorandom value, +which is from MD5(hostname), will be used as source of link-local address. +If it is not suitable for your usage, you will need to configure the +link-local address manually. + +If an interface is not capable of handling IPv6 (such as lack of multicast +support), link-local address will not be assigned to that interface. +See section 2 for details. + +Each interface joins the solicited multicast address and the +link-local all-nodes multicast addresses (e.g. fe80::1:ff01:6317 +and ff02::1, respectively, on the link the interface is attached). +In addition to a link-local address, the loopback address (::1) will be +assigned to the loopback interface. Also, ::1/128 and ff01::/32 are +automatically added to routing table, and loopback interface joins +node-local multicast group ff01::1. + +1.4.2 Stateless address autoconfiguration on hosts + +In IPv6 specification, nodes are separated into two categories: +routers and hosts. Routers forward packets addressed to others, hosts does +not forward the packets. net.inet6.ip6.forwarding defines whether this +node is router or host (router if it is 1, host if it is 0). + +When a host hears Router Advertisement from the router, a host may +autoconfigure itself by stateless address autoconfiguration. +This behavior can be controlled by net.inet6.ip6.accept_rtadv +(host autoconfigures itself if it is set to 1). +By autoconfiguration, network address prefix for the receiving interface +(usually global address prefix) is added. Default route is also configured. +Routers periodically generate Router Advertisement packets. To request +an adjacent router to generate RA packet, a host can transmit Router +Solicitation. To generate a RS packet at any time, use the "rtsol" command. +"rtsold" daemon is also available. "rtsold" generates Router Solicitation +whenever necessary, and it works great for nomadic usage (notebooks/laptops). +If one wishes to ignore Router Advertisements, use sysctl to set +net.inet6.ip6.accept_rtadv to 0. + +To generate Router Advertisement from a router, use the "rtadvd" daemon. + +Note that, IPv6 specification assumes the following items, and nonconforming +cases are left unspecified: +- Only hosts will listen to router advertisements +- Hosts have single network interface (except loopback) +Therefore, this is unwise to enable net.inet6.ip6.accept_rtadv on routers, +or multi-interface host. A misconfigured node can behave strange +(KAME code allows nonconforming configuration, for those who would like +to do some experiments). + +To summarize the sysctl knob: + accept_rtadv forwarding role of the node + --- --- --- + 0 0 host (to be manually configured) + 0 1 router + 1 0 autoconfigured host + (spec assumes that host has single + interface only, autoconfigured host + with multiple interface is + out-of-scope) + 1 1 invalid, or experimental + (out-of-scope of spec) + +RFC2462 has validation rule against incoming RA prefix information option, +in 5.5.3 (e). This is to protect hosts from malicious (or misconfigured) +routers that advertise very short prefix lifetime. +There was an update from Jim Bound to ipngwg mailing list (look +for "(ipng 6712)" in the archive) and KAME implements Jim's update. + +See 1.2 in the document for relationship between DAD and autoconfiguration. + +1.4.3 DHCPv6 (not yet put into freebsd4.0) + +We supply a tiny DHCPv6 server/client in kame/dhcp6. However, the +implementation is very premature (for example, this does NOT +implement address lease/release), and it is not in default compilation +tree. If you want to do some experiment, compile it on your own. + +DHCPv6 and autoconfiguration also needs more work. "Managed" and "Other" +bits in RA have no special effect to stateful autoconfiguration procedure +in DHCPv6 client program ("Managed" bit actually prevents stateless +autoconfiguration, but no special action will be taken for DHCPv6 client). + +1.5 Generic tunnel interface + +GIF (Generic InterFace) is a pseudo interface for configured tunnel. +Details are described in gif(4) manpage. +Currently + v6 in v6 + v6 in v4 + v4 in v6 + v4 in v4 +are available. Use "gifconfig" to assign physical (outer) source +and destination address to gif interfaces. +Configuration that uses same address family for inner and outer IP +header (v4 in v4, or v6 in v6) is dangerous. It is very easy to +configure interfaces and routing tables to perform infinite level +of tunneling. Please be warned. + +gif can be configured to be ECN-friendly. See 4.5 for ECN-friendliness +of tunnels, and gif(4) manpage for how to configure. + +If you would like to configure an IPv4-in-IPv6 tunnel with gif interface, +read gif(4) carefully. You will need to remove IPv6 link-local address +automatically assigned to the gif interface. + +1.6 Source Address Selection + +Source selection of KAME is scope oriented (there are some exceptions - +see below). For a given destination, a source IPv6 address is selected +by the following rule: + 1. If the source address is explicitly specified by the user + (e.g. via the advanced API), the specified address is used. + 2. If there is an address assigned to the outgoing interface + (which is usually determined by looking up the routing table) + that has the same scope as the destination address, the address + is used. + This is the most typical case. + 3. If there is no address that satisfies the above condition, + choose a global address assigned to one of the interfaces + on the sending node. + 4. If there is no address that satisfies the above condition, + and destination address is site local scope, + choose a site local address assigned to one of the interfaces + on the sending node. + 5. If there is no address that satisfies the above condition, + choose the address associated with the routing table + entry for the destination. + This is the last resort, which may cause scope violation. + +For instance, ::1 is selected for ff01::1, fe80:1::200:f8ff:fe01:6317 +for fe80:1::2a0:24ff:feab:839b (note that embedded interface index - +described in 1.3 - helps us choose the right source address. Those +embedded indices will not be on the wire). +If the outgoing interface has multiple address for the scope, +a source is selected longest match basis (rule 3). Suppose +3ffe:501:808:1:200:f8ff:fe01:6317 and 3ffe:2001:9:124:200:f8ff:fe01:6317 +are given to the outgoing interface. 3ffe:501:808:1:200:f8ff:fe01:6317 +is chosen as the source for the destination 3ffe:501:800::1. + +Note that the above rule is not documented in the IPv6 spec. It is +considered "up to implementation" item. +There are some cases where we do not use the above rule. One +example is connected TCP session, and we use the address kept in tcb +as the source. +Another example is source address for Neighbor Advertisement. +Under the spec (RFC2461 7.2.2) NA's source should be the target +address of the corresponding NS's target. In this case we follow +the spec rather than the above longest-match rule. + +For new connections (when rule 1 does not apply), deprecated addresses +(addresses with preferred lifetime = 0) will not be chosen as source address +if other choises are available. If no other choices are available, +deprecated address will be used as a last resort. If there are multiple +choice of deprecated addresses, the above scope rule will be used to choose +from those deprecated addreses. If you would like to prohibit the use +of deprecated address for some reason, configure net.inet6.ip6.use_deprecated +to 0. The issue related to deprecated address is described in RFC2462 5.5.4 +(NOTE: there is some debate underway in IETF ipngwg on how to use +"deprecated" address). + +1.7 Jumbo Payload + +KAME supports the Jumbo Payload hop-by-hop option used to send IPv6 +packets with payloads longer than 65,535 octets. But since currently +KAME does not support any physical interface whose MTU is more than +65,535, such payloads can be seen only on the loopback interface(i.e. +lo0). + +If you want to try jumbo payloads, you first have to reconfigure the +kernel so that the MTU of the loopback interface is more than 65,535 +bytes; add the following to the kernel configuration file: + options "LARGE_LOMTU" #To test jumbo payload +and recompile the new kernel. + +Then you can test jumbo payloads by the ping6 command with -b and -s +options. The -b option must be specified to enlarge the size of the +socket buffer and the -s option specifies the length of the packet, +which should be more than 65,535. For example, type as follows; + % ping6 -b 70000 -s 68000 ::1 + +The IPv6 specification requires that the Jumbo Payload option must not +be used in a packet that carries a fragment header. If this condition +is broken, an ICMPv6 Parameter Problem message must be sent to the +sender. KAME kernel follows the specification, but you cannot usually +see an ICMPv6 error caused by this requirement. + +If KAME kernel receives an IPv6 packet, it checks the frame length of +the packet and compares it to the length specified in the payload +length field of the IPv6 header or in the value of the Jumbo Payload +option, if any. If the former is shorter than the latter, KAME kernel +discards the packet and increments the statistics. You can see the +statistics as output of netstat command with `-s -p ip6' option: + % netstat -s -p ip6 + ip6: + (snip) + 1 with data size < data length + +So, KAME kernel does not send an ICMPv6 error unless the erroneous +packet is an actual Jumbo Payload, that is, its packet size is more +than 65,535 bytes. As described above, KAME kernel currently does not +support physical interface with such a huge MTU, so it rarely returns an +ICMPv6 error. + +TCP/UDP over jumbogram is not supported at this moment. This is because +we have no medium (other than loopback) to test this. Contact us if you +need this. + +IPsec does not work on jumbograms. This is due to some specification twists +in supporting AH with jumbograms (AH header size influences payload length, +and this makes it real hard to authenticate inbound packet with jumbo payload +option as well as AH). + +There are fundamental issues in *BSD support for jumbograms. We would like to +address those, but we need more time to finalize these. To name a few: +- mbuf pkthdr.len field is typed as "int" in 4.4BSD, so it will not hold + jumbogram with len > 2G on 32bit architecture CPUs. If we would like to + support jumbogram properly, the field must be expanded to hold 4G + + IPv6 header + link-layer header. Therefore, it must be expanded to at least + int64_t (u_int32_t is NOT enough). +- We mistakingly use "int" to hold packet length in many places. We need + to convert them into larger integral type. It needs a great care, as we may + experience overflow during packet length computation. +- We mistakingly check for ip6_plen field of IPv6 header for packet payload + length in various places. We should be checking mbuf pkthdr.len instead. + ip6_input() will perform sanity check on jumbo payload option on input, + and we can safely use mbuf pkthdr.len afterwards. +- TCP code needs a careful update in bunch of places, of course. + +1.8 Loop prevention in header processing + +IPv6 specification allows arbitrary number of extension headers to +be placed onto packets. If we implement IPv6 packet processing +code in the way BSD IPv4 code is implemented, kernel stack may +overflow due to long function call chain. KAME sys/netinet6 code +is carefully designed to avoid kernel stack overflow. Because of +this, KAME sys/netinet6 code defines its own protocol switch +structure, as "struct ip6protosw" (see netinet6/ip6protosw.h). +There is no such update to IPv4 part (sys/netinet) for +compatibility, but small change is added to its pr_input() +prototype. So "struct ipprotosw" is also defined. +Because of this, if you receive IPsec-over-IPv4 packet with massive +number of IPsec headers, kernel stack may blow up. IPsec-over-IPv6 is okay. +(Off-course, for those all IPsec headers to be processed, each +such IPsec header must pass each IPsec check. So an anonymous +attacker won't be able to do such an attack.) + +1.9 ICMPv6 + +After RFC2463 was published, IETF ipngwg has decided to disallow ICMPv6 error +packet against ICMPv6 redirect, to prevent ICMPv6 storm on a network medium. +KAME already implements this into the kernel. + +1.10 Applications + +For userland programming, we support IPv6 socket API as specified in +RFC2553, RFC2292 and upcoming internet drafts. + +TCP/UDP over IPv6 is available and quite stable. You can enjoy "telnet", +"ftp", "rlogin", "rsh", "ssh", etc. These applications are protocol +independent. That is, they automatically chooses IPv4 or IPv6 +according to DNS. + +1.11 Kernel Internals + + (*) TCP/UDP part is handled differently between operating system platforms. + See 1.12 for details. + +The current KAME has escaped from the IPv4 netinet logic. While +ip_forward() calls ip_output(), ip6_forward() directly calls +if_output() since routers must not divide IPv6 packets into fragments. + +ICMPv6 should contain the original packet as long as possible up to +1280. UDP6/IP6 port unreach, for instance, should contain all +extension headers and the *unchanged* UDP6 and IP6 headers. +So, all IP6 functions except TCP never convert network byte +order into host byte order, to save the original packet. + +tcp_input(), udp6_input() and icmp6_input() can't assume that IP6 +header is preceding the transport headers due to extension +headers. So, in6_cksum() was implemented to handle packets whose IP6 +header and transport header is not continuous. TCP/IP6 nor UDP6/IP6 +header structure don't exist for checksum calculation. + +To process IP6 header, extension headers and transport headers easily, +KAME requires network drivers to store packets in one internal mbuf or +one or more external mbufs. A typical old driver prepares two +internal mbufs for 96 - 204 bytes data, however, KAME's reference +implementation stores it in one external mbuf. + +"netstat -s -p ip6" tells you whether or not your driver conforms +KAME's requirement. In the following example, "cce0" violates the +requirement. (For more information, refer to Section 2.) + + Mbuf statistics: + 317 one mbuf + two or more mbuf:: + lo0 = 8 + cce0 = 10 + 3282 one ext mbuf + 0 two or more ext mbuf + +Each input function calls IP6_EXTHDR_CHECK in the beginning to check +if the region between IP6 and its header is +continuous. IP6_EXTHDR_CHECK calls m_pullup() only if the mbuf has +M_LOOP flag, that is, the packet comes from the loopback +interface. m_pullup() is never called for packets coming from physical +network interfaces. + +Both IP and IP6 reassemble functions never call m_pullup(). + +1.12 IPv4 mapped address and IPv6 wildcard socket + +RFC2553 describes IPv4 mapped address (3.7) and special behavior +of IPv6 wildcard bind socket (3.8). The spec allows you to: +- Accept IPv4 connections by AF_INET6 wildcard bind socket. +- Transmit IPv4 packet over AF_INET6 socket by using special form of + the address like ::ffff:10.1.1.1. +but the spec itself is very complicated and does not specify how the +socket layer should behave. +Here we call the former one "listening side" and the latter one "initiating +side", for reference purposes. + +Almost all KAME implementations treat tcp/udp port number space separately +between IPv4 and IPv6. You can perform wildcard bind on both of the adderss +families, on the same port. + +There are some OS-platform differences in KAME code, as we use tcp/udp +code from different origin. The following table summarizes the behavior. + + listening side initiating side + (AF_INET6 wildcard (connetion to ::ffff:10.1.1.1) + socket gets IPv4 conn.) + --- --- +KAME/BSDI3 not supported not supported +KAME/FreeBSD228 not supported not supported +KAME/FreeBSD3x configurable supported + default: enabled +KAME/FreeBSD4x configurable supported + default: enabled +KAME/NetBSD configurable supported + default: disabled +KAME/BSDI4 enabled supported (*) +KAME/OpenBSD not supported not supported + +(*) on KAME/BSDI4, port number space is not always separated. + +The following sections will give you more details, and how you can +configure the behavior. + +Comments on listening side: + +It looks that RFC2553 talks too little on wildcard bind issue, +especially on the port space issue, failure mode and relationship +between AF_INET/INET6 wildcard bind. There can be several separate +interpretation for this RFC which conform to it but behaves differently. +So, to implement portable application you should assume nothing +about the behavior in the kernel. Using getaddrinfo() is the safest way. +Port number space and wildcard bind issues were discussed in detail +on ipv6imp mailing list, in mid March 1999 and it looks that there's +no concrete consensus (means, up to implementers). You may want to +check the mailing list archives. + +If a server application would like to accept IPv4 and IPv6 connections, +there will be two alternatives. + +One is using AF_INET and AF_INET6 socket (you'll need two sockets). +Use getaddrinfo() with AI_PASSIVE into ai_flags, and socket(2) and bind(2) +to all the addresses returned. +By opening multiple sockets, you can accept connections onto the socket with +proper address family. IPv4 connections will be accepted by AF_INET socket, +and IPv6 connections will be accepted by AF_INET6 socket (NOTE: KAME/BSDI4 +kernel sometimes violate this - we will fix it). + +Another way is using one AF_INET6 wildcard bind socket. +Use getaddrinfo() with AI_PASSIVE into ai_flags and with +AF_INET6 into ai_family, and set the 1st argument hostname to +NULL. And socket(2) and bind(2) to the address returned. +(should be IPv6 unspecified addr) +You can accept either of IPv4 and IPv6 packet via this one socket. + +To support only IPv6 traffic on AF_INET6 wildcard binded socket portably, +always check the peer address when a connection is made toward +AF_INET6 listening socket. If the address is IPv4 mapped address, you may +want to reject the connection. You can check the condition by using +IN6_IS_ADDR_V4MAPPED() macro. +To resolv this issue more easily, there is system dependent setsockopt() +option, IPV6_BINDV6ONLY, used like below. + int on; + + setsockopt(s, IPPROTO_IPV6, IPV6_BINDV6ONLY, + (char *)&on, sizeof (on)) < 0)); +When this call succeed, then this socket only receive IPv6 packets. + + +Comments on initiating side: + +Advise to application implementers: to implement a portable IPv6 application +(which works on multiple IPv6 kernels), we believe that the following +is the key to the success: +- NEVER hardcode AF_INET nor AF_INET6. +- Use getaddrinfo() and getnameinfo() throughout the system. + Never use gethostby*(), getaddrby*(), inet_*() or getipnodeby*(). + (To update existing applications to be IPv6 aware easily, + sometime getipnodeby*() will be useful. But if possible, try to + rewrite the code to use getaddrinfo() and getnameinfo().) +- If you would like to connect to destination, use getaddrinfo() and try + all the destination returned, like telnet does. +- Some of the IPv6 stack is shipped with buggy getaddrinfo(). Ship a minimal + working version with your application and use that as last resort. + +If you would like to use AF_INET6 socket for both IPv4 and IPv6 outgoing +connection, you will need to use getipnodebyname(). When you would like to +update your existing appication to be IPv6 aware with minimal effort, +this approach might be choosed. But please note that it is a temporal +solution, because getipnodebyname() itself is not recommended as it does +not handle scoped IPv6 addresses at all. For IPv6 name resolution, +getaddrinfo() is the preferred API. So you should rewrite your +application to use getaddrinfo(), when you get the time to do it. + +When writing applications that make outgoing connections, story goes much +simpler if you treat AF_INET and AF_INET6 as totally seaprate address family. +{set,get}sockopt issue goes simpler, DNS issue will be made simpler. We do +not recommend you to rely upon IPv4 mapped address. + +1.12.1 KAME/BSDI3 and KAME/FreeBSD228 + +The platforms do not support IPv4 mapped address at all (both listening side +and initiating side). AF_INET6 and AF_INET sockets are totally separated. + +Port number space is totally separate between AF_INET and +AF_INET6 sockets. + +1.12.2 KAME/FreeBSD3x + +KAME/FreeBSD3x uses shared tcp4/6 code (from sys/netinet/tcp*) and separete +udp4/6 code. It uses unified inpcb/in6pcb structure. + +The platform can be configured to support IPv4 mapped address. +Kernel configuration is summarized as follows: +- By default, MAPPED_ADDR_ENABLED option is defined in the kernel + configuration file. In this case, AF_INET6 socket will grab + IPv4 connections in certain condition, + and can initiate connection to IPv4 destination embedded in + IPv4 mapped IPv6 address. +- You can disable it on entire system with sysctl like below. + sysctl -w net.inet6.ip6.mapped_addr=0 +- If you remove MAPPED_ADDR_ENABLED option, the code for IPv4 mapped address + will not be compiled. It behaves as described in 1.12.1. + +1.12.2.1 KAME/FreeBSD3x, listening side + +Each socket can be configured to support special AF_INET6 wildcard bind +(enabled by default). +You can disable it on each socket basis with setsockopt() like below. + int on; + + setsockopt(s, IPPROTO_IPV6, IPV6_BINDV6ONLY, + (char *)&on, sizeof (on)) < 0)); + +Wildcard AF_INET6 socket grabs IPv4 connection if and only if the following +conditions are satisfied: +- there's no AF_INET socket that matches the IPv4 connection +- the AF_INET6 socket is configured to accept IPv4 traffic, i.e. + getsockopt(IPV6_BINDV6ONLY) returns 0. +There's no problem with open/close ordering. + +1.12.2.2 KAME/FreeBSD3x, initiating side + +KAME/FreeBSD3x supports outgoing connetion to IPv4 mapped address +(::ffff:10.1.1.1), if the node is configured to support IPv4 mapped address. + +1.12.3 FreeBSD4x + +FreeBSD4x uses shared tcp4/6 code (from sys/netinet/tcp*) and separete +udp4/6 code. It uses unified inpcb/in6pcb structure. + +The platform can be configured to support IPv4 mapped address. +Kernel configuration is summarized as follows: +- By default, AF_INET6 socket will grab IPv4 connections in certain condition, + and can initiate connection to IPv4 destination embedded in + IPv4 mapped IPv6 address. +- You can disable it on entire system with sysctl like below. + sysctl -w net.inet6.ip6.mapped_addr=0 + +1.12.3.1 FreeBSD4x, listening side + +Each socket can be configured to support special AF_INET6 wildcard bind +(enabled by default). +You can disable it on each socket basis with setsockopt() like below. + int on; + + setsockopt(s, IPPROTO_IPV6, IPV6_BINDV6ONLY, + (char *)&on, sizeof (on)) < 0)); + +Wildcard AF_INET6 socket grabs IPv4 connection if and only if the following +conditions are satisfied: +- there's no AF_INET socket that matches the IPv4 connection +- the AF_INET6 socket is configured to accept IPv4 traffic, i.e. + getsockopt(IPV6_BINDV6ONLY) returns 0. +There's no problem with open/close ordering. + +1.12.3.2 FreeBSD4x, initiating side + +FreeBSD4x supports outgoing connetion to IPv4 mapped address +(::ffff:10.1.1.1), if the node is configured to support IPv4 mapped address. + +1.12.4 KAME/NetBSD + +KAME/NetBSD uses shared tcp4/6 code (from sys/netinet/tcp*) and shared +udp4/6 code (from sys/netinet/udp*). The implementation is made differently +from KAME/FreeBSD3x. KAME/NetBSD uses separate inpcb/in6pcb structures, +while KAME/FreeBSD3x uses merged inpcb structure. + +1.12.4.1 KAME/NetBSD, listening side + +The platform can be configured to support IPv4 mapped address/special AF_INET6 +wildcard bind (disabled by default). Kernel behavior can be summarized as +follows: +- default: No special support code for AF_INET6 wildcard socket will be + compiled in. AF_INET6 sockets and AF_INET sockets are totally separate. + The behavior is similar to what described in 1.12.1. +- add "MAPPED_ADDR_ENABLED=0" option to kernel config: special support code + will be compiled in, but is disabled by default. It can be controlled by + sysctl (net.inet6.ip6.mapped_addr), or setsockopt(IPV6_BINDV6ONLY). +- add "MAPPED_ADDR_ENABLED=1" option to kernel config: special support code + will be compiled in, but is enabled by default. It can be controlled by + sysctl (net.inet6.ip6.mapped_addr), or setsockopt(IPV6_BINDV6ONLY). + +sysctl setting will affect per-socket configuration at in6pcb creation time +only. In other words, per-socket configuration will be copied from sysctl +configuration at in6pcb creation time. To change per-socket behavior, you +must perform setsockopt or reopen the socket. Change in sysctl configuration +will not change the behavior or sockets that are already opened. + +Wildcard AF_INET6 socket grabs IPv4 connection if and only if the following +conditions are satisfied: +- there's no AF_INET socket that matches the IPv4 connection +- the AF_INET6 socket is configured to accept IPv4 traffic, i.e. + getsockopt(IPV6_BINDV6ONLY) returns 0. +There's no problem with open/close ordering. + +1.12.4.1 KAME/NetBSD, initiating side + +When you initiate a connection, you can always connect to IPv4 destination +over AF_INET6 socket, usin IPv4 mapped address destination (::ffff:10.1.1.1). +This is enabled independently from the configuration for listening side, and +always enabled. + +1.12.5 KAME/BSDI4 + +KAME/BSDI4 uses NRL-based TCP/UDP stack and inpcb source code, +which was derived from NRL IPv6/IPsec stack. I guess it supports IPv4 mapped +address and speical AF_INET6 wildcard bind. The implementation is, again, +different from other KAME/*BSDs. + +1.12.5.1 KAME/BSDI4, listening side + +NRL inpcb layer supports special behavior of AF_INET6 wildcard socket. +It grabs IPv4 connection under certain condition. NRL inpcb layer has +different behavior than KAME implementation, namely: +- If you bind(2) a socket to IPv6 wildcard address (::) then bind(2) + another socket to IPv4 wildcard address (0.0.0.0), the latter will fail + with EADDRINUSE. +- If you bind(2) to IPv4 wildcard address then IPv6 wildcard address, + both will success. However, all IPv4 traffic (and IPv6 traffic) will be + captured by IPv6 wildcard socket. + +1.12.5.2 KAME/BSDI4, initiating side + +KAME/BSDi4 supports connection initiation to IPv4 mapped address +(like ::ffff:10.1.1.1). + +1.12.6 KAME/OpenBSD + +KAME/OpenBSD uses NRL-based TCP/UDP stack and inpcb source code, +which was derived from NRL IPv6/IPsec stack. + +1.12.6.1 KAME/OpenBSD, listening side + +KAME/OpenBSD disables special behavior on AF_INET6 wildcard bind for +security reasons (if IPv4 traffic toward AF_INET6 wildcard bind is allowed, +access control will become much harder). KAME/BSDI4 uses NRL-based TCP/UDP +stack as well, however, the behavior is different due to OpenBSD's security +policy. + +As a result the behavior of KAME/OpenBSD is similar to KAME/BSDI3 and +KAME/FreeBSD228 (see 1.12.1 for more detail). + +1.12.6.2 KAME/OpenBSD, initiating side + +KAME/OpenBSD does not support connection initiation to IPv4 mapped address +(like ::ffff:10.1.1.1). + +1.13 sockaddr_storage + +When RFC2553 was about to be finalized, there was discusson on how struct +sockaddr_storage members are named. One proposal is to prepend "__" to the +members (like "__ss_len") as they should not be touched. The other proposal +was that don't prepend it (like "ss_len") as we need to touch those members +directly. There was no clear consensus on it. + +As a result, RFC2553 defines struct sockaddr_storage as follows: + struct sockaddr_storage { + u_char __ss_len; /* address length */ + u_char __ss_family; /* address family */ + /* and bunch of padding */ + }; +On the contrary, XNET draft defines as follows: + struct sockaddr_storage { + u_char ss_len; /* address length */ + u_char ss_family; /* address family */ + /* and bunch of padding */ + }; + +In December 1999, it was agreed that RFC2553bis should pick the latter (XNET) +definition. + +KAME kit prior to December 1999 used RFC2553 definition. KAME kit after +December 1999 (including December) will conform to XNET definition, +based on RFC2553bis discusson. + +If you look at multiple IPv6 implementations, you will be able to see +both definitions. As an userland programmer, the most portable way of +dealing with it is to: +(1) ensure ss_family and/or ss_len are available on the platform, by using + GNU autoconf, +(2) have -Dss_family=__ss_family to unify all occurences (including header + file) into __ss_family, or +(3) never touch __ss_family. cast to sockaddr * and use sa_family like: + struct sockaddr_storage ss; + family = ((struct sockaddr *)&ss)->sa_family + +2. Network Drivers + +KAME requires three items to be added into the standard drivers: + +(1) mbuf clustering requirement. In this stable release, we changed + MINCLSIZE into MHLEN+1 for all the operating systems in order to make + all the drivers behave as we expect. + +(2) multicast. If "ifmcstat" yields no multicast group for a + interface, that interface has to be patched. + +To avoid troubles, we suggest you to comment out the device drivers +for unsupported/unnecessary cards, from the kernel configuration file. +If you accidentally enable unsupported drivers, some of the userland +tools may not work correctly (routing daemons are typical example). + +In the following sections, "official support" means that KAME developers +are using that ethernet card/driver frequently. + +(NOTE: In the past we required all pcmcia drivers to have a call to +in6_ifattach(). We have no such requirement any more) + +2.1 FreeBSD 4.x-RELEASE + +Here is a list of FreeBSD 4.x-RELEASE drivers and its conditions: + + driver mbuf(1) multicast(2) official + support? + --- --- --- --- + fe ok ok yes + fxp*1 ok ok yes + de*2 ok ok - + ep ok ok yes + + +More drivers will just simply work on FreeBSD 4.x-RELEASE with +IPv6 but have not been checked yet. + +*1: There seem to be some problem in driver, with multicast filter + configuration. This happens with certain revision of chipset on the card. + Now an workaround for the problem is added to sys/net/if.c:ifioctl(). + +*2: There is a problem report that when multiple de card is used, + and INET6 is enabled, some of the de interfaces initialization fails. + As an workaround for the problem, simply adding small sleep() + just before ifconfig in /etc/rc.network seems to avoid the problem. + +3. Translator + +We categorize IPv4/IPv6 translator into 4 types. + +Translator A --- It is used in the early stage of transition to make +it possible to establish a connection from an IPv6 host in an IPv6 +island to an IPv4 host in the IPv4 ocean. + +Translator B --- It is used in the early stage of transition to make +it possible to establish a connection from an IPv4 host in the IPv4 +ocean to an IPv6 host in an IPv6 island. + +Translator C --- It is used in the late stage of transition to make it +possible to establish a connection from an IPv4 host in an IPv4 island +to an IPv6 host in the IPv6 ocean. + +Translator D --- It is used in the late stage of transition to make it +possible to establish a connection from an IPv6 host in the IPv6 ocean +to an IPv4 host in an IPv4 island. + +KAME provides an TCP relay translator for category A. This is called +"FAITH". We also provide IP header translator for category A. +(The latter is not yet put into FreeBSD4.x yet.) + +3.1 FAITH TCP relay translator + +FAITH system uses TCP relay daemon called "faithd" helped by the KAME kernel. +FAITH will reserve an IPv6 address prefix, and relay TCP connection +toward that prefix to IPv4 destination. + +For example, if the reserved IPv6 prefix is 3ffe:0501:0200:ffff::, and +the IPv6 destination for TCP connection is 3ffe:0501:0200:ffff::163.221.202.12, +the connection will be relayed toward IPv4 destination 163.221.202.12. + + destination IPv4 node (163.221.202.12) + ^ + | IPv4 tcp toward 163.221.202.12 + FAITH-relay dual stack node + ^ + | IPv6 TCP toward 3ffe:0501:0200:ffff::163.221.202.12 + source IPv6 node + +faithd must be invoked on FAITH-relay dual stack node. + +For more details, consult src/usr.sbin/faithd/README. + +3.2 IPv6-to-IPv4 header translator + +(to be written) + +4. IPsec + +IPsec is mainly organized by three components. + +(1) Policy Management +(2) Key Management +(3) AH and ESP handling + +Note that KAME/OpenBSD does NOT include support for KAME IPsec code, +as OpenBSD team has their home-brew IPsec stack and they have no plan +to replace it. IPv6 support for IPsec is, therefore, lacking on KAME/OpenBSD. +KAME/BSDI4 lacks IPsec at this moment (both NRL and KAME). In the near +future we will be adding KAME IPSec code support into KAME/BSDI4. + +4.1 Policy Management + +The kernel implements experimental policy management code. There are two way +to manage security policy. One is to configure per-socket policy using +setsockopt(3). In this cases, policy configuration is described in +ipsec_set_policy(3). The other is to configure kernel packet filter-based +policy using PF_KEY interface, via setkey(8). + +The policy entry is not re-ordered with its +indexes, so the order of entry when you add is very significant. + +4.2 Key Management + +The key management code implemented in this kit (sys/netkey) is a +home-brew PFKEY v2 implementation. This conforms to RFC2367. + +The home-brew IKE daemon, "racoon" is included in the kit +(kame/kame/racoon). +Basically you'll need to run racoon as daemon, then setup a policy +to require keys (like ping -P 'out ipsec esp/transport//use'). +The kernel will contact racoon daemon as necessary to exchange keys. + +4.3 AH and ESP handling + +IPsec module is implemented as "hooks" to the standard IPv4/IPv6 +processing. When sending a packet, ip{,6}_output() checks if ESP/AH +processing is required by checking if a matching SPD (Security +Policy Database) is found. If ESP/AH is needed, +{esp,ah}{4,6}_output() will be called and mbuf will be updated +accordingly. When a packet is received, {esp,ah}4_input() will be +called based on protocol number, i.e. (*inetsw[proto])(). +{esp,ah}4_input() will decrypt/check authenticity of the packet, +and strips off daisy-chained header and padding for ESP/AH. It is +safe to strip off the ESP/AH header on packet reception, since we +will never use the received packet in "as is" form. + +By using ESP/AH, TCP4/6 effective data segment size will be affected by +extra daisy-chained headers inserted by ESP/AH. Our code takes care of +the case. + +Basic crypto functions can be found in directory "sys/crypto". ESP/AH +transform are listed in {esp,ah}_core.c with wrapper functions. If you +wish to add some algorithm, add wrapper function in {esp,ah}_core.c, and +add your crypto algorithm code into sys/crypto. + +Tunnel mode is partially supported in this release, with the following +restrictions: +- IPsec tunnel is not combined with GIF generic tunneling interface. + It needs a great care because we may create an infinite loop between + ip_output() and tunnelifp->if_output(). Opinion varies if it is better + to unify them, or not. +- MTU and Don't Fragment bit (IPv4) considerations need more checking, but + basically works fine. +- Authentication model for AH tunnel must be revisited. We'll need to + improve the policy management engine, eventually. + +4.4 Conformance to RFCs and IDs + +The IPsec code in the kernel conforms (or, tries to conform) to the +following standards: + "old IPsec" specification documented in rfc182[5-9].txt + "new IPsec" specification documented in rfc240[1-6].txt, rfc241[01].txt, + rfc2451.txt and draft-mcdonald-simple-ipsec-api-01.txt (draft expired, + but you can take from ftp://ftp.kame.net/pub/internet-drafts/). + (NOTE: IKE specifications, rfc241[7-9].txt are implemented in userland, + as "racoon" IKE daemon) + +Currently supported algorithms are: + old IPsec AH + null crypto checksum (no document, just for debugging) + keyed MD5 with 128bit crypto checksum (rfc1828.txt) + keyed SHA1 with 128bit crypto checksum (no document) + HMAC MD5 with 128bit crypto checksum (rfc2085.txt) + HMAC SHA1 with 128bit crypto checksum (no document) + old IPsec ESP + null encryption (no document, similar to rfc2410.txt) + DES-CBC mode (rfc1829.txt) + new IPsec AH + null crypto checksum (no document, just for debugging) + keyed MD5 with 96bit crypto checksum (no document) + keyed SHA1 with 96bit crypto checksum (no document) + HMAC MD5 with 96bit crypto checksum (rfc2403.txt + HMAC SHA1 with 96bit crypto checksum (rfc2404.txt) + new IPsec ESP + null encryption (rfc2410.txt) + DES-CBC with derived IV + (draft-ietf-ipsec-ciph-des-derived-01.txt, draft expired) + DES-CBC with explicit IV (rfc2405.txt) + 3DES-CBC with explicit IV (rfc2451.txt) + BLOWFISH CBC (rfc2451.txt) + CAST128 CBC (rfc2451.txt) + RC5 CBC (rfc2451.txt) + each of the above can be combined with: + ESP authentication with HMAC-MD5(96bit) + ESP authentication with HMAC-SHA1(96bit) + +The following algorithms are NOT supported: + old IPsec AH + HMAC MD5 with 128bit crypto checksum + 64bit replay prevention + (rfc2085.txt) + keyed SHA1 with 160bit crypto checksum + 32bit padding (rfc1852.txt) + +IPsec (in kernel) and IKE (in userland as "racoon") has been tested +at several interoperability test events, and it is known to interoperate +with many other implementations well. Also, KAME IPsec has quite wide +coverage for IPsec crypto algorithms documented in RFC (we cover +algorithms without intellectual property issues only). + +4.5 ECN consideration on IPsec tunnels + +KAME IPsec implements ECN-friendly IPsec tunnel, described in +draft-ipsec-ecn-00.txt. +Normal IPsec tunnel is described in RFC2401. On encapsulation, +IPv4 TOS field (or, IPv6 traffic class field) will be copied from inner +IP header to outer IP header. On decapsulation outer IP header +will be simply dropped. The decapsulation rule is not compatible +with ECN, since ECN bit on the outer IP TOS/traffic class field will be +lost. +To make IPsec tunnel ECN-friendly, we should modify encapsulation +and decapsulation procedure. This is described in +http://www.aciri.org/floyd/papers/draft-ipsec-ecn-00.txt, chapter 3. + +KAME IPsec tunnel implementation can give you three behaviors, by setting +net.inet.ipsec.ecn (or net.inet6.ipsec6.ecn) to some value: +- RFC2401: no consideration for ECN (sysctl value -1) +- ECN forbidden (sysctl value 0) +- ECN allowed (sysctl value 1) +Note that the behavior is configurable in per-node manner, not per-SA manner +(draft-ipsec-ecn-00 wants per-SA configuration, but it looks too much for me). + +The behavior is summarized as follows (see source code for more detail): + + encapsulate decapsulate + --- --- +RFC2401 copy all TOS bits drop TOS bits on outer + from inner to outer. (use inner TOS bits as is) + +ECN forbidden copy TOS bits except for ECN drop TOS bits on outer + (masked with 0xfc) from inner (use inner TOS bits as is) + to outer. set ECN bits to 0. + +ECN allowed copy TOS bits except for ECN use inner TOS bits with some + CE (masked with 0xfe) from change. if outer ECN CE bit + inner to outer. is 1, enable ECN CE bit on + set ECN CE bit to 0. the inner. + +General strategy for configuration is as follows: +- if both IPsec tunnel endpoint are capable of ECN-friendly behavior, + you'd better configure both end to "ECN allowed" (sysctl value 1). +- if the other end is very strict about TOS bit, use "RFC2401" + (sysctl value -1). +- in other cases, use "ECN forbidden" (sysctl value 0). +The default behavior is "ECN forbidden" (sysctl value 0). + +For more information, please refer to: + http://www.aciri.org/floyd/papers/draft-ipsec-ecn-00.txt + RFC2481 (Explicit Congestion Notification) + KAME sys/netinet6/{ah,esp}_input.c + +(Thanks goes to Kenjiro Cho for detailed analysis) + +4.6 Interoperability + +Here are (some of) platforms we have tested IPsec/IKE interoperability +in the past. Note that both ends (KAME and others) may have modified their +implementation, so use the following list just for reference purposes. + Altiga, Ashley-laurent (vpcom.com), Data Fellows (F-Secure), Ericsson + ACC, FreeS/WAN, HITACHI, IBM AIX, IIJ, Intel, Microsoft WinNT, NIST + (linux IPsec + plutoplus), Netscreen, OpenBSD, RedCreek, Routerware, + SSH, Secure Computing, Soliton, Toshiba, VPNet, Yamaha RT100i + +5. IPComp +(not yet put into FreeBSD4.x, due to inflate related changes in 4.x.) + +IPComp stands for IP payload compression protocol. This is aimed for +payload compression, not the header compression like PPP VJ compression. +This may be useful when you are using slow serial link (say, cell phone) +with powerful CPU (well, recent notebook PCs are really powerful...). +The protocol design of IPComp is very similar to IPsec. + +KAME implements the following specifications: +- RFC2393: IP Payload Compression Protocol (IPComp) +- RFC2394: IP Payload Compression Using DEFLATE + +Here are some points to be noted: +- IPComp is treated as part of IPsec protocol suite, and SPI and + CPI space is unified. Spec says that there's no relationship + between two so they are assumed to be separate. +- IPComp association (IPCA) is kept in SAD. +- It is possible to use well-known CPI (CPI=2 for DEFLATE for example), + for outbound/inbound packet, but for indexing purposes one element from + SPI/CPI space will be occupied anyway. +- pfkey is modified to support IPComp. However, there's no official + SA type number assignment yet. Portability with other IPComp + stack is questionable (anyway, who else implement IPComp on UN*X?). +- Spec says that IPComp output processing must be performed before IPsec + output processing, to achieve better compression ratio and "stir" data + stream before encryption. However, with manual SPD setting, you are able to + violate the ordering requirement (KAME code is too generic, maybe). +- Though MTU can be significantly decreased by using IPComp, no special + consideration is made about path MTU (spec talks nothing about MTU + consideration). IPComp is designed for serial links, not ethernet-like + medium, it seems. +- You can change compression ratio on outbound packet, by changing + deflate_policy in sys/netinet6/ipcomp_core.c. You can also change history + buffer size by changing deflate_window in the same source code. + (should it be sysctl accessible? or per-SAD configurable?) +- Tunnel mode IPComp is not working right. KAME box can generate tunnelled + IPComp packet, however, cannot accept tunneled IPComp packet. + +6. ALTQ (not yet put into FreeBSD4.x) + +KAME kit includes ALTQ 2.0 code, which supports FreeBSD2, FreeBSD3 and +NetBSD. For other BSDs, ALTQ does not work. +ALTQ in KAME supports (or tries to support) IPv6. ALTQ-related userland +tools must be built manually, using ports/altq or pkgsrc/net/altq. + + Index: examples/IPv6/USAGE =================================================================== RCS file: USAGE diff -N USAGE --- /dev/null Wed Feb 23 08:43:46 2000 +++ USAGE Wed Feb 23 09:27:42 2000 @@ -0,0 +1,473 @@ + USAGE + + KAME Project + + $Date$ + $FreeBSD$ + +This is a introduction of how to use the commands provided in the KAME +kit. For more information, please refer to each man page. + +<<>> + +A link-local address is automatically assigned to each interface, when +the interface becomes up for the first time. Even if you find an interface +without a link-local address, do not panic. The link-local address will be +assigned when it becomes up (with "ifconfig IF up"). + +Some network drivers allow an interface to become up even without a +hardware address (for example, PCMCIA network cards). In such cases, it is +possible that an interface has no link-local address even if the +interface is up. If you see such situation, please disable the +interface once and then re-enable it (i.e. do `ifconfig IF down; +ifconfig IF up'). + +Pseudo interfaces (like "gif" tunnel device) will borrow IPv6 interface +identifier (lowermost 64bit of the address) from EUI64/IEEE802 sources, +like ethernet cards. Pseudo interfaces will be able to get IPv6 link-local +address, if you have other "real" interface configured beforehand. +If you have no EUI64/IEEE802 sources on the node, you may need to configure +link-local address manually. Though we have last-resort code in the kernel, +which generates interface identifier from MD5(hostname), it may not suitable +for your usage (for example, if you configure same hostname on both sides +of gif tunnel, you will be doomed). + +If you have a router announcing Router Advertisement, +global addresses will be assigned automatically. So, "ifconfig" is not +necessary for your *host*. (Please refer to "sysctl" section for configuring +a host to accept Router Advertisement.) + +If you want to set up a router, you need to assign global addresses +for two or more interfaces by "ifconfig" or "prefix". (prefix command +is described at next section) +If you want to assign a global address by "ifconfig", don't forget to +specify the "alias" argument to keep the link-local address. + +# ifconfig de0 inet6 fec0:0:0:1000:200:f8ff:fe01:6317 alias +# ifconfig de0 +de0: flags=8843 mtu 1500 + inet 172.16.202.12 netmask 0xffffff00 broadcast 172.16.202.255 + inet6 fe80::200:f8ff:fe01:6317%de0 prefixlen 64 + inet6 fec0:0:0:1000:200:f8ff:fe01:6317 prefixlen 64 + inet6 fec0:0:0:1000:: prefixlen 64 anycast + ether 00:00:f8:01:63:17 + media: autoselect (10baseT/UTP) status: active + supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP + +See also "/etc/rc.network6" for actual examples. + +<> + +In IPv6 architecture, an IPv6 address of an interface can be generated +from a prefix assigned to it, and a link-dependent identifier for the +interface. Assigning a full IPv6 address by ifconfig is not +necessary anymore, because, user can only take care of prefix, by letting +system take care of interface identifier. + +The newly added "prefix" command enables user to just assign prefixes +for interfaces, and let your system automatically generate IPv6 +addresses. Prefixes added by the "prefix" command is maintained in +the kernel consistently with prefixes assigned by Router +Renumbering(in case of routers). + +But "prefix" command can only be used on router, because host should be +able to configure its addr automatically. Prefixes added by the "prefix" +command are maintained independently from prefixes assigned by +Router Advertisement. Those two type of prefixes should not coexist on +a machine at the same time, and when it happens, it is considered to be +miss configuration. + +Manual assignment of prefixes or change of prefix properties take +precedence over ones assigned by Router Renumbering. + +If you want to assign a prefix(and consequently an address) manually, do +as follows: + +# prefix de0 fec0:0:0:1000:: +# ifconfig de0 +de0: flags=8843 mtu 1500 + inet 172.16.202.12 netmask 0xffffff00 broadcast 172.16.202.255 + inet6 fe80:1::200:f8ff:fe01:6317 prefixlen 64 + inet6 fec0:0:0:1000:200:f8ff:fe01:6317 prefixlen 64 + inet6 fec0:0:0:1000:: prefixlen 64 anycast + ether 00:00:f8:01:63:17 + media: autoselect (10baseT/UTP) status: active + supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP + +To check assigned prefix, use the "ndp" command. (See description of +ndp command about its usage) + +# ndp -p +fec0:0:0:1000::/64 if=de0 + flags=LA, vltime=2592000, pltime=604800, expire=Never + No advertising router + +The "prefix" command also has node internal prefix renumbering +ability. + +If you have multiple prefixes which have fec0:0:0:1000:/56 at the top, +and would like to renumber them to fec0:0:0:2000:/56, then use the +"prefix" command with the "matchpr" argument and the "usepr" argument. + +Suppose that current state of before renumbering as follows: + +# ifconfig de0 +de0: flags=8843 mtu 1500 + inet 172.16.202.12 netmask 0xffffff00 broadcast 172.16.202.255 + inet6 fe80:1::200:f8ff:fe01:6317 prefixlen 64 + inet6 fec0:0:0:1000:200:f8ff:fe01:6317 prefixlen 64 + inet6 fec0:0:0:1000:: prefixlen 64 anycast + ether 00:00:f8:01:63:17 + media: autoselect (10baseT/UTP) status: active + supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP + +# ifconfig de1 +de1: flags=8843 mtu 1500 + inet 172.16.203.12 netmask 0xffffff00 broadcast 172.16.203.255 + inet6 fe80:1::200:f8ff:fe55:7011 prefixlen 64 + inet6 fec0:0:0:1001:200:f8ff:fe55:7011 prefixlen 64 + inet6 fec0:0:0:1001:: prefixlen 64 anycast + ether 00:00:f8:55:70:11 + media: autoselect (10baseT/UTP) status: active + supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP + +# ndp -p +fec0:0:0:1000::/64 if=de0 + flags=LA, vltime=2592000, pltime=604800, expire=Never + No advertising router +fec0:0:0:1001::/64 if=de1 + flags=LA, vltime=2592000, pltime=604800, expire=Never + No advertising router + +Then do as follows: + +# prefix -a matchpr fec0:0:0:1000:: mp_len 56 usepr fec0:0:0:2000:: up_uselen 56 change + +If command is successful, prefixes and addresses will be renumbered as +follows. + +# ifconfig de0 +de0: flags=8843 mtu 1500 + inet 172.16.202.12 netmask 0xffffff00 broadcast 172.16.202.255 + inet6 fe80:1::200:f8ff:fe01:6317 prefixlen 64 + inet6 fec0:0:0:2000:200:f8ff:fe01:6317 prefixlen 64 + inet6 fec0:0:0:2000:: prefixlen 64 anycast + ether 00:00:f8:01:63:17 + media: autoselect (10baseT/UTP) status: active + supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP +# ifconfig de1 +de1: flags=8843 mtu 1500 + inet 172.16.203.12 netmask 0xffffff00 broadcast 172.16.203.255 + inet6 fe80:1::200:f8ff:fe55:7011 prefixlen 64 + inet6 fec0:0:0:2001:200:f8ff:fe55:7011 prefixlen 64 + inet6 fec0:0:0:2001:: prefixlen 64 anycast + ether 00:00:f8:55:70:11 + media: autoselect (10baseT/UTP) status: active + supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP +# ndp -p +fec0:0:0:2000::/64 if=de0 + flags=LA, vltime=2592000, pltime=604800, expire=Never + No advertising router +fec0:0:0:2001::/64 if=de1 + flags=LA, vltime=2592000, pltime=604800, expire=Never + No advertising router + +See also "/etc/rc.network6" for actual examples. + +<<>> + +If there is a router announcing Router Advertisement on the subnet, +you don't need to add a default route for your host by yourself. +(Please refer to "sysctl" section to accept Router Advertisement.) + +If you want to add a default route manually, do as follows: + +# route add -inet6 default fe80::200:a2ff:fe0e:7543%de0 + +"default" means ::/0. + +Note that, in IPv6, link-local address should be used as gateway +("fe80::200:a2ff:fe0e:7543%de1" in the above). If you use global addresses, +icmp6 redirect may not work properly. For ease of configuration we recommend +you to avoid static routes and run a routing daemon (route6d for example) +instead. + +<<>> (This might be integrated into "ping" as "ping -6" in the future.) + +Reachability can be checked by "ping6". This "ping6" allows multicast +for its argument. + +% ping6 -I xl0 ff02::1 +or +% ping6 ff02::1%xl0 + +PING6(56=40+8+8 bytes) fe80::5254:ff:feda:cb7d --> ff02::1 +56 bytes from fe80::5254:ff:feda:cb7d, icmp_seq=0 hlim=64 time=0.25 ms +56 bytes from fe80::2a0:c9ff:fe84:ed6c, icmp_seq=0 hlim=64 time=1.333 ms(DUP!) +56 bytes from fe80::5254:ff:feda:d161, icmp_seq=0 hlim=64 time=1.459 ms(DUP!) +56 bytes from fe80::260:97ff:fec2:80bf, icmp_seq=0 hlim=64 time=1.538 ms(DUP!) + +<<>> + +Name resolution is possible by ICMPv6 node information query message. +This is very convenient for link-local addresses whose host name cannot be +resolved by DNS. Specify the "-w" option to "ping6". + +% ping6 -I xl0 -w ff02::1 + +64 bytes from fe80::5254:ff:feda:cb7d: fto.kame.net +67 bytes from fe80::5254:ff:feda:d161: banana.kame.net +69 bytes from fe80::2a0:c9ff:fe84:ebd9: paradise.kame.net +66 bytes from fe80::260:8ff:fe8b:447f: taroh.kame.net +66 bytes from fe80::2a0:c9ff:fe84:ed6c: ayame.kame.net + +<<>> + +The route for a target host can be checked by "traceroute6". + +% traceroute6 tokyo.v6.wide.ad.jp + +traceroute to tokyo.v6.wide.ad.jp (3ffe:501:0:401:200:e8ff:fed5:8923), 30 hops max, 12 byte packets + 1 nr60.v6.kame.net 1.239 ms 0.924 ms 0.908 ms + 2 otemachi.v6.wide.ad.jp 28.953 ms 31.451 ms 26.567 ms + 3 tokyo.v6.wide.ad.jp 26.549 ms 26.58 ms 26.186 ms + +If the -l option is specified, both address and name are shown in each line. +% traceroute6 -l tokyo.v6.wide.ad.jp + +traceroute to tokyo.v6.wide.ad.jp (3ffe:501:0:401:200:e8ff:fed5:8923), 30 hops max, 12 byte packets + 1 nr60.v6.kame.net (3ffe:501:4819:2000:260:97ff:fec2:80bf) 1.23 ms 0.952 ms 0.92 ms + 2 otemachi.v6.wide.ad.jp (3ffe:501:0:1802:260:97ff:feb6:7ff0) 27.345 ms 26.706 ms 26.563 ms + 3 tokyo.v6.wide.ad.jp (3ffe:501:0:401:200:e8ff:fed5:8923) 26.329 ms 26.36 ms 28.63 ms + +<<>> + +To display the current Neighbor cache, use "ndp": + +% ndp -a +Neighbor Linklayer Address Netif Expire St Flgs Prbs +nr60.v6.kame.net 0:60:97:c2:80:bf xl0 expired S R +fec0:0:0:1000:2c0:cff:fe10 0:c0:c:10:3a:53 xl0 permanent R +paradise.v6.kame.net 52:54:0:dc:52:17 xl0 expired S R +fe80:1::200:eff:fe49:f929 0:0:e:49:f9:29 xl0 expired S R +fe80:1::200:86ff:fe05:80da 0:0:86:5:80:da xl0 expired S +fe80:1::200:86ff:fe05:c2d8 0:0:86:5:c2:d8 xl0 9s R + +To flush the all NDP cache, execute the following by root. + +# ndp -c + +To display the prefix list. + +% ndp -p +fec0:0:0::1000::/64 if=xl0 + flags=LA, vltime=2592000, pltime=604800, expire=29d23h59m58s + advertised by + fe80::5254:ff:fedc:5217 + fe80::260:97ff:fec2:80bf + fe80::200:eff:fe49:f929 + +To display the default router list. + +% ndp -r +fe80::260:97ff:fec2:80bf if=xl0, flags=, expire=29m55s +fe80::5254:ff:fedc:5217 if=xl0, flags=, expire=29m7s +fe80::200:eff:fe49:f929 if=xl0, flags=, expire=28m47s + +<<>> + +To generate a Router Solicitation message right now to get global +addresses, use "rtsol". + +# ifconfig xl0 +xl0: flags=8a43 mtu 1500 + inet6 fe80:2::2a0:24ff:feab:839b%xl0 prefixlen 64 + ether 0:a0:24:ab:83:9b + media: autoselect (10baseT/UTP) status: active + supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP 100baseTX + +# rtsol xl0 +# ifconfig xl0 +xl0: flags=8a43 mtu 1500 + inet6 fe80:2::2a0:24ff:feab:839b%xl0 prefixlen 64 + inet6 fec0:0:0:1000:2a0:24ff:feab:839b prefixlen 64 + ether 0:a0:24:ab:83:9b + media: autoselect (10baseT/UTP) status: active + supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP 100baseTX + + +<<>> + +rtsold is a daemon version of rtsol. If you run KAME IPv6 on a laptop +computer and frequently move with it, the daemon is useful since it watches +the interface and sends router solicitations when the status of the interface +changes. Note, however, that the feature is disabled by default. Please +add -m option at invocation of rtsold. + +rtsold also supports multiple interfaces. For example, you can +invoke the daemon as follows: +# rtsold -m ep0 cnw0 + +<<>> + +To see routing table: + +# netstat -nr +# netstat -nrl (long format with Ref and Use) + +<<>> + +If "net.inet6.ip6.accept_rtadv" is 1, Router Advertisement is +accepted. This means that global addresses and default route are +automatically set up. Otherwise, the announcement is rejected. The +default value is 0. To set "net.inet6.ip6.accept_rtadv" to 1, execute +as follows: + +# sysctl -w net.inet6.ip6.accept_rtadv=1 + +<<>> + +"gif" interface enables you to perform IPv{4,6} over IPv{4,6} +protocol tunneling. To use this interface, you must specify the +outer IPv{4,6} address by using gifconfig, like: + +# gifconfig gif0 172.16.198.61 172.16.11.21 + +"ifconfig gif0" will configure the address pair used for inner +IPv{4,6} header. + +It is not required to configure inner IPv{4,6} address pair. If +you do not configure inner IPv{4,6} address pair, tunnel link is +considered as un-numbered link and the source address of inner +IPv{4,6} address pair will be borrowed from other interfaces. + +The following example configures un-numbered IPv6-over-IPv4 tunnel: +# gifconfig gif0 10.0.0.1 10.0.0.1 netmask 255.255.255.0 + +The following example configures numbered IPv6-over-IPv4 tunnel: +# gifconfig gif0 10.0.0.1 10.0.0.1 netmask 255.255.255.0 +# ifconfig gif0 inet6 fec0:0:0:3000::1 fec0:0:0:3000::2 prefixlen 64 alias + +IPv6 spec allows you to use point-to-point link without global IPv6 +address assigned to the interface. Routing protocol (such as RIPng) +uses link-local addresses only. If you are to configure IPv6-over-IPv4 +tunnel, you need not to configure an address pair for inner IPv6 +header. We suggest you to use the former example (un-numbered +IPv6-over-IPv4 tunnel) to connect to 6bone for simplicity, +for router to router connection. + +Note that it is so easy to make an infinite routing loop using gif +interface, if you configure a tunnel using the same protocol family +for inner and outer header (i.e. IPv4-over-IPv4). + +Refer to gifconfig(8) for more details. + +<<>> + +Inetd supports AF_INET and AF_INET6 sockets, with IPsec policy +configuration support. + +Refer to inetd(8) for more details. + +<<>> + +The current KAME supports both transport mode and tunnel mode. +However, tunnel mode comes with some restrictions. + +IPsec requires fairly complex configuration, so here we show transport +mode only. http://www.kame.net/newsletter/ has more comprehensive +examples. + +Let's setup security association to deploy a secure channel between +HOST A (10.2.3.4) and HOST B (10.6.7.8). Here we show a little +complicated example. From HOST A to HOST B, only old AH is used. +From HOST B to HOST A, new AH and new ESP are combined. + +Now we should choose algorithm to be used corresponding to "AH"/"new +AH"/"ESP"/"new ESP". Please refer to the "setkey" man page to know +algorithm names. Our choice is MD5 for AH, new-HMAC-SHA1 for new AH, +and new-DES-expIV with 8 byte IV for new ESP. + +Key length highly depends on each algorithm. For example, key +length must be equal to 16 bytes for MD5, 20 for new-HMAC-SHA1, +and 8 for new-DES-expIV. Now we choose "MYSECRETMYSECRET", +"KAMEKAMEKAMEKAMEKAME", "PASSWORD", respectively. + +OK, let's assign SPI (Security Parameter Index) for each protocol. +Please note that we need 3 SPIs for this secure channel since three +security headers are produced (one for from HOST A to HOST B, two for +from HOST B to HOST A). Please also note that SPI MUST be greater +than or equal to 256. We choose, 1000, 2000, and 3000, respectively. + + + (1) + HOST A ------> HOST B + + (1)PROTO=AH + ALG=MD5(RFC1826) + KEY=MYSECRETMYSECRET + SPI=1000 + + (2.1) + HOST A <------ HOST B + <------ + (2.2) + + (2.1) + PROTO=AH + ALG=new-HMAC-SHA1(new AH) + KEY=KAMEKAMEKAMEKAMEKAME + SPI=2000 + + (2.2) + PROTO=ESP + ALG=new-DES-expIV(new ESP) + IV length = 8 + KEY=PASSWORD + SPI=3000 + +Now, let's setup security association. Execute "setkey" on both HOST +A and B: + +# setkey -c +add 10.2.3.4 10.6.7.8 ah 1000 -m transport -A keyed-md5 "MYSECRETMYSECRET" ; +add 10.6.7.8 10.2.3.4 ah 2000 -m transport -A hmac-sha1 "KAMEKAMEKAMEKAMEKAME" ; +add 10.6.7.8 10.2.3.4 esp 3000 -m transport -E des-cbc "PASSWORD" ; +^D + +Actually, IPsec communication doesn't process until security policy +entries will be defined. In this case, you must setup each host. + +At A: +# setkey -c +spdadd 10.2.3.4 10.6.7.8 any -P out ipsec + ah/transport/10.2.3.4-10.6.7.8/require ; +^D + +At B: +spdadd 10.6.7.8 10.2.3.4 any -P out ipsec + esp/transport/10.6.7.8-10.2.3.4/require ; +spdadd 10.6.7.8 10.2.3.4 any -P out ipsec + ah/transport/10.6.7.8-10.2.3.4/require ; +^D + +To utilize the security associations installed into the kernel, you +must set the socket security level by using setsockopt(). +This is per-application (or per-socket) security. For example, +the "ping" command has the -P option with parameter to enable AH and/or ESP. + +For example: +% ping -P "out ipsec \ + ah/transport/10.0.1.1-10.0.2.2/use \ + esp/tunnel/10.0.1.1-10.0.1.2/require" 10.0.2.2 + +If there are proper SAs, this policy specification causes ICMP packet +to be AH transport mode inner ESP tunnel mode like below. + + HOST C -----------> GATEWAY D ----------> HOST E + 10.0.1.1 10.0.1.2 10.0.2.1 10.0.2.2 + | | | | + | ======= ESP ======= | + ==================== AH ================== + + ----Next_Part(Thu_Feb_24_02:42:14_2000_601)---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Wed Feb 23 13: 0: 6 2000 Delivered-To: freebsd-doc@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 4913137B9EA for ; Wed, 23 Feb 2000 13:00:01 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id NAA18062; Wed, 23 Feb 2000 13:00:01 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from monica.et.bocholt.fh-gelsenkirchen.de (monica.et.bocholt.fh-gelsenkirchen.de [193.175.197.63]) by hub.freebsd.org (Postfix) with ESMTP id 6037537B9E0 for ; Wed, 23 Feb 2000 12:50:35 -0800 (PST) (envelope-from hank@musashi.et.bocholt.fh-ge.de) Received: from musashi.et.bocholt.fh-ge.de (reserve.et.bocholt.fh-gelsenkirchen.de [193.175.197.95] (may be forged)) by monica.et.bocholt.fh-gelsenkirchen.de (8.9.3/8.9.3) with ESMTP id VAA29423 for ; Wed, 23 Feb 2000 21:50:33 +0100 Received: (from hank@localhost) by musashi.et.bocholt.fh-ge.de (8.9.3/8.9.3) id VAA05559; Wed, 23 Feb 2000 21:49:44 +0100 (CET) (envelope-from hank) Message-Id: <200002232049.VAA05559@musashi.et.bocholt.fh-ge.de> Date: Wed, 23 Feb 2000 21:49:44 +0100 (CET) From: gouders@et.bocholt.fh-gelsenkirchen.de Reply-To: gouders@et.bocholt.fh-gelsenkirchen.de To: freefall-gnats@musashi.et.bocholt.fh-ge.de X-Send-Pr-Version: 3.2 Subject: docs/16943: Missing question mark in FAQ. Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 16943 >Category: docs >Synopsis: Missing question mark in FAQ. >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Wed Feb 23 13:00:00 PST 2000 >Closed-Date: >Last-Modified: >Originator: Dirk Gouders >Release: FreeBSD 3.4-RELEASE i386 >Organization: FH-GE-Abt.-Bocholt >Environment: >Description: There's a question mark missing in the FAQ. >How-To-Repeat: >Fix: Here's the diff: *** book.sgml 2000/02/14 08:01:08 --- book.sgml 2000/02/23 20:47:04 *************** *** 4642,4648 **** ! Why doesn't my mouse work with X If you are using syscons (the default console driver), you can configure FreeBSD to support a mouse pointer on each virtual --- 4642,4648 ---- ! Why doesn't my mouse work with X? If you are using syscons (the default console driver), you can configure FreeBSD to support a mouse pointer on each virtual >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Wed Feb 23 13:20: 6 2000 Delivered-To: freebsd-doc@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 23A3637B9ED for ; Wed, 23 Feb 2000 13:20:02 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id NAA20103; Wed, 23 Feb 2000 13:20:02 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from monica.et.bocholt.fh-gelsenkirchen.de (monica.et.bocholt.fh-gelsenkirchen.de [193.175.197.63]) by hub.freebsd.org (Postfix) with ESMTP id 0490637B9AB for ; Wed, 23 Feb 2000 13:14:38 -0800 (PST) (envelope-from hank@musashi.et.bocholt.fh-ge.de) Received: from musashi.et.bocholt.fh-ge.de (reserve.et.bocholt.fh-gelsenkirchen.de [193.175.197.95] (may be forged)) by monica.et.bocholt.fh-gelsenkirchen.de (8.9.3/8.9.3) with ESMTP id WAA29460 for ; Wed, 23 Feb 2000 22:14:36 +0100 Received: (from hank@localhost) by musashi.et.bocholt.fh-ge.de (8.9.3/8.9.3) id WAA05833; Wed, 23 Feb 2000 22:13:47 +0100 (CET) (envelope-from hank) Message-Id: <200002232113.WAA05833@musashi.et.bocholt.fh-ge.de> Date: Wed, 23 Feb 2000 22:13:47 +0100 (CET) From: gouders@et.bocholt.fh-gelsenkirchen.de Reply-To: gouders@et.bocholt.fh-gelsenkirchen.de To: freefall-gnats@musashi.et.bocholt.fh-ge.de X-Send-Pr-Version: 3.2 Subject: docs/16945: Inconsistent use of colon Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 16945 >Category: docs >Synopsis: Inconsistent use of colon >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Wed Feb 23 13:20:01 PST 2000 >Closed-Date: >Last-Modified: >Originator: Dirk Gouders >Release: FreeBSD 3.4-RELEASE i386 >Organization: FH-GE-Abt.-Bocholt >Environment: >Description: In a section of the FAQ a colon is used after one file name but not after another only about five lines later. >How-To-Repeat: >Fix: If you think that should be fixed, here's the diff: *** book.sgml 2000/02/23 20:47:39 1.6 --- book.sgml 2000/02/23 21:09:48 *************** *** 4659,4665 **** moused_port=/dev/psm0 # or whatever your real port is moused_flags= ! /etc/XF86Config Section Pointer Protocol "MouseSystems" Device "/dev/sysmouse" --- 4659,4665 ---- moused_port=/dev/psm0 # or whatever your real port is moused_flags= ! /etc/XF86Config: Section Pointer Protocol "MouseSystems" Device "/dev/sysmouse" >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Wed Feb 23 21:26:51 2000 Delivered-To: freebsd-doc@freebsd.org Received: from server.baldwin.cx (jobaldwi.campus.vt.edu [198.82.67.146]) by hub.freebsd.org (Postfix) with ESMTP id 3995137BAFF for ; Wed, 23 Feb 2000 21:26:49 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from john.baldwin.cx (john [10.0.0.2]) by server.baldwin.cx (8.9.3/8.9.3) with ESMTP id AAA61509 for ; Thu, 24 Feb 2000 00:26:02 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-Id: <200002240526.AAA61509@server.baldwin.cx> X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Thu, 24 Feb 2000 00:26:02 -0500 (EST) From: John Baldwin To: doc@FreeBSD.org Subject: Patch regarding wheel mice under X Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I committed the imwheel port, which is used to map mouse wheel events into keyboard events, thus enabling one to actually use the cool little wheel on their mouse in X. As such, I've added a brief tutorial to the X and Wheeled Mice question in the FAQ that goes over setting up imwheel. The patch can be found at http://people.FreeBSD.org/~jhb/patches/wheelmice.diff. Any and all feedback appreciated. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Wed Feb 23 23:34:55 2000 Delivered-To: freebsd-doc@freebsd.org Received: from mta3.snfc21.pbi.net (mta3.snfc21.pbi.net [206.13.28.141]) by hub.freebsd.org (Postfix) with ESMTP id 295CB37BB1B; Wed, 23 Feb 2000 23:34:40 -0800 (PST) (envelope-from ehampshire@scu.edu) Received: from ice ([216.103.215.136]) by mta3.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with SMTP id <0FQF00NBHBP333@mta3.snfc21.pbi.net>; Wed, 23 Feb 2000 23:34:17 -0800 (PST) Date: Thu, 23 Mar 2000 23:34:46 -0800 From: Eric Hampshire Subject: NAT Documentation To: freebsd-doc@FreeBSD.ORG Cc: jim@freebsd.org Message-id: <00f701bf9563$6e0b52c0$0301000a@yourmom.dhs.org> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 Content-type: multipart/alternative; boundary="----=_NextPart_000_00F4_01BF9520.5FAC9060" X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Priority: 3 Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_00F4_01BF9520.5FAC9060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Okay, here it is... the documentation for setting up a gateway under = FreeBSD. I wrote in as Thomas Hargrove earlier (he's my roommate) = because he was on my computer using my burner. Anyways, here it is: =20 Setting up a Gateway =20 Step 1: Note: The following steps assume you have a PCI network = card that you are adding to your machine. If you plan on adding an ISA = network card you are going to have to recompile your kernel after adding = the IRQ and port number (ex. 0x280) to the proper place in your kernel = source. If you already have two PCI network cards installed skip down = to the part that starts "Pick a range.". =20 Install two network cards in a machine running FreeBSD. = One network card should have an IP assigned by your ISP (a static IP) or = by DHCP (a dynamic IP), also assigned by your ISP. This network card is = the external interface and you should have instructions on what to set = the IP and netmask to. Now you have some choices for the other network = card which will be the internal interface. The following IP ranges are = available for private networks: =20 10.0.0.1 - 10.255.255.254 mask 255.0.0.0 172.16.0.1 - 172.16.255.254 mask 255.240.0.0 192.168.0.1 - 192.168.255.254 mask 255.255.0.0 =20 Pick a range and then an IP for your gateway. This IP will the default = gateway you set on all the machines on your internal network. Add a = line in your rc.conf (located in /etc) so this network card is = configured and set up on bootup. =20 In the following example the network is set up with a = FreeBSD machine connected via Pacbell DSL to the internet. Pacbell DSL = provides the IP 216.103.215.136 and the default gateway 216.103.215.254. = The FreeBSD machine is the gateway with an IP of 10.0.1.11 and is = providing NAT (network address translation) for two Windows 98 machines, = with the IP addresses 10.0.1.2 and 10.0.1.3. Both these Windows = machines should set their default gateway to be 10.0.1.11. =20 Example: #here's where you list your network cards (in this example called pn0 = and pn1) network_interfaces=3D"pn0 pn1 lo0" =20 #here's the external interface (IP and default router provided by ISP) ifconfig_pn0=3D"inet 216.103.215.136 netmask 255.255.255.0 defaultrouter=3D"216.103.215.254" =20 #here's the internal interface configuration (what you need to add) ifconfig_pn1=3D"inet 10.0.1.11 netmask 255.255.255.0" =20 Step 2: Now you're ready to configure the kernel. You will need to = recompile the kernel to add the routing options it needs to do NAT = (network address translation). You need to have the kernel source = installed. It will be located in /usr/src/sys. If you do not have this = directory, run /stand/sysinstall and add the Kern-Developer packages. = Here's what you need to do now: =20 # cd /usr/src/sys/i386/conf # cp GENERIC LOCAL =20 Now you need to edit LOCAL with your favorite text editor (vi, emacs, = pico, etc.). In this example I use vi. =20 # vi LOCAL =20 In the options section, add these lines: =20 options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options IPDIVERT =20 Now go the end of the file and make sure that the following line is = there: =20 pseudo-device bpfilter 4 #Berkeley = packet filter =20 The number after bpfilter is adjustable. The number 4 is used above = because it's a good default value, but this number depends on the number = of simultaneously instances you need running on your gateway. For = example, if you plan to run DCHP, NAT, and a tcpdump at the same time, = then you need that number to be 3. Okay, now you're ready to recompile your kernel. Follow = these steps: =20 # config LOCAL # cd /sys/compile/LOCAL # make clean # make depend # make # make install =20 This last step, "make install" copies your old kernel to /kernel.old and = puts in the newly compiled kernel. Now it's time to edit rc.conf again. = Again, use your favorite text editor (my choice is vi here) and add the = following lines: =20 firewall_enable=3D"YES firewall_type=3D"open" gateway_enable=3D"YES" natd_enable=3D"YES" natd_interface=3D"pn0" #This is the = external (public) interface =20 If you get your IP dynamically (ie. Through DHCP) then add the following = line: =20 natd_flags=3D"-dynamic" =20 =20 Step 3: Reboot!!! That's it. If something goes wrong and it = won't boot you can always hit something other than RETURN when it asks = you to and type "boot kernel.old" to boot the machine using your old = kernel. Thanks for letting me write it! Eric Hampshire ------=_NextPart_000_00F4_01BF9520.5FAC9060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Okay, here it is... the documentation = for setting=20 up a gateway under FreeBSD.  I wrote in as Thomas Hargrove earlier = (he's my=20 roommate) because he was on my computer using my burner.  Anyways, = here it=20 is:
 
 

Setting up a=20 Gateway

 

Step=20 1:

           &nbs= p;   =20 Note: The following steps assume you have a PCI network card that = you are=20 adding to your machine.  = If you plan=20 on adding an ISA network card you are going to have to recompile your = kernel=20 after adding the IRQ and port number (ex. 0x280) to the proper place in = your=20 kernel source.  If you = already have=20 two PCI network cards installed skip down to the part that starts = “Pick a=20 range…”.

           &nbs= p;   =20

           &nbs= p;   =20 Install two network cards in a machine running FreeBSD.  One network card should have = an IP=20 assigned by your ISP (a static IP) or by DHCP (a dynamic IP), also = assigned by=20 your ISP.  This network = card is the=20 external interface and you should have instructions on what to set the = IP and=20 netmask to.  Now you have = some=20 choices for the other network card which will be the internal = interface.  The following IP ranges are = available=20 for private networks:

 

10.0.0.1 - = 10.255.255.254 =20             = mask=20 255.0.0.0

172.16.0.1 - = 172.16.255.254 =20            =20 mask 255.240.0.0

192.168.0.1 - = 192.168.255.254 =20          =20 mask 255.255.0.0

 

Pick a range and then an IP for your = gateway.  This IP will the default = gateway you set=20 on all the machines on your internal network.  Add a line in your rc.conf = (located in=20 /etc) so this network card is configured and set up on bootup.

 

           =20 In the following example the network is set up with a FreeBSD = machine=20 connected via Pacbell DSL to the internet. =20 Pacbell DSL provides the IP 216.103.215.136 and the default = gateway=20 216.103.215.254.  The = FreeBSD=20 machine is the gateway with an IP of 10.0.1.11 and is providing NAT = (network=20 address translation) for two Windows 98 machines, with the IP addresses = 10.0.1.2=20 and 10.0.1.3.  Both these = Windows=20 machines should set their default gateway to be 10.0.1.11.

 

Example:

#here’s=20 where you list your network cards (in this example called pn0 and=20 pn1)

network_interfaces=3D”pn0 pn1=20 lo0”

 

#here’s=20 the external interface (IP and default router provided by=20 ISP)

ifconfig_pn0=3D”inet 216.103.215.136=20 netmask 255.255.255.0

defaultrouter=3D”216.103.215.254”

=

 

#here’s=20 the internal interface configuration (what you need to=20 add)

ifconfig_pn1=3D”inet 10.0.1.11=20 netmask 255.255.255.0”


 

Step=20 2:

           =20 Now you’re ready to configure the kernel.  You will need to recompile the = kernel to=20 add the routing options it needs to do NAT (network address = translation).  You need to have the kernel = source=20 installed.  It will be = located in=20 /usr/src/sys.  If you do = not have=20 this directory, run /stand/sysinstall and add the Kern-Developer = packages.  Here’s what you need to = do=20 now:

 

           =20 # cd /usr/src/sys/i386/conf

           =20 # cp GENERIC LOCAL

 

Now you=20 need to edit LOCAL with your favorite text editor (vi, emacs, pico, = etc…).  In this example I use=20 vi.

 

           =20 # vi LOCAL

 

In the=20 options section, add these lines:
 
           =20 options        IPFIREWALL
  =          =20 options        = IPFIREWALL_DEFAULT_TO_ACCEPT
 =20          =20 options        IPDIVERT

 

Now go the=20 end of the file and make sure that the following line is=20 there:

 

           =20 pseudo-device   =            =20 bpfilter 4           =20 #Berkeley packet filter

 

The=20 number after bpfilter is adjustable. =20 The number 4 is used above because it’s a good default = value, but this=20 number depends on the number of simultaneously instances you need = running on=20 your gateway.  For = example, if you=20 plan to run DCHP, NAT, and a tcpdump at the same time, then you need = that number=20 to be 3.

           &nbs= p;   =20 Okay, now you’re ready to recompile your kernel.  Follow these=20 steps:

 

           &nbs= p;   =20 # config LOCAL

           &nbs= p;   =20 # cd /sys/compile/LOCAL

           &nbs= p;   =20 # make clean

           &nbs= p;   =20 # make depend

           &nbs= p;   =20 # make

           &nbs= p;   =20 # make install

 

This last step, = “make=20 install” copies your old kernel to /kernel.old and puts in the = newly compiled=20 kernel.  Now it’s = time to edit=20 rc.conf again.  Again, use = your=20 favorite text editor (my choice is vi here) and add the following=20 lines:

 

           &nbs= p;   =20 firewall_enable=3D”YES

           &nbs= p;   =20 firewall_type=3D”open”

           &nbs= p;   =20 gateway_enable=3D”YES”

           &nbs= p;   =20 natd_enable=3D”YES”

           &nbs= p;   =20 natd_interface=3D”pn0”           &nbs= p;   =20 #This is the external (public) interface

 

If=20 you get your IP dynamically (ie. Through DHCP) then add the following=20 line:

 

           &nbs= p;   =20 natd_flags=3D”-dynamic”

 

 

Step=20 3:

           &nbs= p;   =20 Reboot!!!  = That’s it.  If something goes wrong and it = won’t=20 boot you can always hit something other than RETURN when it asks you to = and type=20 “boot kernel.old” to boot the machine using your old = kernel.

 

 

Thanks for letting = me write=20 it!

Eric=20 Hampshire

------=_NextPart_000_00F4_01BF9520.5FAC9060-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Thu Feb 24 5:39:13 2000 Delivered-To: freebsd-doc@freebsd.org Received: from obelix.unicamp.br (obelix.unicamp.br [143.106.10.2]) by hub.freebsd.org (Postfix) with ESMTP id 9873437BCB0 for ; Thu, 24 Feb 2000 05:39:02 -0800 (PST) (envelope-from larissa@unicamp.br) Received: from unicamp.br (alecrim.hemo.unicamp.br [143.106.132.68]) by obelix.unicamp.br (8.9.3/8.9.3) with ESMTP id LAA11833 for ; Thu, 24 Feb 2000 11:38:54 -0200 (EDT) Message-ID: <38B543DD.1DDD03D@unicamp.br> Date: Thu, 24 Feb 2000 11:44:45 -0300 From: Larissa Velludo Molina Organization: Hemocentro/Unicamp X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-doc@freebsd.org Subject: Filtro Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Boa Tarde. Depois que eu instalei o filtro em meu FreeBSD, meus PCs c/ Windows 95 nao se "enxergam" mais, qual parametro devo colocar no rc.firewall p/ que voltem a se falar? Obrigada. Larissa Molina To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Thu Feb 24 10:29: 8 2000 Delivered-To: freebsd-doc@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 2A33C37BCD2; Thu, 24 Feb 2000 10:28:55 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (from jhb@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id KAA67132; Thu, 24 Feb 2000 10:28:55 -0800 (PST) (envelope-from jhb@FreeBSD.org) Date: Thu, 24 Feb 2000 10:28:55 -0800 (PST) From: Message-Id: <200002241828.KAA67132@freefall.freebsd.org> To: gouders@et.bocholt.fh-gelsenkirchen.de, jhb@FreeBSD.org, freebsd-doc@FreeBSD.org Subject: Re: docs/16943: Missing question mark in FAQ. Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: Missing question mark in FAQ. State-Changed-From-To: open->closed State-Changed-By: jhb State-Changed-When: Thu Feb 24 10:28:37 PST 2000 State-Changed-Why: Committed, thanks! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Thu Feb 24 10:32:40 2000 Delivered-To: freebsd-doc@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id C289737BCD7; Thu, 24 Feb 2000 10:32:38 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (from jhb@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id KAA68851; Thu, 24 Feb 2000 10:32:38 -0800 (PST) (envelope-from jhb@FreeBSD.org) Date: Thu, 24 Feb 2000 10:32:38 -0800 (PST) From: Message-Id: <200002241832.KAA68851@freefall.freebsd.org> To: gouders@et.bocholt.fh-gelsenkirchen.de, jhb@FreeBSD.org, freebsd-doc@FreeBSD.org Subject: Re: docs/16945: Inconsistent use of colon Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: Inconsistent use of colon State-Changed-From-To: open->closed State-Changed-By: jhb State-Changed-When: Thu Feb 24 10:31:23 PST 2000 State-Changed-Why: The section in question has already been rewritten, and the problem is no longer present. Thanks for looking, though.:w To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Thu Feb 24 10:42:55 2000 Delivered-To: freebsd-doc@freebsd.org Received: from server.baldwin.cx (jobaldwi.campus.vt.edu [198.82.67.146]) by hub.freebsd.org (Postfix) with ESMTP id EE92337BC39; Thu, 24 Feb 2000 10:42:39 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from john.baldwin.cx (john [10.0.0.2]) by server.baldwin.cx (8.9.3/8.9.3) with ESMTP id NAA00672; Thu, 24 Feb 2000 13:42:38 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-Id: <200002241842.NAA00672@server.baldwin.cx> X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200002241832.KAA68851@freefall.freebsd.org> Date: Thu, 24 Feb 2000 13:42:38 -0500 (EST) From: John Baldwin To: jhb@FreeBSD.org Subject: Re: docs/16945: Inconsistent use of colon Cc: freebsd-doc@FreeBSD.org, gouders@et.bocholt.fh-gelsenkirchen.de Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 24-Feb-00 jhb@FreeBSD.org wrote: > Synopsis: Inconsistent use of colon > > State-Changed-From-To: open->closed > State-Changed-By: jhb > State-Changed-When: Thu Feb 24 10:31:23 PST 2000 > State-Changed-Why: > The section in question has already been rewritten, and the problem is > no longer present. Thanks for looking, though.:w Can we say, "vi(1) on the brain". *sigh* What's worse is I hit Escape before that, but I did manage to delete that character at least. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Fri Feb 25 4:58:21 2000 Delivered-To: freebsd-doc@freebsd.org Received: from ns.a-net.ne.jp (ns.a-net.ne.jp [210.161.126.226]) by hub.freebsd.org (Postfix) with SMTP id 2E4AF37BD23; Fri, 25 Feb 2000 04:58:11 -0800 (PST) (envelope-from ganba@a-net.ne.jp) Received: from mail.a-net.ne.jp (unverified [210.161.126.7]) by ns.a-net.ne.jp (EMWAC SMTPRS 0.83) with SMTP id ; Fri, 25 Feb 2000 21:55:52 +0900 Message-ID: <200002252157.529@ganba.a-net.ne.jp> Date: Fri, 25 Feb 2000 21:57:17 +0900 From: =?ISO-2022-JP?B?GyRCJCIkZiRfGyhC?= To: ganba@a-net.ne.jp Subject: =?ISO-2022-JP?B?GyRCJGgkJiQzJD0hIiQiJGYkXyROJVshPCVgJVohPCU4GyhC?= =?ISO-2022-JP?B?GyRCJFgbKEI=?= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Mailer: Gen Mail 0.9b X-Antirelay: Good relay from local net2 210.161.126.0/24 Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org $B$O$8$a$^$7$F!"$"$f$_(B $B$H8@$$$^$9!#(B $BFMA3$N%a!<%k$G!"$4$a$s$J$5$$!#(B $B$3$s$J;d$,%[!<%`%Z!<%8$r:n$C$A$c$$$^$7$?!#(B $B$^$@!"2?$bL5$$$s$@$1$I!&!&!&!#(B $B$G$b!"$3$s$J;d$G$b(B"$B%j!{%k!<%He$KBg$-$/$H$j$"$2$F$b$i$($F$H$C$F$b%O%C%T!<$G$9!#(B http://www1.sphere.ne.jp/cube/idol/ $B$I$)!; Fri, 25 Feb 2000 16:10:02 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id QAA46358; Fri, 25 Feb 2000 16:10:02 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from nscache2.x-treme.gr (mail1.x-treme.gr [212.120.196.23]) by hub.freebsd.org (Postfix) with ESMTP id 35F1C37BEC5 for ; Fri, 25 Feb 2000 16:03:37 -0800 (PST) (envelope-from keramida@ceid.upatras.gr) Received: from hades.hell.gr (pat39.x-treme.gr [212.120.197.231]) by nscache2.x-treme.gr (8.9.3/8.9.3/IPNG-ADV-ANTISPAM-0.1) with ESMTP id CAA09186 for ; Sat, 26 Feb 2000 02:03:26 +0200 Received: (from charon@localhost) by hades.hell.gr (8.9.3/8.9.3) id QAA47098; Fri, 25 Feb 2000 16:39:06 +0200 (EET) (envelope-from charon) Message-Id: <200002251439.QAA47098@hades.hell.gr> Date: Fri, 25 Feb 2000 16:39:06 +0200 (EET) From: keramida@ceid.upatras.gr Reply-To: keramida@ceid.upatras.gr To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: docs/16994: discard description in LINT Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 16994 >Category: docs >Synopsis: Description of `disc' does not show that disc = ds[0-9]+ >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Fri Feb 25 16:10:01 PST 2000 >Closed-Date: >Last-Modified: >Originator: Giorgos Keramidas >Release: FreeBSD 4.0-CURRENT i386 >Organization: >Environment: Sources cvsup'ed Feb 23, 2000. >Description: The description of pseudo-device disc in LINT does not show that this is in fact the 'ds' type of interface. >How-To-Repeat: grep '\' LINT >Fix: --- LINT.orig Tue Feb 22 03:58:47 2000 +++ LINT Fri Feb 25 16:34:00 2000 @@ -429,7 +429,7 @@ # simultaneous BPF clients programs runnable. # The `disc' pseudo-device implements a minimal network interface, # which throws away all packets sent and never receives any. It is -# included for testing purposes. +# included for testing purposes. This shows up as the 'ds' interface. # The `tun' pseudo-device implements (user-)ppp and nos-tun # The `gif' pseudo-device implements IPv6 over IP4 tunneling, # IPv4 over IPv6 tunneling, IPv4 over IPv4 tunneling and @@ -451,7 +451,7 @@ pseudo-device sppp #Generic Synchronous PPP pseudo-device loop #Network loopback device pseudo-device bpf #Berkeley packet filter -pseudo-device disc #Discard device +pseudo-device disc #Discard device (ds0, ds1, etc) pseudo-device tun #Tunnel driver (ppp(8), nos-tun(8)) pseudo-device sl 2 #Serial Line IP pseudo-device ppp 2 #Point-to-point protocol >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Fri Feb 25 17:10: 6 2000 Delivered-To: freebsd-doc@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id DC15037BF13 for ; Fri, 25 Feb 2000 17:10:02 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id RAA49677; Fri, 25 Feb 2000 17:10:02 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from rat-thing.netizen.com.au (europa-as63.labyrinth.net.au [202.182.81.63]) by hub.freebsd.org (Postfix) with ESMTP id 3B08037BDBD for ; Fri, 25 Feb 2000 17:00:29 -0800 (PST) (envelope-from benno@rat-thing.netizen.com.au) Received: (from benno@localhost) by rat-thing.netizen.com.au (8.9.3/8.9.3) id MAA00817; Sat, 26 Feb 2000 12:00:25 +1100 (EST) (envelope-from benno) Message-Id: <200002260100.MAA00817@rat-thing.netizen.com.au> Date: Sat, 26 Feb 2000 12:00:25 +1100 (EST) From: benno@netizen.com.au Reply-To: benno@netizen.com.au To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: docs/16995: Typo in ipsec_set_policy.3 Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 16995 >Category: docs >Synopsis: Typo in ipsec_set_policy.3 >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Fri Feb 25 17:10:01 PST 2000 >Closed-Date: >Last-Modified: >Originator: Benno Rice >Release: FreeBSD 4.0-CURRENT i386 >Organization: Netizen Pty Ltd >Environment: 4.0-CURRENT as of 22 Feb 2000. >Description: Minor typo in share/lib/libipsec/ipsec_set_policy.3 >How-To-Repeat: man ipsec_set_policy >Fix: The following patch is for share/lib/libipsec/ipsec_set_policy.3: *** /usr/src/lib/libipsec/ipsec_set_policy.3.orig Sat Feb 26 11:10:59 2000 --- /usr/src/lib/libipsec/ipsec_set_policy.3 Sat Feb 26 11:11:15 2000 *************** *** 244,250 **** .\" .Sh SEE ALSO .Xr ipsec_strerror 3 , ! .Xr ispec 4 .Xr setkey 8 .\" .Sh HISTORY --- 244,250 ---- .\" .Sh SEE ALSO .Xr ipsec_strerror 3 , ! .Xr ipsec 4 , .Xr setkey 8 .\" .Sh HISTORY >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Fri Feb 25 19:15: 5 2000 Delivered-To: freebsd-doc@freebsd.org Received: from berlin.atlantic.net (berlin.atlantic.net [209.208.0.20]) by hub.freebsd.org (Postfix) with ESMTP id 21D2837BEB5; Fri, 25 Feb 2000 19:15:00 -0800 (PST) (envelope-from bobj@atlantic.net) Received: from mail.atlantic.net (IDENT:root@mail.atlantic.net [209.208.0.71]) by berlin.atlantic.net (8.9.3/8.9.3) with ESMTP id WAA25551; Fri, 25 Feb 2000 22:17:35 -0500 Received: from bsd.cisi.com (ocalflifanb-as-1-r2-ip-351.atlantic.net [209.208.31.97]) by mail.atlantic.net (8.9.3/8.9.3) with ESMTP id WAA27634; Fri, 25 Feb 2000 22:14:51 -0500 Received: from nancy.cisi.com (nancy.cisi.com [192.168.0.131]) by bsd.cisi.com (8.9.3/8.9.3) with SMTP id WAA34308; Fri, 25 Feb 2000 22:14:19 -0500 (EST) (envelope-from bobj@atlantic.net) Message-Id: <3.0.6.32.20000225221357.00995cf0@rio.atlantic.net> X-Sender: bobj@rio.atlantic.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Fri, 25 Feb 2000 22:13:57 -0500 To: John Baldwin , jhb@FreeBSD.ORG From: Bob Johnson Subject: Re: docs/16945: Inconsistent use of colon Cc: freebsd-doc@FreeBSD.ORG In-Reply-To: <200002241842.NAA00672@server.baldwin.cx> References: <200002241832.KAA68851@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 01:42 PM 02/24/2000 -0500, John Baldwin wrote: [...] >> no longer present. Thanks for looking, though.:w > >Can we say, "vi(1) on the brain". *sigh* What's worse is I hit Escape >before that, but I did manage to delete that character at least. > You mean it's not an emoticon of you sticking your tongue out at us, or maybe puckered up for a kiss...? >-- > >John Baldwin -- http://www.FreeBSD.org/~jhb/ >PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc >"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ -- Bob +-------------------------------------------------------- | Bob Johnson | bobj@atlantic.net +-------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sat Feb 26 9:34:49 2000 Delivered-To: freebsd-doc@freebsd.org Received: from hotmail.com (oe17.law7.hotmail.com [216.33.236.121]) by hub.freebsd.org (Postfix) with SMTP id 4EF2037BCAB for ; Sat, 26 Feb 2000 09:34:47 -0800 (PST) (envelope-from sharmad_s@hotmail.com) Received: (qmail 20533 invoked by uid 65534); 26 Feb 2000 17:34:45 -0000 Message-ID: <20000226173445.20532.qmail@hotmail.com> X-Originating-IP: [202.54.17.35] From: "Sharmad Naik" To: Subject: Subscribe Date: Sat, 26 Feb 2000 23:02:43 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01BF80AD.9742D3E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0005_01BF80AD.9742D3E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_0005_01BF80AD.9742D3E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_0005_01BF80AD.9742D3E0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sat Feb 26 14:40: 6 2000 Delivered-To: freebsd-doc@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 7114837BE9F for ; Sat, 26 Feb 2000 14:40:01 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id OAA95776; Sat, 26 Feb 2000 14:40:01 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from nscache2.x-treme.gr (mail1.x-treme.gr [212.120.196.23]) by hub.freebsd.org (Postfix) with ESMTP id 7622637B596 for ; Sat, 26 Feb 2000 14:30:44 -0800 (PST) (envelope-from keramida@ceid.upatras.gr) Received: from hades.hell.gr (pat58.x-treme.gr [212.120.197.250]) by nscache2.x-treme.gr (8.9.3/8.9.3/IPNG-ADV-ANTISPAM-0.1) with ESMTP id AAA01579 for ; Sun, 27 Feb 2000 00:30:24 +0200 Received: by hades.hell.gr (Postfix, from userid 1001) id 236EEDD287; Sat, 26 Feb 2000 23:37:16 +0200 (EET) Message-Id: <20000226213716.236EEDD287@hades.hell.gr> Date: Sat, 26 Feb 2000 23:37:16 +0200 (EET) From: keramida@ceid.upatras.gr Reply-To: keramida@ceid.upatras.gr To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: docs/17014: send-pr MAIL_AGENT is unconditionally set Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 17014 >Category: docs >Synopsis: send-pr sets MAIL_AGENT unconditionally >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Sat Feb 26 14:40:01 PST 2000 >Closed-Date: >Last-Modified: >Originator: Giorgos Keramidas >Release: FreeBSD 4.0-CURRENT i386 >Organization: >Environment: The send-pr.sh script of Feb 23, 2000. >Description: The send-pr shell script sets MAIL_AGENT unconditionally. On systems with dialup access, where sendmail might require some custom invocation command line, this fails to use the default value of MAIL_AGENT for the user who runs it. >How-To-Repeat: You can see the relevant command in the installed version of send-pr.sh script, by running: grep MAIL_AGENT `which send-pr` By changing MAIL_AGENT=".." to MAIL_AGENT="${MAIL_AGENT:-..}" any existing value of MAIL_AGENT is preserved. >Fix: --- send-pr.sh.orig Thu Sep 2 15:00:49 1999 +++ send-pr.sh Sat Feb 26 05:20:33 2000 @@ -56,7 +56,7 @@ # What mailer to use. This must come after the config file, since it is # host-dependent. -MAIL_AGENT="/usr/sbin/sendmail -oi -t" +MAIL_AGENT="${MAIL_AGENT:-/usr/sbin/sendmail -oi -t}" ECHON=bsd >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message From owner-freebsd-doc Sat Feb 26 14:40:12 2000 Delivered-To: freebsd-doc@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 29FC537BE17 for ; Sat, 26 Feb 2000 14:40:01 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id OAA95767; Sat, 26 Feb 2000 14:40:01 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from nscache2.x-treme.gr (mail1.x-treme.gr [212.120.196.23]) by hub.freebsd.org (Postfix) with ESMTP id 9B62E37B5BF for ; Sat, 26 Feb 2000 14:30:32 -0800 (PST) (envelope-from keramida@ceid.upatras.gr) Received: from hades.hell.gr (pat58.x-treme.gr [212.120.197.250]) by nscache2.x-treme.gr (8.9.3/8.9.3/IPNG-ADV-ANTISPAM-0.1) with ESMTP id AAA01578 for ; Sun, 27 Feb 2000 00:30:24 +0200 Received: by hades.hell.gr (Postfix, from userid 1001) id B9317DD26F; Sat, 26 Feb 2000 23:48:43 +0200 (EET) Message-Id: <20000226214843.B9317DD26F@hades.hell.gr> Date: Sat, 26 Feb 2000 23:48:43 +0200 (EET) From: keramida@ceid.upatras.gr Reply-To: keramida@ceid.upatras.gr To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: docs/17013: swapon(8) manpage error Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 17013 >Category: docs >Synopsis: swapon(8) manpage error >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Sat Feb 26 14:40:00 PST 2000 >Closed-Date: >Last-Modified: >Originator: Giorgos Keramidas >Release: FreeBSD 4.0-CURRENT i386 >Organization: >Environment: Manpage of swapon last updated in Feb 23, 2000. >Description: The BUGS section of swapon(8) manpage incorrectly states: BUGS There is no way to stop paging and swapping on a device. It is therefore not possible to make use of devices which may be dismounted during system operation. The last sentence effectively states that swapon is useless! >How-To-Repeat: man swapon >Fix: --- swapon.8.orig Sun Sep 26 03:05:45 1999 +++ swapon.8 Sat Feb 26 04:43:25 2000 @@ -88,8 +88,8 @@ .El .Sh BUGS There is no way to stop paging and swapping on a device. -It is therefore not possible to make use of devices which may be -dismounted during system operation. +It is therefore not possible to dismount swap devices which are +mounted during system operation. .Sh HISTORY The .Nm >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message