EN JA
SPPP(4)
SPPP(4) FreeBSD Kernel Interfaces Manual SPPP(4)

名称

sppp同期回線のためにポイントツーポイントプロトコルネットワークレイヤ

書式

device sppp

解説

sppp ネットワークレイヤは、状態機械と RFC 1661 で記述されるように ポイントツーポイントプロトコル (point to point protocol) (PPP) のリンク制御プロトコル (Link Control Protocol) (LCP) を実装します。このレイヤはそれ自体のネットワークインタフェースを提供しないで、むしろ、その上で PPP スタックを実行したい、同期ポイントツーポイント接続に提供するドライバの最上位のレイヤとなることを意図されることに注意してください。対応するネットワークインタフェースはこれらのハードウェアドライバによって提供されなければなりません。

sppp レイヤは 3 つの基本的な運転モードを提供します。設定される特別のフラグがないデフォルトモードは、インタフェースが ifconfig(8) コマンドで活動を始めるとすぐに、PPP 接続 (LCP レイヤへの管理 Open イベント) を作成します。再びインタフェースの活動を停止することは、LCP レイヤひいては最上位の他のすべてのレイヤを終わらせます。また、リンクは、下位のレイヤがもはや必要でないことを示して Network Control Protocol (NCP) がもうこれ以上オープンされていないとすぐにリンク自体を終了します。

ifconfig(8) でリンクレベルフラグ link0 を設定することは、それぞれのネットワークインタフェースは passive (パッシブ) モードに入ります。 LCP レイヤへの管理 Open イベントは Up イベント (“キャリヤ”の上昇) が下位のレイヤに信号を送るまで、遅れることを意味します。何らかの外部のイベントが到着した後だけを除いて、物理的なレイヤが起動時にただちに利用可能でないところで着呼接続をサポートするために下位のレイヤによって使用することができます。下位のレイヤからの Down イベントを受け取る場合でも、完全にインタフェースを停止することはありません。

最終的に、フラグ link1 を設定すれば、インタフェースは dial-on-demand (発呼デマンド) モードで動作します。下位のレイヤがキャリヤの概念をサポートする場合にだけこれも役に立ちます。それぞれのインタフェースを設定すると、発信ネットワークパケットが到着するか、または着信接続を示す、下位のレイヤが Up イベントの信号を送るまで、 LCP レイヤへの管理 Open イベントを遅らせます。 passive (パッシブ) モードで Down イベント (キャリヤの損失) を受け取っても自動的にインタフェースを停止しません、したがって、さらに接続が可能なままで残っています。

sppp レイヤは ifconfig(8) で設定することができる デバッグ インタフェースフラグをサポートします。このフラグが設定されると、リンクの両端の間のオプションのネゴシエーション (交渉) がレベル LOG_DEBUG でログが記録されると同様に様々な制御プロトコルパケットは交換されます。これは、新しい設定を使い始める最初の試みの間に設定問題を調べるために役立ちます。このフラグが設定されなければ、主要なフェーズ遷移だけがレベル LOG_INFO でログに記録されます。

ローカルインタフェース IP アドレスをそれを 0.0.0.0 に設定することでネゴシエーションのためにオープンしたままにすることは可能です。これは、リモートピアが呼び出し側の識別に基づいた値が正確に供給できるか、リモートアドレスがこちら側で供給されることが必要です。 IPCP オプションネゴシエーションが動作する方法のため、このアドレスはリモートピアを間違った仮定をするかもしれない、ネゴシエーションの間に遅れて供給されます。

同様の精神でリモートアドレスはマジック値 0.0.0.* に設定できます。それが 0.0.0.0 でない限りはどんなアドレスがリモート側で使われるか気にしないことを意味します。利用者の ISP にいくつかのダイヤルインサーバがあるなら、これは役に立ちます。利用者はもちろん route add something_or_other 0.0.0.* を実行できます。それはまさに利用者がやりたいことをするでしょう。

RFC 1334 と RFC 1994 関連に書かれている PAP と CHAP 認証プロトコルもまた実装されています。それらのパラメータは spppcontrol(8) ユーティリティによって制御されます。

VJ ヘッダ圧縮は実装されており、デフォルトで有効です。 spppcontrol(8) を使用して無効にすることができます。

診断

<ifname><ifnum>: <proto> illegal <event> in state <statename>
それぞれの制御プロトコルが現在の状態で起こるべきでないイベントが起こりました。状態オートマトンの説明に関しては RFC 1661 を参照してください。
<ifname><ifnum>: loopback
状態オートマトンは回線ループバックを検出しました (すなわち、それはそれ自体と通信していました)。インタフェースは一時的に無効にされます。
<ifname><ifnum>: up
回線ループバックが以前に検出された後に LCP レイヤは再び実行されます。
<ifname><ifnum>: down
キープアライブ (生き続ける) 機能は、回線が応答しないことを検出しました。キープアライブが行われるためには下位のレイヤによって明らかに要求されなければなりません。

関連項目

inet(4), intro(4), ppp(4), ifconfig(8), spppcontrol(8) W. Simpson, Editor, The Point-to-Point Protocol (PPP), RFC 1661. G. McGregor, The PPP Internet Protocol Control Protocol (IPCP), RFC 1332. B. Lloyd and W. Simpson, PPP Authentication Protocols, RFC 1334. W. Simpson, PPP Challenge Handshake Authentication Protocol (CHAP), RFC 1994.

作者

sppp の始めの実装は Serge Vakulenko <vak@cronyx.ru>によって Cronyx Ltd., Moscow で 1994 年に書かれました。 Jörg Wunsch <joerg_wunsch@uriah.heep.sax.de>は RFC 1661 で記述されるように状態機械を完全に実装するために 1997 年にかなりの部分を書き直したので、ダイヤルアップ回線でそれを使用することができました。彼はまたこのマニュアルページを書きました。 Serge は後に、 Jörg Wunsch によって再び行われた現在の実装のための基本として役立った PAP と CHAP のためのに基本的な実装を書きました。

バグ

たくさん。

現在、 IPCP 制御プロトコルと ip(4) ネットワークプロトコルのみがサポートされます。より多くの NCP は、認証とリンク品質報告のための他の制御プロトコルと同様に実装されるべきです。

ネゴシエーション (交渉) ループの回避は完全に実装されていません。ネゴシエーションが収束しないなら、これは永久ループを引き起こすかもしれません。

RFC 1661 によって調整可能であるべきである様々なパラメータは、現在、カーネルにハードコード (決め打ち) されており、 spppcontrol(8) を通してアクセス可能にするべきです。

パッシブ モードは広範囲にテストされていません。

リンクレベル圧縮プロトコルはサポートされるべきです。

May 25, 2008 FreeBSD