path: root/ja_JP.eucJP/FAQ/network.sgml

<!-- $Id: network.sgml,v 1.12 1999-05-12 04:46:26 motoyuki Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: 1.24 --> 

  <sect>
    <heading>ネットワーキング<label id="networking"></heading>
    <p><em>訳: &a.arimura; <newline>&a.shou; <newline>&a.nishika;
               <newline>&a.kiroh .
    <newline>4 October 1998.</em>

    <sect1>
      <heading>``diskless boot'' に関する情報はどこで得られますか?</heading>

      <p>``diskless boot'' というのは, FreeBSD がネットワーク上で起動し, 
      必要なファイルを自分のハードディスクではなくてサーバから読み込むものです. 
      詳細については
      <url url="../handbook/diskless.html"
      name="ハンドブックのディスクレスブートに関する節">
      を読んでください. 

    <sect1>
      <heading>
        FreeBSD をネットワークの router として使用することはできますか?
      </heading>

      <p>インターネット標準やこれまでのよい経験によって指摘されている通り, 
      FreeBSD は標準ではパケットを forward するように設定されていません. 
      しかし, <htmlurl url="http://www.freebsd.org/cgi/man.cgi?rc.conf"
      name="rc.conf"> の中で次の変数の値を 
      <tt/YES/ とする事によってこの機能を有効にすることができます. 

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

      <p>このオプションによって<htmlurl 
      url="http://www.freebsd.org/cgi/man.cgi?sysctl" name="sysctl"> の変数
      <tt/net.inet.ip.forwarding/ が <tt/1/ になります. 

      <p>ほとんどの場合, router についての情報を同じネットワーク
      の他の計算機等に知らせるために, 経路制御のためのの process 
      を走らせる必要があるでしょう. FreeBSD には BSD の標準経路制御デーモン
      である
      <htmlurl url="http://www.freebsd.org/cgi/man.cgi?routed"
      name="routed"> が付属していますが, より複雑な状況に対処するためには
      <em/GaTeD/ (<tt/ftp.gated.Merit.EDU/ から FTP で手に入れることができます) 
      を使用することもできます. 3_5Alpha7 において FreeBSD がサポートされています. 

      <p>注意してほしいのは, FreeBSD をこのようにして使用している場合でも, 
      router に関するインターネット標準の必要条件を完全には満たしていない
      ということです. しかし, 普通に使用する場合にはほとんど問題ありません. 

    <sect1>
      <heading>
        Win95 の走っているマシンを, FreeBSD 経由でインターネットに接続できますか?
      </heading>

      <p>通常, この質問が出てくる状況は自宅に二台の PC があり, 一台では
      FreeBSD が, もう一台では Win95 が走っているような場合です. 
      ここでやろうとしていう事はFreeBSDの走っている計算機をインターネット
      に接続し, Win95 の走っているマシンからは FreeBSD の走っているマシンを
      経由して接続をおこなう事です. これは二つ前の質問の特別な場合に相当します. 

      <p>FreeBSDを<url url="http://www.ssimicro.com/~jeremyc/ppp.html"
      name="PPP の Dialup ルータ">として設定する方法については, 
      役に立つ文書があります. 

      <p><bf/注:/ これには, Windows の走っているマシンからどれだけの
      作業を同時におこなうかによって, 最低 2 個, 場合によってはもっと多くの
      固定した IP アドレスが必要です. もし固定した IP アドレスがない場合には, 
      プライベートな IP アドレスを用いたサブネットを使用し, FreeBSD 上で
      <url url="http://squid.nlanr.net/Squid/" name="SQUID">や
      <url url="http://www.tis.com/" name="TIS firewall ツールキット">
      のような <bf/proxy/ を用いることによって実現することもできます. 

      <p>また, <ref id="natd"> に関する節も参照してください.

    <sect1>
      <heading>
        ISC からリリースされている BIND の最新版は compile できないんでしょうか?
      </heading>

      <p>BIND の配布物と FreeBSD とでは ``<tt/cdefs.h/'' というファイルの中で, 
      データ型の矛盾があります. 
      <tt>compat/include/sys/cdefs.h</tt> を削除してください. 

    <sect1>
      <heading>FreeBSD で SLIP と PPP は使えますか?</heading>

      <p>使えます. FreeBSD を用いて他のサイトに接続する場合には,
      <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"> そして
      <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp"
      name="ppp">
      のマニュアルページを見てください. 
      <tt/pppd/ と <tt/ppp/ は PPP のサーバ, クライアント両方の
      機能を持っています.
      <htmlurl url="http://www.freebsd.org/cgi/man.cgi?sliplogin"
      name="Sliplogin"> は SLIP のサーバ専用で,
      <htmlurl url="http://www.freebsd.org/cgi/man.cgi?slattach"
      name="slattach"> は SLIP のクライアント専用です.
 
      <p>これらのプログラムの解説が, <url
      url="../handbook/index.html" name="ハンドブック"> 
      の以下のセクションにあります.

      <itemize>
        <item><url url="../handbook/slips.html"
        name="ハンドブックの SLIP (サーバ側) の節">

        <item><url url="../handbook/slipc.html"
        name="ハンドブックの SLIP (クライアント側) の節">

        <item><url url="../handbook/ppp.html"
        name="ハンドブックの PPP (kernel バージョン) の節">

        <item><url url="../handbook/ppp-and-slip.html#USERPPP"
        name="ハンドブックの PPP (user モードバージョン) の節">
      </itemize>

      <p>「シェルアカウント」を通じてのみインターネットへアクセス可能な場合, 
      <htmlurl url="http://www.freebsd.org/cgi/ports.cgi?^slirp"
      name="slirp"> package みたいなものが欲しくなるかもしれませんね.
      これを使えば, ローカルマシンから直接 ftp や http のようなサービスに
      (限定的ではありますが) アクセスすることができます.

    <sect1>
      <heading>
        FreeBSD は NAT か IP マスカレードをサポートしていますか?<label id="natd">
      </heading>

      <p>ローカルなサブネット (一台以上のローカルマシン) を持っているが, 
      インターネットプロバイダから 1 つしか IP アドレスの割り当てを
      受けていない場合 (または IP アドレスを動的に割り当てられている場合でも), 
      <htmlurl url="http://www.freebsd.org/cgi/man.cgi?natd"
      name="natd"> プログラムを使いたくなるかもしれませんね.
      <tt/Natd/ を使えば, 1 つしか IP アドレスを持っていない場合でも,
      サブネット全体をインターネットに接続させることができます.

      <p><htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp"
      name="ppp"> も, 同様の機能を持っており, <tt/-alias/ 
      スイッチで有効にすることができます. どちらの場合も <htmlurl
      url="http://www.freebsd.org/cgi/man.cgi?libalias" name="alias library">
      が使われます. 

    <sect1>
      <heading>
        <tt/ppp/ が動きません. どこを間違えているのでしょう?<label id="userppp">
      </heading>

      <p>まず <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp"
      name="ppp"> のマニュアルと, <url url="../handbook/ppp-and-slip.html#USERPPP"
      name="ハンドブックの ppp のセクション">を読んでみましょう. 次に,

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

      <p>という命令を <bf/ppp/ のコマンドプロンプトに対して打ち込むか,
      設定ファイル <tt>/etc/ppp/ppp.conf</tt> に加えて
      (<bf>default</bf> セクションの先頭に加えるのが一番良いでしょう)
      ログを有効にしてみてください. その際, <htmlurl
      url="http://www.freebsd.org/cgi/man.cgi?syslog.conf"
      name="/etc/syslog.conf"> に

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

      <p>と書かれた行が含まれているか, また, <tt>/var/log/ppp.log</tt>
      が存在しているかどうか確かめておいてください. さて, これで
      何が起きているのか突き止めるために, ログファイルからたくさんの
      情報を得られるようになりました. ログに訳の分らない部分があっても
      心配ご無用. あなたが助けを求めた誰かにとっては, その部分が
      意味をなす場合があるのです.

      <p>訳注: ログの取得に syslog を使用するようになったのは
      2.2.5 以降からです. 

      <p>使用中の ppp のバージョンで "set log" 命令を解釈しない場合は, 
      <url url="http://www.freebsd.org/~brian" name="最新版">
      をダウンロードすべきです. FreeBSD の 2.1.5 以降でビルドできます. 

      <sect2>
        <heading>ppp を実行するとハングします</heading>

	<p>ホスト名の解決がうまくいっていないのでしょう. まず,
        リゾルバが <tt>/etc/hosts</tt>を参照するように,
	<tt>/etc/host.conf</tt> の最初の行に host と書き込んでください.
	つぎに, <tt>/etc/hosts</tt>に使用しているマシンのエントリを
	書き加えます. ローカルでネットワークを使用していない場合は, 
	<tt>localhost</tt> の行を以下のように変更してください:

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

	使用しているホストのエントリを追加してもかまいません. 
	詳細は関連するマンページを参照してください.
	
      <sect2>
        <heading>ppp が -auto モードでダイアルしてくれない</heading>

        <p>まず最初に, デフォルトルートが確立しているかどうかチェックして
        ください. <htmlurl 
        url="http://www.freebsd.org/cgi/man.cgi?netstat" 
        name="netstat -rn"> を実行すると, 以下のような情報が表示されるはずです.

        <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>これはあなたがハンドブックやマニュアル, ppp.conf.sample の中で
        出てくるアドレスを使用していると仮定した場合の例です.
        デフォルトルートが確立していない場合, ppp.conf の中の <tt/HISADDR/
        が理解できない, 古いバージョンの <htmlurl
        url="http://www.freebsd.org/cgi/man.cgi?ppp"
        name="ppp"> が走っている可能性があります. FreeBSD 2.2.5 より前の
        バージョンに付属していた <bf/ppp/ を使用している場合,

        <verb>
          add 0 0 HISADDR
        </verb>

        <p>と書かれた行を以下のように修正してください.

        <verb>
          add 0 0 10.0.0.2
        </verb>

        <p>netstat -rn でデフォルトルートの情報が表示されない場合, もう一つ,
        <htmlurl url="http://www.freebsd.org/cgi/man.cgi?rc.conf"
        name="/etc/rc.conf"> (2.2.2 より前のリリースでは
        <tt>/etc/sysconfig</tt> と呼ばれていました) の中でデフォルトの
        ルータを誤って設定し, <tt>ppp.conf</tt> から

        <verb>
          delete ALL
        </verb>

        <p>の行をうっかり消してしまった可能性があります. 
        この場合は, ハンドブックの
        <url url="../handbook/ppp-and-slip.html#USERPPP-FINAL"
        name="システムの最終設定"> の項を読み直してください.

      <sect2>
        <heading>"No route to host" とはどういう意味ですか?</heading>

        <p>このエラーは通常, <tt>/etc/ppp/ppp.linkup</tt> に以下のような
        セクションが無い場合に起こります.
        <verb>
          MYADDR:
            delete ALL
            add 0 0 HISADDR
        </verb>

        <p>これは動的 IP アドレスを使用している場合, またはゲートウェイの
        アドレスを知らない場合にのみ必要な設定です. インタラクティブモード
        を使用している場合, <tt/パケットモード/ に入った後で (プロンプトが
        <bf/PPP/ と大文字に変わったらパケットモードに入ったしるしです), 
        以下の命令を入力してください.

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

        <p>詳しい情報については, ハンドブックの
        <url url="../handbook/ppp-and-slip.html#USERPPP-DYNAMICIP"
        name="PPP と動的 IP 設定"> の項を参照してください.

      <sect2>
        <heading>3 分ほど経つと接続が切れてしまう</heading>

        <p>ppp のタイムアウトは デフォルトでは 3 分です. これは

        <verb>
          set timeout NNN
        </verb>

        <p>という命令によって調整することができます. <bf/NNN/ には
        接続が切れるまでのアイドル時間が秒数で入ります. NNN が 0 の場合, 
        タイムアウトによる切断は起こりません. このコマンドは <tt>ppp.conf</tt> 
        に入れることも, インタラクティブモードでプロンプトから入力することも
        できます. ソケットを用いる
        <htmlurl url="http://www.freebsd.org/cgi/man.cgi?telnet"
        name="telnet"> か
        <htmlurl url="http://www.freebsd.org/cgi/man.cgi?pppctl"
        name="pppctl"> を使用し, <bf/ppp/s サーバに接続することによって,
        回線がアクティブな間に限定してタイムアウトの時間を調整することも
        可能です. 

        <p>訳注 pppctl は 2.2.5R からです. 

        <p>詳しい情報は 
        <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp"
        name="ppp"> のマニュアルを参照してください.

      <sect2>
        <heading>負荷が高いと接続が切れてしまう</heading>

        <p>Link Quality Reporting (LQR) の設定を行っている場合,
        マシンと接続先の間で非常にたくさんの LQR パケットが失われている
        可能性があります. 結果として ppp は回線の具合いが悪いと考え,
        回線を切断するのです. 2.2.5 より前のバージョンの FreeBSD では
        LQR はデフォルトで有効になっています. 現在ではデフォルトの状態で
        無効です. LQR は以下の命令で無効にすることができます.

        <verb>
          disable lqr
        </verb>

      <sect2>
        <heading>接続がランダムに切れてしまう</heading>

        <p>時々, ノイズの多い回線, あるいは待ち機能付きの回線では, 
        モデムが (誤って) キャリアを失ったと思い込み, ハングアップしてしまう
        ことがあります.

        <p>大多数のモデムでは, 一時的なキャリアの喪失にどれだけ我慢するか
        設定で決めることができます. 例えば USR Sportster では, S10 レジスタ
        の値を 10 倍した秒数がその値になります. この場合, モデムをもっと
        のんびり屋さんにするには, dial 行に次のような文字列を加えると
        良いでしょう.

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

        <p>詳しくはお使いのモデムのマニュアルをご覧ください.

      <sect2>
        <heading>接続が不規則にハングアップしてしまう</heading>

	<p>たくさんの人が, 原因不明のハングアップを経験しています.
	検証のために必要なのは, まずどちら側のリンクでそれが起こっているか,
	ということです.

	<p>外部接続型モデムを利用しているなら, 単に <tt/ping/ を使うことで,
	データを送信するときに <tt/TD/ ランプが点灯するかどうかを確認することができます.
	もし, <tt/TD/ ランプが点灯して, <tt/RD/ ランプが点灯しなければ,
	問題は回線の向こう側にあります. <tt/TD/ が点灯しなければ,
	問題は回線のこちら側です. 内蔵型モデムの場合, <tt/ppp.conf/ ファイルに
	<tt/set server/ コマンドを入れる必要があるでしょう.
	回線が切断されたとき, pppctl を使って ppp に接続してください.
	そのとき, ネットワーク接続が急に復旧(診断ソケットへのアクセスで,
	ppp が復活します)するか, もしくは接続自体が全くできない
	(ただし, ppp 起動時に <tt/set socket/
	コマンドがちゃんと実行されているとします)としたら, 
	問題は回線のこちら側です. もし, 接続可能で, かつ状況が変化しなければ,
	<tt/set log local async/ を使ってローカル非同期ログ(async logging)を有効にし,
	<tt/ping/ を他のウィンドウかターミナルから使ってください.
	非同期ログには, こちら側のリンクの送受信データが記録されます.
	もし, データが送信されたにもかかわらず返って来ていなければ,
	問題は回線の向こう側にあることになります.

	<p>問題が回線のどちら側かにあることが分かったら,
	つぎの二つの可能性が考えられるでしょう.

        <sect3>
          <heading>回線の向こう側での反応がない</heading>

	  <p>これに対処できることはほとんどありません. 大部分の ISP
	  は, Microsoft 社製 OS 以外の利用者に対してのサポートを拒否するでしょう.
          <tt/ppp.conf/ ファイルの中に <tt/enable lqr/ を記述することで
	  ppp が回線の向こう側で発生するハングアップを検出することができますが,
	  この検出は比較的遅いため, あまり役に立ちません. また, あなたは
	  user-ppp を利用していることを ISP に知られたくないと思うかも知れませんね.
	  
	  <p>まず最初に, こちら側の圧縮機能を全て無効にしてみて下さい.
	  それには, 設定ファイルをつぎのようにします.

          <verb>
            disable pred1 deflate deflate24 protocomp acfcomp shortseq vj
            deny pred1 deflate deflate24 protocomp acfcomp shortseq vj
          </verb>

	  <p>そして再接続し, 変更前と同じように通信できることを確認します.
	  もしこれによって状況が改善されるか, 完全に解決したら,
	  (上の設定のうち)どの設定で状況が変化したのかを,
	  色々な組合せで試してみて下さい. これは, ISP
	  に問い合わせを行なうときの有効な情報となります(ただし,
	  あなたが Microsoft 社製品以外のものを利用していることも
	  明らかにしてしまいますが).

	  <p>ISP に問い合わせを行なう前に, こちら側の非同期ログを有効にして,
	  接続がハングアップするまで待って下さい. この作業は,
	  非常に多くのディスク空間を消費するかも知れません.
	  興味の対象となっているのは, 通信ポートから最後に読み込まれたデータです.
	  それは通常 ASCII データで, 問題点の詳細(``Memory fault, core dump''など)が
	  記載されている可能性があります.

	  <p>回線の向こう側で通信ログを監視することは可能なはずですので,
	  ハングアップが発生した時, ISP の対応が好意的ならば
	  どうして ISP 側で問題が発生したのかこちらに伝えてくれるかも知れません.
	  <url url="mailto:brian@Awfulhak.org" name="brian@Awfulhak.org">
	  まで詳細を送って頂くか, ISP に直接私に連絡するように伝えて下さっても構いません.
	  
        <sect3>
          <heading>ppp がハングアップする</heading>

	  <p>ベストな方法は, <tt/CFLAGS+=-g/ と <tt/STRIP=/ を ppp の Makefile
	  に追加して, ppp を再構築し, そして
          <tt/make clean &amp;&amp; make &amp;&amp; make install/ を行なうことです.
	  ppp がハングアップした時, <tt/ps ajxww | fgrep ppp/ を使って ppp
	  のプロセス ID を調べ, <tt/gdb ppp PID/ を実行して下さい.
	  gdb のプロンプトから, <tt/bt/ を使ってスタックをトレースすることができます.	  

	  <p>スタックトレースの結果は, <url url="mailto:brian@Awfulhak.org"
          name="brian@Awfulhak.org"> まで送って下さい.

      <sect2>
        <heading>Login OK! のメッセージが出た後, 何も起こらない</heading>

        <p>2.2.5 より前のリリースの FreeBSD では, 
        <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp"
        name="ppp"> はリンクが確立した後, 接続先が Line Control Protocol (LCP)
        を発信するのを待ちます. しかし, 多くの ISP ではネゴシエーションを
        自分からは起こさず, クライアントが起こすのを待っています.
        <bf/ppp/ に強制的に LCP を発信させるには, 次の命令を使います.

        <verb>
          set openmode active
        </verb>

        <p><bf/注/: 両方の側がネゴジェーションを起こしても, 大抵の場合は
        何の問題もありません. ですから, 現在では openmode はデフォルトで
        active になっています. 次のセクションでこれが問題に<bf/なる/場合を
        説明します.

      <sect2>
        <heading>でもまだ "magic is the same" というエラーが出る</heading>

        <p>時折, 接続直後のログに "magic is the same" というメッセージが
        あらわれることがあります. このメッセージがあらわれても何も起きない
        場合もありますし, どちらかの側が接続を切ってしまう場合もあります.
        ppp の実装の多くはこの問題に対応できておらず, その場合にはちゃんと
        link が上がっている状態であっても, ppp が最終的にあきらめてしまい
        接続を切るまで, 設定のリクエストが繰り返し送られ, 設定が行われた
        という通知が log ファイルに残ると思います.

        <p>これは通常, ディスクアクセスの遅いサーバマシンのシリアルポートで
        getty が生きていて, ppp がログインスクリプトか, ログイン直後に
        起動されたプログラムから実行されている場合に起こります. slirp を使用
        している場合に同様の症状が見られたという報告もあります. 原因は
        getty の終了されるまでと, ppp が実行され, クライアント側の ppp が
        Line Control Protocol (LCP) を送り始めるまでのタイミングにあります.
        サーバ側のシリアルポートで ECHO が有効なままになっているので,
        クライアント側の ppp にパケットが「反射」してしまうのです.

        <p>LCP ネゴジェーションの一部として, リンクの両サイドで magic number
        を定めて, 「反射」が起きていないかどうか確かめる作業があります.
        規約では, 接続相手がこちらと同じ magic number を提示してきたら,
        NAK を送って新しい magic number を選択しなければならないと
        定めています. この作業の間, サーバのシリアルポートの ECHO がずっと
        有効になったままなので, クライアント側の ppp は LCP パケットを送り,
        パケットが反射して全く同じ magic number が送られてくるのを見つけ,
        それに対して NAK を送るのです. 一方 NAK 自体も (これは ppp が magic
        number を変更しなければいけないことを意味しています) 反射して
        くるので, 結果として magic number が数えきれないほど変更され,
        その全てがサーバの tty バッファの中に積み重なることになるのです.
        サーバでスタートした ppp はとすぐ magic number であふれかえってしまい,
        LCP のネゴジェーションを十分に行ったものと判断して, さっさと接続を
        切ってしまいます. 一方, クライアント側は反射が帰ってこなくなったので
        満足しますが, それもサーバが接続を切ったことを知るまでです.

        <p>この事態は, 以下の行を ppp.conf の中に書いて, 相手がネゴシェー
        ションを開始できるようにする事によって回避できます.

        <verb>
          set openmode passive
        </verb>

        <p>これで ppp はサーバが LCP ネゴジェーションを起こすのを待つように
        なります. しかし, 自分からは決してネゴジェーションを起こさないサーバ
        もあるかもしれません. もしこの状況に遭遇した場合には, 次のようにして
        ください.

        <verb>
          set openmode active 3
        </verb>

        <p>これによって ppp は 3 秒間 passive モードを続けた後で LCP リク
        エストを送り始めます. この間に相手がリクエストを送り始めた場合には
        3 秒間待たずにこのリクエストに即座に応答します.

      <sect2>
        <heading>
          接続が切れるまでLCPのnegotiationが続く. 
        </heading>

        <p><bf/ppp/では現在まだ, LCPやCCP, IPCPの返事が元のリクエストと
	連携してくれる機能がきちんと実装されていません. その結果, ある
	<bf/ppp/が相手よりも6秒以上遅い場合には, LCP configurationのリ
	クエストをさらに2回送ります. これは致命的な物です. 

	<bf/A/と<bf/B/という2つの実装を考えてみましょう. <bf/A/が接続の
	直後にLCPリクエストを送り, 一方<bf/B/の方はスタートするのに7秒
	かかったとします. <bf/B/がスタートする時には<bf/A/はLCPリクエスト
	を3回送ってしまっています. 前の節で述べたmagic numberの問題が起き
	ないよう, ECHOはoffになっていると考えています. <bf/B/はREQを送り
	ます. するとこれは<bf/A/のREQのうち最初の物に対するACKとなります. 
	結果として, <bf/A/は<bf/OPENED/の状態に入り, <bf/B/に対して(最初の)
	ACKを送ります. そのうちに<bf/B/は, <bf/B/がスタートする前に<bf/A/
	から送られたもう2つのREQに対するACKを送り返します. <bf/B/は<bf/A/
	からの最初のACKを受け取り, <bf/OPENED/の状態に入ります. <bf/A/は
	<bf/B/からの2つ目のACKを受け取りますので, <bf/REQ-SENT/の状態に戻
	り, さらに, RFCのとおりに(4つ目の)REQを送ります. そして3つ目のACK
	を受け取って<bf/OPENED/の状態に入ります. 一方, <bf/B/は<bf/A/から
	の4つ目のREQを受け取りますので<bf/ACK-SENT/の状態に入り, 2つ目の
	REQと4つ目のACKをRFCのとおりに送ります. <bf/A/は, REQを受けとると
	<bf/REQ-SENT/の状態になり, さらにREQを送ります. そしてすぐにACKを
	受け取って<bf/OPENED/の状態に入ります. 

        <p>これが, 片方の<bf/ppp/があきらめてしまうまで続きます. 

        <p>これを回避する最も良い方法は, 片方を<bf/passive/モードに設定
	する, すなわち反対側がnegotiateを開始するまで待つようにする事です. 
	これは, 

        <verb>
          set openmode passive
        </verb>

	というコマンドでできます. このオプションは気を付けて使わないといけ
	ません. さらに

        <verb>
          set stopped N
        </verb>

	というコマンドを追加して, <bf/ppp/がnegotiationが開始するまで待つ
	最大の時間を設定してください. もしくは, 

        <verb>
          set openmode active N
        </verb>

	というコマンド(ここで, <bf/N/はnegotiationが始まるまで待つ時間です)
	を使うこともできます. 詳しくはmanual pageを見てください. 

      <sect2>
        <heading>ppp が接続直後に固まってしまう</heading>

        <p>2.2.5 より前のバージョンの FreeBSD では, <bf/ppp/ が Predictor1 圧縮
        のネゴジェーションを誤って解釈して, 接続直後にリンクを無効にしている
        可能性があります. これは両サイドが 異なる Compression Control
        Protocols (CCP) を使ってネゴジェーションを行った場合にのみ発生します.
        この問題は現在は解決していますが, あなたの走らせている <bf/ppp/ の
        バージョンが古い場合でも, 次の命令で解決することができます.

        <verb>
          disable pred1
        </verb>

      <sect2>
        <heading>ppp の内部でシェルを起動しようとすると固まってしまう</heading>

        <p><tt/shell/ あるいは <tt/!/ コマンドを使用すると, <bf/ppp/ は
        シェルを起動し (何か引数を渡した場合は, <bf/ppp/ は引数も
        実行します), コマンドが終了するまで処理を中断します. コマンドを
        実行中に ppp のリンクを使おうとすると, リンクが固まっているように
        見えますが, これは <bf/ppp/ がコマンドの終了を待っているからです.

        <p>このような場合は, 代わりに <tt/!bg/ コマンドを使用してください.
        与えられたコマンドがバックグラウンドで実行されるので, ppp は
        リンクに関するサービスを継続することができます.

      <sect2>
        <heading>ヌルモデムケーブルを使用しているとき, ppp が終了しない</heading>

        <p>ヌルモデムケーブルを使用して直接接続している場合, <bf/ppp/ は
        自動的には接続の終了を知ることができません. これはヌルモデム
        シリアルケーブルの配線に起因しています. この種の接続形態を用いる
        場合は, 以下の命令を用いて LQR を常に有効にする必要があります.

        <verb>
          enable lqr
        </verb>

        <p>こうすると, 接続先がネゴシエーションを行う場合, デフォルトで
        LQR の使用を受け入れるようになります.

      <sect2>
        <heading>ppp を -auto モードで動かすと, 勝手にダイアルすることがある</heading>

        <p><bf/ppp/ が思いもしないときにダイアルを始める場合, その原因を
        突き止め, 防止のために Dial filters (dfilters) をかけてやる
        必要があります.

        <p>原因を突き止めるためには, 以下の命令を使用してください.

        <verb>
          set log +tcp/ip
        </verb>

        <p>これで接続を通過する全てのトラヒックをログに残すことができるように
        なりました. 次に突然回線がつながったときのログのタイムスタンプを
        たどれば, 原因を突き止めることができるはずです.

        <p>原因がわかったら, 次に, このような状況ではダイヤルが起こらないように
        しましょう. 通常, この手の問題は, DNS で名前の解決をしようとしたために
        起こります. DNS による名前の解決によって, 接続が行われるのを防止する
        には, 次のような手段を用います (これは <bf/ppp/ の既に確立した接続
        に関してパケットのフィルタリングをするものでは<bf/ありません/).

        <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>これはデマンドダイヤル機能に問題を生じさせるため,
        常に適切であるとはかぎりません. ほとんどのプログラムは
        他のネットワーク関連の処理をおこなう前に DNS への問い合わせ
        が必要になります.

        <p>DNS の場合は, 何が実際にホスト名を検索しようとしているのかを
        突き止めるべきでしょう. 大抵の場合は,
        <htmlurl url="http://www.freebsd.org/cgi/man.cgi?sendmail"
        name="sendmail"> が犯人です. 設定ファイルで sendmail が
        DNS に問い合わせないようになっているか確認すべきです.
        自分用の設定ファイルを作成するための詳しい方法は
        <ref id="ispmail" name="メールの設定"> の節をご覧ください.
        または, <bf/.mc/ファイルに次のような行を追加してもよいでしょう.

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

        <p>この行を追加すると, sendmailはメールキューを処理する
        (通常sendmailは30分ごとにキューを処理するよう, ``-bd -q30m''
        というオプションを付けて起動されます)
        までか, または
        (多分ppp.linkupというファイルの中で)
        ``sendmail -q''というコマンドが実行されるまで, 全てのメールを
        キューに溜めるようになります．

        <p>訳注 ``sendmail -q'' はその時点のメールキューの内容を処理して
        終了します．

      <sect2>
        <heading>CCP エラーとはどういう意味ですか</heading>

        <p>ログファイル中の以下のエラーは,

        <verb>
          CCP: CcpSendConfigReq
          CCP: Received Terminate Ack (1) state = Req-Sent (6)
        </verb>

        <p>ネゴジェーションにおいて ppp は Predictor1 圧縮を用いるべく主張したが,
        接続先は圧縮を使用しないことを主張した場合に起こります. このメッセージ
        には何の害もありませんが, 出るのが嫌なら, 以下の命令を用いて
        こちら側でも Predictor1 圧縮を無効にすることで対応できます.

        <verb>
          disable pred1
        </verb>

      <sect2>
        <heading>ファイル転送の途中で, ppp が IO エラーを出して固まってしまう</heading>

        <p>FreeBSD 2.2.2 以前のバージョンの tun ドライバには, tun インタフェース
        の MTU のサイズより大きなパケットを受け取ることができないというバグが
        ありました. MTU のサイズより大きなパケットを受け付けると IO エラーが
        起こり, syslogd 経由で記録されるのです.

        <p>ppp の仕様では, LCP のネゴジェーションを行う場合を含む
        <bf>どのような場合でも</bf>最低 1500 オクテットの
        Maximum Receive Unit (MRU) を受け入れる必要があります.
        ですから, MTU を 1500 以下に設定した場合でも, ISP はそれに関係なく
        1500 の大きさのパケットを送ってくるでしょう. そしてこのイケてない
        機能にぶちあたって, リンクが固まるのを目にすることになるのです.

        <p>FreeBSD 2.2.2 以前のバージョンでは, MTU を決して 1500 より小さく
        しないことで, この問題を回避することができます.


      <sect2>
        <heading>どうして ppp は接続速度をログに残さないんでしょう?</heading>

        <p>モデムとの「やり取り」全ての行をログに残すには,
        以下のようにして接続速度のログの有効化を行ってください:

        <verb>
          set log +connect
        </verb>

        <p>これは
        <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ppp" name="ppp">
        に最後にくることが要求されている "expect" という文字列がくるま
        でのすべてのものをログに記録させます.

        <p>接続速度はログにとりたいけれど, PAP や CHAP を使っている 
        (その結果, dial スクリプト中の CONNECT 以降に全く「やりとり」
        を行わない - "set login" スクリプトには何も書かない) のであれ
        ば, ppp に "expect" を含んだ CONNECT 行全てがくるまで待たせる
        ようにしないといけません, 以下のようになります:

        <verb>
          set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n"
        </verb>

        <p>ここで, CONNECT を受信してから, 何も送らず, linefeed を
        待っています, <bf/ppp/ に CONNECT の応答全てを読み込ませている
        わけです.

      <sect2>
        <heading>私のchatスクリプトでは`\'という文字をPPPが解釈して
        くれません</heading>

        <p>PPPは設定ファイルを読み込むときに, <tt/set phone "123 456 789"/
        のような文字列を正しく解釈し, 番号が実際に<bf/1つの/引数であると
        理解します. ``"''という文字を指定するには, backslash (``\'')で
        エスケープしなければなりません.

        <p>chatの各引数が解釈されるときには, ``\P''や``\T''のような
        特別なescape sequence (man pageを見てください)を見付けるために
        もう1回parseを行います. このようにparseは2回繰り返されま
        すので, 正しい回数だけescapeを行わないといけません.

        <p>モデムにたとえば``\''のような文字を送りたい場合には, 次のように
        する必要があります:

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

        <p>実際にモデムに送られる文字列は次のようになります:

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

        <p>他の例ですと

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

        <p>は次のようになります:

        <verb>
          ATZ
          OK
          ATDT1234567
        </verb>

      <sect2>
        <heading>ppp が segmentation fault になるのですが, <tt/ppp.core/
        ファイルがありません</heading>

        <p>ppp (や他のプログラム) はけして core を吐いてはいけません.
        ppp は 実効 uid が 0 で動いていますので, オペレーティングシステム
        は ppp を終了させる前にディスクに core イメージを書き込みません.
        しかし ppp は実際にはセグメンテーション違反や他の core を吐く原因
        となるようなシグナルによって<bf/終了して/ おり, <bf/さらに/ 最新の
        バージョン (このセクションの始めを見てください) を使用している
        ならば, 次のようにしてください:

        <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>これで debug 可能なバージョンの ppp がインストールされます.
        root で ppp を実行し, 全ての特権が無効になっているようにする必要
        があるでしょう. ppp を実行する時には, current directory が make
        した directory であるようにしてください.

        <p>これで, ppp がセグメンテーション例外を受け取ったときには
        ppp.core という名前の core ファイルを吐くようになります. core が
        吐かれたら次のようにしてください:

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

        <p>質問する際には, これら全ての情報を提供して, 問題点の分析ができ
        るようにしてください.
        <p>gdb の使い方に慣れている場合には, 実際に dump の原因となった
        理由やそのアドレス, 関連した変数の値なども調べる事ができるでしょう.

      <sect2>
        <heading>auto mode でダイアルをするようなプロセスが接続されない</heading>

        <p>これは <bf/ppp/ がローカル側の IP アドレスを,
	動的に通信相手と交渉するように設定されている時に発生する
	良く知られた障害でした. 最新のバージョンでは,
	この問題は修正されています.
	<bf/iface/ をマニュアルページから検索してみて下さい.
  
	これは, 最初のプログラムが
	<htmlurl url="http://www.freebsd.org/cgi/man.cgi?connect"
	name="connect(2)"> を呼び出した時, tun インターフェイスの IP
	アドレスが, ソケットの終端に割り当てられてしまうという問題です.
	カーネルは, 外へ出ていく最初のパケットを作り, それを tun デバイスへ書き込みます.
	そして <bf/ppp/ は, そのパケットを読み込んで接続を確立します.
	<bf/ppp/ は動的に IP アドレスを割り当てるため,
	もしインターフェイスのアドレスが変化してしまうと,
	最初に割り当てられたソケット終端の IP アドレスは無効になってしまいます.
	そのため, それ以降相手に送られる全てのパケットは通常,
	相手に届くことはないでしょう. もし仮に届いたとしても,
	既にこちらの IP アドレスは変更されているので,
	どんな反応も最初のマシンには戻ってきません. 

        <p>この問題に対処する理論的な方法がいくつかあります. もし可能なら, 
	相手が再度, 同じ IP アドレスを割り当ててくれることが一番です <tt/:-)/
	<bf/ppp/ の現在のバージョンはこれを行ないますが,
	他のほとんどの実装はそういった動作をしません.

        <p>我々の側から対処できる最も簡単な方法は, tun インターフェイスの
	IP アドレスを固定する事です. またそのかわりに,
	外に出ていくパケットを変更して, 発信元 IP アドレスをインターフェイスの IP
	アドレスから, 交渉によって得られた IP アドレスに,
	適宜書きかえる事によっても対処できます. こ
	これは, 基本的に <bf/ppp/ の最新バージョンにある <tt/iface-alias/ オプションが
	行なっていることと同じです(<htmlurl url="http://www.freebsd.org/cgi/man.cgi?libalias"
        name="libalias(3)"> および, ppp の <bf/-alias/
	スイッチにも関係します). それは, 以前の IP アドレスを全て管理し,
	それらを最後の交渉によって得られた IP アドレスの別名として扱えるようにします.

        <p>もう 1 つの(おそらく最も信頼できる)方法は, bind された
	全てのソケットの IP アドレスを,
	異なるものに変更できるシステムコールを実装することです.
	<bf/ppp/は, 交渉によって新しい IP アドレスを得た時,
	このシステムコールを用いて実行されているプログラムにある,
	全てのソケットを書きかえてやるわけです.
	同じシステムコールが, DHCP クライアントが利用するソケットを
	強制的に再 bind するのにも使うことができるでしょう.

        <p>3 つ目の方法は, IP
	アドレスを指定しないでインターフェイスを利用できるようにすることです.
	外に出ていくパケットは, 最初の SIOCAIFADDR ioctl の完了まで,
	255.255.255.255 という IP アドレス が与えられます.
	これによって. ソケットは常に bind することができます.
	<bf/ppp/に対して発信元 IP アドレスを変更させる事になりますが,
	もしそれが 255.255.255.255 になっていたら, IP アドレスと
	IP チェックサムだけ変更すれば良ければの話になります.
	この方法はちょっとした変更ですが, 他の機構が今までのように, IP
	アドレスを固定して利用する場合に, カーネルが
	不適切に設定されたインターフェイスに向けて, 正常でないパケットを
	送り出してしまう可能性があります.

      <sect2>
        <heading>何故ほとんどのゲームが -alias スイッチ付きだと動かないんですか?</heading>

        <p>訳注:この問題は佐藤 淳一さん作の NAT パッチを使っても解決できます. 
        <htmlurl url="http://www2a.biglobe.ne.jp/~junichi/freebsd/lowtech/nat.html"
        name="NAT on iij-ppp">をご覧ください. 

        <p>libalias を使っている時にゲームなどの類のものが動作しない理由は, 
        外側にあるマシンが接続しようとしているか, 内側にあるマシンに (余計な) 
        UDP パケットを送信しようとしているからです. 
        内側のマシンにこれらのパケットを送るべきかについて, 
        packet alias ソフトウェアは関知しません. 

        <p>うまく動かすためには, 実行中のものが問題の発生している
        ソフトウェアだけであるかを確認し, ゲートウェイの tun インタフェースに対して 
        tcpdump を実行するか, ゲートウェイ上で ppp tcp/ip logging を有効化 
        (``set log +tcp/ip'') してください. 

        <p>行儀の悪いソフトウェアを起動する際に, ゲートウェイマシンを
        通過するパケットを監視すべきです. 外側から何かパケットが戻ってきた時に, 
        そのパケットは破棄されるでしょう (それが問題なのです). 
        これらのパケットの port 番号に注意して, その行儀の悪いソフトウェアを
        停止してください. 
        これを数回繰り返して port 番号が常に同じであるかを確認してみてください. 
        同じであった場合は, /etc/ppp/ppp.conf の適切なセクションに次の行を入れると, 
        そのソフトウェアは動作するようになるでしょう. 


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

        <p>ここで ``proto'' は ``tcp'' か ``udp'' であり,
        ``internalmachine'' はパケットを送りたいマシン, そして
        ``port'' はパケットのディストネーションの port 番号です. 

        <p>上記のコマンドを変更せずに他のマシン上でそのソフトウェアを
        使用できるようにはしたくないかもしれません. そして
        同時に二つの内部のマシン上でそのソフトウェアを実行することは
        この質問の範囲を超えています. 結局, 外側の世界からは
        内部ネットワーク全体がただ一つのマシンとして見えるのです. 

        <p>port 番号が常に同じとは限らない場合, さらに三つのオプションがあります. 

        <p><bf>1)</bf>libalias でサポートするようにし, 結果を送り付ける.
        特定の場合の例は /usr/src/lib/libalias/alias_*.c にあります
        (alias_ftp.c は良いプロトタイプです). これには通常, 外向きの特定のパケットを読み,
        内部の計算機のある特定のポートへの接続を開始するような命令が
        外部の計算機対して送られていることを見分け, 後続のパケットがどこに行けば
        いいのかが分かるように, エイリアステーブル中の ``route'' の部分を設定する,
        という作業が含まれます.

        <p>これは最も難しい方法ですが, 最も良い方法でもありますし, ソフトウェアが
        複数の計算機で動くようにできます.

        <p><bf>2)</bf>プロクシを使う. アプリケーションが, 例えば socks5
        をサポートしているか, (cvsup のように) ``passive'' オプションを持っていると
        この方法が使えます. ``passive'' とは相手側のほうから接続を求めてくることを
        避けるためにあるオプションです.

        <p><bf>3)</bf>''alias addr''を使ってなんでもかんでも内部の計算機に向けて
        流してしまう. これはちょっと無理矢理な解決法です.

        <sect3>
          <heading>有用な port 番号のリストはありませんか?</heading>

          <p>まだ出来ていません. しかし, これは(関心を持って頂けるならば,)
          そういったリストにしていく予定です.

          <itemize>
            <item><bf>Quake</bf>
            <p>Quake は UDP ポートの 6112 を使用すると報告されています.
            つまり, 次の行により quake が動くようになります.
            <tt>alias port udp hostmachine:6112 6112</tt>
            ここで, <tt>hostmachine</tt> は quake サーバの IP アドレスです.
            <p>このように設定する代わりに,
            <htmlurl url="http://www.battle.net/support/proxy/"
            name="www.battle.net"> で Quake のプロキシーがサポートされているか
            調べてもいいでしょう.
          </itemize>

      <sect2>
	<heading>FCS エラーって何?</heading>

	<p>FCS とは <bf/F/rame <bf/C/heck <bf/S/equence (フレームチェック
	シーケンス) の略です. 個々の ppp パケットには, 送受信するデータ
	が正しいかを調べるためのチェックサムが含まれています. 受信した
	パケットの FCS が正しくない場合は, そのパケットは廃棄され, HDLC
	FCS カウントが増やされます. HDLC エラーの数 は, <tt>show hdlc</tt>
	コマンドを使って表示できます.

	<p>リンクの品質が悪かったり, シリアルドライバがパケットを取り
	こぼしていたりすると, FCS エラーがたびたび発生します. FCS エラー
	は, 圧縮プロトコルの速度低下の原因にはなりますが, 特に心配する
	必要はありません. 外付けモデムを使っている場合は, ケーブルが
	ちゃんとシールドされているかを確認してください. そうでない場合,
	FCS エラーの原因となる場合があります.

	<p>接続直後からリンクがフリーズし, 大量の FCS エラーが発生する
	場合は, リンクが 8 ビットクリーンでない可能性があります. ソフト
	ウェアフロー制御 (XON/XOFF) が使われていないことを確認してくだ
	さい. どうしてもソフトウェアフロー制御を使わなければならない場
	合は, <tt>set accmap 0x000a0000</tt> コマンドを使用して, ppp
	に ^Q と ^S をエスケープさせてください

	<p>リモートホストが <bf/PPP/ プロトコルを使用してない場合も, 大量の
	FCS エラーが発生します. この場合はログをとりながら<tt/非同期/で  
	接続し, ログインプロンプトやシェルプロンプトが送られて来てい
	ないか確認してください.

	<p>ログファイルにリンクを終了した原因となるような記録がない場合は,
	リモートホスト(プロバイダ?)の管理者に, セッションを終了された
	理由を尋ねてください.

      <sect2>
        <heading>どれにも当てはまらない! どうしたらいいの?</heading>

        <p>これまでの全ての質問に当てはまらない場合, 設定ファイル, <bf/ppp/
        の実行方法, ログファイルの該当部分と
        <htmlurl url="http://www.freebsd.org/cgi/man.cgi?netstat"
        name="netstat -rn"> コマンドの出力 (接続前と接続後) を含む,
        あなたの持っている全ての情報を
        <url url="mailto:freebsd-questions@FreeBSD.org"
        name="freebsd-questions@FreeBSD.org"> メーリングリストや
        <url url="news:comp.unix.bsd.freebsd.misc"
        name="comp.unix.bsd.freebsd.misc"> ニュースグループへ
        送ってください. 誰かがあなたを正しい方向へ導いてくれるでしょう.

      <sect1>
        <heading><tt>/dev/ed0</tt> デバイスを作成することができません. </heading>

        <p>
        Berkeley UNIX におけるネットワークの構成においては, ネットワーク
        のインタフェースは kernel のコードからのみ直接あつかうことが
        できます. より詳しく知りたい場合は, <tt>/etc/rc.network</tt> 
        というファイルや, このファイルの中に書いてあるさまざまなプログラム
        についてのマニュアルページを見てください. それでもまだ分からない場合には, 
        他の BSD 系の OS のネットワーク管理についての本を読むべきでしょう. 
        ごく少しの例外をのぞいては, FreeBSD のネットワーク管理は SunOS 4.0 
        や Ultrix と基本的に同じです. 

    <sect1>
      <heading>Ethernet アドレスのエイリアスはどのようにして設定できますか?</heading>

      <p><htmlurl url="http://www.freebsd.org/cgi/man.cgi?ifconfig"
      name="ifconfig"> のコマンドラインに ``<tt/netmask 0xffffffff/'' 
      を追加して, 次のように書いてください. 

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

    <sect1>
      <heading>3C503 で他のネットワークの port を使用するにはどのようにすればよいですか?</heading>

      <p>他の port を使用したい場合には, <htmlurl 
      url="http://www.freebsd.org/cgi/man.cgi?ifconfig" 
      name="ifconfig"> のコマンドラインにパラメータを
      追加しなければなりません. default は ``<tt/link0/'' 
      が用いられるようになっています. BNC のかわりに AUI port 
      を使用したい場合には ``<tt/link2/'' というパラメータを
      追加してください. 
      これらのフラグは <htmlurl
      url="http://www.freebsd.org/cgi/man.cgi?rc.conf" name="/etc/rc.conf">.
      の using the ifconfig_* の変数を使って指定されるはずです. 

    <sect1>
      <heading>FreeBSD との間で NFS がうまくできません. </heading>

      <p>PC 用のネットワークカードによっては NFS のようなネットワークを
      酷使するアプリケーションにおいて問題を起こすものがあります. 

      <p>この点に関しては <url 
      url="../handbook/nfs.html" name="ハンドブックの NFS についての節">
      を見てください. 

    <sect1>
      <heading>何故 Linux のディスクを NFS マウントできないのでしょうか?</heading>

      <p>Linux の NFS のコードによっては許可されたportからの
      リクエストからしか受けつけないものがあります. 
      以下を試してみてください. 

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

    <sect1>
      <heading>何故 Sun のディスクを NFS マウントできないのでしょうか?</heading>

      <p>SunOS 4.X が走っている Sun Workstation は許可された port からの
      mount のリクエストしか受けつけません. 
      以下を試してみてください. 

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

    <sect1>
      <heading>PPP で NeXTStep に接続する際に問題があるのですが. </heading>

      <p><htmlurl url="http://www.freebsd.org/cgi/man.cgi?rc.conf" 
      name="/etc/rc.conf"> の中で次の変数を NO にして, 
      TCP extension を無効にしてみてください. 

      <verb>
        tcp_extensions=NO
      </verb>

      <p>Xylogic の Annex も同様の問題がありますので, Annex 経由で PPP をおこなう
      場合にもこの変更を行ってください. 

    <sect1>
      <heading>IP multicast を有効にするには?</heading>

      <p>2.0 かそれ以降の FreeBSD は, 標準の状態で完全に multicast に対応しています. 
      現在使用している計算機を multicast の router として使用するには, 
      <tt/MROUTING/ というオプションを定義したカーネルを作ったうえで,
      <tt/mrouted/ を走らせる必要があります. 2.2 かそれ以降の FreeBSD ならば,
      <tt>/etc/rc.conf</tt> でフラグ <tt/mrouted_enable/ を "YES" にセットして
      おくことで, ブート時に <tt/mrouted/ を起動できます.

      <p>MBONE用のツールは ports 内の専用のカテゴリー mbone にあります.
      <tt/vic/ や <tt/vat/ といった会議用のツールを探している場合はこの場所を
      見てください.

      <p>詳しい情報は
      <url url="http://www.mbone.com/" name="Mbone Information Web">
      にあります.

    <sect1>
      <heading>DEC の PCI チップセットを用いている network カードにはどのような物がありますか?</heading>

      <p><url url="mailto:gfoster@driver.nsta.org"
      name="Glen Foster"> による一覧に, よりmodernな物を追加したものを
      以下に示します.

      <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>何故自分のサイトのホストに対して FQDN を使用する必要があるのですか?</heading>

      <p>実際にはそのホストは別のドメインにあるのではないですか. たとえば, 
      foo.bar.edu というドメインの中から, bar.edu ドメインにある
      ``mumble'' というホストを指定したい場合には, ``mumble'' だけでは
      駄目で, ``mumble.bar.edu'' という fully-qualified domain name で
      指定しなければなりません. 

      <p>伝統的に, BSD の BIND の resolver ではこのような事は可能でしたが, 
      FreeBSD に入っている <htmlurl
      url="http://www.freebsd.org/cgi/man.cgi?named" name="bind"> 
      の現在のバージョンでは, 自分以外のドメインに対して FQDN 
      でない別名を自動的につけてくれるような事はありません. 
      したがって <tt>mumble</tt> というホスト名は <tt>mumble.foo.bar.edu</tt> 
      という名前か, もしくは root ドメイン内にある場合にしか適用されません. 

      <p>これは, <tt>mumble.bar.edu</tt> と <tt>mumble.edu</tt> 
      ということなったドメイン名に対してホスト名のサーチがおこなわれていた
      以前の振る舞いとは異なったものです. このような事が悪い例もしくは
      セキュリティホールとみなされる理由については RFC 1535 を見てください. 

      <p><htmlurl url="http://www.freebsd.org/cgi/man.cgi?resolv.conf"
      name="/etc/resolv.conf"> の中で

      <verb>
        domain foo.bar.edu
      </verb>

      <p>と書いてある行を

      <verb>
        search foo.bar.edu bar.edu
      </verb>

      <p>のように書きかえることで, 上のような事ができます. しかし, 
      RFC 1535 にあるように, search order が ``ローカルな管理と
      パブリックな管理の境界'' をまたがないようにしてください. 

    <sect1>
      <heading>すべてのネットワークの操作に対して ``Permission denied'' というメッセージが表示されるのですが. </heading>

      <p><tt/IPFIREWALL/ オプションを付けてカーネルをコンパイルした場合には, 
      2.1-STABLE の開発の途中から変更になった 2.1.7R の標準的な方針として, 
      明示的に許可されていないすべてのパケットは落とされる設定
      になっている事を覚えておいてください. 

      <p>もしファイアウォールの設定を間違えた場合にネットワークの操作が再びできる
      ようにするには, root でログインして次のコマンドを実行してください. 

      <verb>
        ipfw add 65534 allow all from any to any
      </verb>

      <p><tt>/etc/rc.conf</tt> に "firewall_type='open'" を追加してもよい
      でしょう. 

      <p>FreeBSD のファイアウォールの設定についての情報は
      <url url="../handbook/firewalls.html" name="FreeBSD ハンドブック">
      にあります. 

    <sect1>
      <heading>IPFW のオーバーヘッドはどのくらいでしょうか?</heading>

      <p>この答えはあなたのルールセットとプロセッサのスピードによって
      ほとんど決まります. イーサネットに対して少しのルールセットだけを使っ
      ているほどんどの場合には, その影響は無視できる程度です. 実
      際の測定値を見ないと満足できない方々のために, 実際の測定結
      果をお見せしましょう.

      <p>次の測定は 486-66(訳注: Intel 社製 CPU i486, 66MHz のこと)上で
      2.2.5-STABLE を使用しておこなわれました.
      IPFW は変更が加えられて, <tt/ip_fw_chk/ ルーチン内でかかる時間を
      測定して 1000 パケット毎に結果をコンソールに表示するようになっています.

      <p>それぞれ 1000 ずつのルールが入っている 2 つのルールセットでテストが
      おこなわれました. ひとつ目のルールセットは最悪のケースを見るために

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

      というルールを繰り返したものです.

      <p>パケットが(ポート番号のせいで)このルールにマッチしないことがわかるまでに,
      何度も実行される IPFW のパケットチェックルーチンによって,
      これは最悪のケースを示します. 
      このルールを 999 個繰り返し並べた後に <tt>allow ip from any to any</tt>が
      書かれています.

      <p>2つ目のルールセットは, なるべく早くチェックが終了するように書かれたものです:
      
      <verb>
        ipfw add deny ip from 1.2.3.4 to 1.2.3.4
      </verb>

      <p>このルールでは, 発信元の IP アドレスがマッチしないのでチェックは
      すぐに終了します. 上のルールセットとおなじように, 1000 個目のruleは
      <tt>allow ip from any to any</tt>です.

      <p>1 つ目のルールセットでは, パケットあたりのオーバヘッドはおよそ
      2.703ms/packet, これはだいたい 1 つのルールあたり 2.7 マイクロ秒
      かかっていることになります.
      したがって, このルールにおけるパケット処理時間の理論的な限界は,
      毎秒約 370 パケットです.
      10Mbps のイーサネットで 1500 バイト以下のパケットサイズを仮定すると,
      バンド幅の利用効率は 55.5% が限界となることになります.

      <p>2 つ目のルールセットでは, それぞれのパケットがおよそ
      1.172msで処理されていますので, だいたい 1 つのルールあたり 1.2 マイクロ秒
      かかっていることになります.
      パケット処理時間の理論的な限界は, 毎秒約 853 パケットとなりますので,
      10Mbps Ethernetのバンド幅を使い切ることができます.

      <p>このテストでのルール数は多過ぎるため, 実際に使用する際の
      結果を反映している訳ではありません. これらは上に示した数値を出す
      ためだけに用いられたものです. 効率の良いルールセットを作るためには,
      次のような事を考えておけばよいでしょう.

      <itemize>

        <item>`確定している' ルールは先頭の方に持ってきてください.
	これは, 多数の TCP のトラフィックがこのルールで処理されるためです. 
	そしてこのルールの前には <tt>allow tcp</tt> という記述を置かないでください.

        <item>良く使われるルールを, あまり良く使われないルールよりも
        前の方に(もちろん<bf>ファイアウォールの許可設定を変えない範囲で</bf>)
        持ってきてください. 
        <tt>ipfw -a l</tt> のようしてパケット数の統計を取ることで,
        どのルールが最もよく使われているかを調べることができます.

      </itemize>

      <sect1>
	<heading>サービス要求を他のマシンにリダイレクトするには?</heading>

	<p>FTP などのサービスのリクエストは, 'socket' パッケージを利用
	してリダイレクトできます. 'socket' パッケージは ports の
	'sysutils' カテゴリに含まれています. リダイレクトしたいサービ
	ス(<tt>/etc/inet.conf</tt>のコマンド行をソケットを呼ぶように変
	更してください. 変更例:

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

	<p>ここで 'ftp.foo.com' はリダイレクト先のホスト名, 行の最後の'ftp' 
	はポートです.

     <sect1>
       <heading>バンド幅の管理を行なえるツールはどこで手に入れられますか?</heading>

       <p>FreeBSD 用のバンド幅管理ツールには, 無料で手に入れられる
       <url url="http://www.csl.sony.co.jp/person/kjc/programs.html" 
        name="ALTQ"> と, 
       <url url="http://www.etinc.com" name="Emerging Technologies">
       から入手できる Bandwidth Manager という市販のものの 2 種類があります.

     <sect1>
       <heading>なぜ ``/dev/bpf0: device not configured" が出るのでしょうか?</heading>

       <p>バークレーパケットフィルタ<htmlurl
       url="http://www.FreeBSD.org/cgi/man.cgi?bpf" name="(bpf)">
       ドライバは, それを利用するプログラムを実行する前に有効にしておく必要があります.
       カーネルコンフィグファイルに, 次のように追加してカーネルの再構築をして下さい.

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

       <p>そして再起動してから, 次にデバイスノードを作成する必要があります.
       これは, 次のように入力し, <tt>/dev</tt> を変更することで行ないます. 

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

       <p>デバイスノードの作成の詳細は, <htmlurl url="../handbook/kernelconfig-nodes.html"
       name="FreeBSD ハンドブックのデバイスノードに関する節"> を参照して下さい.

  </sect>