Solución de problemas de Device.Network Testing
Solución de problemas de Device.Network Testing
Para solucionar problemas que se producen con las pruebas de Device.Network, siga estos pasos:
Revise Solución de problemas de errores de prueba de HLK de Windows.
Revise uno de los temas siguientes, en función del tipo de producto o característica de red que esté probando:
Revise las notas de la versión de Windows HLK para ver los problemas de prueba actuales.
Para ver un error de prueba, busque información utilizable en el registro de pruebas de Windows HLK Studio. Si encuentra información utilizable, resuelva el problema y vuelva a ejecutar la prueba.
Problemas de prueba de IPsec conocidos
Si el controlador HLK de Windows no puede conectarse a los clientes, siga estos pasos:
El primer caso de prueba está diseñado para asegurarse de que la configuración es correcta. No hace nada más que comprobar la red pública y privada para la conectividad. Si se produce un error en esta prueba, hay un problema de configuración de prueba.
Compruebe que el archivo config.dat se coloca en el directorio %SystemDrive%\IPsecTestKit\IPsecScenario\ y tiene las direcciones IP correctas para el controlador y los clientes. Este archivo se genera automáticamente, pero en determinados casos, como errores de resolución DNS, el archivo config.dat puede contener datos incorrectos o faltar por completo. Use el formato descrito en la sección Configuración de prueba para comprobar el archivo config.dat.
Compruebe que tiene exenciones de firewall para IPsecControl.exe y IPsecScenario.exe.
Compruebe que, después de ejecutar los scripts de instalación, las interfaces IPsec Offload V2 se han cambiado correctamente a "Test1".
Genconfig_phase2.vbs puede que no genere los archivos CMD necesarios si solo hay 1 puerta de enlace predeterminada para el adaptador de mensajes. Si el servidor DHCP no admite IP V6, solo puede obtener 1 dirección de puerta de enlace predeterminada de IP V6.
Ejecución de variaciones de prueba individuales
En determinados casos cuando se produce un error en las pruebas, ejecute una única variación de prueba en lugar de volver a ejecutar todo el conjunto de aplicaciones. Para ello, realice los pasos siguientes:
Asegúrese de que las sesiones de IPsecScenario.exe se ejecutan en todos los clientes.
Copie las variaciones individuales para que se ejecuten desde OffloadV2_logoTests.cmd y ejecútelas desde una nueva ventana de comandos (%SYSTEMDRIVE%\IPsecTestKit\IPSecscenario\Controller
Troubleshooting LAN (Ethernet) Testing
Es posible que se produzca un error en el trabajo de prueba de IPSec debido a problemas con trabajos de prueba de LAN relacionados. Consulte la sección siguiente para obtener más información.
Problemas de prueba de LAN (Ethernet) conocidos
| Problema | Detalles |
|---|---|
Los trabajos de prueba "IPsec Offloadv2 comprobación del logotipo (Win7)" permanecen en el estado "Scheduler" y nunca se ejecutan. |
Este problema suele deberse a varios problemas de comunicación entre el cliente DTM y el controlador. Puede comprobar si la "Hora del último latido" está cerca de la hora actual. Para forzar el cliente DTM que informa de un latido, puede cambiar manualmente el estado de la máquina a Restablecer o No seguro en DTM Studio y, a continuación, esperar hasta que el estado de la máquina cambie de nuevo a "Normal". Después de cambiar el estado de todas las máquinas necesarias para ejecutar el trabajo a Normal, el trabajo se programará en los clientes DTM. Si el estado de la máquina cambia a Depuración, compruebe si la máquina cliente DTM sigue respondiendo. A veces, el estado de la máquina es Normal y el latido es correcto, pero el trabajo todavía no se ejecutará. Esto se debe a que el firewall o IPsec bloquean la comunicación entre el cliente DTM y el controlador. Asegúrese de que el cliente y el controlador DTM tengan la misma configuración de IPsec. Si el cliente tiene IPsec activado, pero el controlador está desactivado, o viceversa, el trabajo no se programará. El cliente DTM está diseñado para trabajar con un firewall, pero a veces el firewall bloquea el tráfico normal entre el cliente y el controlador. |
El siguiente mensaje de error es observador en el registro de pruebas: "El trabajo xxx requiere que se seleccione un dispositivo, no un controlador" al hacer clic en "Agregar información". |
El error se produce porque ha seleccionado un controlador, no un dispositivo de prueba, en la Consola de dispositivo para ejecutar el trabajo de prueba. Si no encuentra un dispositivo bajo el controlador en la Consola de dispositivo , los archivos INF y los archivos de controlador que proporcionó durante el envío del logotipo no coinciden con los archivos de controlador y archivo INF reales en el cliente DTM. Actualice el archivo INF y los archivos de controlador mediante el archivo INF real y los archivos de controlador instalados en el cliente DTM. |
No aparece el trabajo "IPsec Offloadv2 logo verification (Win7)" en "Device Console". |
Asegúrese de que el dispositivo es un dispositivo Ethernet (LAN) y informe del tipo de medio a NDIS como NdisMedium802_3. Este error a veces se produce cuando la información de hardware notificada por el cliente DTM está incompleta. Para solucionar este problema, intente reiniciar la máquina cliente DTM y actualizar la vista de la consola del dispositivo. Si esto no funciona, intente detener y reiniciar el servicio "wttsvc" en el cliente DTM y, a continuación, actualice la vista de la consola del dispositivo. |
La prueba Ethernet - NDISTest 6.0 (prioridad) puede producir correctamente un error en el 2c_priority y la aserción paquetes dirigidos - NdisSendPackets con un mensaje no se pueden obtener resultados de prueba en el mensaje del adaptador de red de prueba . |
Este problema puede producirse cuando el conmutador de red quita incorrectamente los bits de prioridad. Para confirmar que este problema se produce debido al conmutador de red, pruebe el adaptador quitando el conmutador y conectando los cables directamente. Puede hacerlo mediante una configuración de prueba alternativa. Esta configuración de prueba solo se puede usar en los dispositivos que no admiten Chimney, (descarga TCP), ya que el dispositivo de soporte local es necesario para esos dispositivos. Quite el dispositivo de soporte técnico local y pruebe el conmutador de red por completo y conecte el dispositivo de prueba local directamente de vuelta con el dispositivo de soporte remoto. Si se trata de los pasos, esto es aceptable para la certificación, pero trabaje con el fabricante del conmutador para corregir la configuración del conmutador. |
El Ethernet - NDISTest 6.5 (WoL y PM) puede producir un error correcto en los dispositivos dentro de la aserción de paquete de red FAKE LLMNRv4 con un error que indica que la máquina funciona incorrectamente. |
Para ayudar a determinar si el dispositivo produce un error correcto, desenlate los protocolos solo en el dispositivo remoto. Si esto no resuelve el problema, abra un incidente de soporte técnico. |
Nota
Para solucionar problemas de NDISTest (6.0 o 6.5), adjunte un depurador al equipo de prueba.
Problemas conocidos de prueba de banda ancha móvil
En la lista siguiente se describen algunas sugerencias de solución de problemas comunes para las pruebas de banda ancha móvil:
Los cambios realizados en los dispositivos de los equipos cliente DTM no se reflejan en DTM Studio. Por ejemplo, se espera que la máquina esté en estado Listo, pero no lo es.
Abra una ventana del símbolo del sistema en el equipo cliente y
net stop wttsvcejecute .Ejecute
net start wttsvc. Este comando actualiza el directorio C:\wtt\JobsWorkingDir\AssetCfg\Log\.Actualice la ventana Consola de dispositivo en DTM Studio. El controlador DTM puede tardar varios minutos en sondear el equipo cliente para ver los cambios en su lista de dispositivos.
No se han detectado equipos para el grupo de máquinas.
Abra la ventana Monitor de trabajos en DTM Studio.
Haga clic en el botón Mostrar generador de consultas en la parte superior de la pantalla.
Haga clic en la pestaña Consulta de máquina .
Defina parámetros de búsqueda para los equipos de destino. Normalmente, establezca una sola regla, como "DataStore es igual a "Nombre del controlador".
Haga clic con el botón derecho en la regla que acaba de definir y, a continuación, haga clic en Ejecutar. Una lista extensa de equipos rellena la lista Máquinas debajo de los campos de consulta.
Arrastre todas las máquinas de la lista Máquinas al nuevo grupo de máquinas que se creó.
Los equipos no parecen ejecutar trabajos programados para ellos.
Abra la ventana Monitor de trabajos en DTM Studio.
En la pestaña Grupo de máquinas, seleccione el grupo de máquinas que se espera que ejecute trabajos.
Para cada equipo de ese grupo, compruebe que su estado es Listo.
Si el estado de un equipo no es Listo, haga clic con el botón derecho en el equipo, seleccione Cambiar estado y, a continuación, haga clic en Restablecer.
Después de unos minutos, actualice la pantalla y el estado cambia a Listo.
Programe e inicie los trabajos de nuevo.
Requisitos previos conocidos de pruebas de software de seguridad de red
Las pruebas de software de seguridad de red (TransitionTechnologies_Tests y WindowsFilteringPlatform_Tests) requieren que los controladores de miniporte sparta estén instalados y configurados correctamente. Los controladores de miniporte de Sparta se instalan cuando se ejecuta cada prueba; sin embargo, si decide hacerlo, puede comprobar que están presentes abriendo un símbolo del sistema y escribiendo IPConfig.exe /all. Debería ver cuatro nuevas interfaces de Sparta denominadas Sparta Miniport Primary, Sparta Miniport Secondary, Sparta Miniport Terciario y Sparta Miniport Quaternary.
Problemas conocidos de prueba de enrutador
Actualmente no hay problemas conocidos de prueba de enrutador.
Problemas de prueba conocidos de LAN inalámbrica (802.11)
En la lista siguiente se describen algunas sugerencias de solución de problemas comunes para las pruebas wlan:
Los cambios realizados en los dispositivos en las máquinas de clientes DTM no se reflejan en DTM Studio. Por ejemplo, se espera que la máquina esté en estado Listo, pero no lo es.
Abra una ventana del símbolo del sistema en el equipo cliente y, a continuación, ejecute
net stop wttsvc.Ejecute
net start wttsvc. Este comando actualizará el directorio C:\wtt\JobsWorkingDir\AssetCfg\Log\.Actualice la ventana Consola de dispositivo en DTM Studio. Es posible que tenga que esperar varios minutos para que el controlador DTM sondee el equipo cliente para ver los cambios en su lista de dispositivos.
No se han detectado máquinas para el grupo de máquinas.
Abra la ventana Monitor de trabajos en DTM Studio.
Seleccione el botón Mostrar generador de consultas en la parte superior de la pantalla.
Haga clic en la pestaña Consulta de máquina .
Defina parámetros de búsqueda para las máquinas que está buscando. Normalmente, puede establecer una sola regla, como "DataStore es igual a "Nombre del controlador".
Haga clic con el botón derecho en la regla que acaba de definir y, a continuación, haga clic en Ejecutar. Una lista extensa de máquinas debe rellenar la lista Máquinas debajo de los campos de consulta definidos.
Arrastre todas las máquinas de la lista Máquinas a los nuevos grupos de máquinas que ha creado.
Las máquinas no parecen ejecutar trabajos programados para ellos.
Abra la ventana Monitor de trabajos en DTM Studio.
En la pestaña Grupo de máquinas, seleccione el grupo de máquinas que espera que esté ejecutando trabajos.
Para cada máquina de ese grupo, compruebe que su estado es Listo.
Si el estado de una máquina no es Listo, haga clic con el botón derecho en la máquina, seleccione Cambiar estado y, a continuación, haga clic en Restablecer.
Después de unos minutos, actualice la pantalla y el estado cambiará a Listo.
Programe e inicie los trabajos de nuevo.
Problemas con la instalación del controlador SoftAP de prueba en la topología: Administrador de dispositivos notifica el código 52
No instale el controlador softAP de prueba x64 antes de instalar el cliente DTM. Cuando se instala el cliente DTM, se instala el certificado raíz. Dado que la firma del controlador de SoftAP de prueba depende de la instalación del certificado raíz, el administrador de dispositivos notifica el código del dispositivo 52.
Configuración de NDISTest para la ejecución independiente
La instalación de NDISTest independiente de DTM Studio permite ejecutar pruebas individuales. Se debe configurar un DUT, SUT y Test SoftAP para habilitar la ejecución independiente.
Nota
Todas las máquinas de prueba deben usar la misma arquitectura de procesador.
Nota
Para solucionar problemas de NDISTest, intente adjuntar un depurador a la máquina de prueba.
Configuración de un dispositivo de soporte técnico en prueba (SUT)
Copie todos los archivos binarios y subdirectorios de NDISTest desde el siguiente controlador DTM:
\\<ControllerMachine]>\tests\<architecture>\nttest\nettest\ndis\ndistest.net\<ControllerMachine> es el nombre del equipo del controlador DTM y <la arquitectura> es x86 (para procesadores basados en x86) o amd64 (para procesadores basados en x64).
Inicie NDISTest.exe desde el directorio de instalación. Cuando se abra el formulario principal, seleccione Servidor en el menú Archivo para iniciar el formulario de servidor.
Seleccione el dispositivo de mensaje en la lista Dispositivo de mensaje . Este dispositivo debe estar habilitado para IP y en la misma subred que el dispositivo de mensaje de cliente que se configurará más adelante.
Seleccione Dispositivos SUT en Dispositivos de soporte técnico. El dispositivo de soporte técnico seleccionado en este servidor desde será visible para el cliente después de iniciar el servidor.
Seleccione el trabajo "servidor" en Trabajos. Esta es la prueba del lado servidor que se iniciará después de hacer clic en el botón Iniciar.
Una vez seleccionadas todas las opciones, haga clic en Iniciar para iniciar el servidor.
Configuración de un punto de acceso de software de prueba (Prueba de SoftAP)
Copie todos los archivos binarios y subdirectorios de NDISTest desde el siguiente controlador DTM:
\\<ControllerMachine]>\tests\<architecture>\nttest\nettest\ndis\ndistest.net\<ControllerMachine> es el nombre del equipo del controlador DTM y <la arquitectura> es x86 (para procesadores basados en x86) o amd64 (para procesadores basados en x64).
Instale el controlador SoftAP para ambos dispositivos WLAN de Atheros en el SoftAP de prueba. Puede instalar este controlador desde Administrador de dispositivos, que puede abrir mediante la ejecución
devmgmt.mscdesde un símbolo del sistema. Complete el paso siguiente:En Administrador de dispositivos, instale el controlador para las estaciones de SoftAP desde:
\\<ControllerMachine]>\Tests\<architecture>\nttest\nettest\ndis\NDISTest.net\SoftAPMiniport\<ControllerMachine> es el nombre del equipo del controlador DTM y <la arquitectura> es x86 (para procesadores basados en x86) o amd64 (para procesadores basados en x64), dependiendo de la arquitectura de procesador de la máquina cliente DTM que tenga los dispositivos SoftAP.
Inicie NDISTest.exe desde el directorio de instalación. Cuando se abra el formulario principal, seleccione Servidor en el menú Archivo para iniciar el formulario de servidor.
Seleccione el dispositivo de mensaje en la lista Dispositivo de mensaje . Este dispositivo debe ser un dispositivo habilitado para IP y en la misma subred que el dispositivo de mensaje de cliente que se configurará más adelante.
Seleccione los dispositivos AP en Dispositivos AP. Los dispositivos AP seleccionados en este servidor serán visibles para el cliente después de iniciar el servidor.
Seleccione el trabajo "servidor" en Trabajos. Esta es la prueba del lado servidor que se iniciará después de hacer clic en el botón Iniciar.
Una vez seleccionadas todas las opciones, haga clic en Iniciar para iniciar el servidor.
Configuración del dispositivo en prueba (DUT)
Copie todos los archivos binarios y subdirectorios de NDISTest desde el siguiente controlador DTM:
\\<ControllerMachine>\tests\<architecture>\nttest\nettest\ndis\ndistest.net\<ControllerMachine> es el nombre del equipo del controlador DTM y <la arquitectura> es x86 (para procesadores basados en x86) o amd64 (para procesadores basados en x64).
Inicie NDISTest.exe desde el directorio de instalación. Cuando se abra el formulario principal, seleccione Cliente en el menú Archivo para iniciar el formulario de cliente.
Seleccione el destino de prueba en la lista Destino de prueba. Para el dispositivo de red, este destino de prueba debe ser Miniport.
Seleccione el dispositivo de prueba en la lista Dispositivo de prueba. Debe ser un dispositivo de prueba específico del proveedor.
Seleccione un dispositivo de mensaje en la lista Dispositivo de mensaje . Debe ser un dispositivo habilitado para IP que esté en la misma subred que el dispositivo de mensaje del servidor. Una vez seleccionado el dispositivo de mensaje, se debe mostrar la sección del dispositivo AP y el dispositivo AP del servidor debe estar disponible en la lista.
Seleccione un dispositivo de soporte técnico en Dispositivos de soporte técnico. Debe ser un dispositivo de soporte técnico específico del proveedor.
Seleccione un dispositivo AP en Dispositivos AP. Debe ser el dispositivo AP que se seleccionó en el lado servidor.
Seleccione las pruebas de la sección Trabajos que se ejecutarán después de iniciar el cliente.
Una vez seleccionadas todas las opciones, haga clic en Iniciar para iniciar el cliente. Los trabajos seleccionados comenzarán a ejecutarse. Los resultados de las pruebas se almacenarán en el cliente en la siguiente subcarpeta de registro:
<NDISTestRootFolder>/logs/<AdapterName>/
Configuración de la captura de paquetes de cliente
Configure una topología de prueba para la ejecución independiente. Para obtener más información, vaya a "Configuración de NDISTest para la ejecución independiente".
Configure un segundo SUT. Para obtener más información, vaya a "Configuración de un dispositivo de soporte técnico en prueba (SUT)."
Inicie NDISTest.exe desde el directorio de instalación. Cuando se abra el formulario principal, seleccione Depurar en el menú Ver para iniciar la sección Captura de paquetes en el cliente.
Seleccione un dispositivo De captura en Captura de paquetes. Debe ser un dispositivo de soporte técnico seleccionado en el lado servidor.
En Trabajos, seleccione las pruebas que se ejecutarán después de iniciar el cliente.
Una vez seleccionadas todas las opciones, haga clic en Iniciar para iniciar el cliente.
Las capturas de paquetes correspondientes a las pruebas se generarán en el servidor con el dispositivo de captura. Los registros estarán en la siguiente subcarpeta de registro:
<NDISTestRootFolder>/logs/<AdapterName>/
Solución de problemas cuando la sección Captura de paquetes no aparece en el cliente
Compruebe que la interfaz de usuario del centro de mensajes está cerrada. Si la interfaz de usuario NDISTest no está maximizada, la sección Captura de paquetes puede estar oculta detrás de la interfaz de usuario del centro de mensajes.
Problemas conocidos de prueba del enrutador inalámbrico
Esta sugerencia le ayudará a probar la capacidad de enviar velocidades de bits más altas mediante la conexión Ethernet (es decir, valida la máquina).
Para este procedimiento de prueba, configure dos equipos como se muestra en el diagrama siguiente:
Configure el hardware como se muestra a continuación solo con conexión Ethernet.
Asigne una dirección IP estática a la máquina S.
Por ejemplo: 10.0.0.2
Asigne una dirección IP estática a la máquina C.
Por ejemplo: 10.0.0.3
En la máquina C, abra un símbolo del sistema y ejecute el siguiente comando:
stats.exe -z DISCARD -i 20 -x 50 -y 30 -r 20000000 -c 3600 -l -h -uEn la máquina S, abra un símbolo del sistema y ejecute el siguiente comando:
stats.exe -d 10.0.0.3 -r 200000000 -c 4200 -l -h -u
Revise la salida del paso 4 y el paso 5.
Si la salida del paso 4 o del paso 5 muestra errores, las máquinas no pueden realizar velocidades de bits con adaptadores inalámbricos.
Si necesita agregar manualmente un perfil inalámbrico, puede hacerlo mediante el comando netsh.
Por ejemplo: Para agregar el perfil inalámbrico de 802_11a_wpa-psk.xml:
Haga clic en Inicio, en Ejecutary escriba cmd.exe.
Escriba netsh wlan add profile filename=802_11a_wpa-psk.xml i=\*
Haga clic en OK.
Nota
Asegúrese de que el archivo XML de perfil inalámbrico existe en el directorio actual o especifique la ruta de acceso completa.