注意: この文書はかなり以前に書かれたものなので、 いまどきの Linux 環境にはあてはまらない箇所があります。 (JF Project)
これは Linux 用の PPP ドライバです。多くの人が使っており、きわめて安定 しているように見えます。このドライバは 'クライアント' -- 例えば Linux マシンを使ってインターネットプロバイダと接続する -- としても使えるし、' サーバー' -- モデムとインターネットにつながったイーサネットを持ってい る Linux マシンを使ってダイアル・イン PPP 接続をする -- としても使えま す。(実際のところ、PPP のプロトコルにはクライアントとサーバーの区別は ありませんが、このように説明した方がわかりやすいでしょう)
PPP プロトコルは 2 つの部分からできています。一つはデータをフレーム化 しパケットに包む部分。もう一つは LCP, IPCP, UPAP, CHAP と呼ばれるプロ トコルの部分で、接続時のオプションをやりとりしたり認証をしたりします。 このパッケージも同様に 2 つの部分から出来ています。一つは PPP の低レベ ルのフレーミングプロトコルを行うカーネルモジュール、もう一つは pppd と 呼ばれるユーザーレベルのプログラムで、 PPP の接続を行うプロトコルを実 装しています。
カーネルモジュールは PPP のフレームを合成/分解し、エラーを検出し、シリ アルポートとカーネルのネットワークコード、あるいはユーザーレベルのプロ グラムである pppd との間でパケットのやり取りを行います。IP パケットは 直接カーネルのネットワークコードに送られますので、pppd はいったん接続 を完成すれば、接続を終了するまで完全な休眠状態に入ります。接続を終了す る時に再度 pppd は目覚めて、接続を正しく終了させます。
私(MJC)がオリジナルのカーネルドライバを 0 から書きあげました。
Laurence Culhane tol Fred van Kempen の slip.c が貴重なモデルになりま
した(私の書いたプログラムを熟読すれば 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.
欠けている主要な機能は、リモートホストへのパケットが生成された時に自動 的に PPP の接続を実行する機能です("デマンド・ダイリング")。この件に関 しては現在も作業中ですが、いくつか瑣末なデザイン上の問題が残っています。
このバージョンの PPP は 1.0.x (x=0..9) と 1.1.x (x=0..14) カーネルでテス トしています。ルーティング回りのコードが変更されているため、これ以前の カーネルではうまく動かないでしょう。もし、古いバージョンのカーネルを使っ ているなら、アップグレードしてください。
これはイントールには直接関係ありませんが、もし Linux PPP をよく使うよ うなら、PPP のメーリングリストへ参加してください。参加するためには、
X-Mn-Admin: join PPP
と書いたメールを linux-activists-request@niksula.hut.fi に送ります。 メーリングリストへ投稿するには、 linux-activists@niksula.hut.fi へ、本 文の最初に
X-Mn-Key: PPP
と書いて送ります。
このメーリングリストに参加すると、PPP に関するアップグレードやパッチに ついての情報が得られますし、多くの PPP のベテランの経験を聞くことも可 能でしょう。もし問題が起きれば、私自身が診断することもできますが、たい ていの問題は誰かが既に解決済みです。
注意して欲しいのですが、私は Usenet の linux 関連のニュースグループを 定期的に読んでいるわけではないので、必ずしもそこで為される PPP に関す る議論にはついていけません。もし PPP について特に議論したい場合、ぜひ linux-activists の PPP チャンネルに参加してください。
PPP のメーリングリストから抜けるには :-( 、メールの本文に
X-Mn-Admin: leave PPP
と書いて linux-axtivists-request まで送ってください。
投稿するためには、参加した時のアドレスと正確に同じアドレスを使ってくだ さい。すなわち、アカウント名、ホスト名、システム名が同じでなければなり ません。
これは、使っているカーネルのバージョンに依存します。
1.1.14 からは、PPP のサポートは Linux のカーネルに組みこまれました。
PPP を使うかどうかは "make config" の際に Y か N で答えます。
決して、決して、このパッケージのファイルをカーネルのものと入れかえては いけません。カーネルは常にこのパッケージに含まれているファイルよりも新 しいものを使っています。
1.1.13 でも PPP に関するコードはありましたが、confing.in の
PPP に関する項目はコメントアウトされていました。もし 1.1.13 を使って
いるなら、アップグレードした方がいいでしょう。
1.1.13 以前のカーネルでは (全ての 1.0.x のカーネルも含めて)、長い間、 PPP に関するコードはサポートされていましたが、カーネルの設定の際には隠 してありました。PPP のカーネルドライバを組みこむことは簡単です：
ppp.c を drivers/net にコピー
し、ppp.h は include/linux にコピーします。
config.in の CONFIG_PPP の行のコメントを外します。
ppp.c の /* #define NET02D で始まる行の "/*"
を削除して、コメントアウトを外します。
/usr/src/linux)
から、
make config
make dep
make
新しいカーネルでリブートしてください。起動時に以下のようなメッセージが 出力されるはずです：
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.
最初の行の大文字の部分が多少異なっていても気にする必要はありません。
もし 4 チャンネル以上 PPP で使いたい場合、後述する PPP チャンネルを増やしたいを参照してください。
次に、/proc/net/dev の中身を見てみましょう。
こんな風になっているはずです。
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
こうなっていれば、ドライバは正しくインストールされています。
(もちろん、もし何かうまくいかなくても、PPP を使わなければカーネル自体 には問題はありません)
もし pppd を再コンパイルしたいなら、pppd サブディレクトリへ移動して、
ln -s Makefile.linux Makefile
make
とします。lcp.c や upap.c、chap.c をコンパイル
する際にいくつかワーニングメッセージが出るかも知れませんが大丈夫です。
chat も再コンパイルしたい時は、chat のディレクトリにある
README.linux をチェックしてください。
インストールするには、chat と pppd それぞれのディレクトリで 'make
install' します。こうすれば chat と pppd のバイナリが /usr/etc にインストールされ、pppd.8 のマニュアルは
/usr/man/man8 にインストールされます。
pppd はルートの権限で実行しなければいけません。ルートに setuid するか、
ルートになって実行してください。'make install' すれば、
自動的にルートに setuid するようになっています。ユーザーが一人しか
いないマシンでは setuid するのが便利ですが、複数のユーザーが使う
マシンにインストールする際にはセキュリティ上の問題を十分にチェック
してください。
多くの人が PPP で初めて Linux のネットワーク回りのコードを使うことにな るので、このセクションではネットワークを利用するために必要なことの概略 を説明します。原理的には、この章で説明することは PPP 独自のものではあ りません。より詳細については、関係する Linux の各種 HOWTO を参照してく ださい。もしネットワーク回りの設定を十分理解しているなら、この章は飛ば して結構です。
まず最初にチェックすべきファイルは、起動時にネットワーク回りの設定を行
なう rc スクリプトです。このファイルは使っている Linux の
ディストリビューションによって多少名前は異なっていますが、
/etc/rc.net や /etc/rc.d/rc.net.{1,2} のような名前に
なっています。このファイルで、ループバックインターフェース lo
を 'ifconfig' して、そのインターフェースに
対する経路を設定します。その行はこんな風になっているはずです。
$CONFIG lo 127.0.0.1
$ROUTE add loopback
あるいは
/sbin/ifconfig lo 127.0.0.1
/sbin/route add 127.0.0.1
しかしながら、イーサネットカードやインストールされている他のどんな経路 (route)も設定しては *いけません* (もし実際にイーサネットカードを持って いるのでない限り。もしイーサネットカードを持っているなら、どうすべきか 御存知のことと思います)。多くのディストリビューションがイーサネットを 持っている場合の設定を提供しています。
また、外部からの telnet/ftp/finger を許すかどうかも決めないといけませ
ん。もし許すなら、rc の起動スクリプトの中で 'inetd'
デーモンを動かします。
次に、/etc/hosts を修正して、次の 2 行を加えます。最初のものは
ループバック、すなわち自分自身のローカルホストとしてのアドレスで、
2 つめのものは実際に PPP 接続の際に使うホストネームと IP アドレスです。
例えば、
127.0.0.1 loopback localhost # useful aliases
192.1.1.17 billpc.whitehouse.gov bill # my hostname
のようにします。この例では、私の使う IP アドレスは 192.1.1.17 で、私の ホストの名前は billpc.whitehouse.gov となります(もちろん冗談ですよ)。 もしお使いの PPP サーバーが動的な IP アドレスの割り当てに対応している なら、実際に割り当てられる IP アドレスは接続時に決定されることになりま す(後述の " 動的アドレス割り当て" をご覧 ください)。
最後に、/etc/resolv.conf を適切に定義してドメインネーム
システムを設定します。/etc/resolv.conf はこんな形になります。
domain whitehouse.gov
nameserver 192.1.2.1
nameserver 192.1.2.10
ネームサーバーを 192.1.2.1 と 192.1.2.10 と仮定すると、PPP で接続した 場合、正式なホスト名は 'hillarypc.whitehouse.gov' や ' chelseapc.whitehouse.gov'といったホストを 'hillarypc' や 'chelseapc' と言う名でアクセスすることができます。適切なドメイン名や使うネームサー バーの IP ナンバーなどは PPP の接続先に問いあわせてください。
PPP を使う際には、pppd プログラムを適切なオプションをつけて起動します。 知るべきことすべては pppd(8) のマニュアルページにあります。しかし、い くつかの例を見ておくことは有益でしょう。
モデムを経由して PPP サーバーに接続する場合、このようなコマンドを使い ます。
pppd connect 'chat -v "" ATDT5551212 CONNECT "" ogin: ppp word: whitewater' \
/dev/cua1 38400 -detach debug crtscts modem defaultroute 192.1.1.17:
pppd のオプションを順に見てみましょう。
connect 'chat etc...'このコマンドで PPP サーバーと接続を開始します。 ここで使っている 'chat' というプログラムでリモートのコンピュータに電話 をかけます。'connect' コマンドに一つの引数しかあたえられないため、コマ ンド全体をシングルクォート(')で括る必要があります。'chat' 自身のオプショ ンは、
-v 冗長モード： syslog に記録が残されます
"" ： プロンプトを待たずに、、
ATDT 5551212 ： モデムにダイアルコマンドを送り、
CONNECT ： 返事を待って、
"" ： リターンコードを送り(長さ 0 の文字列と
通常のリターンコード)、
ogin: ppp word: whitewater ログインします。
/dev/cua1これはシリアルポートの cua1 を使うことを指示します。
38400これはボーレートの指定。
-detach通常、pppd はフォークして自分自身をバックグラウンドで実行しま すが、このオプションをつけるとそうしなくなります。
debug各種の記録を syslog に残します。
crtsctsコンピュータとモデムの間をハードウェアフローコントロールとしま す (38400 のボーレートではこうしなければいけません)。
modemモデムデバイスを使うことを指示します；このオプションを指定すると、 pppd は電話の前後で回線をハングアップします。
defaultrouteいったん PPP の接続が確立したら、それをデフォルトの経路 (default route)とします；もし PPP を使って Internet に接続したいとすれ ば、こうすることが目的です。
192.1.1.17:これは正式なオプションである x.x.x.x:y.y.y.y を省略した形
です。ここで x.x.x.x はローカルか IP アドレスで
y.y.y.y が PPP 接続のリモート端の IP アドレスになります。
もしこのオプションが指定されないか、(この例のように)片側だけが
指定されたら、x.x.x.x は /etc/hosts にある
ローカルマシンのホスト名の IP アドレスを使用し、y.y.y.y
の部分はリモートのマシンで決定されます。ですから、ここで述べている
架空のマシン、'billpc' の場合、この指定は実際には冗長なものでした。
pppd はエラーメッセージとデバッグ出力を syslogd デーモンに "local2" と
いう名前で出力します(chat を -v オプションで起動した時も同様)。
これらのメッセージはあらかじめコンソールや /usr/adm/messages
といったファイルに出力されるようになっているかも知れません；
どういう設定になっているかは /etc/syslog.conf ファイルを
見てください。もし pppd と chat のメッセージを全てコンソールに出力
したければ、syslog.conf ファイルに
local2.* /dev/console
という行を加えます。"local2.*" と "/dev/console"
の間に 1 つ以上の TAB コードが必要なことに注意してください。
これはもう少し複雑な例です。次に示すのが、Morningstar 製の PPP が動い ている Ultrix マシンに直接接続された Gandalf から PPP 接続するために私 が使っているスクリプトです。
pppd connect /etc/ppp/ppp-connect defaultroute noipdefault debug \
kdebug 2 /dev/cua0 9600
ここで、/etc/ppp/ppp-connect はこんなスクリプトになっています：
#! /bin/sh
/etc/ppp/sendbreak
chat -v -t60 "" \; "service :" blackice ogin: callahan word: PASSWORD \
black% "stty -echo; ppp" "Starting PPP now" && sleep 5
まず break 信号を送り、ターミナルサーバーを起動します。次にセミコロン
を送って(私の使っているターミナルサーバーではセミコロンでボーレートの
自動選択を行います)、"blackice" というサービスを要求します。
ログインして、"black%" というシェルのプロンプトが出るのを待ち、
PPP を起動します。-t60 という引数はタイムアウトまで 1 分間
かける、という意味です。時々、このシステムはきわめて遅くなることがあるので。
"&& sleep5" でスクリプトは 5 秒間停止しますが、
それでも chat が失敗した場合、即座に終了します。
こうして PPP サーバーに起動する時間を与えて
います(とても遅いので)。また、"stty -echo" というオプション
は私にとってきわめて重要な意味をもっています；このオプションをつけないと、
リモートの PPP サーバーがエコーをオフにする以前に、手元の pppd がネゴシエー
ション用のパケットを送ってしまうことがたまにあるからです。リモートの
PPP サーバーがエコーをオフにしていない状態でネゴシエーション・パケット
を送ると、パケットはそのまま手元のマシンに帰ってきてしまい、拒否されて
しまいます(PPP はループバックを検出できます)。そして、リモートの PPP
の準備ができる前に手元の pppd はエラー終了してしまいます。"
stty -echo"
オプションはこれを防ぎます。この種の問題は、遅い Unix マシンを PPP サー
バーにしているごく僅かの人々にしか起らないことでしょうが、原因を究明す
るまでに時間もかかったので、あえてここで言及しておきました。
その他の pppd のオプションはよく似たものです。"noipdefault"
と "kdebug 2" というオプションが新しいものでしょうか。"
noipdefault" オプションを指定すると、pppd は使うべき IP
アドレスをリモート側に問いあわせます；
私の場合のように、PPP サーバーに IP アドレスの動的割り当て機能がある場
合、このオプションが必要となります(すなわち、事前にどのアドレスになる
かはわからない)。"kdebug 2 "というオプションは、カーネルのデバッグレベ
ルを 2 に設定するもので、カーネル内の ppp に関するコードからの出力が多
少詳しくなります。
いずれにせよ、接続がちゃんとできたとすれば、chat がモデムに電話をかけ
させ、 pppd からいくつかのメッセージが出力され(syslog.conf の
設定に応じて)、その後、こんなカーネルからのメッセージが出力されるはずです。
ppp: channel ppp0 mtu changed to 1500
ppp: channel ppp0 open
ppp: channel ppp0 going up for IP packets!
(このメッセージは "kdebug 2" オプションを付け、kern.info メッセージが直接スクリーンに出力されるような設定になって
いる場合にのみ表示されます) 同時に、pppd は関係するメッセージを
/usr/adm/messages (syslong.conf の
設定によっては別のログファイルかも知れません)に出力します。
うまく接続できたようなら、テストする方法はいっぱいあります。
まず第一に、
/sbin/ifconfig
とタイプします(もしかすると、使っているシステムによっては ifconfig
が /sbin 以外の場所にあるかも知れません)。このコマンドは '
UP' の
状態にある全てのネットワークインターフェースを表示します。
ppp0 がその中にある
はずで、最初に示された IP アドレスがあなた自身のもの、"
POINT-TO-POINT ADDR"で示されているのがサーバーのアドレスです。
私のマシンではこんな風になります。
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
次に
ping z.z.z.z
とします。ここで、z.z.z.z は使っているサーバーのアドレスです。
これは大丈夫なはずです。私の場合、こんな風になりました。
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:~$
次に
netstat -nr
とします。こうすれば、こんな風に 3 つの経路が示されるはずです。
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
こういう風になっていても、Destination 欄に
0.0.0.0 という行が見えない
場合(この行が接続時のデフォルトの経路となります)、pppd に '
defaultroute'
オプションをつけていない可能性があります。
ここまで確認できれば、telent/ftp/finger 等、何でも好きなものを使ってみ
てください。しかし、/etc/resolv.conf を正しく設定していない場合、
(ホスト名やドメイン名ではなく)、相手の指定は数字の IP アドレスを使わなけれ
ばならないことに注意してください。
linux サブディレクトリによくある問題についての短い FAQ を用意しました。
もし接続でいないようなら、pppd からの 'debug' 情報をチェック
してください。このためには pppd を 'debug' オプション付きで
起動して、/etc/syslog.conf ファイルに
local2.* /dev/console
local2.* /usr/adm/ppplog
と書いておく必要があります。
こうしておけば、pppd のメッセージが今使っているコンソールと
/usr/adm/ppplog の双方に出力されます。左の欄("local2.*")
と右の欄 ("/dev/console", "/usr/adm/ppplog") の間には一つ
以上の TAB コードが入っていないといけません。/etc/syslog.conf を
修正したら、syslogd のプロセスナンバーを指定して、'kill -HUP <syslogd の pid>' を実行し、現在動い
ている syslogd に設定ファイルを読みこませます。
そうすると、以下のようなメッセージが表示されるはずです。
pppd[NNN]: Connected..." pppd[NNN]: sent [LCP ConfReq"... pppd[NNN]: recv [LCP ConfReq"... pppd[NNN]: ipcp up" もし "recv" メッセージが出ない場合、接続そのものに重大な
問題が生じています(例えば 8 ビット全てを正しく通していないとか)。
その場合、あなたのコンピュータとリモート側の PPP サーバーとの間を通過
した全てのデータをデバッグ・ログファイルに書きだしておくのが解決に
役立ちます。こうするためには、syslog.conf ファイルに
local2.*,kern.* /dev/console
local2.*,kern.* /usr/adm/ppplog
と書き、上と同じように syslog デーモンに HUP シグナルを
送ります。そして、pppd を "kdebug 5" オプションをつけて
起動すれば PPP の接続線上を流れた全てのキャラクターがデバッグ出力
に書きだされます。
時おり、こんなメッセージが出ることもあります。
ppp_toss: tossing frame, reason = 4
このメッセージはシリアル回線のオーバーランのため、PPP コードがリモート
サーバーからのパケット("フレーム")を捨てていることを意味します。このメッ
セージが出る場合、あなたのコンピュータの CPU は能力不足で、シリアルポー
トにキャラクタが届いてから読み出しまでに時間がかかっています；最善の解
決法はシリアルポートに 16550A チップを使うことです。このチップは内部バッ
ファを持っており、CPU に読み出すための時間的余裕を与えます。"
reason =4" 以外の場合は、起るべきではないシリアル回りのエラーが
起きていることを意味しています。
接続の最初の段階では、"bad fcs" というメッセージが何度か出る
かも知れません。これは受けとった PPP フレームのチェックサム・エラーを
意味しています。これが起きるのは、たいてい、接続の開始時にリモート側の
システムが何か "テキスト" メッセージ、例えば "
hello this is the XYZ company" を
送っている場合です。いったん接続が確立し、経路制御も完了した後に "
bad fcs" というメッセージが出るのは正常なことではなく、
伝送時のエラーか電話線のノイズを意味します。
これでもまだ動かなければ、linux-activists の PPP チャンネルにバグレポー トを送ってください。可能な限り多くの情報が入っていることが肝要です。必 要な情報の例として、
syslog.conf ファイルに local2.*,
kern.* を指定して得られた 'debug' 出力Linux の PPP は接続するたびに異なる IP アドレスが割り当てられる PPP サー
バーとも接続することができます。 IP アドレスを割りあててもらうようにリ
モートホストへリクエストを出すには 'noipdefault' オプションを
使います。
Linux のクライアント(例えば "talk" など)を使った場合、"
Cannot assign requested address" というエラーメッセージが出る
ことがあります。これは /etc/hosts に記述してある自分自身の IP
アドレスと PPP インターフェース
に割り当てられた IP アドレスが異なるからです。解決法は、
ifconfig ppp0 として使っているインターフェースのアドレスを
チェックし、/etc/hosts を修正してそれに合わせることです。
他のマシンからあなたのマシンを呼びだし PPP 接続をしたい、というわけで すね。これも Linux PPP では可能です。
まず第一に、あなたの Linux マシンがシリアルラインからの呼出しに正しく 答えて、ログイン・プロンプトを出しているか確認してください。確認するため には、あなたのマシンへ電話をかけて、普通のユーザーとしてログインし、シェ ルプロンプトがちゃんと出て、各種コマンドが正しく使えるかチェックしてく ださい。この文書では Linux マシンを、かかってきた電話に答えるようにセッ トアップする方法については扱いません。それらについては、システムに附属 の文書、あるいは Serial HOWTO ( 日本語訳) を参照してください。
次に、PPP サービスを提供できるようにします。一つの方法は、例えば '
ppp' というアカウント名を作り、ログイン時に起動されるシェルを
pppd を起動するための短いスクリプトにすることです。この方法を取る場合、
/etc/passwd
にこんなエントリを追加することになります。
ppp:(encrypted password):102:50:PPP client login:/tmp:/etc/ppp/ppplogin
起動している /etc/ppp/ppplogin はこんな実行可能な
シェルスクリプトです。
#!/bin/sh
exec /usr/etc/pppd passive :192.1.2.23
[訳注：モデム経由で使うなら modem オプションを付けないと正しく
hang up しないことがあります。]
この設定では、リモートのマシン(接続してくるマシン)の IP アドレスは
192.1.2.23 で、PPP インターフェースを使うローカルの(ホスト側の)
IP アドレスは /etc/hosts に書いてあるマシン名に対応した IP
アドレスになります。'passive' オプションをつけると
(必須ではないのですが)、pppd は起動
時にネゴシエートしようとして、返事が無い場合はそのまま黙って待ち状態に
なります。リモート側のマシンがネゴシエートの準備ができるまでに多少の時
間がかかる場合、このオプションを使うといいでしょう('passive'
オプションは ppp-1.3 と ppp-2.0 の間で変更されていることに注意)
2 台のマシンを接続するだけならこのセットアップで十分ですが、もし Linux PPP を使って外部のマシンをネットワークと接続する場合、あるいは 2 つの ネットワークを接続するような場合には、ネットワークから PPP 接続へパケッ トを送る経路情報を設定しなければなりません。ネットワーク間の接続につい ての設定はこの文書の範囲外です；pppd の経路制御に関するオプションにつ いて、マニュアルページを詳しく読んで、routed などに関する記述を見つけ てください。
ここでは最初の場合のみを考えます。イーサネットに接続された Linux マシ
ンがあって、それに PPP で外部から接続して、イーサネット上のマシンと通
信する、と仮定しましょう。このためには、リモートのマシンにローカルなイー
サネットセグメント上のマシンと同じ IP アドレスを与えて、サーバーとして
使う pppd に 'proxyarp' オプションをつける必要があります。
ここでは、以下のような接続を考えてみます：
192.1.2.23 192.1.2.17
+-----------+ PPP link +----------+
| chelseapc | ------------------- | billpc |
+-----------+ +----------+
| Ethernet
----------------------------------- 192.1.2.x
この場合、billpc の PPP インタフェースとイーサネットインタフェースは同
じ IP アドレス 192.1.2.17 を持っています(一台のマシンで一つ、あるいは
複数の PPP インタフェースがイーサネット・インタフェースと同じ IP アド
レスを持つことは可能です)。billpc の /etc/passwd ファイルには
chelseapc が /etc/ppp/ppplogin スクリプトを起動できるような設定
があります。/etc/ppp/ppplogin スクリプトはこうなっています。
#!/bin/sh
exec /usr/etc/pppd passive proxyarp :192.1.2.23
接続が開始されると、pppd は chelseapc へのエントリを billpc の arp テー
ブルに "proxy arp" として追加します。こうすれば、192.1.2.x の
イーサネット上のマシンに対して、billpc (192.1.2.17) のイーサネット・
インターフェースが chelseapc (192.1.2.23) でもあるかのようにふるまいます。
こうすることで、chelseapc があたかも直接にイーサネットに接続されたマシン
のように通信することが可能になります。
デフォルトでは Linux PPP は 4 つのカーネルチャンネルを使うようになって ます。すなわち、同時に最大 4 つの PPP セッションが可能、ということです。 もし、もっと多くのセッションが必要なら(例えば、多くのダイアル回線にサー ビスを提供する、など)、カーネルのソースコードを修正して、新しくチャン ネルを追加することができます。これには 2 つのステップがあります。
第一に、drivers/net/Space.c のファイルを修正します。
配布されている状態では、このような部分があるはずです。
#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, &ppp3_dev, ppp_init, };
static struct device ppp1_dev = {
"ppp1", 0x0, 0x0, 0x0, 0x0, 1, 0, 0, 0, 0, &ppp2_dev, ppp_init, };
static struct device ppp0_dev = {
"ppp0", 0x0, 0x0, 0x0, 0x0, 0, 0, 0, 0, 0, &ppp1_dev, ppp_init, };
#undef NEXT_DEV
#define NEXT_DEV (&ppp0_dev)
#endif /* PPP */
パターンは明解ですね。チャンネルを追加するには、"
static struct device pppN_dev" 行を追加して、構造体の最初
(ppp[0,1,2]と 11 番目の要素
(&ppp[1,2,3]_dev) を適切に設定します。
PPP デバイスの最後のものの 11 番目の要素が NEXT_DEV になる
ことに注意してください。それ以外のデバイスで
は、&ppp3_dev を &ppp4_dev などに変更します。
例として、2 チャンネル追加してみましょう。
#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, &ppp5_dev, ppp_init, };
static struct device ppp3_dev = {
"ppp3", 0x0, 0x0, 0x0, 0x0, 3, 0, 0, 0, 0, &ppp4_dev, ppp_init, };
... etc.
次に (include/linux ディレクトリにある) ppp.h
ファイルの以下の行を
#define PPP_NRUNIT 4
追加したチャンネル数にあわせて変更します。今回の例では
#define PPP_NRUNIT 6
となります。
これで、カーネルを再コンパイルしリブートします。起動時のメッセージと
/proc/net/dev が変更した数を正しく示していることを
確認してください。
Linux PPP 0.1.x はフリーに配布されている PPP パッケージの PPP-1.3 を元
にしています。一方、Linux PPP 0.2.1 は PPP-2.0.4 を元にしています。両
者の間では pppd のオプションに多少の変更が行なわれ、各種の機能強化がな
されています。変更点についての詳細は pppd ディレクトリにある
"RELNOTES" を参照してください。
また、PPP-1.3 の Linux バージョンに追加されたオプションのいくつかは名 前が変更されています。
それぞれ変更されました。
加えて、ローカルの IP アドレスをリモートの PPP サーバーからもらう場合
には 'noipdefault' オプションが必要になりました。
Good luck!
Michael
----------------------------------------------------------------------- 小島三弘(kojima@komae.denken.or.jp, isle@st.rim.or.jp) 〒 201 東京都 狛江市 岩戸北 2-11-1 (財)電力中央研究所 ヒューマンファクター研究センター Tel:(03)-3480-2111(ex.649), FAX:(03)-3430-5779 -----------------------------------------------------------------------
(sgml conversion, y.senda, ysenda@pop01.odn.ne.jp, 2001/09)