この章では、Solaris PPP 4.0 で発生する一般的な問題の障害追跡に関する情報を提供します。次の項目について説明します。
James Carlson による「PPP Design, Implementation, and Debugging」やオーストラリア国立大学の Web サイトなどの情報源も、PPP の障害追跡に詳細なアドバイスを提供しています。詳細は、PPP に関する専門技術者向けのリファレンスブックおよび PPP に関する Web サイトを参照してください。
次の作業マップを使用すれば、一般的な PPP の問題のためのアドバイスや解決方法をすばやく探すことができます。
表 31–1 PPP の障害追跡 (作業マップ)
作業 |
定義 |
参照先 |
---|---|---|
PPP リンクに関する診断情報を取得する |
PPP 診断ツールを使って障害追跡の出力を取得する | |
PPP リンクのデバッグ情報を取得する |
pppd debug コマンドを使って障害追跡の出力を生成する | |
ネットワークレイヤーでの一般的な問題を障害追跡する |
一連の確認作業を行いネットワーク関連の PPP 問題を特定し解決する | |
一般的な通信の問題を障害追跡する |
PPP リンクに影響を与える通信の問題を特定し解決する | |
構成の問題を障害追跡する |
PPP 構成ファイルで問題を特定し解決する | |
モデム関連の問題を障害追跡する |
モデムの問題を特定し解決する | |
chat スクリプト関連の問題を障害追跡する |
ダイアルアウトマシン上の chat スクリプトの問題を特定し解決する | |
シリアル回線の速度の問題を障害追跡する |
ダイアルインサーバー上で回線速度の問題を特定し解決する | |
専用回線の一般的な問題を障害追跡する |
専用回線の問題を特定し解決する | |
認証に関連する問題を障害追跡する |
認証データベースに関連する問題を特定し解決する | |
PPPoE の問題領域を障害追跡する |
PPP 診断ツールを使用して、PPPoE の問題を特定し解決するための出力を得る |
PPP リンクは、一般に次の 3 つの主要な領域で障害が発生します。
接続の確立に失敗する
通常の使用の中で接続パフォーマンスが低下する
接続のどちらかの側でネットワークに原因と考えられる問題が発生する
この節では、pppd および関連するログファイルから診断情報を取得する方法について説明します。この章の残りの節では、PPP 障害追跡ツールを使って発見し解決できる PPP に関する一般的な問題を説明します。
次に、ローカルマシン上の接続の現在の動作を表示する手順を説明します。
ローカルマシン上でスーパーユーザーになります。
PPP に設定されているシリアルデバイスを引数として pppd を実行します。
# pppd /dev/ttyname debug updetach |
# pppd /dev/cua/b debug updetach have route to 0.0.0.0/0.0.0.0 via 172.21.0.4 serial speed set to 230400 bps Using interface sppp0 Connect: sppp0 <--> /dev/cua/b sent [LCP ConfReq id=0x7b <asyncmap 0x0> <magic 0x73e981c8> <pcomp> <accomp>] rcvd [LCP Ident id=0x79 magic=0x0 "ppp-2.4.0b1 (Sun Microsystems, Inc., Dec 6 2000 09:36:22)"] Peer Identification: ppp-2.4.0b1 (Sun Microsystems, Inc., Dec 6 2000 09:36:22) rcvd [LCP ConfRej id=0x7b <asyncmap 0x0>] sent [LCP Ident id=0x7c magic=0x0 "ppp-2.4.0b1 (Sun Microsystems, Inc., Nov 15 2000 09:38:33)" sent [LCP ConfReq id=0x7d <magic 0x73e981c8> <pcomp> <accomp>] rcvd [LCP ConfAck id=0x7d <magic 0x73e981c8> <pcomp> <accomp>] rcvd [LCP ConfAck id=0x78 <magic 0xdd4ad820> <pcomp> <accomp>] sent [LCP ConfAck id=0x78 <magic 0xdd4ad820> <pcomp> <accomp>] sent [LCP Ident id=0x7e magic=0x73e981c8 "ppp-2.4.0b1 (Sun Microsystems, Inc., Nov 15 2000 09:38:33)"] sent [IPCP ConfReq id=0x3d <addr 0.0.0.0> <compress VJ 0f 01>] rcvd [LCP Ident id=0x7a magic=0xdd4ad820 "ppp-2.4.0b1 (Sun Microsystems, Inc., Dec 6 2000 09:36:22)"] Peer Identification: ppp-2.4.0b1 (Sun Microsystems, Inc., Dec 6 2000 09:36:22) rcvd [IPCP ConfReq id=0x92 <addr 10.0.0.1> <compress VJ 0f 01> sent [IPCP ConfAck id=0x92 <addr 10.0.0.1> <compress VJ 0f 01> rcvd [IPCP ConfNak id=0x3d <addr 10.0.0.2>]] sent [IPCP ConfReq id=0x3e <addr 10.0.0.2> <compress VJ 0f 01>] rcvd [IPCP ConfAck id=0x3e <addr 10.0.0.2> <compress VJ 0f 01>] local IP address 10.0.0.2 remote IP address 10.0.0.1 |
# pppd /dev/se_hdlc1 default-asyncmap debug updetach pppd 2.4.0b1 (Sun Microsystems, Inc., Oct 24 2001 07:13:18) started by root, uid 0 synchronous speed appears to be 0 bps init option: '/etc/ppp/peers/syncinit.sh' started (pid 105122) Serial port initialized. synchronous speed appears to be 64000 bps Using interface sppp0 Connect: sppp0 <--> /dev/se_hdlc1 sent [LCP ConfReq id=0xe9 <magic 0x474283c6><pcomp> <accomp>] rcvd [LCP ConfAck id=0xe9 <magic 0x474283c6><pcomp> <accomp>] rcvd [LCP ConfReq id=0x22 <magic 0x8e3a53ff><pcomp> <accomp>] sent [LCP ConfReq id=0x22 <magic 0x8e3a53ff><pcomp> <accomp>] sent [LCP Ident id=0xea magic=0x474283c6 "ppp-2.4.0b1 (Sun Microsystems, Inc., Oct 22 2001 14:31:44)"] sent [IPCP ConfReq id=0xf7 <addr 0.0.0.0> <compress VJ Of o1>]] sent [CCP ConfReq id=0x3f <deflate 15> <deflate(old#) 15> <bsd v1 15>] rcvd [LCP Ident id=0x23 magic=0x8e3a53ff "ppp-2.4.0b1 (Sun Microsystems, Inc., Oct 22 2001 14:31:44)"] Peer Identification: ppp-2.4.0b1 (Sun Microsystems, Inc., Oct 22 2001 14:31:44) rcvd [IPCP ConfReq id=0x25 <addr 10.0.0.1> <compress VJ Of 01>] sent [IPCP ConfAck id=0x25 <addr 10.0.0.1> <compress VJ Of 01>] rcvd [CCP ConfReq id=0x3 <deflate 15> <deflate(old#) 15 <bsd v1 15>] sent [CCP ConfAck id=0x3 <deflate 15> <deflate(old#) 15 <bsd v1 15>] rcvd [IPCP ConfNak id=0xf8 <addr 10.0.0.2>] rcvd [IPCP ConfReq id=0xf7 <addr 10.0.0.2> <compress VJ Of 01>] rcvd [CCP ConfAck id=0x3f <deflate 15> <deflate(old#) 15 <bsd v1 15>] Deflate (15) compression enabled rcvd [IPCP ConfAck id=0xf8 <addr 10.0.0.2> <compress VJ Of 01>] local IP address 10.0.0.2 remote IP address 10.0.0.1 |
次に、pppd コマンドを使ってデバッグ情報を取得する方法を示します。
手順 1 から手順 3 までは各ホストごとに 1 度実行するだけでかまいません。その後、手順 4 に進んでホストのデバッグをオンに設定できます。
pppd からの出力を保持するためのログファイルを作成します。
% touch /var/log/pppdebug |
次の pppd 用の syslog 機能を /etc/syslog.conf に追加します。
daemon.debug;local2.debug /var/log/pppdebug |
syslogd を再起動します。
% pkill -HUP -x syslogd |
pppd の次の構文を使用して、特定のピアに対する呼び出しのデバッグをオンに設定します。
% pppd debug call peer-name |
peer-name は、/etc/ppp/peers ディレクトリにあるファイル名でなければなりません。
ログファイルの内容を表示します。
% tail -f /var/log/pppdebug |
ログファイルの例については、例 31–3 を参照してください。
PPP リンクがアクティブになっているのに、リモートネットワーク上のホストにほとんど接続できない場合、ネットワークに問題のある可能性があります。この節では、PPP リンクに影響を与えるネットワークの問題を特定し解決する方法について説明します。
ローカルマシン上でスーパーユーザーになり、問題のある接続を切断します。
次のオプションを PPP 構成に追加して、構成ファイルのオプションのプロトコルを無効にします。
noccp novj nopcomp noaccomp default-asyncmap |
このオプションは、もっとも単純で圧縮を行わない PPP を使用可能にします。コマンド行でこれらのオプションを引数として pppd を実行してみます。これまで接続できなかったホストに接続できれば、次のいずれかの位置にオプションを追加します。
/etc/ppp/peers/peer-name、call オプションの後
/etc/ppp/options、オプションを広域的に適用する場合
リモートピアを呼び出します。次に、デバッグをオンに設定します。
% pppd debug call peer-name |
chat の -v オプションを使用して、chat プログラムから冗長ログを取得します。
たとえば、PPP 構成ファイルで次の形式を使用します。
connect 'chat -v -f /etc/ppp/chatfile' |
Telnet または他のアプリケーションを使ってリモートホストに接続し、問題を再度発生させてみます。
デバッグログを調べます。これでもリモートホストに接続できない場合は、PPP の問題はネットワークに関連している可能性があります。
リモートホストの IP アドレスが登録されているインターネットアドレスであることを確認します。
組織によっては、ローカルネットワーク内では通用するが、インターネットへは経路指定できない内部 IP アドレスを割り当てる場合があります。リモートホストが社内にある場合、インターネットに接続するためには、管理者は、NAT (名前- アドレス変換) またはプロキシサーバーを設定する必要があります。リモートホストが社内にない場合は、遠隔組織に問題を報告する必要があります。
経路指定テーブルを調べます。
(省略可能) マシンがルーターである場合、オプションの機能を確認します。
# ndd -set /dev/ip ip_forwarding 1 |
ndd の詳細は、ndd(1M) のマニュアルページを参照してください。
netstat -s および同様のツールから取得した統計を確認します。
netstat の詳細は、netstat(1M) のマニュアルページを参照してください。
netstat -s によって生成されたメッセージを使用すると、次の表に示したネットワークの問題を解決できます。
表 31–2 PPP に影響を与える一般的なネットワークの問題
メッセージ |
問題 |
解決方法 |
---|---|---|
IP packets not forwardable |
ローカルホストで送信経路が見つからない |
ローカルホストの経路指定テーブルに欠如している送信経路を追加する |
ICMP input destination unreachable |
ローカルホストで送信経路が見つからない |
ローカルホストの経路指定テーブルに欠如している送信経路を追加する |
ICMP time exceeded |
2 つのルーターが同じ着信アドレスを互いに送信し、パケットが互いに何度も往復し、TTL (存続時間) の値を超過した |
traceroute を使ってルーティングループの源を見つけ、エラーになっているルーターの管理者に連絡する。traceroute の詳細は、traceroute(1M) のマニュアルページを参照 |
IP packets not forwardable |
ローカルホストで送信経路が見つからない |
ローカルホストの経路指定テーブルに欠如している送信経路を追加する |
ICMP input destination unreachable |
ローカルホストで送信経路が見つからない |
ローカルホストの経路指定テーブルに欠如している送信経路を追加する |
DNS 構成を確認します。
ネームサービス構成に問題があると、IP アドレスを解釈処理できないため、アプリケーションは障害を発生します。
ネームサービスの問題を解決するための情報については、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』の「DNS の障害追跡 (参照情報)」を参照してください。
通信の問題は、2 つのピアが接続の確立に失敗したときに発生します。これらの問題は、実際は、chat スクリプトの構成が不適切であるために発生するネゴシエーションの問題であることがしばしばあります。この節では、通信の問題を解決するための情報を提供します。問題のある chat スクリプトによって発生するネゴシエーションの問題の解決方法については、表 31–5 を参照してください。
ローカルマシン上でスーパーユーザーになり、ピアを呼び出します。
リモートピアを呼び出します。次に、デバッグをオンに設定します。
% pppd debug call peer-name |
通信の問題によっては、問題解決のためにピアからデバッグ情報を取得する必要がある場合があります。
次の表に示す通信問題のリストに、取得したログの内容に対応する症状があるかどうかを確認します。
表 31–3 PPP に影響を与える一般的な通信の問題
症状 |
問題 |
解決方法 |
---|---|---|
too many Configure-Requests メッセージ |
あるピアが他のピアを認識できない |
次の問題を確認する
|
pppd debug の出力は LCP が起動していることを示しているが、より上位のプロトコルが失敗したか、あるいは CRC エラーを示している |
非同期制御文字マップ (ACCM) が正しく設定されていない |
default-async オプションを使用して ACCM を標準のデフォルトである FFFFFFFF に設定する。まずコマンド行で pppd のオプションとして default-async を使用してみる。問題が解決したら、default-async を /etc/ppp/options または call オプションの後の /etc/ppp/peers/peer-name に追加する |
pppd debug の出力は IPCP が起動していることを示しているが、すぐに終了してしまう |
IP アドレスの設定が間違っている可能性がある |
|
接続のパフォーマンスが非常に低い |
フロー制御構成のエラー、モデム設定のエラー、不適切に設定された DTE レートなどにより、モデムが適切に構成されていない可能性がある |
モデム構成を確認し、適宜調整する |
PPP の問題には、PPP 構成ファイルの問題が原因となっているものがあります。この節では、一般的な構成の問題を特定して解決するための情報を提供します。
ローカルマシン上でスーパーユーザーになります。
リモートピアを呼び出します。次に、デバッグをオンに設定します。
% pppd debug call peer-name |
次の表に示す構成問題のリストに、取得したログの内容に対応する症状があるかどうかを確認します。
表 31–4 一般的な PPP 構成の問題
症状 |
問題 |
解決方法 |
---|---|---|
pppd debug の出力に「Could not determine remote IP address.」というエラーメッセージが含まれる |
/etc/ppp/peers/peer-name ファイルにそのピアの IP アドレスが存在しない。ピアが、接続ネゴシエーション時に IP アドレスを提供しない |
次の形式を使用して、pppd コマンド行、あるいは /etc/ppp/peers/peer-name でピアの IP アドレスを指定する :10.0.0.10 |
pppd debug の出力がCCP データ圧縮が失敗したことを示す。出力には接続が解除されたことも表示する |
ピアの PPP 圧縮設定が衝突している可能性がある |
ピアの 1 つで /etc/ppp/options に noccp オプションを追加して CCP 圧縮を無効にする |
モデムは、ダイアルアップリンクで問題の発生しやすい領域です。モデム構成でもっともよく発生する問題は、ピアからの応答がないことです。しかし、接続の問題の原因が本当にモデム構成の問題なのかどうかを判定することは難しい場合があります。
モデムの基本的な障害追跡に関するヒントは、『Solaris のシステム管理 (上級編)』の「端末とモデムの問題を解決する方法」を参照してください。モデムメーカーのマニュアルや Web サイトも、特定の装置に関する問題の解決に役立ちます。この節では、モデムの問題を特定して解決するためのヒントを提供します。
次の手順は、問題のあるモデム構成が接続の問題の原因となっているかどうかを判定するのに役立ちます。
PPP デバッグをオンに設定する方法 で説明した手順で、デバッグをオンに設定してピアを呼び出します。
作成された /var/log/pppdebug ログを表示します。
出力に次の症状が認められる場合は、モデム構成に問題がある可能性があります。
ピアから「recvd」メッセージが返されない
出力にピアからの LCP メッセージが含まれるが、接続は失敗し、ローカルマシンから「too many LCP Configure Requests」のメッセージが送信される
このメッセージは、ローカルマシンはピアを認識できるが、ピアはローカルマシンを認識できないことを示します。
接続が SIGHUP 信号で終了する
ping を使用してさまざまなサイズのパケットを接続上に送信します。
ping の詳細は、ping(1M) のマニュアルページを参照してください。
小さいパケットは受信されるが、大きいパケットはドロップされる場合、モデムに問題があることを示します。
インタフェース sppp0 上のエラーを確認します。
% netstat -ni Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue lo0 8232 127.0.0.0 127.0.0.1 826808 0 826808 0 0 0 hme0 1500 172.21.0.0 172.21.3.228 13800032 0 1648464 0 0 0 sppp0 1500 10.0.0.2 10.0.0.1 210 0 128 0 0 0 |
インタフェースのエラーが時間がたつにつれて増えている場合は、モデム構成に問題がある可能性があります。
chat スクリプトは、ダイアルアップリンクで問題が発生しやすい領域です。この節では、chat からデバッグ情報を取得する手順と、一般的な問題を解決するためのヒントを示します。
ダイアルアウトマシン上でスーパーユーザーになります。
/etc/ppp/peers/peer-name ファイルを編集してピアが呼び出されるようにします。
connect オプションで指定されている chat コマンドに引数として -v を追加します。
connect "/usr/bin/chat -v -f /etc/ppp/chat-script-name" |
/etc/ppp/connect-errors ファイルの chat スクリプトのエラーを表示します。
以下は、chat で見られる主なエラーです。
Oct 31 08:57:13 deino chat[107294]: [ID 702911 local2.info] expect (CONNECT) Oct 31 08:57:58 deino chat[107294]: [ID 702911 local2.info] alarm Oct 31 08:57:58 deino chat[107294]: [ID 702911 local2.info] Failed |
この例は、(CONNECT) 文字列を待つ間にタイムアウトしたことを示します。chat が失敗すると、pppd から次のメッセージを受け取ります。
Connect script failed |
次の表に、chat スクリプトの一般的なエラーと、エラー解決のためのヒントを示します。
表 31–5 chat スクリプトの一般的な問題
ダイアルインサーバーは、速度の設定の衝突が原因で問題が発生する可能性があります。次に示す手順は、接続の問題の原因がシリアル回線速度の衝突であることを特定するのに役立ちます。
/bin/login のようなプログラムを介して PPP を起動し、回線の速度を指定した
PPP を mgetty から起動し、誤ってビットレートを指定した
ダイアルインサーバーにログインします。デバッグをオンに設定してピアを呼び出しま す。
手順については、PPP デバッグをオンに設定する方法を参照してください。
作成された /var/log/pppdebug ログを表示します。
出力に次のメッセージがないか確認します。
LCP too many configure requests |
PPP が /bin/login のようなプログラムを介して起動されているかどうかを調べ、設定されている回線速度を調べます。
このような状況では、pppd はもともと設定されていた回線速度を /bin/login で指定されている速度に変更します。
ユーザーが PPP を mgetty コマンドから起動し、偶然にビットレートを指定していないかどうか確認します。
この処理もまた、シリアル回線速度の衝突を引き起こします。
次のようにしてシリアル回線速度の衝突の問題を解決します。
専用回線でもっとも一般的な問題は、パフォーマンスの低下です。ほとんどの場合、問題を解決するためには、電話会社に相談する必要があります。
表 31–6 一般的な専用回線の問題
症状 |
問題 |
解決方法 |
---|---|---|
接続が開始しない |
CSU BPV (CSU 極性違反) が原因の可能性がある。接続の一方の側が AMI 回線用に設定されており、もう一方の側が ESF の B8ZS (Bit 8 Zero Substitute) 用に設定されている。 |
米国またはカナダのユーザーは、この問題を CSU/DSU のメニューから直接解決できる。詳細は、CSU/DSU メーカーのマニュアルを参照。 その他の地域のユーザーは、プロバイダが CSU BPV の解決策を用意している可能性がある |
接続のパフォーマンスが非常に低い |
接続上でトラフィックが持続しているときに、pppd debug の出力が CRC エラーを示す。回線に、電話会社とネットワークの間の誤った設定によって生じた刻時の問題がある可能性がある。 |
電話会社に連絡し、「ループ刻時」を使用していたことを確認する。 構造化されていない専用回線では、刻時を提供する必要がある場合がある。北米のユーザーはループクロックを使用すること。
|
症状 |
問題 |
解決方法 |
---|---|---|
pppd debug の出力が「Peer is not authorized to use remote address address」というメッセージを示す |
PAP 認証を使用しており、リモートピアの IP アドレスが /etc/ppp/pap-secrets ファイルに存在しない |
/etc/ppp/pap-secrets ファイルで、ピアのエントリの後にアスタリスク (*) を追加する |
pppd debug の出力は LCP が起動していることを示しているが、その直後に終了してしまう |
特定のセキュリティプロトコルのデータベースでパスワードが間違っている可能性がある |
/etc/ppp/pap-secrets または /etc/ppp/chap-secrets ファイルでピアのパスワードを確認する |
PPP および標準の UNIX ユーティリティを使用して PPPoE の問題を特定できます。この節では、PPPoE のデバッグ情報を取得する方法について説明します。また、PPPoE 関連の問題を解決する方法についても記述します。
接続上の問題の原因が PPPoE だと思われるとき、次の診断ツールを使って障害追跡情報を取得できます。
PPPoE トンネルを実行しているマシン、つまり PPPoE クライアントまたは PPPoE アクセスサーバーでスーパーユーザーになります。
PPP デバッグをオンに設定する方法 で説明した手順で、デバッグをオンに設定します。
ログファイル /var/log/pppdebug の内容を表示します。
以下の例は、PPPoE トンネルとの接続で生成されたログファイルの一部です。
Sep 6 16:28:45 enyo pppd[100563]: [ID 702911 daemon.info] Plugin pppoe.so loaded. Sep 6 16:28:45 enyo pppd[100563]: [ID 860527 daemon.notice] pppd 2.4.0b1 (Sun Microsystems, Inc., Sep 5 2001 10:42:05) started by troot, uid 0 Sep 6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.debug] connect option: '/usr/lib/inet/pppoec -v hme0' started (pid 100564) Sep 6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.info] Serial connection established. Sep 6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.info] Using interface sppp0 Sep 6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.notice] Connect: sppp0 <--> /dev/sppptun Sep 6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.debug] /etc/ppp/pap-secrets is apparently empty Sep 6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.debug] /etc/ppp/chap-secrets is apparently empty Sep 6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.debug] sent [LCP ConfReq id=0xef <mru 1492> asyncmap 0x0 <magic 0x77d3e953><pcomp><acomp> Sep 6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.debug] rcvd [LCP ConfReq id=0x2a <mru 1402> asyncmap 0x0 <magic 0x9985f048><pcomp><acomp |
デバッグの出力によって問題を特定できない場合は、次の手順に進みます。
# pppd connect "/usr/lib/inet/pppoec -v interface-name" |
pppoec は、診断情報を stderr に送信します。pppd をフォアグラウンドで実行する場合、出力が画面に表示されます。pppd をバックグラウンドで実行する場合、出力は /etc/ppp/connect-errors に送られます。
次の例は、PPPoE トンネルがネゴシエートされたときに生成されるメッセージです。
Connect option: '/usr/lib/inet/pppoec -v hme0' started (pid 100564) /usr/lib/inet/pppoec: PPPoE Event Open (1) in state Dead (0): action SendPADI (2) /usr/lib/inet/pppoec: Sending PADI to ff:ff:ff:ff:ff:ff: 18 bytes /usr/lib/inet/pppoec: PPPoE State change Dead (0) -> InitSent (1) /usr/lib/inet/pppoec: Received Active Discovery Offer from 8:0:20:cd:c1:2/hme0:pppoed /usr/lib/inet/pppoec: PPPoE Event rPADO+ (5) in state InitSent (1): action SendPADR+ (5) /usr/lib/inet/pppoec: Sending PADR to 8:0:20:cd:c1:2: 22 bytes /usr/lib/inet/pppoec: PPPoE State change InitSent (1) -> ReqSent (3) /usr/lib/inet/pppoec: Received Active Discovery Session-confirmation from 8:0:20:cd:c1:2/hme0:pppoed /usr/lib/inet/pppoec: PPPoE Event rPADS (7) in state ReqSent (3): action Open (7) /usr/lib/inet/pppoec: Connection open; session 0002 on hme0:pppoe /usr/lib/inet/pppoec: PPPoE State change ReqSent (3) -> Convers (4) /usr/lib/inet/pppoec: connected |
診断メッセージによって問題を特定できない場合は、次の手順に進みます。
snoop を実行します。次にトレースをファイルに保存します。
snoop の詳細は、snoop(1M) のマニュアルページを参照してください。
# snoop -o pppoe-trace-file |
snoop トレースファイルを表示します。
# snoop -i pppoe-trace-file -v pppoe |
ETHER: ----- Ether Header ----- ETHER: ETHER: Packet 1 arrived at 6:35:2.77 ETHER: Packet size = 32 bytes ETHER: Destination = ff:ff:ff:ff:ff:ff, (broadcast) ETHER: Source = 8:0:20:78:f3:7c, Sun ETHER: Ethertype = 8863 (PPPoE Discovery) ETHER: PPPoE: ----- PPP Over Ethernet ----- PPPoE: PPPoE: Version = 1 PPPoE: Type = 1 PPPoE: Code = 9 (Active Discovery Initiation) PPPoE: Session Id = 0 PPPoE: Length = 12 bytes PPPoE: PPPoE: ----- Service-Name ----- PPPoE: Tag Type = 257 PPPoE: Tag Length = 0 bytes PPPoE: PPPoE: ----- Host-Uniq ----- PPPoE: Tag Type = 259 PPPoE: Tag Length = 4 bytes PPPoE: Data = Ox00000002 PPPoE: . . . ETHER: ----- Ether Header ----- ETHER: ETHER: Packet 5 arrived at 6:35:2.87 ETHER: Packet size = 60 bytes ETHER: Destination = 8:0:20:78:f3:7c, Sun) ETHER: Source = 0:2:fd:39:7f:7, ETHER: Ethertype = 8864 (PPPoE Session) ETHER: PPPoE: ----- PPP Over Ethernet ----- PPPoE: PPPoE: Version = 1 PPPoE: Type = 1 PPPoE: Code = 0 (PPPoE Session) PPPoE: Session Id = 24383 PPPoE: Length = 20 bytes PPPoE: PPP: ----- Point-to-Point Protocol ----- PPP: PPP-LCP: ----- Link Control Protocol ----- PPP-LCP: PPP-LCP: Code = 1 (Configure Request) PPP-LCP: Identifier = 80 PPP-LCP: Length = 18 |