第 21 章 一般的な PPP 問題の解決 (手順)

この章では、Solaris PPP 4.0 で発生する一般的な問題のトラブルシューティングに関する情報を提供します。次の項目について説明します。

• 「PPP のトラブルシューティングのためのツール」

• 「PPP および PPPoE 関連の問題の解決」

• 「専用回線の問題の解決」

• 「認証の問題の診断と解決」

James Carlson による『PPP Design, Implementation, and Debugging』やオーストラリア国立大学の Web サイトなどの情報源も、PPP のトラブルシューティングに詳細なアドバイスを提供しています。詳細は、「PPP に関する専門技術者向けのリファレンスブック」および 「PPP に関する Web サイト」を参照してください。

PPP 問題の解決 (作業マップ)

次の作業マップを使用すれば、一般的な PPP の問題のためのアドバイスや解決方法をすばやく探すことができます。

PPP のトラブルシューティングのためのツール

PPP リンクは、一般に次の 3 つの主要な領域で障害が発生します。

• 接続の確立に失敗する

• 通常の使用の中で接続パフォーマンスが低下する

• 接続のどちらかの側でネットワークに原因と考えられる問題が発生する

PPP が動作しているかどうかを確認するためのもっとも簡単な方法は、リンクを介したコマンドを実行することです。ping や traceroute などのコマンドをピアのネットワーク上のホストに対して実行し、結果を調べます。ただし、確立されている接続のパフォーマンスを監視したり、問題のある接続をトラブルシューティングしたりするには、PPP および UNIX のデバッグツールを使用してください。

この節では、pppd および関連するログファイルから診断情報を取得する方法について説明します。この章の残りの節では、PPP トラブルシューティングツールを使って発見し解決できる PPP に関する一般的な問題を説明します。

pppd から診断情報を取得する方法

次に、ローカルマシン上の接続の現在の動作を表示する手順を説明します。

1. ローカルマシン上でスーパーユーザーになるか、同等の役割になります。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. PPP に設定されているシリアルデバイスを引数としてpppd を実行します。

   # pppd cua/b debug updetach

   次に、pppd をフォアグラウンドで実行したときに表示されるダイアルアップリンクおよび専用回線リンクの診断結果の例を示します。バックグラウンドで pppd debug を実行すると、作成される出力は /etc/ppp/connect-errors ファイルに送られます。

例 21–1 正常に動作しているダイアルアップ接続からの出力

# 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., Oct  6 
	2004 09:36:22)"]
Peer Identification: ppp-2.4.0b1 (Sun Microsystems, Inc., Oct  6 2004 09:36:22)
	rcvd [LCP ConfRej id=0x7b <asyncmap 0x0>]
sent [LCP Ident id=0x7c magic=0x0 "ppp-2.4.0b1 (Sun Microsystems, Inc., Sep 15 
	2004 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., 
	Sep 15 2004 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., 
	Oct  6 2004 09:36:22)"]
Peer Identification: ppp-2.4.0b1 (Sun Microsystems, Inc., Oct  6 2004 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

例 21–2 正常に動作している専用回線リンクからの出力

# pppd /dev/se_hdlc1 default-asyncmap debug updetach
pppd 2.4.0b1 (Sun Microsystems, Inc., Oct 24 2004 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 2004 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 2004 14:31:44)"]
Peer Identification: ppp-2.4.0b1 (Sun Microsystems, Inc., Oct 22 2004 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

PPP デバッグをオンに設定する方法

次に、pppd コマンドを使ってデバッグ情報を取得する方法を示します。

手順 1 から手順 3 までは各ホストごとに 1 度実行するだけでかまいません。その後、手順 4 に進んでホストのデバッグをオンに設定できます。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. pppd からの出力を保持するためのログファイルを作成します。

   # touch /var/log/pppdebug

3. 次の pppd 用の syslog 機能を /etc/syslog.conf に追加します。

   daemon.debug;local2.debug /var/log/pppdebug

4. syslogd を再起動します。

   # pkill -HUP -x syslogd

5. pppd の次の構文を使用して、特定のピアに対する呼び出しのデバッグをオンに設定します。

   # pppd debug call peer-name

   peer-name は、/etc/ppp/peers ディレクトリにあるファイル名でなければなりません。

6. ログファイルの内容を表示します。

   # tail -f /var/log/pppdebug

   ログファイルの例については、手順 3 を参照してください。

PPP および PPPoE 関連の問題の解決

PPP 関連の問題と PPPoE 関連の問題を解決する方法については、次の節を参照してください。

• 「ネットワークの問題を診断する方法」

• 「PPP に影響を与える一般的なネットワークの問題」

• 「通信の問題を診断し解決する方法」

• 「PPP に影響を与える一般的な通信の問題」

• 「PPP 構成の問題を診断する方法」

• 「一般的な PPP 構成の問題」

• 「モデムの問題を診断する方法」

• 「chat スクリプトのデバッグ情報を取得する方法」

• 「chat スクリプトの一般的な問題」

• 「シリアル回線の速度の問題を診断して解決する方法」

• 「PPPoE の診断情報を取得する方法」

ネットワークの問題を診断する方法

PPP リンクがアクティブになったにもかかわらずリモートネットワーク上のほとんどのホストに到達できないという場合は、ネットワーク問題が見つかる可能性があります。ここでは、PPP リンクに影響を与えるネットワーク障害を特定し、解決する方法を示します。

1. ローカルマシン上でスーパーユーザーになるか、同等の役割になります。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. 問題のある接続を切断します。

3. 次のオプションを PPP 構成に追加して、構成ファイルのオプションのプロトコルを無効にします。

   noccp novj nopcomp noaccomp default-asyncmap

   このオプションは、もっとも単純で圧縮を行わない PPP を使用可能にします。コマンド行でこれらのオプションを引数として pppd を実行してみます。これまで接続できなかったホストに接続できれば、次のいずれかの位置にオプションを追加します。

   • /etc/ppp/peers/peer-name、call オプションのあと

   • /etc/ppp/options、オプションを広域的に適用する場合

4. リモートピアを呼び出します。次に、デバッグをオンに設定します。

   % pppd debug call peer-name

5. chat の -v オプションを使用して、chat プログラムから冗長ログを取得します。

   たとえば、PPP 構成ファイルで次の形式を使用します。

   connect 'chat -v -f /etc/ppp/chatfile'

   /etc/ppp/chatfile は、お使いの chat ファイルの名前を表します。

6. Telnet またはほかのアプリケーションを使ってリモートホストに接続し、問題を再度発生させてみます。

   デバッグログを調べます。これでもリモートホストに接続できない場合は、PPP の問題はネットワークに関連している可能性があります。

7. リモートホストの IP アドレスが登録されているインターネットアドレスであることを確認します。

   組織によっては、ローカルネットワーク内では通用するが、インターネットへは経路指定できない内部 IP アドレスを割り当てる場合があります。リモートホストが社内にある場合、インターネットに接続するためには、管理者は、NAT (名前 - アドレス変換) またはプロキシサーバーを設定する必要があります。リモートホストが社内にない場合は、遠隔組織に問題を報告する必要があります。

8. 経路指定テーブルを調べます。

   1. ローカルマシンとピアの両方で経路指定テーブルを確認します。

   2. 経路指定テーブルで、ピアからリモートシステムへのパスにあるルーターをすべて確認します。また、リモートシステムからピアへの戻りのパスにあるルーターもすべて確認します。

      中間ルーターの設定が間違っていないことを確認します。ピアへの戻りのパスに問題が見つかることがしばしばあります。

9. (省略可能) マシンがルーターである場合、オプションの機能を確認します。

   # ndd -set /dev/ip ip_forwarding 1

   ndd の詳細は、ndd(1M) のマニュアルページを参照してください。

   Solaris 10 リリースでは、ndd(1M) ではなく routeadm(1M) を利用できます。

   # routeadm -e ipv4-forwarding -u

   ---

   注 –

   ndd コマンドに持続性はありません。このコマンドに設定された値は、システムのリブート時に消失します。routeadm コマンドは持続します。このコマンドに設定された値は、システムのリブート後も保持されます。

   ---

10. netstat -s および同様のツールから取得した統計を確認します。

    netstat の詳細は、netstat(1M) のマニュアルページを参照してください。

    1. ローカルマシン上で統計を実行します。

    2. ピアを呼び出します。

    3. netstat -s によって生成された新しい統計を調べます。詳細は、「PPP に影響を与える一般的なネットワークの問題」を参照してください。

11. DNS 構成を確認します。

    ネームサービス構成に問題があると、IP アドレスを解釈処理できないため、アプリケーションは障害を発生します。

PPP に影響を与える一般的なネットワークの問題

netstat -s によって生成されたメッセージを使用すると、次の表に示したネットワークの問題を解決できます。関連する作業情報として、「ネットワークの問題を診断する方法」を参照してください。

通信の問題を診断し解決する方法

通信の問題は、2 つのピアがリンクを正常に確立できない場合に発生します。これらは、chat スクリプトが不正に設定されているために起きるネゴシエーション問題であることもあります。ここでは、通信の問題を解決する方法を示します。誤りのある chat スクリプトによって発生するネゴシエーション問題を解決する方法については、表 21–5 を参照してください。

1. ローカルマシン上でスーパーユーザーになるか、同等の役割になります。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. ピアを呼び出します。

3. リモートピアを呼び出します。次に、デバッグをオンに設定します。

   % pppd debug call peer-name

   通信の問題によっては、問題解決のためにピアからデバッグ情報を取得する必要がある場合があります。

4. 生成されたログをチェックし、通信の問題が報告されていないかを確認します。詳細は、「PPP に影響を与える一般的な通信の問題」を参照してください。

PPP に影響を与える一般的な通信の問題

次の表は、「通信の問題を診断し解決する方法」の作業で出力されるログに関連する症状を説明したものです。

PPP 構成の問題を診断する方法

PPP の問題には、PPP 構成ファイルの問題が原因となっているものがあります。ここでは、一般的な構成問題を特定し、解決する方法を示します。

1. ローカルマシン上でスーパーユーザーになるか、同等の役割になります。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. リモートピアを呼び出します。次に、デバッグをオンに設定します。

   % pppd debug call peer-name

3. 生成されたログをチェックし、構成問題が報告されていないかを確認します。詳細は、「一般的な PPP 構成の問題」を参照してください。

一般的な PPP 構成の問題

次の表は、「PPP 構成の問題を診断する方法」の作業で出力されるログに関連する症状を説明したものです。

モデムの問題を診断する方法

モデムは、ダイアルアップリンクで問題の発生しやすい領域です。モデム構成でもっともよく発生する問題は、ピアからの応答がないことです。しかし、接続の問題の原因が本当にモデム構成の問題なのかどうかを判定することは難しい場合があります。

モデムの基本的なトラブルシューティングに関するヒントは、『Solaris のシステム管理 (上級編)』の「端末とモデムの問題を解決する方法」を参照してください。モデムメーカーのマニュアルや Web サイトは、特定の装置に関する問題の解決に役立ちます。次の手順は、問題のあるモデム構成が接続の問題の原因となっているかどうかを判定するのに役立ちます。

1. 「PPP デバッグをオンに設定する方法」で説明した手順で、デバッグをオンに設定してピアを呼び出します。

2. 作成された /var/log/pppdebug ログを表示し、モデム構成に問題がないかを確認します。

3. ping を使用してさまざまなサイズのパケットを接続上に送信します。

   ping の詳細は、ping(1M) のマニュアルページを参照してください。

   小さいパケットは受信されるが、大きいパケットはドロップされる場合、モデムに問題があることを示します。

4. インタフェース 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

   インタフェースのエラーが時間がたつにつれて増えている場合は、モデム構成に問題がある可能性があります。

注意事項

作成された /var/log/pppdebug ログの表示で次の症状が認められる場合は、モデムの構成に問題がある可能性があります。ローカルマシンはピアを認識できますが、ピアはローカルマシンを認識できません。

• ピアから「recvd」メッセージが返されない。

• 出力にピアからの LCP メッセージが含まれるが、接続は失敗し、ローカルマシンから「too many LCP Configure Requests」のメッセージが送信される。

• 接続が SIGHUP 信号で終了する。

chat スクリプトのデバッグ情報を取得する方法

次の操作は、chat のデバッグ情報を表示して一般的な問題の解決方法を知る手段として行なってください。詳細は、「chat スクリプトの一般的な問題」を参照してください。

1. ダイアルアウトマシン上のスーパーユーザー、またはそれと同等の役割になります。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. /etc/ppp/peers/peer-name ファイルを編集してピアが呼び出されるようにします。

3. connect オプションで指定されている chat コマンドに引数として -v を追加します。

   connect "/usr/bin/chat -v -f /etc/ppp/chat-script-name"

4. /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 スクリプトの一般的な問題

chat スクリプトは、ダイアルアップリンクにおいてもっとも問題が発生しやすい領域です。次の表に、chat スクリプトの一般的なエラーと、エラー解決のためのヒントを示します。操作方法については、「chat スクリプトのデバッグ情報を取得する方法」を参照してください。

ogin: user-name
ssword: password

ogin: pppuser
ssword: \q\U

ogin: pppuser
ssword: \q\U

CONNECT ”

CONNECT \c

CONNECT ”

CONNECT \c

CONNECT ”

CONNECT \c

CONNECT ”

CONNECT \c

CONNECT ”

CONNECT \c

シリアル回線の速度の問題を診断して解決する方法

ダイアルインサーバーは、速度の設定の衝突が原因で問題が発生する可能性があります。次に示す手順は、接続の問題の原因がシリアル回線速度の衝突であることを特定するのに役立ちます。

速度の問題は、次のような原因で発生します。

• /bin/login のようなプログラムを介して PPP を起動し、回線の速度を指定した

• PPP を mgetty から起動し、誤ってビットレートを指定した

pppd は、はじめは回線に設定されていた速度を /bin/login または mgetty によって設定された速度に変更します。このことが回線の障害を発生させます。

1. ダイアルインサーバーにログインします。デバッグをオンに設定してピアを呼び出します。

   手順については、「PPP デバッグをオンに設定する方法」を参照してください。

2. 作成された /var/log/pppdebug ログを表示します。

   出力に次のメッセージがないか確認します。

   LCP too many configure requests

   このメッセージは、PPP に設定されているシリアル回線の速度が衝突している可能性があることを示します。

3. PPP が /bin/login のようなプログラムを介して起動されているかどうかを調べ、設定されている回線速度を調べます。

   このような状況では、pppd はもともと設定されていた回線速度を /bin/login で指定されている速度に変更します。

4. ユーザーが PPP を mgetty コマンドから起動し、誤ってビットレートを指定していないかどうか確認します。

   この処理もまた、シリアル回線速度の衝突を引き起こします。

5. 次のようにしてシリアル回線速度の衝突の問題を解決します。

   1. モデムの DTE レートをロックします。

   2. autobaud を使用しないようにします。

   3. 設定後に回線速度を変更しないようにします。

PPPoE の診断情報を取得する方法

PPP および標準の UNIX ユーティリティーを使用して PPPoE の問題を特定できます。接続上の問題の原因が PPPoE だと思われるとき、次の診断ツールを使ってトラブルシューティング情報を取得できます。

1. PPPoE トンネルを実行しているマシン、つまり PPPoE クライアントまたは PPPoE アクセスサーバーでスーパーユーザーになります。

2. 「PPP デバッグをオンに設定する方法」で説明した手順で、デバッグをオンに設定します。

3. ログファイル /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

   デバッグの出力によって問題を特定できない場合は、次の手順に進みます。

4. PPPoE から診断メッセージを取得します。

   # 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

   診断メッセージによって問題を特定できない場合は、次の手順に進みます。

5. snoop を実行します。次にトレースをファイルに保存します。

   snoop の詳細は、snoop(1m) のマニュアルページを参照してください。

   # snoop -o pppoe-trace-file

6. 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

専用回線の問題の解決

専用回線でもっとも一般的な問題は、パフォーマンスの低下です。ほとんどの場合、問題を解決するためには、電話会社に相談する必要があります。

認証の問題の診断と解決

次の表は、一般的な認証問題について説明したものです。