path: root/zh_TW.Big5/FAQ/network.sgml

<!-- $Id: network.sgml,v 1.2 1999-02-16 14:20:18 vanilla Exp $ -->
<!-- The FreeBSD Documentation Project -->
<!-- Translate into Chinese by wing@cc.nsysu.edu.tw -->
<!-- English Version: 1.20 -->

  <sect>
    <heading>Networking<label id="networking"></heading>

    <sect1>
      <heading>§ÚÀ³¸Ó¨ì­þÃä§ä¦³ÃöµLºÏºÐ¶}¾÷ (diskless booting) ªº¸ê®Æ?</heading>

      <p>µLºÏºÐ¶}¾÷´N¬OÅý FreeBSD ¥D¾÷±qºô¸ô¤W¶}¾÷,¨Ã¥B±qºô¸ô¤Wªº server ¤WŪ¨ú
      ¨ä¥L¥²­nªºÀÉ®×,¦Ó«D¥Ñ¥D¾÷ªºµwºÐ¤W¨ú±o³o¨ÇÀɮסC ¸Ô²Óªº¸ê®Æ¥i¥H°Ñ¦Ò
      <url url="../handbook/diskless.html"
      name="FreeBSD ¤â¥UªºµLºÏºÐ¶}¾÷½g">

    <sect1>
      <heading>
        FreeBSD ªº¥D¾÷¥i¥H·í§@¬Y­Óºô¸ô¤Wªº¸ô¥Ñ¾¹ (router) ¶Ü ?
      </heading>

      <p>¥Ñ©óºô»Úºô¸ôªº¼Ð·Ç¤Æ©Mµ{¦¡³]­pªº¥R¤À¸gÅ礧½ç,§Ú­Ì
      ¯à°÷¦b FreeBSD ¨t²Î¤º«Ø«Ê¥]Âà¶Ç (packet fowarding) ªº¥\¯à¡C§A¥i¥H
      ±N³o­Ó¥\¯à¥´¶},¥u­n±N³o­ÓÅܼƳ]©w¬°
      <tt/YES/ ¦b <htmlurl url="http://www.freebsd.org/cgi/man.cgi?rc.conf"
      name="rc.conf">³o­ÓÀɮפ¤

      <verb>
        gateway_enable=YES          # Set to YES if this host will be a gateway
      </verb>

      <p>³o­Ó¿ï¶µ·|±N <htmlurl 
      url="http://www.freebsd.org/cgi/man.cgi?sysctl" name="sysctl"> ÅܼƳ]©w
      <tt/net.inet.ip.forwarding/ ¬° <tt/1/.

      <p>¦b¤j³¡¤Àªºª¬ªp¤U, §AÁÙ¥²¶·¦A¶]¤@­Ó³B²z routing ªºµ{¦¡,§i¶Dºô¸ô¤Wªº¨ä¥L
      ¥D¾÷Ãö©ó§Aªº router ³]©wªº¸ê®Æ; FreeBSD
      ¥X¼t®É«K¤ºªþ¤@­Ó¼Ð·Çªº BSD routing µ{¦¡ 
      <htmlurl url="http://www.freebsd.org/cgi/man.cgi?routed"
      name="routed">, ¦pªG§Aªººô¸ô³]©w§ó¬°½ÆÂø,§A¥i¥H¸Õ¸Õ¬Ý
      <em/GaTeD/ (¥i¥H¥H FTP ¤è¦¡¥Ñ <tt/ftp.gated.Merit.EDU/ ¤U¸ü) 
      ³o­Óµ{¦¡¦Û 3_5Alpha7 «á¤ä´© FreeBSD .

      <p>§Ú­Ì¦³¥²­n§i¶D§A,´Nºâ¬O FreeBSD ¥H³oºØ¤è¦¡³]©w§¹¦¨
      , ¥¦ÁÙ¬OµLªk§¹¥þº¡¨¬ Internet ¹ï router ªº¼Ð·Ç©w¸q
      ;¤£¹L, ´N¤é±`¨Ï¥Î¦Ó¨¥¥¦¤w¸g¨¬°÷À³¥I¨Ï¥ÎªÌªº»Ý¨D¤F¡C

    <sect1>
      <heading>§Ú¥i¥H³z¹L FreeBSD ±N§Úªº Win95 ¾÷¾¹³s¤W Internet ¶Ü?</heading>

      <p>°ò¥»¤W, ·|°Ý³oºØ°ÝÃDªº¤H¦b®a¸Ì¦Ü¤Ö¦³¨â¥x¹q¸£, ¤@¥x¶] FreeBSD
      ¥t¥~¤@¥x¶] Win95; ³o­Ó¥D·N¬O±N FreeBSD ¥D¾÷³s¤W Internet
      ,µM«á³z¹L³o¥x FreeBSD ¥D¾÷,Åý¶] Win95 ªº¹q¸£¯à°÷¤Wºô¡C
      ³o­Ó°ÝÃDºâ¬O«e¤@­Ó°ÝÃDªº¤@­Ó¯S¨Ò¡C

      <p>³oÃ䦳­«­nªº¤å¥ó,±Ð§A«ç»ò§â FreeBSD ªº¥D¾÷³]©w¦¨
      <url url="http://www.ssimicro.com/~jeremyc/ppp.html"
      name="PPP Dialup Router">

      <p><bf/ª`·N:/ ¦b³oºØª¬ªp¤U§A¦Ü¤Ö­n¦³¨â­Ó¥H¤Wªº©T©w IP addresses
      , ¦³®É¬O¤T­Ó¥H¤W©Î§ó¦h²Õ IP ¦P®É¨Ï¥Î, µø§Aªº»Ý¨D¦Ó©w¡C
      ¦pªG§A¨S¦³©T©wªº IP ¥i¥H¨Ï¥Î,§A¥i¥H¦Ò¼{¨Ï¥Î private IP
      ¤lºô¸ô,¨Ã¦w¸Ë <bf/proxies/ ¨Ò¦p
      <url url="http://squid.nlanr.net/Squid/" name="SQUID"> ©Î¬O
      <url url="http://www.tis.com/" name="the TIS firewall toolkit">
      ¦b§Aªº FreeBSD ¥D¾÷¤W¡C

      <p>¥t¥~¥i¥H°Ñ¦Ò <ref id="natd">.

    <sect1>
      <heading>
        ¬°¤°»ò§Ú¦b compile ISC ³Ì·sª©ªº BIND µ{¦¡®É¦Ñ¬O¥¢±Ñ?
      </heading>

      <p>¦b ``<tt/cdefs.h/'' Àɮפ¤ªº©w¸q»P FreeBSD ¨t²Î¤¤¤ºªþ
      ªºÀɮשw¸q¦³©Ò½Ä¬ð¡Cª½±µ§â
      <tt>compat/include/sys/cdefs.h</tt> ¬å±¼´N¥i¥H¤F¡C

    <sect1>
      <heading>FreeBSD ¤ä´© SLIP ©M PPP ¶Ü?</heading>

      <p>¬Oªº¡C §A¥i¥H¬d¬d man pages ¤¤Ãö©ó 
      <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"> ¥H¤Î 
      <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp" name="ppp"> ªº»¡©ú.
      <tt/pppd/ ©M <tt/ppp/ ³£´£¨Ñ¼·¶i¤Î¼·¥Xªº¥\¯à¡C
      <htmlurl url="http://www.freebsd.org/cgi/man.cgi?sliplogin"
      name="Sliplogin"> ±Mªù³B²z¦³Ãö¼·¤Jªº¥\¯à,¦Ó
      <htmlurl url="http://www.freebsd.org/cgi/man.cgi?slattach"
      name="slattach"> ³B²z¦³Ãö¼·¥Xªº¥\¯à¡C

      <p>³o¨Çµ{¦¡¦³¸Ô²Óªº»¡©ú,§A¥i¥H¦b
      <url url="../handbook/handbook.html" name="handbook">¤¤§ä¨ì:

      <itemize>
        <item><url url="../handbook/slips.html"
        name="SLIP (server ºÝ) ªº»¡©ú">

        <item><url url="../handbook/slipc.html"
        name="SLIP (client ºÝ) ªº»¡©ú">

        <item><url url="../handbook/ppp.html"
        name="PPP (kernel ¼Ò¦¡) ªº»¡©ú">

        <item><url url="../handbook/userppp.html"
        name="PPP (¨Ï¥ÎªÌ¼Ò¦¡) ªº»¡©ú">
      </itemize>

      <p>¦pªG§A¥u¯àÂÇ¥Ñ"shell account"ªº¤è¦¡¤Wºôªº¸Ü,
      §A¥i¯à·|·Q¬Ý¬Ý <htmlurl
      url="http://www.freebsd.org/cgi/ports.cgi?^slirp" name="slirp">
      ³o­Ó³nÅé¡C ¥¦¥i¥HÅý§Aªº¹q¸£ª½±µ³s¤W (¬Y¨Ç) ªA°È,
      ¨Ò¦p ftp ©M http µ¥µ¥¡C

    <sect1>
      <heading>
        FreeBSD ¤ä´© NAT ©Î Masquerading ¶Ü?<label id="natd">
      </heading>

      <p>¦pªG§A¦³¤@­ÓªñºÝªº¤lºô¸ô(¦³¤@¥x¥H¤Wªº¾÷¾¹), ¦ý¬O§Aªº Internet provider
      «o¥u¤À°t¤@­Ó IP number µ¹§A
      (©ÎªÌ§A¥u¤À°t¨ì¤@­Ó°ÊºAªº IP number), §A¥i¥H°Ñ¦Ò
      <htmlurl url="http://www.freebsd.org/cgi/man.cgi?natd" name="natd">
      ³o­Óµ{¦¡¡C  <tt/Natd/ Åý§A¥i¥H³z¹L³o¤@­Ó IP number Åý¾ã­Ó¤lºô¸ôªº¹q¸£³£¯à
      ³s¤W internet ¡C

      <p><htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp"
      name="ppp"> ³o­Óµ{¦¡¤]´£¨ÑÃþ¦üªº¥\¯à , ¦pªG§A¤U
      <tt/-alias/ ³o­Ó¿ï¶µªº¸Ü¡C  <htmlurl
      url="http://www.freebsd.org/cgi/man.cgi?libalias" name="alias library">
      ¦b³o¨â­Ó³B²z¤è¦¡¤¤³£·|³Q¨Ï¥Î¨ì¡C

    <sect1>
      <heading>
        §Ú¤£¯à¨Ï¥Î ppp ,§Ú°µ¿ù¤F¤°»ò¶Ü ?<label id="userppp">
      </heading>

      <p>§AÀ³¸Ó¥ý¬Ý¬Ý <htmlurl
      url="http://www.freebsd.org/cgi/man.cgi?ppp" name="ppp man page"> ©M
      <url url="../handbook/userppp.html"
      name="ppp ¨Ï¥Î»¡©ú">.  ¨Ï¥Î¥H¤U«ü¥O¨Ó¥´¶}°O¿ý (logging) ªº¥\¯à

      <verb>
        set log Phase Chat Connect Carrier lcp ipcp ccp command
      </verb>

      <p>³o­Ó©R¥O¥i¥H¦b <bf/ppp/ command prompt ©ÎªÌ¬O¦b
      <tt>/etc/ppp/ppp.conf</tt> ²ÕºAÀɮפ¤¥[¤J¡C
      (¥[¦b <bf>default</bf> section ªº¶}ÀY³Ì¦n).
      ½T©w¦b <htmlurl
      url="http://www.freebsd.org/cgi/man.cgi?syslog.conf"
      name="/etc/syslog.conf"> ¸Ì­±¦³³o»ò¤@¦æ:

      <verb>
        !ppp
        *.*              /var/log/ppp.log
      </verb>

      <p>¦Ó¥B<tt>/var/log/ppp.log</tt> ³o­ÓÀɮצs¦b¡C ¦p¦¹¤@¨Ó
      §A¥i¥H±q log Àɮפ¤ª¾¹D¨ì©³µo¥Í¤F¤°»ò¨Æ±¡¡C
      ¥ý¤£¥Î¾á¤ßÀɮתº¤º®e§A¬Ý¤£À´, ¦pªG§A­n¦V¤H¨D±Ïªº¸Ü
      , ±Ï§Aªº¤H·|¬Ý±oÀ´ªº¡C

      <p>¦pªG§A¨t²Î¤Wªº¨º¥÷ ppp ¤£´£¨Ñ "set log"
      ªº«ü¥Oªº¸Ü, §AÀ³¸Ó¥h¤U¸ü
      <url url="http://www.freebsd.org/~brian" name="³Ì·sª©¥»">.
      ³o­Óª©¥»¦b FreeBSD 2.1.5 ¥H¤Wªºª©¥»³£¥i¥H¨Ï¥Î¡C

      <sect2>
        <heading>§Ú¤@°õ¦æ ppp ,¥¦´N±¾¦b¨ºÃ䤣°Ê¤F</heading>

        <p>·|µo¥Í³oºØ±¡§Î³q±`¬O§Aªº hostname ¨S¦³¿ìªk¸Ñ¥X¨Ó¡C ¸Ñ¨M³o­Ó°ÝÃD
        ³Ì¦nªº¿ìªk¬O½T©w <tt>/etc/hosts</tt> ·|³Q§Aªº resolver ²Ä¤@­Ó°Ñ¦Ò¨ì¡C
        §A¥i¥H­×§ï<tt>/etc/host.conf</tt>
        ¨Ã¥B§â<tt>hosts</tt> ©ñ¨ì³Ì«e­±.  ±µµÛ, ¥u­n§â§Aªº¾÷¾¹¦WºÙ©ñ¨ì
        <tt>/etc/hosts</tt> ¸Ì­±´N¥i¥H¤F¡C  ¦pªG§A¨S¦³
        local network ªº¸Ü, ­×§ï <tt>localhost</tt> ³o¤@¦æ:

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

        §_«h, ´N§â§A¥D¾÷ªº¸ê°T¥[¤JÀɮפ¤¡C  §A¥i¥H°Ñ¦Ò
        ¬ÛÃöªº man pages ¥HÀò±o¶i¤@¨Bªº¸ê°T¡C
        <p>¦pªG§A¶¶§Qªº§¹¦¨³o¨Ç°Ê§@, §AÀ³¸Ó¥i¥H¦¨¥\ªº°õ¦æ <tt>ping -c1 `hostname`</tt>
        .

      <sect2>
        <heading>Ppp ¦b -auto ¼Ò¦¡¤U¤£¯à¼·¸¹</heading>

        <p>­º¥ý½T©w§Aªº¤º©w¸ô¥Ñ (default route) ¬O§_¦³³]©w¡C ¤U <htmlurl 
        url="http://www.freebsd.org/cgi/man.cgi?netstat">
        name="netstat -rn"> ³o­Ó«ü¥O, §AÀ³¸Ó¯à°÷¬Ý¨ì¦p¥H¤U½d¨Òªº¨â­Ó entries :

        <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>³o¨Ç³]©w¬O°²³]±z¨Ï¥Îªº address ¸ò handbook ¸Ì­±ªº³]©w,
        ©Î¬O»P man page ªº½d¨Ò§í©Î¬O ppp.conf.sample ³o­ÓÀɮ׸̪º³]©w¬Û¦P.
        ¦pªG±z¨S¦³³]©w default route, ¨º»ò¦³¥i¯à±z²{¦b¨Ï¥Îª©¥»ªº
        <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.  ¦pªG±zªº¨t²Î
        <bf/ppp/ ¬O¦b FreeBSD 2.2.5 ¤§«eªº¸Ü, ­×§ï

        <verb>
          add 0 0 HISADDR
        </verb>

        <p>³o¤@¦æ¦¨¬°

        <verb>
          add 0 0 10.0.0.2
        </verb>

        <p>default route ³o¦æ¨S¦³¥X²{ªº¥t¤@­Ó­ì¦]¬O
        §A³]¿ù¤F default router , ³o­Ó³]©w¦b
        <htmlurl url="http://www.freebsd.org/cgi/man.cgi?rc.conf"
        name="/etc/rc.conf"> Àɮפ¤ (³o­ÓÀɮצb release 2.2.2 «e¥s
        <tt>/etc/sysconfig</tt> ), §A»Ý­n¥[¤J³o»ò¤@¦æ

        <verb>
          delete ALL
        </verb>

        <p>¦b <tt>ppp.conf</tt>¤¤.  ¦pªGµo¥Í³oºØ±¡§Î, ¦^¨ì handbook
        <url url="../handbook/userppp:final.html"
        name="Final system configuration"> ªº»¡©ú¤¤¬d¸ß.

      <sect2>
        <heading>¤°»ò¥s°µ "No route to host"</heading>

        <p>This error is usually due to a missin³o­Óª¬ªp³q±`¬O¦]¬°¯Ê¤Ö¤F³o¬q³]©w

        <verb>
          MYADDR:
            delete ALL
            add 0 0 HISADDR
        </verb>

        <p>½ÐÀˬd±zªº <tt>/etc/ppp/ppp.linkup</tt> Àɮפ¤¬O§_¦³³o¨Ç³]©w.  ¥u¦³¦b±z
        ¨Ï¥Î°ÊºA IP (dynamic IP) ©Î¤£ª¾¹D±z gateway ªº IP ®É¤~»Ý­n³]©w³o­Ó.
        ¦pªG±z¬O¨Ï¥Î¤¬°Ê¼Ò¦¡(interactive mode) ªº¸Ü, ±z¥i¥H
        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>±z¥i¥H°Ñ¦Ò handbook ¤¤ <url url="../handbook/userppp:dynamicIP.html"
        name="PPP and Dynamic IP addresses"> ¦³¸û¸ÔºÉªº»¡©ú.


      <sect2>
        <heading>§Úªº³s½u¦bµ¥«Ý¤T¤ÀÄÁ«á¤ÁÂ_¤F</heading>

        <p>ppp ¹w³]ªº timeout ­È¬O¤T¤ÀÄÁ.  ¥i¥H¥Î¥H¤U³o¦æ©R¥O½Õ¾ã

        <verb>
          set timeout NNN
        </verb>

        <p><bf/NNN/ ¥Nªí¦b¨S¦³³s½u¦¨¥\«eµ¥«Ý´X¬í¤~±N³s½uÃö³¬.
        ¦pªG <bf/NNN/ ³]¬° 0, ¨º»ò±N¤£·|¦]¬° timeout ¦ÓÃö³¬³s½u,·|¤@ª½µ¥«Ý¤U¥h
        .  §A¥i¥H§â³o¦æ©R¥O©ñ¨ì
        <tt>ppp.conf</tt> ³o­ÓÀɮ׸̭±, ©Î¬O¦b interactive mode ¸Ì­±¿é¤J³o­Ó«ü¥O.
        ¤]¥i¥H¥Î on the fly ªº¤è¦¡½Õ¾ã,¦b½u¸ô±Ò¥Î¨ÃÁp±µ¨ì
        <bf/ppp/s ¦øªA¾¹ªº½u¸ô®É¨Ï¥Î
        <htmlurl url="http://www.freebsd.org/cgi/man.cgi?telnet" name="telnet">
        ©Î <htmlurl url="http://www.freebsd.org/cgi/man.cgi?pppctl"
        name="pppctl">.  °Ñ¦Ò
        <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp" name="ppp"> man
        page ¥HÀò±o§ó¸ÔºÉªº¸ê®Æ.

      <sect2>
        <heading>§Úªº³s½u¦]¬°­t²ü¤Ó­«¦ÓÂ_½u</heading>

        <p>¦pªG±z³]©w¤F Link Quality Reporting (LQR) , ´N¦³¥i¯à
        µo¥Í±z©M¹ï¤è¥D¾÷¤§¶¡¦³¤Ó¦hªº LQR «Ê¥]¿ò¥¢ªº²{¶H.
        Ppp ·|¦]¦¹§PÂ_¹q¸Ü½u¸ô¦³°ÝÃD.
        , ¨Ã¥B¨M©w¤ÁÂ_³s½u. ¦b FreeBSD 2.2.5 ª©¥H«e,
        LQR ¤º©w­È¬O enabled .  ²{¦bªº¤º©w­È¬O disabled.
        LQR ¥i¥H¥Î³o¤@¦æ©R¥O¨ú®ø

        <verb>
          disable lqr
        </verb>

      <sect2>
        <heading>§Úªº³s½u·|¤£©w®ÉªºÂ_±¼</heading>

        <p>¦³®É­Ô¦pªG½u¸ô¤W¦³¤Ó¦h¾¸°T,¬Æ¦Ü¦pªG±z¨Ï¥Î¤F¸Ü¤¤´¡¼·ªºªA°Èªº¸Ü.
        , ±zªº modem ±N©Î hang ¦í,¦]¬°¥L»~»{³o¨Ç°T®§¬O lost carrier.

        <p>¤j³¡¤Àªº modem ³£¦³®e§Ô¼È®É¥¢¥h carrier ªº³]©w.
        .  ¥H USR Sportster ¬°¨Ò, this is measured by the S10 register in
        tenths of a second.  ¦pªG­nÅý±zªº modem ¯à®e§Ô§ó¤jªº¿ù»~, §A¥i¥H¦b±zªº dial string
        ¸Ì­±¥[¤J¥H¤Uªº send-expect ©R¥O:

        <verb>
          set dial "...... ATS10=10 OK ......"
        </verb>

        <p>°Ñ¦Ò±zªº modem ¤ºªþªº»¡©ú®Ñ¥H¨ú±o§ó¸Ô²Óªº¸ê®Æ.

      <sect2>
        <heading>¦b¬Ý¨ì Login OK! ªº°T®§¥H«á´N¨S¦³¤ÏÀ³¤F</heading>

        <p>¦b FreeBSD 2.2.5 ¥H«eªºª©¥»¤W, ¤@¦ý³s½u«Ø¥ß§¹¦¨¥H«á,
        <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp"
        name="ppp"> ·|µ¥¹ï¤èªº¾÷¾¹±Ò°Ê Line Control
        Protocol (LCP).  «Ü¦h ISP ¤£·|¦Û°Ê±Ò°Ê³o­Ó°T®§¥æ´«,¦Ó¬Oµ¥
        «Ý cleint ºÝ±Ò°Ê.  ­n±j­¢ <bf/ppp/ ¥D°Ê±Ò°Ê
        LCP, ½Ð¤U³o­Ó©R¥O:

        <verb>
          set openmode active
        </verb>

        <p><bf/Note/: ³q±`¦pªG¨âÃä³£±Ò°Ê°T®§¥æ´«ªº¸Ü,³q±`¤£·|³y¦¨¥ô¦ó°Æ§@¥Î.
        , ©Ò¥H openmode ¥Ø«e¤º©w­È¬O±Ò°Êªº.  µM¦Ó,
        ¤U¤@¬q±N¸ÑÄÀ¦b¤°»òª¬ªp¤U³o­Ó³]©w <bf/¯uªº/ ·|³y¦¨°Æ§@¥Î.

      <sect2>
        <heading>§Ú¤@ª½¬Ý¨ì magic being the same ªº¿ù»~°T®§</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>§Ú¨S¦³¿ìªk«Ø¥ß <tt>/dev/ed0</tt> ³o­Ó device!</heading>

      <p>¦b Berkeley ºô¸ô¬[ºc¤¤, ¥u¦³ kernel µ{¦¡½X¥i¥Hª½±µ¦s¨úºô¸ô¬É­±¥d.
      ½Ð°Ñ¦Ò <tt>/etc/rc.network</tt> ³o­ÓÀɮשM manual pages ¨ú±o»P¨ä¥L¤£¦Pºô¸ôµ{¦¡
      §ó¶i¤@¨Bªº¸ê°T.  ¦pªG§Aı±o§A§¹¥þ·d²V¤Fªº¸Ü, ±zÀ³¸Ó§ä¤@¥»»P¨ä¥L BSD ¬ÛÃö
      §@·~¨t²Îºô¸ôºÞ²z¦³Ãö®Ñ¨Ó°Ñ¦Ò; °£¤F¤Ö¼ÆÅãµÛªº¤£¦P¥~, FreeBSD ªººô¸ôºÞ²z
      °ò¥»¤W©M SunOS 4.0 ©M Ultrix ¬O¤@¼Ëªº.


    <sect1>
      <heading>§Ú¦p¦ó«Ø¥ß Ethernet aliases?</heading>

      <p>§â ``<tt/netmask 0xffffffff/'' ¥[¨ì§Aªº <htmlurl 
      url="http://www.freebsd.org/cgi/man.cgi?ifconfig" name="ifconfig">
      ©R¥O¦C¤¤,¨Ò¦p:

      <verb>
        ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff
      </verb>

    <sect1>
      <heading>§Ú¦p¦ó«ü©w§Úªº 3C503 ¨Ï¥Î¨ä¥L¤£¦Pªºªº network port?</heading>

      <p>¦pªG±z·Q¨Ï¥Î¨ä¥Lªº port, §A¥²¶·¦b
      <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ifconfig"
      name="ifconfig"> ªº©R¥O¤¤«ü©wÃB¥~ªº°Ñ¼Æ. ¤º©wªº
      port ¬O ``<tt/link0/''. ­n¨Ï¥Î AUI port ¥N´À
      BNC port ªº¸Ü, §ï¥Î ``<tt/link2/''.  ³o¨Ç flags À³¸Ó§ïÅÜ
      ifconfig_* ªºÅܼƨӫü©w,§A¥i¥H¦b³o­ÓÀɮ׸̭±§ä¨ì <htmlurl
      url="http://www.freebsd.org/cgi/man.cgi?rc.conf" name="/etc/rc.conf">.

    <sect1>
      <heading>§Ú¦b³s¤W/¿é¥X FreeBSD ªº NFS ®É¥X²{°ÝÃD.</heading>

      <p>¬Y¨Ç PC ªººô¸ô¥d¤ñ¨ä¥Lªº¦n(§t»Wªº»¡¨Ó)
      ³oºØª¬ªp¦b³y¦¨ NFS ³oºØ¹ïºô¸ô±Ó·Pªºµ{¦¡¦³®É·|¥X²{°ÝÃD.

      <p>°Ñ¦Ò <url url="../handbook/nfs.html" name="the Handbook entry on NFS">
      ¥HÀò±o³o­Ó¥DÃDªº§ó¦h¸ê°T.

    <sect1>
      <heading>¬°¤°»ò§Ú¤£¯à NFS-mount Linux ªº¾÷¾¹?</heading>

      <p>¬Y¨Çª©¥»ªº Linux NFS µ{¦¡½X¥u±µ¨ü privileged port ªº mount request
      ; ¸Õ¥Î³o¦æ«ü¥O¬Ý¬Ý

      <verb>
        mount -o -P linuxbox:/blah /mnt
      </verb>

    <sect1>
      <heading>W¬°¤°»ò§Ú¤£¯à NFS-mount Sun ªº¾÷¾¹?</heading>

      <p>¶] SunOS 4.X ªº Sun ¤u§@¯¸¥u±µ¨ü¨Ó¦Û privileged port ªº mount request
      ; ¸Õ¥Î³o¦æ«ü¥O¬Ý¬Ý

      <verb>
        mount -o -P sunbox:/blah /mnt
      </verb>

    <sect1>
      <heading>§Ú¦b¨Ï¥Î PPP ³s½u¨ì NeXTStep ¾÷¾¹®É¦³°ÝÃD.</heading>

      <p>§â TCP extensions ¨ú®ø, ³o­Ó³]©w¦b <htmlurl
      url="http://www.freebsd.org/cgi/man.cgi?rc.conf" name="/etc/rc.conf"> ¸Ì­±.
      §â¥H¤U³o­Ó­È³]¦¨ NO:

      <verb>
        tcp_extensions=NO
      </verb>

      <p>Xylogic ªº Annex ¥D¾÷¤]¦³¬Û¦Pªº°ÝÃD,±z­n°µ¬Û¦Pªº­×§ï¤~¯à³s¤W
	³o¨Ç¥D¾÷.

    <sect1>
      <heading>§Ú­n«ç¼Ë¤~¯à§â IP multicast support ¥´¶}?</heading>

      <p>Multicast host operations are fully supported in FreeBSD 2.0 and
      later by default.  ¦pªG±z·Q±N±zªº¥D¾÷³]©w¦¨ multicast router ªº¸Ü, 
      ±z¥²¶·­«·s compile ±zªº kernel, ¥[¤J <tt>MROUTING</tt>
      ªº¿ï¶µ,¨Ã¥B°õ¦æ <tt/mrouted/.  ¦pªG±zªº<tt>/etc/rc.conf</tt> ¸Ì­±ªº
      <tt/mrouted_enable/ ³o­Ó°Ñ¼Æ¬O³]©w¦¨"YES" ªº¸Ü.FreeBSD 2.2 ¤Î¤§«áªº
      ª©¥»·|¦b¶}¾÷®É°õ¦æ <tt/mrouted/ .

      <p>MBONE ªº¦UºØ¤u¨ã¥i¥H¦b¥L­Ì ports ¤U©ÒÄÝ¥s°µ mbone¥Ø¿ý¤¤§ä¨ì.
      ¦pªG±z¦b§äµø°T·|ijªº¤u¨ã¦p <tt/vic/ ©M <tt/vat/ ªº¸Ü,
      ¨ì¨ºÃä§ä§ä!

      <p>¦pªG»Ý­n§ó¶i¤@³¡ªº°T®§,§ä§ä 
      <url url="http://www.mbone.com/" name="Mbone Information Web">.

    <sect1>
      <heading>­þ¨Çºô¸ô¥d¬O¨Ï¥Î DEC PCI chipset?</heading>

      <p>¥H¤U¬O <url url="mailto:gfoster@driver.nsta.org"
      name="Glen Foster">´£¨Ñªº²M³æ:

      <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>¬°¤°»ò§Úªº¥D¾÷­n´£¨Ñ FQDN ?</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>