FreeBSD 日本語マニュアル検索 (jman/japropos/jwhatis)


日本語 man コマンド類 (ja-man-1.1j_5) と日本語 man ドキュメント (ja-man-doc-5.4 (5.4-RELEASE 用) など) をインストールすると、以下のような man コマンド閲覧、キーワード検索が コンソールからできるようになります。

4.11-RELEASE-K, 5.4-RELEASE-K, 5.5-RELEASE-K, 6.0-RELEASE-K から 6.4-RELEASE-K, 7.0-RELEASE-K から 7.4-RELEASE-K, 8.0-RELEASE-K から 8.4-RELEASE-K, 9.0-RELEASE-K から 9.3-RELEASE-K, 10.0-RELEASE-K から 10.3-RELEASE-K, 11.0-RELEASE-K から 11.4-RELEASE-K, 12.0-RELEASE-K, 12.1-RELEASE-K は、 プライベート版 (小金丸が編集してまとめたもの) ですが、 より多くの翻訳したファイルが含まれています。 (5.4-RELEASE-K から 6.4-RELEASE-K, 7.0-RELEASE-K から 7.4-RELEASE-K, 8.0-RELEASE-K から 8.4-RELEASE-K, 9.0-RELEASE-K から 9.3-RELEASE-K, 10.0-RELEASE-K から 10.3-RELEASE-K, 11.0-RELEASE-K から 11.4-RELEASE-K, 12.0-RELEASE-K から 12.3-RELEASE-K, 13.0-RELEASE-K から 13.2-RELEASE-K は、全翻訳済み)

13.3-STABLE-K, 15.0-CURRENT-K は現在、作成中で日々更新されています。



検索コマンド: man apropos whatis
コマンド/キーワード:
日本語マニュアル RELEASE :
セクション:
Table of Contents
名称 | 書式 | 解説 | 診断 | 関連項目 | 作者 | バグ
SPPP(4)            FreeBSD カーネルインタフェースマニュアル            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), 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) を通してアクセス可
     能にするべきです。

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

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

FreeBSD 12.2                     May 25, 2008                     FreeBSD 12.2

Table of Contents

FreeBSD マニュアル検索