os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Changes in the English version (1.6->1.8) are merged.

Browse source 
Submitted by: Mitsuharu ARIMURA <arimura@sr3.t.u-tokyo.ac.jp>
This commit is contained in:
Hiroyuki Hanai 1998-03-16 07:35:46 +00:00
parent 554277e932
commit a2a6764de7
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=2547
2 changed files with 230 additions and 30 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

130
ja/FAQ/network.sgml
View file

@ -1,6 +1,6 @@
<!-- $Id: network.sgml,v 1.3 1998-01-27 01:38:20 hanai Exp $ -->
<!-- $Id: network.sgml,v 1.4 1998-03-16 07:35:46 hanai Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: 1.6 -->
<!-- Original revision: 1.8 -->
<sect>
<heading>ネットワーキング<label id="networking"></heading>
@ -159,7 +159,7 @@
set log Phase Chat Connect Carrier lcp ipcp ccp command
</verb>
<p>という命令を <tt/ppp/ のコマンドプロンプトで打ち込むか,
<p>という命令を <bf/ppp/ のコマンドプロンプトに対して打ち込むか,
設定ファイル <tt>/etc/ppp/ppp.conf</tt> に加えて
(<bf>default</bf> セクションの先頭に加えるのが一番良いでしょう)
ログを有効にしてみてください. その際, <htmlurl
@ -205,7 +205,7 @@ default 10.0.0.2 UGSc 0 0 tun0
が理解できない, 古いバージョンの <htmlurl
url="http://www.freebsd.org/cgi/man.cgi?ppp"
name="ppp"> が走っている可能性があります. FreeBSD 2.2.5 より前の
バージョンに付属していた <tt/ppp/ を使用している場合,
バージョンに付属していた <bf/ppp/ を使用している場合,
<verb>
add 0 0 HISADDR
@ -275,7 +275,7 @@ default 10.0.0.2 UGSc 0 0 tun0
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?telnet"
name="telnet"> か
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?pppctl"
name="pppctl"> を使用し, <tt/ppp/ サーバに接続することによって,
name="pppctl"> を使用し, <bf/ppp/s サーバに接続することによって,
回線がアクティブな間に限定してタイムアウトの時間を調整することも
可能です.
@ -326,7 +326,7 @@ default 10.0.0.2 UGSc 0 0 tun0
name="ppp"> はリンクが確立した後, 接続先が Line Control Protocol (LCP)
を発信するのを待ちます. しかし, 多くの ISP ではネゴジェーションを
自分からは起こさず, クライアントが起こすのを待っています.
<tt/ppp/ に強制的に LCP を発信させるには, 次の命令を使います.
<bf/ppp/ に強制的に LCP を発信させるには, 次の命令を使います.
<verb>
set openmode active
@ -393,14 +393,69 @@ default 10.0.0.2 UGSc 0 0 tun0
エストを送り始めます. この間に相手がリクエストを送り始めた場合には
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 では, <tt/ppp/ が Predictor1 圧縮
<p>2.2.5 より前のバージョンの FreeBSD では, <bf/ppp/ が Predictor1 圧縮
のネゴジェーションを誤って解釈して, 接続直後にリンクを無効にしている
可能性があります. これは両サイドが 異なる Compression Control
Protocols (CCP) を使ってネゴジェーションを行った場合にのみ発生します.
この問題は現在は解決していますが, あなたの走らせている <tt/ppp/ の
この問題は現在は解決していますが, あなたの走らせている <bf/ppp/ の
バージョンが古い場合でも, 次の命令で解決することができます.
<verb>
@ -410,11 +465,11 @@ default 10.0.0.2 UGSc 0 0 tun0
<sect2>
<heading>ppp の内部でシェルを起動しようとすると固まってしまう</heading>
<p><tt/shell/ あるいは <tt/!/ コマンドを使用すると, <tt/ppp/ は
シェルを起動し (何か引数を渡した場合は, <tt/ppp/ は引数も
<p><tt/shell/ あるいは <tt/!/ コマンドを使用すると, <bf/ppp/ は
シェルを起動し (何か引数を渡した場合は, <bf/ppp/ は引数も
実行します), コマンドが終了するまで処理を中断します. コマンドを
実行中に ppp のリンクを使おうとすると, リンクが固まっているように
見えますが, これは <tt/ppp/ がコマンドの終了を待っているからです.
見えますが, これは <bf/ppp/ がコマンドの終了を待っているからです.
<p>このような場合は, 代わりに <tt/!bg/ コマンドを使用してください.
与えられたコマンドがバックグラウンドで実行されるので, ppp は
@ -423,7 +478,7 @@ default 10.0.0.2 UGSc 0 0 tun0
<sect2>
<heading>ヌルモデムケーブルを使用しているとき, ppp が終了しない</heading>
<p>ヌルモデムケーブルを使用して直接接続している場合, <tt/ppp/ は
<p>ヌルモデムケーブルを使用して直接接続している場合, <bf/ppp/ は
自動的には接続の終了を知ることができません. これはヌルモデム
シリアルケーブルの配線に起因しています. この種の接続形態を用いる
場合は, 以下の命令を用いて LQR を常に有効にする必要があります.
@ -438,7 +493,7 @@ default 10.0.0.2 UGSc 0 0 tun0
<sect2>
<heading>ppp を -auto モードで動かすと, 勝手にダイアルすることがある</heading>
<p><tt/ppp/ が思いもしないときにダイアルを始める場合, その原因を
<p><bf/ppp/ が思いもしないときにダイアルを始める場合, その原因を
突き止め, 防止のために Dial filters (dfilters) をかけてやる
必要があります.
@ -455,7 +510,7 @@ default 10.0.0.2 UGSc 0 0 tun0
<p>原因がわかったら, 次に, このような状況ではダイヤルが起こらないように
しましょう. 通常, この手の問題は, DNS で名前の解決をしようとしたために
起こります. DNS による名前の解決によって, 接続が行われるのを防止する
には, 次のような手段を用います (これは <tt/ppp/ の既に確立した接続
には, 次のような手段を用います (これは <bf/ppp/ の既に確立した接続
に関してパケットのフィルタリングをするものでは<bf/ありません/).
<verb>
@ -652,10 +707,55 @@ default 10.0.0.2 UGSc 0 0 tun0
<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>これまでの全ての質問に当てはまらない場合, 設定ファイル, <tt/ppp/
<p>これまでの全ての質問に当てはまらない場合, 設定ファイル, <bf/ppp/
の実行方法, ログファイルの該当部分と
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?netstat"
name="netstat -rn"> コマンドの出力 (接続前と接続後) を含む,

130
ja_JP.eucJP/FAQ/network.sgml
View file

@ -1,6 +1,6 @@
<!-- $Id: network.sgml,v 1.3 1998-01-27 01:38:20 hanai Exp $ -->
<!-- $Id: network.sgml,v 1.4 1998-03-16 07:35:46 hanai Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: 1.6 -->
<!-- Original revision: 1.8 -->
<sect>
<heading>ネットワーキング<label id="networking"></heading>
@ -159,7 +159,7 @@
set log Phase Chat Connect Carrier lcp ipcp ccp command
</verb>
<p>という命令を <tt/ppp/ のコマンドプロンプトで打ち込むか,
<p>という命令を <bf/ppp/ のコマンドプロンプトに対して打ち込むか,
設定ファイル <tt>/etc/ppp/ppp.conf</tt> に加えて
(<bf>default</bf> セクションの先頭に加えるのが一番良いでしょう)
ログを有効にしてみてください. その際, <htmlurl
@ -205,7 +205,7 @@ default 10.0.0.2 UGSc 0 0 tun0
が理解できない, 古いバージョンの <htmlurl
url="http://www.freebsd.org/cgi/man.cgi?ppp"
name="ppp"> が走っている可能性があります. FreeBSD 2.2.5 より前の
バージョンに付属していた <tt/ppp/ を使用している場合,
バージョンに付属していた <bf/ppp/ を使用している場合,
<verb>
add 0 0 HISADDR
@ -275,7 +275,7 @@ default 10.0.0.2 UGSc 0 0 tun0
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?telnet"
name="telnet"> か
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?pppctl"
name="pppctl"> を使用し, <tt/ppp/ サーバに接続することによって,
name="pppctl"> を使用し, <bf/ppp/s サーバに接続することによって,
回線がアクティブな間に限定してタイムアウトの時間を調整することも
可能です.
@ -326,7 +326,7 @@ default 10.0.0.2 UGSc 0 0 tun0
name="ppp"> はリンクが確立した後, 接続先が Line Control Protocol (LCP)
を発信するのを待ちます. しかし, 多くの ISP ではネゴジェーションを
自分からは起こさず, クライアントが起こすのを待っています.
<tt/ppp/ に強制的に LCP を発信させるには, 次の命令を使います.
<bf/ppp/ に強制的に LCP を発信させるには, 次の命令を使います.
<verb>
set openmode active
@ -393,14 +393,69 @@ default 10.0.0.2 UGSc 0 0 tun0
エストを送り始めます. この間に相手がリクエストを送り始めた場合には
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 では, <tt/ppp/ が Predictor1 圧縮
<p>2.2.5 より前のバージョンの FreeBSD では, <bf/ppp/ が Predictor1 圧縮
のネゴジェーションを誤って解釈して, 接続直後にリンクを無効にしている
可能性があります. これは両サイドが 異なる Compression Control
Protocols (CCP) を使ってネゴジェーションを行った場合にのみ発生します.
この問題は現在は解決していますが, あなたの走らせている <tt/ppp/ の
この問題は現在は解決していますが, あなたの走らせている <bf/ppp/ の
バージョンが古い場合でも, 次の命令で解決することができます.
<verb>
@ -410,11 +465,11 @@ default 10.0.0.2 UGSc 0 0 tun0
<sect2>
<heading>ppp の内部でシェルを起動しようとすると固まってしまう</heading>
<p><tt/shell/ あるいは <tt/!/ コマンドを使用すると, <tt/ppp/ は
シェルを起動し (何か引数を渡した場合は, <tt/ppp/ は引数も
<p><tt/shell/ あるいは <tt/!/ コマンドを使用すると, <bf/ppp/ は
シェルを起動し (何か引数を渡した場合は, <bf/ppp/ は引数も
実行します), コマンドが終了するまで処理を中断します. コマンドを
実行中に ppp のリンクを使おうとすると, リンクが固まっているように
見えますが, これは <tt/ppp/ がコマンドの終了を待っているからです.
見えますが, これは <bf/ppp/ がコマンドの終了を待っているからです.
<p>このような場合は, 代わりに <tt/!bg/ コマンドを使用してください.
与えられたコマンドがバックグラウンドで実行されるので, ppp は
@ -423,7 +478,7 @@ default 10.0.0.2 UGSc 0 0 tun0
<sect2>
<heading>ヌルモデムケーブルを使用しているとき, ppp が終了しない</heading>
<p>ヌルモデムケーブルを使用して直接接続している場合, <tt/ppp/ は
<p>ヌルモデムケーブルを使用して直接接続している場合, <bf/ppp/ は
自動的には接続の終了を知ることができません. これはヌルモデム
シリアルケーブルの配線に起因しています. この種の接続形態を用いる
場合は, 以下の命令を用いて LQR を常に有効にする必要があります.
@ -438,7 +493,7 @@ default 10.0.0.2 UGSc 0 0 tun0
<sect2>
<heading>ppp を -auto モードで動かすと, 勝手にダイアルすることがある</heading>
<p><tt/ppp/ が思いもしないときにダイアルを始める場合, その原因を
<p><bf/ppp/ が思いもしないときにダイアルを始める場合, その原因を
突き止め, 防止のために Dial filters (dfilters) をかけてやる
必要があります.
@ -455,7 +510,7 @@ default 10.0.0.2 UGSc 0 0 tun0
<p>原因がわかったら, 次に, このような状況ではダイヤルが起こらないように
しましょう. 通常, この手の問題は, DNS で名前の解決をしようとしたために
起こります. DNS による名前の解決によって, 接続が行われるのを防止する
には, 次のような手段を用います (これは <tt/ppp/ の既に確立した接続
には, 次のような手段を用います (これは <bf/ppp/ の既に確立した接続
に関してパケットのフィルタリングをするものでは<bf/ありません/).
<verb>
@ -652,10 +707,55 @@ default 10.0.0.2 UGSc 0 0 tun0
<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>これまでの全ての質問に当てはまらない場合, 設定ファイル, <tt/ppp/
<p>これまでの全ての質問に当てはまらない場合, 設定ファイル, <bf/ppp/
の実行方法, ログファイルの該当部分と
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?netstat"
name="netstat -rn"> コマンドの出力 (接続前と接続後) を含む,