<!doctype linuxdoctr system>
<article>
<title>PPP for Linux</title>
<author>Michael Callahan, callahan@maths.ox.ac.uk<newline>
        Al Longyera, longyear@netcom.com</author>
<date>v1.0.1, June 1994</date>

<trans>こじまみつひろ</trans>
<tdate>v1.0.1j, May 18, 1995</tdate>

<abstract>ppp-2.1.2 に付属の README の和訳</abstract>

<p>
<bf>注意: この文書はかなり以前に書かれたものなので、
いまどきの Linux 環境にはあてはまらない箇所があります。
(JF Project)</bf>
</p>

<![IGNORE[

$Id: PPP.README.linux.sgml,v 1.5 2002/03/17 10:20:18 mdk Exp $
$Log: PPP.README.linux.sgml,v $
Revision 1.5  2002/03/17 10:20:18  mdk
	* docs/TIA-HOWTO/TIA-HOWTO.sgml: inserted archived notice.
	* docs/TIA-HOWTO/info (ITEM): changed into archived.
	* docs/TIA-HOWTO/Makefile (SGML2HTML): added.

	* docs/IPX-HOWTO/: ditto.
	* docs/Term-HOWTO/: ditto.
	* docs/PPP.README.linux/: ditto.
	[JF:16294]

Revision 1.4  2001/10/05 23:47:22  senda
SGML 登録, yuji senda

Revision 1.2  2000/05/12 15:20:52  nakano
LINUXDOCTR_2000_05_09 branch merge: migration to linuxdoctr DTD for translation docs

Revision 1.1.1.1.2.1  2000/05/09 12:56:49  nakano
linuxdoc->linuxdoctr

Revision 1.1.1.1  1999/02/22 19:20:57  baba


# Revision 1.1  1995/05/18  15:01:29  kojima
# Initial revision
#

PPP for Linux                                             Version 1.0.1
=============                                                  based on
                                                              ppp-2.1.2
                                                              June 1994

Michael Callahan    callahan@maths.ox.ac.uk
Al Longyear         longyear@netcom.com

  目次：
    ・イントロダクション
    ・著作権表示
    ・将来の予定
    ・インストール
	・ネットワークの概説
	・PPP サーバーとの接続
	・うまくいったなら、、
	・ダメだったら、、
	・それでもダメなら、、(バグレポート)
	・動的アドレス割り当て
	・PPP 接続を受ける側のセットアップ	
	・PPP チャンネルを増したい
	・LINUX PPP 0.1.x との違い
	・結論
]]>

<sect>はじめに
<p>
<sect1>イントロダクション
<p>
これは Linux 用の PPP ドライバです。多くの人が使っており、きわめて安定
しているように見えます。このドライバは 'クライアント' -- 例えば Linux 
マシンを使ってインターネットプロバイダと接続する -- としても使えるし、'
サーバー' -- モデムとインターネットにつながったイーサネットを持ってい
る Linux マシンを使ってダイアル・イン PPP 接続をする -- としても使えま
す。(実際のところ、PPP のプロトコルにはクライアントとサーバーの区別は
ありませんが、このように説明した方がわかりやすいでしょう)

PPP プロトコルは 2 つの部分からできています。一つはデータをフレーム化
しパケットに包む部分。もう一つは LCP, IPCP, UPAP, CHAP と呼ばれるプロ
トコルの部分で、接続時のオプションをやりとりしたり認証をしたりします。
このパッケージも同様に 2 つの部分から出来ています。一つは PPP の低レベ
ルのフレーミングプロトコルを行うカーネルモジュール、もう一つは pppd と
呼ばれるユーザーレベルのプログラムで、 PPP の接続を行うプロトコルを実
装しています。

カーネルモジュールは PPP のフレームを合成/分解し、エラーを検出し、シリ
アルポートとカーネルのネットワークコード、あるいはユーザーレベルのプロ
グラムである pppd との間でパケットのやり取りを行います。IP パケットは
直接カーネルのネットワークコードに送られますので、pppd はいったん接続
を完成すれば、接続を終了するまで完全な休眠状態に入ります。接続を終了す
る時に再度 pppd は目覚めて、接続を正しく終了させます。

</sect1>

<sect1>著作権表示
<p>
私(MJC)がオリジナルのカーネルドライバを 0 から書きあげました。 
Laurence Culhane tol Fred van Kempen の <tt>slip.c</tt> が貴重なモデルになりま
した(私の書いたプログラムを熟読すれば slip.c を真似ている所が多々ある
ことがわかるでしょう)。しかしながら、私は pppd に必要な機能を RFC1331 
をガイドにして実装しました。Linux 用のドライバは大部分 386BSD や SunOS 
用と同じインターフェースを使っています。異なる点は、Linux は非同期 I/O 
をサポートしていないところです。だから、私は ioctl をハックして、パケッ
トが来たら PPP をサポートするカーネルモジュールがシグナルを出すように
して、pppd が代りにこのシグナルを使うようにしました。

Al Longyear が pppd のバージョン 2.0.4 を (ppp-2.0.4 のフリーなパッケー
ジから)移植しました。彼はまた、カーネルドライバと pppd の OS から独立
している部分について、いくつかの機能強化を行いました。Linux の PPP に
対する彼の貢献はきわめて大なので、このリリースは私たちの連名で行なって
います。

pppd プログラムは Paul Mackerras がメンテナンスしている Sun と 386BSD 
用のフリーな PPP プログラムから作りました。このパッケージには、以下の
人々への「感謝」が述べられています。

Brad Parker, Greg Christy, Drew D. Perkins, Rick Adams and Chris
Torek.

</sect1>

<sect1>将来の予定
<p>
欠けている主要な機能は、リモートホストへのパケットが生成された時に自動
的に PPP の接続を実行する機能です("デマンド・ダイリング")。この件に関
しては現在も作業中ですが、いくつか瑣末なデザイン上の問題が残っています。

</sect1>
</sect>

<sect>インストール
<p>
このバージョンの PPP は 1.0.x (x=0..9) と 1.1.x (x=0..14) カーネルでテス
トしています。ルーティング回りのコードが変更されているため、これ以前の
カーネルではうまく動かないでしょう。もし、古いバージョンのカーネルを使っ
ているなら、アップグレードしてください。

<sect1>linux-activists の PPP チャンネルへの招待：
<p>
これはイントールには直接関係ありませんが、もし Linux PPP をよく使うよ
うなら、PPP のメーリングリストへ参加してください。参加するためには、

<tscreen><verb>
X-Mn-Admin: join PPP 
</verb></tscreen>

と書いたメールを linux-activists-request@niksula.hut.fi に送ります。
メーリングリストへ投稿するには、 linux-activists@niksula.hut.fi へ、本
文の最初に

<tscreen><verb>
X-Mn-Key: PPP
</verb></tscreen>

と書いて送ります。

このメーリングリストに参加すると、PPP に関するアップグレードやパッチに
ついての情報が得られますし、多くの PPP のベテランの経験を聞くことも可
能でしょう。もし問題が起きれば、私自身が診断することもできますが、たい
ていの問題は誰かが既に解決済みです。

注意して欲しいのですが、私は Usenet の linux 関連のニュースグループを
定期的に読んでいるわけではないので、必ずしもそこで為される PPP に関す
る議論にはついていけません。もし PPP について特に議論したい場合、ぜひ 
linux-activists の PPP チャンネルに参加してください。

PPP のメーリングリストから抜けるには :-( 、メールの本文に

<tscreen><verb>
X-Mn-Admin: leave PPP 
</verb></tscreen>

と書いて linux-axtivists-request まで送ってください。

投稿するためには、参加した時のアドレスと正確に同じアドレスを使ってくだ
さい。すなわち、アカウント名、ホスト名、システム名が同じでなければなり
ません。

</sect1>

<sect1>カーネルドライバのインストール：
<p>
これは、使っているカーネルのバージョンに依存します。

1.1.14 からは、PPP のサポートは Linux のカーネルに組みこまれました。
PPP を使うかどうかは "<tt>make config</tt>" の際に Y か N で答えます。

決して、決して、このパッケージのファイルをカーネルのものと入れかえては
いけません。カーネルは常にこのパッケージに含まれているファイルよりも新
しいものを使っています。

1.1.13 でも PPP に関するコードはありましたが、<tt>confing.in</tt> の 
PPP に関する項目はコメントアウトされていました。もし 1.1.13 を使って
いるなら、アップグレードした方がいいでしょう。

1.1.13 以前のカーネルでは (全ての 1.0.x のカーネルも含めて)、長い間、 
PPP に関するコードはサポートされていましたが、カーネルの設定の際には隠
してありました。PPP のカーネルドライバを組みこむことは簡単です：

<enum>
<item>
このパッケージに含まれている <tt>ppp.c</tt> を <tt>drivers/net</tt> にコピー
し、<tt>ppp.h</tt> は <tt>include/linux</tt> にコピーします。

<item>
<tt>config.in</tt> の <tt>CONFIG_PPP</tt> の行のコメントを外します。

<item>
もし 1.1.3 以前(1.0.x も含めて)のカーネルを使っているなら：
<tt>ppp.c</tt> の <tt>/* #define NET02D</tt> で始まる行の "<tt>/*</tt>" 
を削除して、コメントアウトを外します。

<item>
カーネルソースのトップディレクトリ (たいていは <tt>/usr/src/linux</tt>) 
から、

<tscreen><verb>
make config
make dep
make
</verb></tscreen>

を実行します。
</enum>

新しいカーネルでリブートしてください。起動時に以下のようなメッセージが
出力されるはずです：

<tscreen><verb>
PPP: version 0.2.7 (4 channels) NEW_TTY_DRIVERS OPTIMIZE_FLAGS
TCP compression code copyright 1989 Regents of the University of California
PPP line discipline registered.
</verb></tscreen>

最初の行の大文字の部分が多少異なっていても気にする必要はありません。

もし 4 チャンネル以上 PPP で使いたい場合、<!--下の "ADDING MORE PPP
CHANNELS-->後述する <ref id="adding-channels" 
name="PPP チャンネルを増やしたい">を参照してください。

次に、<tt>/proc/net/dev</tt> の中身を見てみましょう。
こんな風になっているはずです。

<tscreen><verb>
Inter-|   Receive                  |  Transmit
 face |packets errs drop fifo frame|packets errs drop fifo colls carrier
    lo:      0    0    0    0    0        0    0    0    0     0    0
  ppp0:      0    0    0    0    0        0    0    0    0     0    0
  ppp1:      0    0    0    0    0        0    0    0    0     0    0
  ppp2:      0    0    0    0    0        0    0    0    0     0    0
  ppp3:      0    0    0    0    0        0    0    0    0     0    0
</verb></tscreen>

こうなっていれば、ドライバは正しくインストールされています。

(もちろん、もし何かうまくいかなくても、PPP を使わなければカーネル自体
には問題はありません)

</sect1>

<sect1>pppd のインストール：
<p>
もし pppd を再コンパイルしたいなら、pppd サブディレクトリへ移動して、

<tscreen><verb>
ln -s Makefile.linux Makefile 
make 
</verb></tscreen>

とします。<tt>lcp.c</tt> や <tt>upap.c</tt>、<tt>chap.c</tt> をコンパイル
する際にいくつかワーニングメッセージが出るかも知れませんが大丈夫です。

chat も再コンパイルしたい時は、<tt>chat</tt> のディレクトリにある 
<tt>README.linux</tt> をチェックしてください。

インストールするには、chat と pppd それぞれのディレクトリで '<tt>make
install</tt>' します。こうすれば chat と pppd のバイナリが <tt>
/usr/etc</tt> にインストールされ、pppd.8 のマニュアルは 
<tt>/usr/man/man8</tt> にインストールされます。

pppd はルートの権限で実行しなければいけません。ルートに setuid するか、
ルートになって実行してください。'<tt>make install</tt>' すれば、
自動的にルートに setuid するようになっています。ユーザーが一人しか
いないマシンでは setuid するのが便利ですが、複数のユーザーが使う
マシンにインストールする際にはセキュリティ上の問題を十分にチェック
してください。

</sect>

<sect>ネットワークの概説
<p>
多くの人が PPP で初めて Linux のネットワーク回りのコードを使うことにな
るので、このセクションではネットワークを利用するために必要なことの概略
を説明します。原理的には、この章で説明することは PPP 独自のものではあ
りません。より詳細については、関係する Linux の各種 HOWTO を参照してく
ださい。もしネットワーク回りの設定を十分理解しているなら、この章は飛ば
して結構です。

まず最初にチェックすべきファイルは、起動時にネットワーク回りの設定を行
なう <tt>rc</tt> スクリプトです。このファイルは使っている Linux の
ディストリビューションによって多少名前は異なっていますが、
<tt>/etc/rc.net</tt> や <tt>/etc/rc.d/rc.net.{1,2}</tt> のような名前に
なっています。このファイルで、ループバックインターフェース <tt>lo</tt> 
を '<tt>ifconfig</tt>' して、そのインターフェースに
対する経路を設定します。その行はこんな風になっているはずです。

<tscreen><verb>
$CONFIG lo 127.0.0.1
$ROUTE add loopback
</verb></tscreen>

あるいは

<tscreen><verb>
/sbin/ifconfig lo 127.0.0.1
/sbin/route add 127.0.0.1
</verb></tscreen>

しかしながら、イーサネットカードやインストールされている他のどんな経路
(route)も設定しては *いけません* (もし実際にイーサネットカードを持って
いるのでない限り。もしイーサネットカードを持っているなら、どうすべきか
御存知のことと思います)。多くのディストリビューションがイーサネットを
持っている場合の設定を提供しています。

また、外部からの telnet/ftp/finger を許すかどうかも決めないといけませ
ん。もし許すなら、<tt>rc</tt> の起動スクリプトの中で '<tt>inetd</tt>' 
デーモンを動かします。

次に、<tt>/etc/hosts</tt> を修正して、次の 2 行を加えます。最初のものは
ループバック、すなわち自分自身のローカルホストとしてのアドレスで、
2 つめのものは実際に PPP 接続の際に使うホストネームと IP アドレスです。
例えば、

<tscreen><verb>
127.0.0.1  loopback localhost   # useful aliases
192.1.1.17  billpc.whitehouse.gov bill  # my hostname
</verb></tscreen>

のようにします。この例では、私の使う IP アドレスは 192.1.1.17 で、私の
ホストの名前は billpc.whitehouse.gov となります(もちろん冗談ですよ)。
もしお使いの PPP サーバーが動的な IP アドレスの割り当てに対応している
なら、実際に割り当てられる IP アドレスは接続時に決定されることになりま
す(後述の "<ref id="dynamic" name="動的アドレス割り当て">" をご覧
ください)。

最後に、<tt>/etc/resolv.conf</tt> を適切に定義してドメインネーム
システムを設定します。<tt>/etc/resolv.conf</tt> はこんな形になります。

<tscreen><verb>
domain whitehouse.gov
nameserver 192.1.2.1
nameserver 192.1.2.10
</verb></tscreen>

ネームサーバーを 192.1.2.1 と 192.1.2.10 と仮定すると、PPP で接続した
場合、正式なホスト名は 'hillarypc.whitehouse.gov' や '
chelseapc.whitehouse.gov'といったホストを 'hillarypc' や 'chelseapc' 
と言う名でアクセスすることができます。適切なドメイン名や使うネームサー
バーの IP ナンバーなどは PPP の接続先に問いあわせてください。

</sect>

<sect>PPP サーバーとの接続
<p>
PPP を使う際には、pppd プログラムを適切なオプションをつけて起動します。
知るべきことすべては pppd(8) のマニュアルページにあります。しかし、い
くつかの例を見ておくことは有益でしょう。

<sect1>例 1：簡単なダイアルアップ接続
<p>
モデムを経由して PPP サーバーに接続する場合、このようなコマンドを使い
ます。

<tscreen><verb>
pppd connect 'chat -v "" ATDT5551212 CONNECT "" ogin: ppp word: whitewater' \
      /dev/cua1 38400 -detach debug crtscts modem defaultroute 192.1.1.17:
</verb></tscreen>

pppd のオプションを順に見てみましょう。

<descrip>
<tag><tt>connect 'chat etc...'</tt></tag>
 このコマンドで PPP サーバーと接続を開始します。
ここで使っている 'chat' というプログラムでリモートのコンピュータに電話
をかけます。'connect' コマンドに一つの引数しかあたえられないため、コマ
ンド全体をシングルクォート(')で括る必要があります。'chat' 自身のオプショ
ンは、

<tscreen><verb>
-v 冗長モード： syslog に記録が残されます
""           ： プロンプトを待たずに、、
ATDT 5551212 ： モデムにダイアルコマンドを送り、
CONNECT      ： 返事を待って、
""           ： リターンコードを送り(長さ 0 の文字列と
                通常のリターンコード)、
ogin: ppp word: whitewater ログインします。
</verb></tscreen>

<tag><tt>/dev/cua1</tt></tag>
これはシリアルポートの <tt>cua1</tt> を使うことを指示します。

<tag><tt>38400</tt></tag>
これはボーレートの指定。

<tag><tt>-detach</tt></tag>
通常、pppd はフォークして自分自身をバックグラウンドで実行しま
すが、このオプションをつけるとそうしなくなります。

<tag><tt>debug</tt></tag>
 各種の記録を syslog に残します。

<tag><tt>crtscts</tt></tag>
コンピュータとモデムの間をハードウェアフローコントロールとしま
す (38400 のボーレートではこうしなければいけません)。

<tag><tt>modem</tt></tag>
モデムデバイスを使うことを指示します；このオプションを指定すると、
pppd は電話の前後で回線をハングアップします。

<tag><tt>defaultroute</tt></tag>
いったん PPP の接続が確立したら、それをデフォルトの経路
(default route)とします；もし PPP を使って Internet に接続したいとすれ
ば、こうすることが目的です。

<tag><tt>192.1.1.17:</tt></tag>
これは正式なオプションである <tt>x.x.x.x:y.y.y.y</tt> を省略した形
です。ここで <tt>x.x.x.x</tt> はローカルか IP アドレスで 
<tt>y.y.y.y</tt> が PPP 接続のリモート端の IP アドレスになります。
もしこのオプションが指定されないか、(この例のように)片側だけが
指定されたら、<tt>x.x.x.x</tt> は <tt>/etc/hosts</tt> にある
ローカルマシンのホスト名の IP アドレスを使用し、<tt>y.y.y.y</tt> 
の部分はリモートのマシンで決定されます。ですから、ここで述べている
架空のマシン、'billpc' の場合、この指定は実際には冗長なものでした。

</descrip>

pppd はエラーメッセージとデバッグ出力を syslogd デーモンに "local2" と
いう名前で出力します(chat を <tt>-v</tt> オプションで起動した時も同様)。
これらのメッセージはあらかじめコンソールや <tt>/usr/adm/messages</tt> 
といったファイルに出力されるようになっているかも知れません；
どういう設定になっているかは <tt>/etc/syslog.conf</tt> ファイルを
見てください。もし pppd と chat のメッセージを全てコンソールに出力
したければ、<tt>syslog.conf</tt> ファイルに

<tscreen><verb>
local2.*		/dev/console
</verb></tscreen>

という行を加えます。"<tt>local2.*</tt>" と "<tt>/dev/console</tt>" 
の間に 1 つ以上の TAB コードが必要なことに注意してください。

</sect1>

<sect1>例 2：専用線を使って PPP サーバーに接続する場合
<p>
これはもう少し複雑な例です。次に示すのが、Morningstar 製の PPP が動い
ている Ultrix マシンに直接接続された Gandalf から PPP 接続するために私
が使っているスクリプトです。

<tscreen><verb>
pppd connect /etc/ppp/ppp-connect defaultroute noipdefault debug \
      kdebug 2 /dev/cua0 9600
</verb></tscreen>

ここで、<tt>/etc/ppp/ppp-connect</tt> はこんなスクリプトになっています：

<tscreen><verb>
#! /bin/sh
/etc/ppp/sendbreak
chat -v -t60 "" \; "service :" blackice ogin: callahan word: PASSWORD \
    black% "stty -echo; ppp" "Starting PPP now"  &amp;&amp; sleep 5
</verb></tscreen>

まず break 信号を送り、ターミナルサーバーを起動します。次にセミコロン
を送って(私の使っているターミナルサーバーではセミコロンでボーレートの
自動選択を行います)、"<tt>blackice</tt>" というサービスを要求します。
ログインして、"<tt>black%</tt>" というシェルのプロンプトが出るのを待ち、
PPP を起動します。<tt>-t60</tt> という引数はタイムアウトまで 1 分間
かける、という意味です。時々、このシステムはきわめて遅くなることがあるので。

"<tt>&amp;&amp; sleep5</tt>" でスクリプトは 5 秒間停止しますが、
それでも chat が失敗した場合、即座に終了します。
こうして PPP サーバーに起動する時間を与えて
います(とても遅いので)。また、"<tt>stty -echo</tt>" というオプション
は私にとってきわめて重要な意味をもっています；このオプションをつけないと、
リモートの PPP サーバーがエコーをオフにする以前に、手元の pppd がネゴシエー
ション用のパケットを送ってしまうことがたまにあるからです。リモートの 
PPP サーバーがエコーをオフにしていない状態でネゴシエーション・パケット
を送ると、パケットはそのまま手元のマシンに帰ってきてしまい、拒否されて
しまいます(PPP はループバックを検出できます)。そして、リモートの PPP 
の準備ができる前に手元の pppd はエラー終了してしまいます。"
<tt>stty -echo</tt>" 
オプションはこれを防ぎます。この種の問題は、遅い Unix マシンを PPP サー
バーにしているごく僅かの人々にしか起らないことでしょうが、原因を究明す
るまでに時間もかかったので、あえてここで言及しておきました。

その他の pppd のオプションはよく似たものです。"<tt>noipdefault</tt>" 
と "<tt>kdebug 2</tt>" というオプションが新しいものでしょうか。"
<tt>noipdefault</tt>" オプションを指定すると、pppd は使うべき IP 
アドレスをリモート側に問いあわせます；
私の場合のように、PPP サーバーに IP アドレスの動的割り当て機能がある場
合、このオプションが必要となります(すなわち、事前にどのアドレスになる
かはわからない)。"<tt>kdebug 2</tt> "というオプションは、カーネルのデバッグレベ
ルを 2 に設定するもので、カーネル内の ppp に関するコードからの出力が多
少詳しくなります。

いずれにせよ、接続がちゃんとできたとすれば、chat がモデムに電話をかけ
させ、 pppd からいくつかのメッセージが出力され(<tt>syslog.conf</tt> の
設定に応じて)、その後、こんなカーネルからのメッセージが出力されるはずです。

<tscreen><verb>
ppp: channel ppp0 mtu changed to 1500
ppp: channel ppp0 open
ppp: channel ppp0 going up for IP packets!
</verb></tscreen>

(このメッセージは "<tt>kdebug 2</tt>" オプションを付け、<tt>
kern.info</tt> メッセージが直接スクリーンに出力されるような設定になって
いる場合にのみ表示されます) 同時に、pppd は関係するメッセージを 
<tt>/usr/adm/messages</tt> (<tt>syslong.conf</tt> の
設定によっては別のログファイルかも知れません)に出力します。

</sect>

<sect>テストとトラブルシューティング
<p>
<sect1>うまくいったなら、、
<p>
うまく接続できたようなら、テストする方法はいっぱいあります。

まず第一に、

<tscreen><verb>
/sbin/ifconfig 
</verb></tscreen>

とタイプします(もしかすると、使っているシステムによっては <tt>ifconfig</tt> 
が <tt>/sbin</tt> 以外の場所にあるかも知れません)。このコマンドは '
<tt>UP</tt>' の
状態にある全てのネットワークインターフェースを表示します。
<tt>ppp0</tt> がその中にある
はずで、最初に示された IP アドレスがあなた自身のもの、"
<tt>POINT-TO-POINT ADDR</tt>"で示されているのがサーバーのアドレスです。
私のマシンではこんな風になります。

<tscreen><verb>
lo        Link encap Local Loopback  
          inet addr 127.0.0.1  Bcast 127.255.255.255  Mask 255.0.0.0
          UP LOOPBACK RUNNING  MTU 2000  Metric 1
          RX packets 0 errors 0 dropped 0 overrun 0
          TX packets 0 errors 0 dropped 0 overrun 0

ppp0      Link encap Point-Point Protocol
          inet addr 192.76.32.2  P-t-P 129.67.1.165  Mask 255.255.255.0
          UP POINTOPOINT RUNNING  MTU 1500  Metric 1
          RX packets 33 errors 0 dropped 0 overrun 0
          TX packets 42 errors 0 dropped 0 overrun 0
</verb></tscreen>

次に 

<tscreen><verb>
ping z.z.z.z
</verb></tscreen>

とします。ここで、<tt>z.z.z.z</tt> は使っているサーバーのアドレスです。
これは大丈夫なはずです。私の場合、こんな風になりました。

<tscreen><verb>
waddington:~$ ping 129.67.1.165
PING 129.67.1.165 (129.67.1.165): 56 data bytes
64 bytes from 129.67.1.165: icmp_seq=0 ttl=255 time=268 ms
64 bytes from 129.67.1.165: icmp_seq=1 ttl=255 time=247 ms
64 bytes from 129.67.1.165: icmp_seq=2 ttl=255 time=266 ms
^C
--- 129.67.1.165 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 247/260/268 ms
waddington:~$
</verb></tscreen>

次に 

<tscreen><verb>
netstat -nr
</verb></tscreen>

とします。こうすれば、こんな風に 3 つの経路が示されるはずです。

<tscreen><verb>
Kernel routing table
Destination     Gateway         Genmask         Flags Metric Ref Use    Iface
129.67.1.165    0.0.0.0         255.255.255.255 UH    0      0        6 ppp0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         129.67.1.165    0.0.0.0         UG    0      0     6298 ppp0
</verb></tscreen>

こういう風になっていても、<tt>Destination</tt> 欄に 
<tt>0.0.0.0</tt> という行が見えない
場合(この行が接続時のデフォルトの経路となります)、pppd に '
<tt>defaultroute</tt>' 
オプションをつけていない可能性があります。

ここまで確認できれば、telent/ftp/finger 等、何でも好きなものを使ってみ
てください。しかし、<tt>/etc/resolv.conf</tt> を正しく設定していない場合、
(ホスト名やドメイン名ではなく)、相手の指定は数字の IP アドレスを使わなけれ
ばならないことに注意してください。

</sect1>

<sect1>ダメだったら、、
<p>
linux サブディレクトリによくある問題についての短い FAQ を用意しました。

もし接続でいないようなら、pppd からの '<tt>debug</tt>' 情報をチェック
してください。このためには pppd を '<tt>debug</tt>' オプション付きで
起動して、<tt>/etc/syslog.conf</tt> ファイルに

<tscreen><verb>
local2.*					/dev/console
local2.*					/usr/adm/ppplog
</verb></tscreen>

と書いておく必要があります。

こうしておけば、pppd のメッセージが今使っているコンソールと 
<tt>/usr/adm/ppplog</tt> の双方に出力されます。左の欄("<tt>local2.*</tt>") 
と右の欄 ("<tt>/dev/console</tt>", "<tt>/usr/adm/ppplog</tt>") の間には一つ
以上の TAB コードが入っていないといけません。<tt>/etc/syslog.conf</tt> を
修正したら、syslogd のプロセスナンバーを指定して、'<tt>
kill -HUP &lt;syslogd の pid&gt;</tt>' を実行し、現在動い
ている syslogd に設定ファイルを読みこませます。

そうすると、以下のようなメッセージが表示されるはずです。

<itemize>
<item>"<tt>pppd&lsqb;NNN&rsqb;: Connected...</tt>" <newline>
"connect" スクリプトが正しく終了しました。
<item>"<tt>pppd&lsqb;NNN&rsqb;: sent &lsqb;LCP ConfReq</tt>"... <newline>
pppd はリモート側とネゴシエーションを開始しました。
<item>"<tt>pppd&lsqb;NNN&rsqb;: recv &lsqb;LCP ConfReq</tt>"... <newline>
pppd はリモート側からネゴシエーション用のフレームを受信しました。
<item>"<tt>pppd&lsqb;NNN&rsqb;: ipcp up</tt>" <newline>
IP トラフィックを通すための接続が確立したと pppd は解釈しました
</itemize>

もし "<tt>recv</tt>" メッセージが出ない場合、接続そのものに重大な
問題が生じています(例えば 8 ビット全てを正しく通していないとか)。
その場合、あなたのコンピュータとリモート側の PPP サーバーとの間を通過
した全てのデータをデバッグ・ログファイルに書きだしておくのが解決に
役立ちます。こうするためには、<tt>syslog.conf</tt> ファイルに

<tscreen><verb>
local2.*,kern.*				/dev/console
local2.*,kern.*				/usr/adm/ppplog
</verb></tscreen>

と書き、上と同じように syslog デーモンに <tt>HUP</tt> シグナルを
送ります。そして、pppd を "<tt>kdebug 5</tt>" オプションをつけて
起動すれば PPP の接続線上を流れた全てのキャラクターがデバッグ出力
に書きだされます。

時おり、こんなメッセージが出ることもあります。

<tscreen><verb>
ppp_toss: tossing frame, reason = 4
</verb></tscreen>

このメッセージはシリアル回線のオーバーランのため、PPP コードがリモート
サーバーからのパケット("フレーム")を捨てていることを意味します。このメッ
セージが出る場合、あなたのコンピュータの CPU は能力不足で、シリアルポー
トにキャラクタが届いてから読み出しまでに時間がかかっています；最善の解
決法はシリアルポートに 16550A チップを使うことです。このチップは内部バッ
ファを持っており、CPU に読み出すための時間的余裕を与えます。"
<tt>reason =4</tt>" 以外の場合は、起るべきではないシリアル回りのエラーが
起きていることを意味しています。

接続の最初の段階では、"<tt>bad fcs</tt>" というメッセージが何度か出る
かも知れません。これは受けとった PPP フレームのチェックサム・エラーを
意味しています。これが起きるのは、たいてい、接続の開始時にリモート側の
システムが何か "テキスト" メッセージ、例えば "
<tt>hello this is the XYZ company</tt>" を
送っている場合です。いったん接続が確立し、経路制御も完了した後に "
<tt>bad fcs</tt>" というメッセージが出るのは正常なことではなく、
伝送時のエラーか電話線のノイズを意味します。

</sect1>

<sect1>それでもダメなら、、(バグレポート)
<p>
これでもまだ動かなければ、linux-activists の PPP チャンネルにバグレポー
トを送ってください。可能な限り多くの情報が入っていることが肝要です。必
要な情報の例として、

<itemize>
<item>使っているカーネルのバージョン
<item>使っている Linux PPP のバージョン
<item>PPP セッションを開始するのに使っているコマンド
<item><tt>syslog.conf</tt> ファイルに <tt>local2.*</tt>, 
<tt>kern.*</tt> を指定して得られた '<tt>debug</tt>' 出力
<item>接続先の PPP の種類(例えば Xyzzy Corp のターミナルサーバー、モーニ
ングスター製の PPP ソフト、などなど)
<item>接続形態(モデム、専用線、などなど)
</itemize>

</sect1>
</sect>

<sect>追加設定
<p>
<sect1>動的アドレス割り当て <label id="dynamic">
<p>
Linux の PPP は接続するたびに異なる IP アドレスが割り当てられる PPP サー
バーとも接続することができます。 IP アドレスを割りあててもらうようにリ
モートホストへリクエストを出すには '<tt>noipdefault</tt>' オプションを
使います。

Linux のクライアント(例えば "talk" など)を使った場合、"
<tt>Cannot assign requested address</tt>" というエラーメッセージが出る
ことがあります。これは <tt>/etc/hosts</tt> に記述してある自分自身の IP 
アドレスと PPP インターフェース
に割り当てられた IP アドレスが異なるからです。解決法は、
<tt>ifconfig ppp0</tt> として使っているインターフェースのアドレスを
チェックし、<tt>/etc/hosts</tt> を修正してそれに合わせることです。

</sect1>

<sect1>PPP 接続を受ける側のセットアップ
<p>
他のマシンからあなたのマシンを呼びだし PPP 接続をしたい、というわけで
すね。これも Linux PPP では可能です。

まず第一に、あなたの Linux マシンがシリアルラインからの呼出しに正しく
答えて、ログイン・プロンプトを出しているか確認してください。確認するため
には、あなたのマシンへ電話をかけて、普通のユーザーとしてログインし、シェ
ルプロンプトがちゃんと出て、各種コマンドが正しく使えるかチェックしてく
ださい。この文書では Linux マシンを、かかってきた電話に答えるようにセッ
トアップする方法については扱いません。それらについては、システムに附属
の文書、あるいは Serial HOWTO (<htmlurl 
url="http://www.linux.or.jp/JF/JFdocs/Serial-HOWTO.html" 
name="日本語訳">) を参照してください。

次に、PPP サービスを提供できるようにします。一つの方法は、例えば '
<tt>ppp</tt>' というアカウント名を作り、ログイン時に起動されるシェルを 
pppd を起動するための短いスクリプトにすることです。この方法を取る場合、
<tt>/etc/passwd</tt> 
にこんなエントリを追加することになります。

<tscreen><verb>
ppp:(encrypted password):102:50:PPP client login:/tmp:/etc/ppp/ppplogin
</verb></tscreen>

起動している <tt>/etc/ppp/ppplogin</tt> はこんな実行可能な
シェルスクリプトです。

<tscreen><verb>
#!/bin/sh
exec /usr/etc/pppd passive :192.1.2.23
</verb></tscreen>

&lsqb;訳注：モデム経由で使うなら <tt>modem</tt> オプションを付けないと正しく 
hang up しないことがあります。&rsqb;

この設定では、リモートのマシン(接続してくるマシン)の IP アドレスは 
<tt>192.1.2.23</tt> で、PPP インターフェースを使うローカルの(ホスト側の) 
IP アドレスは <tt>/etc/hosts</tt> に書いてあるマシン名に対応した IP 
アドレスになります。'<tt>passive</tt>' オプションをつけると 
(必須ではないのですが)、pppd は起動
時にネゴシエートしようとして、返事が無い場合はそのまま黙って待ち状態に
なります。リモート側のマシンがネゴシエートの準備ができるまでに多少の時
間がかかる場合、このオプションを使うといいでしょう('<tt>passive</tt>' 
オプションは ppp-1.3 と ppp-2.0 の間で変更されていることに注意)

2 台のマシンを接続するだけならこのセットアップで十分ですが、もし Linux
PPP を使って外部のマシンをネットワークと接続する場合、あるいは 2 つの
ネットワークを接続するような場合には、ネットワークから PPP 接続へパケッ
トを送る経路情報を設定しなければなりません。ネットワーク間の接続につい
ての設定はこの文書の範囲外です；pppd の経路制御に関するオプションにつ
いて、マニュアルページを詳しく読んで、routed などに関する記述を見つけ
てください。

ここでは最初の場合のみを考えます。イーサネットに接続された Linux マシ
ンがあって、それに PPP で外部から接続して、イーサネット上のマシンと通
信する、と仮定しましょう。このためには、リモートのマシンにローカルなイー
サネットセグメント上のマシンと同じ IP アドレスを与えて、サーバーとして
使う pppd に '<tt>proxyarp</tt>' オプションをつける必要があります。
ここでは、以下のような接続を考えてみます：

<tscreen><verb>
 192.1.2.23                        192.1.2.17
+-----------+      PPP link       +----------+
| chelseapc | ------------------- |  billpc  |
+-----------+		          +----------+
                                        |           Ethernet 
                            ----------------------------------- 192.1.2.x
</verb></tscreen>

この場合、billpc の PPP インタフェースとイーサネットインタフェースは同
じ IP アドレス 192.1.2.17 を持っています(一台のマシンで一つ、あるいは
複数の PPP インタフェースがイーサネット・インタフェースと同じ IP アド
レスを持つことは可能です)。billpc の <tt>/etc/passwd</tt> ファイルには 
chelseapc が <tt>/etc/ppp/ppplogin</tt> スクリプトを起動できるような設定
があります。<tt>/etc/ppp/ppplogin</tt> スクリプトはこうなっています。

<tscreen><verb>
#!/bin/sh
exec /usr/etc/pppd passive proxyarp :192.1.2.23
</verb></tscreen>

接続が開始されると、pppd は chelseapc へのエントリを billpc の arp テー
ブルに "<tt>proxy arp</tt>" として追加します。こうすれば、192.1.2.x の
イーサネット上のマシンに対して、billpc (192.1.2.17) のイーサネット・
インターフェースが chelseapc (192.1.2.23) でもあるかのようにふるまいます。
こうすることで、chelseapc があたかも直接にイーサネットに接続されたマシン
のように通信することが可能になります。

</sect1>

<sect1>PPP チャンネルを増したい <label id="adding-channels">
<p>
デフォルトでは Linux PPP は 4 つのカーネルチャンネルを使うようになって
ます。すなわち、同時に最大 4 つの PPP セッションが可能、ということです。
もし、もっと多くのセッションが必要なら(例えば、多くのダイアル回線にサー
ビスを提供する、など)、カーネルのソースコードを修正して、新しくチャン
ネルを追加することができます。これには 2 つのステップがあります。

第一に、<tt>drivers/net/Space.c</tt> のファイルを修正します。
配布されている状態では、このような部分があるはずです。

<tscreen><verb>
#if defined(CONFIG_PPP)
extern int ppp_init(struct device *);
static struct device ppp3_dev = {
    "ppp3", 0x0, 0x0, 0x0, 0x0, 3, 0, 0, 0, 0, NEXT_DEV,  ppp_init, };
static struct device ppp2_dev = {
    "ppp2", 0x0, 0x0, 0x0, 0x0, 2, 0, 0, 0, 0, &amp;ppp3_dev, ppp_init, };
static struct device ppp1_dev = {
    "ppp1", 0x0, 0x0, 0x0, 0x0, 1, 0, 0, 0, 0, &amp;ppp2_dev, ppp_init, };
static struct device ppp0_dev = {
    "ppp0", 0x0, 0x0, 0x0, 0x0, 0, 0, 0, 0, 0, &amp;ppp1_dev, ppp_init, };
#undef NEXT_DEV
#define NEXT_DEV (&amp;ppp0_dev)
#endif   /* PPP */
</verb></tscreen>

パターンは明解ですね。チャンネルを追加するには、"
<tt>static struct device pppN_dev</tt>" 行を追加して、構造体の最初 
(ppp&lsqb;0,1,2&rsqb;と 11 番目の要素 
(&amp;ppp&lsqb;1,2,3&rsqb;_dev) を適切に設定します。
PPP デバイスの最後のものの 11 番目の要素が <tt>NEXT_DEV</tt> になる
ことに注意してください。それ以外のデバイスで
は、<tt>&amp;ppp3_dev</tt> を <tt>&amp;ppp4_dev</tt> などに変更します。

例として、2 チャンネル追加してみましょう。

<tscreen><verb>
#if defined(CONFIG_PPP)
extern int ppp_init(struct device *);
static struct device ppp5_dev = {
    "ppp5", 0x0, 0x0, 0x0, 0x0, 5, 0, 0, 0, 0, NEXT_DEV,  ppp_init, };
static struct device ppp4_dev = {
    "ppp4", 0x0, 0x0, 0x0, 0x0, 4, 0, 0, 0, 0, &amp;ppp5_dev,  ppp_init, };
static struct device ppp3_dev = {
    "ppp3", 0x0, 0x0, 0x0, 0x0, 3, 0, 0, 0, 0, &amp;ppp4_dev,  ppp_init, };
... etc.
</verb></tscreen>

次に (<tt>include/linux</tt> ディレクトリにある) <tt>ppp.h</tt> 
ファイルの以下の行を

<tscreen><verb>
#define PPP_NRUNIT     4
</verb></tscreen>

追加したチャンネル数にあわせて変更します。今回の例では

<tscreen><verb>
#define PPP_NRUNIT     6
</verb></tscreen>

となります。

これで、カーネルを再コンパイルしリブートします。起動時のメッセージと 
<tt>/proc/net/dev</tt> が変更した数を正しく示していることを
確認してください。

</sect1>
</sect>

<sect>LINUX PPP 0.1.x からの変更点
<p>
Linux PPP 0.1.x はフリーに配布されている PPP パッケージの PPP-1.3 を元
にしています。一方、Linux PPP 0.2.1 は PPP-2.0.4 を元にしています。両
者の間では pppd のオプションに多少の変更が行なわれ、各種の機能強化がな
されています。変更点についての詳細は pppd ディレクトリにある 
"<tt>RELNOTES</tt>" を参照してください。

また、PPP-1.3 の Linux バージョンに追加されたオプションのいくつかは名
前が変更されています。

<itemize>
<item>defroute は defaultroute に
<item>kerndebug は kdebug に
<item>dropdtr は modem に、
</itemize>

それぞれ変更されました。

加えて、ローカルの IP アドレスをリモートの PPP サーバーからもらう場合
には '<tt>noipdefault</tt>' オプションが必要になりました。

</sect>

<sect>結論
<p>
Good luck!

Michael

<verb>
-----------------------------------------------------------------------
小島三弘(kojima@komae.denken.or.jp, isle@st.rim.or.jp)
〒 201 東京都 狛江市 岩戸北 2-11-1
(財)電力中央研究所 ヒューマンファクター研究センター
Tel:(03)-3480-2111(ex.649), FAX:(03)-3430-5779
-----------------------------------------------------------------------
</verb>

(sgml conversion, y.senda, ysenda@pop01.odn.ne.jp, 2001/09)

</sect>
</article>
