From a2a6764de7707218f1364da6bc3ec541b18f7afa Mon Sep 17 00:00:00 2001 From: Hiroyuki Hanai Date: Mon, 16 Mar 1998 07:35:46 +0000 Subject: [PATCH] Changes in the English version (1.6->1.8) are merged. Submitted by: Mitsuharu ARIMURA --- ja/FAQ/network.sgml | 130 +++++++++++++++++++++++++++++++---- ja_JP.eucJP/FAQ/network.sgml | 130 +++++++++++++++++++++++++++++++---- 2 files changed, 230 insertions(+), 30 deletions(-) diff --git a/ja/FAQ/network.sgml b/ja/FAQ/network.sgml index 325596dd8f..3fc40fa1bc 100644 --- a/ja/FAQ/network.sgml +++ b/ja/FAQ/network.sgml @@ -1,6 +1,6 @@ - + - + ネットワーキング @@ -159,7 +159,7 @@ set log Phase Chat Connect Carrier lcp ipcp ccp command -

という命令を という命令を /etc/ppp/ppp.conf に加えて (default セクションの先頭に加えるのが一番良いでしょう) ログを有効にしてみてください. その際, が走っている可能性があります. FreeBSD 2.2.5 より前の - バージョンに付属していた add 0 0 HISADDR @@ -275,7 +275,7 @@ default 10.0.0.2 UGSc 0 0 tun0 か を使用し, を使用し, はリンクが確立した後, 接続先が Line Control Protocol (LCP) を発信するのを待ちます. しかし, 多くの ISP ではネゴジェーションを 自分からは起こさず, クライアントが起こすのを待っています. - set openmode active @@ -393,14 +393,69 @@ default 10.0.0.2 UGSc 0 0 tun0 エストを送り始めます. この間に相手がリクエストを送り始めた場合には 3 秒間待たずにこのリクエストに即座に応答します. + + + 接続が切れるまでLCPのnegotiationが続く. + + +

これが, 片方のこれを回避する最も良い方法は, 片方を + set openmode passive + + + というコマンドでできます. このオプションは気を付けて使わないといけ + ません. さらに + + + set stopped N + + + というコマンドを追加して, + set openmode active N + + + というコマンド(ここで, ppp が接続直後に固まってしまう -

2.2.5 より前のバージョンの FreeBSD では, 2.2.5 より前のバージョンの FreeBSD では, @@ -410,11 +465,11 @@ default 10.0.0.2 UGSc 0 0 tun0 ppp の内部でシェルを起動しようとすると固まってしまう -

このような場合は, 代わりに ヌルモデムケーブルを使用しているとき, ppp が終了しない -

ヌルモデムケーブルを使用して直接接続している場合, ヌルモデムケーブルを使用して直接接続している場合, ppp を -auto モードで動かすと, 勝手にダイアルすることがある -

原因がわかったら, 次に, このような状況ではダイヤルが起こらないように しましょう. 通常, この手の問題は, DNS で名前の解決をしようとしたために 起こります. DNS による名前の解決によって, 接続が行われるのを防止する - には, 次のような手段を用います (これは @@ -652,10 +707,55 @@ default 10.0.0.2 UGSc 0 0 tun0

gdb の使い方に慣れている場合には, 実際に dump の原因となった 理由やそのアドレス, 関連した変数の値なども調べる事ができるでしょう. + + + auto modeでdialをするようなprocessがconnectしてくれない + + +

これはを呼び出した時, tun intergaceのIP numberが + socketのendpointに割り当てられます. kernelは最初に外へ出ていく + packetを作り, それをtunデバイスへ書きます. 次にこの問題に対処する理論的な方法がいくつかあります. もし可能なら, + 相手が同じIP numberを割り当てなおす事ができるのが最も良いです我々の側から対処できる最も簡単な方法は, tun interfaceのIP + numberを固定する事ですが, かわりに外に出ていくpacketを変更して + source IP numberをinterfaceのIPからnegotiateされたIPに書きかえる + 事によっても対処できます. これが, + (およびpppのもう1つの(最も確かな)方法は, 全てのbindされているsocketの + IPを変更するようにsystem callを実装する事です. 3つ目の方法は, interfaceをIP number無しで立ち上げる事を許す + ことです. 外に出ていくpacketは最初のSIOCAIFADDR ioctlが終わるまで + は255.255.255.255というIP numberを与えられます. これによって + socketを完全にbindすることができます. 現在のところ, これらの方法のどれもまだ実装されていません. + どれにも当てはまらない! どうしたらいいの? -

これまでの全ての質問に当てはまらない場合, 設定ファイル, これまでの全ての質問に当てはまらない場合, 設定ファイル, コマンドの出力 (接続前と接続後) を含む, diff --git a/ja_JP.eucJP/FAQ/network.sgml b/ja_JP.eucJP/FAQ/network.sgml index 325596dd8f..3fc40fa1bc 100644 --- a/ja_JP.eucJP/FAQ/network.sgml +++ b/ja_JP.eucJP/FAQ/network.sgml @@ -1,6 +1,6 @@ - + - + ネットワーキング @@ -159,7 +159,7 @@ set log Phase Chat Connect Carrier lcp ipcp ccp command -

という命令を という命令を /etc/ppp/ppp.conf に加えて (default セクションの先頭に加えるのが一番良いでしょう) ログを有効にしてみてください. その際, が走っている可能性があります. FreeBSD 2.2.5 より前の - バージョンに付属していた add 0 0 HISADDR @@ -275,7 +275,7 @@ default 10.0.0.2 UGSc 0 0 tun0 か を使用し, を使用し, はリンクが確立した後, 接続先が Line Control Protocol (LCP) を発信するのを待ちます. しかし, 多くの ISP ではネゴジェーションを 自分からは起こさず, クライアントが起こすのを待っています. - set openmode active @@ -393,14 +393,69 @@ default 10.0.0.2 UGSc 0 0 tun0 エストを送り始めます. この間に相手がリクエストを送り始めた場合には 3 秒間待たずにこのリクエストに即座に応答します. + + + 接続が切れるまでLCPのnegotiationが続く. + + +

これが, 片方のこれを回避する最も良い方法は, 片方を + set openmode passive + + + というコマンドでできます. このオプションは気を付けて使わないといけ + ません. さらに + + + set stopped N + + + というコマンドを追加して, + set openmode active N + + + というコマンド(ここで, ppp が接続直後に固まってしまう -

2.2.5 より前のバージョンの FreeBSD では, 2.2.5 より前のバージョンの FreeBSD では, @@ -410,11 +465,11 @@ default 10.0.0.2 UGSc 0 0 tun0 ppp の内部でシェルを起動しようとすると固まってしまう -

このような場合は, 代わりに ヌルモデムケーブルを使用しているとき, ppp が終了しない -

ヌルモデムケーブルを使用して直接接続している場合, ヌルモデムケーブルを使用して直接接続している場合, ppp を -auto モードで動かすと, 勝手にダイアルすることがある -

原因がわかったら, 次に, このような状況ではダイヤルが起こらないように しましょう. 通常, この手の問題は, DNS で名前の解決をしようとしたために 起こります. DNS による名前の解決によって, 接続が行われるのを防止する - には, 次のような手段を用います (これは @@ -652,10 +707,55 @@ default 10.0.0.2 UGSc 0 0 tun0

gdb の使い方に慣れている場合には, 実際に dump の原因となった 理由やそのアドレス, 関連した変数の値なども調べる事ができるでしょう. + + + auto modeでdialをするようなprocessがconnectしてくれない + + +

これはを呼び出した時, tun intergaceのIP numberが + socketのendpointに割り当てられます. kernelは最初に外へ出ていく + packetを作り, それをtunデバイスへ書きます. 次にこの問題に対処する理論的な方法がいくつかあります. もし可能なら, + 相手が同じIP numberを割り当てなおす事ができるのが最も良いです我々の側から対処できる最も簡単な方法は, tun interfaceのIP + numberを固定する事ですが, かわりに外に出ていくpacketを変更して + source IP numberをinterfaceのIPからnegotiateされたIPに書きかえる + 事によっても対処できます. これが, + (およびpppのもう1つの(最も確かな)方法は, 全てのbindされているsocketの + IPを変更するようにsystem callを実装する事です. 3つ目の方法は, interfaceをIP number無しで立ち上げる事を許す + ことです. 外に出ていくpacketは最初のSIOCAIFADDR ioctlが終わるまで + は255.255.255.255というIP numberを与えられます. これによって + socketを完全にbindすることができます. 現在のところ, これらの方法のどれもまだ実装されていません. + どれにも当てはまらない! どうしたらいいの? -

これまでの全ての質問に当てはまらない場合, 設定ファイル, これまでの全ての質問に当てはまらない場合, 設定ファイル, コマンドの出力 (接続前と接続後) を含む,