From owner-freebsd-doc@FreeBSD.ORG Sun Jun 11 09:02:27 2006 Return-Path: X-Original-To: FreeBSD-doc@FreeBSD.org Delivered-To: FreeBSD-doc@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0934616A418; Sun, 11 Jun 2006 09:02:27 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from ms-dienst.rz.rwth-aachen.de (ms-1.rz.RWTH-Aachen.DE [134.130.3.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6032543D46; Sun, 11 Jun 2006 09:02:25 +0000 (GMT) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from circe (circe.rz.RWTH-Aachen.DE [134.130.3.36]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J0O0081AUFZ0C@ms-dienst.rz.rwth-aachen.de>; Sun, 11 Jun 2006 11:02:24 +0200 (MEST) Received: from talos.rz.RWTH-Aachen.DE ([134.130.3.22]) by circe (MailMonitor for SMTP v1.2.2 ) ; Sun, 11 Jun 2006 11:02:23 +0200 (MEST) Received: from bigboss.hitnet.rwth-aachen.de (bigspace.hitnet.RWTH-Aachen.DE [137.226.181.2]) by smarthost.rwth-aachen.de (8.13.1/8.13.1/1) with ESMTP id k5B92Maa000520; Sun, 11 Jun 2006 11:02:22 +0200 Received: from haakonia.hitnet.rwth-aachen.de ([137.226.181.92]) by bigboss.hitnet.rwth-aachen.de with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1FpLpv-0001QY-3b; Sun, 11 Jun 2006 11:02:23 +0200 Received: by haakonia.hitnet.rwth-aachen.de (Postfix, from userid 1001) id C07023F431; Sun, 11 Jun 2006 11:02:22 +0200 (CEST) Date: Sun, 11 Jun 2006 11:02:22 +0200 From: Christian Brueffer In-reply-to: <20060609234535.02fcdc9e.trhodes@FreeBSD.org> To: Tom Rhodes Message-id: <20060611090222.GA1688@haakonia.hitnet.RWTH-Aachen.DE> MIME-version: 1.0 Content-type: multipart/signed; boundary=9jxsPFA5p3P2qPhR; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline User-Agent: Mutt/1.5.11 X-Operating-System: FreeBSD 6.1-STABLE X-PGP-Key: http://people.FreeBSD.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D References: <200606100338.k5A3cIpr058725@repoman.freebsd.org> <20060609234535.02fcdc9e.trhodes@FreeBSD.org> Cc: FreeBSD-doc@FreeBSD.org, doc-committers@FreeBSD.org, Vitaly Bogdanov , cvs-doc@FreeBSD.org Subject: Re: cvs commit: www/ru support.sgml y2kbug.sgml www/ru/tutorials index.sgml www/ru/support webresources.sgml X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 09:02:27 -0000 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 09, 2006 at 11:45:35PM -0400, Tom Rhodes wrote: > On Sat, 10 Jun 2006 03:38:18 +0000 (UTC) > Vitaly Bogdanov wrote: >=20 > > bvs 2006-06-10 03:38:18 UTC > >=20 > > FreeBSD doc repository > >=20 > > Modified files: > > ru y2kbug.sgml support.sgml=20 > > ru/tutorials index.sgml=20 > > ru/support webresources.sgml=20 > > Log: > > MFen: > > y2kbug.sgml: Just correct original revision number > > support.sgml: 1.353 -> 1.354 > > tutorials/index.sgml: 1.23 -> 1.24 > > support/webresources.sgml: 1.1 -> 1.2 >=20 > Nothing wrong with your commit, which is why I moved it to -doc. > But I want to get an idea here. >=20 > Why do we have a y2kbug file still? It's about half way through > 2006! Can we kill this file??? >=20 I certainly won't stop you :-) I haven't heard anyone talking about the y2k bug in years. - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEi9webHYXjKDtmC0RAkUQAJ9HWmsGnxwlXVjgVeOuKgeulzERjQCfZ0dI thxBrmeKVaezdl7Fi0YpKnE= =LFFE -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR-- From owner-freebsd-doc@FreeBSD.ORG Sun Jun 11 09:07:55 2006 Return-Path: X-Original-To: FreeBSD-doc@FreeBSD.org Delivered-To: FreeBSD-doc@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF09C16A41B; Sun, 11 Jun 2006 09:07:55 +0000 (UTC) (envelope-from erwin@mail.droso.net) Received: from mail.droso.net (koala.droso.net [193.88.12.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 621E843D46; Sun, 11 Jun 2006 09:07:55 +0000 (GMT) (envelope-from erwin@mail.droso.net) Received: by mail.droso.net (Postfix, from userid 1001) id 7A4B222C3F; Sun, 11 Jun 2006 11:07:53 +0200 (CEST) Date: Sun, 11 Jun 2006 11:07:53 +0200 From: Erwin Lansing To: Christian Brueffer Message-ID: <20060611090753.GN55035@droso.net> Mail-Followup-To: Christian Brueffer , Tom Rhodes , FreeBSD-doc@FreeBSD.org, doc-committers@FreeBSD.org, cvs-doc@FreeBSD.org References: <200606100338.k5A3cIpr058725@repoman.freebsd.org> <20060609234535.02fcdc9e.trhodes@FreeBSD.org> <20060611090222.GA1688@haakonia.hitnet.RWTH-Aachen.DE> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qlTNgmc+xy1dBmNv" Content-Disposition: inline In-Reply-To: <20060611090222.GA1688@haakonia.hitnet.RWTH-Aachen.DE> X-Operating-System: FreeBSD/i386 5.4-RELEASE User-Agent: Mutt/1.5.11 Cc: Tom Rhodes , FreeBSD-doc@FreeBSD.org, doc-committers@FreeBSD.org, cvs-doc@FreeBSD.org Subject: Re: cvs commit: www/ru support.sgml y2kbug.sgml www/ru/tutorials index.sgml www/ru/support webresources.sgml X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 09:07:56 -0000 --qlTNgmc+xy1dBmNv Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 11, 2006 at 11:02:22AM +0200, Christian Brueffer wrote: > On Fri, Jun 09, 2006 at 11:45:35PM -0400, Tom Rhodes wrote: > > On Sat, 10 Jun 2006 03:38:18 +0000 (UTC) > > Vitaly Bogdanov wrote: > >=20 > > > bvs 2006-06-10 03:38:18 UTC > > >=20 > > > FreeBSD doc repository > > >=20 > > > Modified files: > > > ru y2kbug.sgml support.sgml=20 > > > ru/tutorials index.sgml=20 > > > ru/support webresources.sgml=20 > > > Log: > > > MFen: > > > y2kbug.sgml: Just correct original revision number > > > support.sgml: 1.353 -> 1.354 > > > tutorials/index.sgml: 1.23 -> 1.24 > > > support/webresources.sgml: 1.1 -> 1.2 > >=20 > > Nothing wrong with your commit, which is why I moved it to -doc. > > But I want to get an idea here. > >=20 > > Why do we have a y2kbug file still? It's about half way through > > 2006! Can we kill this file??? > >=20 >=20 > I certainly won't stop you :-) I haven't heard anyone talking about > the y2k bug in years. >=20 You didn't? Then I haven't ranting enough when I found a system that had a y2k bug. Obviously, when I found it some months ago and nobody had fixed it yet, it probably wasn't an important cronjob :-) -erwin PS: it wasn't a FreeBSD system. --=20 Erwin Lansing http://droso.org Security is like an onion. (o_ _o) It's made up of several layers \\\_\ /_/// erwin@FreeBSD.org And it makes you cry. <____) (____> erwin@aauug.dk --qlTNgmc+xy1dBmNv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEi91pqy9aWxUlaZARAmOaAKDyTxiNo99fKNgAChthuKdNxsEIeQCgvmcW tKxV10Xkq484A6JBI8hFmbI= =iZ7y -----END PGP SIGNATURE----- --qlTNgmc+xy1dBmNv-- From owner-freebsd-doc@FreeBSD.ORG Sun Jun 11 11:20:19 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E8D916A41F for ; Sun, 11 Jun 2006 11:20:19 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50B2243D48 for ; Sun, 11 Jun 2006 11:20:18 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k5BBKIck004331 for ; Sun, 11 Jun 2006 11:20:18 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k5BBKI7B004330; Sun, 11 Jun 2006 11:20:18 GMT (envelope-from gnats) Resent-Date: Sun, 11 Jun 2006 11:20:18 GMT Resent-Message-Id: <200606111120.k5BBKI7B004330@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Peter Schuller Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D69EE16A41F for ; Sun, 11 Jun 2006 11:13:01 +0000 (UTC) (envelope-from root@starfury.scode.org) Received: from starfury.scode.org (starfury.scode.org [194.145.249.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E7B843D45 for ; Sun, 11 Jun 2006 11:13:01 +0000 (GMT) (envelope-from root@starfury.scode.org) Received: by starfury.scode.org (Postfix, from userid 0) id 4B1E79A885E; Sun, 11 Jun 2006 13:12:59 +0200 (CEST) Message-Id: <20060611111259.4B1E79A885E@starfury.scode.org> Date: Sun, 11 Jun 2006 13:12:59 +0200 (CEST) From: Peter Schuller To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: docs/98801: gmirror(8) and glabel(8) manpages should mention geom_{mirror, label}_load X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Peter Schuller List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 11:20:19 -0000 >Number: 98801 >Category: docs >Synopsis: gmirror(8) and glabel(8) manpages should mention geom_{mirror,label}_load >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Sun Jun 11 11:20:17 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Peter Schuller >Release: FreeBSD 6.0-RELEASE-p4 i386 >Organization: >Environment: System: FreeBSD starfury.scode.org 6.0-RELEASE-p4 FreeBSD 6.0-RELEASE-p4 #1: Thu Feb 23 16:56:26 CET 2006 scode@starfury.scode.org:/usr/obj/usr/src/sys/STARFURY i386 >Description: The geom_mirror_load and geom_label_load sysctl variables should be mentioned in their classes' respective manpages. I suspect the same is true for the other classes, but I have not personally tried it so I am not including it in the patch. >How-To-Repeat: >Fix: --- sbin/geom/class/mirror/gmirror.8.orig Sun Jun 11 12:44:23 2006 +++ sbin/geom/class/mirror/gmirror.8 Sun Jun 11 13:05:08 2006 @@ -229,6 +229,19 @@ .It Fl v Be more verbose. .El +.Sh SYSCTL VARIABLES +The following +.Xr sysctl 8 +variables can be used to control the behavior of +the +.Nm MIRROR +GEOM class. The default value is shown next to each variable. +.Bl -tag -width indent +.It Va geom_mirror_load : No 0 +When set to 1, instructs the kernel to automatically load the +.Nm MIRROR +GEOM class on boot. +.El .Sh EXIT STATUS Exit status is 0 on success, and 1 if the command fails. .Sh EXAMPLES --- sbin/geom/class/label/glabel.8.orig Sun Jun 11 13:05:42 2006 +++ sbin/geom/class/label/glabel.8 Sun Jun 11 13:06:29 2006 @@ -184,6 +184,10 @@ This can be set to a number between 0 and 2 inclusive. If set to 0 minimal debug information is printed, and if set to 2 the maximum amount of debug information is printed. +.It Va geom_label_load : No 0 +When set to 1, instructs the kernel to automatically load the +.Nm LABEL +GEOM class on boot. .El .Sh EXIT STATUS Exit status is 0 on success, and 1 if the command fails. >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-doc@FreeBSD.ORG Sun Jun 11 11:50:19 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4847216A418 for ; Sun, 11 Jun 2006 11:50:19 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3A5643D48 for ; Sun, 11 Jun 2006 11:50:18 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k5BBoI5h006488 for ; Sun, 11 Jun 2006 11:50:18 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k5BBoICG006487; Sun, 11 Jun 2006 11:50:18 GMT (envelope-from gnats) Date: Sun, 11 Jun 2006 11:50:18 GMT Message-Id: <200606111150.k5BBoICG006487@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Christian Brueffer Cc: Subject: Re: docs/98801: gmirror(8) and glabel(8) manpages should mention geom_{mirror, label}_load X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christian Brueffer List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 11:50:19 -0000 The following reply was made to PR docs/98801; it has been noted by GNATS. From: Christian Brueffer To: Peter Schuller Cc: FreeBSD-gnats-submit@FreeBSD.org Subject: Re: docs/98801: gmirror(8) and glabel(8) manpages should mention geom_{mirror, label}_load Date: Sun, 11 Jun 2006 13:49:50 +0200 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 11, 2006 at 01:12:59PM +0200, Peter Schuller wrote: >=20 > >Number: 98801 > >Category: docs > >Synopsis: gmirror(8) and glabel(8) manpages should mention geom_{m= irror,label}_load > >Confidential: no > >Severity: non-critical > >Priority: medium > >Responsible: freebsd-doc > >State: open > >Quarter: =20 > >Keywords: =20 > >Date-Required: > >Class: change-request > >Submitter-Id: current-users > >Arrival-Date: Sun Jun 11 11:20:17 GMT 2006 > >Closed-Date: > >Last-Modified: > >Originator: Peter Schuller > >Release: FreeBSD 6.0-RELEASE-p4 i386 > >Organization: > >Environment: > System: FreeBSD starfury.scode.org 6.0-RELEASE-p4 FreeBSD 6.0-RELEASE-p4 = #1: Thu Feb 23 16:56:26 CET 2006 scode@starfury.scode.org:/usr/obj/usr/src/= sys/STARFURY i386 >=20 >=20 > >Description: > The geom_mirror_load and geom_label_load sysctl variables should be > mentioned in their classes' respective manpages. I suspect the same > is true for the other classes, but I have not personally tried it > so I am not including it in the patch. > >How-To-Repeat: > >Fix: >=20 > --- sbin/geom/class/mirror/gmirror.8.orig Sun Jun 11 12:44:23 2006 > +++ sbin/geom/class/mirror/gmirror.8 Sun Jun 11 13:05:08 2006 > @@ -229,6 +229,19 @@ > .It Fl v > Be more verbose. > .El > +.Sh SYSCTL VARIABLES > +The following > +.Xr sysctl 8 > +variables can be used to control the behavior of > +the > +.Nm MIRROR > +GEOM class. The default value is shown next to each variable. > +.Bl -tag -width indent > +.It Va geom_mirror_load : No 0 > +When set to 1, instructs the kernel to automatically load the > +.Nm MIRROR > +GEOM class on boot. > +.El > .Sh EXIT STATUS > Exit status is 0 on success, and 1 if the command fails. > .Sh EXAMPLES > --- sbin/geom/class/label/glabel.8.orig Sun Jun 11 13:05:42 2006 > +++ sbin/geom/class/label/glabel.8 Sun Jun 11 13:06:29 2006 > @@ -184,6 +184,10 @@ > This can be set to a number between 0 and 2 inclusive. > If set to 0 minimal debug information is printed, and if set to 2 the > maximum amount of debug information is printed. > +.It Va geom_label_load : No 0 > +When set to 1, instructs the kernel to automatically load the > +.Nm LABEL > +GEOM class on boot. > .El > .Sh EXIT STATUS > Exit status is 0 on success, and 1 if the command fails. >=20 >=20 These are not sysctl variables, but loader instructions. Also IMHO they don't really belong in section 8 manpages. Instead short section 4 manpages for each geom module should be written (some of the information in the section 8 manpages should probably be moved there then). - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEjANebHYXjKDtmC0RAmu4AJ90JlVLvNoFleMuz1NDrJEdZAJwCwCfTyms LOq1cwwH5loXKHHCciIZC0U= =oRDF -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- From owner-freebsd-doc@FreeBSD.ORG Sun Jun 11 13:20:23 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A67BC16A484 for ; Sun, 11 Jun 2006 13:20:23 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9495043D55 for ; Sun, 11 Jun 2006 13:20:21 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k5BDKLh7011705 for ; Sun, 11 Jun 2006 13:20:21 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k5BDKLO3011704; Sun, 11 Jun 2006 13:20:21 GMT (envelope-from gnats) Date: Sun, 11 Jun 2006 13:20:21 GMT Message-Id: <200606111320.k5BDKLO3011704@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Peter Schuller Cc: Subject: Re: docs/98801: gmirror(8) and glabel(8) manpages should mention geom_{mirror, label}_load X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Peter Schuller List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 13:20:23 -0000 The following reply was made to PR docs/98801; it has been noted by GNATS. From: Peter Schuller To: Christian Brueffer Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: docs/98801: gmirror(8) and glabel(8) manpages should mention geom_{mirror, label}_load Date: Sun, 11 Jun 2006 15:11:14 +0200 > These are not sysctl variables, but loader instructions. I was not sure about the nomenclature. I ended up doing what I did based on gstripe(8), which lists loader variables under sysctl variables, but with a note saying they cannot be changed after boot (though I realize I forgot to do the latter). > Also IMHO they > don't really belong in section 8 manpages. Instead short section 4 > manpages for each geom module should be written (some of the information > in the section 8 manpages should probably be moved there then). On the other hand it is very relevant to anyone reading gmirror(8) or glabel(8). At the very least it seems adding it to (8) is better than leaving it as-is, not documented at all. I can propose new section 4 manpages, but I am not sure how much from their corresponding section 8 manpages really belong there. Would you feel a separate manpage is warranted even if it essentially only contains the relevant loader instructions? While there is some information in gmirror(8)/gmirror(9) that refer to the workings of the geom class itself, rather than the tool, I don't know how much sense it makes to try to strip those pages of that information given that it is so directly relevant to operation of the tool. Perhaps the introductory general information on meta-data layout and general operations. I presume the section for manpages would preferably be named geom_XXX (in keeping with geom(4)). -- / Peter Schuller, InfiDyne Technologies HB PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org From owner-freebsd-doc@FreeBSD.ORG Sun Jun 11 19:44:50 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0ADB416A41F; Sun, 11 Jun 2006 19:44:50 +0000 (UTC) (envelope-from maxim@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A461143D69; Sun, 11 Jun 2006 19:44:49 +0000 (GMT) (envelope-from maxim@FreeBSD.org) Received: from freefall.freebsd.org (maxim@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k5BJinG2039576; Sun, 11 Jun 2006 19:44:49 GMT (envelope-from maxim@freefall.freebsd.org) Received: (from maxim@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k5BJinTk039572; Sun, 11 Jun 2006 19:44:49 GMT (envelope-from maxim) Date: Sun, 11 Jun 2006 19:44:49 GMT From: Maxim Konovalov Message-Id: <200606111944.k5BJinTk039572@freefall.freebsd.org> To: solinym@gmail.com, maxim@FreeBSD.org, freebsd-doc@FreeBSD.org Cc: Subject: Re: docs/98340: vinum(4) refers to vinum(8) which does not exist X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 19:44:50 -0000 Synopsis: vinum(4) refers to vinum(8) which does not exist State-Changed-From-To: open->patched State-Changed-By: maxim State-Changed-When: Sun Jun 11 19:43:50 UTC 2006 State-Changed-Why: Fixed in HEAD and will be MFC'ed in one week. gvinum(8) does have a man page: http://www.freebsd.org/cgi/man.cgi?query=gvinum Thanks for the report! http://www.freebsd.org/cgi/query-pr.cgi?pr=98340 From owner-freebsd-doc@FreeBSD.ORG Sun Jun 11 20:10:17 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D2B4A16A4A1 for ; Sun, 11 Jun 2006 20:10:17 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CEE943D46 for ; Sun, 11 Jun 2006 20:10:17 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k5BKAEKm040956 for ; Sun, 11 Jun 2006 20:10:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k5BKAEKo040955; Sun, 11 Jun 2006 20:10:14 GMT (envelope-from gnats) Date: Sun, 11 Jun 2006 20:10:14 GMT Message-Id: <200606112010.k5BKAEKo040955@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Maxim Konovalov Cc: Subject: docs/97521 X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Maxim Konovalov List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 20:10:17 -0000 The following reply was made to PR docs/97521; it has been noted by GNATS. From: Maxim Konovalov To: thierry herbelot Cc: bug-followup@freebsd.org Subject: docs/97521 Date: Mon, 12 Jun 2006 00:03:13 +0400 (MSD) Hi Thierry, This is just an advise not a strict rule (should vs must). There is no such limitation in the kernel. kvm(3) limits wmesg length by WMESGLEN (defined in sys/user.h) plus terminating NULL. If you don't object I'll close this PR. -- Maxim Konovalov From owner-freebsd-doc@FreeBSD.ORG Sun Jun 11 21:00:42 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B78416A41A for ; Sun, 11 Jun 2006 21:00:42 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A46EE43D48 for ; Sun, 11 Jun 2006 21:00:41 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k5BL0fSZ045170 for ; Sun, 11 Jun 2006 21:00:41 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k5BL0fH1045169; Sun, 11 Jun 2006 21:00:41 GMT (envelope-from gnats) Date: Sun, 11 Jun 2006 21:00:41 GMT Message-Id: <200606112100.k5BL0fH1045169@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Thierry Herbelot Cc: Subject: Re: docs/97521 X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Thierry Herbelot List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 21:00:42 -0000 The following reply was made to PR docs/97521; it has been noted by GNATS. From: Thierry Herbelot To: Maxim Konovalov Cc: bug-followup@freebsd.org Subject: Re: docs/97521 Date: Sun, 11 Jun 2006 22:50:03 +0200 Le Sunday 11 June 2006 22:03, Maxim Konovalov a écrit : > Hi Thierry, > > This is just an advise not a strict rule (should vs must). There is > no such limitation in the kernel. kvm(3) limits wmesg length by > WMESGLEN (defined in sys/user.h) plus terminating NULL. > > If you don't object I'll close this PR. Hello Maxim no problem for me : I just would have liked to have a more explicit wording to define the length of authorized strings. TfH From owner-freebsd-doc@FreeBSD.ORG Sun Jun 11 21:10:24 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 27DCD16A473 for ; Sun, 11 Jun 2006 21:10:24 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 672FA43D5C for ; Sun, 11 Jun 2006 21:10:23 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k5BLAMh5045436 for ; Sun, 11 Jun 2006 21:10:22 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k5BLAMUR045431; Sun, 11 Jun 2006 21:10:22 GMT (envelope-from gnats) Date: Sun, 11 Jun 2006 21:10:22 GMT Message-Id: <200606112110.k5BLAMUR045431@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Maxim Konovalov Cc: Subject: Re: docs/98406: ethers(5): "ethernet-adress" and "fully-qualified-host-name" in wrong order X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Maxim Konovalov List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 21:10:24 -0000 The following reply was made to PR docs/98406; it has been noted by GNATS. From: Maxim Konovalov To: Patrick Hess Cc: bug-follwoup@freebsd.org Subject: Re: docs/98406: ethers(5): "ethernet-adress" and "fully-qualified-host-name" in wrong order Date: Mon, 12 Jun 2006 00:56:55 +0400 (MSD) Hi Patrick, [...] > >Description: > ethers(5) states: > > The ethers database contains information regarding known 48-bit > ethernet addresses of hosts on an Internetwork. The data is > stored in a file called /etc/ethers in the following format: > > ethernet-address fully-qualified-host-name > > Should be: > > fully-qualified-host-name ethernet-address What makes you think so? src/lib/libc/net/ether_addr.c::ether_line(): % i = sscanf(l, "%x:%x:%x:%x:%x:%x %s", &o[0], &o[1], &o[2], % &o[3], &o[4], &o[5], % hostname); ether_line(3) expects the fields in order described in the man page. I won't be surprised if there is a program outside the base system which reads /etc/ethers in opposite order but that won't be FreeBSD problem. -- Maxim Konovalov From owner-freebsd-doc@FreeBSD.ORG Mon Jun 12 04:10:22 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DE3116A418 for ; Mon, 12 Jun 2006 04:10:22 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6E9F43D46 for ; Mon, 12 Jun 2006 04:10:21 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k5C4ALi2074403 for ; Mon, 12 Jun 2006 04:10:21 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k5C4ALZO074401; Mon, 12 Jun 2006 04:10:21 GMT (envelope-from gnats) Resent-Date: Mon, 12 Jun 2006 04:10:21 GMT Resent-Message-Id: <200606120410.k5C4ALZO074401@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Ian Cognito Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8986F16A46F for ; Mon, 12 Jun 2006 04:09:18 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5600343D49 for ; Mon, 12 Jun 2006 04:09:18 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k5C49INS016041 for ; Mon, 12 Jun 2006 04:09:18 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id k5C49Ihg016040; Mon, 12 Jun 2006 04:09:18 GMT (envelope-from nobody) Message-Id: <200606120409.k5C49Ihg016040@www.freebsd.org> Date: Mon, 12 Jun 2006 04:09:18 GMT From: Ian Cognito To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: docs/98842: misc requests for gdbe X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 04:10:22 -0000 >Number: 98842 >Category: docs >Synopsis: misc requests for gdbe >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: Mon Jun 12 04:10:20 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Ian Cognito >Release: 6.0 >Organization: >Environment: >Description: First, let me say gbde is fairly impressive, and my requests in no way constitute bashing it. In the documentation, it'd be nice if we had some idea of how much entropy the passphrase should contain to prevent it from being the weakest link in the security. The following ideas were taken from truecrypt. I haven't really thought through whether they buy us much, so take them as food for thought... It would be nice if we could specify a file on the filesystem which could be used in conjunction with the key to provide enough entropy for said pass phrase, and especially to be able to read it from a pipe (I do not know if gdbe can do this or not). Alternately it could be used in conjunction with the standard key mechanisms to create the sector keys, and so a passphrase alone is insufficient to gain access to plaintext. Either way it's sort of a cheap way of getting a lot of entropy out of a memorable passphrase, which tends to be somewhat weak alone (1-2 bits per letter). >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-doc@FreeBSD.ORG Mon Jun 12 11:01:12 2006 Return-Path: X-Original-To: freebsd-doc@freebsd.org Delivered-To: freebsd-doc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA5C816A41A for ; Mon, 12 Jun 2006 11:01:12 +0000 (UTC) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4949C43D46 for ; Mon, 12 Jun 2006 11:01:12 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k5CB1CBC097974 for ; Mon, 12 Jun 2006 11:01:12 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k5CB18aR097966 for freebsd-doc@freebsd.org; Mon, 12 Jun 2006 11:01:08 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 12 Jun 2006 11:01:08 GMT Message-Id: <200606121101.k5CB18aR097966@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 X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 11:01:12 -0000 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 problem is understood and a solution is being sought. f - feedback Further work requires additional information from the originator or the community - possibly confirmation of the effectiveness of a proposed solution. p - patched A patch has been committed, but some issues (MFC and / or confirmation from originator) are still open. s - suspended The problem is not being worked on, due to lack of information or resources. 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 -- or when fixing the problem is abandoned. Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/05/24] docs/27605 doc [patch] Cross-document references ( tags o [2001/02/02] docs/24786 doc missing FILES descriptions in sa(4) o [2001/04/02] docs/26286 doc *printf(3) etc should gain format string a [2001/08/23] docs/30008 doc [patch] French softupdates document shoul s [2001/10/07] docs/31109 doc [patch] replace gif images w/ png ones du s [2002/01/05] docs/33589 doc [patch] to doc.docbook.mk to post process o [2002/01/14] docs/33852 doc split(1) man page implies that input file a [2002/02/16] docs/35011 doc There are no commands called "diskless" o o [2002/02/22] docs/35222 doc [patch] getmsg.cgi: mailing list archive o [2002/03/06] docs/35608 doc mt(1) page uses "setmark" without explana o [2002/03/06] docs/35609 doc mt(1) page needs explanation of "long era o [2002/03/06] docs/35612 doc ps(1) page "state" description doesn't me o [2002/03/16] docs/35943 doc at(1) config files are misplaced in /var/ o [2002/03/16] docs/35953 doc hosts.equiv(5) manual is confusing or wro o [2002/03/28] docs/36432 doc Proposal for doc/share/mk: make folded bo o [2002/03/29] docs/36449 doc symlink(7) manual doesn't mention trailin o [2002/05/27] docs/38620 doc suggestion: minor rework of question in C o [2002/06/07] docs/38982 doc [patch] developers-handbook/Jail fix o [2002/06/15] docs/39348 doc diskless(8): note that kenv fetch of host o [2002/06/19] docs/39530 doc access(2) man page has unnecessarily broa o [2002/07/10] docs/40423 doc Keyboard(4)'s definition of parameters to o [2002/07/28] docs/41089 doc pax(1) -B option does not mention interac o [2002/08/20] docs/41807 doc [patch] natd(8): document natd -punch_fw o [2002/08/20] docs/41820 doc Device driver confusion in Handbook (sect o [2002/10/04] docs/43651 doc stab(5) incorrectly states to include jus o [2002/10/08] docs/43823 doc [PATCH] update to environ(7) manpage o [2002/10/09] docs/43861 doc non-trivial typo in wicontrol(8) man page o [2002/10/11] docs/43941 doc document the Rationale for Upgrade Sequen o [2002/10/15] docs/44074 doc [patch] ln(1) manual clarifications o [2002/10/29] docs/44594 doc Handbook doesn't mention drivers.flp for o [2002/12/02] docs/45940 doc burncd(1) missing info o [2002/12/11] docs/46196 doc [patch] menu_format(3): Missing return va o [2002/12/16] docs/46291 doc correlation between HZ kernel config para o [2002/12/16] docs/46295 doc please add information to Nvi recovery em o [2003/01/28] docs/47594 doc [PATCH] passwd(5) incorrectly states allo o [2003/02/02] docs/47818 doc [patch] ln(1) manpage is confusing o [2003/02/08] docs/48101 doc [patch] add documentation on the fixit di o [2003/03/06] docs/48980 doc [patch] nsgmls -s errors and sect. 3.2.1 o [2003/03/23] docs/50211 doc [PATCH] doc.docbook.mk: fix textfile crea o [2003/04/03] docs/50573 doc resolver(3): return values for res_query/ o [2003/05/06] docs/51875 doc [patch] atkbd(4) adjustment o [2003/05/06] docs/51891 doc DIAGNOSTICS in ed(4) driver manpage don't o [2003/05/07] docs/51921 doc [patch] ls(1) manpage lacks some informat o [2003/05/11] docs/52071 doc [PATCH] Add more information about soft u o [2003/06/21] docs/53575 doc Change to Handbook Section 20.9 (SMTP Aut o [2003/06/21] docs/53596 doc Updates to mt(1) manual page o [2003/06/25] docs/53732 doc quota output and quota(1) man page do not o [2003/07/13] docs/54451 doc [patch] i386_get_ldt(2): i386_{get|set}_l o [2003/07/26] docs/54879 doc jot(1) -r description s [2003/08/12] docs/55482 doc document the fact that DUMP has access to o [2003/09/24] docs/57153 doc S_IRWXU missing in fstat(2) man page? o [2003/09/30] docs/57388 doc [patch] INSTALL.TXT enhancement: mention o [2003/10/04] docs/57569 doc error on gensetdefs(8) man page o [2003/10/13] docs/57926 doc [patch] amd.conf(5) poorly format as it h o [2003/10/13] docs/57974 doc man page apropos for select macros (FD_SE o [2003/10/30] docs/58710 doc killpg(2) contains an error regarding sen o [2003/11/07] docs/59044 doc [patch] doc.docbook.mk does not properly o [2003/11/19] docs/59477 doc Outdated Info Documents at http://docs.fr o [2003/11/30] docs/59835 doc ipfw(8) man page does not warn about acce o [2003/12/23] docs/60529 doc resolver(5) man page is badly out of date o [2003/12/24] docs/60544 doc [patch] getenv(3) manpage doesn't state t o [2004/01/08] docs/61070 doc handbook: Installation docs misleading: o [2004/01/13] docs/61301 doc [patch] Manpage patch for aue(4) to enabl o [2004/01/21] docs/61667 doc Obsolete documentation on FreeBSD PnP o [2004/01/25] docs/61859 doc ddb(4): Incorrect informaiton about trace o [2004/02/06] docs/62412 doc one of the diskless boot methods describe o [2004/02/12] docs/62719 doc cross-reference pccardd(8) and devd(8) o [2004/02/12] docs/62724 doc [patch] host(1) manpage does not include o [2004/02/22] docs/63215 doc Wrong prototypes in mi_switch(9) (ref doc o [2004/03/27] docs/64807 doc Handbook section on NAT incomplete o [2004/04/02] docs/65065 doc [patch] improper language ntpd(8) man pag o [2004/04/13] docs/65477 doc release notes: installation instruction f o [2004/04/14] docs/65530 doc [patch] minor improvement to getgrent(3) o [2004/05/04] docs/66265 doc [patch] Document what -f and LD_TRACE_LOA o [2004/05/05] docs/66296 doc [patch] contrib/amd/amq/amq.8 uses log_op o [2004/05/07] docs/66343 doc [patch] unlisted supported card on man pa o [2004/05/10] docs/66483 doc [patch] share/man/man4/csa.4 grammar nits o [2004/05/17] docs/66770 doc [patch] share/man/man4/ng_pppoe.4 tyops, o [2004/05/23] docs/67078 doc [patch] MFC of a rtld(1) man page is inco f [2004/06/10] docs/67806 doc [patch] Let 5.x users know how to boot in o [2004/07/09] docs/68843 doc Dates on rc.subr(8) & rc(8) are whack. o [2004/07/09] docs/68845 doc The .At macro produces unexpected results o [2004/08/01] docs/69861 doc [patch] usr.bin/csplit/csplit.1 does not o [2004/08/09] docs/70217 doc [patch] Suggested rewrite of docproj/sgml o [2004/08/20] docs/70697 doc pcm(4) is out of date o [2004/09/10] docs/71555 doc handbook: changes for how to run matlab o o [2004/09/13] docs/71690 doc [patch] inaccurate information in systat( f [2004/09/21] docs/71980 doc Handbook says that no other software is k o [2004/10/06] docs/72383 doc manpage for awk(1) is terribly small and o [2004/11/06] docs/73583 doc [patch] add missing instructions to ndis( o [2004/11/07] docs/73638 doc ipfw(8): Clarify syntax for use of tables o [2004/11/08] docs/73679 doc FreeBSD 5.3 Release notes mention new nat o [2004/11/28] docs/74477 doc [patch] Correct several links in the cont o [2004/12/02] docs/74612 doc [patch] updates to the glossary o [2004/12/14] docs/75068 doc login.conf(5) manual page says nothing ab o [2004/12/28] docs/75577 doc [patch] typos in man3 manual pages, login o [2005/01/05] docs/75865 doc comments on "backup-basics" in handbook o [2005/01/09] docs/75995 doc hcreate(3) documentation(?) bug o [2005/01/11] docs/76094 doc handbooke: incorrect statement about part o [2005/01/17] docs/76333 doc [patch] ferror(3): EOF indicator can be c o [2005/01/20] docs/76515 doc [patch] misleading use of make -j flag in o [2005/02/04] docs/77087 doc [patch] the bootvinum script given in the o [2005/02/24] docs/78041 doc [patch] docs for md(4) need further expla o [2005/02/27] docs/78138 doc [patch] Error in pre-installation section o [2005/03/01] docs/78240 doc [patch] handbook: replace with f [2005/03/05] docs/78440 doc POSIX semaphores don't work by default in o [2005/03/06] docs/78480 doc Networked printer setup unnecessarily com o [2005/03/07] docs/78520 doc error in man(5) lpd.conf, lpd.perms pages o [2005/03/16] docs/78915 doc rfork(2)'s RFTHREAD is not documented o [2005/03/23] docs/79156 doc buffersize knob for sound(4) is a tunable o [2005/04/20] docs/80159 doc [patch] rtld(1) mentions "%m" but it's no o [2005/05/11] docs/80871 doc terminfo(5) man page source corrupted o [2005/06/01] docs/81776 doc ifconfig(8) man page not updated with car o [2005/06/10] docs/82114 doc ndisapi(9) manual page cross-referenced b o [2005/06/21] docs/82481 doc tar(1)/gtar(1) man page mod request o [2005/06/22] docs/82508 doc misleading man page for basename(3)/dirna o [2005/06/24] docs/82595 doc 25.5.3 Configuring a bridge section of th o [2005/06/29] docs/82779 doc [patch] Kill entry for ddb manpage o [2005/07/17] docs/83621 doc [patch]: Minor omissions in /usr/src/UPDA p [2005/07/26] docs/84101 doc [patch] mt(1) manpage has erroneous synop o [2005/07/27] docs/84154 doc Handbook somewhat off in use of /boot/ker o [2005/07/29] docs/84265 doc [patch] chmod(1) manpage omits implicatio p [2005/07/29] docs/84266 doc [patch] security(8) manpage should have i o [2005/07/29] docs/84267 doc [patch] chflags(1) manual doesn't say it' o [2005/07/29] docs/84268 doc chmod(1) manpage's BUGS entry is either w o [2005/07/29] docs/84317 doc fdp-primer doesn't show class=USERNAME di o [2005/07/31] docs/84408 doc [patch] dump(8) manpage doesn't require a o [2005/08/02] docs/84467 doc [patch] bsdlabel(8) manpage uses archaic s [2005/08/03] docs/84519 doc [patch] mdoc(7) manpage needs more about o [2005/08/04] docs/84538 doc sk(4) driver supports Marvell 88E800x chi o [2005/08/04] docs/84549 doc [patch] errno(2) manpage uses "<...>" for s [2005/08/04] docs/84550 doc mdoc(7) manpage erroneously requires SYNO o [2005/08/07] docs/84645 doc intro(6) manpage should always be install o [2005/08/08] docs/84670 doc [patch] tput(1) manpage missing ENVIRONME o [2005/08/10] docs/84764 doc [patch] hosts.equiv(5) manpage should SEE o [2005/08/11] docs/84806 doc mdoc(7) manpage has section ordering prob o [2005/08/12] docs/84849 doc [patch] fdisk(8) manpage doesn't warn fdi o [2005/08/14] docs/84913 doc bsdlabel(8) manpage seems wrong about fsi o [2005/08/15] docs/84955 doc [patch] mdoc(7) manpage should mention mi o [2005/08/15] docs/84956 doc [patch] intro(5) manpage doesn't mention o [2005/08/17] docs/85062 doc [patch] tr(1) manpage omits several chara o [2005/08/17] docs/85063 doc [patch] expand(1) manpage needs to clarif o [2005/08/17] docs/85066 doc [patch] builtin(1) manpage has incomplete o [2005/08/18] docs/85097 doc [patch] devd.conf.5 lacks a lot of vital o [2005/08/18] docs/85100 doc NOTES: ICH audio device support statement o [2005/08/19] docs/85118 doc [PATCH] opiekey(1) references non-existin o [2005/08/19] docs/85127 doc [patch] loader(8) manpage uses too-rare " o [2005/08/19] docs/85128 doc loader.conf(5) autoboot_delay incompletly o [2005/08/21] docs/85186 doc [patch] ktrace(1) manpage doesn't warn ab o [2005/08/21] docs/85187 doc [patch] find(1) manpage missing block inf o [2005/08/23] docs/85243 doc Missing icmp related abbreviations for pf o [2005/08/27] docs/85353 doc [patch] minor cosmetic/punctuation change o [2005/09/19] docs/86342 doc bikeshed entry of Handbook is wrong o [2005/09/29] docs/86733 doc [patch] handbook: add using kldload as an o [2005/10/23] docs/87857 doc ifconfig(8) wireless options order matter o [2005/10/24] docs/87936 doc Handbook chapter on NIS/YP lacks good inf o [2005/11/04] docs/88477 doc Possible addition to xl(4) manpage, Diagn o [2005/11/04] docs/88503 doc mkuzip(8) references nonexistant geom_uzi o [2005/11/05] docs/88512 doc [patch] mount_ext2fs(8) man page has no d o [2005/11/20] docs/89325 doc [PATCH] Clarification of kbdmap(5), atkbd o [2005/11/24] docs/89492 doc vfs doc: some VOP_*(9) manual pages are o o [2005/11/30] docs/89747 doc [PATCH] faq: s/kbd0/ukbd0/ when USB keybo o [2005/12/16] docs/90498 doc [patch] wrong parameter name to function o [2005/12/20] docs/90711 doc missing man page for sigtimedwait(2) o [2005/12/31] docs/91149 doc read(2) can return EINVAL for unaligned a o [2006/01/04] docs/91297 doc restore(8) man page not accurate? o [2006/01/08] docs/91506 doc ndis(4) man page should be more specific o [2006/01/31] docs/92626 doc jail manpage should mention disabling som o [2006/02/12] docs/93249 doc rewrite of handbook chapter 23 (PPP & SLI o [2006/02/14] docs/93363 doc Handbook 23.11. SMTP-Authentifizierung o [2006/02/17] docs/93491 doc discrepancy man page for pam_unix(8) f [2006/02/18] docs/93517 doc Presented usage of Ports in Handbook lack o [2006/02/20] docs/93590 doc [patch] pf.conf's man page mentions route o [2006/03/06] docs/94125 doc DGE-530T doesn't work on FreeBSD v6.0 o [2006/03/17] docs/94625 doc [patch] growfs man page -- document "pani o [2006/03/21] docs/94803 doc Slightly confusing/misleading man page fo o [2006/03/28] docs/95039 doc [patch] small cosmetic syslog.conf(5) fix o [2006/03/30] docs/95104 doc tsleep() man page mentions nonexistent 'm o [2006/03/31] docs/95139 doc FAQ to move filesystem to new disk fails: o [2006/04/21] docs/96127 doc add hint to pass arp packets through filt o [2006/04/23] docs/96207 doc Comments of a sockaddr_un structure could o [2006/05/13] docs/97231 doc [patch] ndis(4) man page outdated o [2006/05/14] docs/97237 doc [patch] Fix dead links in FAQ o [2006/05/17] docs/97375 doc [PATCH] remove nonexistent man page refer o [2006/05/17] docs/97409 doc Incorrect command name in Kerberos sectio o [2006/05/20] docs/97521 doc inconsistency in tsleep(9) manpage o [2006/05/26] docs/97939 doc some mistake in man of amq(8) o [2006/05/30] docs/98129 doc older versions of the handbook not easy t p [2006/06/02] docs/98340 doc vinum(4) refers to vinum(8) which does no o [2006/06/02] docs/98344 doc [patch] An update of the article "Choosin o [2006/06/02] docs/98406 doc ethers(5): "ethernet-adress" and "fully-q o [2006/06/09] docs/98759 doc [patch] sbp_targ(4) man page missing refe o [2006/06/11] docs/98801 doc [patch] gmirror(8) and glabel(8) manpages 193 problems total. From owner-freebsd-doc@FreeBSD.ORG Mon Jun 12 15:33:44 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8082D16A41F; Mon, 12 Jun 2006 15:33:44 +0000 (UTC) (envelope-from maxim@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33C0843D49; Mon, 12 Jun 2006 15:33:44 +0000 (GMT) (envelope-from maxim@FreeBSD.org) Received: from freefall.freebsd.org (maxim@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k5CFXipf022650; Mon, 12 Jun 2006 15:33:44 GMT (envelope-from maxim@freefall.freebsd.org) Received: (from maxim@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k5CFXhAd022644; Mon, 12 Jun 2006 15:33:43 GMT (envelope-from maxim) Date: Mon, 12 Jun 2006 15:33:43 GMT From: Maxim Konovalov Message-Id: <200606121533.k5CFXhAd022644@freefall.freebsd.org> To: freebsd@sopwith.solgatos.com, maxim@FreeBSD.org, freebsd-doc@FreeBSD.org Cc: Subject: Re: docs/90711: missing man page for sigtimedwait(2) X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 15:33:44 -0000 Synopsis: missing man page for sigtimedwait(2) State-Changed-From-To: open->patched State-Changed-By: maxim State-Changed-When: Mon Jun 12 15:32:15 UTC 2006 State-Changed-Why: There is sigtimedwait(2) man page in HEAD. Perhaps need to import it to RELENG_6 eventually. http://www.freebsd.org/cgi/query-pr.cgi?pr=90711 From owner-freebsd-doc@FreeBSD.ORG Mon Jun 12 15:34:42 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBD2516A41F; Mon, 12 Jun 2006 15:34:42 +0000 (UTC) (envelope-from maxim@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94BF443D49; Mon, 12 Jun 2006 15:34:42 +0000 (GMT) (envelope-from maxim@FreeBSD.org) Received: from freefall.freebsd.org (maxim@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k5CFYgZW022706; Mon, 12 Jun 2006 15:34:42 GMT (envelope-from maxim@freefall.freebsd.org) Received: (from maxim@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k5CFYgOc022702; Mon, 12 Jun 2006 15:34:42 GMT (envelope-from maxim) Date: Mon, 12 Jun 2006 15:34:42 GMT From: Maxim Konovalov Message-Id: <200606121534.k5CFYgOc022702@freefall.freebsd.org> To: maxim@FreeBSD.org, freebsd-doc@FreeBSD.org, davidxu@FreeBSD.org Cc: Subject: Re: docs/90711: missing man page for sigtimedwait(2) X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 15:34:42 -0000 Synopsis: missing man page for sigtimedwait(2) Responsible-Changed-From-To: freebsd-doc->davidxu Responsible-Changed-By: maxim Responsible-Changed-When: Mon Jun 12 15:33:56 UTC 2006 Responsible-Changed-Why: Over to the author of te sigtimedwait(2) man page for consideration. http://www.freebsd.org/cgi/query-pr.cgi?pr=90711 From owner-freebsd-doc@FreeBSD.ORG Mon Jun 12 20:39:10 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A782816A474; Mon, 12 Jun 2006 20:39:10 +0000 (UTC) (envelope-from maxim@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60A3943D45; Mon, 12 Jun 2006 20:39:10 +0000 (GMT) (envelope-from maxim@FreeBSD.org) Received: from freefall.freebsd.org (maxim@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k5CKdAEP046097; Mon, 12 Jun 2006 20:39:10 GMT (envelope-from maxim@freefall.freebsd.org) Received: (from maxim@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k5CKd9sk046093; Mon, 12 Jun 2006 20:39:09 GMT (envelope-from maxim) Date: Mon, 12 Jun 2006 20:39:09 GMT From: Maxim Konovalov Message-Id: <200606122039.k5CKd9sk046093@freefall.freebsd.org> To: thierry@herbelot.com, maxim@FreeBSD.org, freebsd-doc@FreeBSD.org Cc: Subject: Re: docs/97521: inconsistency in tsleep(9) manpage X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 20:39:10 -0000 Synopsis: inconsistency in tsleep(9) manpage State-Changed-From-To: open->closed State-Changed-By: maxim State-Changed-When: Mon Jun 12 20:37:22 UTC 2006 State-Changed-Why: The statement about wmesg length is just a convention not a strict rule. Actually there is no such limit in the kernel land. http://www.freebsd.org/cgi/query-pr.cgi?pr=97521 From owner-freebsd-doc@FreeBSD.ORG Mon Jun 12 21:35:22 2006 Return-Path: X-Original-To: freebsd-doc@freebsd.org Delivered-To: freebsd-doc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77A8216A41F for ; Mon, 12 Jun 2006 21:35:22 +0000 (UTC) (envelope-from rdm@cfcl.com) Received: from cfcl.com (cpe-24-221-172-174.ca.sprintbbd.net [24.221.172.174]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13A3E43D46 for ; Mon, 12 Jun 2006 21:35:21 +0000 (GMT) (envelope-from rdm@cfcl.com) Received: from [192.168.254.205] ([192.168.254.205]) by cfcl.com (8.12.6/8.12.6) with ESMTP id k5CLe9vF016093 for ; Mon, 12 Jun 2006 14:40:11 -0700 (PDT) (envelope-from rdm@cfcl.com) Mime-Version: 1.0 Message-Id: Date: Mon, 12 Jun 2006 14:36:49 -0700 To: freebsd-doc@freebsd.org From: Rich Morin Content-Type: text/plain; charset="us-ascii" Subject: mandoc question X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 21:35:22 -0000 Assuming that I have a function argument n and want to say something like: The n'th character is ignored. How do I use the .Fa macro (or whatever) to do this. My current code is The .Fa n'th character is ignored. but that highlights all of "n'th". I've tried a couple of other possibilities (along with RTFM), but no luck so far. Help? -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development From owner-freebsd-doc@FreeBSD.ORG Tue Jun 13 02:46:49 2006 Return-Path: X-Original-To: freebsd-doc@freebsd.org Delivered-To: freebsd-doc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 331A616A478 for ; Tue, 13 Jun 2006 02:46:49 +0000 (UTC) (envelope-from rdm@cfcl.com) Received: from cfcl.com (cpe-24-221-172-174.ca.sprintbbd.net [24.221.172.174]) by mx1.FreeBSD.org (Postfix) with ESMTP id A171B43D46 for ; Tue, 13 Jun 2006 02:46:48 +0000 (GMT) (envelope-from rdm@cfcl.com) Received: from [192.168.254.205] ([192.168.254.205]) by cfcl.com (8.12.6/8.12.6) with ESMTP id k5D2pRvF061135 for ; Mon, 12 Jun 2006 19:51:36 -0700 (PDT) (envelope-from rdm@cfcl.com) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 12 Jun 2006 19:48:03 -0700 To: freebsd-doc@freebsd.org From: Rich Morin Content-Type: text/plain; charset="us-ascii" Subject: Re: mandoc question X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 02:46:49 -0000 It turns out that there's a more general solution: .Fa n Ns \'th -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development From owner-freebsd-doc@FreeBSD.ORG Tue Jun 13 02:49:43 2006 Return-Path: X-Original-To: freebsd-doc@freebsd.org Delivered-To: freebsd-doc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A802E16A418 for ; Tue, 13 Jun 2006 02:49:43 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB4D343D67 for ; Tue, 13 Jun 2006 02:49:38 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by ug-out-1314.google.com with SMTP id m3so2426651uge for ; Mon, 12 Jun 2006 19:49:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KYNGAszZTRrtv56FMekpbMm5sPW+we/lS0csnh8hCu/nnzWMywPLxKTgJmhbC/y7ZNpJzZykdRqUJXVb4LjOZSXF7tHPS2GVtG12A7RtsY84CndIpTO/8tIdo+wMiwCOzZaOBRK+dAWGzp5ivE9iKcnsjsfrEbGSjDYZfG2qWnM= Received: by 10.78.123.4 with SMTP id v4mr133796huc; Mon, 12 Jun 2006 18:47:37 -0700 (PDT) Received: by 10.78.50.15 with HTTP; Mon, 12 Jun 2006 18:47:37 -0700 (PDT) Message-ID: <84dead720606121847u2c4e9c51ge9e8793c0d8ea24e@mail.gmail.com> Date: Tue, 13 Jun 2006 07:17:37 +0530 From: "Joseph Koshy" To: "Rich Morin" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-doc@freebsd.org Subject: Re: mandoc question X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 02:49:43 -0000 On 6/13/06, Rich Morin wrote: > Assuming that I have a function argument n and want to say > something like: > > The n'th character is ignored. > > How do I use the .Fa macro (or whatever) to do this. My > current code is > > The > .Fa n'th > character is ignored. > > but that highlights all of "n'th". I've tried a couple of > other possibilities (along with RTFM), but no luck so far. > > Help? Try the .Ap macro: The .Fa n Ap th character is ignored. -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-doc@FreeBSD.ORG Tue Jun 13 07:19:46 2006 Return-Path: X-Original-To: doc@freebsd.org Delivered-To: freebsd-doc@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B686616A41A for ; Tue, 13 Jun 2006 07:19:46 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64E9543D45 for ; Tue, 13 Jun 2006 07:19:46 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id D519C170DF for ; Tue, 13 Jun 2006 07:19:44 +0000 (UTC) To: doc@freebsd.org From: Poul-Henning Kamp Date: Tue, 13 Jun 2006 07:19:44 +0000 Message-ID: <51619.1150183184@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Subject: Hardware notes: token ring, fddi and atm interfaces X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 07:19:46 -0000 I just noticed that the hardware notes contain three empty sections for TR, FDDI and ATM interfaces: http://localhost:8080/releases/6.1R/hardware-amd64.html#FDDI Is this intentional/optimal/old cruft ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-doc@FreeBSD.ORG Tue Jun 13 17:09:48 2006 Return-Path: X-Original-To: doc@freebsd.org Delivered-To: freebsd-doc@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E189416A47B for ; Tue, 13 Jun 2006 17:09:48 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27EC543D5E for ; Tue, 13 Jun 2006 17:09:46 +0000 (GMT) (envelope-from bmah@freebsd.org) Received: from [192.168.40.183] (64-84-9-2-sf-gw.ncircle.com [64.84.9.2]) (authenticated bits=0) by a.mail.sonic.net (8.13.6/8.13.3) with ESMTP id k5DH9jh1004951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jun 2006 10:09:46 -0700 Message-ID: <448EF159.1020008@freebsd.org> Date: Tue, 13 Jun 2006 10:09:45 -0700 From: "Bruce A. Mah" User-Agent: Thunderbird 1.5.0.4 (X11/20060606) MIME-Version: 1.0 To: Poul-Henning Kamp References: <51619.1150183184@critter.freebsd.dk> In-Reply-To: <51619.1150183184@critter.freebsd.dk> X-Enigmail-Version: 0.94.0.0 OpenPGP: id=5ba052c3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4B01AB601F0A57F58CA358F1" Cc: doc@freebsd.org Subject: Re: Hardware notes: token ring, fddi and atm interfaces X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 17:09:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4B01AB601F0A57F58CA358F1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If memory serves me right, Poul-Henning Kamp wrote: > I just noticed that the hardware notes contain three empty sections > for TR, FDDI and ATM interfaces: >=20 > http://localhost:8080/releases/6.1R/hardware-amd64.html#FDDI >=20 > Is this intentional/optimal/old cruft ? Some combination of the first and the last. It's an artifact of the (stupid) way that I tried to generate separate hardware note documents for each architecture. When I first did this work, we only supported i386 and alpha, but the way we do conditional inclusion of text just doesn't scale very well to the number of architectures we have. I am leaning towards the idea that the right way to do this now is to have unified, mostly-MI release documentation (i.e. release notes, hardware notes, installation guide) annotated appropriately in the places that need to be MD. Bruce. --------------enig4B01AB601F0A57F58CA358F1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEjvFZ2MoxcVugUsMRAgcgAKCCsk6LkUbOLC7JsiaAwADNwkuS+gCgjlgC esBiEGLzVhfFQfMnGUIFaF8= =KBRY -----END PGP SIGNATURE----- --------------enig4B01AB601F0A57F58CA358F1-- From owner-freebsd-doc@FreeBSD.ORG Tue Jun 13 19:04:51 2006 Return-Path: X-Original-To: doc@freebsd.org Delivered-To: freebsd-doc@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F69516A47B for ; Tue, 13 Jun 2006 19:04:51 +0000 (UTC) (envelope-from sms.gateway@saude.gov.br) Received: from DTR2007.saude.gov.br (trtymx.saude.gov.br [200.214.130.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id C42A543D46 for ; Tue, 13 Jun 2006 19:04:47 +0000 (GMT) (envelope-from sms.gateway@saude.gov.br) Received: from localhost (unknown [127.0.0.1]) by DTR2007.saude.gov.br (Symantec Mail Security) with ESMTP id 079243B8230 for ; Tue, 13 Jun 2006 15:43:56 -0300 (BRT) From: sms.gateway@saude.gov.br To: doc@freebsd.org Date: Tue, 13 Jun 2006 16:01:52 -0300 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Message-Id: <20060613184355.E2A78444015@DTR2007.saude.gov.br> X-Brightmail-Tracker: AAAAAA== Cc: Subject: =?utf-8?q?E-Mail_bloqueado_por_seguran=C3=A7a?= X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 19:04:51 -0000 SMSGateway A Política de Proteção contra Vírus e Spam´s do Ministério da Saúde bloqueou e substituiu este e-mail. Foram detectadas as seguintes violações: Connection From: 200.214.130.50 From: doc@freebsd.org To: jozi.machado@saude.gov.br Date: Tue, 13 Jun 2006 16:01:51 -0300 Subject: pescaria por kilo --- Scan information follows --- Virus Name: W32.Netsky.AD@mm File Attachment: circular.zip Attachment Status: deleted --- File name Block information follows --- File Attachment: circular.zip Matching file name: Message is considered to be a mass-mailer. The message was dropped. From owner-freebsd-doc@FreeBSD.ORG Tue Jun 13 22:33:09 2006 Return-Path: X-Original-To: freebsd-doc@freebsd.org Delivered-To: freebsd-doc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B585D16A47C for ; Tue, 13 Jun 2006 22:33:09 +0000 (UTC) (envelope-from simon@zaphod.nitro.dk) Received: from mx.nitro.dk (zarniwoop.nitro.dk [83.92.207.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39D0043D49 for ; Tue, 13 Jun 2006 22:33:08 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: from zaphod.nitro.dk (unknown [192.168.3.18]) by mx.nitro.dk (Postfix) with ESMTP id B2C0D2D48BA for ; Tue, 13 Jun 2006 22:33:07 +0000 (UTC) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id 991F611420; Wed, 14 Jun 2006 00:33:07 +0200 (CEST) Date: Wed, 14 Jun 2006 00:33:07 +0200 From: "Simon L. Nielsen" To: freebsd-doc@freebsd.org Message-ID: <20060613223307.GB1074@zaphod.nitro.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="St7VIuEGZ6dlpu13" Content-Disposition: inline User-Agent: Mutt/1.5.11 Subject: Split and cleanup of Porters Handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 22:33:09 -0000 --St7VIuEGZ6dlpu13 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey, For quite a while the Porters Handbook book.sgml has just been growing and has for a while been way to big for comfort (at least to me), and there has been talk on several occasions on splitting it. book.sgml is currently over 10000 lines long and 354KB. Other than that, a big part of the indentation is wrong, which is a pain at least for Emacs users since it partly breaks automatic indentation. So, I would like to split book.sgml into chapter files like we have for the FreeBSD Handbook and fix/style the indentation is the process. Currently the book.sgml,v file is 1.5MB which means that if we have to repo-copy it for each of the 14 chapters that will result in 21MB extra repository space, and due to style fixes "cvs annotate" still won't be able to show the history right anyaway. Yes, 21MB isn't much on today's disks, but if it doesn't buy you anything I don't reallly see a reason to get the extra repo space. Therefor I suggest simply creating new files for each chapter without repo-copy. The last pre-split version of book.sgml will still be in the repository so you can run cvs annotate on that for history. So, are there strong objections to doing this, and/or do anyone have better ideas for handling this? --=20 Simon L. Nielsen --St7VIuEGZ6dlpu13 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEjz0jh9pcDSc1mlERAurPAJwPjQYihyojJ08u+3VRIt5izuyQrgCfeYEb Y62rDoNrEBqNilzQ9VMnqpo= =S2Hk -----END PGP SIGNATURE----- --St7VIuEGZ6dlpu13-- From owner-freebsd-doc@FreeBSD.ORG Wed Jun 14 02:12:44 2006 Return-Path: X-Original-To: freebsd-doc@FreeBSD.org Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0248D16A474 for ; Wed, 14 Jun 2006 02:12:44 +0000 (UTC) (envelope-from www@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D91C43D69 for ; Wed, 14 Jun 2006 02:12:43 +0000 (GMT) (envelope-from www@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k5E2ChjZ024511 for ; Wed, 14 Jun 2006 02:12:43 GMT (envelope-from www@www.freebsd.org) Received: (from www@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id k5E2Cho4024510 for freebsd-doc@FreeBSD.org; Wed, 14 Jun 2006 02:12:43 GMT (envelope-from www) Date: Wed, 14 Jun 2006 02:12:43 GMT From: World Wide Web Owner Message-Id: <200606140212.k5E2Cho4024510@www.freebsd.org> To: freebsd-doc@FreeBSD.org Cc: Subject: FreeBSD web build failed on www.freebsd.org X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 02:12:44 -0000 ===> ../es/releases/3.0R ===> ../es/releases/3.1R ===> ../es/releases/3.2R ===> ../es/releases/3.3R ===> ../es/releases/3.4R ===> ../es/releases/3.5R ===> ../es/releases/4.0R ===> ../es/releases/4.1R ===> ../es/releases/4.1.1R ===> ../es/releases/4.2R ===> ../es/releases/4.3R ===> ../es/gnome env SGML_CATALOG_FILES= XML_CATALOG_FILES="file:///w/www/build/doc/es_ES.ISO8859-1/share/sgml/catalog.xml file:///w/www/build/doc/share/sgml/catalog.xml file:///w/www/build/doc/share/sgml/catalog-common.xml file:///w/www/build/www/es/share/sgml/catalog.xml file:///w/www/build/www/share/sgml/catalog-common.xml file:///usr/local/share/xml/catalog" /usr/local/bin/xsltproc --xinclude --stringparam LOCALBASE /usr/local --stringparam WEB_PREFIX /w/www/build/www --nonet --catalogs -o index.html /w/www/build/www/es/gnome/index.xsl /w/www/build/www/es/gnome/news.xml I/O error : Attempt to load network entity http://gnomedesktop.org/backend.php warning: failed to load external entity "http://gnomedesktop.org/backend.php" I/O error : Attempt to load network entity http://gnomedesktop.org/backend.php warning: failed to load external entity "http://gnomedesktop.org/backend.php" /usr/local/bin/tidy -wrap 90 -m -raw -preserve -f /dev/null -asxml index.html ===> ../es/gnome/docs *** Error code 1 (ignored) ===> ../es/ports (cd /w/www/build/www/es/ports && make -f /w/www/build/www/es/ports/Makefile.inc0 all) ===> ../es/doc ===> ../es/doc/articles ===> ../es/doc/articles/casestudy-argentina.com /bin/rm -f docbook.css /bin/cat /w/www/build/doc/share/misc/docbook.css > docbook.css Index is disabled or no index to generate. /usr/bin/env /usr/local/bin/jade -V html-manifest -ioutput.html -d /w/www/build/doc/share/sgml/default.dsl -ifreebsd.urls.relprefix.4 -V %generate-legalnotice-link% -V %generate-article-toc% -V %generate-docformat-navi-link% -ioutput.html.images -D /w/www/build/doc/es_ES.ISO8859-1/articles/casestudy-argentina.com/../../../share/images/articles/casestudy-argentina.com -D /usr/obj/w/www/build/doc/es_ES.ISO8859-1/articles/casestudy-argentina.com -c /w/www/build/doc/es_ES.ISO8859-1/share/sgml/catalog -c /w/www/build/doc/share/sgml/catalog -c /usr/local/share/sgml/docbook/dsssl/modular/catalog -c /usr/local/share/sgml/iso8879/catalog -c /usr/local/share/sgml/jade/catalog -c /usr/local/share/sgml/catalog.ports -t sgml /w/www/build/doc/es_ES.ISO8859-1/articles/casestudy-argentina.com/article.sgml /usr/local/bin/jade:/w/www/build/doc/es_ES.ISO8859-1/articles/casestudy-argentina.com/article.sgml:1:0:E: character "$" not allowed in prolog *** Error code 1 Stop in /w/www/build/doc/es_ES.ISO8859-1/articles/casestudy-argentina.com. *** Error code 1 Stop in /w/www/build/doc/es_ES.ISO8859-1/articles. *** Error code 1 Stop in /w/www/build/doc/es_ES.ISO8859-1. *** Error code 1 Stop in /w/www/build/www/es/doc. *** Error code 1 (ignored) *** Error code 1 Stop in /w/www/build/www/es. *** Error code 1 Stop in /w/www/build/www/en. 2917.47 real 1531.48 user 246.04 sys From owner-freebsd-doc@FreeBSD.ORG Wed Jun 14 07:33:08 2006 Return-Path: X-Original-To: freebsd-doc@FreeBSD.org Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 41CFD16A474; Wed, 14 Jun 2006 07:33:08 +0000 (UTC) (envelope-from pav@FreeBSD.org) Received: from e0-a11.b1.lan.prg.vol.cz (e0-a11.b1.lan.prg.vol.cz [195.122.204.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id 442B043D46; Wed, 14 Jun 2006 07:33:07 +0000 (GMT) (envelope-from pav@FreeBSD.org) Received: from pav.hide.vol.cz (localhost [127.0.0.1]) by e0-a11.b1.lan.prg.vol.cz (8.13.6/8.13.6) with ESMTP id k5E7X418005317; Wed, 14 Jun 2006 09:33:04 +0200 (CEST) (envelope-from pav@FreeBSD.org) Received: (from pav@localhost) by pav.hide.vol.cz (8.13.6/8.13.6/Submit) id k5E7X4JM005316; Wed, 14 Jun 2006 09:33:04 +0200 (CEST) (envelope-from pav@FreeBSD.org) X-Authentication-Warning: pav.hide.vol.cz: pav set sender to pav@FreeBSD.org using -f From: Pav Lucistnik To: "Simon L. Nielsen" In-Reply-To: <20060613223307.GB1074@zaphod.nitro.dk> References: <20060613223307.GB1074@zaphod.nitro.dk> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-5DJC5wLLnyWZ9F28l6Ar" Date: Wed, 14 Jun 2006 09:33:04 +0200 Message-Id: <1150270384.5111.4.camel@pav.hide.vol.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 FreeBSD GNOME Team Port Cc: freebsd-doc@FreeBSD.org Subject: Re: Split and cleanup of Porters Handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pav@FreeBSD.org List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 07:33:08 -0000 --=-5DJC5wLLnyWZ9F28l6Ar Content-Type: text/plain; charset=ISO8859-2 Content-Transfer-Encoding: quoted-printable Simon L. Nielsen p=ED=B9e v st 14. 06. 2006 v 00:33 +0200: > So, are there strong objections to doing this, and/or do anyone have > better ideas for handling this? I suggested this a year ago :) Mark Linimon wants to do a major reorganization of PH, IIRC, so do ask him beforehand. --=20 Pav Lucistnik In fact, the GAH is a very powerful and secretive organization whose single weakness is its lack of existance. - rec.games.roguelike.angband --=-5DJC5wLLnyWZ9F28l6Ar Content-Type: application/pgp-signature; name=signature.asc Content-Description: Toto je =?UTF-8?Q?digit=C3=A1ln=C4=9B?= =?ISO-8859-1?Q?_podepsan=E1?= =?UTF-8?Q?_=C4=8D=C3=A1st?= =?ISO-8859-1?Q?_zpr=E1vy?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQBEj7uwntdYP8FOsoIRAj+TAJ9ReSpR8ZrHe4rTFKWT+r7Vcq2DHgCeNHNG SjS/e7Ogyu/a2FNSHFoKvwg= =ZlK9 -----END PGP SIGNATURE----- --=-5DJC5wLLnyWZ9F28l6Ar-- From owner-freebsd-doc@FreeBSD.ORG Wed Jun 14 07:42:31 2006 Return-Path: X-Original-To: freebsd-doc@freebsd.org Delivered-To: freebsd-doc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C637416A41B; Wed, 14 Jun 2006 07:42:31 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EF4943D45; Wed, 14 Jun 2006 07:42:31 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 059022EE2; Wed, 14 Jun 2006 02:42:30 -0500 (CDT) Date: Wed, 14 Jun 2006 02:42:30 -0500 To: "Simon L. Nielsen" Message-ID: <20060614074230.GA1221@soaustin.net> References: <20060613223307.GB1074@zaphod.nitro.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060613223307.GB1074@zaphod.nitro.dk> User-Agent: Mutt/1.5.9i From: linimon@lonesome.com (Mark Linimon) Cc: freebsd-doc@freebsd.org Subject: Re: Split and cleanup of Porters Handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 07:42:31 -0000 I'm quite concerned that it will be more difficult to figure out when new text was introduced, or old text was changed. There have been several times in the past that I have tried to find out "why is XYZ being done, is that just something from the old days? When was it introduced?" and have been unable to, due to the fact that years ago there was some kind of repocopy and split (off from the Handbook, perhaps?) and it's so obscure that it's just not possible to track it all down. I have had some ideas in the past on how to reorg the handbook in terms of "policies (which will be enforced) vs. best practices (which is what portmgr recommends", and further split the thing up into a Ports Users' Guide vs. what really ought to be in the "Porter's Handbook", but I have been far enough away from doc work for a while that I think I have to admit I won't get around to this anytime in the next month or two. mcl From owner-freebsd-doc@FreeBSD.ORG Wed Jun 14 11:40:19 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5318716A47C for ; Wed, 14 Jun 2006 11:40:19 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B73443D6E for ; Wed, 14 Jun 2006 11:40:17 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k5EBeH19007407 for ; Wed, 14 Jun 2006 11:40:17 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k5EBeHM1007406; Wed, 14 Jun 2006 11:40:17 GMT (envelope-from gnats) Resent-Date: Wed, 14 Jun 2006 11:40:17 GMT Resent-Message-Id: <200606141140.k5EBeHM1007406@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Yavor Christov Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7BD1816A492 for ; Wed, 14 Jun 2006 11:32:24 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48A2C43D8F for ; Wed, 14 Jun 2006 11:32:18 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k5EBWIBX090882 for ; Wed, 14 Jun 2006 11:32:18 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id k5EBWIXx090881; Wed, 14 Jun 2006 11:32:18 GMT (envelope-from nobody) Message-Id: <200606141132.k5EBWIXx090881@www.freebsd.org> Date: Wed, 14 Jun 2006 11:32:18 GMT From: Yavor Christov To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: docs/98941: Partitioning resize - only commercial product available for NTFS X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 11:40:19 -0000 >Number: 98941 >Category: docs >Synopsis: Partitioning resize - only commercial product available for NTFS >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 Jun 14 11:40:16 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Yavor Christov >Release: 6.1 >Organization: >Environment: FreeBSD 6.1-RELEASE #0: Sun May 7 04:42:56 UTC 2006 root@opus.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP i386 >Description: In FreeBSD Handbook it is written (under chapter 2.2.3.1 Disk Layouts for the i386™): You can use a commercial tool such as PartitionMagic® to resize your partitions to make space for FreeBSD. The tools directory on the CDROM contains two free software tools which can carry out this task, namely FIPS and PResizer. Documentation for both of these is available in the same directory. FIPS, PResizer, and PartitionMagic can resize FAT16 and FAT32 partitions -- used in MS-DOS® through Windows ME. PartitionMagic is the only one of the above applications that can resize NTFS partitions. However, I personally have used GParted not once to resize NTFS partitions and not only that it does that but it is also a free solution to the above mentioned problem. It can be downloaded from http://gparted.sourceforge.net/ and beside NTFS partitions it handles perfectly bunch of other stuff. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-doc@FreeBSD.ORG Wed Jun 14 14:50:19 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CCAB16A47D for ; Wed, 14 Jun 2006 14:50:19 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42AE743D5A for ; Wed, 14 Jun 2006 14:50:17 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k5EEoG9G020433 for ; Wed, 14 Jun 2006 14:50:16 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k5EEoGsq020432; Wed, 14 Jun 2006 14:50:16 GMT (envelope-from gnats) Date: Wed, 14 Jun 2006 14:50:16 GMT Message-Id: <200606141450.k5EEoGsq020432@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Christian Brueffer Cc: Subject: Re: docs/98801: gmirror(8) and glabel(8) manpages should mention geom_{mirror, label}_load X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christian Brueffer List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 14:50:19 -0000 The following reply was made to PR docs/98801; it has been noted by GNATS. From: Christian Brueffer To: Peter Schuller , FreeBSD-gnats-submit@freebsd.org Cc: Subject: Re: docs/98801: gmirror(8) and glabel(8) manpages should mention geom_{mirror, label}_load Date: Wed, 14 Jun 2006 16:43:12 +0200 --TakKZr9L6Hm6aLOc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 11, 2006 at 03:11:14PM +0200, Peter Schuller wrote: > > These are not sysctl variables, but loader instructions.=20 >=20 > I was not sure about the nomenclature. I ended up doing what I did based = on=20 > gstripe(8), which lists loader variables under sysctl variables, but with= a=20 > note saying they cannot be changed after boot (though I realize I forgot = to=20 > do the latter). >=20 > > Also IMHO they=20 > > don't really belong in section 8 manpages. Instead short section 4 > > manpages for each geom module should be written (some of the information > > in the section 8 manpages should probably be moved there then). >=20 > On the other hand it is very relevant to anyone reading gmirror(8) or=20 > glabel(8). At the very least it seems adding it to (8) is better than=20 > leaving it as-is, not documented at all. >=20 > I can propose new section 4 manpages, but I am not sure how much from the= ir=20 > corresponding section 8 manpages really belong there. Would you feel a=20 > separate manpage is warranted even if it essentially only contains the=20 > relevant loader instructions? >=20 > While there is some information in gmirror(8)/gmirror(9) that refer to th= e=20 > workings of the geom class itself, rather than the tool, I don't know how= =20 > much sense it makes to try to strip those pages of that information given= =20 > that it is so directly relevant to operation of the tool. Perhaps the=20 > introductory general information on meta-data layout and general operatio= ns. >=20 IMHO all information about the implementation of the class should go into section 4 manpage as well. "Would it make sense to just put the module information in there if nothing else is available?" IMHO yes, together with one or two lines about what the module does. One of our aims is actually to have a manpage for every kernel driver/option/whatever (or an MLINK to a relevant manpage). > I presume the section for manpages would preferably be named geom_XXX (in= =20 > keeping with geom(4)). >=20 Yes, probably with an MLINK to e.g. gmirror(4). - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --TakKZr9L6Hm6aLOc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEkCCAbHYXjKDtmC0RAiTeAKCYq1kJXUn7BJB896xzk0uCqQOdvgCgl3jI s5hba23A4GZ74EFyinbubWY= =cSA6 -----END PGP SIGNATURE----- --TakKZr9L6Hm6aLOc-- From owner-freebsd-doc@FreeBSD.ORG Wed Jun 14 16:14:12 2006 Return-Path: X-Original-To: freebsd-doc@freebsd.org Delivered-To: freebsd-doc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3339D16A479 for ; Wed, 14 Jun 2006 16:14:12 +0000 (UTC) (envelope-from rdm@cfcl.com) Received: from cfcl.com (cpe-24-221-172-174.ca.sprintbbd.net [24.221.172.174]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECFCB43D5D for ; Wed, 14 Jun 2006 16:14:07 +0000 (GMT) (envelope-from rdm@cfcl.com) Received: from [192.168.254.205] ([192.168.254.205]) by cfcl.com (8.12.6/8.12.6) with ESMTP id k5EGJ4vH095871 for ; Wed, 14 Jun 2006 09:19:08 -0700 (PDT) (envelope-from rdm@cfcl.com) Mime-Version: 1.0 Message-Id: Date: Wed, 14 Jun 2006 09:15:39 -0700 To: freebsd-doc@freebsd.org From: Rich Morin Content-Type: text/plain; charset="us-ascii" Subject: checking man page includes and prototypes? X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 16:14:12 -0000 I'm doing a lot of editing of section 2 and 3 man pages, concentrating on the includes and prototypes. Although I'm trying to be careful, it's quite likely that some errors will slip past me. So, I'm casting about for a way to do an automated sanity check. Here's one idea: For each man page For each prototype Construct a C test file. Compile the test file. Look for nastygrams, etc. For example, the sysconf(3) SYNOPSIS contains the lines: #include long sysconf(int name); I can turn this into the file test.c: #include main() { int name; sysconf(name); } Compiling this (e.g., "cc test.c") finishes silently. So far, so good... Editing "sysconf" into "sysconfx" produces a promising nastygram: /usr/bin/ld: Undefined symbols: _sysconfx collect2: ld returned 1 exit status However, editing "int name;" into "float name;' does NOT cause a nastygram. So, it appears that prototype checking is not being done. The gcc(1) man page gave me the idea of trying gcc -pedantic -ansi test.c but this didn't make any visible difference. I see a bazillion other options, including a bunch of "-W..." goodies, but I'd rather not try them all at random. I tried "gcc -pedantic -ansi -Wstrict-prototypes test.c", but it only complained about my "main" statement (?): test.c:3: warning: function declaration isn't a prototype Any suggestions (general or specific) on how I might be able to cajole gcc (or whatever) into helping me? -r P.S. The "obvious" strategy of inspecting the header file(s) breaks down under closer examination. The declaration may be located in an include file which is referenced indirectly, #defines or #ifdefs may be involved, etc. So, for a general, automated solution, I'd like to rely on the compiler (etc) to tell me whether the usage is complete and correct. -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development From owner-freebsd-doc@FreeBSD.ORG Wed Jun 14 16:18:05 2006 Return-Path: X-Original-To: freebsd-doc@freebsd.org Delivered-To: freebsd-doc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31C7E16A9AC; Wed, 14 Jun 2006 16:18:05 +0000 (UTC) (envelope-from remko@freebsd.org) Received: from caelis.elvandar.org (caelis.elvandar.org [217.148.169.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id B84BF43D49; Wed, 14 Jun 2006 16:18:04 +0000 (GMT) (envelope-from remko@freebsd.org) Received: from localhost (caelis.elvandar.org [217.148.169.59]) by caelis.elvandar.org (Postfix) with ESMTP id 9AD1292FD5E; Wed, 14 Jun 2006 18:18:03 +0200 (CEST) Received: from caelis.elvandar.org ([217.148.169.59]) by localhost (caelis.elvandar.org [217.148.169.59]) (amavisd-new, port 10024) with ESMTP id 14665-03; Wed, 14 Jun 2006 18:18:03 +0200 (CEST) Received: from [192.168.1.65] (a82-93-208-228.adsl.xs4all.nl [82.93.208.228]) by caelis.elvandar.org (Postfix) with ESMTP id 42AE392FC46; Wed, 14 Jun 2006 18:18:03 +0200 (CEST) Message-ID: <449036BA.2030803@FreeBSD.org> Date: Wed, 14 Jun 2006 18:18:02 +0200 From: Remko Lodder User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: "Simon L. Nielsen" References: <20060613223307.GB1074@zaphod.nitro.dk> In-Reply-To: <20060613223307.GB1074@zaphod.nitro.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by the elvandar.org maildomain Cc: freebsd-doc@freebsd.org Subject: Re: Split and cleanup of Porters Handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: remko@FreeBSD.org List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 16:18:05 -0000 Simon L. Nielsen wrote: > Hey, > > For quite a while the Porters Handbook book.sgml has just been growing > and has for a while been way to big for comfort (at least to me), and > there has been talk on several occasions on splitting it. book.sgml > is currently over 10000 lines long and 354KB. Other than that, a big > part of the indentation is wrong, which is a pain at least for Emacs > users since it partly breaks automatic indentation. > > So, I would like to split book.sgml into chapter files like we have > for the FreeBSD Handbook and fix/style the indentation is the process. > > Currently the book.sgml,v file is 1.5MB which means that if we have to > repo-copy it for each of the 14 chapters that will result in 21MB > extra repository space, and due to style fixes "cvs annotate" still > won't be able to show the history right anyaway. Yes, 21MB isn't much > on today's disks, but if it doesn't buy you anything I don't reallly > see a reason to get the extra repo space. > > Therefor I suggest simply creating new files for each chapter without > repo-copy. The last pre-split version of book.sgml will still be in > the repository so you can run cvs annotate on that for history. > > So, are there strong objections to doing this, and/or do anyone have > better ideas for handling this? > No better ideas, go for it! -- Kind regards, Remko Lodder ** remko@elvandar.org FreeBSD ** remko@FreeBSD.org /* Quis custodiet ipsos custodes */ From owner-freebsd-doc@FreeBSD.ORG Wed Jun 14 16:48:11 2006 Return-Path: X-Original-To: freebsd-doc@FreeBSD.org Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F2F4016A47B; Wed, 14 Jun 2006 16:48:10 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from pittgoth.com (ns1.pittgoth.com [216.38.206.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F59B43E8C; Wed, 14 Jun 2006 16:44:41 +0000 (GMT) (envelope-from trhodes@FreeBSD.org) Received: from mobile.pittgoth.com (ip70-177-190-239.dc.dc.cox.net [70.177.190.239]) (authenticated bits=0) by pittgoth.com (8.13.4/8.13.4) with ESMTP id k5EGkulr098161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Jun 2006 12:46:57 -0400 (EDT) (envelope-from trhodes@FreeBSD.org) Date: Wed, 14 Jun 2006 12:43:54 -0400 From: Tom Rhodes To: linimon@lonesome.com (Mark Linimon) Message-Id: <20060614124354.4a45d91b.trhodes@FreeBSD.org> In-Reply-To: <20060614074230.GA1221@soaustin.net> References: <20060613223307.GB1074@zaphod.nitro.dk> <20060614074230.GA1221@soaustin.net> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-doc@FreeBSD.org, simon@FreeBSD.org Subject: Re: Split and cleanup of Porters Handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 16:48:11 -0000 On Wed, 14 Jun 2006 02:42:30 -0500 linimon@lonesome.com (Mark Linimon) wrote: > I'm quite concerned that it will be more difficult to figure out when new > text was introduced, or old text was changed. There have been several > times in the past that I have tried to find out "why is XYZ being done, is > that just something from the old days? When was it introduced?" and have > been unable to, due to the fact that years ago there was some kind of > repocopy and split (off from the Handbook, perhaps?) and it's so obscure > that it's just not possible to track it all down. > > I have had some ideas in the past on how to reorg the handbook in terms > of "policies (which will be enforced) vs. best practices (which is what > portmgr recommends", and further split the thing up into a Ports Users' > Guide vs. what really ought to be in the "Porter's Handbook", but I have > been far enough away from doc work for a while that I think I have to admit > I won't get around to this anytime in the next month or two. > Well, 20+ megabytes of space isn't much. And storage space is nice and cheap these days. -- Tom Rhodes From owner-freebsd-doc@FreeBSD.ORG Wed Jun 14 16:59:56 2006 Return-Path: X-Original-To: freebsd-doc@FreeBSD.org Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B062F16A41A for ; Wed, 14 Jun 2006 16:59:56 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from pittgoth.com (ns1.pittgoth.com [216.38.206.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D2C743D7D for ; Wed, 14 Jun 2006 16:59:55 +0000 (GMT) (envelope-from trhodes@FreeBSD.org) Received: from mobile.pittgoth.com (ip70-177-190-239.dc.dc.cox.net [70.177.190.239]) (authenticated bits=0) by pittgoth.com (8.13.4/8.13.4) with ESMTP id k5EH2kYM099371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Jun 2006 13:02:47 -0400 (EDT) (envelope-from trhodes@FreeBSD.org) Date: Wed, 14 Jun 2006 12:59:45 -0400 From: Tom Rhodes To: Rich Morin Message-Id: <20060614125945.292e5329.trhodes@FreeBSD.org> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-doc@FreeBSD.org Subject: Re: checking man page includes and prototypes? X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 16:59:56 -0000 On Wed, 14 Jun 2006 09:15:39 -0700 Rich Morin wrote: > I'm doing a lot of editing of section 2 and 3 man pages, > concentrating on the includes and prototypes. Although > I'm trying to be careful, it's quite likely that some > errors will slip past me. So, I'm casting about for a > way to do an automated sanity check. Here's one idea: > > For each man page > For each prototype > Construct a C test file. > Compile the test file. > Look for nastygrams, etc. > > For example, the sysconf(3) SYNOPSIS contains the lines: > > #include > > long > sysconf(int name); > > I can turn this into the file test.c: > > #include > > main() { > > int name; > sysconf(name); > } > > Compiling this (e.g., "cc test.c") finishes silently. > So far, so good... > > > Editing "sysconf" into "sysconfx" produces a promising > nastygram: > > /usr/bin/ld: Undefined symbols: > _sysconfx > collect2: ld returned 1 exit status > > > However, editing "int name;" into "float name;' does > NOT cause a nastygram. So, it appears that prototype > checking is not being done. The gcc(1) man page gave > me the idea of trying > > gcc -pedantic -ansi test.c > > but this didn't make any visible difference. I see a > bazillion other options, including a bunch of "-W..." > goodies, but I'd rather not try them all at random. I > tried "gcc -pedantic -ansi -Wstrict-prototypes test.c", > but it only complained about my "main" statement (?): > > test.c:3: warning: function declaration isn't a prototype > > > Any suggestions (general or specific) on how I might be > able to cajole gcc (or whatever) into helping me? > > -r > > P.S. The "obvious" strategy of inspecting the header file(s) > breaks down under closer examination. The declaration > may be located in an include file which is referenced > indirectly, #defines or #ifdefs may be involved, etc. > > So, for a general, automated solution, I'd like to rely > on the compiler (etc) to tell me whether the usage is > complete and correct. Have you tried using cc with -Wall? Lemmie sleep some and I might come up with something else. -- Tom Rhodes From owner-freebsd-doc@FreeBSD.ORG Wed Jun 14 17:14:18 2006 Return-Path: X-Original-To: freebsd-doc@FreeBSD.org Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF1CC16A47B for ; Wed, 14 Jun 2006 17:14:18 +0000 (UTC) (envelope-from rdm@cfcl.com) Received: from cfcl.com (cpe-24-221-172-174.ca.sprintbbd.net [24.221.172.174]) by mx1.FreeBSD.org (Postfix) with ESMTP id 494D843D5E for ; Wed, 14 Jun 2006 17:14:18 +0000 (GMT) (envelope-from rdm@cfcl.com) Received: from [192.168.254.205] ([192.168.254.205]) by cfcl.com (8.12.6/8.12.6) with ESMTP id k5EHJIvF025364 for ; Wed, 14 Jun 2006 10:19:19 -0700 (PDT) (envelope-from rdm@cfcl.com) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060614125945.292e5329.trhodes@FreeBSD.org> References: <20060614125945.292e5329.trhodes@FreeBSD.org> Date: Wed, 14 Jun 2006 10:09:40 -0700 To: freebsd-doc@FreeBSD.org From: Rich Morin Content-Type: text/plain; charset="us-ascii" Cc: Subject: Re: checking man page includes and prototypes? X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 17:14:18 -0000 At 12:59 PM -0400 6/14/06, Tom Rhodes wrote: > Have you tried using cc with -Wall? This adds some interesting diagnostics, but none that seem particularly useful. -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development From owner-freebsd-doc@FreeBSD.ORG Thu Jun 15 08:50:17 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B971016A47A for ; Thu, 15 Jun 2006 08:50:17 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25CB043D49 for ; Thu, 15 Jun 2006 08:50:17 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k5F8oGZi090234 for ; Thu, 15 Jun 2006 08:50:17 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k5F8oG8Z090228; Thu, 15 Jun 2006 08:50:16 GMT (envelope-from gnats) Resent-Date: Thu, 15 Jun 2006 08:50:16 GMT Resent-Message-Id: <200606150850.k5F8oG8Z090228@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Jelte Jansen Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5F3D16A474 for ; Thu, 15 Jun 2006 08:41:41 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 448D743D46 for ; Thu, 15 Jun 2006 08:41:41 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k5F8fetH007575 for ; Thu, 15 Jun 2006 08:41:40 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id k5F8feg2007574; Thu, 15 Jun 2006 08:41:40 GMT (envelope-from nobody) Message-Id: <200606150841.k5F8feg2007574@www.freebsd.org> Date: Thu, 15 Jun 2006 08:41:40 GMT From: Jelte Jansen To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Cc: Subject: docs/98974: Missing tunables in loader(8) manpage X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 08:50:17 -0000 >Number: 98974 >Category: docs >Synopsis: Missing tunables in loader(8) manpage >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: Thu Jun 15 08:50:16 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Jelte Jansen >Release: 6.* >Organization: NLnet Labs >Environment: FreeBSD alpha.nlnetlabs.nl 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Thu Nov 3 09:36:13 UTC 2005 root@x64.samsco.home:/usr/obj/usr/src/sys/GENERIC i386 >Description: Some tunables (at least kern.maxdsiz, to set the maximum allowed datasize for processes which defaults to 512 mb) are not documented in any manual page i could find. These would probably go in loader(8). The only place i found where it is even mentioned is /boot/defaults/loader.conf, but the information there is too sparse to know what values to use and what it's for. >How-To-Repeat: man loader (no mention here) grep maxdsiz /usr/src/sys/kern/subr_param.c (is is a tunable) >Fix: Add text to the manpage, i propose something like: kern.maxdsiz Set the maximum allowed datasize resource limit for processes. This value defaults to 512 megabytes. The value should be entered in number of bytes, without modifiers. The value may not exceed addressable space. But someone else can probably do a better job, i'm not sure if the no modifiers is still necessary. There are probably other tunables that are not mentioned yet. >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-doc@FreeBSD.ORG Thu Jun 15 09:38:04 2006 Return-Path: X-Original-To: freebsd-doc@FreeBSD.org Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EAB9416A47C for ; Thu, 15 Jun 2006 09:38:04 +0000 (UTC) (envelope-from lutz.wendland@uni-ulm.de) Received: from mail.uni-ulm.de (mail.uni-ulm.de [134.60.1.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4967843D48 for ; Thu, 15 Jun 2006 09:38:03 +0000 (GMT) (envelope-from lutz.wendland@uni-ulm.de) Received: from [192.168.1.2] (dslb-084-056-134-151.pools.arcor-ip.net [84.56.134.151]) (authenticated bits=0) by mail.uni-ulm.de (8.13.6/8.13.6) with ESMTP id k5F9c1jR026045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 15 Jun 2006 11:38:02 +0200 (MEST) Message-ID: <44912A73.6060909@uni-ulm.de> Date: Thu, 15 Jun 2006 11:37:55 +0200 From: Lutz Wendland User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: freebsd-doc@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Document not found - http://www.freebsd.org/cgi/source X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 09:38:05 -0000 Hi, I'd like to report a broken link on the FreeBSD Homepage. On the Web-Page "FreeBSD Ports Search FAQ" [1] I tried to follow the link to the source code of the script 'ports.cgi' and received a 'Document not found' [2] error message. I hope to be helpful in reporting this incident. Kind regards Lutz [1] http://www.freebsd.org/cgi/ports.cgi?stype=faq [2] http://www.freebsd.org/cgi/source From owner-freebsd-doc@FreeBSD.ORG Thu Jun 15 10:48:53 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A25D16A503; Thu, 15 Jun 2006 10:48:53 +0000 (UTC) (envelope-from ceri@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5210F43D45; Thu, 15 Jun 2006 10:48:53 +0000 (GMT) (envelope-from ceri@FreeBSD.org) Received: from freefall.freebsd.org (ceri@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k5FAmrTZ096891; Thu, 15 Jun 2006 10:48:53 GMT (envelope-from ceri@freefall.freebsd.org) Received: (from ceri@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k5FAmrdp096887; Thu, 15 Jun 2006 10:48:53 GMT (envelope-from ceri) Date: Thu, 15 Jun 2006 10:48:53 GMT From: Ceri Davies Message-Id: <200606151048.k5FAmrdp096887@freefall.freebsd.org> To: patrickhess@gmx.net, ceri@FreeBSD.org, freebsd-doc@FreeBSD.org Cc: Subject: Re: docs/98406: ethers(5): "ethernet-adress" and "fully-qualified-host-name" in wrong order X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 10:48:53 -0000 Synopsis: ethers(5): "ethernet-adress" and "fully-qualified-host-name" in wrong order State-Changed-From-To: open->closed State-Changed-By: ceri State-Changed-When: Thu Jun 15 10:47:58 UTC 2006 State-Changed-Why: The PR is incorrect. Thanks to the submitter for taking the time to submit the report. http://www.freebsd.org/cgi/query-pr.cgi?pr=98406 From owner-freebsd-doc@FreeBSD.ORG Thu Jun 15 11:00:48 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB4F616A481 for ; Thu, 15 Jun 2006 11:00:48 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDAEB43D6E for ; Thu, 15 Jun 2006 11:00:42 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k5FB0gh9097419 for ; Thu, 15 Jun 2006 11:00:42 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k5FB0gNB097418; Thu, 15 Jun 2006 11:00:42 GMT (envelope-from gnats) Date: Thu, 15 Jun 2006 11:00:42 GMT Message-Id: <200606151100.k5FB0gNB097418@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Ceri Davies Cc: Subject: Re: docs/98842: misc requests for gdbe X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ceri Davies List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 11:00:48 -0000 The following reply was made to PR docs/98842; it has been noted by GNATS. From: Ceri Davies To: Ian Cognito , Cc: Subject: Re: docs/98842: misc requests for gdbe Date: Thu, 15 Jun 2006 11:50:16 +0100 On 12/6/06 05:09, "Ian Cognito" wrote: > > It would be nice if we could specify a file on the filesystem which could be > used in conjunction with the key to provide enough entropy for said pass > phrase, and especially to be able to read it from a pipe (I do not know if > gdbe can do this or not). Alternately it could be used in conjunction with > the standard key mechanisms to create the sector keys, and so a passphrase > alone is insufficient to gain access to plaintext. Either way it's sort of a > cheap way of getting a lot of entropy out of a memorable passphrase, which > tends to be somewhat weak alone (1-2 bits per letter). The geli(8) system has this. Ceri -- That must be wonderful! I don't understand it at all. -- Moliere From owner-freebsd-doc@FreeBSD.ORG Thu Jun 15 11:00:57 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4309A16A482 for ; Thu, 15 Jun 2006 11:00:57 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 152E943D5A for ; Thu, 15 Jun 2006 11:00:50 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k5FB0o9T097450 for ; Thu, 15 Jun 2006 11:00:50 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k5FB0oj1097449; Thu, 15 Jun 2006 11:00:50 GMT (envelope-from gnats) Date: Thu, 15 Jun 2006 11:00:50 GMT Message-Id: <200606151100.k5FB0oj1097449@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Ceri Davies Cc: Subject: Re: docs/98974: Missing tunables in loader(8) manpage X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ceri Davies List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 11:00:57 -0000 The following reply was made to PR docs/98974; it has been noted by GNATS. From: Ceri Davies To: Jelte Jansen , Cc: Tom Rhodes Subject: Re: docs/98974: Missing tunables in loader(8) manpage Date: Thu, 15 Jun 2006 11:52:27 +0100 On 15/6/06 09:41, "Jelte Jansen" wrote: > Some tunables (at least kern.maxdsiz, to set the maximum allowed datasize for > processes which defaults to 512 mb) are not documented in any manual page i > could find. These would probably go in loader(8). The only place i found where > it is even mentioned is /boot/defaults/loader.conf, but the information there > is too sparse to know what values to use and what it's for. Some moons ago, Tom Rhodes was working on a new manpage for tunables. Tom, is this still ongoing (or did it even get committed and I didn't notice)? Ceri From owner-freebsd-doc@FreeBSD.ORG Thu Jun 15 11:10:24 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4D4E16A474 for ; Thu, 15 Jun 2006 11:10:24 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3445343D49 for ; Thu, 15 Jun 2006 11:10:24 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k5FBAOVO097756 for ; Thu, 15 Jun 2006 11:10:24 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k5FBANl2097755; Thu, 15 Jun 2006 11:10:24 GMT (envelope-from gnats) Date: Thu, 15 Jun 2006 11:10:24 GMT Message-Id: <200606151110.k5FBANl2097755@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Tom Rhodes Cc: Subject: Re: docs/98974: Missing tunables in loader(8) manpage X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Rhodes List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 11:10:24 -0000 The following reply was made to PR docs/98974; it has been noted by GNATS. From: Tom Rhodes To: Ceri Davies Cc: jelte@NLnetLabs.nl, freebsd-gnats-submit@FreeBSD.org Subject: Re: docs/98974: Missing tunables in loader(8) manpage Date: Thu, 15 Jun 2006 07:02:35 -0400 On Thu, 15 Jun 2006 11:52:27 +0100 Ceri Davies wrote: > On 15/6/06 09:41, "Jelte Jansen" wrote: > > > Some tunables (at least kern.maxdsiz, to set the maximum allowed datasize for > > processes which defaults to 512 mb) are not documented in any manual page i > > could find. These would probably go in loader(8). The only place i found where > > it is even mentioned is /boot/defaults/loader.conf, but the information there > > is too sparse to know what values to use and what it's for. > > Some moons ago, Tom Rhodes was working on a new manpage for tunables. > > Tom, is this still ongoing (or did it even get committed and I didn't > notice)? And I was really wondering if I should follow up. It appears there is a slight difference between tunables and sysctls. To be honest, I don't see it, but yea. Anyway, I created a simple script to find and document as many as plausible: src/tools/tools/sysdoc If someone can do something better with it, then yay. Eventually I may redo it in C, but I doubt. -- Tom Rhodes From owner-freebsd-doc@FreeBSD.ORG Thu Jun 15 14:37:17 2006 Return-Path: X-Original-To: freebsd-doc@freebsd.org Delivered-To: freebsd-doc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3AE816A479 for ; Thu, 15 Jun 2006 14:37:17 +0000 (UTC) (envelope-from rdm@cfcl.com) Received: from cfcl.com (cpe-24-221-172-174.ca.sprintbbd.net [24.221.172.174]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A91143D49 for ; Thu, 15 Jun 2006 14:37:17 +0000 (GMT) (envelope-from rdm@cfcl.com) Received: from [192.168.254.205] ([192.168.254.205]) by cfcl.com (8.12.6/8.12.6) with ESMTP id k5FEgMvF017645 for ; Thu, 15 Jun 2006 07:42:23 -0700 (PDT) (envelope-from rdm@cfcl.com) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 15 Jun 2006 07:38:52 -0700 To: freebsd-doc@freebsd.org From: Rich Morin Content-Type: text/plain; charset="us-ascii" Subject: Re: checking man page includes and prototypes? X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 14:37:18 -0000 In case anyone is interested, here is the outline of a way to check man page includes and prototypes against the code: For each man page: Save #include information. For each prototype: Construct two C test files. Compile the test files. Look for nastygrams, etc. For example, the sysconf(3) SYNOPSIS contains the lines: #include long sysconf(int name); Here's the first test file: % cat test1.c /* || test1.c - test to see if prototype matches what's included. || || Usage: cc -c test1.c # Silence gives consent. */ #include /* man page include(s) */ long sysconf(int name); /* man page prototype */ Here's the second test file: % cat test2.c /* || test2.c - test to see if include(s) supply a prototype || || Usage: cc -c test2.c # Silence means error. || || Output should be of the form: || || test2.c:9: error: conflicting types for 'sysconf' || /usr/include/unistd.h:462: error: || previous declaration of 'sysconf' was here */ #include /* man page include(s) */ void sysconf(void, void); /* known false prototype */ The testing process will be somewhat iterative, because of oddball cases. Roughly: Generate and test files, reporting only the exceptions. If parsing problems are encountered, either: Tweak the man page to make parsing easier, upgrade the parsing script to handle the issue, or add a "hint" to a control (e.g., YAML) file. If actual inconsistencies are found, either: Fix the man page to match the code, or vice versa. Rinse, repeat until the test script comes up clean. This test suite could (and I believe should) be put into the release cycle, as a sanity check. If anyone wants to pursue the matter, please contact me for details. -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development From owner-freebsd-doc@FreeBSD.ORG Thu Jun 15 16:25:26 2006 Return-Path: X-Original-To: doc@FreeBSD.org Delivered-To: freebsd-doc@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C751B16A49E for ; Thu, 15 Jun 2006 16:25:26 +0000 (UTC) (envelope-from finwepalantir@yahoo.com) Received: from web36712.mail.mud.yahoo.com (web36712.mail.mud.yahoo.com [209.191.85.46]) by mx1.FreeBSD.org (Postfix) with SMTP id 485EE43D48 for ; Thu, 15 Jun 2006 16:25:26 +0000 (GMT) (envelope-from finwepalantir@yahoo.com) Received: (qmail 28491 invoked by uid 60001); 15 Jun 2006 16:25:25 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=icGBqiY1ruDyMwF5II58961EXn6TKsAO+WX5PALl2BP8RPihO1H6XoSOwOHWFkKuYrRgMpvXf0uUyA2+LytixKqysdiyqaTz64YONW+sfZfFeLTpcUsohHUY6gvFZQRZKAkQ5EIwVErict9GuoMrIIDjPzTg44f9qDtYpXmkfA4= ; Message-ID: <20060615162525.28489.qmail@web36712.mail.mud.yahoo.com> Received: from [200.93.221.71] by web36712.mail.mud.yahoo.com via HTTP; Thu, 15 Jun 2006 09:25:25 PDT Date: Thu, 15 Jun 2006 09:25:25 -0700 (PDT) From: "finwepalantir@yahoo.com" To: doc@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Images missing in the handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 16:25:26 -0000 Dear FreeBSD Doc Team, There are some images missing in the "2.5 Allocating Disk Space" chapter. They are missing in the online and offline version. I can not say if there are other missing images 'cause I have not browsed the Handbook through. /install/bsdlabel-ed1.png /install/bsdlabel-ed1.png /install/bsdlabel-auto.png /install/bsdlabel-root1.png /install/bsdlabel-root2.png /install/bsdlabel-fs.png /install/bsdlabel-root3.png /install/bsdlabel-ed2.png Sincerely yours, Nick __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-doc@FreeBSD.ORG Thu Jun 15 18:37:16 2006 Return-Path: X-Original-To: doc@freebsd.org Delivered-To: freebsd-doc@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 149D116A41A for ; Thu, 15 Jun 2006 18:37:16 +0000 (UTC) (envelope-from remko@freebsd.org) Received: from caelis.elvandar.org (caelis.elvandar.org [217.148.169.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59FFC43D6E for ; Thu, 15 Jun 2006 18:37:13 +0000 (GMT) (envelope-from remko@freebsd.org) Received: from localhost (caelis.elvandar.org [217.148.169.59]) by caelis.elvandar.org (Postfix) with ESMTP id 0ACB492FCF4; Thu, 15 Jun 2006 20:37:12 +0200 (CEST) Received: from caelis.elvandar.org ([217.148.169.59]) by localhost (caelis.elvandar.org [217.148.169.59]) (amavisd-new, port 10024) with ESMTP id 89587-03; Thu, 15 Jun 2006 20:37:11 +0200 (CEST) Message-ID: <4491A8DC.9010407@FreeBSD.org> Date: Thu, 15 Jun 2006 20:37:16 +0200 From: Remko Lodder User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "finwepalantir@yahoo.com" References: <20060615162525.28489.qmail@web36712.mail.mud.yahoo.com> In-Reply-To: <20060615162525.28489.qmail@web36712.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by the elvandar.org maildomain Cc: doc@FreeBSD.org Subject: Re: Images missing in the handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 18:37:16 -0000 finwepalantir@yahoo.com wrote: > Dear FreeBSD Doc Team, > > There are some images missing in the "2.5 Allocating Disk Space" chapter. > They are missing in the online and offline version. I can not say if there > are other missing images 'cause I have not browsed the Handbook through. > > > /install/bsdlabel-ed1.png > /install/bsdlabel-ed1.png > /install/bsdlabel-auto.png > /install/bsdlabel-root1.png > /install/bsdlabel-root2.png > /install/bsdlabel-fs.png > /install/bsdlabel-root3.png > /install/bsdlabel-ed2.png > > Sincerely yours, > > Nick > Hi Nick, Thanks for the report! It seems that you are right, i will try to figure out what is going wrong here. Thanks for reporting this to us! Kind regards, Remko From owner-freebsd-doc@FreeBSD.ORG Thu Jun 15 23:24:42 2006 Return-Path: X-Original-To: freebsd-doc@FreeBSD.org Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B98A16A47A for ; Thu, 15 Jun 2006 23:24:42 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from pittgoth.com (ns1.pittgoth.com [216.38.206.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6D2943D5E for ; Thu, 15 Jun 2006 23:24:36 +0000 (GMT) (envelope-from trhodes@FreeBSD.org) Received: from mobile.pittgoth.com (net-ix.gw.ai.net [205.134.160.6] (may be forged)) (authenticated bits=0) by pittgoth.com (8.13.4/8.13.4) with ESMTP id k5FNRvUo088596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 15 Jun 2006 19:27:58 -0400 (EDT) (envelope-from trhodes@FreeBSD.org) Date: Thu, 15 Jun 2006 19:24:28 -0400 From: Tom Rhodes To: freebsd-doc@FreeBSD.org Message-Id: <20060615192428.79254baa.trhodes@FreeBSD.org> In-Reply-To: <4491A8DC.9010407@FreeBSD.org> References: <20060615162525.28489.qmail@web36712.mail.mud.yahoo.com> <4491A8DC.9010407@FreeBSD.org> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: Re: Images missing in the handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 23:24:42 -0000 On Thu, 15 Jun 2006 20:37:16 +0200 Remko Lodder wrote: > finwepalantir@yahoo.com wrote: > > Dear FreeBSD Doc Team, > > > > There are some images missing in the "2.5 Allocating Disk Space" chapter. > > They are missing in the online and offline version. I can not say if there > > are other missing images 'cause I have not browsed the Handbook through. > > > > > > /install/bsdlabel-ed1.png > > /install/bsdlabel-ed1.png > > /install/bsdlabel-auto.png > > /install/bsdlabel-root1.png > > /install/bsdlabel-root2.png > > /install/bsdlabel-fs.png > > /install/bsdlabel-root3.png > > /install/bsdlabel-ed2.png > > > > Sincerely yours, > > > > Nick > > > Hi Nick, > > Thanks for the report! It seems that you are right, i will try to figure > out what is going wrong here. > > Thanks for reporting this to us! Most likely it was a drive by ... you can blame me. :) -- Tom Rhodes From owner-freebsd-doc@FreeBSD.ORG Fri Jun 16 05:50:16 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 548DD16A47D for ; Fri, 16 Jun 2006 05:50:16 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8810043D48 for ; Fri, 16 Jun 2006 05:50:11 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k5G5oBhW069443 for ; Fri, 16 Jun 2006 05:50:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k5G5oBPC069442; Fri, 16 Jun 2006 05:50:11 GMT (envelope-from gnats) Resent-Date: Fri, 16 Jun 2006 05:50:11 GMT Resent-Message-Id: <200606160550.k5G5oBPC069442@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Dennis Olvany Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA9DE16A474 for ; Fri, 16 Jun 2006 05:43:03 +0000 (UTC) (envelope-from dennisolvany@postfix.deadghost.com) Received: from postfix.deadghost.com (deadghost.com [67.102.60.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 320D743D48 for ; Fri, 16 Jun 2006 05:42:59 +0000 (GMT) (envelope-from dennisolvany@postfix.deadghost.com) Received: from postfix.deadghost.com (localhost [127.0.0.1]) by postfix.deadghost.com (Postfix) with ESMTP id 5AD9760EF for ; Fri, 16 Jun 2006 00:42:58 -0500 (CDT) Received: (from dennisolvany@localhost) by postfix.deadghost.com (8.13.3/8.13.3/Submit) id k5G5gwFp049787; Fri, 16 Jun 2006 00:42:58 -0500 (CDT) (envelope-from dennisolvany) Message-Id: <200606160542.k5G5gwFp049787@postfix.deadghost.com> Date: Fri, 16 Jun 2006 00:42:58 -0500 (CDT) From: Dennis Olvany To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: docs/99007: [patch] misleading nat configuration info X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dennis Olvany List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 05:50:16 -0000 >Number: 99007 >Category: docs >Synopsis: [patch] misleading nat configuration info >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: update >Submitter-Id: current-users >Arrival-Date: Fri Jun 16 05:50:10 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Dennis Olvany >Release: FreeBSD 5.4-SECURITY i386 >Organization: >Environment: System: FreeBSD postfix.deadghost.com 5.4-SECURITY FreeBSD 5.4-SECURITY #0: Tue Apr 18 06:15:11 UTC 2006 root@builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 >Description: nat configuration instructions give users the impression that kernel compilation is necessary, it is not >How-To-Repeat: >Fix: manually load kernel modules or use rc scripts to invoke the modules --- chapter.sgml begins here --- Advanced Networking Synopsis This chapter will cover a number of advanced networking topics. After reading this chapter, you will know: The basics of gateways and routes. How to set up IEEE 802.11 and &bluetooth; devices. How to make FreeBSD act as a bridge. How to set up network booting on a diskless machine. How to set up network address translation. How to connect two computers via PLIP. How to set up IPv6 on a FreeBSD machine. How to configure ATM. Before reading this chapter, you should: Understand the basics of the /etc/rc scripts. Be familiar with basic network terminology. Know how to configure and install a new FreeBSD kernel (). Know how to install additional third-party software (). Coranth Gryphon Contributed by Gateways and Routes routing gateway subnet For one machine to be able to find another over a network, there must be a mechanism in place to describe how to get from one to the other. This is called routing. A route is a defined pair of addresses: a destination and a gateway. The pair indicates that if you are trying to get to this destination, communicate through this gateway. There are three types of destinations: individual hosts, subnets, and default. The default route is used if none of the other routes apply. We will talk a little bit more about default routes later on. There are also three types of gateways: individual hosts, interfaces (also called links), and Ethernet hardware addresses (MAC addresses). An Example To illustrate different aspects of routing, we will use the following example from netstat: &prompt.user; netstat -r Routing tables Destination Gateway Flags Refs Use Netif Expire default outside-gw UGSc 37 418 ppp0 localhost localhost UH 0 181 lo0 test0 0:e0:b5:36:cf:4f UHLW 5 63288 ed0 77 10.20.30.255 link#1 UHLW 1 2421 example.com link#1 UC 0 0 host1 0:e0:a8:37:8:1e UHLW 3 4601 lo0 host2 0:e0:a8:37:8:1e UHLW 0 5 lo0 => host2.example.com link#1 UC 0 0 224 link#1 UC 0 0 default route The first two lines specify the default route (which we will cover in the next section) and the localhost route. loopback device The interface (Netif column) that this routing table specifies to use for localhost is lo0, also known as the loopback device. This says to keep all traffic for this destination internal, rather than sending it out over the LAN, since it will only end up back where it started. Ethernet MAC address The next thing that stands out are the addresses beginning with 0:e0:. These are Ethernet hardware addresses, which are also known as MAC addresses. FreeBSD will automatically identify any hosts (test0 in the example) on the local Ethernet and add a route for that host, directly to it over the Ethernet interface, ed0. There is also a timeout (Expire column) associated with this type of route, which is used if we fail to hear from the host in a specific amount of time. When this happens, the route to this host will be automatically deleted. These hosts are identified using a mechanism known as RIP (Routing Information Protocol), which figures out routes to local hosts based upon a shortest path determination. subnet FreeBSD will also add subnet routes for the local subnet (10.20.30.255 is the broadcast address for the subnet 10.20.30, and example.com is the domain name associated with that subnet). The designation link#1 refers to the first Ethernet card in the machine. You will notice no additional interface is specified for those. Both of these groups (local network hosts and local subnets) have their routes automatically configured by a daemon called routed. If this is not run, then only routes which are statically defined (i.e. entered explicitly) will exist. The host1 line refers to our host, which it knows by Ethernet address. Since we are the sending host, FreeBSD knows to use the loopback interface (lo0) rather than sending it out over the Ethernet interface. The two host2 lines are an example of what happens when we use an &man.ifconfig.8; alias (see the section on Ethernet for reasons why we would do this). The => symbol after the lo0 interface says that not only are we using the loopback (since this address also refers to the local host), but specifically it is an alias. Such routes only show up on the host that supports the alias; all other hosts on the local network will simply have a link#1 line for such routes. The final line (destination subnet 224) deals with multicasting, which will be covered in another section. Finally, various attributes of each route can be seen in the Flags column. Below is a short table of some of these flags and their meanings: U Up: The route is active. H Host: The route destination is a single host. G Gateway: Send anything for this destination on to this remote system, which will figure out from there where to send it. S Static: This route was configured manually, not automatically generated by the system. C Clone: Generates a new route based upon this route for machines we connect to. This type of route is normally used for local networks. W WasCloned: Indicated a route that was auto-configured based upon a local area network (Clone) route. L Link: Route involves references to Ethernet hardware. Default Routes default route When the local system needs to make a connection to a remote host, it checks the routing table to determine if a known path exists. If the remote host falls into a subnet that we know how to reach (Cloned routes), then the system checks to see if it can connect along that interface. If all known paths fail, the system has one last option: the default route. This route is a special type of gateway route (usually the only one present in the system), and is always marked with a c in the flags field. For hosts on a local area network, this gateway is set to whatever machine has a direct connection to the outside world (whether via PPP link, DSL, cable modem, T1, or another network interface). If you are configuring the default route for a machine which itself is functioning as the gateway to the outside world, then the default route will be the gateway machine at your Internet Service Provider's (ISP) site. Let us look at an example of default routes. This is a common configuration: [Local2] <--ether--> [Local1] <--PPP--> [ISP-Serv] <--ether--> [T1-GW] The hosts Local1 and Local2 are at your site. Local1 is connected to an ISP via a dial up PPP connection. This PPP server computer is connected through a local area network to another gateway computer through an external interface to the ISPs Internet feed. The default routes for each of your machines will be: Host Default Gateway Interface Local2 Local1 Ethernet Local1 T1-GW PPP A common question is Why (or how) would we set the T1-GW to be the default gateway for Local1, rather than the ISP server it is connected to?. Remember, since the PPP interface is using an address on the ISP's local network for your side of the connection, routes for any other machines on the ISP's local network will be automatically generated. Hence, you will already know how to reach the T1-GW machine, so there is no need for the intermediate step of sending traffic to the ISP server. It is common to use the address X.X.X.1 as the gateway address for your local network. So (using the same example), if your local class-C address space was 10.20.30 and your ISP was using 10.9.9 then the default routes would be: Host Default Route Local2 (10.20.30.2) Local1 (10.20.30.1) Local1 (10.20.30.1, 10.9.9.30) T1-GW (10.9.9.1) You can easily define the default route via the /etc/rc.conf file. In our example, on the Local2 machine, we added the following line in /etc/rc.conf: defaultrouter="10.20.30.1" It is also possible to do it directly from the command line with the &man.route.8; command: &prompt.root; route add default 10.20.30.1 For more information on manual manipulation of network routing tables, consult &man.route.8; manual page. Dual Homed Hosts dual homed hosts There is one other type of configuration that we should cover, and that is a host that sits on two different networks. Technically, any machine functioning as a gateway (in the example above, using a PPP connection) counts as a dual-homed host. But the term is really only used to refer to a machine that sits on two local-area networks. In one case, the machine has two Ethernet cards, each having an address on the separate subnets. Alternately, the machine may only have one Ethernet card, and be using &man.ifconfig.8; aliasing. The former is used if two physically separate Ethernet networks are in use, the latter if there is one physical network segment, but two logically separate subnets. Either way, routing tables are set up so that each subnet knows that this machine is the defined gateway (inbound route) to the other subnet. This configuration, with the machine acting as a router between the two subnets, is often used when we need to implement packet filtering or firewall security in either or both directions. If you want this machine to actually forward packets between the two interfaces, you need to tell FreeBSD to enable this ability. See the next section for more details on how to do this. Building a Router router A network router is simply a system that forwards packets from one interface to another. Internet standards and good engineering practice prevent the FreeBSD Project from enabling this by default in FreeBSD. You can enable this feature by changing the following variable to YES in &man.rc.conf.5;: gateway_enable=YES # Set to YES if this host will be a gateway This option will set the &man.sysctl.8; variable net.inet.ip.forwarding to 1. If you should need to stop routing temporarily, you can reset this to 0 temporarily. Your new router will need routes to know where to send the traffic. If your network is simple enough you can use static routes. FreeBSD also comes with the standard BSD routing daemon &man.routed.8;, which speaks RIP (both version 1 and version 2) and IRDP. Support for BGP v4, OSPF v2, and other sophisticated routing protocols is available with the net/zebra package. Commercial products such as &gated; are also available for more complex network routing solutions. BGP RIP OSPF Al Hoang Contributed by Setting Up Static Routes Manual Configuration Let us assume we have a network as follows: INTERNET | (10.0.0.1/24) Default Router to Internet | |Interface xl0 |10.0.0.10/24 +------+ | | RouterA | | (FreeBSD gateway) +------+ | Interface xl1 | 192.168.1.1/24 | +--------------------------------+ Internal Net 1 | 192.168.1.2/24 | +------+ | | RouterB | | +------+ | 192.168.2.1/24 | Internal Net 2 In this scenario, RouterA is our &os; machine that is acting as a router to the rest of the Internet. It has a default route set to 10.0.0.1 which allows it to connect with the outside world. We will assume that RouterB is already configured properly and knows how to get wherever it needs to go. (This is simple in this picture. Just add a default route on RouterB using 192.168.1.1 as the gateway.) If we look at the routing table for RouterA we would see something like the following: &prompt.user; netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.0.0.1 UGS 0 49378 xl0 127.0.0.1 127.0.0.1 UH 0 6 lo0 10.0.0/24 link#1 UC 0 0 xl0 192.168.1/24 link#2 UC 0 0 xl1 With the current routing table RouterA will not be able to reach our Internal Net 2. It does not have a route for 192.168.2.0/24. One way to alleviate this is to manually add the route. The following command would add the Internal Net 2 network to RouterA's routing table using 192.168.1.2 as the next hop: &prompt.root; route add -net 192.168.2.0/24 192.168.1.2 Now RouterA can reach any hosts on the 192.168.2.0/24 network. Persistent Configuration The above example is perfect for configuring a static route on a running system. However, one problem is that the routing information will not persist if you reboot your &os; machine. The way to handle the addition of a static route is to put it in your /etc/rc.conf file: # Add Internal Net 2 as a static route static_routes="internalnet2" route_internalnet2="-net 192.168.2.0/24 192.168.1.2" The static_routes configuration variable is a list of strings separated by a space. Each string references to a route name. In our above example we only have one string in static_routes. This string is internalnet2. We then add a configuration variable called route_internalnet2 where we put all of the configuration parameters we would give to the &man.route.8; command. For our example above we would have used the command: &prompt.root; route add -net 192.168.2.0/24 192.168.1.2 so we need "-net 192.168.2.0/24 192.168.1.2". As said above, we can have more than one string in static_routes. This allows us to create multiple static routes. The following lines shows an example of adding static routes for the 192.168.0.0/24 and 192.168.1.0/24 networks on an imaginary router: static_routes="net1 net2" route_net1="-net 192.168.0.0/24 192.168.0.1" route_net2="-net 192.168.1.0/24 192.168.1.1" Routing Propagation routing propagation We have already talked about how we define our routes to the outside world, but not about how the outside world finds us. We already know that routing tables can be set up so that all traffic for a particular address space (in our examples, a class-C subnet) can be sent to a particular host on that network, which will forward the packets inbound. When you get an address space assigned to your site, your service provider will set up their routing tables so that all traffic for your subnet will be sent down your PPP link to your site. But how do sites across the country know to send to your ISP? There is a system (much like the distributed DNS information) that keeps track of all assigned address-spaces, and defines their point of connection to the Internet Backbone. The Backbone are the main trunk lines that carry Internet traffic across the country, and around the world. Each backbone machine has a copy of a master set of tables, which direct traffic for a particular network to a specific backbone carrier, and from there down the chain of service providers until it reaches your network. It is the task of your service provider to advertise to the backbone sites that they are the point of connection (and thus the path inward) for your site. This is known as route propagation. Troubleshooting traceroute Sometimes, there is a problem with routing propagation, and some sites are unable to connect to you. Perhaps the most useful command for trying to figure out where routing is breaking down is the &man.traceroute.8; command. It is equally useful if you cannot seem to make a connection to a remote machine (i.e. &man.ping.8; fails). The &man.traceroute.8; command is run with the name of the remote host you are trying to connect to. It will show the gateway hosts along the path of the attempt, eventually either reaching the target host, or terminating because of a lack of connection. For more information, see the manual page for &man.traceroute.8;. Multicast Routing multicast routing kernel options MROUTING FreeBSD supports both multicast applications and multicast routing natively. Multicast applications do not require any special configuration of FreeBSD; applications will generally run out of the box. Multicast routing requires that support be compiled into the kernel: options MROUTING In addition, the multicast routing daemon, &man.mrouted.8; must be configured to set up tunnels and DVMRP via /etc/mrouted.conf. More details on multicast configuration may be found in the manual page for &man.mrouted.8;. Eric Anderson Written by Wireless Networking wireless networking 802.11 wireless networking Introduction It can be very useful to be able to use a computer without the annoyance of having a network cable attached at all times. FreeBSD can be used as a wireless client, and even as a wireless access point. Wireless Modes of Operation There are two different ways to configure 802.11 wireless devices: BSS and IBSS. BSS Mode BSS mode is the mode that typically is used. BSS mode is also called infrastructure mode. In this mode, a number of wireless access points are connected to a wired network. Each wireless network has its own name. This name is called the SSID of the network. Wireless clients connect to these wireless access points. The IEEE 802.11 standard defines the protocol that wireless networks use to connect. A wireless client can be tied to a specific network, when a SSID is set. A wireless client can also attach to any network by not explicitly setting a SSID. IBSS Mode IBSS mode, also called ad-hoc mode, is designed for point to point connections. There are actually two types of ad-hoc mode. One is IBSS mode, also called ad-hoc or IEEE ad-hoc mode. This mode is defined by the IEEE 802.11 standards. The second is called demo ad-hoc mode or Lucent ad-hoc mode (and sometimes, confusingly, ad-hoc mode). This is the old, pre-802.11 ad-hoc mode and should only be used for legacy installations. We will not cover either of the ad-hoc modes further. Infrastructure Mode Access Points Access points are wireless networking devices that allow one or more wireless clients to use the device as a central hub. When using an access point, all clients communicate through the access point. Multiple access points are often used to cover a complete area such as a house, business, or park with a wireless network. Access points typically have multiple network connections: the wireless card, and one or more wired Ethernet adapters for connection to the rest of the network. Access points can either be purchased prebuilt, or you can build your own with FreeBSD and a supported wireless card. Several vendors make wireless access points and wireless cards with various features. Building a FreeBSD Access Point wireless networking access point Requirements In order to set up a wireless access point with FreeBSD, you need to have a compatible wireless card. Currently, only cards with the Prism chipset are supported. You will also need a wired network card that is supported by FreeBSD (this should not be difficult to find, FreeBSD supports a lot of different devices). For this guide, we will assume you want to &man.bridge.4; all traffic between the wireless device and the network attached to the wired network card. The hostap functionality that FreeBSD uses to implement the access point works best with certain versions of firmware. Prism 2 cards should use firmware version 1.3.4 or newer. Prism 2.5 and Prism 3 cards should use firmware 1.4.9. Older versions of the firmware way or may not function correctly. At this time, the only way to update cards is with &windows; firmware update utilities available from your card's manufacturer. Setting It Up First, make sure your system can see the wireless card: &prompt.root; ifconfig -a wi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::202:2dff:fe2d:c938%wi0 prefixlen 64 scopeid 0x7 inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 ether 00:09:2d:2d:c9:50 media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps) status: no carrier ssid "" stationname "FreeBSD Wireless node" channel 10 authmode OPEN powersavemode OFF powersavesleep 100 wepmode OFF weptxkey 1 Do not worry about the details now, just make sure it shows you something to indicate you have a wireless card installed. If you have trouble seeing the wireless interface, and you are using a PC Card, you may want to check out &man.pccardc.8; and &man.pccardd.8; manual pages for more information. Next, you will need to load a module in order to get the bridging part of FreeBSD ready for the access point. To load the &man.bridge.4; module, simply run the following command: &prompt.root; kldload bridge It should not have produced any errors when loading the module. If it did, you may need to compile the &man.bridge.4; code into your kernel. The Bridging section of this handbook should be able to help you accomplish that task. Now that you have the bridging stuff done, we need to tell the FreeBSD kernel which interfaces to bridge together. We do that by using &man.sysctl.8;: &prompt.root; sysctl net.link.ether.bridge.enable=1 &prompt.root; sysctl net.link.ether.bridge.config="wi0 xl0" &prompt.root; sysctl net.inet.ip.forwarding=1 On &os; versions earlier than 5.2, you need to use the following options instead: &prompt.root; sysctl net.link.ether.bridge=1 &prompt.root; sysctl net.link.ether.bridge_cfg="wi0,xl0" &prompt.root; sysctl net.inet.ip.forwarding=1 Now it is time for the wireless card setup. The following command will set the card into an access point: &prompt.root; ifconfig wi0 ssid my_net channel 11 media DS/11Mbps mediaopt hostap up stationname "FreeBSD AP" The &man.ifconfig.8; line brings the wi0 interface up, sets its SSID to my_net, and sets the station name to FreeBSD AP. The sets the card into 11Mbps mode and is needed for any to take effect. The option places the interface into access point mode. The option sets the 802.11b channel to use. The &man.wicontrol.8; manual page has valid channel options for your regulatory domain. Now you should have a complete functioning access point up and running. You are encouraged to read &man.wicontrol.8;, &man.ifconfig.8;, and &man.wi.4; for further information. It is also suggested that you read the section on encryption that follows. Status Information Once the access point is configured and operational, operators will want to see the clients that are associated with the access point. At any time, the operator may type: &prompt.root; wicontrol -l 1 station: 00:09:b7:7b:9d:16 asid=04c0, flags=3<ASSOC,AUTH>, caps=1<ESS>, rates=f<1M,2M,5.5M,11M>, sig=38/15 This shows that there is one station associated, along with its parameters. The signal indicated should be used as a relative indication of strength only. Its translation to dBm or other units varies between different firmware revisions. Clients A wireless client is a system that accesses an access point or another client directly. Typically, wireless clients only have one network device, the wireless networking card. There are a few different ways to configure a wireless client. These are based on the different wireless modes, generally BSS (infrastructure mode, which requires an access point), and IBSS (ad-hoc, or peer-to-peer mode). In our example, we will use the most popular of the two, BSS mode, to talk to an access point. Requirements There is only one real requirement for setting up FreeBSD as a wireless client. You will need a wireless card that is supported by FreeBSD. Setting Up a Wireless FreeBSD Client You will need to know a few things about the wireless network you are joining before you start. In this example, we are joining a network that has a name of my_net, and encryption turned off. In this example, we are not using encryption, which is a dangerous situation. In the next section, you will learn how to turn on encryption, why it is important to do so, and why some encryption technologies still do not completely protect you. Make sure your card is recognized by FreeBSD: &prompt.root; ifconfig -a wi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::202:2dff:fe2d:c938%wi0 prefixlen 64 scopeid 0x7 inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 ether 00:09:2d:2d:c9:50 media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps) status: no carrier ssid "" stationname "FreeBSD Wireless node" channel 10 authmode OPEN powersavemode OFF powersavesleep 100 wepmode OFF weptxkey 1 Now, we can set the card to the correct settings for our network: &prompt.root; ifconfig wi0 inet 192.168.0.20 netmask 255.255.255.0 ssid my_net Replace 192.168.0.20 and 255.255.255.0 with a valid IP address and netmask on your wired network. Remember, our access point is bridging the data between the wireless network, and the wired network, so it will appear to the other devices on your network that you are on the wired network just as they are. Once you have done that, you should be able to ping hosts on the wired network just as if you were connected using a standard wired connection. If you are experiencing problems with your wireless connection, check to make sure that you are associated (connected) to the access point: &prompt.root; ifconfig wi0 should return some information, and you should see: status: associated If it does not show associated, then you may be out of range of the access point, have encryption on, or possibly have a configuration problem. Encryption wireless networking encryption Encryption on a wireless network is important because you no longer have the ability to keep the network contained in a well protected area. Your wireless data will be broadcast across your entire neighborhood, so anyone who cares to read it can. This is where encryption comes in. By encrypting the data that is sent over the airwaves, you make it much more difficult for any interested party to grab your data right out of the air. The two most common ways to encrypt the data between your client and the access point are WEP, and &man.ipsec.4;. WEP WEP WEP is an abbreviation for Wired Equivalency Protocol. WEP is an attempt to make wireless networks as safe and secure as a wired network. Unfortunately, it has been cracked, and is fairly trivial to break. This also means it is not something to rely on when it comes to encrypting sensitive data. It is better than nothing, so use the following to turn on WEP on your new FreeBSD access point: &prompt.root; ifconfig wi0 inet up ssid my_net wepmode on wepkey 0x1234567890 media DS/11Mbps mediaopt hostap And you can turn on WEP on a client with this command: &prompt.root; ifconfig wi0 inet 192.168.0.20 netmask 255.255.255.0 ssid my_net wepmode on wepkey 0x1234567890 Note that you should replace the 0x1234567890 with a more unique key. IPsec &man.ipsec.4; is a much more robust and powerful tool for encrypting data across a network. This is definitely the preferred way to encrypt data over a wireless network. You can read more about &man.ipsec.4; security and how to implement it in the IPsec section of this handbook. Tools There are a small number of tools available for use in debugging and setting up your wireless network, and here we will attempt to describe some of them and what they do. The <application>bsd-airtools</application> Package The bsd-airtools package is a complete toolset that includes wireless auditing tools for WEP key cracking, access point detection, etc. The bsd-airtools utilities can be installed from the net-mgmt/bsd-airtools port. Information on installing ports can be found in of this handbook. The program dstumbler is the packaged tool that allows for access point discovery and signal to noise ratio graphing. If you are having a hard time getting your access point up and running, dstumbler may help you get started. To test your wireless network security, you may choose to use dweputils (dwepcrack, dwepdump and dwepkeygen) to help you determine if WEP is the right solution to your wireless security needs. The <command>wicontrol</command>, <command>ancontrol</command> and <command>raycontrol</command> Utilities These are the tools you can use to control how your wireless card behaves on the wireless network. In the examples above, we have chosen to use &man.wicontrol.8;, since our wireless card is a wi0 interface. If you had a Cisco wireless device, it would come up as an0, and therefore you would use &man.ancontrol.8;. The <command>ifconfig</command> Command ifconfig The &man.ifconfig.8; command can be used to do many of the same options as &man.wicontrol.8;, however it does lack a few options. Check &man.ifconfig.8; for command line parameters and options. Supported Cards Access Points The only cards that are currently supported for BSS (as an access point) mode are devices based on the Prism 2, 2.5, or 3 chipsets. For a complete list, look at &man.wi.4;. 802.11b Clients Almost all 802.11b wireless cards are currently supported under FreeBSD. Most cards based on Prism, Spectrum24, Hermes, Aironet, and Raylink will work as a wireless network card in IBSS (ad-hoc, peer-to-peer, and BSS) mode. 802.11a & 802.11g Clients The &man.ath.4; device driver supports 802.11a and 802.11g. If your card is based on an Atheros chipset, you may be able to use this driver. Unfortunately, there are still many vendors that do not provide schematics for their drivers to the open source community because they regard such information as trade secrets. Consequently, the developers of FreeBSD and other operating systems are left two choices: develop the drivers by a long and pain-staking process of reverse engineering or using the existing driver binaries available for the µsoft.windows; platforms. Most developers, including those involved with FreeBSD, have taken the latter approach. Thanks to the contributions of Bill Paul (wpaul), as of FreeBSD 5.3-RELEASE there is native support for the Network Driver Interface Specification (NDIS). The FreeBSD NDISulator (otherwise known as Project Evil) takes a &windows; driver binary and basically tricks it into thinking it is running on &windows;. This feature is still relatively new, but most test cases seem to work adequately. NDIS NDISulator &windows; drivers Microsoft Windows Microsoft Windows device drivers KLD (kernel loadable object) In order to use the NDISulator, you need three things: Kernel sources &windowsxp; driver binary (.SYS extension) &windowsxp; driver configuration file (.INF extension) You may need to compile the &man.ndis.4; mini port driver wrapper module. As root: &prompt.root; cd /usr/src/sys/modules/ndis &prompt.root; make && make install Locate the files for your specific card. Generally, they can be found on the included CDs or at the vendors' websites. In the following examples, we will use W32DRIVER.SYS and W32DRIVER.INF. The next step is to compile the driver binary into a loadable kernel module. To accomplish this, as root, go into the if_ndis module directory and copy the &windows; driver files into it: &prompt.root; cd /usr/src/sys/modules/if_ndis &prompt.root; cp /path/to/driver/W32DRIVER.SYS ./ &prompt.root; cp /path/to/driver/W32DRIVER.INF ./ We will now use the ndiscvt utility to create the driver definition header ndis_driver_data.h to build the module: &prompt.root; ndiscvt -i W32DRIVER.INF -s W32DRIVER.SYS -o ndis_driver_data.h The and options specify the configuration and binary files, respectively. We use the option because the Makefile will be looking for this file when it comes time to build the module. Some &windows; drivers require additional files to operate. You may include them with ndiscvt by using the option. Consult the &man.ndiscvt.8; manual page for more information. Finally, we can build and install the driver module: &prompt.root; make && make install To use the driver, you must load the appropriate modules: &prompt.root; kldload ndis &prompt.root; kldload if_ndis The first command loads the NDIS miniport driver wrapper, the second loads the actual network interface. Check &man.dmesg.8; to see if there were any errors loading. If all went well, you should get output resembling the following: ndis0: <Wireless-G PCI Adapter> mem 0xf4100000-0xf4101fff irq 3 at device 8.0 on pci1 ndis0: NDIS API version: 5.0 ndis0: Ethernet address: 0a:b1:2c:d3:4e:f5 ndis0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ndis0: 11g rates: 6Mbps 9Mbps 12Mbps 18Mbps 36Mbps 48Mbps 54Mbps From here you can treat the ndis0 device like any other wireless device (e.g. wi0) and consult the earlier sections of this chapter. Pav Lucistnik Written by
pav@FreeBSD.org
 Bluetooth Bluetooth Introduction Bluetooth is a wireless technology for creating personal networks operating in the 2.4 GHz unlicensed band, with a range of 10 meters. Networks are usually formed ad-hoc from portable devices such as cellular phones, handhelds and laptops. Unlike the other popular wireless technology, Wi-Fi, Bluetooth offers higher level service profiles, e.g. FTP-like file servers, file pushing, voice transport, serial line emulation, and more. The Bluetooth stack in &os; is implemented using the Netgraph framework (see &man.netgraph.4;). A broad variety of Bluetooth USB dongles is supported by the &man.ng.ubt.4; driver. The Broadcom BCM2033 chip based Bluetooth devices are supported via the &man.ubtbcmfw.4; and &man.ng.ubt.4; drivers. The 3Com Bluetooth PC Card 3CRWB60-A is supported by the &man.ng.bt3c.4; driver. Serial and UART based Bluetooth devices are supported via &man.sio.4;, &man.ng.h4.4; and &man.hcseriald.8;. This section describes the use of the USB Bluetooth dongle. Plugging in the Device By default Bluetooth device drivers are available as kernel modules. Before attaching a device, you will need to load the driver into the kernel: &prompt.root; kldload ng_ubt If the Bluetooth device is present in the system during system startup, load the module from /boot/loader.conf: ng_ubt_load="YES" Plug in your USB dongle. The output similar to the following will appear on the console (or in syslog): ubt0: vendor 0x0a12 product 0x0001, rev 1.10/5.25, addr 2 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3, wMaxPacketSize=49, nframes=6, buffer size=294 The Bluetooth stack has to be started manually on &os; 6.0, and on &os; 5.X before 5.5. It is done automatically from &man.devd.8; on &os; 5.5, 6.1 and newer. Copy /usr/share/examples/netgraph/bluetooth/rc.bluetooth into some convenient place, like /etc/rc.bluetooth. This script is used to start and stop the Bluetooth stack. It is a good idea to stop the stack before unplugging the device, but it is not (usually) fatal. When starting the stack, you will receive output similar to the following: &prompt.root; /etc/rc.bluetooth start ubt0 BD_ADDR: 00:02:72:00:d4:1a Features: 0xff 0xff 0xf 00 00 00 00 00 <3-Slot> <5-Slot> <Encryption> <Slot offset> <Timing accuracy> <Switch> <Hold mode> <Sniff mode> <Park mode> <RSSI> <Channel quality> <SCO link> <HV2 packets> <HV3 packets> <u-law log> <A-law log> <CVSD> <Paging scheme> <Power control> <Transparent SCO data> Max. ACL packet size: 192 bytes Number of ACL packets: 8 Max. SCO packet size: 64 bytes Number of SCO packets: 8 HCI Host Controller Interface (HCI) Host Controller Interface (HCI) provides a command interface to the baseband controller and link manager, and access to hardware status and control registers. This interface provides a uniform method of accessing the Bluetooth baseband capabilities. HCI layer on the Host exchanges data and commands with the HCI firmware on the Bluetooth hardware. The Host Controller Transport Layer (i.e. physical bus) driver provides both HCI layers with the ability to exchange information with each other. A single Netgraph node of type hci is created for a single Bluetooth device. The HCI node is normally connected to the Bluetooth device driver node (downstream) and the L2CAP node (upstream). All HCI operations must be performed on the HCI node and not on the device driver node. Default name for the HCI node is devicehci. For more details refer to the &man.ng.hci.4; manual page. One of the most common tasks is discovery of Bluetooth devices in RF proximity. This operation is called inquiry. Inquiry and other HCI related operations are done with the &man.hccontrol.8; utility. The example below shows how to find out which Bluetooth devices are in range. You should receive the list of devices in a few seconds. Note that a remote device will only answer the inquiry if it put into discoverable mode. &prompt.user; hccontrol -n ubt0hci inquiry Inquiry result, num_responses=1 Inquiry result #0 BD_ADDR: 00:80:37:29:19:a4 Page Scan Rep. Mode: 0x1 Page Scan Period Mode: 00 Page Scan Mode: 00 Class: 52:02:04 Clock offset: 0x78ef Inquiry complete. Status: No error [00] BD_ADDR is unique address of a Bluetooth device, similar to MAC addresses of a network card. This address is needed for further communication with a device. It is possible to assign human readable name to a BD_ADDR. The /etc/bluetooth/hosts file contains information regarding the known Bluetooth hosts. The following example shows how to obtain human readable name that was assigned to the remote device: &prompt.user; hccontrol -n ubt0hci remote_name_request 00:80:37:29:19:a4 BD_ADDR: 00:80:37:29:19:a4 Name: Pav's T39 If you perform an inquiry on a remote Bluetooth device, it will find your computer as your.host.name (ubt0). The name assigned to the local device can be changed at any time. The Bluetooth system provides a point-to-point connection (only two Bluetooth units involved), or a point-to-multipoint connection. In the point-to-multipoint connection the connection is shared among several Bluetooth devices. The following example shows how to obtain the list of active baseband connections for the local device: &prompt.user; hccontrol -n ubt0hci read_connection_list Remote BD_ADDR Handle Type Mode Role Encrypt Pending Queue State 00:80:37:29:19:a4 41 ACL 0 MAST NONE 0 0 OPEN A connection handle is useful when termination of the baseband connection is required. Note, that it is normally not required to do it by hand. The stack will automatically terminate inactive baseband connections. &prompt.root; hccontrol -n ubt0hci disconnect 41 Connection handle: 41 Reason: Connection terminated by local host [0x16] Refer to hccontrol help for a complete listing of available HCI commands. Most of the HCI commands do not require superuser privileges. L2CAP Logical Link Control and Adaptation Protocol (L2CAP) Logical Link Control and Adaptation Protocol (L2CAP) provides connection-oriented and connectionless data services to upper layer protocols with protocol multiplexing capability and segmentation and reassembly operation. L2CAP permits higher level protocols and applications to transmit and receive L2CAP data packets up to 64 kilobytes in length. L2CAP is based around the concept of channels. Channel is a logical connection on top of baseband connection. Each channel is bound to a single protocol in a many-to-one fashion. Multiple channels can be bound to the same protocol, but a channel cannot be bound to multiple protocols. Each L2CAP packet received on a channel is directed to the appropriate higher level protocol. Multiple channels can share the same baseband connection. A single Netgraph node of type l2cap is created for a single Bluetooth device. The L2CAP node is normally connected to the Bluetooth HCI node (downstream) and Bluetooth sockets nodes (upstream). Default name for the L2CAP node is devicel2cap. For more details refer to the &man.ng.l2cap.4; manual page. A useful command is &man.l2ping.8;, which can be used to ping other devices. Some Bluetooth implementations might not return all of the data sent to them, so 0 bytes in the following example is normal. &prompt.root; l2ping -a 00:80:37:29:19:a4 0 bytes from 0:80:37:29:19:a4 seq_no=0 time=48.633 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=1 time=37.551 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=2 time=28.324 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=3 time=46.150 ms result=0 The &man.l2control.8; utility is used to perform various operations on L2CAP nodes. This example shows how to obtain the list of logical connections (channels) and the list of baseband connections for the local device: &prompt.user; l2control -a 00:02:72:00:d4:1a read_channel_list L2CAP channels: Remote BD_ADDR SCID/ DCID PSM IMTU/ OMTU State 00:07:e0:00:0b:ca 66/ 64 3 132/ 672 OPEN &prompt.user; l2control -a 00:02:72:00:d4:1a read_connection_list L2CAP connections: Remote BD_ADDR Handle Flags Pending State 00:07:e0:00:0b:ca 41 O 0 OPEN Another diagnostic tool is &man.btsockstat.1;. It does a job similar to as &man.netstat.1; does, but for Bluetooth network-related data structures. The example below shows the same logical connection as &man.l2control.8; above. &prompt.user; btsockstat Active L2CAP sockets PCB Recv-Q Send-Q Local address/PSM Foreign address CID State c2afe900 0 0 00:02:72:00:d4:1a/3 00:07:e0:00:0b:ca 66 OPEN Active RFCOMM sessions L2PCB PCB Flag MTU Out-Q DLCs State c2afe900 c2b53380 1 127 0 Yes OPEN Active RFCOMM sockets PCB Recv-Q Send-Q Local address Foreign address Chan DLCI State c2e8bc80 0 250 00:02:72:00:d4:1a 00:07:e0:00:0b:ca 3 6 OPEN RFCOMM RFCOMM Protocol The RFCOMM protocol provides emulation of serial ports over the L2CAP protocol. The protocol is based on the ETSI standard TS 07.10. RFCOMM is a simple transport protocol, with additional provisions for emulating the 9 circuits of RS-232 (EIATIA-232-E) serial ports. The RFCOMM protocol supports up to 60 simultaneous connections (RFCOMM channels) between two Bluetooth devices. For the purposes of RFCOMM, a complete communication path involves two applications running on different devices (the communication endpoints) with a communication segment between them. RFCOMM is intended to cover applications that make use of the serial ports of the devices in which they reside. The communication segment is a Bluetooth link from one device to another (direct connect). RFCOMM is only concerned with the connection between the devices in the direct connect case, or between the device and a modem in the network case. RFCOMM can support other configurations, such as modules that communicate via Bluetooth wireless technology on one side and provide a wired interface on the other side. In &os; the RFCOMM protocol is implemented at the Bluetooth sockets layer. pairing Pairing of Devices By default, Bluetooth communication is not authenticated, and any device can talk to any other device. A Bluetooth device (for example, cellular phone) may choose to require authentication to provide a particular service (for example, Dial-Up service). Bluetooth authentication is normally done with PIN codes. A PIN code is an ASCII string up to 16 characters in length. User is required to enter the same PIN code on both devices. Once user has entered the PIN code, both devices will generate a link key. After that the link key can be stored either in the devices themselves or in a persistent storage. Next time both devices will use previously generated link key. The described above procedure is called pairing. Note that if the link key is lost by any device then pairing must be repeated. The &man.hcsecd.8; daemon is responsible for handling of all Bluetooth authentication requests. The default configuration file is /etc/bluetooth/hcsecd.conf. An example section for a cellular phone with the PIN code arbitrarily set to 1234 is shown below: device { bdaddr 00:80:37:29:19:a4; name "Pav's T39"; key nokey; pin "1234"; } There is no limitation on PIN codes (except length). Some devices (for example Bluetooth headsets) may have a fixed PIN code built in. The switch forces the &man.hcsecd.8; daemon to stay in the foreground, so it is easy to see what is happening. Set the remote device to receive pairing and initiate the Bluetooth connection to the remote device. The remote device should say that pairing was accepted, and request the PIN code. Enter the same PIN code as you have in hcsecd.conf. Now your PC and the remote device are paired. Alternatively, you can initiate pairing on the remote device. On &os; 5.5, 6.1 and newer, the following line can be added to the /etc/rc.conf file to have hcsecd started automatically on system start: hcsecd_enable="YES" The following is a sample of the hcsecd daemon output: hcsecd[16484]: Got Link_Key_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', link key doesn't exist hcsecd[16484]: Sending Link_Key_Negative_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Got PIN_Code_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', PIN code exists hcsecd[16484]: Sending PIN_Code_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4 SDP Service Discovery Protocol (SDP) The Service Discovery Protocol (SDP) provides the means for client applications to discover the existence of services provided by server applications as well as the attributes of those services. The attributes of a service include the type or class of service offered and the mechanism or protocol information needed to utilize the service. SDP involves communication between a SDP server and a SDP client. The server maintains a list of service records that describe the characteristics of services associated with the server. Each service record contains information about a single service. A client may retrieve information from a service record maintained by the SDP server by issuing a SDP request. If the client, or an application associated with the client, decides to use a service, it must open a separate connection to the service provider in order to utilize the service. SDP provides a mechanism for discovering services and their attributes, but it does not provide a mechanism for utilizing those services. Normally, a SDP client searches for services based on some desired characteristics of the services. However, there are times when it is desirable to discover which types of services are described by an SDP server's service records without any a priori information about the services. This process of looking for any offered services is called browsing. The Bluetooth SDP server &man.sdpd.8; and command line client &man.sdpcontrol.8; are included in the standard &os; installation. The following example shows how to perform a SDP browse query. &prompt.user; sdpcontrol -a 00:01:03:fc:6e:ec browse Record Handle: 00000000 Service Class ID List: Service Discovery Server (0x1000) Protocol Descriptor List: L2CAP (0x0100) Protocol specific parameter #1: u/int/uuid16 1 Protocol specific parameter #2: u/int/uuid16 1 Record Handle: 0x00000001 Service Class ID List: Browse Group Descriptor (0x1001) Record Handle: 0x00000002 Service Class ID List: LAN Access Using PPP (0x1102) Protocol Descriptor List: L2CAP (0x0100) RFCOMM (0x0003) Protocol specific parameter #1: u/int8/bool 1 Bluetooth Profile Descriptor List: LAN Access Using PPP (0x1102) ver. 1.0 ... and so on. Note that each service has a list of attributes (RFCOMM channel for example). Depending on the service you might need to make a note of some of the attributes. Some Bluetooth implementations do not support service browsing and may return an empty list. In this case it is possible to search for the specific service. The example below shows how to search for the OBEX Object Push (OPUSH) service: &prompt.user; sdpcontrol -a 00:01:03:fc:6e:ec search OPUSH Offering services on &os; to Bluetooth clients is done with the &man.sdpd.8; server. On &os; 5.5, 6.1 and newer, the following line can be added to the /etc/rc.conf file: sdpd_enable="YES" Then the sdpd daemon can be started with: &prompt.root; /etc/rc.d/sdpd start On &os; 6.0, and on &os; 5.X before 5.5, sdpd is not integrated into the system startup scripts. It has to be started manually with: &prompt.root; sdpd The local server application that wants to provide Bluetooth service to the remote clients will register service with the local SDP daemon. The example of such application is &man.rfcomm.pppd.8;. Once started it will register Bluetooth LAN service with the local SDP daemon. The list of services registered with the local SDP server can be obtained by issuing SDP browse query via local control channel: &prompt.root; sdpcontrol -l browse Dial-Up Networking (DUN) and Network Access with PPP (LAN) Profiles The Dial-Up Networking (DUN) profile is mostly used with modems and cellular phones. The scenarios covered by this profile are the following: use of a cellular phone or modem by a computer as a wireless modem for connecting to a dial-up Internet access server, or using other dial-up services; use of a cellular phone or modem by a computer to receive data calls. Network Access with PPP (LAN) profile can be used in the following situations: LAN access for a single Bluetooth device; LAN access for multiple Bluetooth devices; PC to PC (using PPP networking over serial cable emulation). In &os; both profiles are implemented with &man.ppp.8; and &man.rfcomm.pppd.8; - a wrapper that converts RFCOMM Bluetooth connection into something PPP can operate with. Before any profile can be used, a new PPP label in the /etc/ppp/ppp.conf must be created. Consult &man.rfcomm.pppd.8; manual page for examples. In the following example &man.rfcomm.pppd.8; will be used to open RFCOMM connection to remote device with BD_ADDR 00:80:37:29:19:a4 on DUN RFCOMM channel. The actual RFCOMM channel number will be obtained from the remote device via SDP. It is possible to specify RFCOMM channel by hand, and in this case &man.rfcomm.pppd.8; will not perform SDP query. Use &man.sdpcontrol.8; to find out RFCOMM channel on the remote device. &prompt.root; rfcomm_pppd -a 00:80:37:29:19:a4 -c -C dun -l rfcomm-dialup In order to provide Network Access with PPP (LAN) service the &man.sdpd.8; server must be running. A new entry for LAN clients must be created in the /etc/ppp/ppp.conf file. Consult &man.rfcomm.pppd.8; manual page for examples. Finally, start RFCOMM PPP server on valid RFCOMM channel number. The RFCOMM PPP server will automatically register Bluetooth LAN service with the local SDP daemon. The example below shows how to start RFCOMM PPP server. &prompt.root; rfcomm_pppd -s -C 7 -l rfcomm-server OBEX OBEX Object Push (OPUSH) Profile OBEX is a widely used protocol for simple file transfers between mobile devices. Its main use is in infrared communication, where it is used for generic file transfers between notebooks or PDAs, and for sending business cards or calendar entries between cellular phones and other devices with PIM applications. The OBEX server and client are implemented as a third-party package obexapp, which is available as comms/obexapp port. OBEX client is used to push and/or pull objects from the OBEX server. An object can, for example, be a business card or an appointment. The OBEX client can obtain RFCOMM channel number from the remote device via SDP. This can be done by specifying service name instead of RFCOMM channel number. Supported service names are: IrMC, FTRN and OPUSH. It is possible to specify RFCOMM channel as a number. Below is an example of an OBEX session, where device information object is pulled from the cellular phone, and a new object (business card) is pushed into the phone's directory. &prompt.user; obexapp -a 00:80:37:29:19:a4 -C IrMC obex> get telecom/devinfo.txt devinfo-t39.txt Success, response: OK, Success (0x20) obex> put new.vcf Success, response: OK, Success (0x20) obex> di Success, response: OK, Success (0x20) In order to provide OBEX Object Push service, &man.sdpd.8; server must be running. A root folder, where all incoming objects will be stored, must be created. The default path to the root folder is /var/spool/obex. Finally, start OBEX server on valid RFCOMM channel number. The OBEX server will automatically register OBEX Object Push service with the local SDP daemon. The example below shows how to start OBEX server. &prompt.root; obexapp -s -C 10 Serial Port Profile (SPP) The Serial Port Profile (SPP) allows Bluetooth devices to perform RS232 (or similar) serial cable emulation. The scenario covered by this profile deals with legacy applications using Bluetooth as a cable replacement, through a virtual serial port abstraction. The &man.rfcomm.sppd.1; utility implements the Serial Port profile. A pseudo tty is used as a virtual serial port abstraction. The example below shows how to connect to a remote device Serial Port service. Note that you do not have to specify a RFCOMM channel - &man.rfcomm.sppd.1; can obtain it from the remote device via SDP. If you would like to override this, specify a RFCOMM channel on the command line. &prompt.root; rfcomm_sppd -a 00:07:E0:00:0B:CA -t /dev/ttyp6 rfcomm_sppd[94692]: Starting on /dev/ttyp6... Once connected, the pseudo tty can be used as serial port: &prompt.root; cu -l ttyp6 Troubleshooting A remote device cannot connect Some older Bluetooth devices do not support role switching. By default, when &os; is accepting a new connection, it tries to perform a role switch and become master. Devices, which do not support this will not be able to connect. Note that role switching is performed when a new connection is being established, so it is not possible to ask the remote device if it does support role switching. There is a HCI option to disable role switching on the local side: &prompt.root; hccontrol -n ubt0hci write_node_role_switch 0 Something is going wrong, can I see what exactly is happening? Yes, you can. Use the third-party package hcidump, which is available as comms/hcidump port. The hcidump utility is similar to &man.tcpdump.1;. It can be used to display the content of the Bluetooth packets on the terminal and to dump the Bluetooth packets to a file. Steve Peterson Written by Bridging Introduction IP subnet bridge It is sometimes useful to divide one physical network (such as an Ethernet segment) into two separate network segments without having to create IP subnets and use a router to connect the segments together. A device that connects two networks together in this fashion is called a bridge. A FreeBSD system with two network interface cards can act as a bridge. The bridge works by learning the MAC layer addresses (Ethernet addresses) of the devices on each of its network interfaces. It forwards traffic between two networks only when its source and destination are on different networks. In many respects, a bridge is like an Ethernet switch with very few ports. Situations Where Bridging Is Appropriate There are two common situations in which a bridge is used today. High Traffic on a Segment Situation one is where your physical network segment is overloaded with traffic, but you do not want for whatever reason to subnet the network and interconnect the subnets with a router. Let us consider an example of a newspaper where the Editorial and Production departments are on the same subnetwork. The Editorial users all use server A for file service, and the Production users are on server B. An Ethernet network is used to connect all users together, and high loads on the network are slowing things down. If the Editorial users could be segregated on one network segment and the Production users on another, the two network segments could be connected with a bridge. Only the network traffic destined for interfaces on the other side of the bridge would be sent to the other network, reducing congestion on each network segment. Filtering/Traffic Shaping Firewall firewall NAT The second common situation is where firewall functionality is needed without network address translation (NAT). An example is a small company that is connected via DSL or ISDN to their ISP. They have a 13 globally-accessible IP addresses from their ISP and have 10 PCs on their network. In this situation, using a router-based firewall is difficult because of subnetting issues. router DSL ISDN A bridge-based firewall can be configured and dropped into the path just downstream of their DSL/ISDN router without any IP numbering issues. Configuring a Bridge Network Interface Card Selection A bridge requires at least two network cards to function. Unfortunately, not all network interface cards support bridging. Read &man.bridge.4; for details on the cards that are supported. Install and test the two network cards before continuing. Kernel Configuration Changes kernel options BRIDGE To enable kernel support for bridging, add the: options BRIDGE statement to your kernel configuration file, and rebuild your kernel. Firewall Support firewall If you are planning to use the bridge as a firewall, you will need to add the IPFIREWALL option as well. Read for general information on configuring the bridge as a firewall. If you need to allow non-IP packets (such as ARP) to flow through the bridge, there is a firewall option that must be set. This option is IPFIREWALL_DEFAULT_TO_ACCEPT. Note that this changes the default rule for the firewall to accept any packet. Make sure you know how this changes the meaning of your ruleset before you set it. Traffic Shaping Support If you want to use the bridge as a traffic shaper, you will need to add the DUMMYNET option to your kernel configuration. Read &man.dummynet.4; for further information. Enabling the Bridge Add the line: net.link.ether.bridge.enable=1 to /etc/sysctl.conf to enable the bridge at runtime, and the line: net.link.ether.bridge.config=if1,if2 to enable bridging on the specified interfaces (replace if1 and if2 with the names of your two network interfaces). If you want the bridged packets to be filtered by &man.ipfw.8;, you should add: net.link.ether.bridge.ipfw=1 as well. For versions prior to &os; 5.2-RELEASE, use instead the following lines: net.link.ether.bridge=1 net.link.ether.bridge_cfg=if1,if2 net.link.ether.bridge_ipfw=1 Other Information If you want to be able to &man.ssh.1; into the bridge from the network, it is correct to assign one of the network cards an IP address. The consensus is that assigning both cards an address is a bad idea. If you have multiple bridges on your network, there cannot be more than one path between any two workstations. Technically, this means that there is no support for spanning tree link management. A bridge can add latency to your &man.ping.8; times, especially for traffic from one segment to another. Jean-François Dockès Updated by Alex Dupre Reorganized and enhanced by Diskless Operation diskless workstation diskless operation A FreeBSD machine can boot over the network and operate without a local disk, using file systems mounted from an NFS server. No system modification is necessary, beyond standard configuration files. Such a system is relatively easy to set up because all the necessary elements are readily available: There are at least two possible methods to load the kernel over the network: PXE: The &intel; Preboot eXecution Environment system is a form of smart boot ROM built into some networking cards or motherboards. See &man.pxeboot.8; for more details. The Etherboot port (net/etherboot) produces ROM-able code to boot kernels over the network. The code can be either burnt into a boot PROM on a network card, or loaded from a local floppy (or hard) disk drive, or from a running &ms-dos; system. Many network cards are supported. A sample script (/usr/share/examples/diskless/clone_root) eases the creation and maintenance of the workstation's root file system on the server. The script will probably require a little customization but it will get you started very quickly. Standard system startup files exist in /etc to detect and support a diskless system startup. Swapping, if needed, can be done either to an NFS file or to a local disk. There are many ways to set up diskless workstations. Many elements are involved, and most can be customized to suit local taste. The following will describe variations on the setup of a complete system, emphasizing simplicity and compatibility with the standard FreeBSD startup scripts. The system described has the following characteristics: The diskless workstations use a shared read-only / file system, and a shared read-only /usr. The root file system is a copy of a standard FreeBSD root (typically the server's), with some configuration files overridden by ones specific to diskless operation or, possibly, to the workstation they belong to. The parts of the root which have to be writable are overlaid with &man.md.4; file systems. Any changes will be lost when the system reboots. The kernel is transferred and loaded either with Etherboot or PXE as some situations may mandate the use of either method. As described, this system is insecure. It should live in a protected area of a network, and be untrusted by other hosts. All the information in this section has been tested using &os; 5.2.1-RELEASE. Background Information Setting up diskless workstations is both relatively straightforward and prone to errors. These are sometimes difficult to diagnose for a number of reasons. For example: Compile time options may determine different behaviors at runtime. Error messages are often cryptic or totally absent. In this context, having some knowledge of the background mechanisms involved is very useful to solve the problems that may arise. Several operations need to be performed for a successful bootstrap: The machine needs to obtain initial parameters such as its IP address, executable filename, server name, root path. This is done using the DHCP or BOOTP protocols. DHCP is a compatible extension of BOOTP, and uses the same port numbers and basic packet format. It is possible to configure a system to use only BOOTP. The &man.bootpd.8; server program is included in the base &os; system. However, DHCP has a number of advantages over BOOTP (nicer configuration files, possibility of using PXE, plus many others not directly related to diskless operation), and we will describe mainly a DHCP configuration, with equivalent examples using &man.bootpd.8; when possible. The sample configuration will use the ISC DHCP software package (release 3.0.1.r12 was installed on the test server). The machine needs to transfer one or several programs to local memory. Either TFTP or NFS are used. The choice between TFTP and NFS is a compile time option in several places. A common source of error is to specify filenames for the wrong protocol: TFTP typically transfers all files from a single directory on the server, and would expect filenames relative to this directory. NFS needs absolute file paths. The possible intermediate bootstrap programs and the kernel need to be initialized and executed. There are several important variations in this area: PXE will load &man.pxeboot.8;, which is a modified version of the &os; third stage loader. The &man.loader.8; will obtain most parameters necessary to system startup, and leave them in the kernel environment before transferring control. It is possible to use a GENERIC kernel in this case. Etherboot, will directly load the kernel, with less preparation. You will need to build a kernel with specific options. PXE and Etherboot work equally well; however, because kernels normally let the &man.loader.8; do more work for them, PXE is the preferred method. If your BIOS and network cards support PXE, you should probably use it. Finally, the machine needs to access its file systems. NFS is used in all cases. See also &man.diskless.8; manual page. Setup Instructions Configuration Using <application>ISC DHCP</application> DHCP diskless operation The ISC DHCP server can answer both BOOTP and DHCP requests. ISC DHCP 3.0 is not part of the base system. You will first need to install the net/isc-dhcp3-server port or the corresponding package. Once ISC DHCP is installed, it needs a configuration file to run, (normally named /usr/local/etc/dhcpd.conf). Here follows a commented example, where host margaux uses Etherboot and host corbieres uses PXE: default-lease-time 600; max-lease-time 7200; authoritative; option domain-name "example.com"; option domain-name-servers 192.168.4.1; option routers 192.168.4.1; subnet 192.168.4.0 netmask 255.255.255.0 { use-host-decl-names on; option subnet-mask 255.255.255.0; option broadcast-address 192.168.4.255; host margaux { hardware ethernet 01:23:45:67:89:ab; fixed-address margaux.example.com; next-server 192.168.4.4; filename "/data/misc/kernel.diskless"; option root-path "192.168.4.4:/data/misc/diskless"; } host corbieres { hardware ethernet 00:02:b3:27:62:df; fixed-address corbieres.example.com; next-server 192.168.4.4; filename "pxeboot"; option root-path "192.168.4.4:/data/misc/diskless"; } } This option tells dhcpd to send the value in the host declarations as the hostname for the diskless host. An alternate way would be to add an option host-name margaux inside the host declarations. The next-server directive designates the TFTP or NFS server to use for loading loader or kernel file (the default is to use the same host as the DHCP server). The filename directive defines the file that Etherboot or PXE will load for the next execution step. It must be specified according to the transfer method used. Etherboot can be compiled to use NFS or TFTP. The &os; port configures NFS by default. PXE uses TFTP, which is why a relative filename is used here (this may depend on the TFTP server configuration, but would be fairly typical). Also, PXE loads pxeboot, not the kernel. There are other interesting possibilities, like loading pxeboot from a &os; CD-ROM /boot directory (as &man.pxeboot.8; can load a GENERIC kernel, this makes it possible to use PXE to boot from a remote CD-ROM). The root-path option defines the path to the root file system, in usual NFS notation. When using PXE, it is possible to leave off the host's IP as long as you do not enable the kernel option BOOTP. The NFS server will then be the same as the TFTP one. Configuration Using BOOTP BOOTP diskless operation Here follows an equivalent bootpd configuration (reduced to one client). This would be found in /etc/bootptab. Please note that Etherboot must be compiled with the non-default option NO_DHCP_SUPPORT in order to use BOOTP, and that PXE needs DHCP. The only obvious advantage of bootpd is that it exists in the base system. .def100:\ :hn:ht=1:sa=192.168.4.4:vm=rfc1048:\ :sm=255.255.255.0:\ :ds=192.168.4.1:\ :gw=192.168.4.1:\ :hd="/tftpboot":\ :bf="/kernel.diskless":\ :rp="192.168.4.4:/data/misc/diskless": margaux:ha=0123456789ab:tc=.def100 Preparing a Boot Program with <application>Etherboot</application> Etherboot Etherboot's Web site contains extensive documentation mainly intended for Linux systems, but nonetheless containing useful information. The following will just outline how you would use Etherboot on a FreeBSD system. You must first install the net/etherboot package or port. You can change the Etherboot configuration (i.e. to use TFTP instead of NFS) by editing the Config file in the Etherboot source directory. For our setup, we shall use a boot floppy. For other methods (PROM, or &ms-dos; program), please refer to the Etherboot documentation. To make a boot floppy, insert a floppy in the drive on the machine where you installed Etherboot, then change your current directory to the src directory in the Etherboot tree and type: &prompt.root; gmake bin32/devicetype.fd0 devicetype depends on the type of the Ethernet card in the diskless workstation. Refer to the NIC file in the same directory to determine the right devicetype. Booting with <acronym>PXE</acronym> By default, the &man.pxeboot.8; loader loads the kernel via NFS. It can be compiled to use TFTP instead by specifying the LOADER_TFTP_SUPPORT option in /etc/make.conf. See the comments in /usr/share/examples/etc/make.conf for instructions. There are two other undocumented make.conf options which may be useful for setting up a serial console diskless machine: BOOT_PXELDR_PROBE_KEYBOARD, and BOOT_PXELDR_ALWAYS_SERIAL. To use PXE when the machine starts, you will usually need to select the Boot from network option in your BIOS setup, or type a function key during the PC initialization. Configuring the <acronym>TFTP</acronym> and <acronym>NFS</acronym> Servers TFTP diskless operation NFS diskless operation If you are using PXE or Etherboot configured to use TFTP, you need to enable tftpd on the file server: Create a directory from which tftpd will serve the files, e.g. /tftpboot. Add this line to your /etc/inetd.conf: tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /tftpboot It appears that at least some PXE versions want the TCP version of TFTP. In this case, add a second line, replacing dgram udp with stream tcp. Tell inetd to reread its configuration file. The must be in the /etc/rc.conf file for this command to execute correctly: &prompt.root; /etc/rc.d/inetd restart You can place the tftpboot directory anywhere on the server. Make sure that the location is set in both inetd.conf and dhcpd.conf. In all cases, you also need to enable NFS and export the appropriate file system on the NFS server. Add this to /etc/rc.conf: nfs_server_enable="YES" Export the file system where the diskless root directory is located by adding the following to /etc/exports (adjust the volume mount point and replace margaux corbieres with the names of the diskless workstations): /data/misc -alldirs -ro margaux corbieres Tell mountd to reread its configuration file. If you actually needed to enable NFS in /etc/rc.conf at the first step, you probably want to reboot instead. &prompt.root; /etc/rc.d/mountd restart Building a Diskless Kernel diskless operation kernel configuration If using Etherboot, you need to create a kernel configuration file for the diskless client with the following options (in addition to the usual ones): options BOOTP # Use BOOTP to obtain IP address/hostname options BOOTP_NFSROOT # NFS mount root file system using BOOTP info You may also want to use BOOTP_NFSV3, BOOT_COMPAT and BOOTP_WIRED_TO (refer to NOTES). These option names are historical and slightly misleading as they actually enable indifferent use of DHCP and BOOTP inside the kernel (it is also possible to force strict BOOTP or DHCP use). Build the kernel (see ), and copy it to the place specified in dhcpd.conf. When using PXE, building a kernel with the above options is not strictly necessary (though suggested). Enabling them will cause more DHCP requests to be issued during kernel startup, with a small risk of inconsistency between the new values and those retrieved by &man.pxeboot.8; in some special cases. The advantage of using them is that the host name will be set as a side effect. Otherwise you will need to set the host name by another method, for example in a client-specific rc.conf file. In order to be loadable with Etherboot, a kernel needs to have the device hints compiled in. You would typically set the following option in the configuration file (see the NOTES configuration comments file): hints "GENERIC.hints" Preparing the Root Filesystem root file system diskless operation You need to create a root file system for the diskless workstations, in the location listed as root-path in dhcpd.conf. Using <command>make world</command> to populate root This method is quick and will install a complete virgin system (not only the root file system) into DESTDIR. All you have to do is simply execute the following script: #!/bin/sh export DESTDIR=/data/misc/diskless mkdir -p ${DESTDIR} cd /usr/src; make buildworld && make buildkernel cd /usr/src/etc; make distribution Once done, you may need to customize your /etc/rc.conf and /etc/fstab placed into DESTDIR according to your needs. Configuring Swap If needed, a swap file located on the server can be accessed via NFS. <acronym>NFS</acronym> Swap The kernel does not support enabling NFS swap at boot time. Swap must be enabled by the startup scripts, by mounting a writable file system and creating and enabling a swap file. To create a swap file of appropriate size, you can do like this: &prompt.root; dd if=/dev/zero of=/path/to/swapfile bs=1k count=1 oseek=100000 To enable it you have to add the following line to your rc.conf: swapfile=/path/to/swapfile Miscellaneous Issues Running with a Read-only <filename>/usr</filename> diskless operation /usr read-only If the diskless workstation is configured to run X, you will have to adjust the XDM configuration file, which puts the error log on /usr by default. Using a Non-FreeBSD Server When the server for the root file system is not running FreeBSD, you will have to create the root file system on a FreeBSD machine, then copy it to its destination, using tar or cpio. In this situation, there are sometimes problems with the special files in /dev, due to differing major/minor integer sizes. A solution to this problem is to export a directory from the non-FreeBSD server, mount this directory onto a FreeBSD machine, and use &man.devfs.5; to allocate device nodes transparently for the user. ISDN ISDN A good resource for information on ISDN technology and hardware is Dan Kegel's ISDN Page. A quick simple road map to ISDN follows: If you live in Europe you might want to investigate the ISDN card section. If you are planning to use ISDN primarily to connect to the Internet with an Internet Provider on a dial-up non-dedicated basis, you might look into Terminal Adapters. This will give you the most flexibility, with the fewest problems, if you change providers. If you are connecting two LANs together, or connecting to the Internet with a dedicated ISDN connection, you might consider the stand alone router/bridge option. Cost is a significant factor in determining what solution you will choose. The following options are listed from least expensive to most expensive. Hellmuth Michaelis Contributed by ISDN Cards ISDN cards FreeBSD's ISDN implementation supports only the DSS1/Q.931 (or Euro-ISDN) standard using passive cards. Some active cards are supported where the firmware also supports other signaling protocols; this also includes the first supported Primary Rate (PRI) ISDN card. The isdn4bsd software allows you to connect to other ISDN routers using either IP over raw HDLC or by using synchronous PPP: either by using kernel PPP with isppp, a modified &man.sppp.4; driver, or by using userland &man.ppp.8;. By using userland &man.ppp.8;, channel bonding of two or more ISDN B-channels is possible. A telephone answering machine application is also available as well as many utilities such as a software 300 Baud modem. Some growing number of PC ISDN cards are supported under FreeBSD and the reports show that it is successfully used all over Europe and in many other parts of the world. The passive ISDN cards supported are mostly the ones with the Infineon (formerly Siemens) ISAC/HSCX/IPAC ISDN chipsets, but also ISDN cards with chips from Cologne Chip (ISA bus only), PCI cards with Winbond W6692 chips, some cards with the Tiger300/320/ISAC chipset combinations and some vendor specific chipset based cards such as the AVM Fritz!Card PCI V.1.0 and the AVM Fritz!Card PnP. Currently the active supported ISDN cards are the AVM B1 (ISA and PCI) BRI cards and the AVM T1 PCI PRI cards. For documentation on isdn4bsd, have a look at /usr/share/examples/isdn/ directory on your FreeBSD system or at the homepage of isdn4bsd which also has pointers to hints, erratas and much more documentation such as the isdn4bsd handbook. In case you are interested in adding support for a different ISDN protocol, a currently unsupported ISDN PC card or otherwise enhancing isdn4bsd, please get in touch with &a.hm;. For questions regarding the installation, configuration and troubleshooting isdn4bsd, a &a.isdn.name; mailing list is available. ISDN Terminal Adapters Terminal adapters (TA), are to ISDN what modems are to regular phone lines. modem Most TA's use the standard Hayes modem AT command set, and can be used as a drop in replacement for a modem. A TA will operate basically the same as a modem except connection and throughput speeds will be much faster than your old modem. You will need to configure PPP exactly the same as for a modem setup. Make sure you set your serial speed as high as possible. PPP The main advantage of using a TA to connect to an Internet Provider is that you can do Dynamic PPP. As IP address space becomes more and more scarce, most providers are not willing to provide you with a static IP anymore. Most stand-alone routers are not able to accommodate dynamic IP allocation. TA's completely rely on the PPP daemon that you are running for their features and stability of connection. This allows you to upgrade easily from using a modem to ISDN on a FreeBSD machine, if you already have PPP set up. However, at the same time any problems you experienced with the PPP program and are going to persist. If you want maximum stability, use the kernel PPP option, not the userland PPP. The following TA's are known to work with FreeBSD: Motorola BitSurfer and Bitsurfer Pro Adtran Most other TA's will probably work as well, TA vendors try to make sure their product can accept most of the standard modem AT command set. The real problem with external TA's is that, like modems, you need a good serial card in your computer. You should read the FreeBSD Serial Hardware tutorial for a detailed understanding of serial devices, and the differences between asynchronous and synchronous serial ports. A TA running off a standard PC serial port (asynchronous) limits you to 115.2 Kbs, even though you have a 128 Kbs connection. To fully utilize the 128 Kbs that ISDN is capable of, you must move the TA to a synchronous serial card. Do not be fooled into buying an internal TA and thinking you have avoided the synchronous/asynchronous issue. Internal TA's simply have a standard PC serial port chip built into them. All this will do is save you having to buy another serial cable and find another empty electrical socket. A synchronous card with a TA is at least as fast as a stand-alone router, and with a simple 386 FreeBSD box driving it, probably more flexible. The choice of synchronous card/TA v.s. stand-alone router is largely a religious issue. There has been some discussion of this in the mailing lists. We suggest you search the archives for the complete discussion. Stand-alone ISDN Bridges/Routers ISDN stand-alone bridges/routers ISDN bridges or routers are not at all specific to FreeBSD or any other operating system. For a more complete description of routing and bridging technology, please refer to a networking reference book. In the context of this section, the terms router and bridge will be used interchangeably. As the cost of low end ISDN routers/bridges comes down, it will likely become a more and more popular choice. An ISDN router is a small box that plugs directly into your local Ethernet network, and manages its own connection to the other bridge/router. It has built in software to communicate via PPP and other popular protocols. A router will allow you much faster throughput than a standard TA, since it will be using a full synchronous ISDN connection. The main problem with ISDN routers and bridges is that interoperability between manufacturers can still be a problem. If you are planning to connect to an Internet provider, you should discuss your needs with them. If you are planning to connect two LAN segments together, such as your home LAN to the office LAN, this is the simplest lowest maintenance solution. Since you are buying the equipment for both sides of the connection you can be assured that the link will work. For example to connect a home computer or branch office network to a head office network the following setup could be used: Branch Office or Home Network 10 base 2 Network uses a bus based topology with 10 base 2 Ethernet (thinnet). Connect router to network cable with AUI/10BT transceiver, if necessary. ---Sun workstation | ---FreeBSD box | ---Windows 95 | Stand-alone router | ISDN BRI line 10 Base 2 Ethernet If your home/branch office is only one computer you can use a twisted pair crossover cable to connect to the stand-alone router directly. Head Office or Other LAN 10 base T Network uses a star topology with 10 base T Ethernet (Twisted Pair). -------Novell Server | H | | ---Sun | | | U ---FreeBSD | | | ---Windows 95 | B | |___---Stand-alone router | ISDN BRI line ISDN Network Diagram One large advantage of most routers/bridges is that they allow you to have 2 separate independent PPP connections to 2 separate sites at the same time. This is not supported on most TA's, except for specific (usually expensive) models that have two serial ports. Do not confuse this with channel bonding, MPP, etc. This can be a very useful feature if, for example, you have an dedicated ISDN connection at your office and would like to tap into it, but do not want to get another ISDN line at work. A router at the office location can manage a dedicated B channel connection (64 Kbps) to the Internet and use the other B channel for a separate data connection. The second B channel can be used for dial-in, dial-out or dynamically bonding (MPP, etc.) with the first B channel for more bandwidth. IPX/SPX An Ethernet bridge will also allow you to transmit more than just IP traffic. You can also send IPX/SPX or whatever other protocols you use. Chern Lee Contributed by Network Address Translation Overview natd FreeBSD's Network Address Translation daemon, commonly known as &man.natd.8; is a daemon that accepts incoming raw IP packets, changes the source to the local machine and re-injects these packets back into the outgoing IP packet stream. &man.natd.8; does this by changing the source IP address and port such that when data is received back, it is able to determine the original location of the data and forward it back to its original requester. Internet connection sharing NAT The most common use of NAT is to perform what is commonly known as Internet Connection Sharing. Setup Due to the diminishing IP space in IPv4, and the increased number of users on high-speed consumer lines such as cable or DSL, people are increasingly in need of an Internet Connection Sharing solution. The ability to connect several computers online through one connection and IP address makes &man.natd.8; a reasonable choice. Most commonly, a user has a machine connected to a cable or DSL line with one IP address and wishes to use this one connected computer to provide Internet access to several more over a LAN. To do this, the FreeBSD machine on the Internet must act as a gateway. This gateway machine must have two NICs—one for connecting to the Internet router, the other connecting to a LAN. All the machines on the LAN are connected through a hub or switch. There are many ways to get a LAN connected to the Internet through a &os; gateway. This example will only cover a gateway with at least two NICs. _______ __________ ________ | | | | | | | Hub |-----| Client B |-----| Router |----- Internet |_______| |__________| |________| | ____|_____ | | | Client A | |__________| Network Layout A setup like this is commonly used to share an Internet connection. One of the LAN machines is connected to the Internet. The rest of the machines access the Internet through that gateway machine. kernel configuration Configuration NAT configuration entails only a short series of commands: kldload ipfw kldload ipdivert sysctl net.inet.ip.forwarding=1 natd -dynamic -n fxp0 ipfw add divert natd ip4 from any to any via fxp0 ipfw add allow ip from any to any Additionally, at choice, support may be compiled into the kernel: options IPFIREWALL options IPDIVERT options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_VERBOSE The following must be in /etc/rc.conf: gateway_enable="YES" firewall_enable="YES" firewall_type="OPEN" natd_enable="YES" natd_interface="fxp0" natd_flags="" Sets up the machine to act as a gateway. Running sysctl net.inet.ip.forwarding=1 would have the same effect. Enables the firewall rules in /etc/rc.firewall at boot. This specifies a predefined firewall ruleset that allows anything in. See /etc/rc.firewall for additional types. Indicates which interface to forward packets through (the interface connected to the Internet). Any additional configuration options passed to &man.natd.8; on boot. Having the previous options defined in /etc/rc.conf would run natd -interface fxp0 at boot. This can also be run manually. It is also possible to use a configuration file for &man.natd.8; when there are too many options to pass. In this case, the configuration file must be defined by adding the following line to /etc/rc.conf: natd_flags="-f /etc/natd.conf" The /etc/natd.conf file will contain a list of configuration options, one per line. For example the next section case would use the following file: redirect_port tcp 192.168.0.2:6667 6667 redirect_port tcp 192.168.0.3:80 80 For more information about the configuration file, consult the &man.natd.8; manual page about the option. Each machine and interface behind the LAN should be assigned IP address numbers in the private network space as defined by RFC 1918 and have a default gateway of the natd machine's internal IP address. For example, client A and B behind the LAN have IP addresses of 192.168.0.2 and 192.168.0.3, while the natd machine's LAN interface has an IP address of 192.168.0.1. Client A and B's default gateway must be set to that of the natd machine, 192.168.0.1. The natd machine's external, or Internet interface does not require any special modification for &man.natd.8; to work. Port Redirection The drawback with &man.natd.8; is that the LAN clients are not accessible from the Internet. Clients on the LAN can make outgoing connections to the world but cannot receive incoming ones. This presents a problem if trying to run Internet services on one of the LAN client machines. A simple way around this is to redirect selected Internet ports on the natd machine to a LAN client. For example, an IRC server runs on client A, and a web server runs on client B. For this to work properly, connections received on ports 6667 (IRC) and 80 (web) must be redirected to the respective machines. The must be passed to &man.natd.8; with the proper options. The syntax is as follows: -redirect_port proto targetIP:targetPORT[-targetPORT] [aliasIP:]aliasPORT[-aliasPORT] [remoteIP[:remotePORT[-remotePORT]]] In the above example, the argument should be: -redirect_port tcp 192.168.0.2:6667 6667 -redirect_port tcp 192.168.0.3:80 80 This will redirect the proper tcp ports to the LAN client machines. The argument can be used to indicate port ranges over individual ports. For example, tcp 192.168.0.2:2000-3000 2000-3000 would redirect all connections received on ports 2000 to 3000 to ports 2000 to 3000 on client A. These options can be used when directly running &man.natd.8;, placed within the natd_flags="" option in /etc/rc.conf, or passed via a configuration file. For further configuration options, consult &man.natd.8; Address Redirection address redirection Address redirection is useful if several IP addresses are available, yet they must be on one machine. With this, &man.natd.8; can assign each LAN client its own external IP address. &man.natd.8; then rewrites outgoing packets from the LAN clients with the proper external IP address and redirects all traffic incoming on that particular IP address back to the specific LAN client. This is also known as static NAT. For example, the IP addresses 128.1.1.1, 128.1.1.2, and 128.1.1.3 belong to the natd gateway machine. 128.1.1.1 can be used as the natd gateway machine's external IP address, while 128.1.1.2 and 128.1.1.3 are forwarded back to LAN clients A and B. The syntax is as follows: -redirect_address localIP publicIP localIP The internal IP address of the LAN client. publicIP The external IP address corresponding to the LAN client. In the example, this argument would read: -redirect_address 192.168.0.2 128.1.1.2 -redirect_address 192.168.0.3 128.1.1.3 Like , these arguments are also placed within the natd_flags="" option of /etc/rc.conf, or passed via a configuration file. With address redirection, there is no need for port redirection since all data received on a particular IP address is redirected. The external IP addresses on the natd machine must be active and aliased to the external interface. Look at &man.rc.conf.5; to do so. Parallel Line IP (PLIP) PLIP Parallel Line IP PLIP PLIP lets us run TCP/IP between parallel ports. It is useful on machines without network cards, or to install on laptops. In this section, we will discuss: Creating a parallel (laplink) cable. Connecting two computers with PLIP. Creating a Parallel Cable You can purchase a parallel cable at most computer supply stores. If you cannot do that, or you just want to know how it is done, the following table shows how to make one out of a normal parallel printer cable. Wiring a Parallel Cable for Networking A-name A-End B-End Descr. Post/Bit DATA0 -ERROR 2 15 15 2 Data 0/0x01 1/0x08 DATA1 +SLCT 3 13 13 3 Data 0/0x02 1/0x10 DATA2 +PE 4 12 12 4 Data 0/0x04 1/0x20 DATA3 -ACK 5 10 10 5 Strobe 0/0x08 1/0x40 DATA4 BUSY 6 11 11 6 Data 0/0x10 1/0x80 GND 18-25 18-25 GND -
Setting Up PLIP First, you have to get a laplink cable. Then, confirm that both computers have a kernel with &man.lpt.4; driver support: &prompt.root; grep lp /var/run/dmesg.boot lpt0: <Printer> on ppbus0 lpt0: Interrupt-driven port The parallel port must be an interrupt driven port, you should have a line similar to the following in your in the /boot/device.hints file: hint.ppc.0.at="isa" hint.ppc.0.irq="7" Then check if the kernel configuration file has a device plip line or if the plip.ko kernel module is loaded. In both cases the parallel networking interface should appear when you use the &man.ifconfig.8; command to display it: &prompt.root; ifconfig plip0 plip0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500 Plug the laplink cable into the parallel interface on both computers. Configure the network interface parameters on both sites as root. For example, if you want to connect the host host1 with another machine host2: host1 <-----> host2 IP Address 10.0.0.1 10.0.0.2 Configure the interface on host1 by doing: &prompt.root; ifconfig plip0 10.0.0.1 10.0.0.2 Configure the interface on host2 by doing: &prompt.root; ifconfig plip0 10.0.0.2 10.0.0.1 You now should have a working connection. Please read the manual pages &man.lp.4; and &man.lpt.4; for more details. You should also add both hosts to /etc/hosts: 127.0.0.1 localhost.my.domain localhost 10.0.0.1 host1.my.domain host1 10.0.0.2 host2.my.domain To confirm the connection works, go to each host and ping the other. For example, on host1: &prompt.root; ifconfig plip0 plip0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 10.0.0.1 --> 10.0.0.2 netmask 0xff000000 &prompt.root; netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire host2 host1 UH 0 0 plip0 &prompt.root; ping -c 4 host2 PING host2 (10.0.0.2): 56 data bytes 64 bytes from 10.0.0.2: icmp_seq=0 ttl=255 time=2.774 ms 64 bytes from 10.0.0.2: icmp_seq=1 ttl=255 time=2.530 ms 64 bytes from 10.0.0.2: icmp_seq=2 ttl=255 time=2.556 ms 64 bytes from 10.0.0.2: icmp_seq=3 ttl=255 time=2.714 ms --- host2 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms Aaron Kaplan Originally Written by Tom Rhodes Restructured and Added by Brad Davis Extended by IPv6 IPv6 (also know as IPng IP next generation) is the new version of the well known IP protocol (also know as IPv4). Like the other current *BSD systems, FreeBSD includes the KAME IPv6 reference implementation. So your FreeBSD system comes with all you will need to experiment with IPv6. This section focuses on getting IPv6 configured and running. In the early 1990s, people became aware of the rapidly diminishing address space of IPv4. Given the expansion rate of the Internet there were two major concerns: Running out of addresses. Today this is not so much of a concern anymore since RFC1918 private address space (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16) and Network Address Translation (NAT) are being employed. Router table entries were getting too large. This is still a concern today. IPv6 deals with these and many other issues: 128 bit address space. In other words theoretically there are 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses available. This means there are approximately 6.67 * 10^27 IPv6 addresses per square meter on our planet. Routers will only store network aggregation addresses in their routing tables thus reducing the average space of a routing table to 8192 entries. There are also lots of other useful features of IPv6 such as: Address autoconfiguration (RFC2462) Anycast addresses (one-out-of many) Mandatory multicast addresses IPsec (IP security) Simplified header structure Mobile IP IPv6-to-IPv4 transition mechanisms For more information see: IPv6 overview at playground.sun.com KAME.net 6bone.net Background on IPv6 Addresses There are different types of IPv6 addresses: Unicast, Anycast and Multicast. Unicast addresses are the well known addresses. A packet sent to a unicast address arrives exactly at the interface belonging to the address. Anycast addresses are syntactically indistinguishable from unicast addresses but they address a group of interfaces. The packet destined for an anycast address will arrive at the nearest (in router metric) interface. Anycast addresses may only be used by routers. Multicast addresses identify a group of interfaces. A packet destined for a multicast address will arrive at all interfaces belonging to the multicast group. The IPv4 broadcast address (usually xxx.xxx.xxx.255) is expressed by multicast addresses in IPv6. Reserved IPv6 addresses IPv6 address Prefixlength (Bits) Description Notes :: 128 bits unspecified cf. 0.0.0.0 in IPv4 ::1 128 bits loopback address cf. 127.0.0.1 in IPv4 ::00:xx:xx:xx:xx 96 bits embedded IPv4 The lower 32 bits are the IPv4 address. Also called IPv4 compatible IPv6 address ::ff:xx:xx:xx:xx 96 bits IPv4 mapped IPv6 address The lower 32 bits are the IPv4 address. For hosts which do not support IPv6. fe80:: - feb:: 10 bits link-local cf. loopback address in IPv4 fec0:: - fef:: 10 bits site-local   ff:: 8 bits multicast   001 (base 2) 3 bits global unicast All global unicast addresses are assigned from this pool. The first 3 bits are 001.
Reading IPv6 Addresses The canonical form is represented as: x:x:x:x:x:x:x:x, each x being a 16 Bit hex value. For example FEBC:A574:382B:23C1:AA49:4592:4EFE:9982 Often an address will have long substrings of all zeros therefore one such substring per address can be abbreviated by ::. Also up to three leading 0s per hexquad can be omitted. For example fe80::1 corresponds to the canonical form fe80:0000:0000:0000:0000:0000:0000:0001. A third form is to write the last 32 Bit part in the well known (decimal) IPv4 style with dots . as separators. For example 2002::10.0.0.1 corresponds to the (hexadecimal) canonical representation 2002:0000:0000:0000:0000:0000:0a00:0001 which in turn is equivalent to writing 2002::a00:1. By now the reader should be able to understand the following: &prompt.root; ifconfig rl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 inet 10.0.0.10 netmask 0xffffff00 broadcast 10.0.0.255 inet6 fe80::200:21ff:fe03:8e1%rl0 prefixlen 64 scopeid 0x1 ether 00:00:21:03:08:e1 media: Ethernet autoselect (100baseTX ) status: active fe80::200:21ff:fe03:8e1%rl0 is an auto configured link-local address. It is generated from the MAC address as part of the auto configuration. For further information on the structure of IPv6 addresses see RFC3513. Getting Connected Currently there are four ways to connect to other IPv6 hosts and networks: Join the experimental 6bone Getting an IPv6 network from your upstream provider. Talk to your Internet provider for instructions. Tunnel via 6-to-4 (RFC3068) Use the net/freenet6 port if you are on a dial-up connection. Here we will talk on how to connect to the 6bone since it currently seems to be the most popular way. First take a look at the 6bone site and find a 6bone connection nearest to you. Write to the responsible person and with a little bit of luck you will be given instructions on how to set up your connection. Usually this involves setting up a GRE (gif) tunnel. Here is a typical example on setting up a &man.gif.4; tunnel: &prompt.root; ifconfig gif0 create &prompt.root; ifconfig gif0 gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 &prompt.root; ifconfig gif0 tunnel MY_IPv4_ADDR MY_IPv4_REMOTE_TUNNEL_ENDPOINT_ADDR &prompt.root; ifconfig gif0 inet6 alias MY_ASSIGNED_IPv6_TUNNEL_ENDPOINT_ADDR MY_IPv6_REMOTE_TUNNEL_ENDPOINT_ADDR Replace the capitalized words by the information you received from the upstream 6bone node. This establishes the tunnel. Check if the tunnel is working by &man.ping6.8; 'ing ff02::1%gif0. You should receive two ping replies. In case you are intrigued by the address ff02:1%gif0, this is a multicast address. %gif0 states that the multicast address at network interface gif0 is to be used. Since we ping a multicast address the other endpoint of the tunnel should reply as well. By now setting up a route to your 6bone uplink should be rather straightforward: &prompt.root; route add -inet6 default -interface gif0 &prompt.root; ping6 -n MY_UPLINK &prompt.root; traceroute6 www.jp.FreeBSD.org (3ffe:505:2008:1:2a0:24ff:fe57:e561) from 3ffe:8060:100::40:2, 30 hops max, 12 byte packets 1 atnet-meta6 14.147 ms 15.499 ms 24.319 ms 2 6bone-gw2-ATNET-NT.ipv6.tilab.com 103.408 ms 95.072 ms * 3 3ffe:1831:0:ffff::4 138.645 ms 134.437 ms 144.257 ms 4 3ffe:1810:0:6:290:27ff:fe79:7677 282.975 ms 278.666 ms 292.811 ms 5 3ffe:1800:0:ff00::4 400.131 ms 396.324 ms 394.769 ms 6 3ffe:1800:0:3:290:27ff:fe14:cdee 394.712 ms 397.19 ms 394.102 ms This output will differ from machine to machine. By now you should be able to reach the IPv6 site www.kame.net and see the dancing tortoise — that is if you have a IPv6 enabled browser such as www/mozilla, Konqueror, which is part of x11/kdebase3, or www/epiphany. DNS in the IPv6 World There used to be two types of DNS records for IPv6. The IETF has declared A6 records obsolete. AAAA records are the standard now. Using AAAA records is straightforward. Assign your hostname to the new IPv6 address you just received by adding: MYHOSTNAME AAAA MYIPv6ADDR To your primary zone DNS file. In case you do not serve your own DNS zones ask your DNS provider. Current versions of bind (version 8.3 and 9) and dns/djbdns (with the IPv6 patch) support AAAA records. Applying the needed changes to <filename>/etc/rc.conf</filename> IPv6 Client Settings These settings will help you configure a machine that will be on your LAN and act as a client, not a router. To have &man.rtsol.8; autoconfigure your interface on boot all you need to add is: ipv6_enable="YES" To statically assign an IP address such as 2001:471:1f11:251:290:27ff:fee0:2093, to your fxp0 interface, add: ipv6_ifconfig_fxp0="2001:471:1f11:251:290:27ff:fee0:2093" To assign a default router of 2001:471:1f11:251::1 add the following to /etc/rc.conf: ipv6_defaultrouter="2001:471:1f11:251::1" IPv6 Router/Gateway Settings This will help you take the directions that your tunnel provider, such as the 6bone, has given you and convert it into settings that will persist through reboots. To restore your tunnel on startup use something like the following in /etc/rc.conf: List the Generic Tunneling interfaces that will be configured, for example gif0: gif_interfaces="gif0" To configure the interface with a local endpoint of MY_IPv4_ADDR to a remote endpoint of REMOTE_IPv4_ADDR: gifconfig_gif0="MY_IPv4_ADDR REMOTE_IPv4_ADDR" To apply the IPv6 address you have been assigned for use as your IPv6 tunnel endpoint, add: ipv6_ifconfig_gif0="MY_ASSIGNED_IPv6_TUNNEL_ENDPOINT_ADDR" Then all you have to do is set the default route for IPv6. This is the other side of the IPv6 tunnel: ipv6_defaultrouter="MY_IPv6_REMOTE_TUNNEL_ENDPOINT_ADDR" IPv6 Tunnel Settings If the server is to route IPv6 between the rest of your network and the world, the following /etc/rc.conf setting will also be needed: ipv6_gateway_enable="YES" Router Advertisement and Host Auto Configuration This section will help you setup &man.rtadvd.8; to advertise the IPv6 default route. To enable &man.rtadvd.8; you will need the following in your /etc/rc.conf: rtadvd_enable="YES" It is important that you specify the interface on which to do IPv6 router solicitation. For example to tell &man.rtadvd.8; to use fxp0: rtadvd_interfaces="fxp0" Now we must create the configuration file, /etc/rtadvd.conf. Here is an example: fxp0:\ :addrs#1:addr="2001:471:1f11:246::":prefixlen#64:tc=ether: Replace fxp0 with the interface you are going to be using. Next, replace 2001:471:1f11:246:: with the prefix of your allocation. If you are dedicated a /64 subnet you will not need to change anything else. Otherwise, you will need to change the prefixlen# to the correct value. Harti Brandt Contributed by Asynchronous Transfer Mode (ATM) Configuring classical IP over ATM (PVCs) Classical IP over ATM (CLIP) is the simplest method to use Asynchronous Transfer Mode (ATM) with IP. It can be used with switched connections (SVCs) and with permanent connections (PVCs). This section describes how to set up a network based on PVCs. Fully meshed configurations The first method to set up a CLIP with PVCs is to connect each machine to each other machine in the network via a dedicated PVC. While this is simple to configure it tends to become impractical for a larger number of machines. The example supposes that we have four machines in the network, each connected to the ATM network with an ATM adapter card. The first step is the planning of the IP addresses and the ATM connections between the machines. We use the following: Host IP Address hostA 192.168.173.1 hostB 192.168.173.2 hostC 192.168.173.3 hostD 192.168.173.4 To build a fully meshed net we need one ATM connection between each pair of machines: Machines VPI.VCI couple hostA - hostB 0.100 hostA - hostC 0.101 hostA - hostD 0.102 hostB - hostC 0.103 hostB - hostD 0.104 hostC - hostD 0.105 The VPI and VCI values at each end of the connection may of course differ, but for simplicity we assume that they are the same. Next we need to configure the ATM interfaces on each host: hostA&prompt.root; ifconfig hatm0 192.168.173.1 up hostB&prompt.root; ifconfig hatm0 192.168.173.2 up hostC&prompt.root; ifconfig hatm0 192.168.173.3 up hostD&prompt.root; ifconfig hatm0 192.168.173.4 up assuming that the ATM interface is hatm0 on all hosts. Now the PVCs need to be configured on hostA (we assume that they are already configured on the ATM switches, you need to consult the manual for the switch on how to do this). hostA&prompt.root; atmconfig natm add 192.168.173.2 hatm0 0 100 llc/snap ubr hostA&prompt.root; atmconfig natm add 192.168.173.3 hatm0 0 101 llc/snap ubr hostA&prompt.root; atmconfig natm add 192.168.173.4 hatm0 0 102 llc/snap ubr hostB&prompt.root; atmconfig natm add 192.168.173.1 hatm0 0 100 llc/snap ubr hostB&prompt.root; atmconfig natm add 192.168.173.3 hatm0 0 103 llc/snap ubr hostB&prompt.root; atmconfig natm add 192.168.173.4 hatm0 0 104 llc/snap ubr hostC&prompt.root; atmconfig natm add 192.168.173.1 hatm0 0 101 llc/snap ubr hostC&prompt.root; atmconfig natm add 192.168.173.2 hatm0 0 103 llc/snap ubr hostC&prompt.root; atmconfig natm add 192.168.173.4 hatm0 0 105 llc/snap ubr hostD&prompt.root; atmconfig natm add 192.168.173.1 hatm0 0 102 llc/snap ubr hostD&prompt.root; atmconfig natm add 192.168.173.2 hatm0 0 104 llc/snap ubr hostD&prompt.root; atmconfig natm add 192.168.173.3 hatm0 0 105 llc/snap ubr Of course other traffic contracts than UBR can be used given the ATM adapter supports those. In this case the name of the traffic contract is followed by the parameters of the traffic. Help for the &man.atmconfig.8; tool can be obtained with: &prompt.root; atmconfig help natm add or in the &man.atmconfig.8; manual page. The same configuration can also be done via /etc/rc.conf. For hostA this would look like: network_interfaces="lo0 hatm0" ifconfig_hatm0="inet 192.168.173.1 up" natm_static_routes="hostB hostC hostD" route_hostB="192.168.173.2 hatm0 0 100 llc/snap ubr" route_hostC="192.168.173.3 hatm0 0 101 llc/snap ubr" route_hostD="192.168.173.4 hatm0 0 102 llc/snap ubr" The current state of all CLIP routes can be obtained with: hostA&prompt.root; atmconfig natm show --- chapter.sgml ends here --- >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-doc@FreeBSD.ORG Sat Jun 17 09:30:16 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F9D016A474 for ; Sat, 17 Jun 2006 09:30:16 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B9C943D48 for ; Sat, 17 Jun 2006 09:30:15 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k5H9UF0r070881 for ; Sat, 17 Jun 2006 09:30:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k5H9UFe7070880; Sat, 17 Jun 2006 09:30:15 GMT (envelope-from gnats) Resent-Date: Sat, 17 Jun 2006 09:30:15 GMT Resent-Message-Id: <200606170930.k5H9UFe7070880@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, chinsan Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3961016A479; Sat, 17 Jun 2006 09:26:16 +0000 (UTC) (envelope-from chinsan.tw@gmail.com) Received: from smtp2.bc.hgc.com.tw (smtp2.bc.hgc.com.tw [203.133.1.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5E0743D45; Sat, 17 Jun 2006 09:26:15 +0000 (GMT) (envelope-from chinsan.tw@gmail.com) Received: from smtp2.bc.hgc.com.tw (u14-109.u203-187.giga.net.tw [203.187.14.109]) by smtp2.bc.hgc.com.tw (Postfix) with SMTP id C81D22FFEC; Sat, 17 Jun 2006 17:26:11 +0800 (CST) Received: by smtp2.bc.hgc.com.tw (sSMTP sendmail emulation); Sat, 17 Jun 2006 17:27:37 +0800 Message-Id: <20060617092615.C81D22FFEC@smtp2.bc.hgc.com.tw> Date: Sat, 17 Jun 2006 17:27:37 +0800 From: chinsan To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: vanilla@FreeBSD.org Subject: docs/99074: [UPDATE] zh_TW.Big5: update to 20060617-svn#617 X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: chinsan List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 09:30:16 -0000 >Number: 99074 >Category: docs >Synopsis: [UPDATE] zh_TW.Big5: update to 20060617-svn#617 >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: update >Submitter-Id: current-users >Arrival-Date: Sat Jun 17 09:30:15 GMT 2006 >Closed-Date: >Last-Modified: >Originator: chinsan >Release: FreeBSD 6.1-STABLE i386 >Organization: FreeBSD Taiwan >Environment: System: FreeBSD chinsan2.twbbs.org 6.1-STABLE FreeBSD 6.1-STABLE #1: Fri Jun 2 16:44:35 CST 2006 root@chinsan2.twbbs.org:/usr/obj/usr/src/sys/GENERIC i386 >Description: - Update to 200606170-SVN #617 (http://OpenSVN.csie.org/freebsddoc) - Generated by chinsan, psilotum, tzhuan, whsyu >How-To-Repeat: >Fix: Please fetch http://chinsan2.twbbs.org/chinsan/freebsddoc-tw-20060617-svn617-snap.diff SIZE (freebsddoc-tw-20060617-svn617-snap.diff) = 3741076 MD5 (freebsddoc-tw-20060617-svn617-snap.diff) = 92c602af5480b11ff9d958b9ada9461a >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-doc@FreeBSD.ORG Sat Jun 17 09:58:11 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 798B116A474; Sat, 17 Jun 2006 09:58:11 +0000 (UTC) (envelope-from vanilla@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B61E43D49; Sat, 17 Jun 2006 09:58:11 +0000 (GMT) (envelope-from vanilla@FreeBSD.org) Received: from freefall.freebsd.org (vanilla@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k5H9wATI073532; Sat, 17 Jun 2006 09:58:10 GMT (envelope-from vanilla@freefall.freebsd.org) Received: (from vanilla@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k5H9wAgA073528; Sat, 17 Jun 2006 09:58:10 GMT (envelope-from vanilla) Date: Sat, 17 Jun 2006 09:58:10 GMT From: "Vanilla I. Shu" Message-Id: <200606170958.k5H9wAgA073528@freefall.freebsd.org> To: vanilla@FreeBSD.org, freebsd-doc@FreeBSD.org, vanilla@FreeBSD.org Cc: Subject: Re: docs/99074: [UPDATE] zh_TW.Big5: update to 20060617-svn#617 X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 09:58:11 -0000 Synopsis: [UPDATE] zh_TW.Big5: update to 20060617-svn#617 Responsible-Changed-From-To: freebsd-doc->vanilla Responsible-Changed-By: vanilla Responsible-Changed-When: Sat Jun 17 09:57:57 UTC 2006 Responsible-Changed-Why: I will handle this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=99074 From owner-freebsd-doc@FreeBSD.ORG Sat Jun 17 12:39:09 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6193016A581; Sat, 17 Jun 2006 12:39:09 +0000 (UTC) (envelope-from maxim@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 122B043D45; Sat, 17 Jun 2006 12:39:09 +0000 (GMT) (envelope-from maxim@FreeBSD.org) Received: from freefall.freebsd.org (maxim@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k5HCd8OK083890; Sat, 17 Jun 2006 12:39:08 GMT (envelope-from maxim@freefall.freebsd.org) Received: (from maxim@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k5HCd8F9083886; Sat, 17 Jun 2006 12:39:08 GMT (envelope-from maxim) Date: Sat, 17 Jun 2006 12:39:08 GMT From: Maxim Konovalov Message-Id: <200606171239.k5HCd8F9083886@freefall.freebsd.org> To: solinym@gmail.com, maxim@FreeBSD.org, freebsd-doc@FreeBSD.org Cc: Subject: Re: docs/98340: vinum(4) refers to vinum(8) which does not exist X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 12:39:09 -0000 Synopsis: vinum(4) refers to vinum(8) which does not exist State-Changed-From-To: patched->closed State-Changed-By: maxim State-Changed-When: Sat Jun 17 12:38:55 UTC 2006 State-Changed-Why: Merged to RELENG_6. http://www.freebsd.org/cgi/query-pr.cgi?pr=98340 From owner-freebsd-doc@FreeBSD.ORG Sat Jun 17 20:10:21 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D6A116A47D for ; Sat, 17 Jun 2006 20:10:21 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7988C43D45 for ; Sat, 17 Jun 2006 20:10:20 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k5HKAKfV009641 for ; Sat, 17 Jun 2006 20:10:20 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k5HKAKCI009637; Sat, 17 Jun 2006 20:10:20 GMT (envelope-from gnats) Resent-Date: Sat, 17 Jun 2006 20:10:20 GMT Resent-Message-Id: <200606172010.k5HKAKCI009637@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, David Wolfskill Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8796716A474; Sat, 17 Jun 2006 20:04:38 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id C058D43D48; Sat, 17 Jun 2006 20:04:37 +0000 (GMT) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id k5HK4a49050163; Sat, 17 Jun 2006 13:04:36 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.1/Submit) id k5HK4aQN050162; Sat, 17 Jun 2006 13:04:36 -0700 (PDT) (envelope-from david) Message-Id: <200606172004.k5HK4aQN050162@bunrab.catwhisker.org> Date: Sat, 17 Jun 2006 13:04:36 -0700 (PDT) From: David Wolfskill To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: gnn@FreeBSD.org Subject: docs/99084: doc update for new mailing list freebsd-embedded X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Wolfskill List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2006 20:10:21 -0000 >Number: 99084 >Category: docs >Synopsis: doc update for new mailing list freebsd-embedded >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: update >Submitter-Id: current-users >Arrival-Date: Sat Jun 17 20:10:19 GMT 2006 >Closed-Date: >Last-Modified: >Originator: David Wolfskill >Release: n/a >Organization: Wolfskill & Dowling Residence >Environment: System: FreeBSD g1-18.catwhisker.org. 6.1-STABLE FreeBSD 6.1-STABLE #97: Sat Jun 17 06:57:05 PDT 2006 root@g1-18.catwhisker.org.:/common/S1/obj/usr/src/sys/LAPTOP_30W i386 >Description: New mailing list freebsd-embedded created; this PR updates docs accordingly. Note: it is not yet clear what the fate of the freebsd-small list will be, now that this list is created. >How-To-Repeat: Note discrepancy between mailing lists shown at (e.g.) vs. those shown at . >Fix: Index: en_US.ISO8859-1/books/handbook/eresources/chapter.sgml =================================================================== RCS file: /cvs/freebsd/doc/en_US.ISO8859-1/books/handbook/eresources/chapter.sgml,v retrieving revision 1.175 diff -u -r1.175 chapter.sgml --- en_US.ISO8859-1/books/handbook/eresources/chapter.sgml 23 Nov 2005 20:10:30 -0000 1.175 +++ en_US.ISO8859-1/books/handbook/eresources/chapter.sgml 17 Jun 2006 19:58:23 -0000 @@ -260,6 +260,11 @@ + &a.embedded.name; + Using FreeBSD in embedded applications + + + &a.emulation.name; Emulation of other systems such as Linux/&ms-dos;/&windows; @@ -960,6 +965,19 @@ + &a.embedded.name; + + + Using FreeBSD in embedded + applications + + This list discusses topics related to unusually small and + embedded FreeBSD installations. This is a technical mailing + list for which strictly technical content is expected. + + + + &a.emulation.name; Index: en_US.ISO8859-1/share/sgml/mailing-lists.ent =================================================================== RCS file: /cvs/freebsd/doc/en_US.ISO8859-1/share/sgml/mailing-lists.ent,v retrieving revision 1.50 diff -u -r1.50 mailing-lists.ent --- en_US.ISO8859-1/share/sgml/mailing-lists.ent 24 Nov 2005 16:29:44 -0000 1.50 +++ en_US.ISO8859-1/share/sgml/mailing-lists.ent 17 Jun 2006 19:56:06 -0000 @@ -159,6 +159,10 @@ FreeBSD users of Eclipse IDE, tools, rich client applications and ports"> freebsd-eclipse"> + +FreeBSD-embedded mailing list"> +freebsd-embedded"> + FreeBSD-emulation mailing list"> freebsd-emulation"> >Release-Note: >Audit-Trail: >Unformatted: