diff options
Diffstat (limited to 'ja_JP.eucJP/FAQ/network.sgml')
| -rw-r--r-- | ja_JP.eucJP/FAQ/network.sgml | 1035 |
1 files changed, 0 insertions, 1035 deletions
diff --git a/ja_JP.eucJP/FAQ/network.sgml b/ja_JP.eucJP/FAQ/network.sgml deleted file mode 100644 index 3fc40fa1bc..0000000000 --- a/ja_JP.eucJP/FAQ/network.sgml +++ /dev/null @@ -1,1035 +0,0 @@ -<!-- $Id: network.sgml,v 1.4 1998-03-16 07:35:46 hanai Exp $ --> -<!-- The FreeBSD Japanese Documentation Project --> -<!-- Original revision: 1.8 --> - - <sect> - <heading>ネットワーキング<label id="networking"></heading> - <p><em>訳: &a.arimura; <newline>&a.shou; <newline>&a.nishika; . - <newline>24 December 1997.</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="direct-at" name="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/handbook.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/userppp.html" - 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/userppp.html" - 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 が -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/userppp:final.html" - 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/userppp:dynamicIP.html" - 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>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''というコマンドが送られるまで, 全てのメールを - 送信しないようになります． - - <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でdialをするようなprocessがconnectしてくれない - </heading> - - <p>これは<bf/ppp/が動的なlocalのIP numberを相手とnegotiateする - ように設定されている時のknown problemです. 最初のプログラムが - <htmlurl url="http://www.freebsd.org/cgi/man.cgi?connect" - name="connect(2)">を呼び出した時, tun intergaceのIP numberが - socketのendpointに割り当てられます. kernelは最初に外へ出ていく - packetを作り, それをtunデバイスへ書きます. 次に<bf/ppp/はpacket - を読んで接続を確立します. <bf/ppp/の動的IP割り当ての結果として, - interfaceのアドレスは変わりますので, 一番最初のsocketのendpoint - のは無効になります. そしてそれ以降相手に送られるpacketは落とされ - てしまいます. 仮にそうでないとしても, 既にIP numberは変更されて - いるので, どんな返事も始めのmachineには戻ってきません. - - <p>この問題に対処する理論的な方法がいくつかあります. もし可能なら, - 相手が同じIP numberを割り当てなおす事ができるのが最も良いです<tt/:-)/ - - <p>我々の側から対処できる最も簡単な方法は, tun interfaceのIP - numberを固定する事ですが, かわりに外に出ていくpacketを変更して - source IP numberをinterfaceのIPからnegotiateされたIPに書きかえる - 事によっても対処できます. これが, - <htmlurl url="http://www.freebsd.org/cgi/man.cgi?libalias" - name="libalias(3)"> (およびpppの<bf/-alias/ switch)の行っている - 方法です. - - <p>もう1つの(最も確かな)方法は, 全てのbindされているsocketの - IPを変更するようにsystem callを実装する事です. <bf/ppp/は, - 新しくIP numberがnegotiateされた時に, このsystem callを用いて - 全てのsocketを書きかえるのです. - - <p>3つ目の方法は, interfaceをIP number無しで立ち上げる事を許す - ことです. 外に出ていくpacketは最初のSIOCAIFADDR ioctlが終わるまで - は255.255.255.255というIP numberを与えられます. これによって - socketを完全にbindすることができます. <bf/ppp/に対してsource IP - numberを変更させる事になりますが, もしそれが255.255.255.255になって - おり, IP numberとIP checksumだけ変更すれば良ければの話になります. - しかし, この方法は, 他の部分の仕組みが古い物との互換性を持つよう - 変更されてしまった場合には, kernelが適切に設定されていないinterface - に対して悪いpacketを送信してしまいます. - - <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>FreeBSD 2.0 においては multicast は標準で完全に対応しています. - 現在使用している計算機を multicast の router として使用するには, - <tt/ip_mroute_mod/というloadable kernel moduleをloadして - <tt/mrouted/ を走らせる必要があります. - - <p>より詳しい情報は以下の場所にあります. - - <verb> -Product Description Where ---------------- ----------------------- --------------------------------------- -faq.txt Mbone FAQ ftp.isi.edu:/mbone/faq.txt -imm/immserv jpg/gif画像のための ftp.hawaii.edu:/paccom/imm.src.tar.Z - IMage Multicast -nv Networkビデオ ftp.parc.xerox.com: - /pub/net-reseach/exp/nv3.3alpha.tar.Z -vat LBL Visual Audioツール ftp.ee.lbl.gov: - /conferencing/vat/i386-vat.tar.Z -wb LBL White Board ftp.ee.lbl.gov: - /conferencing/wb/i386-wb.tar.Z -mmcc MultiMedia Conference ftp.isi.edu: - 制御プログラム /confctrl/mmcc/mmcc-intel.tar.Z -rtpqual RTPパケットの質を ftp.psc.edu:/pub/net_tools/rtpqual.c - チェックするツール -vat_nv_record vatとnvのための ftp.sics.se:archive/vat_nv_record.tar.Z - 録画ツール - </verb> - - <sect1> - <heading>DEC の PCI チップセットを用いている network カードにはどのような物がありますか?</heading> - - <p><url url="mailto:gfoster@driver.nsta.org" - name="Glen Foster"> による一覧があります. - - <verb> - Vendor Model - ---------------------------------------------- - ASUS PCI-L101-TB - Accton ENI1203 - Cogent EM960PCI - Compex ENET32-PCI - D-Link DE-530 - DEC DE435 - Danpex EN-9400P3 - JCIS Condor JC1260 - Linksys EtherPCI - Mylex LNP101 - SMC EtherPower 10/100 (Model 9332) - SMC EtherPower (Model 8432) - TopWare TE-3500P - Zynx ZX342 - </verb> - - <sect1> - <heading>何故自分のサイトのホストに対して 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/オプションを付けてkernelをコンパイルした場合には, - 2.1-STABLE の開発の途中から変更になった 2.1.7R の標準的な方針として, - 明示的に許可されていないすべてのパケットは落とされる設定 - になっている事を覚えておいてください. - - <p>もしfirewallの設定を間違えた場合にネットワークの操作が再びできる - ようにするには, root で login して次のコマンドを実行してください. - - <verb> - ipfw add 65534 allow all from any to any - </verb> - - <p>FreeBSD の firewall の設定についての情報は - <url url="../handbook/firewalls.html" name="FreeBSD ハンドブック"> - にあります. - - <sect1> - <heading>IPFWのオーバーヘッドはどのくらいでしょうか?</heading> - - <p>この答えはあなたのrule setとprocessorのスピードによって - ほとんど決まります. Ethernetに対して少しのrule setだけを使っ - ているほどんどの場合には, その影響は無視できる程度です. 実 - 際の測定値を見ないと満足できない方々のために, 実際の測定結 - 果をお見せしましょう. - - <p>次の測定は486-66上で2.2.5-STABLEを使用しておこなわれました. - IPFWは変更が加えられて, <tt/ip_fw_chk/ルーチン内でかかる時間を - 測定して1000パケット毎に結果をconsoleに表示するようになっています. - - <p>それぞれ1000ずつのruleが入っている2つのrule setでテストが - おこなわれました. ひとつ目のsetは最悪のケースを見るために - - <verb> - ipfw add deny tcp from any to any 55555 - </verb> - - というruleを繰り返したものです. - - <p>このsetを用いますと, (port番号によって) packetが全てのruleにマッチ - しない事が最終的に決まるまでに, IPFWのpacketをチェックするルーチン - のほとんど全てが実行されますので, 最悪のケースとなります. この - ruleを999個繰り返した後に<tt>allow ip from any to any</tt>が - 書かれています. - - <p>2つ目のsetは, なるべく早くチェックが終了するように書かれたものです: - - <verb> - ipfw add deny ip from 1.2.3.4 to 1.2.3.4 - </verb> - - <p>このruleではsource側のIPアドレスがマッチしないのでチェックは - すぐに終了します. 上のsetとおなじように, 1000個目のruleは - <tt>allow ip from any to any</tt>です. - - <p>1つ目のsetでは, packetあたりのoverheadはだいたい2.703ms/packet, - 言いかえると1つのruleあたり2.7マイクロ秒です. したがってこのruleに - おけるpacketを処理する時間の理論的な限界は1秒あたり約370 packetです. - 10MbpsのEthernetで1500 byte以下のpacketサイズを仮定すると, 55.5%の - バンド幅までしか使えない事になります. - - <p>2つ目のsetでは, それぞれのpacketはだいたい1.172msで処理されて - いますので1つのruleあたり1.2マイクロ秒となります. packetの - 処理時間の理論的な限界はだいたい1秒あたり853 packetとなりますので - 10Mbps Ethernetのバンド幅を使い切ることができます. - - <p>このテストでのruleの数は多過ぎますので, 実際に使用している際の - 結果を反映している訳ではありません. これらは上に示した数値を出す - ためだけに用いられたものです. 実際に効率の良いrule setを作るために - は, 次のような事を考えておけばよいでしょう. - - <itemize> - - <item>`確定している' ruleは, TCPのtrafficの多数を処理するために - 前の方に持ってきてください. そしてこのruleの前には<tt>allow tcp</tt> - という記述をしないでください. - - <item>良く使われるruleを, あまり良く使われないruleよりも - 前の方に(もちろん<bf>firewallの許可の設定を変えない範囲で</bf>) - 持ってきてください. - <tt>ipfw -a l</tt>のようにしてpacket数の統計を取ることによって - どのruleが最もよく使われているかが分かります. - - </itemize> - - </sect> - |