10.7.8. でもまだ "magic is the same" というエラーが出る

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

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

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 のネゴジェーションを十分に行ったものと判断して, さっさと接続を 切ってしまいます. 一方, クライアント側は反射が帰ってこなくなったので 満足しますが, それもサーバが接続を切ったことを知るまでです.

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

          set openmode passive
        

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

          set openmode active 3
        

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