次のページ
前のページ
目次へ
$Id: PPP.README.linux.sgml,v 1.1.1.1 1999/02/22 19:20:57 baba Exp $
$Log: PPP.README.linux.sgml,v $
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 との違い
・結論
・イントロダクション
これは 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-activists の PPP チャンネルへの招待：
これはイントールには直接関係ありませんが、もし 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 のカーネルドライバを組みこむことは簡単です：
1) このパッケージに含まれている ppp.c を drivers/net にコピーし、ppp.h
は include/linux にコピーします。
2) config.in の CONFIG_PPP の行のコメントを外します。
3) もし 1.1.3 以前(1.0.x も含めて)のカーネルを使っているなら：
ppp.c の /* #define NET02D で始まる行の "/*" を削除して、コメントアウ
トを外します。
4) カーネルソースのトップディレクトリ(たいていは /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 で使いたい場合、下の "ADDING MORE PPP
CHANNELS" を参照してください。
次に、/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 を再コンパイルしたいなら、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 サーバーとの接続
PPP を使う際には、pppd プログラムを適切なオプションをつけて起動します。
知るべきことすべては pppd(8) のマニュアルページにあります。しかし、い
くつかの例を見ておくことは有益でしょう。
例 1：簡単なダイアルアップ接続
モデムを経由して 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
コードが必要なことに注意してください。
例 2：専用線を使って PPP サーバーに接続する場合
これはもう少し複雑な例です。次に示すのが、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..." "connect" スクリプトが正しく終了しました。
- "pppd[NNN]: sent [LCP ConfReq"... pppd はリモート側とネゴシエーショ
ンを開始しました。
- "pppd[NNN]: recv [LCP ConfReq"... pppd はリモート側からネゴシエー
ション用のフレームを受信しました。
- "pppd[NNN]: ipcp up" IP トラフィックを通すための接続が確立したと
pppd は解釈しました
もし "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 チャンネルにバグレポー
トを送ってください。可能な限り多くの情報が入っていることが肝要です。必
要な情報の例として、
- 使っているカーネルのバージョン
- 使っている Linux PPP のバージョン
- PPP セッションを開始するのに使っているコマンド
- syslog.conf ファイルに local2.*, kern.* を指定して得られた 'debug' 出力
- 接続先の PPP の種類(例えば Xyzzy Corp のターミナルサーバー、モーニ
ングスター製の PPP ソフト、などなど)
- 接続形態(モデム、専用線、などなど)
・動的アドレス割り当て
Linux の PPP は接続するたびに異なる IP アドレスが割り当てられる PPP サー
バーとも接続することができます。 IP アドレスを割りあててもらうようにリ
モートホストへリクエストを出すには 'noipdefault' オプションを使います。
Linux のクライアント(例えば "talk" など)を使った場合、"Cannot assign
requested address" というエラーメッセージが出ることがあります。これは
/etc/hosts に記述してある自分自身の IP アドレスと PPP インターフェース
に割り当てられた IP アドレスが異なるからです。解決法は、ifconfig ppp0
として使っているインターフェースのアドレスをチェックし、/etc/hosts を
修正してそれに合わせることです。
・PPP 接続を受ける側のセットアップ
他のマシンからあなたのマシンを呼びだし 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 があたかも直接にイーサネットに接続されたマシンのように通
信することが可能になります。
・PPP チャンネルを増したい
デフォルトでは 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 からの変更点
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 バージョンに追加されたオプションのいくつかは名
前が変更されています。
'defroute' は 'defaultroute' に
'kerndebug' は 'kdebug' に
'dropdtr' は 'modem' に、それぞれ変更されました。
加えて、ローカルの 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
-----------------------------------------------------------------------
次のページ
前のページ
目次へ