path: root/FAQ/network.sgml

<!-- $Id: network.sgml,v 1.20 1999-01-27 10:01:08 mbarkah 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="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 <bf/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 just hangs when I run it</heading>

        <p>This is usually because your hostname won't resolve.  The best
        way to fix this is to make sure that <tt>/etc/hosts</tt> is
        consoluted by your resolver first by editing <tt>/etc/host.conf</tt>
        and putting the <tt>hosts</tt> line first.  Then, simply put an
        entry in <tt>/etc/hosts</tt> for your local machine.  If you have
        no local network, change your <tt>localhost</tt> line:

        <verb>
127.0.0.1	foo.bar.com foo localhost
        </verb>

        Otherwise, simply add another entry for your host.  Consult the
        relevant man pages for more details.
        <p>You should be able to successfully <tt>ping -c1 `hostname`</tt>
        when you're done.

      <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
        <bf/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 <bf/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 <bf/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.  Most ppp implementations cannot survive this problem, and
        even if the link seems to come up, you'll see repeated configure
        requests and configure acknowledgements in the log file until
        ppp eventually gives up and closes the connection.

        <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.  I've also heard reports
        of it happening consistently when using slirp.  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>This can be avoided by allowing the peer to start negotiating
        with 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 however may never initiate negotiations.
        If this is the case, you can do something like:

        <verb>
          set openmode active 3
        </verb>

        <p>This tells ppp to be passive for 3 seconds, and then to start
        sending LCP requests.  If the peer starts sending requests during
        this period, ppp will immediately respond rather than waiting for
        the full 3 second period.

      <sect2>
        <heading>
          LCP negotiations continue 'till the connection is closed
        </heading>

        <p>There is currently an implementation mis-feature in <bf/ppp/
        where it doesn't associate LCP, CCP &amp; IPCP responses with
        their original requests.  As a result, if one <bf/ppp/
        implementation is more than 6 seconds slower than the other side,
        the other side will send two additional LCP configuration requests.
        This is fatal.

        Consider two implementations, <bf/A/ and <bf/B/.  <bf/A/ starts
        sending LCP requests immediately after connecting and <bf/B/ takes
        7 seconds to start.  When <bf/B/ starts, <bf/A/ has sent 3 LCP
        REQs.  We're assuming the line has ECHO switched off, otherwise
        we'd see magic number problems as described in the previous section.
        <bf/B/ sends a REQ, then an ACK to the first of <bf/A/'s REQs.
        This results in <bf/A/ entering the <bf/OPENED/ state and sending
        and ACK (the first) back to <bf/B/.  In the meantime, <bf/B/ sends
        back two more ACKs in response to the two additional REQs sent by
        <bf/A/ before <bf/B/ started up.  <bf/B/ then receives the first
        ACK from <bf/A/ and enters the <bf/OPENED/ state.  <bf/A/ receives
        the second ACK from <bf/B/ and goes back to the <bf/REQ-SENT/ state,
        sending another (forth) REQ as per the RFC.  It then receives the
        third ACK and enters the <bf/OPENED/ state.  In the meantime,
        <bf/B/ receives the forth REQ from <bf/A/, resulting in it reverting
        to the <bf/ACK-SENT/ state and sending another (second) REQ and
        (forth) ACK as per the RFC.  <bf/A/ gets the REQ, goes into
        <bf/REQ-SENT/ and sends another REQ.  It immediately receives the
        following ACK and enters <bf/OPENED/.

        <p>This goes on 'till one side figures out that they're getting
        nowhere and gives up.

        <p>The best way to avoid this is to configure one side to be
        <bf/passive/ - that is, make one side wait for the other to start
        negotiating.  This can be done with the

        <verb>
          set openmode passive
        </verb>

        command.  Care should be taken with this option.  You should also
        use the

        <verb>
          set stopped N
        </verb>

        command to limit the amount of time that <bf/ppp/ waits for the peer
        to begin negotiations.  Alternatively, the

        <verb>
          set openmode active N
        </verb>

        command (where <bf/N/ is the number of seconds to wait before
        starting negotiations) can be used.  Check the manual page for
        details.

      <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 <bf/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
        <bf/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, <bf/ppp/
        executes a shell (or if you've passed any arguements, <bf/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 <bf/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 <bf/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 <bf/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 <bf/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
        details on how to create your own configuration file and what should
        go into it.  You may also want to add the following line to your
        <bf/.mc/ file:

        <verb>
          define(`confDELIVERY_MODE', `d')dnl
        </verb>

        <p>This will make sendmail queue everything until the queue is
        run (usually, sendmail is invoked with ``-bd -q30m'', telling it
        to run the queue every 30 minutes) or until a ``sendmail -q''
        is done (perhaps from your ppp.linkup file).

      <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>Ppp ignores the `\' character in my chat script</heading>

        <p>Ppp parses each line in your config files so that it can
        interpret strings such as <tt/set phone "123 456 789"/ correctly
        (and realize that the number is actually only <bf/one/ argument.
        In order to specify a ``"'' character, you must escape it using
        a backslash (``\'').

        <p>When the chat interpreter parses each argument, it re-interprets
        the argument in order to find any special escape sequences such
        as ``\P'' or ``\T'' (see the man page).  As a result of this
        double-parsing, you must remember to use the correct number of
        escapes.

        <p>If you wish to actually send a ``\'' character to (say) your
        modem, you'd need something like:

        <verb>
          set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK"
        </verb>

        <p>resulting in the following sequence:

        <verb>
          ATZ
          OK
          AT\X
          OK
        </verb>

        <p>or

        <verb>
          set phone 1234567
          set dial "\"\" ATZ OK ATDT\\T"
        </verb>

        <p>resulting in the following sequence:

        <verb>
          ATZ
          OK
          ATDT1234567
        </verb>

      <sect2>
        <heading>Ppp gets a seg-fault, but I see no <tt/ppp.core/ file</heading>

        <p>Ppp (or any other program for that matter) should never
        dump core.  Because ppp runs with an effective user id of 0,
        the operating system will not write ppps core image to disk
        before terminating it.  If, however ppp <bf/is/ actually
        termating due to a segmentation violation or some other
        signal that normally causes core to be dumped, <bf/and/ you're
        sure you're using the latest version (see the start of this
        section), then you should do the following:

        <verb>
          $ tar xfz ppp-*.src.tar.gz
          $ cd ppp*/ppp
          $ echo STRIP= >>Makefile
          $ echo CFLAGS+=-g >>Makefile
          $ make clean all
          $ su
          # make install
          # chmod 555 /usr/sbin/ppp
        </verb>

        <p>You will now have a debuggable version of ppp installed.  You
        will have to be root to run ppp as all of its privileges have
        been revoked.  When you start ppp, take a careful note of what
        your current directory was at the time.

        <p>Now, if and when ppp receives the segmentation violation, it
        will dump a core file called ppp.core.  You should then do the
        following:

        <verb>
          $ su
          # gdb /usr/sbin/ppp ppp.core
          (gdb) bt
          .....
          (gdb) f 0
          .....
          (gdb) i args
          .....
          (gdb) l
          .....
        </verb>

        <p>All of this information should be given alongside your
        question, making it possible to diagnose the problem.
        <p>If you're familiar with gdb, you may wish to find out some
        other bits and pieces such as what actually caused the dump and
        the addresses & values of the relevant variables.

      <sect2>
        <heading>
          The process that forces a dial in auto mode never connects
        </heading>

        <p>This was a known problem with <bf/ppp/ set up to negotiate
        a dynamic local IP number with the peer in auto mode.  It is
        fixed in the latest version - search the man page for <bf/iface/.

        <p>The problem was that when that initial program calls
        <htmlurl url="http://www.freebsd.org/cgi/man.cgi?connect"
        name="connect(2)">, the IP number of the tun interface is
        assigned to the socket endpoint.  The kernel creates the first
        outgoing packet and writes it to the tun device.  <bf/Ppp/ then
        reads the packet and establishes a connection.  If, as a result
        of <bf/ppp/s dynamic IP assignment, the interface address is changed,
        the original socket endpoint will be invalid.  Any subsequent
        packets sent to the peer will usually be dropped.  Even if
        they aren't, any responses will not route back to the originating
        machine as the IP number is no longer owned by that machine.

        <p>There are several theoretical ways to approach this problem.
        It would be nicest if the peer would re-assign the same IP number
        if possible <tt/:-)/  The current version of <bf/ppp/ does this,
        but most other implementations don't.

        <p>The easiest method from our side would be to never change the
        tun interface IP number, but instead to change all outgoing packets
        so that the source IP number is changed from the interface IP to
        the negotiated IP on the fly.  This is essentially what the
        <tt/iface-alias/ option in the latest version of <bf/ppp/ is
        doing (with the help of <htmlurl
        url="http://www.freebsd.org/cgi/man.cgi?libalias" name="libalias(3)">
        and ppp's <bf/-alias/ switch) - it's maintaining all previous
        interface addresses and aliasing them to the last negotiated address.

        <p>Another alternative (and probably the most reliable) would be
        to implement a system call that changes all bound sockets from one
        IP to another.  <bf/Ppp/ would use this call to modify the
        sockets of all existing programs when a new IP number is
        negotiated.  The same system call could be used by dhcp clients
        when they are forced to re-bind() their sockets.

        <p>Yet another possibility is to allow an interface to be brought
        up without an IP number.  Outgoing packets would be given
        an IP number of 255.255.255.255 up until the first SIOCAIFADDR
        ioctl is done.  This would result in fully binding the socket.  It
        would be up to <bf/ppp/ to change the source IP number, but only if
        it's set to 255.255.255.255, and only the IP number and IP checksum
        would need to change.  This, however is a bit of a hack as
        the kernel would be sending bad packets to an improperly
        configured interface, on the assumption that some other mechanism
        is capable of fixing things retrospectively.

      <sect2>
        <heading>Why don't most games work with the -alias switch</heading>

        <p>The reason games and the like don't work when libalias is
        in use is that the machine on the outside will try to open a
        connection or send (unsolicited) UDP packets to the machine
        on the inside.  The packet alias software doesn't know that
        it should send these packets to the interior machine.

        <p>To make things work, make sure that the only thing running
        is the software that you're having problems with, then either
        run tcpdump on the tun interface of the gateway or enable ppp
        tcp/ip logging (``set log +tcp/ip'') on the gateway.

        <p>When you start the offending software, you should see packets
        passing through the gateway machine.  When something comes back
        from the outside, it'll be dropped (that's the problem).  Note
        the port number of these packets then shut down the offending
        software.  Do this a few times to see if the port numbers are
        consistent.  If they are, then the following line in the relevant
        section of /etc/ppp/ppp.conf will make the software functional:

        <verb>
          alias port proto internalmachine:port port
        </verb>

        <p>where ``proto'' is either ``tcp'' or ``udp'',
        ``internalmachine'' is the machine that you want the packets
        to be sent to and ``port'' is the destination port number of
        the packets.

        <p>You won't be able to use the software on other machines
        without changing the above command, and running the software
        on two internal machines at the same time is out of the question
        - after all, the outside world is seeing your entire internal
        network as being just a single machine.

        <p>If the port numbers aren't consistent, there are three more
        options:

        <p><bf>1)</bf> Submit support in libalias.  Examples of ``special
        cases'' can be found in /usr/src/lib/libalias/alias_*.c (alias_ftp.c
        is a good prototype).  This usually involves reading certain
        recognised outgoing packets, identifying the instruction that
        tells the outside machine to initiate a connection back to the
        internal machine on a specific (random) port and setting up a
        ``route'' in the alias table so that the subsequent packets
        know where to go.

        <p>This is the most difficult solution, but it is the best and
        will make the software work with multiple machines.

        <p><bf>2)</bf> Use a proxy.  The application may support socks5
        for example, or (as in the ``cvsup'' case) may have a ``passive''
        option that avoids ever requesting that the peer open connections
        back to the local machine.

        <p><bf>3)</bf> Redirect everything to the internal machine using
        ``alias addr''.  This is the sledge-hammer approach.

      <sect2>
        <heading>What are FCS errors ?</heading>

        <p>FCS stands for <bf/F/rame <bf/C/heck <bf/S/equence.  Each
        ppp packet has a checksum attached to ensure that the data
        being received is the data being sent.  If the FCS of an
        incoming packet is incorrect, the packet is dropped and the
        HDLC FCS count is increased.  The HDLC error values can be
        displayed using the <tt>show hdlc</tt> command.

        <p>If your link is bad (or if your serial driver is dropping
        packets), you will see the occasional FCS error.  This is not
        usually worth worrying about although it does slow down the
        compression protocols substantially.  If you have an external
        modem, make sure your cable is properly shielded from
        interference - this may eradicate the problem.

        <p>If your link freezes as soon as you've connected and you see
        a large number of FCS errors, this may be because your link is
        not 8 bit clean.  Make sure your modem is not using software
        flow control (XON/XOFF).  If your datalink <bf>must</bf> use
        software flow control, use the command
        <tt>set accmap 0x000a0000</tt> to tell <bf>ppp</bf> to escape
        the ^Q and ^S characters.

        <p>Another reason for seeing too many FCS errors may be that
        the remote end has stopped talking <bf/PPP/.  You may want to
        enable <tt/async/ logging at this point to determine if the
        incoming data is actually a login or shell prompt.  If you
        have a shell prompt at the remote end, it's possible to
        terminate ppp without dropping the line by using the
        <tt>close lcp</tt> command (a following <tt>term</tt> command
        will reconnect you to the shell on the remote machine.

        <p>If nothing in your log file indicates why the link might
        have been terminated, you should ask the remote administrator
        (your ISP?) why the session was terminated.

      <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 <bf/ppp/,
        the relevant 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
      later by default.  If you want your box to run as a multicast router, 
      you will need to recompile your kernel with the <tt>MROUTING</tt>
      option and run <tt/mrouted/.  FreeBSD 2.2 and later will start
      <tt/mrouted/ at boot time if the flag <tt/mrouted_enable/ is set 
      to "YES" in <tt>/etc/rc.conf</tt>.

      <p>MBONE tools are available in their own ports category, mbone.  If 
      you are looking for the conference tools <tt/vic/ and <tt/vat/, 
      look there!

      <p>For more information, see the 
      <url url="http://www.mbone.com/" name="Mbone Information Web">.

    <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">, with some more modern additions:

      <verb>
        Vendor          Model
        ----------------------------------------------
        ASUS            PCI-L101-TB
        Accton          ENI1203
        Cogent          EM960PCI
        Compex          ENET32-PCI
        D-Link          DE-530
        Dayna           DP1203, DP2100
        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>You can also set "firewall_type='open'" in <tt>/etc/rc.conf</tt>.

      <p>For further information on configuring a FreeBSD firewall,
      see the <url url="../handbook/firewalls.html" name="Handbook section">.

    <sect1>
      <heading>How much overhead does IPFW incur?</heading>

      <p>The answer to this depends mostly on your rule set and processor
      speed.  For most applications dealing with ethernet and small
      rule sets, the answer is, negligible.  For those of you that need
      actual measurements to satisfy your curiosity, read on.

      <p>The following measurements were made using 2.2.5-STABLE on
      a 486-66.  IPFW was modified to measure the time spent within
      the <tt/ip_fw_chk/ routine, displaying the results to the console
      every 1000 packets.

      <p>Two rule sets, each with 1000 rules were tested.  The first set
      was designed to demonstrate a worst case scenario by repeating the
      rule:

      <verb>
        ipfw add deny tcp from any to any 55555
      </verb>

      <p>This demonstrates worst case by causing most of IPFW's packet
      check routine to be executed before finally deciding that the
      packet does not match the rule (by virtue of the port number).
      Following the 999th iteration of this rule was an <tt>allow ip
      from any to any</tt>.

      <p>The second set of rules were designed to abort the rule
      check quickly:

      <verb>
        ipfw add deny ip from 1.2.3.4 to 1.2.3.4
      </verb>

      <p>The nonmatching source IP address for the above rule causes
      these rules to be skipped very quickly.  As before, the 1000th
      rule was an <tt>allow ip from any to any</tt>.

      <p>The per-packet processing overhead in the former case was
      approximately 2.703ms/packet, or roughly 2.7 microseconds per
      rule.  Thus the theoretical packet processing limit with these
      rules is around 370 packets per second.  Assuming 10Mbps ethernet
      and a ~1500 byte packet size, we would only be able to achieve a
      55.5% bandwidth utilization.

      <p>For the latter case each packet was processed in
      approximately 1.172ms, or roughly 1.2 microseconds per rule.
      The theoretical packet processing limit here would be about
      853 packets per second, which could consume 10Mbps ethernet
      bandwidth.

      <p>The excessive number of rules tested and the nature of those
      rules do not provide a real-world scenario -- they were used only
      to generate the timing information presented here.  Here are a
      few things to keep in mind when building an efficient rule set:

      <itemize>

        <item>Place an `established' rule early on to handle the
        majority of TCP traffic.  Don't put any <tt>allow tcp</tt>
        statements before this rule.

        <item>Place heavily triggered rules earlier in the rule
        set than those rarely used (<bf>without changing the
        permissiveness of the firewall</bf>, of course).  You can see
        which rules are used most often by examining the packet counting
        statistics with <tt>ipfw -a l</tt>.

      </itemize>

    <sect1>
      <heading>How can I redirect service requests from one machine to another?
      </heading>

      <p>You can redirect FTP (and other service) request with the 'socket'
      package, available in the ports tree in category 'sysutils'.  
      Simply replace the service's commandline to call socket instead, like so:

<verb>
ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.foo.com ftp
</verb>

      <p>where 'ftp.foo.com' and 'ftp' are the host and port to redirect to,
      respectively.
    
     <sect1>
       <heading>Where can I get a bandwidth management tool?</heading>

       <p>There are two bandwidth management tools available for FreeBSD. 
       <url url="http://www.csl.sony.co.jp/person/kjc/programs.html" 
        name="ALTQ"> is available for free; Bandwidth Manager from
       <url url="http://www.etinc.com" name="Emerging Technologies"> is
       a commercial product. 

     <sect1>
       <heading>Why do I get ``/dev/bpf0: device not configured"?</heading>

       <p>The Berkeley Packet Filter <htmlurl
       url="http://www.FreeBSD.org/cgi/man.cgi?bpf" name="(bpf)"> driver
       needs to be enabled before running programs that utilize it. 
       Add this to your kernel config file and build a new kernel:

       <verb>
	 pseudo-device bpfilter		# Berkeley Packet Filter
       </verb>

       <p>Secondly, after rebooting you will have to create the device
       node. This can be accomplished by a change to the <tt>/dev</tt>
       directory, followed by the execution of:

       <tscreen><verb>
       # sh MAKEDEV bpf0
       </verb></tscreen>

       <p>Please see the <htmlurl url="../handbook/kernelconfig:nodes.html"
       name="handbook's entry on device nodes"> for more information
       on creating devices.

  </sect>