Résolution des problèmes de test Device.Network

Résolution des problèmes de test Device.Network

Pour résoudre les problèmes qui se produisent avec les tests Device.Network, procédez comme suit :

1. Consultez Résolution des problèmes d’échecs de test Windows HLK.

   Passez en revue l’une des rubriques suivantes, en fonction du type de produit ou de fonctionnalité réseau que vous testez :

   • Configuration requise pour le test de déchargement de tâche IPsec v2

   • Conditions préalables au test lan

   • Conditions préalables au test du haut débit mobile

   • Conditions préalables au test de routeur (non sans fil)

   • Conditions préalables de test du réseau local sans fil (802.11)

   • Prérequis pour le test des routeurs sans fil

2. Consultez les notes de publication de Windows HLK pour connaître les problèmes de test actuels.

3. En cas d’échec de test, recherchez des informations utilisables dans le journal des tests Windows HLK Studio. Si vous trouvez des informations utilisables, résolvez le problème et réexécutez le test.

Problèmes de test IPsec connus

Si le contrôleur Windows HLK ne peut pas se connecter aux clients, procédez comme suit :

1. Le tout premier cas de test est conçu pour s’assurer que l’installation est correcte. Il ne fait rien d’autre que case activée le réseau public et privé pour la connectivité. Si ce test échoue, il existe un problème de configuration de test.

2. Vérifiez que le fichier config.dat est placé dans le répertoire %SystemDrive%\IPsecTestKit\IPsecScenario\ et dispose des adresses IP appropriées pour le contrôleur et les clients. Ce fichier est généré automatiquement, mais dans certains cas, par exemple, les échecs de résolution DNS, le fichier config.dat peut contenir des données incorrectes ou être manquant. Utilisez le format décrit dans la section Programme d’installation du test pour vérifier le fichier config.dat.

3. Vérifiez que vous disposez d’exemptions de pare-feu pour les IPsecControl.exe et les IPsecScenario.exe.

4. Vérifiez qu’après avoir exécuté les scripts d’installation, les interfaces IPsec Offload V2 sont correctement renommées en « Test1 ».

Genconfig_phase2.vbs ne peut pas générer les fichiers CMD nécessaires s’il n’existe que 1 passerelle par défaut pour l’adaptateur de message. Si votre serveur DHCP ne prend pas en charge IP V6, vous ne pouvez obtenir que 1 adresse de passerelle IP V6 par défaut.

Exécution de variantes de test individuelles

Dans certains cas, lorsque les tests échouent, exécutez une seule variante de test au lieu de réexécuter l’ensemble de la suite. Pour cela, procédez comme suit :

1. Assurez-vous que les sessions IPsecScenario.exe sont en cours d’exécution sur tous les clients.

2. Copiez des variantes individuelles à exécuter à partir de OffloadV2_logoTests.cmd et exécutez-les à partir d’une nouvelle fenêtre de commande (%SYSTEMDRIVE%\IPsecTestKit\IPSecscenario\Controller

Troubleshooting LAN (Ethernet) Testing

Le travail de test IPSec peut échouer en raison de problèmes liés aux travaux de test LAN associés. Pour plus d’informations, consultez la section suivante.

Problèmes de test LAN (Ethernet) connus

Problèmes connus de test de haut débit mobile

La liste suivante décrit quelques conseils de résolution des problèmes courants pour les tests à haut débit mobile :

Les modifications apportées aux appareils sur les ordinateurs clients DTM ne sont pas reflétées dans DTM Studio. Par exemple, l’ordinateur est censé être à l’état Prêt, mais ce n’est pas le cas.

1. Ouvrez une fenêtre d’invite de commandes sur l’ordinateur client, puis exécutez net stop wttsvc.

2. Exécutez net start wttsvc. Cette commande met à jour le répertoire C:\wtt\JobsWorkingDir\AssetCfg\Log\.

3. Actualisez la fenêtre Console de l’appareil dans DTM Studio. Plusieurs minutes peuvent être nécessaires pour que le contrôleur DTM interroge l’ordinateur client pour connaître les modifications apportées à sa liste d’appareils.

Les ordinateurs n’ont pas été découverts pour le pool de machines.

1. Ouvrez la fenêtre Moniteur de travaux dans DTM Studio.

2. Cliquez sur le bouton Afficher le Générateur de requêtes en haut de l’écran.

3. Cliquez sur l’onglet Requête de l’ordinateur .

4. Définissez les paramètres de recherche pour les ordinateurs ciblés. En règle générale, définissez une règle unique telle que « DataStore est égal à « Nom du contrôleur ».

5. Cliquez avec le bouton droit sur la règle qui vient d’être définie, puis cliquez sur Exécuter. Une liste complète d’ordinateurs remplit la liste machines sous les champs de requête.

6. Faites glisser les machines de la liste Machines dans le nouveau pool d’ordinateurs créé.

Les ordinateurs ne semblent pas exécuter de travaux planifiés pour eux.

1. Ouvrez la fenêtre Moniteur de travaux dans DTM Studio.

2. Sous l’onglet Pool d’ordinateurs , sélectionnez le pool d’ordinateurs qui est censé exécuter des travaux.

3. Pour chaque ordinateur de ce pool, vérifiez que son status est Prêt.

4. Si le status d’un ordinateur n’est pas Prêt, cliquez avec le bouton droit sur l’ordinateur, pointez sur Modifier l’état, puis cliquez sur Réinitialiser.

5. Après quelques minutes, actualisez l’écran et le status passe à Prêt.

6. Planifiez et recommencez les travaux.

Prérequis connus pour les tests logiciels de sécurité réseau

Les tests logiciels de sécurité réseau (TransitionTechnologies_Tests et WindowsFilteringPlatform_Tests) nécessitent que les pilotes miniport Sparta soient installés et configurés correctement. Les pilotes miniport Sparta sont installés à chaque exécution de test. Toutefois, si vous le souhaitez, vous pouvez vérifier qu’ils sont présents en ouvrant une invite de commandes et en tapant IPConfig.exe /all. Vous devriez voir quatre nouvelles interfaces sparta nommées Sparta Miniport Primary, Sparta Miniport Secondary, Sparta Miniport Tertiaire et Sparta Miniport Quaternary.

Problèmes de test de routeur connus

Actuellement, il n’existe aucun problème de test de routeur connu.

Problèmes de test lan sans fil connus (802.11)

La liste suivante décrit quelques conseils de dépannage courants pour les tests WLAN :

Les modifications que vous avez apportées aux appareils sur les ordinateurs clients DTM ne sont pas répercutées dans DTM Studio. Par exemple, la machine est censée être à l’état Prêt, mais ce n’est pas le cas.

1. Ouvrez une fenêtre d’invite de commandes sur l’ordinateur client, puis exécutez net stop wttsvc.

2. Exécutez net start wttsvc. Cette commande met à jour le répertoire C:\wtt\JobsWorkingDir\AssetCfg\Log\.

3. Actualisez la fenêtre Console de l’appareil dans DTM Studio. Vous devrez peut-être attendre plusieurs minutes pour que le contrôleur DTM interroge la machine cliente pour connaître les modifications apportées à sa liste d’appareils.

Les machines n’ont pas été découvertes pour le pool de machines.

1. Ouvrez la fenêtre Moniteur de travaux dans DTM Studio.

2. Sélectionnez le bouton Afficher le Générateur de requêtes en haut de l’écran.

3. Cliquez sur l’onglet Requête de l’ordinateur .

4. Définissez des paramètres de recherche pour les machines que vous recherchez. En règle générale, vous pouvez définir une règle unique telle que « DataStore est égal à 'Nom du contrôleur' ».

5. Cliquez avec le bouton droit sur la règle que vous venez de définir, puis cliquez sur Exécuter. Une liste complète de machines doit remplir la liste Machines sous les champs de requête que vous avez définis.

6. Faites glisser les machines de la liste Machines dans les nouveaux pools d’ordinateurs que vous avez créés.

Les machines ne semblent pas exécuter de travaux planifiés pour eux.

1. Ouvrez la fenêtre Moniteur de travaux dans DTM Studio.

2. Sous l’onglet Pool d’ordinateurs , sélectionnez le pool d’ordinateurs que vous prévoyez d’exécuter des travaux.

3. Pour chaque machine de ce pool, vérifiez que son status est Prêt.

4. Si le status d’un ordinateur n’est pas Prêt, cliquez avec le bouton droit sur l’ordinateur, pointez sur Modifier l’état, puis cliquez sur Réinitialiser.

5. Après quelques minutes, actualisez l’écran et le status passe à Prêt.

6. Planifiez et recommencez les travaux.

Problèmes liés à l’installation du pilote Test SoftAP sur la topologie : Gestionnaire de périphériques signale le code 52

N’installez pas le pilote SoftAP test x64 avant d’installer le client DTM. Lorsque le client DTM est installé, le certificat racine est installé. Étant donné que la signature du pilote SoftAP de test dépend de l’installation du certificat racine, le gestionnaire de périphériques signale le code de périphérique 52.

Configuration de NDISTest pour une exécution autonome

L’installation de NDISTest séparément de DTM Studio vous permet d’exécuter des tests individuels. Un SOFTAP DUT, SUT et Test doit être configuré pour permettre l’exécution autonome.

Configuration d’un appareil de support en cours de test (SUT)

1. Copiez tous les fichiers binaires et sous-répertoires NDISTest à partir du contrôleur DTM suivant :

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

   <ControllerMachine> est le nom de l’ordinateur du contrôleur DTM et <l’architecture> est x86 (pour les processeurs x86) ou amd64 (pour les processeurs x64).

2. Lancez NDISTest.exe à partir du répertoire d’installation. Lorsque le formulaire main s’ouvre, sélectionnez Serveur dans le menu Fichier pour lancer le formulaire de serveur.

3. Sélectionnez l’appareil de messagerie dans la liste Appareil message . Cet appareil doit être activé sur IP et sur le même sous-réseau que l’appareil de message client qui sera configuré ultérieurement.

4. Sélectionnez appareils SUT dans Appareils de support. L’appareil de support sélectionné sur ce serveur à partir de sera visible par le client une fois le serveur démarré.

5. Sélectionnez le travail « serveur » dans Travaux. Il s’agit du test côté serveur qui sera lancé après avoir cliqué sur le bouton Démarrer.

Une fois toutes les options sélectionnées, cliquez sur Démarrer pour démarrer le serveur.

Configuration d’un point d’accès logiciel de test (Test SoftAP)

1. Copiez tous les fichiers binaires et sous-répertoires NDISTest à partir du contrôleur DTM suivant :

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

   <ControllerMachine> est le nom de l’ordinateur du contrôleur DTM et <l’architecture> est x86 (pour les processeurs x86) ou amd64 (pour les processeurs x64).

2. Installez le pilote SoftAP pour les deux appareils Atheros WLAN sur test SoftAP. Vous pouvez installer ce pilote à partir de Gestionnaire de périphériques, que vous pouvez ouvrir en exécutant devmgmt.msc à partir d’une invite de commandes. Effectuez l’étape suivante :

   Dans Gestionnaire de périphériques, installez le pilote pour les stations SoftAP à partir de :

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

   <ControllerMachine> est le nom de l’ordinateur du contrôleur DTM et <l’architecture> est x86 (pour les processeurs x86) ou amd64 (pour les processeurs x64), selon l’architecture du processeur de la machine cliente DTM qui a les périphériques SoftAP.

3. Lancez NDISTest.exe à partir du répertoire d’installation. Lorsque le formulaire main s’ouvre, sélectionnez Serveur dans le menu Fichier pour lancer le formulaire de serveur.

4. Sélectionnez l’appareil de messagerie dans la liste Appareil message . Cet appareil doit être un appareil avec ip et se trouver sur le même sous-réseau que l’appareil de messagerie client qui sera configuré ultérieurement.

5. Sélectionnez le ou les appareils AP dans Appareils AP. Les appareils AP sélectionnés sur ce serveur seront visibles par le client une fois le serveur démarré.

6. Sélectionnez le travail « serveur » dans Travaux. Il s’agit du test côté serveur qui sera lancé après avoir cliqué sur le bouton Démarrer.

Une fois toutes les options sélectionnées, cliquez sur Démarrer pour démarrer le serveur.

Configuration de l’appareil testé (DUT)

1. Copiez tous les fichiers binaires et sous-répertoires NDISTest à partir du contrôleur DTM suivant :

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

   <ControllerMachine> est le nom de l’ordinateur du contrôleur DTM et <l’architecture> est x86 (pour les processeurs x86) ou amd64 (pour les processeurs x64).

2. Lancez NDISTest.exe à partir du répertoire d’installation. Lorsque le formulaire main s’ouvre, sélectionnez Client dans le menu Fichier pour lancer le formulaire client.

3. Sélectionnez la cible de test dans la liste Cible de test . Pour le périphérique réseau, cette cible de test doit être Miniport.

4. Sélectionnez l’appareil de test dans la liste Appareil de test . Il doit s’agir d’un appareil de test spécifique au fournisseur.

5. Sélectionnez un appareil de message dans la liste Appareil message . Il doit s’agir d’un appareil ip qui se trouve sur le même sous-réseau que l’appareil de message du serveur. Une fois l’appareil de message sélectionné, la section Appareil AP doit s’afficher et l’appareil AP serveur doit être disponible dans la liste.

6. Sélectionnez un appareil de support dans Appareils de support. Il doit s’agir d’un appareil de support propre au fournisseur.

7. Sélectionnez un appareil AP dans Appareils AP. Il doit s’agir de l’appareil AP qui a été sélectionné côté serveur.

8. Sélectionnez les tests dans la section Travaux qui seront exécutés après le lancement du client.

Une fois toutes les options sélectionnées, cliquez sur Démarrer pour démarrer le client. Tous les travaux sélectionnés commencent à être exécutés. Les résultats des tests seront stockés sur le client dans le sous-dossier de journalisation suivant :

<NDISTestRootFolder>/logs/<AdapterName>/

Configuration de la capture de paquets client

1. Configurez une topologie de test pour une exécution autonome. Pour plus d’informations, accédez à « Configuration de NDISTest pour l’exécution autonome ».

2. Configurez un deuxième SUT. Pour plus d’informations, accédez à « Configuration d’un appareil de support sous test (SUT) ».

3. Lancez NDISTest.exe à partir du répertoire d’installation. Lorsque le formulaire main s’ouvre, sélectionnez Déboguer dans le menu Affichage pour lancer la section Capture de paquets sur le client.

4. Sélectionnez un périphérique de capture dans Capture de paquets. Il doit s’agir d’un appareil de support qui a été sélectionné côté serveur.

5. Dans Travaux, sélectionnez les tests qui seront exécutés après le lancement du client.

6. Une fois toutes les options sélectionnées, cliquez sur Démarrer pour démarrer le client.

7. Les captures de paquets correspondant aux tests sont générées sur le serveur avec l’appareil de capture. Les journaux se trouveront dans le sous-dossier de journalisation suivant :

   <NDISTestRootFolder>/logs/<AdapterName>/

Résolution des problèmes lorsque la section Capture de paquets n’apparaît pas sur le client

Vérifiez que l’interface utilisateur du centre de messages est fermée. Si l’interface utilisateur NDISTest n’est pas agrandie, la section Capture de paquets peut être masquée derrière l’interface utilisateur du centre de messages.

Problèmes connus de test de routeur sans fil

Ce conseil vous aidera à tester la capacité de la machine à envoyer des débits binaires plus élevés à l’aide d’une connexion Ethernet (c’est-à-dire, valide la machine).

Pour cette procédure de test, configurez deux ordinateurs, comme indiqué dans le diagramme suivant :

1. Configurer le matériel comme indiqué ci-dessous avec une connexion Ethernet uniquement

2. Attribuez une adresse IP statique à l’ordinateur S.

   Par exemple : 10.0.0.2

3. Attribuez une adresse IP statique à l’ordinateur C.

   Par exemple : 10.0.0.3

4. Sur la machine C, ouvrez une invite de commandes et exécutez la commande suivante :

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

5. Sur la machine S, ouvrez une invite de commandes et exécutez la commande suivante :

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

6. Passez en revue la sortie des étapes 4 et 5.

Si la sortie de l’étape 4 ou de l’étape 5 montre des échecs, vos ordinateurs ne peuvent pas effectuer de débits binaires à l’aide d’adaptateurs sans fil.

Si vous devez ajouter manuellement un profil sans fil, vous pouvez le faire à l’aide de la commande netsh.

Par exemple : pour ajouter le profil sans fil 802_11a_wpa-psk.xml :

1. Cliquez sur Démarrer, sur Exécuter, puis entrez cmd.exe.

2. Type netsh wlan add profile filename=802_11a_wpa-psk.xml i=\*

3. Cliquez sur OK.

Rubriques connexes

Test device.network

Résolution des problèmes de Windows HLK