Risoluzione dei problemi relativi ai test di Device.Network
Risoluzione dei problemi relativi ai test di Device.Network
Per risolvere i problemi che si verificano con i test di Device.Network, seguire questa procedura:
Esaminare la risoluzione dei problemi relativi ai test di Windows HLK.
Esaminare uno degli argomenti seguenti, a seconda del tipo di prodotto o funzionalità di rete che si sta testando:
Esaminare le note sulla versione di Windows HLK per i problemi di test correnti.
Per un errore di test, cercare informazioni utilizzabili nel log di test di Windows HLK Studio. Se si trovano informazioni utilizzabili, risolvere il problema ed eseguire nuovamente il test.
Problemi noti di test IPsec
Se windows HLK Controller non è in grado di connettersi ai client, seguire questa procedura:
Il primo test case è progettato per garantire che la configurazione sia corretta. Non fa nulla, ma controlla la rete pubblica e privata per la connettività. Se questo test ha esito negativo, si verifica un problema di configurazione del test.
Verificare che il file config.dat sia inserito nella directory %SystemDrive%\IPsecTestKit\IPsecScenario\ e abbia gli indirizzi IP corretti per il controller e i client. Questo file viene generato automaticamente, ma in alcuni casi, ad esempio errori di risoluzione DNS, il file config.dat può contenere dati non corretti o essere mancanti completamente. Usare il formato descritto nella sezione Configurazione test per verificare il file config.dat.
Verificare di avere esenzioni del firewall per IPsecControl.exe e IPsecScenario.exe.
Verificare che dopo l'esecuzione degli script di installazione, le interfacce IPsec Offload V2 vengano rinominate correttamente in "Test1".
Genconfig_phase2.vbs potrebbe non generare i file CMD necessari se è presente solo 1 gateway predefinito per l'adapter di messaggi. Se il server DHCP non supporta IP V6, è possibile ottenere solo 1 indirizzo gateway predefinito IP V6.
Esecuzione di singole varianti di test
In alcuni casi quando i test hanno esito negativo, eseguire una singola variazione di test anziché eseguire nuovamente l'intera suite. A questo scopo, seguire questa procedura:
Assicurarsi che le sessioni di IPsecScenario.exe siano in esecuzione su tutti i client.
Copiare singole varianti da eseguire da OffloadV2_logoTests.cmd ed eseguirle da una nuova finestra di comando (%SYSTEMDRIVE%\IPsecTestKit\IPSecscenario\Controller
Troubleshooting LAN (Ethernet) Testing
Il processo di test IPSec potrebbe non riuscire a causa di problemi relativi ai processi di test LAN correlati. Per informazioni dettagliate, vedere la sezione seguente.
Problemi di test di LAN (Ethernet) noti
| Problema | Dettagli |
|---|---|
I processi di test "IPsec Offloadv2 (Win7)" rimangono nello stato "Scheduler" e non vengono mai eseguiti. |
Questo problema è in genere causato da vari problemi di comunicazione tra il client DTM e il controller. È possibile verificare se l'ora dell'ultimo heartbeat è vicina all'ora corrente. Per forzare il client DTM che segnala un heartbeat, è possibile modificare manualmente lo stato del computer in Reimpostazione o Unsafe in DTM Studio e quindi attendere fino a quando lo stato del computer non viene modificato in "Normal". Dopo aver modificato lo stato di tutti i computer necessari per eseguire il processo in Normale, il processo verrà pianificato nei client DTM. Se lo stato del computer viene modificato in Debug, verificare se il computer client DTM è ancora reattivo. A volte, lo stato del computer è Normale e l'heartbeat è corretto, ma il processo non verrà ancora eseguito. Questo è probabilmente causato dal firewall o IPsec bloccando la comunicazione tra il client DTM e il controller. Assicurarsi che il client e il controller DTM abbiano la stessa configurazione IPsec. Se il client ha attivato IPsec, ma il controller è disattivato o viceversa, il processo non verrà pianificato. Il client DTM è progettato per lavorare con un firewall, ma a volte il firewall blocca il normale traffico tra il client e il controller. |
Il messaggio di errore seguente è osservatore nel log di test: "Il processo xxx richiede l'selezione di un dispositivo, non un driver" quando si fa clic su "Aggiungi informazioni". |
L'errore si verifica perché è stato selezionato un driver, non un dispositivo di test, nella console del dispositivo per eseguire il processo di test. Se non è possibile trovare un dispositivo sotto il driver nella console del dispositivo, i file INF e i file driver forniti durante l'invio del logo non corrispondono ai file INF effettivi e ai file driver nel client DTM. Aggiornare i file INF e i file driver usando il file INF effettivo e i file driver installati nel client DTM. |
Nessun processo di verifica del logo IPsec Offloadv2 (Win7)" viene visualizzato nella "Console del dispositivo". |
Assicurarsi che il dispositivo sia un dispositivo Ethernet (LAN) e un tipo di supporto di report su NDIS come NdisMedium802_3. Questo errore si verifica a volte quando le informazioni hardware segnalate dal client DTM sono incomplete. Per risolvere questo problema, provare a riavviare il computer client DTM e aggiornare la visualizzazione della console del dispositivo. Se non funziona, provare a arrestare e riavviare il servizio "wttsvc" nel client DTM e quindi aggiornare la visualizzazione della console del dispositivo. |
Il test Ethernet - NDISTest 6.0 (priorità) potrebbe non riuscire correttamente i pacchetti 2c_priority e Directed Packets - NdisSendPackets con un'asserzione Unable to get test risultati nel messaggio della scheda di rete di test . |
Questo problema può verificarsi quando il commutatore di rete striscia erroneamente i bit di priorità. Per verificare che questo problema si verifichi a causa del commutatore di rete, testare l'adattatore rimuovendo l'interruttore e connettendo direttamente i cavi. È possibile eseguire questa operazione usando una configurazione di test alternativa. Questa configurazione di test può essere usata solo dai dispositivi che non supportano Chimney, (TCP Offload) perché il dispositivo di supporto locale è necessario per tali dispositivi. Rimuovere completamente il dispositivo di supporto locale e testare il commutatore di rete e connettere il dispositivo di test locale direttamente al back-to-back con il dispositivo di supporto remoto. Se si tratta del passaggio, questo è accettabile per la certificazione, ma collaborare con il produttore del commutatore per correggere la configurazione del commutatore. |
I dispositivi Ethernet - NDISTest 6.5 (WoL e PM) potrebbero non riuscire correttamente all'interno dell'asserzione di pacchetto di rete Send a FAKE LLMNRv4 con un errore che indica che il computer funziona in modo errato. |
Per determinare se il dispositivo ha esito negativo correttamente, scollegare solo i protocolli nel dispositivo remoto. Se questo problema non viene risolto, aprire un evento imprevisto di supporto |
Nota
Per risolvere i problemi relativi a NDISTest (6.0 o 6.5), collegare un debugger al computer di test.
Problemi noti relativi ai test a banda larga mobile
L'elenco seguente descrive alcuni suggerimenti comuni per la risoluzione dei problemi per i test di Mobile Broadband:
Le modifiche apportate ai dispositivi nei computer client DTM non vengono riflesse in DTM Studio. Ad esempio, il computer deve trovarsi nello stato Pronto, ma non è.
Aprire una finestra del prompt dei comandi nel computer client e quindi eseguire
net stop wttsvc.Eseguire
net start wttsvc. Questo comando aggiorna la directory C:\wtt\JobsWorkingDir\AssetCfg\Log\.Aggiornare la finestra Console del dispositivo in DTM Studio. Potrebbe richiedere diversi minuti per il controller DTM per eseguire il polling del computer client per le modifiche nell'elenco dei dispositivi.
I computer non sono stati individuati per il pool di computer.
Aprire la finestra Monitoraggio processi in DTM Studio.
Fare clic sul pulsante Mostra Generatore query nella parte superiore della schermata.
Fare clic sulla scheda Query computer .
Definire i parametri di ricerca per i computer di destinazione. In genere, impostare una singola regola, ad esempio "DataStore è uguale al nome del controller".
Fare clic con il pulsante destro del mouse sulla regola appena definita e quindi scegliere Esegui. Un elenco completo di computer popola l'elenco Computer sotto i campi di query.
Trascinare tutti i computer nell'elenco Computer nel nuovo pool di computer creato.
I computer non sembrano eseguire processi pianificati.
Aprire la finestra Monitoraggio processi in DTM Studio.
Nella scheda Pool di computer selezionare il pool di computer previsto per l'esecuzione dei processi.
Per ogni computer in tale pool, verificare che lo stato sia Pronto.
Se lo stato di un computer non è Pronto, fare clic con il pulsante destro del mouse sul computer, scegliere Modifica stato e quindi fare clic su Reimposta.
Dopo alcuni minuti, aggiornare la schermata e lo stato cambia in Pronto.
Pianificare e avviare di nuovo i processi.
Prerequisiti noti per il test software di sicurezza di rete
I test software di sicurezza di rete (TransitionTechnologies_Tests e WindowsFilteringPlatform_Tests) richiedono che i driver miniport di Sparta siano installati e configurati correttamente. I driver miniport di Sparta vengono installati quando ogni esecuzione di test, tuttavia, se si sceglie di, è possibile verificare che siano presenti aprendo un prompt dei comandi e digitando IPConfig.exe /all. Dovrebbero essere visualizzate quattro nuove interfacce di Sparta denominate Sparta Miniport Primary, Sparta Miniport Secondary, Sparta Miniport Terziario e Sparta Miniport Quaternary.
Problemi noti di test del router
Attualmente non sono presenti problemi di test del router noti.
Problemi di test della lan wireless noti (802.11)
L'elenco seguente descrive alcuni suggerimenti comuni per la risoluzione dei problemi per i test WLAN:
Le modifiche apportate ai dispositivi nei computer client DTM non vengono riflesse in DTM Studio. Ad esempio, il computer deve trovarsi nello stato Pronto, ma non è.
Aprire una finestra del prompt dei comandi nel computer client e quindi eseguire
net stop wttsvc.Eseguire
net start wttsvc. Questo comando aggiornerà la directory C:\wtt\JobsWorkingDir\AssetCfg\Log\ .Aggiornare la finestra Console del dispositivo in DTM Studio. Potrebbe essere necessario attendere diversi minuti per il controller DTM per eseguire il polling del computer client per le modifiche nell'elenco dei dispositivi.
I computer non sono stati individuati per il pool di computer.
Aprire la finestra Monitoraggio processi in DTM Studio.
Selezionare il pulsante Mostra Generatore query nella parte superiore della schermata.
Fare clic sulla scheda Query computer .
Definire i parametri di ricerca per i computer da cercare. In genere, è possibile impostare una singola regola, ad esempio "DataStore uguale al nome del controller".
Fare clic con il pulsante destro del mouse sulla regola appena definita e quindi scegliere Esegui. Un elenco completo di computer deve popolare l'elenco Computer sotto i campi di query definiti.
Trascinare tutti i computer nell'elenco Computer in nuovi pool di computer creati.
I computer non sembrano eseguire processi pianificati.
Aprire la finestra Monitoraggio processi in DTM Studio.
Nella scheda Pool di computer selezionare il pool di computer che si prevede di eseguire processi.
Per ogni computer in tale pool, verificare che lo stato sia Pronto.
Se lo stato di un computer non è Pronto, fare clic con il pulsante destro del mouse sul computer, scegliere Modifica stato e quindi fare clic su Reimposta.
Dopo alcuni minuti, aggiornare la schermata e lo stato verrà modificato in Pronto.
Pianificare e avviare di nuovo i processi.
Problemi con l'installazione del driver Test SoftAP nella topologia: Gestione dispositivi segnala il codice 52
Non installare il driver SoftAP test x64 prima di installare il client DTM. Quando il client DTM è installato, viene installato il certificato radice. Poiché la firma del driver SoftAP test dipende dall'installazione del certificato radice, gestione dispositivi segnala il codice del dispositivo 52.
Configurazione di NDISTest per l'esecuzione autonoma
L'installazione di NDISTest separata da DTM Studio consente di eseguire singoli test. Un DUT, SUT e Test SoftAP deve essere configurato per abilitare l'esecuzione autonoma.
Nota
Tutti i computer di test devono usare la stessa architettura del processore.
Nota
Per risolvere i problemi relativi a NDISTest, provare a collegare un debugger al computer di test.
Configurazione di un dispositivo di supporto in fase di test (SUT)
Copiare tutti i file binari e le sotto directory di NDISTest dal controller DTM seguente:
\\<ControllerMachine]>\tests\<architecture>\nttest\nettest\ndis\ndistest.net\<ControllerMachine> è il nome del computer controller DTM e <dell'architettura> è x86 (per processori basati su x86) o amd64 (per processori basati su x64).
Avviare NDISTest.exe dalla directory di installazione. Quando si apre il modulo principale, selezionare Server dal menu File per avviare il modulo del server.
Selezionare il dispositivo messaggio dall'elenco Dispositivo messaggio . Questo dispositivo deve essere abilitato per IP e nella stessa subnet del dispositivo del messaggio client che verrà configurato in un secondo momento.
Selezionare DISPOSITIVI SUT da Dispositivi di supporto. Il dispositivo di supporto selezionato in questo server sarà visibile al client dopo l'avvio del server.
Selezionare il processo "server" da Processi. Si tratta del test lato server che verrà avviato dopo aver fatto clic sul pulsante start.
Dopo aver selezionato tutte le opzioni, fare clic su Avvia per avviare il server.
Configurazione di un punto di accesso software di test (Test SoftAP)
Copiare tutti i file binari e le sotto directory di NDISTest dal controller DTM seguente:
\\<ControllerMachine]>\tests\<architecture>\nttest\nettest\ndis\ndistest.net\<ControllerMachine> è il nome del computer controller DTM e <dell'architettura> è x86 (per processori basati su x86) o amd64 (per processori basati su x64).
Installare il driver SoftAP per entrambi i dispositivi WLAN Atheros nel Test SoftAP. È possibile installare questo driver da Gestione dispositivi, che è possibile aprire eseguendo
devmgmt.mscda un prompt dei comandi. Completare il passaggio seguente:In Gestione dispositivi installare il driver per le stazioni SoftAP da:
\\<ControllerMachine]>\Tests\<architecture>\nttest\nettest\ndis\NDISTest.net\SoftAPMiniport\<ControllerMachine> è il nome del computer controller DTM e <dell'architettura è x86 (per processori basati su x86) o amd64 (per processori basati su x64), a seconda dell'architettura> del processore del computer client DTM che dispone dei dispositivi SoftAP.
Avviare NDISTest.exe dalla directory di installazione. Quando si apre il modulo principale, selezionare Server dal menu File per avviare il modulo del server.
Selezionare il dispositivo messaggio dall'elenco Dispositivo messaggio . Questo dispositivo deve essere abilitato per IP e nella stessa subnet del dispositivo del messaggio client che verrà configurato in un secondo momento.
Selezionare i dispositivi API da Dispositivi API. I dispositivi API selezionati in questo server saranno visibili al client dopo l'avvio del server.
Selezionare il processo "server" da Processi. Si tratta del test lato server che verrà avviato dopo aver fatto clic sul pulsante start.
Dopo aver selezionato tutte le opzioni, fare clic su Avvia per avviare il server.
Configurazione del dispositivo in test (DUT)
Copiare tutti i file binari e le sotto directory di NDISTest dal controller DTM seguente:
\\<ControllerMachine>\tests\<architecture>\nttest\nettest\ndis\ndistest.net\<ControllerMachine> è il nome del computer controller DTM e <dell'architettura> è x86 (per processori basati su x86) o amd64 (per processori basati su x64).
Avviare NDISTest.exe dalla directory di installazione. Quando si apre il modulo principale, selezionare Client dal menu File per avviare il modulo client.
Selezionare la destinazione di test dall'elenco Destinazione test . Per il dispositivo di rete, questa destinazione di test deve essere Miniport.
Selezionare il dispositivo di test dall'elenco Dispositivo di test. Questo deve essere un dispositivo di test specifico del fornitore.
Selezionare un dispositivo messaggio dall'elenco Dispositivo messaggio . Deve trattarsi di un dispositivo abilitato per l'IP nella stessa subnet del dispositivo del messaggio del server. Dopo aver selezionato il dispositivo messaggio, la sezione del dispositivo AP deve essere visualizzata e il dispositivo API del server deve essere disponibile nell'elenco.
Selezionare un dispositivo di supporto da Dispositivi di supporto. Questo deve essere un dispositivo di supporto specifico del fornitore.
Selezionare un dispositivo AP da Dispositivi AP. Questo deve essere il dispositivo AP selezionato sul lato server.
Selezionare i test nella sezione Processi che verranno eseguiti dopo l'avvio del client.
Dopo aver selezionato tutte le opzioni, fare clic su Avvia per avviare il client. Tutti i processi selezionati inizieranno l'esecuzione. I risultati dei test verranno archiviati nel client nella sottocartella di registrazione seguente:
<NDISTestRootFolder>/logs/<AdapterName>/
Configurazione dell'acquisizione di pacchetti client
Configurare una topologia di test per l'esecuzione autonoma. Per altre informazioni, passare a "Configurazione di NDISTest per l'esecuzione autonoma".
Configurare un secondo SUT. Per altre informazioni, passare a "Configurazione di un dispositivo di supporto in test (SUT)."
Avviare NDISTest.exe dalla directory di installazione. Quando si apre il modulo principale, selezionare Debug dal menu Visualizza per avviare la sezione Acquisizione pacchetti nel client.
Selezionare un dispositivo Di acquisizione da Acquisizione pacchetti. Questo deve essere un dispositivo di supporto selezionato sul lato server.
In Processi selezionare i test che verranno eseguiti dopo l'avvio del client.
Dopo aver selezionato tutte le opzioni, fare clic su Avvia per avviare il client.
Le acquisizioni di pacchetti corrispondenti ai test verranno generate nel server con il dispositivo di acquisizione. I log saranno presenti nella sottocartella di registrazione seguente:
<NDISTestRootFolder>/logs/<AdapterName>/
Risoluzione dei problemi quando la sezione Acquisizione pacchetti non viene visualizzata nel client
Verificare che l'interfaccia utente del Centro messaggi sia chiusa. Se l'interfaccia utente NDISTest non è ingrandita, la sezione Acquisizione pacchetti potrebbe essere nascosta dietro l'interfaccia utente del Centro messaggi.
Problemi noti di test del router wireless
Questo suggerimento ti aiuterà a testare la capacità di inviare velocità di bit più elevate tramite la connessione Ethernet (ad esempio convalida il computer).
Per questa procedura di test, configurare due computer come illustrato nel diagramma seguente:
Configurare l'hardware come illustrato di seguito con solo la connessione Ethernet
Assegnare un indirizzo IP statico al computer S.
Ad esempio: 10.0.0.2
Assegnare un indirizzo IP statico al computer C.
Ad esempio: 10.0.0.3
Nel computer C aprire un prompt dei comandi ed eseguire il comando seguente:
stats.exe -z DISCARD -i 20 -x 50 -y 30 -r 20000000 -c 3600 -l -h -uNel computer S aprire un prompt dei comandi ed eseguire il comando seguente:
stats.exe -d 10.0.0.3 -r 20000000 -c 4200 -l -h -u
Esaminare l'output del passaggio 4 e del passaggio 5.
Se l'output del passaggio 4 o del passaggio 5 mostra eventuali errori, i computer non possono effettuare velocità di bit usando schede wireless.
Se è necessario aggiungere manualmente un profilo wireless, è possibile farlo usando il comando netsh.
Ad esempio: per aggiungere il profilo wireless 802_11a_wpa-psk.xml:
Fare clic su Start, fare clic su Esegui e immettere cmd.exe.
Digitare netsh wlan add profile filename=802_11a_wpa-psk.xml i=\*
Fare clic su OK.
Nota
Assicurarsi che il file XML del profilo wireless esista nella directory corrente o specificare il percorso completo.