10.7.9. 接続が切れるまでLCPのnegotiationが続く.

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

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

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

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

          set openmode passive
        

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

          set stopped N
        

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

          set openmode active N
        

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