10.1. |
|
まず ppp(8) のマニュアルと、 FreeBSD ハンドブックの「PPP」を読んでみましょう。 次に、 set log Phase Chat Connect Carrier lcp ipcp ccp command
という命令を ppp
のコマンドプロンプトに対して打ち込むか、
設定ファイル
!ppp
*.* /var/log/ppp.log
と書かれた行が含まれているか、また、
訳注:ログの取得に syslog を使用するようになったのは 2.2.5 以降からです。
使用中の | |
10.2. |
|
ホスト名の解決がうまくいっていないのでしょう。まず、
リゾルバ (resolver) が
127.0.0.1 foo.bar.com foo localhost 使用しているホストのエントリを追加してもかまいません。 詳細は関連するマンページを参照してください。 | |
10.3. |
|
まず最初に、デフォルトルートが確立しているかどうかチェックしてください。
Destination Gateway Flags Refs Use Netif Expire
default 10.0.0.2 UGSc 0 0 tun0
10.0.0.2 10.0.0.1 UH 0 0 tun0
これはあなたがハンドブックやマニュアル、
add 0 0 HISADDR と書かれた行を以下のように修正してください。 add 0 0 10.0.0.2
delete ALL の行をうっかり消してしまった可能性があります。 この場合は、 FreeBSD ハンドブックの「システムの最終設定」の項を読み直してください。 | |
10.4. | 「 |
このエラーは通常、
MYADDR:
delete ALL
add 0 0 HISADDR これは動的 IP アドレスを使用している場合、 またはゲートウェイのアドレスを知らない場合にのみ必要な設定です。 インタラクティブモードを使用している場合、 パケットモードに入った後で (プロンプトが PPP と大文字に変わったらパケットモードに入ったしるしです)、 以下の命令を入力してください。 delete ALL
add 0 0 HISADDR 詳しい情報については、 FreeBSD ハンドブックの「PPP と動的 IP 設定」の項を参照してください。 | |
10.5. | 3 分ほど経つと接続が切れてしまう |
set timeout NNN
という命令によって調整することができます。
訳注:
詳しい情報は ppp(8) のマニュアルページを参照してください。 | |
10.6. | 負荷が高いと接続が切れてしまう |
Link Quality Reporting (LQR) の設定を行っている場合、
マシンと接続先の間で非常にたくさんの LQR
パケットが失われている可能性があります。結果として
disable lqr | |
10.7. | 接続がランダムに切れてしまう |
ノイズの多い回線、あるいは待ち機能付きの回線では、 時々モデムが (誤って) キャリアを失ったと思い込み、 回線が切断されてしまうことがあります。 大多数のモデムでは、 一時的なキャリアの喪失をどれくらいの時間で検出するかを、 設定で決めることができます。 たとえば USR Sportster では、S10 レジスタ の値を 10 倍した秒数がその値になります。 この場合、モデムをもっとのんびり屋さんにするには、 dial 行に次のような文字列を加えると良いでしょう。 set dial "...... ATS10=10 OK ......" 詳しくはお使いのモデムのマニュアルをご覧ください。 | |
10.8. | 接続が不規則にハングアップしてしまう |
たくさんの人が、原因不明のハングアップを経験しています。 検証のために必要なのは、まずどちら側のリンクでそれが起こっているか、 ということです。
外部接続型モデムを利用しているなら、
単に 問題が回線のどちら側かにあることが分かったら、 つぎの二つの可能性が考えられるでしょう。 | |
10.9. | 回線の向こう側での反応がない |
これに対処できることはほとんどありません。大部分の ISP
は、Microsoft 社製 OS 以外の利用者に対してのサポートを拒否するでしょう。
まず最初に、こちら側の圧縮機能をすべて無効にしてみてください。 それには、設定ファイルをつぎのようにします。 disable pred1 deflate deflate24 protocomp acfcomp shortseq vj
deny pred1 deflate deflate24 protocomp acfcomp shortseq vj そして再接続し、変更前と同じように通信できることを確認します。 もしこれによって状況が改善されるか、完全に解決したら、 (上の設定のうち) どの設定で状況が変化したのかを、 色々な組合せで試してみてください。これは、ISP に問い合わせを行なうときの有効な情報となります (ただし、 あなたが Microsoft 社製品以外のものを利用していることも明らかにしてしまいますが)。
ISP に問い合わせを行なう前に、こちら側の非同期ログを有効にして、
接続がハングアップするまで待ってください。この作業は、
非常に多くのディスク空間を消費するかも知れません。
興味の対象となっているのは、通信ポートから最後に読み込まれたデータです。
それは通常 ASCII データで、
問題点の詳細 (「
回線の向こう側で通信ログを監視することは可能なはずですので、
切断が発生した時、ISP の対応が好意的ならば
どうして ISP 側で問題が発生したのかこちらに伝えてくれるかも知れません。
| |
10.10. |
|
ベストな方法は、
スタックトレースの結果は、 | |
10.11. |
|
2.2.5 より前のリリースの FreeBSD では、 ppp(8) はリンクが確立した後、接続先が Line Control Protocol (LCP) を発信するのを待ちます。しかし、多くの ISP ではネゴシエーションを自分からは起こさず、 クライアントが起こすのを待っています。 ppp に強制的に LCP を発信させるには、 次の命令を使います。 set openmode active 注記:両方の側がネゴジェーションを起こしても、 大抵の場合は何の問題もありません。 ですから、現在では openmode はデフォルトで有効になっています。 次のセクションでこれが問題になる場合を説明します。 | |
10.12. | でもまだ 「 |
時折、接続直後のログに
「
これは通常、
ディスクアクセスの遅いサーバマシンのシリアルポートで
LCP
ネゴシエーションの一部として、
リンクの両サイドで
magic number を定めて、
「反射」が起きていないかどうか確かめる作業があります。
規約では、接続相手がこちらと同じ magic number を提示してきたら、
NAK を送って新しい
magic number を選択しなければならないと定めています。
この作業の間、サーバのシリアルポートの
この事態は、以下の行を
set openmode passive
これで set openmode active 3
これによって | |
10.13. | 接続が切れるまで LCP のネゴシエーションが続くのですが。 |
現在の ppp は、まだ LCP や CCP、 IPCP の返事が、 元のリクエストと連携してくれる機能がきちんと実装されていません。 その結果、ある ppp の実装が相手よりも 6 秒以上遅い場合には、 LCP 設定のリクエストをさらに 2 回送ります。 これは致命的な物です。
これが、片方の
これを回避する最も良い方法は、
片方を
set openmode passive というコマンドでできます。 このオプションは気を付けて使わないといけません。さらに set stopped N というコマンドを追加して、 ppp がネゴシエーションが開始するまで待つ 最大の時間を設定してください。もしくは、 set openmode active N
というコマンド (ここで、
| |
10.14. | ppp が接続直後に固まってしまう |
2.2.5 より前のバージョンの FreeBSD では、ppp が Predictor1 圧縮のネゴシエーションを誤って解釈して、 接続直後にリンクを無効にしている可能性があります。 これは両サイドが異なる Compression Control Protocols (CCP) を使ってネゴジェーションを行った場合にのみ発生します。 この問題は現在は解決していますが、あなたの走らせている ppp のバージョンが古い場合でも、次の命令で解決することができます。 disable pred1 | |
10.15. |
|
このような場合は、代わりに
| |
10.16. | ヌルモデムケーブルを使用しているとき、
|
ヌルモデムケーブルを使用して直接接続している場合、 ppp は自動的には接続の終了を知ることができません。 これはヌルモデムシリアルケーブルの配線に起因しています。 この種の接続形態を用いる場合は、 以下の命令を用いて LQR を常に有効にする必要があります。 enable lqr こうすると、接続先がネゴシエーションを行う場合、デフォルトで LQR の使用を受け入れるようになります。 | |
10.17. |
|
ppp が思いもしないときにダイアルを始める場合、その原因を突き止め、 防止のためにダイヤルフィルタ (dfilters) をかけてやる 必要があります。 原因を突き止めるためには、以下の命令を使用してください。 set log +tcp/ip これで接続を通過するすべてのトラフィックをログに残すことができるようになりました。 次に突然回線がつながったときのログのタイムスタンプをたどれば、 原因を突き止めることができるはずです。 原因がわかったら、次に、このような状況ではダイヤルが起こらないようにしましょう。 通常、この手の問題は、DNS で名前の解決をしようとしたために起こります。 DNS による名前の解決によって、 接続が行われるのを防止するには、 次のような手段を用います (これは ppp の既に確立した接続に関してパケットのフィルタリングをするものではありません)。 set dfilter 1 deny udp src eq 53
set dfilter 2 deny udp dst eq 53
set dfilter 3 permit 0/0 0/0 これはデマンドダイヤル機能に問題を生じさせるため、 常に適切であるとはかぎりません。 ほとんどのプログラムは他のネットワーク関連の処理を行なう前に DNS への問い合わせが必要になります。
DNS の場合は、
何が実際にホスト名を検索しようとしているのかを突き止めるべきでしょう。
大抵の場合は、
sendmail(8)
が犯人です。
設定ファイルで sendmail が
DNS に問い合わせないようになっているか確認すべきです。
自分用の設定ファイルを作成するための詳しい方法は、
メールの設定 の項をご覧ください。
または、
define(`confDELIVERY_MODE', `d')dnl
この行を追加すると、sendmail
はメールキューを処理する (通常
sendmail は 30 分ごとにキューを処理するよう、
「 訳注:
「 | |
10.18. | CCP エラーとはどういう意味ですか |
ログファイル中の以下のエラーは、 CCP: CcpSendConfigReq
CCP: Received Terminate Ack (1) state = Req-Sent (6)
のネゴシエーションにおいて disable pred1 | |
10.19. | ファイル転送の途中で、 |
FreeBSD 2.2.2 以前のバージョンの
FreeBSD 2.2.2 以前のバージョンでは、MTU を決して 1500 より小さくしないことで、 この問題を回避することができます。 | |
10.20. | どうして |
モデムとの「やり取り」すべての行をログに残すには、 以下のようにして接続速度のログの有効化を行ってください。 set log +connect これは
ppp(8)
に最後にくることが要求されている
「
接続速度はログにとりたいけれど、PAP
や CHAP
を使っている (その結果、ダイヤルスクリプト中の
set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n"
ここで、 | |
10.21. | 私の |
モデムにたとえば 「 set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK" 実際にモデムに送られる文字列は次のようになります。 ATZ
OK
AT\X
OK 他の例ですと set phone 1234567
set dial "\"\" ATZ OK ATDT\\T" は次のようになります。 ATZ
OK
ATDT1234567 | |
10.22. |
|
ppp (や他のプログラム) は決して core を吐いてはいけません。 ppp は実効 uid が 0 で動いていますので、 オペレーティングシステムは ppp を終了させる前にディスクに core イメージを書き込みません。 しかし ppp は実際にはセグメンテーション違反や、 他の core を吐く原因となるようなシグナルによって終了しており、 さらに最新のバージョン (このセクションの始めを見てください) を使用しているならば、次のようにしてください。 % tar xfz ppp-*.src.tar.gz
% cd ppp*/ppp
% echo STRIP= >>Makefile
% echo CFLAGS+=-g >>Makefile
% make clean all
% su
# make install
# chmod 555 /usr/sbin/ppp
これでデバッグ可能なバージョンの
ppp がインストールされます。
これで、ppp
がセグメンテーション例外を受け取ったときには
% su
# gdb /usr/sbin/ppp ppp.core
(gdb) bt
.....
(gdb) f 0
....
(gdb) i args
....
(gdb) l
.....質問する際には、これらすべての情報を提供して、 問題点の分析ができるようにしてください。
| |
10.23. | auto モードでダイアルをするようなプロセスが接続されない。 |
これは ppp
がローカル側の IP アドレスを、
動的に通信相手と交渉するように設定されている時に発生する良く知られた障害でした。
最新のバージョンでは、
この問題は修正されています。
これは、最初のプログラムが
connect(2)
を呼び出した時、
この問題に対処する理論的な方法がいくつかあります。もし可能なら、
相手が再度、同じ IP
アドレスを割り当ててくれることが一番です
我々の側から対処できる最も簡単な方法は、 もう 1 つの (おそらく最も信頼できる) 方法は、bind された すべてのソケットの IP アドレスを、 異なるものに変更できるシステムコールを実装することです。 pppは、 新しい IP アドレスが割り当てられた時、 このシステムコールを用いて実行されているプログラムにある、 すべてのソケットを書きかえてやるわけです。 同じシステムコールが、DHCP クライアントが利用するソケットを 強制的に再 bind するのにも使うことができるでしょう。
3 つ目の方法は、IP
アドレスを指定しないでインターフェイスを利用できるようにすることです。
外に出ていくパケットは、最初の | |
10.24. | 何故ほとんどのゲームが
|
libalias を使っている時にゲームなどの類のものが動作しない理由は、 外側にあるマシンが接続しようとしているか、内側にあるマシンに (余計な) UDP パケットを送信しようとしているからです。 内側のマシンにこれらのパケットを送るべきかについて、 NAT ソフトウェアは関知しません。
うまく動かすためには、
実行中のものが問題の発生しているソフトウェアだけであるかを確認し、
ゲートウェイの
行儀の悪いソフトウェアを起動する際に、
ゲートウェイマシンを通過するパケットを監視すべきです。
外側から何かパケットが戻ってきた時に、
そのパケットは破棄されるでしょう (それが問題なのです)。
これらのパケットのポート番号に注意して、
その行儀の悪いソフトウェアを停止してください。
これを数回繰り返してポート番号が常に同じであるかを確認してみてください。
同じであった場合は、
nat port proto internalmachine :port port
ここで 上記のコマンドを変更せずに、 他のマシン上でそのソフトウェアを使用できるようにはしたくないかもしれません。 そして同時に二つの内部のマシン上でそのソフトウェアを実行することは、 この質問の範囲を超えています。結局、外側の世界からは、 内部ネットワーク全体がただ一つのマシンとして見えるのです。 ポート番号が常に同じとは限らない場合、さらに三つのオプションがあります。
| |
10.25. | 有用なポート番号のリストはありませんか? |
まだ出来ていません。しかし、
これは (関心を持って頂けるならば) そういったリストにしていく予定です。
それぞれの例にある
| |
10.26. | FCS エラーって何? |
FCS とは
リンクの品質が悪かったり、 シリアルドライバがパケットを取りこぼしていたりすると、 FCS エラーがたびたび発生します。 FCS エラーは、 圧縮プロトコルの速度低下の原因にはなりますが、 特に心配する必要はありません。 外付けモデムを使っている場合は、 ケーブルがちゃんとシールドされているかを確認してください。 そうでない場合、 FCS エラーの原因となる場合があります。
接続直後からリンクがフリーズし、大量の
FCS エラーが発生する場合は、
リンクが 8 ビットクリーンでない可能性があります。
ソフトウェアフロー制御 (XON/XOFF)
が使われていないことを確認してください。
どうしてもソフトウェアフロー制御を使わなければならない場合は、
リモートホストが PPP プロトコルを使用してない場合も、大量の FCS エラーが発生します。 この場合はログをとりながら非同期で接続し、 ログインプロンプトやシェルプロンプトが送られて来ていないか確認してください。 ログファイルにリンクを終了した原因となるような記録がない場合は、 リモートホスト (プロバイダ?) の管理者に、 セッションを終了された理由を尋ねてください。 | |
10.27. | ゲートウェイで PPPoE を実行すると MacOS や Windows 98 との接続がフリーズしてしまうのですが、 これはなぜなのでしょうか? |
Michael Wozniak これは、いわゆる「ブラックホールルータ (Black Hole router)」に原因があります。 Windows 98 と MacOS (および、おそらく他の Microsoft 社製 OS) の TCP パケット送出は、 PPPoE のフレーム (Ethernet の MTU は標準で 1500) に入らないような大きなセグメントサイズを要求します。 そしてさらに分割禁止 (「don't fragment」) フラグビットを (TCP パケットにデフォルトで) セットするのですが、 Telco のルータは、分割が必須 ("must fragment") であることを示す ICMP メッセージを、接続しようとするウェブサイトに対して送出しません (つまり、ルータは正しく ICMP パケットを送出しているのですが、 ウェブサイトのファイアウォールがそれを落としているのです)。 そのためウェブサーバが PPPoE 接続に対して大きすぎるフレームを送出すると Telco のルータはそのフレームを捨ててしまい、 見ようとしたページが表示されないという症状が現われます (MSS より小さいページや画像は表示されます)。 ほとんどの Telco PPPoE 設定は、標準でこのように設定されているようです。 (ああ、彼らがルーティングプログラムの作り方を理解してさえいれば…)。 一つの解決法は、Windows 95/98 マシンで regedit を使い、 次のレジストリエントリを追加することです。 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\0000\MaxMTU
レジストリエントリは、「1450」 の値
(もっと正確に言うと、TCP パケットを PPPoE フレームに完全に適合させるには
「1464」 であるべきでですが、
「1450」 とすると、現われる可能性がある他の IP
プロトコルに対してエラーマージンを確保することができます)
にする必要があります。
このレジストリキーは、Windows2000 で
FreeBSD/NAT/PPPoE ルータと共存させるために Windoze の MTU を変更する方法に関する詳細は、 Microsoft Knowledge Base にある、 番号 「Q158474 - Windows TCPIP Registry Entries」、 および番号 「Q120642 - TCPIP & NBT Configuration Parameters for Windows NT」 を参照してください。 残念なことに、MacOS には
TCP/IP 設定を変更する方法がありません。
しかし、Sustainable Softworks 社
が販売している OTAdvancedTuner (OT は OpenTransport という
MacOS の TCP/IP スタックの名前のこと) のような商用ソフトウェアが存在します。
このソフトウェアは、ユーザから TCP/IP 設定の変更を行なうことを可能にします。
MacOS NAT ユーザはドロップダウンメニューから
ppp の最新版
(2.3 かそれ以降) には、自動的に MSS を適切な値に調節する
| |
10.28. | どれにも当てはまらない! どうしたらいいの? |
これまでのすべての質問に当てはまらない場合、設定ファイル、
ppp
の実行方法、ログファイルの該当部分と
|
本文書、および他の文書は ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/ からダウンロードできます。
FreeBSD に関する質問がある場合には、
ドキュメント を読んだ上で
<questions@FreeBSD.org> まで (英語で) 連絡してください。
本文書に関する質問については、
<doc@FreeBSD.org> まで電子メールを (英語で) 送ってください。