Solução de problemas de teste de device.network
Solução de problemas de teste de device.network
Para solucionar problemas que ocorrem com testes Device.Network, siga estas etapas:
Examine Solução de problemas de falhas de teste do Windows HLK.
Examine um dos seguintes tópicos, dependendo do tipo de produto ou recurso de rede que você está testando:
Examine as notas de versão do Windows HLK para obter problemas de teste atuais.
Para obter uma falha de teste, procure informações utilizáveis no log de teste do Windows HLK Studio. Se você encontrar informações utilizáveis, resolve o problema e execute novamente o teste.
Problemas conhecidos de teste do IPsec
Se o Controlador HLK do Windows não puder se conectar aos clientes, siga estas etapas:
O primeiro caso de teste foi projetado para garantir que a configuração esteja correta. Ele não faz nada além de marcar a rede pública e privada para conectividade. Se esse teste falhar, haverá um problema de configuração de teste.
Verifique se o arquivo config.dat está colocado no diretório %SystemDrive%\IPsecTestKit\IPsecScenario\ e se tem os endereços IP corretos para o controlador e os clientes. Esse arquivo é gerado automaticamente, mas em determinados casos, como falhas de resolução DNS, o arquivo config.dat pode conter dados incorretos ou estar completamente ausente. Use o formato descrito na seção Configuração de Teste para verificar o arquivo config.dat.
Verifique se você tem isenções de firewall para IPsecControl.exe e IPsecScenario.exe.
Verifique se, depois de executar os scripts de instalação, as interfaces IPsec Offload V2 são renomeada com êxito como "Test1".
Genconfig_phase2.vbs pode não gerar os arquivos CMD necessários se houver apenas 1 gateway padrão para o adaptador de mensagem. Se o servidor DHCP não der suporte ao IP V6, você poderá obter apenas um endereço de gateway padrão IP V6.
Executando variações de teste individuais
Em determinados casos, quando os testes falharem, execute uma única variação de teste em vez de executar novamente todo o pacote. Para fazer isso, execute estas etapas:
Verifique se as sessões IPsecScenario.exe estão em execução em todos os clientes.
Copie as variações individuais para executar em OffloadV2_logoTests.cmd e execute-as em uma nova janela de comando (%SYSTEMDRIVE%\IPsecTestKit\IPSecscenario\Controller
Troubleshooting LAN (Ethernet) Testing
O trabalho de teste do IPSec pode falhar devido a problemas com trabalhos de teste de LAN relacionados. Consulte a seção a seguir para obter detalhes.
Problemas conhecidos de teste de LAN (Ethernet)
Problema | Detalhes |
---|---|
Os trabalhos de teste "Verificação do logotipo do IPsec Offloadv2 (Win7)" permanecem no status "Agendador" e nunca são executados. |
Esse problema geralmente é causado por vários problemas de comunicação entre o cliente DTM e o controlador. Você pode marcar se a "Hora da Última Pulsação" está próxima da hora atual. Para forçar o cliente DTM que está relatando uma pulsação, você pode alterar manualmente o status do computador para Redefinir ou Não Seguro no DTM Studio e aguardar até que o status do computador seja alterado de volta para "Normal". Depois que o status de todos os computadores necessários para executar o trabalho for alterado para Normal, o trabalho será agendado nos clientes DTM. Se o computador status mudar para Depurar, verifique se o computador cliente DTM ainda está respondendo. Às vezes, o computador status é Normal e a pulsação está correta, mas o trabalho ainda não será executado. Isso provavelmente é causado pelo firewall ou IPsec que bloqueia a comunicação entre o cliente DTM e o controlador. Verifique se o cliente E o controlador DTM têm a mesma configuração IPsec. Se o cliente tiver o IPsec ativado, mas o controlador estiver desativado ou vice-versa, o trabalho não será agendado. O cliente DTM foi projetado para funcionar com um firewall, mas às vezes o firewall bloqueia o tráfego normal entre o cliente e o controlador. |
A seguinte mensagem de erro é observador no log de teste: "O trabalho xxx requer que um dispositivo seja selecionado, não um driver" ao clicar em "Adicionar Informações". |
O erro ocorre porque você selecionou um driver, não um dispositivo de teste, no Console do Dispositivo para executar o trabalho de teste. Se você não conseguir encontrar um dispositivo sob o driver no Console do Dispositivo, os arquivos INF e os arquivos de driver fornecidos durante o envio do logotipo não corresponderão aos arquivos de driver e arquivo INF reais no cliente DTM. Atualize seus arquivos de driver e arquivos INF usando os arquivos de driver e arquivo INF reais instalados no cliente DTM. |
Nenhum trabalho de "Verificação do logotipo do IPsec Offloadv2 (Win7)" aparece no "Console do Dispositivo". |
Verifique se o dispositivo é um dispositivo Ethernet (LAN) e informe o tipo de mídia para o NDIS como NdisMedium802_3. Esse erro ocorre às vezes quando as informações de hardware relatadas pelo cliente DTM estão incompletas. Para resolver esse problema, tente reinicializar o computador cliente DTM e atualizar a exibição do Console do Dispositivo. Se isso não funcionar, tente parar e reiniciar o serviço "wttsvc" no cliente DTM e atualize a exibição do Console do Dispositivo. |
O teste Ethernet – NDISTest 6.0 (prioridade) pode falhar corretamente na declaração 2c_priority e Pacotes Direcionados - NdisSendPackets com uma mensagem Não é possível obter resultados de teste na mensagem do adaptador de rede de teste . |
Esse problema pode ocorrer quando o comutador de rede remove incorretamente os bits de prioridade. Para confirmar que esse problema ocorre devido ao comutador de rede, teste o adaptador removendo o comutador e conectando os cabos diretamente. Você pode fazer isso usando uma configuração de teste alternativa. Essa configuração de teste só pode ser usada por dispositivos que não dão suporte ao Chimney, (Descarregamento TCP), pois o dispositivo de suporte local é necessário para esses dispositivos. Remova completamente o Dispositivo de Suporte Local e o Comutador de Rede de Teste e conecte o Dispositivo de Teste Local diretamente de costas para trás com o Dispositivo de Suporte Remoto. Se isso for aprovado, isso será aceitável para certificação, mas trabalhe com o fabricante da opção para corrigir a configuração da opção. |
A Ethernet – NDISTest 6.5 (WoL e PM) pode falhar corretamente em dispositivos dentro da declaração enviar um pacote de rede FALSO LLMNRv4 com um erro indicando que o computador está funcionando incorretamente. |
Para ajudar a determinar se o dispositivo está falhando corretamente, desvincula os protocolos somente no dispositivo remoto. Se isso não resolve o problema, abra um incidente de suporte |
Observação
Para solucionar problemas do NDISTest (6.0 ou 6.5), anexe um depurador ao computador de teste.
Problemas conhecidos de teste de banda larga móvel
A lista a seguir descreve algumas dicas comuns de solução de problemas para testes de Banda Larga Móvel:
As alterações feitas em dispositivos em computadores cliente DTM não são refletidas no DTM Studio. Por exemplo, espera-se que o computador esteja no estado Pronto, mas não está.
Abra uma janela do prompt de comando no computador cliente e execute
net stop wttsvc
.Execute
net start wttsvc
. Este comando atualiza o diretório C:\wtt\JobsWorkingDir\AssetCfg\Log\.Atualize a janela Console do Dispositivo no DTM Studio. Pode levar vários minutos para o Controlador DTM sondar o computador cliente quanto a alterações em sua lista de dispositivos.
Os computadores não foram descobertos para o pool de computadores.
Abra a janela Monitor do Trabalho no DTM Studio.
Clique no botão Mostrar Construtor de Consultas na parte superior da tela.
Clique na guia Consulta do Computador .
Defina parâmetros de pesquisa para os computadores de destino. Normalmente, defina uma única regra, como "DataStore é igual a 'Nome do Controlador'".
Clique com o botão direito do mouse na regra que acabou de ser definida e clique em Executar. Uma extensa lista de computadores preenche a lista Computadores abaixo dos campos de consulta.
Arraste todos os computadores na lista Computadores para o novo pool de computadores que foi criado.
Os computadores não parecem executar trabalhos agendados para eles.
Abra a janela Monitor do Trabalho no DTM Studio.
Na guia Pool de Computadores , selecione o pool de computadores que deverá estar executando trabalhos.
Para cada computador nesse pool, verifique se sua status está pronta.
Se o status de um computador não estiver Pronto, clique com o botão direito do mouse no computador, aponte para Alterar Status e clique em Redefinir.
Após alguns minutos, atualize a tela e o status muda para Pronto.
Agende e inicie os trabalhos novamente.
Pré-requisitos conhecidos de teste de software de segurança de rede
Os testes de software de segurança de rede (TransitionTechnologies_Tests e WindowsFilteringPlatform_Tests) exigem que os drivers de miniporto do Sparta sejam instalados e configurados corretamente. Os drivers de miniporto do Sparta são instalados quando cada teste é executado, no entanto, se você optar por, você pode verificar se eles estão presentes abrindo um prompt de comando e digitando IPConfig.exe /all. Você deverá ver quatro novas interfaces do Sparta chamadas Sparta Miniport Primary, Sparta Miniport Secondary, Sparta Miniport Tertiary e Sparta Miniport Quaternary.
Problemas conhecidos de teste do roteador
Atualmente, não há problemas conhecidos de teste de roteador.
Problemas conhecidos de teste de LAN sem fio (802.11)
A lista a seguir descreve algumas dicas comuns de solução de problemas para teste de WLAN:
As alterações feitas em dispositivos em computadores de clientes DTM não são refletidas no DTM Studio. Por exemplo, espera-se que o computador esteja no estado Pronto, mas não está.
Abra uma janela do Prompt de Comando no computador cliente e execute
net stop wttsvc.
Execute
net start wttsvc
. Esse comando atualizará o diretório C:\wtt\JobsWorkingDir\AssetCfg\Log\.Atualize a janela Console do Dispositivo no DTM Studio. Talvez seja necessário aguardar vários minutos para que o controlador DTM sondar o computador cliente em busca de alterações em sua lista de dispositivos.
Os computadores não foram descobertos para o pool de computadores.
Abra a janela Monitor de Trabalho no DTM Studio.
Selecione o botão Mostrar Construtor de Consultas na parte superior da tela.
Clique na guia Consulta do Computador .
Defina parâmetros de pesquisa para os computadores que você está procurando. Normalmente, você pode definir uma única regra, como "DataStore é igual a 'Nome do Controlador'".
Clique com o botão direito do mouse na regra que você acabou de definir e clique em Executar. Uma extensa lista de computadores deve preencher a lista Computadores abaixo dos campos de consulta que você definiu.
Arraste todos os computadores na lista Computadores para novos pools de computadores que você criou.
Os computadores não parecem executar trabalhos agendados para eles.
Abra a janela Monitor de Trabalho no DTM Studio.
Na guia Pool de Computadores , selecione o pool de computadores que você espera executar trabalhos.
Para cada computador nesse pool, verifique se o status está Pronto.
Se o status de um computador não estiver Pronto, clique com o botão direito do mouse no computador, aponte para Alterar Status e clique em Redefinir.
Após alguns minutos, atualize a tela e o status será alterado para Pronto.
Agende e inicie os trabalhos novamente.
Problemas com a instalação do driver SoftAP de teste na topologia: Gerenciador de Dispositivos relata o código 52
Não instale o driver SoftAP de teste x64 antes de instalar o cliente DTM. Quando o cliente DTM é instalado, o Certificado Raiz é instalado. Como a assinatura do driver SoftAP de teste depende da instalação do Certificado Raiz, o gerenciador de dispositivos relata o código do dispositivo 52.
Configurando o NDISTest para execução autônoma
Instalar o NDISTest separado do DTM Studio permite executar testes individuais. Um DUT, SUT e SoftAP de teste precisam ser configurados para habilitar a execução autônoma.
Observação
Todos os computadores de teste devem usar a mesma arquitetura de processador.
Observação
Para solucionar problemas do NDISTest, tente anexar um depurador ao computador de teste.
Configurando um dispositivo de suporte em teste (SUT)
Copie todos os binários e subdiretórios do NDISTest do seguinte controlador DTM:
\\<ControllerMachine]>\tests\<architecture>\nttest\nettest\ndis\ndistest.net\
<ControllerMachine> é o nome do computador controlador DTM e <a arquitetura> é x86 (para processadores baseados em x86) ou amd64 (para processadores baseados em x64).
Inicie NDISTest.exe do diretório de instalação. Quando o formulário main for aberto, selecione Servidor no menu Arquivo para iniciar o formulário do servidor.
Selecione o dispositivo de mensagem na lista Dispositivo de Mensagem . Esse dispositivo deve ser habilitado para IP e na mesma sub-rede que o dispositivo de mensagem do cliente que será configurado posteriormente.
Selecione Dispositivos SUT em Dispositivos de Suporte. O dispositivo de suporte selecionado neste servidor de ficará visível para o cliente depois que o servidor for iniciado.
Selecione o trabalho "servidor" em Trabalhos. Este é o teste do lado do servidor que será iniciado depois que você clicar no botão Iniciar.
Depois que todas as opções tiverem sido selecionadas, clique em Iniciar para iniciar o servidor.
Configurando um ponto de acesso de software de teste (SoftAP de teste)
Copie todos os binários e subdiretórios do NDISTest do seguinte controlador DTM:
\\<ControllerMachine]>\tests\<architecture>\nttest\nettest\ndis\ndistest.net\
<ControllerMachine> é o nome do computador controlador DTM e <a arquitetura> é x86 (para processadores baseados em x86) ou amd64 (para processadores baseados em x64).
Instale o driver SoftAP para ambos os dispositivos Atheros WLAN no SoftAP de teste. Você pode instalar esse driver do Gerenciador de Dispositivos, que pode ser aberto executando
devmgmt.msc
em um prompt de comando. Conclua a seguinte etapa:Em Gerenciador de Dispositivos, instale o driver para estações SoftAP de:
\\<ControllerMachine]>\Tests\<architecture>\nttest\nettest\ndis\NDISTest.net\SoftAPMiniport\
<ControllerMachine> é o nome do computador controlador DTM e <a arquitetura> é x86 (para processadores baseados em x86) ou amd64 (para processadores baseados em x64), dependendo da arquitetura do processador do computador cliente DTM que tem os dispositivos SoftAP.
Inicie NDISTest.exe do diretório de instalação. Quando o formulário main for aberto, selecione Servidor no menu Arquivo para iniciar o formulário do servidor.
Selecione o dispositivo de mensagem na lista Dispositivo de Mensagem . Esse dispositivo deve ser habilitado para IP e na mesma sub-rede que o dispositivo de mensagem do cliente que será configurado posteriormente.
Selecione os dispositivos AP em Dispositivos AP. Os dispositivos AP selecionados neste servidor ficarão visíveis para o cliente depois que o servidor for iniciado.
Selecione o trabalho "servidor" em Trabalhos. Este é o teste do lado do servidor que será iniciado depois que você clicar no botão Iniciar.
Depois que todas as opções tiverem sido selecionadas, clique em Iniciar para iniciar o servidor.
Configurando o dispositivo em teste (DUT)
Copie todos os binários e subdiretórios do NDISTest do seguinte controlador DTM:
\\<ControllerMachine>\tests\<architecture>\nttest\nettest\ndis\ndistest.net\
<ControllerMachine> é o nome do computador controlador DTM e <a arquitetura> é x86 (para processadores baseados em x86) ou amd64 (para processadores baseados em x64).
Inicie NDISTest.exe do diretório de instalação. Quando o formulário main for aberto, selecione Cliente no menu Arquivo para iniciar o formulário do cliente.
Selecione o destino de teste na lista Destino de Teste . Para o dispositivo de rede, esse destino de teste deve ser Miniport.
Selecione o dispositivo de teste na lista Dispositivo de Teste . Deve ser um dispositivo de teste específico do fornecedor.
Selecione um dispositivo de mensagem na lista Dispositivo de Mensagem . Esse deve ser um dispositivo habilitado para IP que está na mesma sub-rede que o dispositivo de mensagem do servidor. Depois que o dispositivo de mensagem tiver sido selecionado, a seção do dispositivo AP deverá ser exibida e o dispositivo AP do servidor deverá estar disponível na lista.
Selecione um dispositivo de suporte em Dispositivos de Suporte. Deve ser um dispositivo de suporte específico do fornecedor.
Selecione um dispositivo AP em Dispositivos AP. Esse deve ser o dispositivo AP que foi selecionado no lado do servidor.
Selecione os testes na seção Trabalhos que serão executados depois que o cliente for iniciado.
Depois que todas as opções tiverem sido selecionadas, clique em Iniciar para iniciar o cliente. Todos os trabalhos selecionados iniciarão a execução. Os resultados do teste serão armazenados no cliente na seguinte subpasta de log:
<NDISTestRootFolder>/logs/<AdapterName>/
Configurando a captura de pacotes do cliente
Configure uma topologia de teste para execução autônoma. Para obter mais informações, acesse "Como configurar o NDISTest para execução autônoma".
Configurar um segundo SUT. Para obter mais informações, acesse "Como configurar um dispositivo de suporte em teste (SUT)."
Inicie NDISTest.exe do diretório de instalação. Quando o formulário de main for aberto, selecione Depurar no menu Exibir para iniciar a seção Captura de Pacotes no cliente.
Selecione um Dispositivo de captura na Captura de Pacotes. Este deve ser um dispositivo de suporte que foi selecionado no lado do servidor.
Em Trabalhos, selecione os testes que serão executados depois que o cliente for iniciado.
Depois que todas as opções tiverem sido selecionadas, clique em Iniciar para iniciar o cliente.
As capturas de pacote correspondentes aos Testes serão geradas no servidor com o dispositivo de captura. Os logs estarão na seguinte subpasta de log:
<NDISTestRootFolder>/logs/<AdapterName>/
Solução de problemas quando a seção Captura de Pacotes não aparece no cliente
Verifique se a interface do usuário do centro de mensagens está fechada. Se a interface do usuário do NDISTest não estiver maximizada, a seção Captura de Pacotes poderá estar oculta por trás da interface do usuário do centro de mensagens.
Problemas conhecidos de teste de roteador sem fio
Essa dica ajudará você a testar a capacidade do computador enviar taxas de bits mais altas usando a conexão Ethernet (ou seja, valida o computador).
Para este procedimento de teste, configure dois computadores, conforme mostrado no diagrama a seguir:
Configurar o hardware conforme mostrado abaixo com apenas a conexão Ethernet
Atribua um endereço IP estático ao Machine S.
Por exemplo: 10.0.0.2
Atribua um endereço IP estático ao Computador C.
Por exemplo: 10.0.0.3
No Computador C, abra um prompt de comando e execute o seguinte comando:
stats.exe -z DISCARD -i 20 -x 50 -y 30 -r 20000000 -c 3600 -l -h -u
No Computador S, abra um prompt de comando e execute o seguinte comando:
stats.exe -d 10.0.0.3 -r 20000000 -c 4200 -l -h -u
Examine a saída das Etapas 4 e 5.
Se a saída da Etapa 4 ou da Etapa 5 mostrar falhas, seus computadores não poderão fazer taxas de bits usando adaptadores sem fio.
Se você precisar adicionar um perfil sem fio manualmente, poderá fazer isso usando o comando netsh.
Por exemplo: para adicionar o perfil sem fio 802_11a_wpa-psk.xml:
Clique em Iniciar, em Executar e insiracmd.exe.
Digite netsh wlan add profile filename=802_11a_wpa-psk.xml i=\*
Clique em OK.
Observação
Verifique se o arquivo XML de Perfil Sem Fio existe no diretório atual ou especifique o caminho completo.