Device.Network テストのトラブルシューティング

Device.Network テストのトラブルシューティング

Device.Network テストで発生する問題をトラブルシューティングするには、次の手順に従います。

1. 「Windows HLK テストのエラーのトラブルシューティング」を確認します。

   テストするネットワーク製品または機能の種類に応じて、次のいずれかのトピックを確認してください。

   • IPsec タスク オフロード v2 のテストの前提条件

   • LAN のテストの前提条件

   • モバイル ブロードバンドのテストの前提条件

   • ルーターのテスト (非ワイヤレス) の前提条件

   • ワイヤレス LAN (802.11) のテストの前提条件

   • ワイヤレス ルーターのテストの前提条件

2. 現在のテストの問題については、Windows HLK のリリース ノートを確認してください。

3. テスト エラーについて、Windows HLK Studio テスト ログ内で有用な情報を探します。 有用な情報が見つかったら、問題を解決し、テストを再実行します。

IPsec テストでの既知の問題

Windows HLK コントローラーをクライアントに接続できない場合は、次の手順を行います。

1. 最初のテスト ケースは、セットアップが確実に正しく行われるように設計されたもので、 パブリックおよびプライベート ネットワークの接続を確認する以外に何も行いません。 このテストが失敗した場合、テストのセットアップに問題があります。

2. config.dat ファイルが %SystemDrive%\IPsecTestKit\IPsecScenario\ に配置されており、コントローラーとクライアントの適切な IP アドレスが含まれていることを確認します。 このファイルは自動的に生成されますが、DNS 解決エラーなどの特定のケースでは、config.dat ファイルに誤ったデータが含まれていたり、ファイルが完全に欠落していたりする場合があります。 config.dat ファイルを確認するには、「テストのセットアップ」セクションで説明されている形式を使用してください。

3. IPsecControl.exe および IPsecScenario.exe に対してファイアウォールの除外が設定されていることを確認します。

4. セットアップ スクリプトを実行した後、IPsec Offload V2 インターフェイスの名前が "Test1" に正常に変更されたことを確認します。

メッセージ アダプターの既定のゲートウェイが 1 つしかない場合、必要な CMD ファイルが Genconfig_phase2.vbs によって生成されない可能性があります。 DHCP サーバーで IP V6 がサポートされていない場合、IP V6 の既定のゲートウェイ アドレスを 1 つしか取得できません。

個々のテスト バリエーションの実行

テストが失敗した場合は、スイート全体を再実行するのではなく、1 つのテスト バリエーションを実行します。 その手順は次のとおりです。

1. すべてのクライアントで IPsecScenario.exe セッションが実行されていることを確認します。

2. OffloadV2_logoTests.cmd 内から実行する個々のバリエーションをコピーし、新しいコマンド ウィンドウ (%SYSTEMDRIVE%\IPsecTestKit\IPSecscenario\Controller) から実行します

Troubleshooting LAN (Ethernet) Testing

IPSec テスト ジョブは、関連する LAN テスト ジョブの問題に起因して失敗する場合があります。 詳細については、以下のセクションを参照してください。

LAN (Ethernet) テストでの既知の問題

問題	説明
"IPsec Offloadv2 ロゴ検証 (Win7)" テスト ジョブが "Scheduler" 状態のままで実行されない。	この問題は、通常、DTM クライアントとコントローラーの間のさまざまな通信問題が原因で発生します。 "最終ハートビートの日時" が現在の日時に近づいているかどうかを確認できます。 ハートビートを報告している DTM クライアントを強制するには、DTM Studio でコンピューターの状態を手動で [リセット] または [安全でない] に変更し、コンピューターの状態が [正常] に戻るまで待機します。 ジョブの実行に必要なすべてのコンピューターの状態が [正常] に変更されると、そのジョブが DTM クライアントでスケジュールされます。 コンピューターの状態が [デバッグ] に変更された場合は、DTM クライアント コンピューターがまだ応答しているかどうかを確認します。 コンピューターの状態が [正常] で、ハートビートが正しい場合でも、ジョブが実行されないことがあります。 ほとんどの場合、これは、DTM クライアントとコントローラー間の通信がファイアウォールまたは IPsec によってブロックされることが原因で発生します。 DTM クライアントとコントローラーの IPsec 構成が同じであることを確認してください。 クライアントの IPsec が有効になっているが、コントローラーがオフになっている場合、またはその逆の場合、ジョブはスケジュールされません。 DTM クライアントは、ファイアウォールで動作するように設計されていますが、ファイアウォールによってクライアントとコントローラーの間の通常のトラフィックがブロックされる場合があります。
[情報の追加] をクリックすると、テスト ログに、"ジョブ xxx では、ドライバーではなく、デバイスを選択する必要があります" というエラーメッセージが表示される。	このエラーは、テスト ジョブを実行するために、[デバイス コンソール] でテスト デバイスではなくドライバーを選択したことが原因で発生します。 [デバイス コンソール] のドライバーの下でデバイスが見つからない場合、ロゴの送信時に指定した INF ファイルとドライバー ファイルが、DTM クライアント上の実際の INF ファイルおよびドライバー ファイルと一致していません。 DTM クライアントにインストールされている実際の INF ファイルとドライバー ファイルを使用して、INF ファイルとドライバー ファイルを更新します。
[デバイス コンソール] に "IPsec Offloadv2 ロゴ検証 (Win7)" ジョブが表示されない。	デバイスがイーサネット (LAN) デバイスであり、メディアの種類が NdisMedium802_3 として NDIS に報告されていることを確認します。 このエラーは、DTM クライアントによって報告されたハードウェア情報が不完全な場合に発生することがあります。 この問題を解決するには、DTM クライアント コンピューターを再起動し、[デバイス コンソール] の表示を更新します。 これで解決されない場合は、DTM クライアントで "wttsvc" サービスを停止して再起動し、[デバイス コンソール] の表示を更新してみてください。
イーサネット - NDISTest 6.0 (優先度) テストで、2c_priority とダイレクト パケット - NdisSendPackets アサーションが、"テスト用ネットワーク アダプターでテスト結果を取得できない" というメッセージと共に正しく失敗することがある。	この問題は、優先度ビットがネットワーク スイッチによって誤って削除された場合に発生する可能性があります。 ネットワーク スイッチが原因でこの問題が発生していることを確認するには、スイッチを取り外し、ケーブルを直接接続して、アダプターをテストします。 これは、代替のテスト構成を使用して行うことができます。 このテスト構成は、ローカル サポート デバイスを必要とする Chimney (TCP オフロード) をサポートしていないデバイスでのみ使用できます。 ローカル サポート デバイスとテスト用ネットワーク スイッチを完全に取り外し、ローカル テスト デバイスをリモート サポート デバイスに直接バックツーバック接続してください。 これが成功した場合、認定として受け入れることはできますが、スイッチの製造元と協力してスイッチの構成を修正してください。
イーサネット - NDISTest 6.5 (WoL および PM) で、[フェイク LLMNRv4 ネットワークパケットアサーションを送信する] 内のデバイスが、コンピューターが正しく動作していないことを示すエラーと共に正常に失敗する場合がある。	デバイスが正しく失敗したかどうかを判断するために、リモートデバイスでのみプロトコルのバインドを解除します。 これで問題が解決しない場合は、サポート インシデントを開きます。

Note

NDISTest (6.0 または 6.5) のトラブルシューティングを行うには、テスト コンピューターにデバッガーをアタッチします。

モバイル ブロードバンド テストでの既知の問題

次の一覧では、モバイル ブロードバンド テストの一般的なトラブルシューティングのヒントについて説明します。

DTM クライアント コンピューター上のデバイスに加えられた変更は、DTM Studio には反映されません。 たとえば、コンピューターは準備完了の状態であると想定されているが、実際にはそうではないことがある。

1. クライアント コンピューターでコマンド プロンプト ウィンドウを開き、net stop wttsvc を実行します。

2. net start wttsvc を実行します。 このコマンドは C:\wtt\JobsWorkingDir\AssetCfg\Log\ ディレクトリを更新します。

3. DTM Studio で [デバイス コンソール] ウィンドウを更新します。 DTM コントローラーがクライアント コンピューターに対してデバイス一覧の変更をポーリングするまで数分かかる場合があります。

コンピューター プールに対してコンピューターが検出されない。

1. DTM Studio で [ジョブ モニター] ウィンドウを開きます。

2. 画面の上部にある [クエリ ビルダーを表示する] ボタンをクリックします。

3. [コンピューターのクエリ] タブをクリックします。

4. ターゲット コンピューターの検索パラメーターを定義します。 通常は、"DataStore は 'コントローラー名' と等しい" などの単一のルールを設定します。

5. 先ほど定義したルールを右クリックし、[実行] をクリックします。 クエリ フィールドの下の [コンピューター] 一覧に、コンピューターの広範な一覧が表示されます。

6. [コンピューター] 一覧にある任意のコンピューターを、作成した新しいコンピューター プールにドラッグします。

コンピューターが、スケジュールされたジョブを実行していないように見える。

1. DTM Studio で [ジョブ モニター] ウィンドウを開きます。

2. [コンピューター プール] タブで、ジョブを実行する予定のコンピューター プールを選択します。

3. そのプール内の各コンピューターについて、状態が [準備完了] であることを確認します。

4. コンピューターの状態が [準備完了] ではない場合は、コンピューターを右クリックし、[状態の変更] をポイントして [リセット] をクリックします。

5. 数分後に画面表示を更新すると、状態が [準備完了] に変わります。

6. ジョブをスケジュールし、再度開始します。

ネットワーク セキュリティ ソフトウェア テストの既知の前提条件

ネットワーク セキュリティ ソフトウェア (TransitionTechnologies_Tests および WindowsFilteringPlatform_Tests) では、Sparta ミニポート ドライバーがインストールされ、正しく構成されている必要があります。 Sparta ミニポート ドライバーは、各テストの実行時にインストールされます。ただし、必要に応じて、コマンド プロンプトを開き、「IPConfig.exe/all」と入力することで、それらが存在することを確認できます。 Sparta Miniport Primary、Sparta Miniport Secondary、Sparta Miniport Tertiary、Sparta Miniport Quaternary という名前の 4 つの新しい Sparta インターフェイスが表示されます。

ルーター テストでの既知の問題

現在、ルーター テストについて既知の問題はありません。

ワイヤレス LAN (802.11) テストでの既知の問題

次の一覧では、WLAN テストの一般的なトラブルシューティングのヒントについて説明します。

DTM クライアント コンピューター上のデバイスに加えられた変更は、DTM Studio には反映されません。 たとえば、コンピューターは準備完了の状態であると想定されているが、実際にはそうではないことがある。

1. クライアント コンピューターでコマンド プロンプト ウィンドウを開き、net stop wttsvc. を実行します。

2. net start wttsvc を実行します。 このコマンドは C:\wtt\JobsWorkingDir\AssetCfg\Log\ ディレクトリを更新します。

3. DTM Studio で [デバイス コンソール] ウィンドウを更新します。 DTM コントローラーがクライアント コンピューターに対してデバイス一覧の変更をポーリングするまで数分かかる場合があります。

コンピューター プールに対してコンピューターが検出されない。

1. DTM Studio で [ジョブ モニター] ウィンドウを開きます。

2. 画面の上部にある [クエリ ビルダーを表示する] ボタンを選択します。

3. [コンピューターのクエリ] タブをクリックします。

4. 探しているコンピューターの検索パラメーターを定義します。 通常は、"DataStore equals 'Controller Name'" などの単一のルールを設定できます。

5. 今定義したルールを右クリックし、[実行] をクリックします。 定義したクエリ フィールドの下の [コンピューター] リストに、コンピューターを網羅したリストが表示されるはずです。

6. [コンピューター] のリストにある任意のコンピューターを、作成した新しいコンピューター プールにドラッグします。

コンピューターが、スケジュールされたジョブを実行していない

1. DTM Studio で [ジョブ モニター] ウィンドウを開きます。

2. [コンピューター プール] タブで、ジョブを実行する予定のコンピューター プールを選択します。

3. そのプール内の各コンピューターについて、状態が [準備完了] であることを確認します。

4. コンピューターの状態が [準備完了] になっていない場合は、コンピューターを右クリックし、[状態の変更] をポイントして [リセット] をクリックします。

5. 数分後に画面表示を更新すると、状態が [準備完了] に変わります。

6. ジョブをスケジュールし、再度開始します。

トポロジへの Test SoftAP ドライバーのインストールに関する問題: デバイス マネージャー レポート コード 52

DTM クライアントをインストールする前に、x64 Test SoftAP ドライバーをインストールしないでください。 DTM クライアントがインストールされると、ルート証明書がインストールされます。 テスト SoftAP ドライバーの署名はルート証明書のインストールに依存しているため、デバイス マネージャーはデバイス コード52を報告します。

スタンドアロン実行のための NDISTest の構成

DTM Studio とは別に NDISTest をインストールすると、個々のテストを実行できます。 DUT、SUT、Test SoftAP は、スタンドアロンの実行を有効にするように構成する必要があります。

Note

すべてのテスト コンピューターは、同じプロセッサアーキテクチャを使用している必要があります。

Note

NDISTest のトラブルシューティングを行うには、テスト コンピューターにデバッガーをアタッチしてみてください。

テスト対象のサポート デバイス (SUT) の構成

1. 次の DTM コントローラーからすべての NDISTest バイナリとサブディレクトリをコピーします。

   \\<ControllerMachine]>\tests\<architecture>\nttest\nettest\ndis\ndistest.net\

   <ControllerMachine> は、DTM コントローラー コンピューターの名前であり、<architecture> は、x86 (x86 ベースのプロセッサの場合) または amd64 (x64 ベースのプロセッサの場合) のいずれかです。

2. インストール ディレクトリから NDISTest.exe を起動します。 メイン フォームが開いたら、[ファイル] メニューの [サーバー] を選択して、サーバー フォームを起動します。

3. [メッセージ デバイス] の一覧からメッセージ デバイスを選択します。 このデバイスは、IP 対応であり、後で設定されるクライアント メッセージ デバイスと同じサブネット上にある必要があります。

4. [サポート デバイス] から SUT デバイスを選択します。 サーバーを起動すると、このサーバーで選択されたサポート デバイスがクライアントに表示されます。

5. [ジョブ] から "サーバー" ジョブを選択します。 これはサーバー側のテストであり、[開始] ボタンをクリックした後に起動されます。

すべてのオプションを選択したら、[開始] をクリックしてサーバーを起動します。

テスト ソフトウェア アクセス ポイント (Test SoftAP) の構成

1. 次の DTM コントローラーからすべての NDISTest バイナリとサブディレクトリをコピーします。

   \\<ControllerMachine]>\tests\<architecture>\nttest\nettest\ndis\ndistest.net\

   <ControllerMachine> は、DTM コントローラー コンピューターの名前であり、<architecture> は、x86 (x86 ベースのプロセッサの場合) または amd64 (x64 ベースのプロセッサの場合) のいずれかです。

2. テスト SoftAP の両方の Atheros WLAN デバイスに対して SoftAP driver をインストールします。 このドライバーは、コマンドプロンプトから devmgmt.msc を実行して開くことができるデバイス マネージャーからインストールできます。 次の手順を完了させます。

   [デバイス マネージャー] で、次の場所から SoftAP ステーションのドライバーをインストールします。

   \\<ControllerMachine]>\Tests\<architecture>\nttest\nettest\ndis\NDISTest.net\SoftAPMiniport\

   <ControllerMachine> は、DTM コントローラー コンピューターの名前であり、<architecture> は、SoftAP デバイスがある DTM クライアント コンピューターのプロセッサ アーキテクチャに応じて、x86 (x86 ベースのプロセッサの場合) または amd64 (x64 ベースのプロセッサの場合) のいずれかです。

3. インストール ディレクトリから NDISTest.exe を起動します。 メイン フォームが開いたら、[ファイル] メニューの [サーバー] を選択して、サーバー フォームを起動します。

4. [メッセージ デバイス] の一覧からメッセージ デバイスを選択します。 このデバイスは、IP 対応デバイスであり、後で設定されるクライアント メッセージ デバイスと同じサブネット上にある必要があります。

5. [AP デバイス] から AP デバイスを選択します。 サーバーを起動すると、このサーバーで選択された AP デバイスがクライアントに表示されます。

6. [ジョブ] から "サーバー" ジョブを選択します。 これはサーバー側のテストであり、[開始] ボタンをクリックした後に起動されます。

すべてのオプションを選択したら、[開始] をクリックしてサーバーを起動します。

テスト対象のデバイス (DUT) の構成

1. 次の DTM コントローラーからすべての NDISTest バイナリとサブディレクトリをコピーします。

   \\<ControllerMachine>\tests\<architecture>\nttest\nettest\ndis\ndistest.net\

   <ControllerMachine> は、DTM コントローラー コンピューターの名前であり、<architecture> は、x86 (x86 ベースのプロセッサの場合) または amd64 (x64 ベースのプロセッサの場合) のいずれかです。

2. インストール ディレクトリから NDISTest.exe を起動します。 メイン フォームが開いたら、[ファイル] メニューの [クライアント] を選択して、クライアント フォームを起動します。

3. [テスト ターゲット] リストからテスト ターゲットを選択します。 ネットワーク デバイスの場合、このテスト ターゲットは ミニポートである必要があります。

4. [テスト デバイス] の一覧からテスト デバイスを選択します。 これは、ベンダー固有のテスト デバイスである必要があります。

5. [メッセージ デバイス] の一覧からメッセージ デバイスを選択します。 これは、サーバーのメッセージ デバイスと同じサブネット上にある IP 対応デバイスである必要があります。 メッセージ デバイスを選択すると、[AP デバイス] セクションが表示され、サーバーの AP デバイスが一覧に表示されます。

6. [サポート デバイス] からサポート デバイスを選択します。 これは、ベンダー固有のサポート デバイスである必要があります。

7. [AP デバイス] から AP デバイスを選択します。 これは、サーバー側で選択された AP デバイスである必要があります。

8. クライアントを起動した後に実行されるテストを [ジョブ] セクションから選択します。

すべてのオプションを選択したら、[開始] をクリックしてクライアントを起動します。 選択されたジョブの実行が開始されます。 テスト結果は、クライアントの次のログ サブフォルダーに格納されます。

<NDISTestRootFolder>/logs/<AdapterName>/

クライアント パケット キャプチャの構成

1. スタンドアロン実行用のテスト トポロジを構成します。 詳細については、「スタンドアロン実行のための NDISTest の構成」を参照してください。

2. 2 つ目の SUT をセットアップします。 詳細については、「テスト対象のサポート デバイス (SUT) の構成」を参照してください。

3. インストール ディレクトリから NDISTest.exe を起動します。 メインフォームが開いたら、[表示] メニューの [デバッグ] を選択して、クライアントの [パケット キャプチャ] セクションを起動します。

4. [パケット キャプチャ] からキャプチャ デバイスを選択します。 これは、サーバー側で選択されたサポート デバイスである必要があります。

5. クライアントを起動した後に実行されるテストを [ジョブ] から選択します。

6. すべてのオプションを選択したら、[開始] をクリックしてクライアントを起動します。

7. テストに対応するパケット キャプチャは、キャプチャ デバイスと共にサーバー上で生成されます。 ログは、次のログ サブフォルダーに記録されます。

   <NDISTestRootFolder>/logs/<AdapterName>/

クライアントで [パケット キャプチャ] セクションが表示されない場合のトラブルシューティング

[メッセージ センター] のユーザー インターフェイスが閉じていることを確認します。 NDISTest ユーザー インターフェイスが最大化されていない場合、[パケット キャプチャ] セクションが [メッセージ センター] のユーザー インターフェイスの背後に隠れている可能性があります。

ワイヤレス ルーター テストでの既知の問題

このヒントは、イーサネット接続を使用してより高いビット レートを送信するコンピューターの機能をテストする (つまり、マシンを検証する) のに役立ちます。

このテスト手順では、次の図に示すように 2 台のコンピューターをセットアップします。

1. イーサネット接続のみを使用して、ハードウェアを次のようにセットアップします

2. コンピューター S に静的 IP アドレスを割り当てます。

   例: 10.0.0.2

3. コンピューター C に静的 IP アドレスを割り当てます。

   例: 10.0.0.3

4. コンピューター C で、コマンド プロンプト ウィンドウを開き、次のコマンドを実行します。

   stats.exe -z DISCARD -i 20 -x 50 -y 30 -r 20000000 -c 3600 -l -h -u

5. コンピューター S で、コマンド プロンプト ウィンドウを開き、次のコマンドを実行します。

   stats.exe -d 10.0.0.3 -r 20000000 -c 4200 -l -h -u

6. 手順 4 と手順 5 の出力を確認します。

手順 4 または手順 5 の出力にエラーが表示された場合、コンピューターはワイヤレス アダプターを使用してビット レートを作成できません。

ワイヤレス プロファイルを手動で追加する必要がある場合、netsh コマンドを使用して追加できます。

たとえば、802_11a_wpa-psk.xml ワイヤレス プロファイルを追加するには、次の手順を行います。

1. [スタート]、[実行] の順にクリックし、cmd.exe と入力します。

2. 「netsh wlan add profile filename=802_11a_wpa-psk.xml i=\*」と入力します。

3. [OK] をクリックします。

注意

ワイヤレス プロファイル XML ファイルが現在のディレクトリに存在することを確認するか、完全なパスを指定します。

関連トピック

Device.Network テスト

Windows HLK のトラブルシューティング