1 files changed, 723 insertions, 0 deletions

diff --git a/FAQ/network.sgml b/FAQ/network.sgml
new file mode 100644
index 0000000000..2847f7a313
--- /dev/null
+++ b/FAQ/network.sgml
@@ -0,0 +1,723 @@
+<!-- $Id: network.sgml,v 1.1 1997-11-03 08:53:51 max Exp $ -->
+<!-- The FreeBSD Documentation Project -->
+
+  <sect>
+    <heading>Networking<label id="networking"></heading>
+
+    <sect1>
+      <heading>Where can I get information on ``diskless booting''?</heading>
+
+      <p>``Diskless booting'' means that the FreeBSD box is booted over a
+      network, and reads the necessary files from a server instead of
+      its hard disk. For full details, please read
+      <url url="../handbook/diskless.html"
+      name="the Handbook entry on diskless booting">
+
+    <sect1>
+      <heading>
+        Can a FreeBSD box be used as a dedicated network router?
+      </heading>
+
+      <p>Internet standards and good engineering practice prohibit us from
+      providing packet forwarding by default in FreeBSD. You can
+      however enable this feature by changing the following variable to
+      <tt/YES/ in <htmlurl url="http://www.freebsd.org/cgi/man.cgi?rc.conf"
+      name="rc.conf">:
+
+      <verb>
+        gateway_enable=YES          # Set to YES if this host will be a gateway
+      </verb>
+
+      <p>This option will put the <htmlurl 
+      url="http://www.freebsd.org/cgi/man.cgi?sysctl" name="sysctl"> variable
+      <tt/net.inet.ip.forwarding/ to <tt/1/.
+
+      <p>In most cases, you will also need to run a routing process to
+      tell other systems on your network about your router; FreeBSD
+      comes with the standard BSD routing daemon 
+      <htmlurl url="http://www.freebsd.org/cgi/man.cgi?routed"
+      name="routed">, or for more complex situations you may want to try
+      <em/GaTeD/ (available by FTP from <tt/ftp.gated.Merit.EDU/) which
+      supports FreeBSD as of 3_5Alpha7.
+
+      <p>It is our duty to warn you that, even when FreeBSD is configured
+      in this way, it does not completely comply with the Internet
+      standard requirements for routers; however, it comes close enough
+      for ordinary usage.
+
+    <sect1>
+      <heading>Can I connect my Win95 box to the Internet via FreeBSD?</heading>
+
+      <p>Typically, people who ask this question have two PC's at home, one
+      with FreeBSD and one with Win95; the idea is to use the FreeBSD
+      box to connect to the Internet and then be able to access the
+      Internet from the Windows95 box through the FreeBSD box. This
+      is really just a special case of the previous question.
+
+      <p>There's a useful document available which explains how to set
+      FreeBSD up as a <url url="http://www.ssimicro.com/~jeremyc/ppp.html"
+      name="PPP Dialup Router">
+
+      <p><bf/NOTE:/ This requires having at least two fixed IP addresses
+      available, and possibly three or more, depending on how much
+      work you want to go through to set up the Windows box. As an
+      alternative, if you don't have a fixed IP, you can use one of
+      the private IP subnets and install <bf/proxies/ such as
+      <url url="http://squid.nlanr.net/Squid/" name="SQUID"> and
+      <url url="http://www.tis.com/" name="the TIS firewall toolkit">
+      on your FreeBSD box.
+
+      <p>See also the section on <ref id="direct-at" name="natd">.
+
+    <sect1>
+      <heading>
+        Why does recompiling the latest BIND from ISC fail?
+      </heading>
+
+      <p>There is a conflict between the ``<tt/cdefs.h/'' file in the
+      distribution and the one shipped with FreeBSD. Just remove
+      <tt>compat/include/sys/cdefs.h</tt>.
+
+    <sect1>
+      <heading>Does FreeBSD support SLIP and PPP?</heading>
+
+      <p>Yes.  See the man pages for 
+      <htmlurl url="http://www.freebsd.org/cgi/man.cgi?slattach"
+      name="slattach">, <htmlurl
+      url="http://www.freebsd.org/cgi/man.cgi?sliplogin" name="sliplogin">,
+      <htmlurl url="http://www.freebsd.org/cgi/man.cgi?pppd" name="pppd"> and 
+      <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp" name="ppp">.
+      <tt/pppd/ and <tt/ppp/ provide support for both incoming and outgoing
+      connections.  <htmlurl url="http://www.freebsd.org/cgi/man.cgi?sliplogin"
+      name="Sliplogin"> deals exclusively with incoming connections and
+      <htmlurl url="http://www.freebsd.org/cgi/man.cgi?slattach"
+      name="slattach"> deals exclusively with outgoing connections.
+
+      <p>These programs are described in the following sections of the
+      <url url="../handbook/handbook.html" name="handbook">:
+
+      <itemize>
+        <item><url url="../handbook/slips.html"
+        name="Handbook entry on SLIP (server side)">
+
+        <item><url url="../handbook/slipc.html"
+        name="Handbook entry on SLIP (client side)">
+
+        <item><url url="../handbook/ppp.html"
+        name="Handbook entry on PPP (kernel version)">
+
+        <item><url url="../handbook/userppp.html"
+        name="Handbook entry on PPP (user-mode version)">
+      </itemize>
+
+      <p>If you only have access to the Internet through a "shell
+      account", you may want to have a look at the <htmlurl
+      url="http://www.freebsd.org/cgi/ports.cgi?^slirp" name="slirp">
+      package.  It can provide you with (limited) access to services
+      such as ftp and http direct from your local machine.
+
+    <sect1>
+      <heading>
+        Does FreeBSD support NAT or Masquerading<label id="natd">
+      </heading>
+
+      <p>If you have a local subnet (one or more local machines), but have
+      been allocated only a single IP number from your Internet provider
+      (or even if you receive a dynamic IP number), you may want to look at
+      the <htmlurl url="http://www.freebsd.org/cgi/man.cgi?natd" name="natd">
+      program.  <tt/Natd/ allows you to connect an entire subnet to the
+      internet using only a single IP number.
+
+      <p>The <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp"
+      name="ppp"> program has similar functionality built in via
+      the <tt/-alias/ switch.  The <htmlurl
+      url="http://www.freebsd.org/cgi/man.cgi?libalias" name="alias library">
+      is used in both cases.
+
+    <sect1>
+      <heading>
+        I can't make ppp work.  What am I doing wrong ?<label id="userppp">
+      </heading>
+
+      <p>You should first read the <htmlurl
+      url="http://www.freebsd.org/cgi/man.cgi?ppp" name="ppp man page"> and
+      the <url url="../handbook/userppp.html"
+      name="ppp section of the handbook">.  Enable logging with the command
+
+      <verb>
+        set log Phase Chat Connect Carrier lcp ipcp ccp command
+      </verb>
+
+      <p>This command may be typed at the <tt/ppp/ command prompt or
+      it may be entered in the <tt>/etc/ppp/ppp.conf</tt> configuration file
+      (the start of the <bf>default</bf> section is the best place to put it).
+      Make sure that <htmlurl
+      url="http://www.freebsd.org/cgi/man.cgi?syslog.conf"
+      name="/etc/syslog.conf"> contains the lines
+
+      <verb>
+        !ppp
+        *.*              /var/log/ppp.log
+      </verb>
+
+      <p>and that the file <tt>/var/log/ppp.log</tt> exists.  You can
+      now find out a lot about what's going on from the log file.
+      Don't worry if it doesn't all make sense.  If you need to
+      get help from someone, it may make sense to them.
+
+      <p>If your version of ppp doesn't understand the "set log"
+      command, you should download the
+      <url url="http://www.freebsd.org/~brian" name="latest version">.
+      It will build on FreeBSD version 2.1.5 and higher.
+
+      <sect2>
+        <heading>Ppp won't dial in -auto mode</heading>
+
+        <p>First, check that you've got a default route.  By running <htmlurl 
+        url="http://www.freebsd.org/cgi/man.cgi?netstat">
+        name="netstat -rn">, you should see two entries like this:
+
+        <verb>
+Destination        Gateway            Flags     Refs     Use     Netif Expire
+default            10.0.0.2           UGSc        0        0      tun0
+10.0.0.2           10.0.0.1           UH          0        0      tun0
+        </verb>
+
+        <p>This is assuming that you've used the addresses from the
+        handbook, the man page or from the ppp.conf.sample file.
+        If you haven't got a default route, it may be because you're
+        running an old version of <htmlurl
+        url="http://www.freebsd.org/cgi/man.cgi?ppp"
+        name="ppp"> that doesn't understand the
+        word <tt/HISADDR/ in the ppp.conf file.  If your version of
+        <tt/ppp/ is from before FreeBSD 2.2.5, change the
+
+        <verb>
+          add 0 0 HISADDR
+        </verb>
+
+        <p>line to one saying
+
+        <verb>
+          add 0 0 10.0.0.2
+        </verb>
+
+        <p>Another reason for the default route line being missing is that
+        you have mistakenly set up a default router in your
+        <htmlurl url="http://www.freebsd.org/cgi/man.cgi?rc.conf"
+        name="/etc/rc.conf"> file (this file was called
+        <tt>/etc/sysconfig</tt> prior to release 2.2.2), and you have
+        omitted the line saying
+
+        <verb>
+          delete ALL
+        </verb>
+
+        <p>from <tt>ppp.conf</tt>.  If this is the case, go back to the
+        <url url="../handbook/userppp:final.html"
+        name="Final system configuration"> section of the handbook.
+
+      <sect2>
+        <heading>What does "No route to host" mean</heading>
+
+        <p>This error is usually due to a missing
+
+        <verb>
+          MYADDR:
+            delete ALL
+            add 0 0 HISADDR
+        </verb>
+
+        <p>section in your <tt>/etc/ppp/ppp.linkup</tt> file.  This is
+        only necessary if you have a dynamic IP address or don't know the
+        address of your gateway.  If you're using interactive mode, you can
+        type the following after entering <tt/packet mode/ (packet mode is
+        indicated by the capitalized <bf/PPP/ in the prompt):
+
+        <verb>
+          delete ALL
+          add 0 0 HISADDR
+        </verb>
+
+        <p>Refer to the <url url="../handbook/userppp:dynamicIP.html"
+        name="PPP and Dynamic IP addresses"> section of the handbook
+        for further details.
+
+      <sect2>
+        <heading>My connection drops after about 3 minutes</heading>
+
+        <p>The default ppp timeout is 3 minutes.  This can be adjusted
+        with the line
+
+        <verb>
+          set timeout NNN
+        </verb>
+
+        <p>where <bf/NNN/ is the number of seconds of inactivity before the
+        connection is closed.  If <bf/NNN/ is zero, the connection is
+        never closed due to a timeout.  It is possible to put this command in
+        the <tt>ppp.conf</tt> file, or to type it at the prompt in
+        interactive mode.  It is also possible to adjust it on the fly while
+        the line is active by connecting to <tt/ppp/s server socket using
+        <htmlurl url="http://www.freebsd.org/cgi/man.cgi?telnet" name="telnet">
+        or <htmlurl url="http://www.freebsd.org/cgi/man.cgi?pppctl"
+        name="pppctl">.  Refer to the
+        <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp" name="ppp"> man
+        page for further details.
+
+      <sect2>
+        <heading>My connection drops under heavy load</heading>
+
+        <p>If you have Link Quality Reporting (LQR) configured, it is
+        possible that too many LQR packets are lost between your
+        machine and the peer.  Ppp deduces that the line must therefore
+        be bad, and disconnects.  Prior to FreeBSD version 2.2.5,
+        LQR was enabled by default.  It is now disabled by default.
+        LQR can be disabled with the line
+
+        <verb>
+          disable lqr
+        </verb>
+
+      <sect2>
+        <heading>My connection drops after a random amount of time</heading>
+
+        <p>Sometimes, on a noisy phone line or even on a line with
+        call waiting enabled, your modem may hang up because it
+        thinks (incorrectly) that it lost carrier.
+
+        <p>There's a setting on most modems for determining how tolerant
+        it should be to temporary losses of carrier.  On a USR
+        Sportster for example, this is measured by the S10 register in
+        tenths of a second.  To make your modem more forgiving, you could
+        add the following send-expect sequence to your dial string:
+
+        <verb>
+          set dial "...... ATS10=10 OK ......"
+        </verb>
+
+        <p>Refer to your modem manual for details.
+
+      <sect2>
+        <heading>Nothing happens after the Login OK! message</heading>
+
+        <p>Prior to FreeBSD version 2.2.5, once the link was established,
+        <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp"
+        name="ppp"> would wait for the peer to initiate the Line Control
+        Protocol (LCP).  Many ISPs will not initiate negotiations and
+        expect the client to do so.  To force <tt/ppp/ to initiate
+        the LCP, use the following line:
+
+        <verb>
+          set openmode active
+        </verb>
+
+        <p><bf/Note/: It usually does no harm if both sides initiate
+        negotiation, so openmode is now active by default.  However,
+        the next section explains when it <bf/does/ do some harm.
+
+      <sect2>
+        <heading>I keep seeing errors about magic being the same</heading>
+
+        <p>Occasionally, just after connecting, you may see messages in
+        the log that say "magic is the same".  Sometimes, these
+        messages are harmless, and sometimes one side or the other
+        exits.
+
+        <p>This normally happens on server machines with slow disks that
+        are spawning a getty on the port, and executing ppp from a
+        login script or program after login.  The reason is that in
+        the time taken between getty exiting and ppp starting, the
+        client-side ppp starts sending Line Control Protocol (LCP)
+        packets.  Because ECHO is still switched on for the port on
+        the server, the client ppp sees these packets "reflect" back.
+
+        <p>One part of the LCP negotiation is to establish a magic number
+        for each side of the link so that "reflections" can be detected.
+        The protocol says that when the peer tries to negotiate
+        the same magic number, a NAK should be sent and a new magic
+        number should be chosen.  During the period that the server
+        port has ECHO turned on, the client ppp sends LCP packets,
+        sees the same magic in the reflected packet and NAKs it.  It
+        also sees the NAK reflect (which also means ppp must change
+        its magic).  This produces a potentially enormous number of
+        magic number changes, all of which are happily piling into
+        the server's tty buffer.  As soon as ppp starts on the server,
+        it's flooded with magic number changes and almost immediately
+        decides it's tried enough to negotiate LCP and gives up.
+        Meanwhile, the client, who no longer sees the reflections,
+        becomes happy just in time to see a hangup from the server.
+
+        <p>The only way to circumvent this is to put the following line
+        in your ppp.conf file:
+
+        <verb>
+          set openmode passive
+        </verb>
+
+        <p>This tells ppp to wait for the server to initiate LCP negotiations.
+        Some servers may never initiate negotiations.  If this is the case,
+        please report it as a bug (using send-pr).  Ppp will need to be
+        adjusted so that the user can configure a variable delay before
+        initiating LCP negotiations.
+
+      <sect2>
+        <heading>Ppp locks up shortly after connecting</heading>
+
+        <p>Prior to version 2.2.5 of FreeBSD, it was possible that your
+        link was disabled shortly after connection due to <tt/ppp/
+        mis-handling Predictor1 compression negotiation.  This would
+        only happen if both sides tried to negotiate different
+        Compression Control Protocols (CCP).  This problem is now
+        corrected, but if you're still running an old version of
+        <tt/ppp/, the problem can be circumvented with the line
+
+        <verb>
+          disable pred1
+        </verb>
+
+      <sect2>
+        <heading>Ppp locks up when I shell out to test it</heading>
+
+        <p>When you execute the <tt/shell/ or <tt/!/ command, <tt/ppp/
+        executes a shell (or if you've passed any arguements, <tt/ppp/
+        will execute those arguements).  Ppp will wait for the command
+        to complete before continuing.  If you attempt to use the
+        ppp link while running the command, the link will appear to have
+        frozen.  This is because <tt/ppp/ is waiting for the command
+        to complete.
+
+        <p>If you wish to execute commands like this, use the
+        <tt/!bg/ command instead.  This will execute the given command
+        in the background, and ppp can continue to service the link.
+
+      <sect2>
+        <heading>Ppp over a null-modem cable never exits</heading>
+
+        <p>There is no way for <tt/ppp/ to automatically determine that
+        a direct connection has been dropped.  This is due to the
+        lines that are used in a null-modem serial cable.  When using
+        this sort of connection, LQR should always be enabled with
+        the line
+
+        <verb>
+          enable lqr
+        </verb>
+
+        <p>LQR is accepted by default if negotiated by the peer.
+
+      <sect2>
+        <heading>Why does ppp dial for no reason in -auto mode</heading>
+
+        <p>If <tt/ppp/ is dialing unexpectedly, you must determine the
+        cause, and set up Dial filters (dfilters) to prevent such dialing.
+
+        <p>To determine the cause, use the following line:
+
+        <verb>
+          set log +tcp/ip
+        </verb>
+
+        <p>This will log all traffic through the connection.  The next
+        time the line comes up unexpectedly, you will see the reason
+        logged with a convenient timestamp next to it.
+
+        <p>You can now disable dialing under these circumstances.  Usually,
+        this sort of problem arises due to DNS lookups.  To prevent
+        DNS lookups from establishing a connection (this will <bf/not/
+        prevent <tt/ppp/ from passing the packets through an established
+        connection), use the following:
+
+        <verb>
+          set dfilter 1 deny udp src eq 53
+          set dfilter 2 deny udp dst eq 53
+          set dfilter 3 permit 0/0 0/0
+        </verb>
+
+        <p>This is not always suitable, as it will effectively break your
+        demand-dial capabilities - most programs will need a DNS lookup
+        before doing any other network related things.
+
+        <p>In the DNS case, you should try to determine what is actually
+        trying to resolve a host name.  A lot of the time, 
+        <htmlurl url="http://www.freebsd.org/cgi/man.cgi?sendmail"
+        name="sendmail"> is the culprit.  You should make sure that you tell
+        sendmail not to do any DNS lookups in its configuration file.  See
+        the section on <ref id="ispmail" name="Mail Configuration"> for
+        further details.
+
+      <sect2>
+        <heading>What do these CCP errors mean</heading>
+
+        <p>I keep seeing the following errors in my log file:
+
+        <verb>
+          CCP: CcpSendConfigReq
+          CCP: Received Terminate Ack (1) state = Req-Sent (6)
+        </verb>
+
+        <p>This is because ppp is trying to negotiate Predictor1
+        compression, and the peer does not want to negotiate any
+        compression at all.  The messages are harmless, but if you
+        wish to remove them, you can disable Predictor1 compression
+        locally too:
+
+        <verb>
+          disable pred1
+        </verb>
+
+      <sect2>
+        <heading>Ppp locks up during file transfers with IO errors</heading>
+
+        <p>Under FreeBSD 2.2.2 and before, there was a bug in the tun
+        driver that prevents incoming packets of a size larger than
+        the tun interface's MTU size.  Receipt of a packet greater than
+        the MTU size results in an IO error being logged via syslogd.
+
+        <p>The ppp specification says that an MRU of 1500 should
+        <bf>always</bf> be accepted as a minimum, despite any LCP
+        negotiations, therefore it is possible that should you decrease
+        the MTU to less than 1500, your ISP will transmit packets of
+        1500 regardless, and you will tickle this non-feature - locking
+        up your link.
+
+        <p>The problem can be circumvented by never setting an MTU of
+        less than 1500 under FreeBSD 2.2.2 or before.
+
+      <sect2>
+        <heading>Why doesn't ppp log my connection speed?</heading>
+
+        <p>In order to log all lines of your modem ``conversation'',
+        you must enable the following:
+
+        <verb>
+          set log +connect
+        </verb>
+
+        <p>This will make 
+        <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp" name="ppp">
+        log everything up until the last requested "expect" string.
+
+        <p>If you wish to see your connect speed and are using PAP or CHAP
+        (and therefore don't have anything to "chat" after the CONNECT
+        in the dial script - no "set login" script), you must make sure that
+        you instruct ppp to "expect" the whole CONNECT line, something like
+        this:
+
+        <verb>
+          set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n"
+        </verb>
+
+        <p>Here, we get our CONNECT, send nothing, then expect a line-feed,
+        forcing <bf/ppp/ to read the whole CONNECT response.
+
+      <sect2>
+        <heading>None of this helps - I'm desperate !</heading>
+
+        <p>If all else fails, send as much information as you can,
+        including your config files, how you're starting <tt/ppp/,
+        the relevent parts of your log file and the output of the
+        <htmlurl url="http://www.freebsd.org/cgi/man.cgi?netstat"
+        name="netstat -rn"> command (before and after connecting)  to the
+        <url url="mailto:freebsd-questions@FreeBSD.org"
+        name="freebsd-questions@FreeBSD.org"> mailing list or the
+        <url url="news:comp.unix.bsd.freebsd.misc"
+        name="comp.unix.bsd.freebsd.misc"> news group, and someone
+        should point you in the right direction.
+
+    <sect1>
+      <heading>I can't create a <tt>/dev/ed0</tt> device!</heading>
+
+      <p>In the Berkeley networking framework, network interfaces are only
+      directly accessible by kernel code.  Please see the
+      <tt>/etc/rc.network</tt> file and the manual pages for the various
+      network programs mentioned there for more information.  If this
+      leaves you totally confused, then you should pick up a book
+      describing network administration on another BSD-related
+      operating system; with few significant exceptions, administering
+      networking on FreeBSD is basically the same as on SunOS 4.0 or
+      Ultrix.
+
+    <sect1>
+      <heading>How can I setup Ethernet aliases?</heading>
+
+      <p>Add ``<tt/netmask 0xffffffff/'' to your <htmlurl 
+      url="http://www.freebsd.org/cgi/man.cgi?ifconfig" name="ifconfig">
+      command-line like the following:
+
+      <verb>
+        ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff
+      </verb>
+
+    <sect1>
+      <heading>How do I get my 3C503 to use the other network port?</heading>
+
+      <p>If you want to use the other ports, you'll have to specify an
+      additional parameter on the 
+      <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ifconfig"
+      name="ifconfig"> command line. The
+      default port is ``<tt/link0/''. To use the AUI port instead of
+      the BNC one, use ``<tt/link2/''.  These flags should be specified
+      using the ifconfig_* variables in <htmlurl
+      url="http://www.freebsd.org/cgi/man.cgi?rc.conf" name="/etc/rc.conf">.
+
+    <sect1>
+      <heading>I'm having problems with NFS to/from FreeBSD.</heading>
+
+      <p>Certain PC network cards are better than others (to put it
+      mildly) and can sometimes cause problems with network intensive
+      applications like NFS.
+
+      <p>See <url url="../handbook/nfs.html" name="the Handbook entry on NFS">
+      for more information on this topic.
+
+    <sect1>
+      <heading>Why can't I NFS-mount from a Linux box?</heading>
+
+      <p>Some versions of the Linux NFS code only accept mount requests
+      from a privileged port; try
+
+      <verb>
+        mount -o -P linuxbox:/blah /mnt
+      </verb>
+
+    <sect1>
+      <heading>Why can't I NFS-mount from a Sun box?</heading>
+
+      <p>Sun workstations running SunOS 4.X only accept mount requests
+      from a privileged port; try
+
+      <verb>
+        mount -o -P sunbox:/blah /mnt
+      </verb>
+
+    <sect1>
+      <heading>I'm having problems talking PPP to NeXTStep machines.</heading>
+
+      <p>Try disabling the TCP extensions in <htmlurl
+      url="http://www.freebsd.org/cgi/man.cgi?rc.conf" name="/etc/rc.conf"> by
+      changing the following variable to NO:
+
+      <verb>
+        tcp_extensions=NO
+      </verb>
+
+      <p>Xylogic's Annex boxes are also broken in this regard and you must
+      use the above change to connect thru them.
+
+    <sect1>
+      <heading>How do I enable IP multicast support?</heading>
+
+      <p>Multicast host operations are fully supported in FreeBSD 2.0 and
+      above by default.  If you want your box to run as a multicast router, you
+      will need to load the <tt/ip_mroute_mod/ loadable kernel module
+      and run <tt/mrouted/.
+
+      <p>For more information:
+
+      <verb>
+Product		Description		Where
+--------------- ----------------------- ---------------------------------------
+faq.txt		Mbone FAQ		ftp.isi.edu:/mbone/faq.txt
+imm/immserv	IMage Multicast 	ftp.hawaii.edu:/paccom/imm.src.tar.Z
+        	for jpg/gif images.
+nv		Network Video.		ftp.parc.xerox.com:
+        				/pub/net-reseach/exp/nv3.3alpha.tar.Z
+vat		LBL Visual Audio Tool.	ftp.ee.lbl.gov:
+        				/conferencing/vat/i386-vat.tar.Z
+wb		LBL White Board.	ftp.ee.lbl.gov:
+        				/conferencing/wb/i386-wb.tar.Z
+mmcc		MultiMedia Conference	ftp.isi.edu:
+        	Control program		/confctrl/mmcc/mmcc-intel.tar.Z
+rtpqual		Tools for testing the	ftp.psc.edu:/pub/net_tools/rtpqual.c
+        	quality of RTP packets.
+vat_nv_record	Recording tools for vat ftp.sics.se:archive/vat_nv_record.tar.Z
+        	and nv.
+      </verb>
+
+    <sect1>
+      <heading>Which network cards are based on the DEC PCI chipset?</heading>
+
+      <p>Here is a list compiled by <url url="mailto:gfoster@driver.nsta.org"
+      name="Glen Foster">:
+
+      <verb>
+        Vendor          Model
+        ----------------------------------------------
+        ASUS            PCI-L101-TB
+        Accton          ENI1203
+        Cogent          EM960PCI
+        Compex          ENET32-PCI
+        D-Link          DE-530
+        DEC             DE435
+        Danpex          EN-9400P3
+        JCIS            Condor JC1260
+        Linksys         EtherPCI
+        Mylex           LNP101
+        SMC             EtherPower 10/100 (Model 9332)
+        SMC             EtherPower (Model 8432)
+        TopWare         TE-3500P
+        Zynx            ZX342
+      </verb>
+
+    <sect1>
+      <heading>Why do I have to use the FQDN for hosts on my site?</heading>
+
+      <p>You will probably find that the host is actually in a different
+      domain; for example, if you are in foo.bar.edu and you wish to reach
+      a host called ``mumble'' in the bar.edu domain, you will have to
+      refer to it by the fully-qualified domain name, ``mumble.bar.edu'',
+      instead of just ``mumble''.
+
+      <p>Traditionally, this was allowed by BSD BIND resolvers. However
+      the current version of <htmlurl
+      url="http://www.freebsd.org/cgi/man.cgi?named" name="bind"> that ships
+      with FreeBSD no longer provides default abbreviations for non-fully
+      qualified domain names other than the domain you are in.
+      So an unqualified host <tt>mumble</tt> must either be found
+      as <tt>mumble.foo.bar.edu</tt>, or it will be searched for
+      in the root domain.
+
+      <p>This is different from the previous behavior, where the
+      search continued across <tt>mumble.bar.edu</tt>, and
+      <tt>mumble.edu</tt>.  Have a look at RFC 1535 for why this
+      was considered bad practice, or even a security hole.
+
+      <p>As a good workaround, you can place the line
+
+      <verb>
+        search foo.bar.edu bar.edu
+      </verb>
+
+      <p>instead of the previous
+
+      <verb>
+        domain foo.bar.edu
+      </verb>
+
+      <p>into your <htmlurl url="http://www.freebsd.org/cgi/man.cgi?resolv.conf"
+      name="/etc/resolv.conf"> file.  However, make sure that the search order
+      does not go beyond the ``boundary between local and public
+      administration'', as RFC 1535 calls it.
+
+    <sect1>
+      <heading>``Permission denied'' for all networking operations.</heading>
+
+      <p>If you have compiled your kernel with the <tt/IPFIREWALL/
+      option, you need to be aware that the default policy as of
+      2.1.7R (this actually changed during 2.1-STABLE development)
+      is to deny all packets that are not explicitly allowed.
+
+      <p>If you had unintentionally misconfigured your system for
+      firewalling, you can restore network operability by typing
+      the following while logged in as root:
+
+      <verb>
+        ipfw add 65534 allow all from any to any
+      </verb>
+
+      <p>For further information on configuring a FreeBSD firewall,
+      see the <url url="../handbook/firewalls.html" name="Handbook section">.
+
+  </sect>
+