diff --git a/handbook/booting.sgml b/handbook/booting.sgml index 8440579baf..3c887d564e 100644 --- a/handbook/booting.sgml +++ b/handbook/booting.sgml @@ -1,175 +1,170 @@ The FreeBSD Booting Process

Contributed by &a.phk;. v1.1, April 26th. Booting FreeBSD is essentially a three step: Load the kernel, determine the root filesystem and initialize user-land things. This leads to some interesting possibilities shown below. - Loading a kernel + Loading a kernel

- We presently have three basic mechanisms for loading the kernel: - - biosboot - dosboot - netboot - - Each will be described in detail below. They all pass some + We presently have three basic mechanisms for loading the + kernel as described below: + They all pass some information to the kernel to help the kernel decide what to do next. - Biosboot -

+ + Biosboot + Biosboot is our ``bootblocks'', it consists of two files, which will be installed in the first 8Kbytes of the floppy or hard-disk slice to be booted from. Biosboot can load a kernel from a FreeBSD filesystem. - Dosboot -

+ Dosboot + Dosboot was written by DI. Christian Gusenbauer, and is unfortunately at this time one of the few pieces of code that isn't compilable under FreeBSD itself because it is written for MicroSoft compilers. Dosboot will boot the kernel from a MS-DOS file or from a FreeBSD filesystem partition on the disk. It attempts to negotiate with the various and strange kinds of memory manglers that lurk in high memory on MS/DOS systems and usually wins them for it's case. - Netboot -

+ Netboot + Netboot will try to find a supported ethernet card, and use BOOTP, TFTP and NFS to find a kernel file to boot. + - Determine the root filesystem + + Determine the root filesystem

Once the kernel is loaded and the boot-code jumps to it, the kernel will initialize itself, trying to determine what hardware is present and so on, and then it needs to find a root filesystem. Presently we support the following types of rootfilesystems: - - UFS - MSDOS - MFS - CD9660 - NFS - - - UFS -

+ + + UFS + This is the most normal type of root filesystem. It can reside on a floppy or on harddisk. - MSDOS -

+ MSDOS + While this is technically possible, it isn't particular useful, because of ``FAT'' filesystems inability to make links, device nodes and such ``UNIXisms''. - MFS -

+ MFS + This is actually a UFS filesystem which has been compiled into the kernel. That means that the kernel does not really need any disks/floppies or other HW to function. - CD9660 -

+ CD9660 + This is for using a CD-ROM as root filesystem. - NFS -

+ NFS + This is for using a fileserver as root filesystem, basically making it a diskless machine. + + - Initialize user-land things + Initialize user-land things

To get the user-land going, when the kernel has finished initialization, it will create a with ``/sbin/init''. You can substitute any program for /sbin/init, as long as you keep in mind that: there is no stdin/out/err unless you open it yourself, if you exit, the machine panics signal handling is special for ``Interesting combinations + Interesting combinations

Boot a kernel with a MFS in it with a special /sbin/init which... mounts your /C: Attaches C:/freebsd.fs on /dev/vn0 mounts /dev/vn0 as /rootfs makes symlinks /rootfs/bin -> /bin /rootfs/etc -> /etc /rootfs/sbin -> /sbin ... Now you run FreeBSD without repartitioning your hard disk... server:˜you/FreeBSD as /nfs, chroots to /nfs and executes /sbin/init there Now you run FreeBSD diskless, even though you don't control the NFS server... /dev/rwd0 and writes it to a remote tape station or fileserver. Now you finally got that backup you should have made a year ago... E -- Acts as a firewall/web-server/what do I know... This is particular interesting since you can boot from a write- protected floppy, but still write to your root filesystem... diff --git a/handbook/contrib.sgml b/handbook/contrib.sgml index 8fb0a937da..a671ce896c 100644 --- a/handbook/contrib.sgml +++ b/handbook/contrib.sgml @@ -1,299 +1,299 @@ - + -FreeBSD contributor list

This software was originally derived from William F. Jolitz's 386BSD release 0.1, though almost none of the original 386BSD specific code remains. This software has been essentially reimplemented from the 4.4 BSD Lite release provided by the Computer Science Research Group (CSRG) at the University of California, Berkeley and associated academic contributors. There are also portions of NetBSD that have been integrated into FreeBSD as well, and we would therefore like to thank all the contributors to NetBSD for their work. Despite some occasionally rocky moments in relations between the two groups, we both want essentially the same thing: More BSD based operating systems on people's computers! We wish the NetBSD group every success in their endevors. - Hardware contributors + Hardware contributors

A special thank-you to Walnut Creek CDROM for providing the Pentium P5-90 and 486/DX2-66 EISA/VL systems that are being used for our development work, to say nothing of the network access and other donations of hardware resources. It would have been impossible to do this release without their support. TRW Financial Systems, Inc. provided 130 PCs, three 68 GB fileservers, twelve ethernets, two routers and an ATM switch for debugging the diskless code. They also keep a couple of FreeBSD hackers alive and busy. Thanks! Thanks also to Dermot McDonnell for his donation of a Toshiba XM3401B CDROM drive. It's been most useful! Thanks to Chuck Robey <chuckr@eng.umd.edu> who's been contributing his floppy tape streamer for experimental work. - The FreeBSD core team

(in alphabetical order by first name): Andrey A. Chernov <ache@FreeBSD.org> Bruce Evans <bde@FreeBSD.org> David Greenman <davidg@FreeBSD.org> Garrett A. Wollman <wollman@FreeBSD.org> Gary Palmer <gpalmer@FreeBSD.org> Jörg Wunsch <joerg@FreeBSD.org> John Dyson <dyson@FreeBSD.org> Jordan K. Hubbard <jkh@FreeBSD.org> Justin Gibbs <gibbs@FreeBSD.org> Paul Richards <paul@FreeBSD.org> Poul-Henning Kamp <phk@FreeBSD.org> Rich Murphey <rich@FreeBSD.org> Rodney W. Grimes <rgrimes@FreeBSD.org> Satoshi Asami <asami@FreeBSD.org> Søren Schmidt <sos@FreeBSD.org> - Who is responsible for what + Who is responsible for what

- Additional FreeBSD contributors + Additional FreeBSD contributors

(in alphabetical order by first name): Adam David <adam@veda.is> Adam Glass <glass@postgres.berkeley.edu> Akito Fujita <fujita@zoo.ncl.omron.co.jp> Alain Kalker <alain@Wit401402.student.utwente.nl> Andreas Klemm <andreas@knobel.GUN.de> Andrew Herbert <andrew@werple.apana.org.au> Andrew Moore <alm@FreeBSD.org> Anthony Yee-Hang Chan <yeehang@netcom.com> Atsushi Murai <amurai@spec.co.jp> Bill Fenner <fenner@parc.xerox.com> Bill Paul <wpaul@FreeBSD.org> Bob Wilcox <bob@obiwan.uucp> Brian Tao <taob@gate.sinica.edu.tw> Charles Hannum <mycroft@ai.mit.edu> Chris G. Demetriou <cgd@postgres.berkeley.edu> Chris Provenzano <proven@athena.mit.edu> Chris Stenton <jacs@gnome.co.uk> Chris Torek <torek@ee.lbl.gov> Christian Gusenbauer <cg@fimp01.fim.uni-linz.ac.at> Christoph Robitschko <chmr@edvz.tu-graz.ac.at> Chuck Robey <chuckr@Glue.umd.edu> Cornelis van der Laan <nils@guru.ims.uni-stuttgart.de> Craig Struble <cstruble@vt.edu> Curt Mayer <curt@toad.com> Danny J. Zerkel <dzerkel@feephi.phofarm.com> Dave Burgess <burgess@hrd769.brooks.af.mil> Dave Chapeskie <dchapes@ale.zeus.leitch.com> Dave Rivers <rivers@ponds.uucp> David Dawes <dawes@physics.su.OZ.AU> Dean Huxley <dean@fsa.ca> Don Whiteside <dwhite@anshar.shadow.net> Eric L. Hernes <erich@lodgenet.com> Frank Durda IV <bsdmail@nemesis.lonestar.org> Frank Maclachlan <fpm@crash.cts.com> Frank Nobis <fn@trinity.radio-do.de> Gary A. Browning <gab10@griffcd.amdahl.com> Gary Clark II <gclarkii@FreeBSD.ORG> Gary Jennejohn <gj%pcs.dec.com@inet-gw-1.pa.dec.com> Gene Stark <stark@cs.sunysb.edu> Guido van Rooij <guido@gvr.win.tue.nl> Havard Eidnes <Havard.Eidnes@runit.sintef.no> Holger Veit <Holger.Veit@gmd.de> Ishii Masahiro, R. Kym Horsell J.T. Conklin <jtc@winsey.com> James Clark <jjc@jclark.com> James da Silva <jds@cs.umd.edu> et al Janusz Kokot <janek@gaja.ipan.lublin.pl> Javier Martin Rueda <jmrueda@diatel.upm.es> Jim Wilson <wilson@moria.cygnus.com> Jonathan Bresler < jmb@FreeBSD.ORG> Josh MacDonald <jmacd@uclink.berkeley.edu> Julian Elischer <julian@dialix.oz.au> Julian Stacey <stacey@guug.de> (fallback: <julian@meepmeep.pcs.com>) Keith Bostic <bostic@toe.CS.Berkeley.EDU> Keith Moore <?> Kirk McKusick <mckusick@mckusick.com> Kurt Olsen <kurto@tiny.mcs.usu.edu> L Jonas Olsson <ljo@po.cwru.edu> Lars Fredriksen <fredriks@mcs.com> Lucas James <Lucas.James@ldjpc.apana.org.au> Marc Frajola <marc@escargot.rain.com> Marc Ramirez <mrami@mramirez.sy.yale.edu Marc van Kempen <wmbfmk@urc.tue.nl> Mark Murray <mark@grondar.za> Mark Tinguely <tinguely@plains.nodak.edu> <tinguely@hookie.cs.ndsu.NoDak.edu> Martin Birgmeier Martin Renters <martin@innovus.com> Matt Thomas <thomas@lkg.dec.com> Michael Smith <msmith@atrad.adelaide.edu.au> Mike Pritchard <mpp@mpp.minn.net> NIIMI Satoshi <sa2c@and.or.jp> Nate Williams <nate@FreeBSD.org> Nobuhiro Yasutomi <nobu@psrc.isac.co.jp> Nobuyuki Koganemaru <kogane@kces.koganemaru.co.jp> Ollivier Robert <roberto@FreeBSD.org> Paul Kranenburg <pk@cs.few.eur.nl> Paul Mackerras <paulus@cs.anu.edu.au> Paul Traina <pst@cisco.com> Peter Dufault <dufault@hda.com> Peter Wemm <peter@haywire.DIALix.COM> Philippe Charnier <charnier@lirmm.fr> Richard Stallman <rms@gnu.ai.mit.edu> Rob Shady <rls@id.net> Rob Snow <rsnow@txdirect.net> Sascha Wildner <swildner@channelz.GUN.de> Scott Mace <smace@FreeBSD.org> Sean Eric Fagan <sef@kithrup.com> Serge V. Vakulenko <vak@zebub.msk.su> Stefan Esser <se@MI.Uni-Koeln.DE> Stephen McKay <syssgm@devetir.qld.gov.au> Steve Gerakines <steve2@genesis.tiac.net> Steven Wallace <swallace@ece.uci.edu> Tatsumi Hosokawa <hosokawa@mt.cs.keio.ac.jp> Terry Lee <terry@uivlsi.csl.uiuc.edu> Theo Deraadt <deraadt@fsa.ca> Thomas Gellekum <thomas@ghpc8.ihf.rwth-aachen.de> Tom Samplonius <tom@misery.sdf.com> Torbjorn Granlund <tege@matematik.su.se> Torsten Blum <torstenb@FreeBSD.ORG> Ugen J.S.Antsilevich <ugen@NetVision.net.il> Werner Griessl <werner@btp1da.phy.uni-bayreuth.de> Wolfgang Stanglmeier <wolf@kintaro.cologne.de> Wolfram Schneider <wosch@cs.tu-berlin.de> Yuval Yarom <yval@cs.huji.ac.il> Yves Fonk <yves@cpcoup5.tn.tudelft.nl> - 386BSD Patch kit patch contributors + 386BSD Patch kit patch contributors

(in alphabetical order by first name): Adam Glass <glass@postgres.berkeley.edu> Adrian Hall <adrian@ibmpcug.co.uk> Andrey A. Chernov <ache@astral.msk.su> Andrew Herbert <andrew@werple.apana.org.au> Andrew Moore <alm@netcom.com> Andy Valencia <ajv@csd.mot.com> <jtk@netcom.com> Arne Henrik Juul <arnej@Lise.Unit.NO> Bakul Shah <bvs@bitblocks.com> Barry Lustig <barry@ictv.com> Bob Wilcox <bob@obiwan.uucp> Branko Lankester Brett Lymn <blymn@mulga.awadi.com.AU> Charles Hannum <mycroft@ai.mit.edu> Chris G. Demetriou <cgd@postgres.berkeley.edu> Chris Torek <torek@ee.lbl.gov> Christoph Robitschko <chmr@edvz.tu-graz.ac.at> Daniel Poirot <poirot@aio.jsc.nasa.gov> Dave Burgess <burgess@hrd769.brooks.af.mil> Dave Rivers <rivers@ponds.uucp> David Dawes <dawes@physics.su.OZ.AU> David Greenman <davidg@Root.COM> Eric J. Haug <ejh@slustl.slu.edu> Felix Gaehtgens <felix@escape.vsse.in-berlin.de> Frank Maclachlan <fpm@crash.cts.com> Gary A. Browning <gab10@griffcd.amdahl.com> Geoff Rehmet <csgr@alpha.ru.ac.za> Goran Hammarback <goran@astro.uu.se> Guido van Rooij <guido@gvr.win.tue.nl> Guy Harris <guy@auspex.com> Havard Eidnes <Havard.Eidnes@runit.sintef.no> Herb Peyerl <hpeyerl@novatel.cuc.ab.ca Holger Veit <Holger.Veit@gmd.de> Ishii Masahiro, R. Kym Horsell J.T. Conklin <jtc@winsey.com> Jagane D Sundar < jagane@netcom.com > James Clark <jjc@jclark.com> James Jegers <jimj@miller.cs.uwm.edu> James W. Dolter James da Silva <jds@cs.umd.edu> et al Jay Fenlason <hack@datacube.com> Jim Wilson <wilson@moria.cygnus.com> Joerg Lohse <lohse@tech7.informatik.uni-hamburg.de> Jörg Wunsch <joerg_wunsch@uriah.heep.sax.de> John Dyson - <formerly dyson@ref.tfs.com> John Woods <jfw@eddie.mit.edu> Jordan K. Hubbard <jkh@whisker.hubbard.ie> Julian Elischer <julian@dialix.oz.au> Julian Stacey <stacey@guug.de> (fallback: <julian@meepmeep.pcs.com>) Karl Lehenbauer <karl@NeoSoft.com> <karl@one.neosoft.com> Keith Bostic <bostic@toe.CS.Berkeley.EDU> Ken Hughes Kent Talarico <kent@shipwreck.tsoft.net> Kevin Lahey <kml%rokkaku.UUCP@mathcs.emory.edu> <kml@mosquito.cis.ufl.edu> Marc Frajola <marc@escargot.rain.com> Mark Tinguely <tinguely@plains.nodak.edu> <tinguely@hookie.cs.ndsu.NoDak.edu> Martin Renters <martin@innovus.com> Michael Galassi <nerd@percival.rain.com> Mike Durkin <mdurkin@tsoft.sf-bay.org> Nate Williams <nate@bsd.coe.montana.edu> Nick Handel <nhandel@NeoSoft.com> <nick@madhouse.neosoft.com> Pace Willisson <pace@blitz.com> Paul Kranenburg <pk@cs.few.eur.nl> Paul Mackerras <paulus@cs.anu.edu.au> Paul Popelka <paulp@uts.amdahl.com> Peter da Silva <peter@NeoSoft.com> Phil Sutherland <philsuth@mycroft.dialix.oz.au> Ralf Friedl <friedl@informatik.uni-kl.de> Rick Macklem <root@snowhite.cis.uoguelph.ca> Robert D. Thrush <rd@phoenix.aii.com> Rodney W. Grimes <rgrimes@cdrom.com> Rog Egge <?> Sascha Wildner <swildner@channelz.GUN.de> Scott Burris <scott@pita.cns.ucla.edu> Scott Reynolds <scott@clmqt.marquette.mi.us> Sean Eric Fagan <sef@kithrup.com> Simon J Gerraty <sjg@melb.bull.oz.au> <sjg@zen.void.oz.au> Stephen McKay <syssgm@devetir.qld.gov.au> Terry Lambert <terry@icarus.weber.edu> Terry Lee <terry@uivlsi.csl.uiuc.edu> Warren Toomey <wkt@csadfa.cs.adfa.oz.au> Wiljo Heinen <wiljo@freeside.ki.open.de> William Jolitz <withheld> Wolfgang Solfrank <ws@tools.de> Wolfgang Stanglmeier <wolf@dentaro.GUN.de> Yuval Yarom <yval@cs.huji.ac.il> Last, but not least, the release engineer would like to thank: His Wife, for chocolate chip cookies, and some other things. The DGB project @ TFS, for patience and tolerance. diff --git a/handbook/ctm.sgml b/handbook/ctm.sgml index 254eb92c7d..4d84a36695 100644 --- a/handbook/ctm.sgml +++ b/handbook/ctm.sgml @@ -1,195 +1,195 @@ CTM

Contributed by &a.phk;. Updated 16-Mar-1995. Why should I use Why should I use

. - What do I need to use What do I need to use

You will need two things: The ``/usr/src/usr.sbin/). If you are running an older version of FreeBSD, you can fetch the current The ``deltas'' you feed Ftp the the relevant directory and fetch the /etc/aliases if you want. Check the Starting off with Starting off with

Before you can start using Using Using

To apply the deltas, simply say cd /where/ever/you/want/the/stuff ctm -v -v /where/you/store/your/deltas/src-cur.* Future plans for Future plans for

Tons of them: Make local modifications to the tree possible. One way to do it could be this:

When foo/bar.c'', it would first check for the existence of foo/bar.c#CTM If this file exists, the delta is applied to it instead. This way the foo/bar.c file can be edited to suit local needs. Make a ``restore file(s)'' option to ctm -r src/sys/i386/wd.c /here/are/my/deltas/src-cur.* would restore Clean up the options to The bad news is that I am very busy, so any help in doing this will be most welcome. And don't forget to tell me what you want also... - Miscellaneous stuff + Miscellaneous stuff

All the ``DES infected'' (e.g. export controlled) source is not included. You will get the ``international'' version only. If sufficient interest appears, we will set up a ``Thanks! + Thanks!

diff --git a/handbook/dialup.sgml b/handbook/dialup.sgml index f9075ea352..bb87f073be 100644 --- a/handbook/dialup.sgml +++ b/handbook/dialup.sgml @@ -1,809 +1,809 @@ Dialup access

Contributed by &a.ghelmer;. This document provides suggestions for configuring a FreeBSD system to handle dialup modems. This document is written based on the author's experience with FreeBSD versions 1.0, 1.1, and 1.1.5.1 (and experience with dialup modems on other UNIX-like operating systems); however, this document may not answer all of your questions or provide examples specific enough to your environment. The author cannot be responsible if you damage your system or lose data due to attempting to follow the suggestions here. Prerequisites

To begin with, the author assumes you have some basic knowledge of FreeBSD. You need to have FreeBSD installed, know how to edit files in a UNIX-like environment, and how to look up manual pages on the system. As discussed below, you'll need certain versions of FreeBSD, and knowledge of some terminology & modem and cabling. -FreeBSD Version +FreeBSD Version

First, it is assumed that you are using FreeBSD version 1.1 or higher (including versions 2.x). FreeBSD version 1.0 included two different serial drivers, which complicates the situation. Also, the serial device driver (Terminology +Terminology

A quick rundown of terminology: If you need more information about these terms and data communications in general, the author remembers reading that External vs. Internal Modems +External vs. Internal Modems

External modems seem to be more convenient for dialup, because external modems often can be semi-permanently configured via parameters stored in non-volatile RAM and they usually provide lighted indicators that display the state of important RS-232 signals. Blinking lights impress visitors, but lights are also very useful to see whether a modem is operating properly. Internal modems usually lack non-volatile RAM, so their configuration may be limited only to setting DIP switches. If your internal modem has any signal indicator lights, it is probably difficult to view the lights when the system's cover is in place. -Modems and Cables +Modems and Cables

A background knowledge of these items is assumed You know how to connect your modem to your computer so that the two can communicate (unless you have an internal modem, which doesn't need such a cable) You are familiar with your modem's command set, or know where to look up needed commands You know how to configure your modem (probably via a terminal communications program) so you can set the non-volatile RAM parameters The first, connecting your modem, is usually simple - most straight-through serial cables work without any problems. You need to have a cable with appropriate connectors (DB-25 or DB-9, male or female) on each end, and the cable must be a DCE-to-DTE cable with these signals wired: Transmitted Data ( Received Data ( Request to Send ( Clear to Send ( Data Set Ready ( Data Terminal Ready ( Carrier Detect ( Signal Ground ( FreeBSD needs the Serial Interface Considerations +Serial Interface Considerations

FreeBSD supports NS8250-, NS16450-, NS16550-, and NS16550A-based EIA RS-232C (CCITT V.24) communications interfaces. The 8250 and 16450 devices have single-character buffers. The 16550 device provides a 16-character buffer, which allows for better system performance. (Bugs in plain 16550's prevent the use of the 16-character buffer, so use 16550A's if possible). Because single-character-buffer devices require more work by the operating system than the 16-character-buffer devices, 16550A-based serial interface cards are much prefered. If the system has many active serial ports or will have a heavy load, 16550A-based cards are better for low-error-rate communications. -Quick Overview +Quick Overview

Here is the process that FreeBSD follows to accept dialup logins. A /dev/ttyd0, for our example). The command 4850 ?? I 0:00.09 /usr/libexec/getty V19200 ttyd0 When a user dials the modem's line and the modems connect, the /usr/bin/login, which completes the login by asking for the user's password and then starting the user's shell. Let's dive into the configuration... -Kernel Configuration +Kernel Configuration

FreeBSD kernels typically come prepared to search for four serial ports, known in the PC-DOS world as /sbin/dmesg command to replay the kernel's boot messages. In particular, look for messages that start with the characters /usr/sbin/dmesg | grep 'sio' For example, on a system with four serial ports, these are the serial-port specific kernel boot messages: sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2 at 0x3e8-0x3ef irq 5 on isa sio2: type 16550A sio3 at 0x2e8-0x2ef irq 9 on isa sio3: type 16550A If your kernel doesn't recognize all of your serial ports, you'll probably need to configure a custom FreeBSD kernel for your system. Please see the BSD System Manager's Manual chapter on ``Building Berkeley Kernels with Config'' [the source for which is in /usr/src/share/doc/smm] and ``FreeBSD Configuration Options'' [in /sys/doc/options.doc] for more information on configuring and building kernels. You may have to unpack the kernel source distribution if haven't installed the system sources already (srcdist/srcsys.?? in FreeBSD 1.1, srcdist/sys.?? in FreeBSD 1.1.5.1, or the entire source distribution in FreeBSD 2.0) to be able to configure and build kernels. Create a kernel configuration file for your system (if you haven't already) by /sys/i386/conf. Then, if you are creating a new custom configuration file, copy the file GENERICAH (or GENERICBT, if you have a BusTek SCSI controller on FreeBSD 1.x) to device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr device sio2 at isa? port "IO_COM3" tty irq 5 vector siointr device sio3 at isa? port "IO_COM4" tty irq 9 vector siointr You can comment-out or completely remove lines for devices you don't have. If you have a multiport serial board, such as the Boca Board BB2016, please see the can't share interrupts on ISA-bus PCs (multiport boards have on-board electronics that allow all the 16550A's on the board to share one or two interrupt request lines). When you are finished adjusting the kernel configuration file, use the program Device Special Files +Device Special Files

Most devices in the kernel are accessed through ``device special files'', which are located in the /dev directory. The /dev/ttyd? (dial-in) and /dev/cua0? (call-out) devices. On FreeBSD version 1.1.5 and higher, there are also initialization devices (/dev/ttyid? and /dev/cuai0?) and locking devices (/dev/ttyld? and /dev/cual0?). The initialization devices are used to initialize communications port parameters each time a port is opened, such as crtscts for modems which use CTS/RTS signalling for flow control. The locking devices are used to lock flags on ports to prevent users or programs changing certain parameters; see the manual pages Making Device Special Files +Making Device Special Files

A shell script called /dev directory manages the device special files. (The manual page for /dev and issue the command /dev/ttyd? device special files, but also creates the /dev/cua0? (and all of the initializing and locking special files under FreeBSD 1.1.5 and up) and removes the hardwired terminal special file /dev/tty0?, if it exists. After making new device special files, be sure to check the permissions on the files (especially the /dev/cua* files) to make sure that only users who should have access to those device special files can read & write on them - you probably don't want to allow your average user to use your modems to dialout. The default permissions on the /dev/cua* files should be sufficient: crw-rw---- 1 uucp dialer 28, 129 Feb 15 14:38 /dev/cua01 crw-rw---- 1 uucp dialer 28, 161 Feb 15 14:38 /dev/cuai01 crw-rw---- 1 uucp dialer 28, 193 Feb 15 14:38 /dev/cual01 These permissions allow the user Configuration Files +Configuration Files

There are three system configuration files in the /etc directory that you'll probably need to edit to allow dialup access to your FreeBSD system. The first, /etc/gettytab, contains configuration information for the /usr/libexec/getty daemon. Second, /etc/ttys holds information that tells /sbin/init what /etc/rc.serial script if you have FreeBSD 1.1.5.1 or higher; otherwise, you can initialize ports in the /etc/rc.local script. There are two schools of thought regarding dialup modems on UNIX. One group likes to configure their modems and system so that no matter at what speed a remote user dials in, the local computer-to-modem RS-232 interface runs at a locked speed. The benefit of this configuration is that the remote user always sees a system login prompt immediately. The downside is that the system doesn't know what a user's true data rate is, so full-screen programs like Emacs won't adjust their screen-painting methods to make their response better for slower connections. The other school configures their modems' RS-232 interface to vary its speed based on the remote user's connection speed. For example, V.32bis (14.4 Kbps) connections to the modem might make the modem run its RS-232 interface at 19.2 Kbps, while 2400 bps connections make the modem's RS-232 interface run at 2400 bps. Because <Enter> key until they see a recognizable prompt. If the data rates don't match, /etc/gettytab +/etc/gettytab

/etc/gettytab is a Locked-Speed Config +Locked-Speed Config

If you are locking your modem's data communications rate at a particular speed, you probably won't need to make any changes to /etc/gettytab. -Matching-Speed Config +Matching-Speed Config

You'll need to setup an entry in /etc/gettytab to give # # Fast dialup terminals, 2400/1200/300 rotary (can start either way) # D2400|d2400|Fast-Dial-2400:\ :nx=D1200:tc=2400-baud: 3|D1200|Fast-Dial-1200:\ :nx=D300:tc=1200-baud: 5|D300|Fast-Dial-300:\ :nx=D2400:tc=300-baud: If you have a higher speed modem, you'll probably need to add an entry in /etc/gettytab; here's an entry you could use for a 14.4 Kbps modem with a top interface speed of 19.2 Kpbs: # # Additions for a V.32bis Modem # um|V300|High Speed Modem at 300,8-bit:\ :nx=V19200:tc=std.300: un|V1200|High Speed Modem at 1200,8-bit:\ :nx=V300:tc=std.1200: uo|V2400|High Speed Modem at 2400,8-bit:\ :nx=V1200:tc=std.2400: up|V9600|High Speed Modem at 9600,8-bit:\ :nx=V2400:tc=std.9600: uq|V19200|High Speed Modem at 19200,8-bit:\ :nx=V9600:tc=std.19200: On FreeBSD 1.1.5 and later, this will result in 8-bit, no parity connections. Under FreeBSD 1.1, add std. entries at the top of the file for 8 bits, no parity; otherwise, the default is 7 bits, even parity. The example above starts the communications rate at 19.2 Kbps (for a V.32bis connection), then cycles through 9600 bps (for V.32), 2400 bps, 1200 bps, 300 bps, and back to 19.2 Kbps. Communcations rate cycling is implemented with the # # Additions for a V.32bis or V.34 Modem # Starting at 57.6 Kpbs # vm|VH300|Very High Speed Modem at 300,8-bit:\ :nx=VH57600:tc=std.300: vn|VH1200|Very High Speed Modem at 1200,8-bit:\ :nx=VH300:tc=std.1200: vo|VH2400|Very High Speed Modem at 2400,8-bit:\ :nx=VH1200:tc=std.2400: vp|VH9600|Very High Speed Modem at 9600,8-bit:\ :nx=VH2400:tc=std.9600: vq|VH57600|Very High Speed Modem at 57600,8-bit:\ :nx=VH9600:tc=std.57600: If you have a slow CPU or a heavily loaded system and you don't have 16550A-based serial ports, you may receive sio ``silo'' errors at 57.6 Kbps. -/etc/ttys +/etc/ttys

/etc/ttys is the list of /etc/ttys also provides security information to /etc/ttys or add new lines to make ttyd0 "/usr/libexec/getty xxx" dialup on The first item in the above line is the device special file for this entry - /dev/ttyd0 is the file that this "/usr/libexec/getty (secure, but it should only be used for terminals which are physically secure (such as the system console). The default terminal type (/etc/ttys, you may send the kill -1 1 to send the signal. If this is your first time setting up the system, though, you may want to wait until your modem(s) are properly configured and connected before signalling Locked-Speed Config +Locked-Speed Config

For a locked-speed configuration, your ttyd0 "/usr/libexec/getty std.19200" dialup on If your modem is locked at a different data rate, substitute the appropriate name for the std. entry for /etc/gettytab for your modem's data rate. -Matching-Speed Config +Matching-Speed Config

In a matching-speed configuration, your /etc/gettytab. For example, if you added the above suggested entry for a matching-speed modem that starts at 19.2 Kbps (the ttyd0 "/usr/libexec/getty V19200" dialup on -/etc/rc.serial or /etc/rc.local +/etc/rc.serial or /etc/rc.local

High-speed modems, like V.32, V.32bis, and V.34 modems, need to use hardware (RTS/CTS) flow control. You can add /etc/rc.serial on FreeBSD 1.1.5.1 and up, or /etc/rc.local on FreeBSD 1.1, to set the hardware flow control flag in the FreeBSD kernel for the modem ports. For example, on a sample FreeBSD 1.1.5.1 system, /etc/rc.serial reads: #!/bin/sh # # Serial port initial configuration stty -f /dev/ttyid1 crtscts stty -f /dev/cuai01 crtscts which sets the # Set serial ports to use RTS/CTS flow control stty -f /dev/ttyd0 crtscts stty -f /dev/ttyd1 crtscts stty -f /dev/ttyd2 crtscts stty -f /dev/ttyd3 crtscts Since there isn't an initialization device special file on FreeBSD 1.1, one has to just set the flags on the sole device special file and hope the flags aren't cleared by a miscreant. -Modem Settings +Modem Settings

If you have a modem whose parameters may be permanently set in non-volatile RAM, you'll need to use a terminal program (such as Telix under PC-DOS or Disable XON/XOFF flow control Quiet mode (no result codes) No command echo Please read the documentation for your modem to find out what commands and/or DIP switch settings you need to give it. For example, to set the above parameters on a USRobotics Sportster 14,400 external modem, one could give these commands to the modem: ATZ AT&C1&D2&H1&I0&R2&W You might also want to take this opportunity to adjust other settings in the modem, such as whether it will use V.42bis and/or MNP5 compression. The USR Sportster 14,400 external modem also has some DIP switches that need to be set; for other modems, perhaps you can use these settings as an example: Switch 1: UP - DTR Normal Switch 2: Don't care (Verbal Result Codes/Numeric Result Codes) Switch 3: UP - Suppress Result Codes Switch 4: DOWN - No echo, offline commands Switch 5: UP - Auto Answer Switch 6: UP - Carrier Detect Normal Switch 7: UP - Load NVRAM Defaults Switch 8: Don't care (Smart Mode/Dumb Mode) Result codes should be disabled/suppressed for dialup modems to avoid problems that can occur if Locked-speed Config +Locked-speed Config

For a locked-speed configuration, you'll need to configure the modem to maintain a constant modem-to-computer data rate independent of the communications rate. On a USR Sportster 14,400 external modem, these commands will lock the modem-to-computer data rate at the speed used to issue the commands: ATZ AT&B1&W -Matching-speed Config +Matching-speed Config

For a variable-speed configuration, you'll need to configure your modem to adjust its serial port data rate to match the incoming call rate. On a USR Sportster 14,400 external modem, these commands will lock the modem's error-corrected data rate to the speed used to issue the commands, but allow the serial port rate to vary for non-error-corrected connections: ATZ AT&B2&W -Checking the Modem's Configuration +Checking the Modem's Configuration

Most high-speed modems provide commands to view the modem's current operating parameters in a somewhat human-readable fashion. On the USR Sportster 14,400 external modems, the command Troubleshooting +Troubleshooting

Here are a few steps you can follow to check out the dialup modem on your system. -Checking out the FreeBSD system +Checking out the FreeBSD system

Hook up your modem to your FreeBSD system, boot the system, and, if your modem has status indication lights, watch to see whether the modem's 114 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd0 115 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd1 If you see something different, like this: 114 d0 I 0:00.10 /usr/libexec/getty V19200 ttyd0 ^^ and the modem hasn't accepted a call yet, this means that /etc/ttys to see if there are any mistakes there. Also, check the log file /var/log/messages to see if there are any log messages from /etc/ttys and /etc/gettytab, as well as the appropriate device special files /dev/ttyd?, for any mistakes, missing entries, or missing device special files. -Try Dialing In +Try Dialing In

Try dialing into the system; be sure to use 8 bits, no parity, 1 stop bit on the remote system. If you don't get a prompt right away, or get garbage, try pressing <Enter> about once per second. If you still don't see a BREAK. If you are using a high-speed modem to do the dialing, try dialing again after locking the dialing modem's interface speed (via AT&B1 on a USR Sportster, for example). If you still can't get a /etc/gettytab again and double-check that The initial capability name specified in /etc/ttys for the line matches a name of a capability in /etc/gettytab Each Each If you dial but the modem on the FreeBSD system won't answer, make sure that the modem is configured to answer the phone when FreeBSD-Questions@freebsd.org describing your modem and your problem, and the good folks on the list will try to help. -Acknowledgements +Acknowledgements

Thanks to these people for comments and advice: diff --git a/handbook/hw.sgml b/handbook/hw.sgml index 12d07dcf82..ae987b576a 100644 --- a/handbook/hw.sgml +++ b/handbook/hw.sgml @@ -1,319 +1,319 @@ - + PC Hardware compatibility

Issues of hardware compatibility are among the most troublesome in the computer industry today and FreeBSD is by no means immune to trouble. In this respect, FreeBSD's advantage of being able to run on inexpensive commidity PC hardware is also its liability when it comes to support for the amazing variety of components on the market. While it would be impossible to provide a exhaustive listing of hardware that FreeBSD supports, this section serves as a catalog of the device drivers included with FreeBSD and the hardware each drivers supports. Where possible and appropriate, notes about specific products are included. As FreeBSD is a volunteer project without a funded testing department, we depend on you, the user, for much of the information contained in this catalog. If you have direct experience of hardware that does or does not work with FreeBSD, please let us know by sending email to doc@freebsd.org. Questions about supported hardware should be directed to questions@freebsd.org (see for more information). When submitting information or asking a question, please remember to specify exactly what version of FreeBSD you are using and include as many details of your hardware as possible. Core/Processing Motherboards, busses, and chipsets * ISA * EISA * VLB PCI

Contributed by &a.rgrimes;.25 April 1995.

Of the Intel PCI chip sets the following is a list of brokenness from worst to best and a short description of brokenness.

Mercury: Cache coherency problems, especially if there are ISA bus masters behind the ISA to PCI bridge chip. Hardware flaw, only known work around is to turn the cache off. Saturn-I (ie, 82424ZX at rev 0, 1 or 2): write back cache coherency problems. Hardware flaw, only known work around is to set the external cache to write-through mode. Upgrade to Saturn-II. Saturn-II (ie, 82424ZX at rev 3 or 4): Works fine, but many MB manufactures leave out the external dirty bit SRAM needed for write back operation. Work arounds are either run it in write through mode, or get the dirty bit SRAM installed. (I have these for the ASUS PCI/I-486SP3G rev 1.6 and later boards). Neptune: Can not run more than 2 bus master devices. Admitted Intel design flaw. Workarounds include do not run more than 2 bus masters, special hardware design to replace the PCI bus arbiter (appears on Intel Altair board and several other Intel server group MB's). And of course Intel's official answer, move to the Triton chip set, we ``fixed it there''. Triton: No known cache coherency or bus master problems, chip set does not implement parity checking. Workaround for parity issue. Wait for Triton-II. Triton-II: Unknown, not yet shipping.

* CPUs/FPUs * Memory * BIOS Input/Output Devices * Video cards * Sound cards Serial ports and multiport cards

The sio driver provides support for NS8250-, NS16450-, NS16550 and NS16550A-based EIA RS-232C (CCITT V.24) communications interfaces. Several multiport cards are supported as well. See the sio(4) manual page for detailed technical documentation. -Digiboard PC/8 +Digiboard PC/8

Contributed by &a.awebster;.26 August 1995. Here is a config snippet from a machine with digiboard PC/8 with 16550. It has 8 modems connected to these 8 lines, and they work just great. Do not forget to add options "COM_MULTIPORT" or it wo not work very well! device sio4 at isa? port 0x100 tty flags 0xb05 device sio5 at isa? port 0x108 tty flags 0xb05 device sio6 at isa? port 0x110 tty flags 0xb05 device sio7 at isa? port 0x118 tty flags 0xb05 device sio8 at isa? port 0x120 tty flags 0xb05 device sio9 at isa? port 0x128 tty flags 0xb05 device sio10 at isa? port 0x130 tty flags 0xb05 device sio11 at isa? port 0x138 tty flags 0xb05 irq 9 vector siointr The trick in setting this up is that the MSB of the flags represent the last SIO port, in this case 11 so flags are 0xb05. -Boca 16 +Boca 16

Contributed by &a.whiteside;.26 August 1995. The procedures to make a Boca 16 pord board with FreeBSD are pretty straighforward, but you will need a couple things to make it work: You either need the kernel sources installed so you can recompile the necessary options or you will need someone else to compile it for you. The 2.0.5 default kernel does not come with multiport support enabled and you will need to add a device entry for each port anyways. Two, you will need to know the interrupt and IO setting for your Boca Board so you can set these options properly in the kernel. One important note - the actual UART chips for the Boca 16 are in the connector box, not on the internal board itself. So if you have it unplugged, probes of those ports will fail. I have never tested booting with the box unplugged and plugging it back in, and I suggest you do not either. If you do not already have a custom kernel configuration file set up, refer to for general procedurs. The following are the specifics for the Boca 16 board and assume you are using the kernel name MYKERNEL and editing with vi. Add the line options "COM_MULTIPORT" to the config file. Where the current device sio xxx lines are, you will need to add 16 more devices. Only the last device includes the interrupt vector for the board. (See the sio(4) manual page for detail as to why.) The following example is for a Boca Board with an interrupt of 3, and a base IO address 100h. The IO address for Each port is +8 hexidecimal from the previous port, thus the 100h, 108h, 110h... addresses. device sio1 at isa? port 0x100 tty flags 0x1005 device sio2 at isa? port 0x108 tty flags 0x1005 device sio3 at isa? port 0x110 tty flags 0x1005 device sio4 at isa? port 0x118 tty flags 0x1005 ... device sio15 at isa? port 0x170 tty flags 0x1005 device sio16 at isa? port 0x178 tty flags 0x1005 irq 3 vector siointr The flags entry must be changed from this example unless you are using the exact same sio assignments. Flags are set according to 0xMYY where M indicates the minor number of the master port (the last port on a Boca 16) and YY indicates if FIFO is enabled or disabled(enabled), IRQ sharing is used(yes) and if there is an AST/4 compatible IRQ control register(no). In this example, flags 0x1005 indicates that the master port is sio16. If I added another board and assigned sio17 through sio28, the flags for all 16 ports on that board would be 0x1C05, where 1C indicates the minor number of the master port. Do not change the 05 setting. Save and complete the kernel configuration, recompile, install and reboot. Presuming you have successfully installed the recompiled kernel and have it set to the correct address and IRQ, your boot message should indicate the successful probe of the Boca ports as follows: (obviously the sio numbers, IO and IRQ could be different) sio1 at 0x100-0x107 flags 0x1005 on isa sio1: type 16550A (multiport) sio2 at 0x108-0x10f flags 0x1005 on isa sio2: type 16550A (multiport) sio3 at 0x110-0x117 flags 0x1005 on isa sio3: type 16550A (multiport) sio4 at 0x118-0x11f flags 0x1005 on isa sio4: type 16550A (multiport) sio5 at 0x120-0x127 flags 0x1005 on isa sio5: type 16550A (multiport) sio6 at 0x128-0x12f flags 0x1005 on isa sio6: type 16550A (multiport) sio7 at 0x130-0x137 flags 0x1005 on isa sio7: type 16550A (multiport) sio8 at 0x138-0x13f flags 0x1005 on isa sio8: type 16550A (multiport) sio9 at 0x140-0x147 flags 0x1005 on isa sio9: type 16550A (multiport) sio10 at 0x148-0x14f flags 0x1005 on isa sio10: type 16550A (multiport) sio11 at 0x150-0x157 flags 0x1005 on isa sio11: type 16550A (multiport) sio12 at 0x158-0x15f flags 0x1005 on isa sio12: type 16550A (multiport) sio13 at 0x160-0x167 flags 0x1005 on isa sio13: type 16550A (multiport) sio14 at 0x168-0x16f flags 0x1005 on isa sio14: type 16550A (multiport) sio15 at 0x170-0x177 flags 0x1005 on isa sio15: type 16550A (multiport) sio16 at 0x178-0x17f irq 3 flags 0x1005 on isa sio16: type 16550A (multiport master) If the messages go by too fast to see, dmesg > more will show you the boot messages. Next, apprepriate entries in /dev for the devices must be made using the /dev/MAKEDEV script. After becoming root: cd /dev ./MAKEDEV tty1 ./MAKEDEV cua1 .. (everything inbetween) ./MAKEDEV ttyg ./MAKEDEV cuag If you do not want or need callout devices for some reason, you can dispense with making the cua* devices. If you want a quick and sloppy way to make sure the devices are working, you can simply plug a modem into each port and (as root) echo at > ttyd* for each device you have made. You should see the RX lights flash for each working port. * Parallel ports * Modems * Network cards * Keyboards * Mice * Other * Storage Devices * Disk/tape controllers * SCSI * IDE * Floppy * Hard drives * Tape drives * CD-ROM drives * Other * Other * PCMCIA diff --git a/handbook/install.sgml b/handbook/install.sgml index a259525cc9..ba63835ca2 100644 --- a/handbook/install.sgml +++ b/handbook/install.sgml @@ -1,652 +1,652 @@ - + Installing FreeBSD - MS-DOS user's Questions and Answers + MS-DOS user's Questions and Answers

Help! I have no space! Do I need to delete everything first? If your machine is already running MS-DOS and has little or no free space available for FreeBSD's installation, all is not lost! You may find the FIPS utility, provided in the tools directory on the FreeBSD CDROM or on the various FreeBSD ftp sites, to be quite useful. FIPS allows you to split an existing MS-DOS partition into two pieces, preserving the original partition and allowing you to install onto the second free piece. You first defragment your MS-DOS partition, using the DOS 6.xx DEFRAG utility or the Norton Disk tools, then run FIPS. It will prompt you for the rest of the information it needs. Afterwards, you can reboot and install FreeBSD on the new free slice. See the Distributions menu for an estimation of how much free space you'll need for the kind of installation you want. Can I use compressed MS-DOS filesystems from FreeBSD? No. If you are using a utility such as Stacker(tm) or DoubleSpace(tm), FreeBSD will only be able to use whatever portion of the filesystem you leave uncompressed. The rest of the filesystem will show up as one large file (the stacked/dblspaced file!). Do not remove that file! You will probably regret it greatly! It is probably better to create another uncompressed MS-DOS primary partition and use this for communications between MS-DOS and FreeBSD. Can I mount my MS-DOS extended partitions? This feature isn't in FreeBSD 2.0.5 but should be in 2.1. We've laid all the groundwork for making this happen, now we just need to do the last 1 percent of the work involved. Can I run MS-DOS binaries under FreeBSD? Not yet! We'd like to add support for this someday, but are still lacking anyone to actually do the work. Ongoing work with Linux's PCEMU utility may bring this much closer to being a reality sometime soon. Send mail to hackers@freebsd.org if you're interested in joining this effort! - Supported Configurations

FreeBSD currently runs on a wide variety of ISA, VLB, EISA and PCI bus based PC's, ranging from 386sx to Pentium class machines (though the 386sx is not recommended). Support for generic IDE or ESDI drive configurations, various SCSI controller, network and serial cards is also provided. A minimum of four megabytes of RAM is required to run FreeBSD. To run the X-window system, eight megabytes of RAM is the recommended minimum. Following is a list of all disk controllers and ethernet cards currently known to work with FreeBSD. Other configurations may very well work, and we have simply not received any indication of this. - Disk Controllers + Disk Controllers

WD1003 (any generic MFM/RLL) WD1007 (any generic IDE/ESDI) WD7000 IDE ATA Adaptec 152x series ISA SCSI controllers Adaptec 154x series ISA SCSI controllers Adaptec 174x series EISA SCSI controller in standard and enhanced mode. Adaptec 274X/284X/2940 (Narrow/Wide/Twin) series EISA/VLB/PCI SCSI controllers Adaptec AIC-6260 and AIC-6360 based boards, which includes the AHA-152x and SoundBlaster SCSI cards. Note: You cannot boot from the SoundBlaster cards as they have no on-board BIOS, which is necessary for mapping the boot device into the system BIOS I/O vectors. They are perfectly usable for external tapes, CDROMs, etc, however. The same goes for any other AIC-6x60 based card without a boot ROM. Some systems DO have a boot ROM, which is generally indicated by some sort of message when the system is first powered up or reset. Check your system/board documentation for more details. Buslogic 545S & 545c Note: that Buslogic was formerly known as "Bustec". Buslogic 445S/445c VLB SCSI controller Buslogic 742A, 747S, 747c EISA SCSI controller. Buslogic 946c PCI SCSI controller Buslogic 956c PCI SCSI controller NCR 53C810 and 53C825 PCI SCSI controller. NCR5380/NCR53400 ("ProAudio Spectrum") SCSI controller. DTC 3290 EISA SCSI controller in 1542 emulation mode. UltraStor 14F, 24F and 34F SCSI controllers. Seagate ST01/02 SCSI controllers. Future Domain 8xx/950 series SCSI controllers. With all supported SCSI controllers, full support is provided for SCSI-I & SCSI-II peripherals, including Disks, tape drives (including DAT) and CD ROM drives. The following CD-ROM type systems are supported at this time: SCSI (also includes ProAudio Spectrum and SoundBlaster SCSI) (cd) Mitsumi proprietary interface (mcd) Matsushita/Panasonic (Creative) proprietary interface (matcd) Sony proprietary interface (scd) Note: CD-Drives with IDE interfaces are not supported at this time. Some controllers have limitations with the way they deal with >16MB of memory, due to the fact that the ISA bus only has a DMA address space of 24 bits. If you do your arithmetic, you'll see that this makes it impossible to do direct DMA to any address >16MB. This limitation is even true of some EISA controllers (which are normally 32 bit) when they're configured to emulate an ISA card, which they then do in *all* respects. This problem is avoided entirely by IDE controllers (which do not use DMA), true EISA controllers (like the UltraStor, Adaptec 1742A or Adaptec 2742) and most VLB (local bus) controllers. In the cases where it's necessary, the system will use "bounce buffers" to talk to the controller so that you can still use more than 16Mb of memory without difficulty. - Ethernet cards + Ethernet cards

SMC Elite 16 WD8013 ethernet interface, and most other WD8003E, WD8003EBT, WD8003W, WD8013W, WD8003S, WD8003SBT and WD8013EBT based clones. SMC Elite Ultra is also supported. DEC EtherWORKS III NICs (DE203, DE204, and DE205) DEC EtherWORKS II NICs (DE200, DE201, DE202, and DE422) DEC DC21140 based NICs (SMC???? DE???) DEC FDDI (DEFPA/DEFEA) NICs Fujitsu MB86960A family of NICs Intel EtherExpress Isolan AT 4141-0 (16 bit) Isolink 4110 (8 bit) Novell NE1000, NE2000, and NE2100 ethernet interface. 3Com 3C501 cards 3Com 3C503 Etherlink II 3Com 3c505 Etherlink/+ 3Com 3C507 Etherlink 16/TP 3Com 3C509, 3C579, 3C589 (PCMCIA) Etherlink III Toshiba ethernet cards PCMCIA ethernet cards from IBM and National Semiconductor are also supported. - Misc + Miscellaneous devices

AST 4 port serial card using shared IRQ. ARNET 8 port serial card using shared IRQ. BOCA ATIO66 6 port serial card using shared IRQ. Cyclades Cyclom-y Serial Board. STB 4 port card using shared IRQ. Mitsumi (all models) CDROM interface and drive. SDL Communications Riscom/8 Serial Board. Soundblaster SCSI and ProAudio Spectrum SCSI CDROM interface and drive. Matsushita/Panasonic (Creative SoundBlaster) CDROM interface and drive. Adlib, SoundBlaster, SoundBlaster Pro, ProAudioSpectrum, Gravis UltraSound and Roland MPU-401 sound cards. FreeBSD currently does NOT support IBM's microchannel (MCA) bus, but support is apparently close to materializing. Details will be posted as the situation develops. - Preparing for the installation + Preparing for the installation

There are a number of different methods by which FreeBSD can be installed. The following describes what preparation needs to be done for each type. - Before installing from CDROM + Before installing from CDROM

If your CDROM is of an unsupported type, such as an IDE CDROM, then please skip to section 2.3: MS-DOS Preparation. There is not a lot of preparatory work that needs to be done to successfully install from one of Walnut Creek's FreeBSD CDROMs (other CDROM distributions may work as well, but I can't say for sure as I have no hand or say in their creation). You can either boot into the CD installation directly from MS-DOS using Walnut Creek's supplied "install" batch file or you can make a boot floppy by writing the supplied image (floppies/boot.flp) onto a floppy with the "go" command, which invokes the rawrite.exe command found in the tools/ subdirectory. If you're creating the boot floppy from a UNIX machine, you may find that ``dd if=floppies/boot.flp of=/dev/rfd0'' or ``dd if=floppies/boot.flp of=/dev/floppy'' works well, depending on your hardware and operating system environment. Once you've booted from MS-DOS or floppy, you should be able to select CDROM as the media type in the Media menu and load the entire distribution from CDROM. No other types of installation media should be required. After your system is fully installed and you have rebooted from the hard disk, you should find the CD mounted on the directory /cdrom. A utility called `lndir' comes with the XFree86 distribution which you may also find useful: It allows you to create "link tree" directories to things on Read-Only media like CDROM. One example might be something like this: mkdir /usr/portslndir /cdrom/ports /usr/ports Which would allow you to then "cd /usr/ports; make" and get all the sources from the CD, but yet create all the intermediate files in /usr/ports, which is presumably on a more writable media! - Before installing from Floppy + Before installing from Floppy

If you must install from floppy disks, either due to unsupported hardware or just because you enjoy doing things the hard way, you must first prepare some floppies for the install. The first floppy you'll need is ``floppies/root.flp'', which is somewhat special in that it's not a MS-DOS filesystem floppy at all, but rather an "image" floppy (it's actually a gzip'd cpio file). You can use the rawrite.exe program to do this under DOS, or ``dd'' to do it on a UNIX Workstation (see notes in section 2.1 concerning the ``floppies/boot.flp'' image). Once this floppy is made, put it aside. You'll be asked for it later. You will also need, at minimum, as many 1.44MB or 1.2MB floppies as it takes to hold all files in the bin (binary distribution) directory. THESE floppies *must* be formatted using MS-DOS, using with the FORMAT command in MS-DOS or the File Manager format command in Microsoft Windows(tm). Factory preformatted floppies will also work well, provided that they haven't been previously used for something else. Many problems reported by our users in the past have resulted from the use of improperly formatted media, so we simply take special care to mention it here! After you've MS-DOS formatted the floppies, you'll need to copy the files onto them. The distribution files are split into chunks conveniently sized so that 5 of them will fit on a conventional 1.44MB floppy. Go through all your floppies, packing as many files as will fit on each one, until you've got all the distributions you want packed up in this fashion. Select ``Floppy'' from the Media menu at installation time and you will be prompted for everything after that. - Before installing from a MS-DOS partition + Before installing from a MS-DOS partition

To prepare for installation from an MS-DOS partition, copy the files from the distribution into a directory called C:\FREEBSD. The directory tree structure of the CDROM must be partially reproduced within this directory so we suggest using the DOS xcopy command. For example, to prepare for a minimal installation of FreeBSD: C> MD C:\FREEBSD C> XCOPY /S E:\FLOPPIES C:\FREEBSD\FLOPPIES\ C> XCOPY /S E:\DISTS\BIN C:\FREEBSD\BIN\ asssuming that C: is where you have free space and E: is where your CDROM is mounted. Note that you need the FLOPPIES directory because the root.flp image is needed during an MS-DOS installation. For as many `DISTS' you wish to install from MS-DOS (and you have free space for), install each one under C:\FREEBSD - the BIN dist is only the minimal requirement. If you have room on your MS-DOS partition for all the distributions, you could replace the last line above with: C> XCOPY /S E:\DISTS C:\FREEBSD\ which would copy all the subdirectories of E:\DISTS to C:\FREEBSD. - Before installing from QIC/SCSI Tape + Before installing from QIC/SCSI Tape

Installing from tape is probably the easiest method, short of an on-line install using FTP or a CDROM instal. The installation program expects the files to be simply tar'ed onto the tape, so after getting all of the files for distribution you're interested in, simply tar them onto the tape with a command like: cd /freebsd/distdir tar cvf /dev/rwt0 (or /dev/rst0) dist1 .. dist2 Make sure that the `floppies/' directory is one of the "dists" given above, since the installation will look for `floppies/root.flp' on the tape. When you go to do the installation, you should also make sure that you leave enough room in some temporary directory (which you'll be allowed to choose) to accommodate the FULL contents of the tape you've created. Due to the non-random access nature of tapes, this method of installation requires quite a bit of temporary storage! You should expect to require as much temporary storage as you have stuff written on tape. -Before installing over a network +Before installing over a network

You can do network installations over 3 types of communications links: Serial port SLIP or PPP Parallel port PLIP (laplink cable) Ethernet A standard ethernet controller (includes some PCMCIA). SLIP support is rather primitive, and limited primarily to hard-wired links, such as a serial cable running between a laptop computer and another computer. The link should be hard-wired as the SLIP installation doesn't currently offer a dialing capability; that facility is provided with the PPP utility, which should be used in preference to SLIP whenever possible. If you're using a modem, then PPP is almost certainly your only choice. Make sure that you have your service provider's information handy as you'll need to know it fairly soon in the installation process. You will need to know, at the minimum, your service provider's IP address and possibly your own (though you can also leave it blank and allow PPP to negotiate it with your ISP). You also need to know how to use the various "AT commands" to dial the ISP with your particular modem as the PPP dialer provides only a very simple terminal emulator. If a hard-wired connection to another FreeBSD (2.0R or later) machine is available, you might also consider installing over a "laplink" parallel port cable. The data rate over the parallel port is much higher than is what's typically possible over a serial line (up to 50k/sec), thus resulting in a quicker installation. Finally, for the fastest possible network installation, an ethernet adaptor is always a good choice! FreeBSD supports most common PC ethernet cards, a table of supported cards (and their required settings) provided as part of the FreeBSD Hardware Guide - see the Documentation menu on the boot floppy. If you are using one of the supported PCMCIA ethernet cards, also be sure that it's plugged in _before_ the laptop is powered on! FreeBSD does not, unfortunately, currently support "hot insertion" of PCMCIA cards. You will also need to know your IP address on the network, the "netmask" value for your address class and the name of your machine. Your system administrator can tell you which values to use for your particular network setup. If you will be referring to other hosts by name rather than IP address, you'll also need a name server and possibly the address of a gateway (if you're using PPP, it's your provider's IP address) to use in talking to it. If you do not know the answers to all or most of these questions, then you should really probably talk to your system administrator _first_ before trying this type of installation! Once you have a network link of some sort working, the installation can continue over NFS or FTP. - Preparing for NFS installation + Preparing for NFS installation

NFS installation is fairly straight-forward: Simply copy the FreeBSD distribution files you're interested onto a server somewhere and then point the NFS media selection at it. If this server supports only "privileged port" access (as is generally the default for Sun workstations), you will need to set this option in the Options menu before installation can proceed. If you have a poor quality ethernet card which suffers from very slow transfer rates, you may also wish to toggle the appropriate Options flag. In order for NFS installation to work, the server must support "subdir mounts", e.g. if your FreeBSD 2.0.5 distribution directory lives on: ziggy:/usr/archive/stuff/FreeBSD Then ziggy will have to allow the direct mounting of /usr/archive/stuff/FreeBSD, not just /usr or /usr/archive/stuff. In FreeBSD's /etc/exports file, this is controlled by the ``-alldirs'' option. Other NFS servers may have different conventions. If you are getting `Permission Denied' messages from the server then it's likely that you don't have this enabled properly! - Preparing for FTP Installation + Preparing for FTP Installation

FTP installation may be done from any mirror site containing a reasonably up-to-date version of FreeBSD 2.0.5, a full menu of reasonable choices from almost anywhere in the world being provided by the FTP site menu. If you are installing from some other FTP site not listed in this menu, or you are having troubles getting your name server configured properly, you can also specify your own URL by selecting the ``Other'' choice in that menu. A URL can also be a direct IP address, so the following would work in the absence of a name server: ftp://192.216.222.4/pub/FreeBSD/2.0.5-RELEASE NOTE: Substitute "ALPHA" for "RELEASE" during the ALPHA test period! If you are installing through a firewall then you should probably select ``Passive mode'' ftp, which is the default. If you are talking to a server which does not support passive mode for some reason, see the Options menu to select Active mode transfers. - Installing FreeBSD + Installing FreeBSD

Once you've taken note of the appropriate preinstallation steps, you should be able to install FreeBSD without any further trouble. Should this not be true, then you may wish to go back and re-read the relevant preparation section (section 2.x) for the installation media type you're trying to use - perhaps there's a helpful hint there that you missed the first time? If you're having hardware trouble, or FreeBSD refuses to boot at all, read the Hardware Guide provided on the boot floppy for a list of possible solutions. The FreeBSD boot floppy contains all the on-line documentation you should need to be able to navigate through an installation and if it doesn't then I'd like to know what you found most confusing! It is the objective of the FreeBSD installation program (sysinstall) to be self-documenting enough that painful "step-by-step" guides are no longer necessary. It may take us a little while to reach that objective, but that's the objective! Meanwhile, you may also find the following "typical installation sequence" to be helpful: Boot the boot floppy. After a boot sequence which can take anywhere from from 30 seconds to 3 minutes, depending on your hardware, you should be presented with a menu of initial choices. If the floppy doesn't boot at all, or the boot hangs at some stage, go read the Q&A section of the Hardware Guide for possible causes. Press F1. You should see some basic usage instructions on the menu system and general navigation. If you haven't used this menu system before then PLEASE read this thoroughly! If English is not your native language, you may wish to proceed directly to the Language option and set your preferred language. This will bring up some of the documentation in that language instead of english. Select the Options item and set any special preferences you may have. Select Proceed, bringing you to the Installation Menu. - The installation menu + The installation menu

You can do anything you like in this menu without altering your system except for "Commit", which will perform any requests to alter your system you may have made. If you're confused at any point, the F1 key usually pulls up the right information for the screen you're in. The first step is generally `Partition', which allows you to chose how your drives will be used for FreeBSD. Next, with the `Label' editor, you can specify how the space in any allocated FreeBSD partitions should be used by FreeBSD, or where to mount a non-FreeBSD partition (such as DOS). Next, the `Distributions' menu allows you to specify which parts of FreeBSD you wish to load. A good choice is "User" for a small system or "Developer" for someone wanting a bit more out of FreeBSD. If none of the existing collections sound applicable, select Custom. Next, the `Media' menu allows you to specify what kind of media you wish to install from. If a desired media choice is found and configured automatically then this menu will simply return, otherwise you'll be asked for additional details on the media device type. Finally, the Commit command will actually perform all the actions at once (nothing has been written to your disk so far, nor will it until you give the final confirmation). All new or changed partition information will be written out, file systems will be created and/or non-destructively labelled (depending on how you set their newfs flags in the Label editor) and all selected distributions will be extracted. The Configure menu choice allows you to furthur configure your FreeBSD installation by giving you menu-driven access to various system defaults. Some items, like networking, may be especially important if you did a CDROM/Tape/Floppy installation and have not yet configured your network interfaces (assuming you have some). Properly configuring your network here will allow FreeBSD to come up on the network when you first reboot from the hard disk. Exit returns you to the top menu. At this point, you're generally done with the sysinstall utility and can select the final `Quit'. If you're running it as an installer (e.g. before the system is all the way up) then the system will now reboot. If you selected the boot manager option, you will see a small boot menu with an `F?' prompt. Press the function key for BSD (it will be shown) and you should boot up into FreeBSD off the hard disk. If this fails to happen for some reason, see the Q&A section of the Hardware Guide for possible clues! diff --git a/handbook/relnotes.sgml b/handbook/relnotes.sgml index ff74fbe4e8..cdbf62a324 100644 --- a/handbook/relnotes.sgml +++ b/handbook/relnotes.sgml @@ -1,503 +1,503 @@ - + - About this release

Since our first release of FreeBSD 1.0 nearly two years ago, FreeBSD has changed dramatically. Since release 2.0, FreeBSD has been based on the Berkeley BSD 4.4-lite code rather than the Net2 code used for previous versions. In addition to clearing the legal issues that surrounded the Net2 code, the port to 4.4 has also brought in numerous new features, filesystems and enhanced driver support. Since our release of FreeBSD 2.0 in November of 1994, the performance, feature set, and stability of FreeBSD has improved dramatically. The largest change is a revamped Virtual Memory (VM) system with a merged virtual memory and file buffer cache. This increases performance while reducing FreeBSD's memory footprint, making a system with 4 megabytes of RAM a more acceptable minimum. Other enhancements include full NIS client and server support, transaction TCP support, dial on demand PPP, an improved SCSI subsystem, early support for ISDN, support for FDDI and 100Mbit Fast Ethernet adapters, improved support for the Adaptec 2940 and hundreds of bug fixes. We've also taken the comments and suggestions of many of our users to heart and have attempted to provide what we hope is a more sane and easily understood installation process. Your feedback on this constantly evolving process is especially welcome! In addition to the base distributions, FreeBSD offers a new ported software collection with some 270 commonly sought-after programs. The list of ports ranges from World Wide Web (http) servers, to games, languages, editors and almost everything in between. The entire ports collection requires only 10MB of storage because each port contains only the changes required for the source code to compile on FreeBSD and the information necessary to automatically retrieve the original sources. The original distribution for each port you build is automatically retrieved off of CD-ROM or a via anonymous ftp, so you need only enough disk space to build the ports you want. Each port is also provided as a pre-compiled package which can be installed with the pkg_add(1) command for those who do not wish to compile their own ports from source. See for a more complete description. The core of FreeBSD does not contain DES code which would inhibit its being exported outside the United States. An add-on package, for use only in the United States, contains the programs that normally use DES. The auxiliary packages provided separately can be used by anyone. A freely exportable European distribution of DES for our non-U.S. users also exists and is described in the . If password security for FreeBSD is all you need, and you have no requirement for copying encrypted passwords from other hosts using DES into FreeBSD password entries, then FreeBSD's MD5 based security may be all you require. We feel that our default security model is more than a match for DES, and without any messy export issues to deal with. FreeBSD 2.0.5 represents the culmination of 2 years of work and many thousands of man hours put in by an international development team. We hope you enjoy it! - New feature highlights + New feature highlights

The following features were added or substantially improved between the release of 2.0 and this 2.0.5 release. In order to facilitate better communication, the person, or persons, responsible for each enhancement is noted. Any questions regarding the new functionality should be directed to them first. - Kernel + Kernel

Merged VM-File Buffer Cache A merged VM/buffer cache design greatly enhances overall system performance and makes it possible to do a number of more optimal memory allocation strategies that were not possible before. Owner: David Greenman (davidg@FreeBSD.org) and John Dyson (dyson@implode.root.com) Network PCB hash optimization For systems with a great number of active TCP connections (WEB and ftp servers, for example), this greatly speeds up the lookup time required to match an incoming packet up to its associated connection. Owner: David Greenman (davidg@FreeBSD.org) Name cache optimization The name-cache would cache all files of the same name to the same bucket, which would put for instance all ".." entries in the same bucket. We added the parent directory version to frustrate the hash, and improved the management of the cache in various other ways while we were at it. Owner: Poul-Henning Kamp (phk@FreeBSD.org) David Greenman (davidg@FreeBSD.org) Less restrictive swap-spaces The need to compile the names of the swap devices into the kernel has been removed. Now swapon(8) will accept any block devices, up to the maximum number of swap devices configured in the kernel. Owner: Poul-Henning Kamp (phk@FreeBSD.org) David Greenman (davidg@FreeBSD.org) Hard Wired SCSI Devices Prior to 2.0.5, FreeBSD performed dynamic assignment of unit numbers to SCSI devices as they were probed, allowing a SCSI device failure to possibly change unit number assignment. This could cause filesystems other disks in the system to be incorrectly mounted, or not mounted at all. Hard wiring allows static allocation of unit numbers (and hence device names) to scsi devices based on SCSI ID and bus. SCSI configuration occurs in the kernel config file. Samples of the configuration syntax can be found in the scsi(4) man page or the LINT kernel config file. Owner: Peter Dufault (dufault@hda.com) Sources involved: sys/scsi/* usr.sbin/config/* Slice Support FreeBSD now supports a slice abstraction which enhances FreeBSD's ability to share disks with other operating systems. This support will allow FreeBSD to inhabit DOS extended partitions. Owner: Bruce Evans (bde@FreeBSD.org) Sources involved: sys/disklabel.h sys/diskslice.h sys/dkbad.h kern/subr_diskslice.c kern/subr_dkbad.c i386/isa/diskslice_machdep.c i386/isa/wd.c scsi/sd.c dev/vn/vn.c Support for Ontrack Disk Manager Version 6.0 Support has been added for disks which use Ontrack Disk Manager. The fdisk program does not know about it however, so make all changes using the install program on the boot.flp or the Ontrack Disk Manager tool under MS-DOS. Owner: Poul-Henning Kamp (phk@FreeBSD.org) Bad144 is back and working Bad144 works again, though the semantics are slightly different than before in that the bad-spots are kept relative to the slice rather than absolute on the disk. Owner: Bruce Evans (bde@FreeBSD.org) Poul-Henning Kamp (phk@FreeBSD.org) - New device support + New device support - SCSI and CDROM devices + SCSI and CDROM devices

Matsushita/Panasonic (Creative) CD-ROM driver The Matsushita/Panasonic CR-562 and CR-563 drives are now supported when connected to a Sound Blaster or 100% compatible host adapter. Up to four host adapters are supported for a total of 16 CD-ROM drives. The audio functions are supported with the Karoke variable speed playback. Owner: Frank Durda IV (bsdmail@nemesis.lonestar.org) Sources involved: isa/matcd Adaptec 2742/2842/2940 SCSI driver The original 274x/284x driver has evolved considerably since the 2.0 release of FreeBSD. We now offer full support for the 2940 series as well as the Wide models of these cards. The arbitration bug that caused problems with fast devices has been corrected and experimental tagged queuing support has been added (kernel option AHC_TAGENABLE). John Aycock has also released the sequencer code under a Berkeley style copyright making the driver entirely clean of the GPL. Owner: Justin Gibbs (gibbs@FreeBSD.org) Sources involved: isa/aic7770.c pci/aic7870.c i386/scsi/* sys/dev/aic7xxx/* NCR5380/NCR53400 SCSI (ProAudio Spectrum) driver Owner: core Submitted by: Serge Vakulenko (vak@cronyx.ru) Sources involved: isa/ncr5380.c Sony CDROM driver Owner: core Submitted by: Mikael Hybsch (micke@dynas.se) Sources involved: isa/scd.c - Serial devices + Serial devices

SDL Communications Riscom/8 Serial Board Driver Owner: Andrey Chernov (ache@FreeBSD.org) Sources involved: isa/rc.c isa/rcreg.h Cyclades Cyclom-y Serial Board Driver Owner: Bruce Evans (bde@FreeBSD.org) Submitted by: Andrew Werple (andrew@werple.apana.org.au) and Heikki Suonsivu (hsu@cs.hut.fi) Obtained from: NetBSD Sources involved: isa/cy.c Cronyx/Sigma sync/async serial driver Owner: core Submitted by: Serge Vakulenko Sources involved: isa/cronyx.c - Networking + Networking

Diskless booting Diskless booting in 2.0.5 is much improved over previous releases. The boot program is in src/sys/i386/boot/netboot, and can be run from an MS-DOS system or burned into an EPROM. WD, SMC, 3COM and Novell ethernet cards are currently supported. Local swapping is also supported. DEC DC21140 Fast Ethernet driver This driver supports any of the numerous NICs using the DC21140 chipset including the 100Mb DEC DE-500-XA and SMC 9332. Owner: core Submitted by: Matt Thomas (thomas@lkg.dec.com) Sources involved: pci/if_de.c pci/dc21040.h DEC FDDI (DEFPA/DEFEA) driver Owner: core Submitted by: Matt Thomas (thomas@lkg.dec.com) Sources involved: pci/if_pdq.c pci/pdq.c pci/pdq_os.h pci/pdqreg.h 3Com 3c505 (Etherlink/+) NIC driver Owner: core Submitted by: Dean Huxley (dean@fsa.ca) Obtained from: NetBSD Sources involved: isa/if_eg.c Fujitsu MB86960A family of NICs driver Owner: core Submitted by: M.S. (seki@sysrap.cs.fujitsu.co.jp) Sources involved: isa/if_fe.c Intel EtherExpress driver Owner: Rodney W. Grimes (rgrimes@FreeBSD.org) Sources involved: isa/if_ix.c isa/if_ixreg.h 3Com 3c589 driver Owner: core Submitted by: "HOSOKAWA Tatsumi" (hosokawa@mt.cs.keio.ac.jp), Seiji Murata (seiji@mt.cs.keio.ac.jp) and Noriyuki Takahashi (hor@aecl.ntt.jp) Sources involved: isa/if_zp.c IBM Credit Card Adapter driver Owner: core Submitted by: "HOSOKAWA Tatsumi" (hosokawa@mt.cs.keio.ac.jp), Sources involved: isa/pcic.c isa/pcic.h EDSS1 and 1TR6 ISDN interface driver Owner: core Submitted by: Dietmar Friede (dfriede@drnhh.neuhaus.de) and Juergen Krause (jkr@saarlink.de) Sources involved: gnu/isdn/* - Miscellaneous drivers + Miscellaneous drivers

Joystick driver Owner: Jean-Marc Zucconi (jmz@FreeBSD.org) Sources involved: isa/joy.c National Instruments "LabPC" driver Owner: Peter Dufault (dufault@hda.com) Sources involved: isa/labpc.c WD7000 driver Owner: Olof Johansson (offe@ludd.luth.se) Pcvt Console driver Owner: Joerg Wunsch (joerg@FreeBSD.org) Submitted by: Hellmuth Michaelis (hm@altona.hamburg.com) Sources involved: isa/pcvt/* BSD-audio emulator for VAT driver Owner: Amancio Hasty (ahasty@FreeBSD.org) and Paul Traina (pst@FreeBSD.org) Sources involved: isa/sound/vat_audio.c isa/sound/vat_audioio.h National Instruments AT-GPIB and AT-GPIB/TNT GPIB driver Owner: core Submitted by: Fred Cawthorne (fcawth@delphi.umd.edu) Sources involved: isa/gpib.c isa/gpib.h isa/gpibreg.h Genius GS-4500 hand scanner driver Owner: core Submitted by: Gunther Schadow (gusw@fub46.zedat.fu-berlin.de) Sources involved: isa/gsc.c isa/gscreg.h CORTEX-I Frame Grabber Owner: core Submitted by: Paul S. LaFollette, Jr. ( Sources involved: isa/ctx.c isa/ctxreg.h Video Spigot video capture card Owner: Jim Lowe - Experimental features + Experimental features

UNIONFS and LFS The unionfs and LFS file systems are known to be severely broken in FreeBSD 2.0.5. This is in part due to old bugs that we haven't had time to resolve yet and the need to update these file systems to deal with the new VM system. We hope to address these issues in a later release of FreeBSD. iBCS2 Support FreeBSD now supports running iBCS2 compatible binaries. Currently SCO UNIX 3.2.2 and 3.2.4, and ISC 2.2 COFF are supported. The iBCS2 emulator is in its early stages and has not been extensively tested, but it is functional. Most of SCO's 3.2.2 binaries work, as does an old INFORMIX-2.10 for SCO. Further testing is nessesary to complete this project. There is also work under way for ELF and XOUT loaders, and most of the svr4 syscall wrappers are written. Owner: Soren Schmidt (sos) and Sean Eric Fagan (sef) Sources involved: sys/i386/ibcs2/* and misc kernel changes. diff --git a/handbook/scsi.sgml b/handbook/scsi.sgml index ee4c1dcc0c..9b8c610605 100644 --- a/handbook/scsi.sgml +++ b/handbook/scsi.sgml @@ -1,688 +1,688 @@ - + SCSI

© 1995, &a.wilko;. SCSI is an acronym for Small Computer Systems Interface. It is an ANSI standard that has become one of the leading I/O buses in the computer industry. The foundation of the SCSI standard was laid by Shugart Associates (the same guys that gave the world the first mini floppy disks) when they introduced the SASI bus (Shugart Associates Standard Interface). After some time an industry effort was started to come to a more strict standard allowing devices from different vendors to work together. This effort was recognised in the ANSI SCSI-1 standard. The SCSI-1 standard (approx 1985) is now more or less obsolete. The current standard is SCSI-2 (see ), with SCSI-3 on the drawing boards. In addition to a physical interconnection standard, SCSI defines a logical (command set) standard to which disk devices must adhere. This standard is called the Common Command Set (CCS) and was developed more or less in parallel with ANSI SCSI-1. SCSI-2 includes the (revised) CCS as part of the standard itself. The commands are dependent on the type of device at hand. It does not make much sense of course to define a Write command for a scanner... The SCSI bus is a parallel bus, which comes in a number of variants. The oldest and most used is an 8 bit wide bus, with single-ended signals, carried on 50 wires. (If you don't know what single-ended means, don't worry, that is what this document is all about.) Modern designs also use 16 bit wides buses, with differential signals. This allows transfer speeds of 20Mbytes/second, on cables lengths of up to 25 meters. SCSI-2 allows a maximum buswidth of 32 bits, using an additional cable. Of course the SCSI bus not only has data lines, but also a number of control signals. A very elaborate protocol is part of the standard to allow multiple devices to share the bus in an efficient manner. In SCSI-2, the data is always checked using a seperate parity line. In pre-SCSI-2 designs parity was optional. In SCSI-3 even faster bustypes are introduced, along with a serial SCSI bus that reduces the cabling overhead and allows a higher maximum buslength. As you could have guessed from the description above, SCSI devices are intelligent. They have to be to adhere to the SCSI standard (which is over 2 inches thick BTW). So, for a hard disk drive for instance you do not specify a head/cylinder/sector to address a particular block, but simply the number of the block you want. Elaborate caching schemes, automatic badblock replacement etc are all made possible by this 'intelligent device' approach. On a SCSI bus, each possible pair of devices can communicate. If their function allows this is another matter, but the standard does not restrict it. To avoid signal contention, the 2 devices have to arbitrate for the bus before using it. The philosophy of SCSI is to have a standard that allows older-standard devices to work with newer-standard ones. So, an old SCSI-1 device should normally work on a SCSI-2 bus. Normally, because it is not absolutely sure that the implementation of an old device follows the (old) standard closely enough to be acceptable on a new bus. Modern devices are usually more well-behaved, because the standardisation has become more strict and is better adhered to by the device manufacturers. Generally speaking, the chances of getting a working set of devices on a single bus is better when all the devices are SCSI-2 or newer. This does not imply that you have to dump all your old stuff when you get that shiny 2Gb disk: I own a system on which a pre-SCSI-1 disk, a SCSI-2 QIC tape unit, a SCSI-1 helical scan tape unit and 2 SCSI-1 disks work together quite happily. - Concepts of SCSI + Concepts of SCSI

- A smart interface + A smart interface

As said before, SCSI devices are smart. The idea is to put the knowledge about intimate hardware details onto the SCSI device itself. In this way, the host system does not have to worry about things like how many heads are hard disks has, or how many tracks there are on a specific tape device. If you are curious, the standard specifies commands with which you can query your devices on their hardware particulars. The advantage of intelligent devices is obvious: the device drivers on the host can be made in a much more generic fashion, there is no longer a need to change (and qualify!) drivers for every odd new device that is introduced. - Do's and don't's on interconnections + Do's and don't's on interconnections

For cabling and connectors there is a golden rule: get good stuff. With bus speeds going up all the time you will save yourself a lot of grief by using good material. So, gold plated connectors, shielded cabling, sturdy connector hoods with strain reliefs etc are the way to go. Second golden rule: don't use cables longer than necessary. I once spent 3 days hunting down a problem with a flaky machine only to discover that shortening the SCSI bus with 1 meter solved the problem. And the original bus length was well within the SCSI specification. - SCSI bus types + SCSI bus types

From an electrical point of view, there are two Incompatible bus types: single-ended and differential. This means that there are two different main groups of SCSI devices and controllers, which cannot be mixed on the same bus. It is possible however to use special converter hardware to transform a single-ended bus into a differential one (and vice versa). The differences between the bus types are explained in the next sections. In lots of SCSI related documentation there is a sort of jargon in use to abbreviate the different bus types. A small list: FWD: Fast Wide Differential FND: Fast Narrow Differential SE: Single Ended FN: Fast Narrow etc. With a minor amount of imagination one can usually imagine what is meant. Wide is a bit ambiguous, it can indicate 16 or 32 bit buses. As far as I know, the 32 bit variant is not (yet) in use, so wide normally means 16 bit. Fast means that the timing on the bus is somewhat different, so that on a narrow (8 bit) bus 10 Mbytes/sec are possible instead of 5 Mbytes/sec for 'slow' SCSI. More on this later. It should be noted that the datalines > 8 are only used for datatransfers and device addressing. The transfers of commands and status messages etc are only performed on the lowest 8 datalines. The standard allows narrow devices to operate on a wide bus. The usable buswidth is negotiated between the devices. You have to watch your device addressing closely when mixing wide and narrow. - Single ended buses + Single ended buses

A single-ended SCSI bus uses signals that are either 5 Volts or 0 Volts (indeed, TTL levels) and are relative to a COMMON ground reference. A singled ended 8 bit SCSI bus has approximately 25 ground lines, who are all tied to a single 'rail' on all devices. A standard single ended bus has a maximum length of 6 meters. If the same bus is used with fast-SCSI devices, the maximum length allowed drops to 3 meters. Fast-SCSI means that instead of 5Mbytes/sec the bus allows 10Mbytes/sec transfers. Please note that this means that if some devices on your bus use 'fast' to communicate your bus must adhere to the length restrictions for fast buses! It is obvious that with the newer fast-SCSI devices the buslength can become a real bottleneck. This is why the differential SCSI bus was introduced in the SCSI-2 standard. For connector pinning and connector types please refer to the SCSI-2 standard (see ) itself, connectors etc are listed there in painstaking detail. Beware of devices using non-standard cabling. For instance Apple uses a 25pin D-type connecter (like the one on serial ports and parallel printers). Considering that the official SCSI bus needs 50 pins you can imagine the use of this connector needs some 'creative cabling'. The reduction of the number of ground wires they used is a bad idea, you better stick to 50 pins cabling in accordance with the SCSI standard. - Differential buses + Differential buses

A differential SCSI bus has a maximum length of 25 meters. Quite a difference from the 3 meters for a single-ended fast-SCSI bus. The idea behind differential signals is that each bus signal has it's own return wire. So, each signal is carried on a (preferably twisted) pair of wires. The voltage difference between these two wires determines whether the signal is asserted or de-asserted. To a certain extent the voltage difference between ground and the signal wire pair is not relevant (don't try 10 kVolts though..). It is beyond the scope of this document to explain why this differential idea is so much better. Just accept that electrically seen the use of differential signals gives a much better noise margin. You will normally find differential buses in use for inter-cabinet connections. Because of the lower cost single ended is mostly used for shorter buses like inside cabinets. There is nothing that stops you from using differential stuff with FreeBSD, as long as you use a controller that has device driver support in FreeBSD. As an example, Adaptec marketed the AH1740 as a single ended board, whereas the AH1744 was differential. The software interface to the host is identical for both. - Terminators + Terminators

Terminators in SCSI terminology are resistor networks that are used to get a correct impedance matching. Impedance matching is important to get clean signals on the bus, without reflections or ringing. If you once made a long distance telephone call on a bad line you probably know what reflections are. With 20Mbytes/sec travelling over your SCSI bus, you don't want signals echoing back. Terminators come in various incarnations, with more or less sophisticated designs. Of course, there are internal and external variants. Almost every SCSI device comes with a number of sockets in which a number of resistor networks can (must be!) installed. If you remove terminators from a device, carefully stock 'm. You will need them when you ever decide to reconfigure your SCSI bus. There is enough variation in even these simple tiny things to make finding the exact replacement a frustrating business. There are also SCSI devices that have a single jumper to enable or disable a builtin terminator. There are special terminators you can stick onto a flatcable bus. Others look like external connectors, so a connector hood without a cable. So, lots of choice as you can see. There is much debate going on if and when you should switch from simple resistor (passive) terminators to active terminators. Active terminators contain more or less elaborate circuits to give more clean bus signals. The general consensus seems to be that the usefullnes of active termination increases when you have long buses and/or fast devices. If you ever have problems with your SCSI buses you might consider trying an active terminator. Try to borrow one first, they reputedly are quite expensive. Please keep in mind that terminators for differential and single-ended buses are not identical. You should not mix the two variants. OK, and now where should you install your terminators? This is by far the most misunderstood part of SCSI. And it is by far the simplest.. The rule is: every SCSI bus has 2 (two) terminators, one at each end of the bus. So, two and not one or three or whatever. Do yourself a favour and stick to this rule. It will save you endless grief, because wrong termination has the potential to introduce highly mysterious bugs. A common pitfall is to have an internal (flat)cable in a machine and also an external cable attached to the controller. It seems almost everybody forgets to remove the terminators from the controller. The terminator must now be on the last external device, and not on the controller! In general, every reconfiguration of a SCSI bus must pay attention to this. What I did myself is remove all terminators from my SCSI devices and controllers. I own a couple of external terminators, for both the Centronics-type external cabling and for the internal flat cable connectors. This makes reconfiguration much easier. - Terminator power + Terminator power

The terminators discussed in the previous chapter need power to operate properly. On the SCSI bus, a line is dedicated to this purpose. So, simple huh? Not so. Each device can provide it's own terminator power to the terminator sockets it has on-device. But if you have external terminators, or when the device supplying the terminator power to the SCSI bus line is switched off you are in trouble. The idea is that initiators (these are devices that initiate actions on the bus, a discussion follows) must supply terminator power. All SCSI devices are allowed (but not required) to supply terminator power. To allow for switched-off devices on a bus, the terminator power must be supplied to the bus via a diode. This prevents the backflow of current to switched-off devices. To prevent all kinds of nastiness, the terminator power is usually fused. As you can imagine, fuses might blow. This can, but does not have to, lead to a non functional bus. If multiple devices supply terminator power, a single blown fuse will not put you out of business. A single supplier with a blown fuse certainly will. Clever external terminators sometimes have a LED indication that shows whether terminator power is present. In newer designs auto-restoring fuses are used who 'reset' themselves after some time. On modern devices, sometimes integrated terminators are used. These things are special purpose integrated circuits that can be dis/en-abled with a control pin. It is not necessary to physically remove them from a device. You may find them on newer host adapters, sometimes they even are software configurable, using some sort of setup tool. Consult you documentation! - Device addressing + Device addressing

Because the SCSI bus is, ehh, a bus there must be a way to distinguish or address the different devices connected to it. This is done by means of the SCSI or target ID. Each device has a unique target ID. You can select the ID to which a device must respond using a set of jumpers, or a dipswitch, or something similar. Consult the documentation of your device for more information. Beware of multiple devices configured to use the same ID. Chaos normally reigns in this case. For an 8 bit bus, a maximum of 8 targets is possible. The maximum is 8 because the selection is done bitwise using the 8 datalines on the bus. For wide this increases to the number of datalines. The higher the SCSI target ID, the higher the priority the devices has. When it comes to arbitration between devices that want to use the bus at the same time, the device that has the highest SCSI ID will win. This also means that the SCSI hostadapter usually uses target ID 7 (for narrow buses). For a further subdivision, the standard allows for Logical Units or LUNs for short. A single target ID may have multiple LUNs. For example, a tape device including a tape changer may have LUN 0 for the tape device itself, and LUN 1 for the tapechanger. In this way, the host system can address each of the parts of the tape unit as desired. - Bus layout + Bus layout

SCSI buses are linear. So, not shaped like Y-junctions, star topologies, cobwebbs or whatever else people might want to invent. You might notice that the terminator issue discussed earlier becomes rather hairy if your bus is not linear.. The electrical characteristics, it's noise margins and ultimately the reliability of it all are tightly related to linear bus rule. Stick to the linear bus rule! - Using SCSI with FreeBSD + Using SCSI with FreeBSD

- About translations, BIOSes and magic.. + About translations, BIOSes and magic..

As stated before, you should first make sure that you have a electrically sound bus. When you want to use a SCSI disk on your PC as boot disk, you must aware of some quirks related to PC BIOSes. The PC BIOS in it's first incarnation used a low level physical interface to the harddisk. So, you had to tell the BIOS (using a setup tool or a BIOS builtin setup) how your disk physically looked like. This involved stating number of heads, number of cylinders, number of sectors per track, obscure things like precompensation and reduced write current cylinder etc. One might be inclined to think that since SCSI disks are smart you can forget about this. Alas, the arcane setup issue is still present today. The system BIOS needs to know how to access your SCSI disk with the head/cyl/sector method. The SCSI host adapter or SCSI controller you have put in your AT/EISA/PCI/whatever bus to connect your disk therefore has it's own onboard BIOS. During system startup, the SCSI BIOS takes over the harddisk interface routines from the system BIOS. To fool the system BIOS, the system setup is normally set to No harddisk present. Obvious, isn't it? The SCSI BIOS itself presents to the system a so called translated drive. This means that a fake drive table is constructed that allows the PC to boot the drive. This translation is often (but not always) done using a pseudo drive with 32 heads and 64 sectors per track. By varying the number of cylinders, the SCSI BIOS adapts to the actual drive size. It is useful to note that 32 * 64 / 2 = the size of your drive in megabytes. The division by 2 is to get from disk blocks that are normally 512 bytes in size to Kbytes. Right.. All is well now?! No, it isn't. The system BIOS has another quirk you might run into. The number of cylinders of a bootable harddisk cannot be greater than 1024. Using the translation above, this is a showstopper for disks greater than 1 Gb. With disk capacities going up all the time this is causing problems. Fortunately, the solution is simple: just use another translation, e.g. with 128 heads instead of 32. In most cases new SCSI BIOS versions are available to upgrade older SCSI host adapters. Some newer adapters have an option, in the form of a jumper or software setup selection, to switch the translation the SCSI BIOS uses. It is very important that all operating systems on the disk use the same translation to get the right idea about where to find the relevant partitions. So, when installing FreeBSD you must answer any questions about heads/cylinders etc using the translated values your host adapter uses. Failing to observe the translation issue might be un-bootable systems or operating systems overwriting eachothers partitions. Using fdisk you should be able to see all partitions. As promised earlier: what is this talk about 'lying' devices? As you might already know, the FreeBSD kernel reports the geometry of SCSI disks when booting. An example from one of my systems: Feb 9 19:33:46 yedi /386bsd: aha0 targ 0 lun 0: Feb 9 19:33:46 yedi /386bsd: sd0: 636MB (1303250 total sec), 1632 cyl, 15 head, 53 sec, bytes/sec 512 This info is retrieved from the SCSI disk itself. Newer disks often use a technique called zone bit recording. The idea is that on the outer cylinders of the drive there is more space so more sectors per track can be put on them. This results in disks that have more tracks on outer cylinders than on the inner cylinders and, last but not least, have more capacity. You can imagine that the value reported by the drive when inquiring about the geometry now becomes fake. - SCSI subsystem design + SCSI subsystem design

FreeBSD uses a sort of layered SCSI subsystem. For each different controller card a so called device driver is written. This driver knows all the intimate details about the hardware it controls. The driver has a interface to the upper layers of the SCSI subsystem through which it receives it's commands and reports back any status. On top of the card drivers there are a number of more generic drivers for a class of devices. More specific: a driver for tape devices (abbreviation: st), magnetic disks (sd), cdroms (cd) etc. In case you are wondering where you can find this stuff, it all lives in /sys/scsi. See the man pages in section 4 for more details. The multi level design allows a decoupling of low-level bit banging and more high level stuff. Adding support for another piece of hardware is a much more managable problem. - Kernel configuration + Kernel configuration

Dependent on your hardware, the kernel configuration file must contain a line which describes your hostadapter. This includes I/O addresses, interrupts etc. Consult the man page for your adapter driver to get more info. Although it is probably an obvious remark: the kernel config file should reflect your actual hardware setup. So, interrupts, I/O addresses etc must match the kernel config file. An example from the kernel config file (they live in /sys/i386/conf BTW), with some added comments (between []): controller ahb0 at isa? bio irq 11 vector ahbintr [driver for Adaptec 174x] controller aha0 at isa? port "IO_AHA0" bio irq 11 drq 5 vector ahaintr [for Adaptec 154x] controller sea0 at isa? bio irq 5 iomem 0xc8000 iosiz 0x2000 vector seaintr [for Seagate ST01/02] controller scbus0 device sd0 [support for 4 SCSI harddisks, sd0 up sd3] device sd1 device sd2 device sd3 device st0 [support for 2 SCSI tapes] device st1 device cd0 #Only need one of these, the code dynamically grows [for the cdrom] So, the ahb driver is used for the Adaptec 1740, the aha driver for the Adaptec 154x etc. If you have more than one card of the same type in your system you get an ahb1, ahb2 line etc. The example above supports 4 SCSI disks. If during boot more devices of a specific type (e.g. sd disks) are found than are configured in the booting kernel, the system will complain. You will have to build and boot a new kernel (after adapting the kernel configuration file) before you can use all of the devices. It does not hurt to have 'extra' devices in the kernel, the example above will work fine when you have only 2 SCSI disks. Use man 4 scsi to check for the latest info on the SCSI subsystem. For more detailed info on hostadapter drivers use eg man 4 aha for info on the Adaptec 154x driver. - Tuning your SCSI kernel setup + Tuning your SCSI kernel setup

Experience has shown that some devices are slow to respond to INQUIRY commands after a SCSI bus reset. An INQUIRY command is sent by the kernel on boot to see what kind of device (disk, tape, cdrom etc) is connected to a specific target ID. This process is called device probing by the way. To work around this problem, FreeBSD allows a tunable delay time before the SCSI devices are probed following a SCSI bus reset. You can set this delaytime in your kernel configuration file using a line like: options "SCSI_DELAY=15" #Be pessimistic about Joe SCSI device This line sets the delay time to 15 seconds. On my own system I had to use 3 seconds minimum to get my trusty old CDROM drive to be recognised. Start with a high value (say 30 seconds or so) when you have problems with device recognition. If this helps, tune it back until it just stays working. - Rogue SCSI devices + Rogue SCSI devices

Although the SCSI standard tries to be complete and concise, it is a complex standard and implementing things correctly is no easy task. Some vendors do a better job then others. This is exactly where the 'rogue' devices come into view. Rogues are devices that are recognised by the FreeBSD kernel as behaving slightly (...) non-standard. Rogue devices are reported by the kernel when booting. An example for two of my cartridge tape units: Feb 25 21:03:34 yedi /386bsd: ahb0 targ 5 lun 0: Feb 25 21:03:34 yedi /386bsd: st0: Tandberg tdc3600 is a known rogue Mar 29 21:16:37 yedi /386bsd: aha0 targ 5 lun 0: Mar 29 21:16:37 yedi /386bsd: st1: Archive Viper 150 is a known rogue For instance, there are devices that respond to all LUNs on a certain target ID, even if they are actually only one device. It is easy to see that the kernel might be fooled into believing that there are 8 LUNs at that particular target ID. The confusion this causes is left as an exercise to the user. The SCSI subsystem of FreeBSD recognises devices with bad habits by looking at the INQUIRY response they send when probed. Because the INQUIRY response also includes the version number of the device firmware, it is even possible that for different firmware versions different workarounds are used. This scheme works fine, but keep in mind that it of course only works for devices that are KNOWN to be weird. If you are the first to connect your bogus Mumbletech SCSI cdrom you might be the one that has to define which workaround is needed. - Busmaster host adapters + Busmaster host adapters

Most, but not all, SCSI host adapters are bus mastering controllers. This means that they can do I/O on their own without putting load onto the host CPU for data movement. This is of course an advantage for a multitasking operating system like FreeBSD. It must be noted however that there might be some rough edges. For instance an Adaptec 1542 controller can be set to use different transferspeeds on the host bus (ISA or AT in this case). The controller is settable to different rates because not all motherboards can handle the higher speeds. Problems like hangups, bad data etc might be the result of using a higher data transfer rate then your motherboard can stomach. The solution is of course obvious: switch to a lower data transfer rate and try if that works better. In the case of a Adaptec 1542, there is an option that can be put into the kernel config file to allow dynamic determination of the right, read: fastest feasible, transfer rate. This option is disabled by default: options "TUNE_1542" #dynamic tune of bus DMA speed Check the man pages for the host adapter that you use. Or better still, use the ultimate documentation (read: driver source). - Tracking down problems + Tracking down problems

The following list is an attempt to give a guideline for the most common SCSI problems and their solutions. It is by no means complete. Check for loose connectors and cables. Check and doublecheck the location and number of your terminators. Check if your bus has at least one supplier of terminator power (especially with external terminators. Check if no double target IDs are used. Check if at least one device provides terminator power to the bus. Check if all devices to be used are powered up. Make a minimal bus config with as little devices as possible. If possible, configure your hostadapter to use slow bus speeds. - Further reading

If you intend to do some serious SCSI hacking, you might want to have the official standard at hand: Approved American National Standards can be purchased from ANSI at 11 West 42nd Street, 13th Floor, New York, NY 10036, Sales Dept: (212) 642-4900. You can also buy many ANSI standards and most committee draft documents from Global Engineering Documents, 15 Inverness Way East, Englewood, CO 80112-5704, Phone: (800) 854-7179, Outside USA and Canada: (303) 792-2181, FAX: (303) 792- 2192. Many X3T10 draft documents are available electronically on the SCSI BBS (719-574-0424) and on the ncrinfo.ncr.com anonymous ftp site. Latest X3T10 committee documents are: AT Attachment (ATA or IDE) [X3.221-1994] Approved ATA Extensions (ATA-2) [X3T10/948D Rev 2i] Enhanced Small Device Interface (ESDI) [X3.170-1990/X3.170a-1991] Approved Small Computer System Interface - 2 (SCSI-2) [X3.131-1994] Approved SCSI-2 Common Access Method Transport and SCSI Interface Module (CAM) [X3T10/792D Rev 11] Other publications that might provide you with additional information are: "SCSI: Understanding the Small Computer System Interface", written by NCR Corporation. Available from: Prentice Hall, Englewood Cliffs, NJ, 07632 Phone: (201) 767-5937 ISBN 0-13-796855-8 "Basics of SCSI", a SCSI tutorial written by Ancot Corporation Contact Ancot for availability information at: Phone: (415) 322-5322 Fax: (415) 322-0455 "SCSI Interconnection Guide Book", an AMP publication (dated 4/93, Catalog 65237) that lists the various SCSI connectors and suggests cabling schemes. Available from AMP at (800) 522-6752 or (717) 564-0100 "Fast Track to SCSI", A Product Guide written by Fujitsu. Available from: Prentice Hall, Englewood Cliffs, NJ, 07632 Phone: (201) 767-5937 ISBN 0-13-307000-X "The SCSI Bench Reference", "The SCSI Encyclopedia", and the "SCSI Tutor", ENDL Publications, 14426 Black Walnut Court, Saratoga CA, 95070 Phone: (408) 867-6642 "Zadian SCSI Navigator" (quick ref. book) and "Discover the Power of SCSI" (First book along with a one-hour video and tutorial book), Zadian Software, Suite 214, 1210 S. Bascom Ave., San Jose, CA 92128, (408) 293-0800 On Usenet the newsgroups comp.periphs.scsi and comp.periphs are noteworthy places to look for more info. You can also find the SCSI-Faq there, which posted periodically. Most major SCSI device and hostadapter suppliers operate ftp sites and/or BBS systems. They may be valuable sources of information about the devices you own. diff --git a/handbook/slips.sgml b/handbook/slips.sgml index 5a4b94d625..3e86504010 100644 --- a/handbook/slips.sgml +++ b/handbook/slips.sgml @@ -1,516 +1,516 @@ Setting up a SLIP server

Contribudted by &a.ghelmer;. v1.0, 15 May 1995. This document provides suggestions for setting up SLIP Server services on a FreeBSD system, which typically means configuring your system to automatically startup connections upon login for remote SLIP clients. The author has written this document based on his experience; however, as your system and needs may be different, this document may not answer all of your questions, and the author cannot be responsible if you damage your system or lose data due to attempting to follow the suggestions here. This guide was originally written for SLIP Server services on a FreeBSD 1.x system. It has been modified to reflect changes in the pathnames and the removal of the SLIP interface compression flags in FreeBSD 2.x, which appear to be the only major changes between FreeBSD versions. If you do run encounter mistakes in this document, please email the author with enough information to help correct the problem. For FreeBSD 1.x users, all of the files referenced in the directory /etc/sliphome are actually in the /etc directory. Prerequisites

This document is very technical in nature, so background knowledge is required. It is assumed that you are familiar with the TCP/IP network protocol, and in particular, network and node addressing, network address masks, subnetting, routing, and routing protocols, such as RIP. Configuring SLIP services on a dial-up server requires a knowledge of these concepts, and if you are not familiar with them, please read a copy of either Craig Hunt's TCP/IP Network Administration published by O'Reilly & Associates, Inc. (ISBN Number 0-937175-82-X), or Douglas Comer's books on the TCP/IP protocol. It's further assumed that you have already setup your modem(s) and configured the appropriate system files to allow logins through your modems. If you haven't prepared your system for this yet, please see the tutorial for configuring dialup services; if you have a World-Wide Web browser available, browse the list of tutorials at http://www.freebsd.org/How; otherwise, check the place where you found this document for a document named Quick Overview +Quick Overview

In its typical configuration, using FreeBSD as a SLIP server works as follows: a SLIP user dials up your FreeBSD SLIP Server system and logs in with a special SLIP login ID that uses /usr/sbin/sliplogin as the special user's shell. The /etc/sliphome/slip.hosts to find a matching line for the special user, and if it finds a match, connects the serial line to an available SLIP interface and then runs the shell script /etc/sliphome/slip.login to configure the SLIP interface. -An Example of a SLIP Server Login +An Example of a SLIP Server Login

For example, if a SLIP user ID were Shelmerg, /etc/master.passwd would look something like this (except it would be all on one line): Shelmerg:password:1964:89::0:0:Guy Helmer - SLIP: /usr/users/Shelmerg:/usr/sbin/sliplogin and, when sliplogin will search /etc/sliphome/slip.hosts for a line that had a matching user ID; for example, there may be a line in /etc/sliphome/slip.hosts that reads: Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp /etc/sliphome/slip.login like this: /etc/sliphome/slip.login 0 19200 Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp If all goes well, /etc/sliphome/slip.login will issue an ifconfig for the SLIP interface to which slip.login) to set the local IP address (dc-slip), remote IP address (sl-helmer), network mask for the SLIP interface (0xfffffc00), and any additional flags (autocomp). If something goes wrong, /var/log/messages (see the manual pages for syslogd(8) and syslog.conf(5), and perhaps check /etc/syslog.conf to see to which files syslogd is logging). OK, enough of the examples -- let's dive into setting up the system. -Kernel Configuration +Kernel Configuration

FreeBSD's default kernels usually come with two SLIP interfaces defined (sl0 and sl1); you can use netstat -i to see whether these interfaces are defined in your kernel. Sample output from netstat -i: Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll ed0 1500 0.0.c0.2c.5f.4a 291311 0 174209 0 133 ed0 1500 138.247.224 ivory 291311 0 174209 0 133 lo0 65535 79 0 79 0 0 lo0 65535 loop localhost 79 0 79 0 0 sl0* 296 0 0 0 0 0 sl1* 296 0 0 0 0 0 The sl0 and sl1 interfaces shown in netstat -i's output indicate that there are two SLIP interfaces built into the kernel. (The asterisks after the sl0 and sl1 indicate that the interfaces are ``down''.) However, FreeBSD's default kernels do not come configured to forward packets (ie, your FreeBSD machine will not act as a router) due to Internet RFC requirements for Internet hosts (see RFC's 1009 [Requirements for Internet Gateways], 1122 [Requirements for Internet Hosts -- Communication Layers], and perhaps 1127 [A Perspective on the Host Requirements RFCs]), so if you want your FreeBSD SLIP Server to act as a router, you'll have to add the line options GATEWAY to your machine's kernel configuration file and re-compile the kernel anyway. (Trivia: ``Gateways'' are the Internet's old name for what are now usually called ``routers''.) Please see the BSD System Manager's Manual chapter on ``Building Berkeley Kernels with Config'' [the source for which is in /usr/src/share/doc/smm] and ``FreeBSD Configuration Options'' [in /sys/doc/options.doc] for more information on configuring and building kernels. You may have to unpack the kernel source distribution if haven't installed the system sources already (srcdist/srcsys.?? in FreeBSD 1.1, srcdist/sys.?? in FreeBSD 1.1.5.1, or the entire source distribution in FreeBSD 2.0) to be able to configure and build kernels. You'll notice that near the end of the default kernel configuration file (/sys/i386/conf/GENERICAH) is a line that reads: pseudo-device sl 2 which is the line that defines the number of SLIP devices available in the kernel; the number at the end of the line is the maximum number of SLIP connections that may be operating simultaneously. See the document ``Building Berkeley Kernels with Config'' and the manual page for config(8) to see how to configure and build kernels. -Sliplogin Configuration +Sliplogin Configuration

As mentioned earlier, there are three files in the /etc/sliphome directory that are part of the configuration for /usr/sbin/sliplogin (see sliplogin(8) for the actual manual page for sliplogin): slip.hosts, which defines the SLIP users & their associated IP addresses; slip.login, which usually just configures the SLIP interface; and (optionally) slip.logout, which undoes slip.login's effects when the serial connection is terminated. -slip.hosts Configuration +slip.hosts Configuration

/etc/sliphome/slip.hosts contains lines which have at least four items, separated by whitespace: SLIP user's login ID Local address (local to the SLIP server) of the SLIP link Remote address of the SLIP link Network mask The local and remote addresses may be host names (resolved to IP addresses by /etc/hosts or by the domain name service, depending on your specifications in /etc/host.conf), and I believe the network mask may be a name that can be resolved by a lookup into /etc/networks. On a sample system, /etc/sliphome/slip.hosts looks like this: ----- begin /etc/sliphome/slip.hosts ----- # # login local-addr remote-addr mask opt1 opt2 # (normal,compress,noicmp) # Shelmerg dc-slip sl-helmerg 0xfffffc00 autocomp ----- end /etc/sliphome/slip.hosts ------ At the end of the line is one or more of the options. normal - no header compression compress - compress headers autocomp - compress headers if the remote end allows it noicmp - disable ICMP packets (so any ``ping'' packets will be dropped instead of using up your bandwidth) It appears that section and/or consult your IP network manager. If you are going to use a separate subnet for your SLIP clients, you will need to allocate the subnet number out of your assigned IP network number and assign each of your SLIP client's IP numbers out of that subnet. Then, you will probably either need to configure a static route to the SLIP subnet via your SLIP server on your nearest IP router, or install gated on your FreeBSD SLIP server and configure it to talk the appropriate routing protocols to your other routers to inform them about your SLIP server's route to the SLIP subnet. Otherwise, if you will use the ``proxy ARP'' method, you will need to assign your SLIP client's IP addresses out of your SLIP server's Ethernet subnet, and you'll also need to adjust your /etc/sliphome/slip.login and /etc/sliphome/slip.logout scripts to use arp(8) to manage the proxy-ARP entries in the SLIP server's ARP table. -slip.login Configuration +slip.login Configuration

The typical /etc/sliphome/slip.login file looks like this: ----- begin /etc/sliphome/slip.login ----- #!/bin/sh - # # @(#)slip.login 5.1 (Berkeley) 7/1/90 # # generic login file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 inet $4 $5 netmask $6 ----- end /etc/sliphome/slip.login ----- This slip.login file merely ifconfig's the appropriate SLIP interface with the local and remote addresses and network mask of the SLIP interface. If you have decided to use the ``proxy ARP'' method (instead of using a separate subnet for your SLIP clients), your /etc/sliphome/slip.login file will need to look something like this: ----- begin /etc/sliphome/slip.login for "proxy ARP" ----- #!/bin/sh - # # @(#)slip.login 5.1 (Berkeley) 7/1/90 # # generic login file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 inet $4 $5 netmask $6 # Answer ARP requests for the SLIP client with our Ethernet addr /usr/sbin/arp -s $5 00:11:22:33:44:55 pub ----- end /etc/sliphome/slip.login for "proxy ARP" ----- The additional line in this slip.login, arp -s $5 00:11:22:33:44:55 pub, creates an ARP entry in the SLIP server's ARP table. This ARP entry causes the SLIP server to respond with the SLIP server's Ethernet MAC address whenever a another IP node on the Ethernet asks to speak to the SLIP client's IP address. When using the example above, be sure to replace the Ethernet MAC address (00:11:22:33:44:55) with the MAC address of your system's Ethernet card, or your ``proxy ARP'' will definitely not work! You can discover your SLIP server's Ethernet MAC address by looking at the results of running netstat -i; the second line of the output should look something like: ed0 1500 0.2.c1.28.5f.4a 191923 0 129457 0 116 ^^^^^^^^^^^^^^^ which indicates that this particular system's Ethernet MAC address is 00:02:c1:28:5f:4a -- the periods in the Ethernet MAC address given by netstat -i must be changed to colons and leading zeros should be added to each single-digit hexadecimal number to convert the address into the form that arp(8) desires; see the manual page on arp(8) for complete information on usage. Note that when you create /etc/sliphome/slip.login and /etc/sliphome/slip.logout, the ``execute'' bit (ie, chmod 755 /etc/sliphome/slip.login /etc/sliphome/slip.logout) must be set, or sliplogin will be unable to execute it. -slip.logout Configuration +slip.logout Configuration

/etc/sliphome/slip.logout isn't strictly needed (unless you are implementing ``proxy ARP''), but if you decide to create it, this is an example of a basic slip.logout script: ----- begin /etc/sliphome/slip.logout ----- #!/bin/sh - # # slip.logout # # logout file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 down ----- end /etc/sliphome/slip.logout ----- If you are using ``proxy ARP'', you'll want to have /etc/sliphome/slip.logout remove the ARP entry for the SLIP client: ----- begin /etc/sliphome/slip.logout for "proxy ARP" ----- #!/bin/sh - # # @(#)slip.logout # # logout file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 down # Quit answering ARP requests for the SLIP client /usr/sbin/arp -d $5 ----- end /etc/sliphome/slip.logout for "proxy ARP" ----- The arp -d $5 removes the ARP entry that the ``proxy ARP'' slip.login added when the SLIP client logged in. It bears repeating: make sure /etc/sliphome/slip.logout has the execute bit set for after you create it (ie, chmod 755 /etc/sliphome/slip.logout). -Routing Considerations +Routing Considerations

If you are not using the ``proxy ARP'' method for routing packets between your SLIP clients and the rest of your network (and perhaps the Internet), you will probably either have to add static routes to your closest default router(s) to route your SLIP client subnet via your SLIP server, or you will probably need to install and configure gated on your FreeBSD SLIP server so that it will tell your routers via appropriate routing protocols about your SLIP subnet. -Static Routes +Static Routes

Adding static routes to your nearest default routers can be troublesome (or impossible, if you don't have authority to do so...). If you have a multiple-router network in your organization, some routers, such as Cisco and Proteon, may not only need to be configured with the static route to the SLIP subnet, but also need to be told which static routes to tell other routers about, so some expertise and troubleshooting/tweaking may be necessary to get static-route-based routing to work. -Running gated +Running gated

An alternative to the headaches of static routes is to install gated on your FreeBSD SLIP server and configure it to use the appropriate routing protocols (RIP/OSPF/BGP/EGP) to tell other routers about your SLIP subnet. ftp.gated.cornell.edu in the directory /pub/gated; I believe the current version as of this writing is gated-R3_5Alpha_8.tar.Z, which includes support for FreeBSD ``out-of-the-box''. Complete information and documentation on gated is available on the Web starting at http://www.gated.cornell.edu/. Compile and install it, and then write a /etc/gated.conf file to configure your gated; here's a sample, similar to what the author used on a FreeBSD SLIP server: ----- begin sample /etc/gated.conf for gated version 3.5Alpha5 ----- # # gated configuration file for dc.dsu.edu; for gated version 3.5alpha5 # Only broadcast RIP information for xxx.xxx.yy out the ed Ethernet interface # # # tracing options # traceoptions "/var/tmp/gated.output" replace size 100k files 2 general ; rip yes { interface sl noripout noripin ; interface ed ripin ripout version 1 ; traceoptions route ; } ; # # Turn on a bunch of tracing info for the interface to the kernel: kernel { traceoptions remnants request routes info interface ; } ; # # Propagate the route to xxx.xxx.yy out the Ethernet interface via RIP # export proto rip interface ed { proto direct { xxx.xxx.yy mask 255.255.252.0 metric 1; # SLIP connections } ; } ; # # Accept routes from RIP via ed Ethernet interfaces import proto rip interface ed { all ; } ; ----- end sample /etc/gated.conf ----- The above sample gated.conf file broadcasts routing information regarding the SLIP subnet xxx.xxx.yy via RIP onto the Ethernet; if you are using a different Ethernet driver than the /var/tmp/gated.output for debugging gated's activity; you can certainly turn off the tracing options if gated works OK for you. You'll need to change the xxx.xxx.yy's into the network address of your own SLIP subnet (be sure to change the net mask in the proto direct clause as well). When you get gated built and installed and create a configuration file for it, you'll need to run gated in place of routed on your FreeBSD system; change the routed/gated startup parameters in /etc/netstart as appropriate for your system. Please see the manual page for gated for information on gated's command-line parameters. -Acknowledgements +Acknowledgements

Thanks to these people for comments and advice regarding this tutorial: diff --git a/handbook/userppp.sgml b/handbook/userppp.sgml index 5f366f8063..9265825b71 100644 --- a/handbook/userppp.sgml +++ b/handbook/userppp.sgml @@ -1,360 +1,360 @@ - + Setting up user PPP

Contributed by &a.nik; 28 July 1995.

User PPP was intruduced to FreeBSD in release 2.0.5 as an addition to the exisiting kernel implementation of PPP. So, what is different about this new PPP that warrants its addition? To quote from the manual page: This is a user process PPP software package. Normally, PPP is implemented as a part of the kernel (e.g. as managed by pppd) and it's thus somewhat hard to debug and/or modify its behavior. However, in this implementation PPP is done as a user process with the help of the tunnel device driver (tun). In essence, this means that rather than running a PPP daemon, the ppp program can be run as and when desired. No PPP interface needs to be compiled into the kernel, as the program can use the generic tunnel device to to get data into and out of the kernel. From here on out, user ppp will be referred to as simply as ppp unless a distinction need to be made be it and any other PPP client/server software. Unless otherwise stated, all commands in this section should be executed as root. Parts in this section marked with an asterisk (*) are incomplete. Comments and suggestions are appreciated and should be submitted to &a.nik;. Thanks to Rob Snow <rsnow@txdirect.net> who proved to be a mine of useful information when I was first experimenting with user ppp. -Before you start +Before you start

This document assumes you're in roughly this position: You have an account with an Internet Service Provider (ISP) which lets you use PPP. Further, you have a modem (or other device) connected and configured correctly which allows you to connect to your ISP. You are going to need the following information to hand: IP address of your ISP's gateway Your ISP's netmask setting IP adresses of one or more nameservers If your ISP allocates you a static IP address and/or hostname then you will need that as well. If not, you will need to know from what range of IP addresses your allocated IP address will fall in. If you do not have any of this information then contact your ISP and make sure they provide it to you. As well as this, you may need the files required to recompile your kernel. Check for more information on how to acquire these. In addition, I've assumed that because your connection to the Internet is not full time you are not running a name server (named(8)). -Building a ppp ready kernel +Building a ppp ready kernel

As the description states, ``ppp'' uses the kernel ``tun'' device. It is necessary to make sure that your kernel has support for this device compiled in. To check this, go to your kernel compile directory (probably /sys/i386/conf) and examine your kernel configuration file. It needs to have the line pseudo-device tun 1 in it somewhere. The stock GENERIC kernel has this as standard, so if you have not installed a custom kernel you don't have to change anything. If your kernel configuration file does not have this line in it then you should add the line, re-compile and then re-install the kernel. Boot from this new kernel. -Check the tun device +Check the tun device

My experiences with ppp have only been with one ``tun'' device (tun0). If you have used more (i.e., a number other than `1' in the pseudo-device line in the kernel configuration file) then alter all references to ``tun0'' below to reflect whichever device number you are using. The easiest way to make sure that the tun0 device is configured correctly is to re-make it. To this end, execute the following commands, # cd /dev # ./MAKEDEV tun0 -PPP Configuration +PPP Configuration

The meat of the problem. Confusingly, it appears that both user ppp and pppd (the kernel level implementation of PPP) both assume configuration files kept in /etc/ppp. However, the sample configuration files provided are good for user ppp, so keep them around for reference. The easiest way to do this is, # cd /etc # mv ppp ppp.orig # mkdir ppp Configuring ppp requires that you edit somewhere between one and three files, depending on your requirements. What you put in them depends to some extent on whether your ISP allocates IP addresses statically (i.e., you get given one IP address, and always use that one) or dynamically (i.e., your IP address can be different during different PPP sessions). However, there are a few things that you should do first, regardless of whether you are using static or dynamic IP addresses. -Configure the resolver(5) +Configure the resolver(5)

The resolver is the part of the networking system that turns IP addresses into hostnames. It can be configured to look for maps that describe IP to hostname mappings in one of two places. The first is a file called /etc/hosts (``hosts'' in section 5 of the manual). The second is the Internet Domain Name Service, a distributed data base, the discussion of which is beyond the realm of this document. The resolver is a set of system calls that do the mappings, and you have to tell them where to get their information from. You do this by editing the file /etc/host.conf. Do not call this file /etc/hosts.conf (note the extra ``s'') as the results can be confusing. This file should contain the following two lines, hosts bind which instruct the resolver to look in the file /etc/hosts first, and then to consult the DNS if the name was not found in the /etc/hosts file. It's probably a good idea to make sure you are not running the ``named'' service. Check your /etc/sysconfig file for the line that refers to ``namedflags'', and make sure the line reads namedflags="NO" -Create the /etc/hosts(5) file +Create the /etc/hosts(5) file

This file should contain the IP addresses and names of machines on your network. At a bare minimum it should contain entries for the machine which will be running ppp. Assuming that you're machine is called foo.bar.com with the IP address 10.0.0.1, /etc/hosts should contain 127.0.0.0 localhost 10.0.0.1 foo.bar.com foo The first line defines the alias ``localhost'' as a synonym for the current machine. Regardless of your own IP address, the IP address for this line should always be 127.0.0.1. The second line maps the name ``foo.bar.com'' (and the shorthand ``foo'') to the IP address 10.0.0.1. If your provider allocates you a static IP address then use this in place of 10.0.0.1. -Create the /etc/resolv.conf file +Create the /etc/resolv.conf file

/etc/resolv.conf contains some extra information required when you are not running a nameserver. It points the resolver routines at real nameservers, and specifies some other information. At the very least, /etc/resolv.conf should contain one line with a nameserver which can be queried. You should enter this as an IP address. My /etc/resolv.conf contains nameserver 158.152.1.193 nameserver 158.152.1.65 Which are Demon Internet's two nameservers. Add as many ``nameserver'' lines as your ISP provides nameservers. -PPP and static IP addresses +PPP and static IP addresses

Probably the easiest to configure for. You will need to create three files in the /etc/ppp directory. The first of these is ppp.conf. It should look similar to the example below. Note that lines that end in a ``:'' start in column 1, all other lines should be indented as shown. /etc/ppp/ppp.conf 1 default: 2 set device /dev/cuaa0 3 set speed 9600 4 disable lqr 5 deny lqr 6 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" ATE1Q0 OK-AT-OK \\dATDT\\T TIMEOUT 40 CONNECT" 7 provider: 8 set phone 01234567890 9 set login "TIMEOUT 10 gin:-BREAK-gin: foo word: bar col: ppp" 10 set timeout 120 11 set ifaddr x.x.x.x y.y.y.y Don't include the line numbers, they're just for this discussion. J. Random Provider login: foo password: bar protocol: ppp You will need to alter this script to suit your own needs. It is written in the chat(8) language. Now you have to edit the file /etc/ppp/ppp.linkup: x.x.x.x: add 0 0 HISADDR Replace x.x.x.x with your IP address as before. This file is used to automatically add a default route from your ISP (who's address is automatically inserted with the HISADDR macro) to you. Finally, you can create the file /etc/ppp/ppp.secret, which sets some passwords to prevent people messing around with ppp on your system. You may or may not want to do this, depending on how many people have access to your ppp system. -PPP and Dynamic IP configuration +PPP and Dynamic IP configuration

If you service provider does not assign static IP numbers, ppp can be configured to negotiate the local address. This is done by specifying 0 as the local IP address: set ifaddr 0 0 See the ppp(8) manual page for more detailed information. -Final system configuration +Final system configuration

You now have PPP configured, but there's a few more things to do before it's ready to work. They all involve editing the /etc/sysconfig file. Working from the top down in this file, make sure the ``hostname='' line is set, e.g., hostname=foo.bar.com Look for the network_interfaces variable, and make sure the tun0 device is added to the list. My line looks like network_interfaces="lo0 tun0 ep0" but I have an ethernet card (ep0) to configure as well. Now add an ifconfig line for the tun0 device. It should look something like ifconfig_tun0="inet foo.bar.com y.y.y.y netmask 0xffffffff" as before, change ``foo.bar.com'' to be your hostname, y.y.y.y is the IP address of your providers gateway, and 0xffffffff is the netmask they provided you with (in hexadecimal). Two common values for the netmask are 255.255.255.255 = 0xffffffff 255.255.255.0 = 0xffffff00 Set the routed flags to ``-s'' with the line routedflags=-s It's probably worth your while ensuring that the ``sendmail_flags'' line does not include the ``-q'' option, otherwise sendmail will attempt to do a network lookup every now and then, possibly causing your machine to dial out. My sendmail line looks like sendmail_flags="-bd" The upshot of this is that I must force sendmail to re-examine the mailqueue whenever I have the PPP link up, by typing # /usr/sbin/sendmail -q That should be about all you need to do to get PPP working with a static IP address. All that's left is to reboot the machine. During startup the tun0 device should be detected, and two lines like the following should be printed, tun0: flags=51 mtu 1500 inet x.x.x.x --> y.y.y.y netmask 0xffffffff At this point, it should all be working. You can now either type # ppp and then ``dial provider'' to start the PPP session, or, if you want ppp to establish sessions automatically when there is outbound traffic, type # ppp -auto provider This line could be added to your /etc/rc.local file.