さて、/etc/ppp/options と/etc/resolv.conf ファイルを
作成しました(必要ならば /etc/ppp/pap|chap-secretsファイルも)。
これで PPP 接続がうまくいくかどうか手動で試してみましょう(手動でうまく
いくことが確認できてから自動的に接続する方法を説明します)
手動接続のためには、モデムをリセットせずに終了できる通信ソフトが必要で す。Minicom ならば ALT Q で可能です(古いバージョンの minicom ならば CTRL A Q です)
ルートとしてログインしていることを確認してください。
minicom のような通信ソフトを起動し、普通に PPP サーバに接続します。PPP 接続のために何かコマンドが必要ならば、そのコマンドを実行してください。 以前にチェックしたような
~y}#.!}!}!} }8}!}$}%U}"}&} } } } }%}& ...}'}"}(}"} .~~y}
pap/chap を使っている場合、サーバマシンに接続するだけで自動的に ppp が 起動され、ログインしなくても上記のようなデータが送られてきます(サーバ の設定によってはそうならない場合もあります)
ここでモデムをリセットせずに通信ソフトを終了させ(minicom では ALT Q か CTRL A Q を入力します)、Linux の(ルートの)プロンプトを出し、
pppd -d -detach /dev/cuaX &
と入力します。
-d オプションはデバッグ出力の指定で、このオプションを使えば ppp 接続が 始まるとともに「会話」内容がシステムのログファイルに記録されます。トラ ブルの際にはこのファイルを調べましょう。
実際に入力すべきは cuaX ではなく、通常、
cua0 か cua1 といった実際にモデムが接続されているポー
ト番号を指定することをお忘れなく。
PPP 接続が確立すればモデムのライトが点滅するはずです。PPP 接続を確立す るには多少の時間がかかります。
ここで
ifconfig
コマンドを使って PPP インターフェイスの状態を調べます。
イーサネットやループバックデバイス以外に、このような ppp デバイスの表 示が見られるはずです。
ppp0 Link encap:Point-Point Protocol
inet addr:10.144.153.104 P-t-P:10.144.153.51 Mask:255.255.255.0
UP POINTOPOINT RUNNING MTU:552 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0
TX packets:0 errors:0 dropped:0 overruns:0
ここで、
(ifconfig はあなたの PPP サーバで使っている IP 番号以外は報告しないかも 知れません)
注意：ifconfig は接続が UP で RUNNING 状態になっていることも示しています。
もし、このように表示された場合、
ppp0 Link encap:Point-Point Protocol
inet addr:0.0.0.0 P-t-P:0.0.0.0 Mask:0.0.0.0
POINTOPOINT MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0
TX packets:0 errors:0 dropped:0 overruns:0
PPP 接続がうまく確立されていません。後述するデバッグについての章を御覧 ください。
同時に、リモートホスト(とその先)への経路が確立しているかチェックしましょ う。そのためには、
route -n
コマンドを使います。すると、以下のような出力が見られるはずです。
Kernel routing table Destination Gateway Genmask Flags MSS Window Use Iface 10.144.153.3 * 255.255.255.255 UH 1500 0 1 ppp0 127.0.0.0 * 255.0.0.0 U 3584 0 11 lo 10.0.0.0 * 255.0.0.0 U 1500 0 35 eth0 default 10.144.153.3 * UG 1500 0 5 ppp0
ここで ppp インターフェイスに2 つのエントリができていることに 特に注意してください。
最初のものはホストへの経路(H フラグが示しています)で、接続先の IP アドレ スを示しています。しかし、そこから先への経路はありません。
2 つめのものがデフォルトの経路(default route)で、Linux PC は
この経路にローカルのイーサネット宛てではない全てのパケットを
送りつけます。このデフォルトの経路がネットワークへの経路として PPP サー
バ自身を指しています。PPP サーバは我々のパケットをインターネットへ送り
だし、返答パケットを我々のもとへ送ってこなければなりません。
ルーティングテーブルに 2 つのエントリが見つからない場合、何か間違って います(デバッグについての章を見てください)
次に 'ping' を使って接続をテストします。このためには、ifconfig が表示 した接続先の IP 番号を指定して、
ping 10.144.153.51
とします。すると、このような出力が見られるはずです。
PING 10.144.153.51 (10.144.153.51): 56 data bytes
64 bytes from 10.144.153.51: icmp_seq=0 ttl=255 time=328.3 ms
64 bytes from 10.144.153.51: icmp_seq=1 ttl=255 time=190.5 ms
64 bytes from 10.144.153.51: icmp_seq=2 ttl=255 time=187.5 ms
64 bytes from 10.144.153.51: icmp_seq=3 ttl=255 time=170.7 ms
この表示はいつまでも続くので、適当なところで CTRL C を押して終了させま しょう。すると、
--- 10.144.153.51 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 170.7/219.2/328.3 ms
といった表示がされるはずです。
次に、ホスト名で ping のテストをしてみましょう。指定するホスト名は PPP サーバではなく、別のサイトにあるホストで、動いていることが確実なホスト を選びます。例えば、
ping sunsite.unc.edu
とします。
今回は、指定したホスト名を /etc/resolv.conf で指定した DNS へ
尋ねて IP 番号へ変換しているために多少時間がかかりますがご心配なく(で
もその間もモデムのライトは点滅しているはずです)。少ししてから、以下の
ような出力が表示されるはずです。
PING sunsite.unc.edu (152.2.254.81): 56 data bytes
64 bytes from 152.2.254.81: icmp_seq=0 ttl=254 time=190.1 ms
64 bytes from 152.2.254.81: icmp_seq=1 ttl=254 time=180.6 ms
64 bytes from 152.2.254.81: icmp_seq=2 ttl=254 time=169.8 ms
64 bytes from 152.2.254.81: icmp_seq=3 ttl=254 time=170.6 ms
64 bytes from 152.2.254.81: icmp_seq=4 ttl=254 time=170.6 ms
これも適当なところで CTRL C を押して停止させ、統計情報を見ましょう。
--- sunsite.unc.edu ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 169.8/176.3/190.1 ms
反応が帰ってこなければこの文書のデバッグに関する章を読んでくだ さい。
すべてがうまく行けば、
ppp-off
コマンドで接続を終了させます。
しばらくの後にモデムもハングアップするはずです。
うまくハングアップしない場合、モデムの電源を切るか通信ソフトを立ちあげ て +++ を入力してモデムのコマンドモードに入り、ATH0 コマンドで接続を切 り、モデムから OK プロンプトが帰ることを確認してください。
pppd が作ったロックファイルも消しておきましょう。
rm -f /var/lock/LCK..cuaX