Continuando con los posts sobre el testing del Service Pack 2 de Windows Vista y Windows Server 2008, ahora voy a hablar un poco sobre cómo Microsoft administra una característica o feature que agrega a sus sistemas operativos. La calidad es el objetivo primario cuando se agrega una nueva característica en Windows. Una cosa es tener muchos e interesantes escenarios por soportar al momento de agregar una característica, pero es peor si se agrega algo que no trabaja bien a que no se agregue. Por eso siempre menos es más, porque si se proporciona una nueva característica o tecnología y no funciona total o parcialmente, el usuario se alejará con la impresión de que no funcionó. En cambio si la característica funciona aunque no cumpla con todas las expectativas esperadas, el usuario va a quedarse con la impresión de que sabe que funciona pero le gustaría que además pudiera hacer X, pero X tal vez venga en el próximo release del sistema. Por eso es importante concentrarse en esto al momento de testear Networking y las tecnologías de transición de IPv4 a IPv6.
Como Windows es una plataforma realmente amplia y hay tanta gente que desarrolla, lo extiende y lo usa de infinidad de maneras diferentes lo que hace imposible para Microsoft conocer cada situación y ser capaz de testear de la manera que trabaja cada uno. Precisamente es aquí donde todos entramos en juego para ayudar y validar que lo que hace Microsoft funciona en todos los escenarios y en la infinidad de maneras en que Windows puede ser utilizado. Es importante siempre reportar qué parte de la experiencia no funcionó o qué se esperaba versus qué es lo que se obtuvo. Para reportar bugs en Networking lo primero que se necesita es el Mapa de Red, al cual se llega haciengo click en el «Network and Sharing Center» en el Panel de control.
Luego clickear en el link que dice «View Full Map».
Este mapa es una representación de la red a la que pertenecemos, el cual es nuevo en Windows Vista. Así que utilizar el Mapa de Red para describir nuestro esquema de red incluyendo el tipo de conexión. En algunos escenarios, es posible que el mapa de red no muestre toda la información relevante sobre nuestra red, de ser así por favor hacer saber sobre las computadoras o dispositivos faltantes siguiendo las instrucciones detalladas que aparecen al clickear en el área resaltada en la siguiente figura:
Un verdadero reporte de bug de Networking necesita contener toda información relevante incluyendo fabricante de hardware y versión del driver como así también la versión del firmware para cualquier hardware de red como placas de red, access points y routers. Para ello necesitamos la información provista por ipconfig, Desde la consola y con privilegios administrativos ejecutamos «ipconfig /all»:
Información como direcciones IP, direcciones MAC, fabricantes de NIC y mucho más aparecerán en la consola. Toda esta información es necesaria incluirla en el reporte de bugs de Microsoft Connect como un archivo adjunto junto con cualquier screenshot. Esta información es necesaria para cualquier tipo de conexión incluyendo pero no limitado a conexiones wired, wireless, VPN y dial-up.
En Windows Vista se ha agregado soporte para la próxima generación de protocolos de Internet, conocidos como IPv6. Esta información se incluye como parte del reporte de «ipconfig /all» si IPv6 está habilitado en nuestra red. Cabe destacar que en Windows Vista IPv6 está hablitado por defecto, sin embargo no todo el hardware de red soporta IPv6 todavía. Durante 1970, IPv4 fue inventado pero pasó mucho tiempo antes que la red Internet que conocemos actualmente fuera concebida y creada. Si bien IPv4 ha sobrevivido todo este tiempo hay ciertas cuestiones que necesitan ser corregidas. Entre ellas la escasez de direcciones IP, esto es particularmente muy visible en Asia y Europa, que entraron tarde al juego de Internet y como resultado no recibieron la asignación de direcciones IP que USA obtuvo. Actualmente USA tiene el 8% de la población mundial mientras que posee el 75% de las direcciones IPv4.
Por lo tanto, esencialmente, IPv6 apunta a la visión de que todos los dispositivos que se conecten(inalámbricamente o no), ya sean celulares, cámaras, etc. permitirles participar en Internet como ciudadanos de primera clase. IPv6 apunta a satisfacer esa necesidad y es por eso que en Windows Vista está habilitado por defecto. Esto significa que los desarrolladores ahora tienen que escribir sus aplicaciones para que sean agnósticas de protocolo de red y las empresas necesitan empezar a crear un plan de cómo van a implementar IPv6 en el tiempo. En Windows Vista hay muchas tecnologías que permiten que esta transición suceda sin tener que actualizar toda la red, entre ellas Toredo, ISATAP, PortProxy para más información les recomiendo leer el excelente paper sobre tecnologías de transición de Networking en http://technet.microsoft.com/en-us/library/bb726951.aspx. Por eso se recomienda empezar con las aplicaciones y las tecnologías de transición y posteriormente a medida que los patrones de tráfico cambien evaluar como actualizar la red a IPv6.
Para reportar bugs de Networking es necesario lograr reproducir el bug en un contexto de tracing. Esto realmente consiste en 3 pasos básicos:
- Tener habilitado tracing antes de testear.
- Ejecutar los pasos necesarios para reproducir el bug.
- Deshabilitar tracing.
Por ejemplo , para el caso de una conexión cableada en una LAN:
- Habilito tracing desde la consola en como Administrador: netsh lan set tracing mode=yes
- Luego voy paso a paso para reproducir el problema. Supongamos que estoy testeando conectividad IPv6 en la LAN.
- Finalmente, una vez reproducido el bug de forma exitosa deshabilitar tracing con: netsh lan set tracing mode=no
En «C:Windowstracingwired» encontraremos un archivo llamado wired.cab con todo el reporte de tracing. Este archivo habrá que adjuntarlo al reporte de bugs en Microsoft Connect. Los logs generados por tracing son críticos para debugear el bug por parte del Windows Beta Team, es por ello que siempre que sea posible reproducir un bug de Networking hay que enviar toda la información de contexto de tracing.
Si probamos IPv6 sobre VPN, los logs generados encuentran en «C:Windowstracing», son varios archivos con la extensión .log. Los comandos para habilitar y deshabilitar tracing son:
- netsh ras set tracing * enabled
- netsh ras set tracing * disabled
Para una conexión wireless, los logs se almacenan en «C:Windowstracingwireless» y concretamente habrá un archivo wireless.cab que contiene todo el reporte de tracing a adjuntar. Los comandos para habilitar y deshabilitar tracing son:
- netsh wlan set tracing yes
- netsh wlan set tracing no
Finalmente adjuntar todos las trazas sobre cualquier tipo de conexión que reportemos un bug, como cualquier otro bit de información que ayude debugear la conectividad de la red.
Fernik