The Freescale ZigBee Test Client ( ZTC) es una herramienta de diagnóstico que permite realizar extensas pruebas del protocolo BeeStack entre interfaces de capa y para la comunicación con un procesador Host cuando se utiliza la caja negra de las aplicaciones específicas de ZigBee. Con el software de herramienta de prueba de Freescale y ZTC , un usuario puede iniciar una red ZigBee , unir dispositivos a la red , y ejecutar cualquiera de los más de 300 comandos para probar los servicios de aplicaciones BeeStack y sus interfaces. Diseñado para funcionar en el entorno de desarrollo Toolkit Freescale BeeKit de conectividad inalámbrica, las herramientas de software adicionales permiten la configuración del dispositivo y las configuraciones para la prueba. Estas herramientas de software son: Software BeeKit más el código base BeeStack , que contiene las bibliotecas y algo de código fuente Freescale CodeWarrior IDE para dispositivos HCS08 basado en calidad de compilador , enlazador y depurador IAR Embedded Workbench para dispositivos basados en ARM7 en calidad de compilador , enlazador y depurador El software de herramienta de prueba de Freescale para iniciar las pruebas ZTC , pruebas de aplicación BeeStack Box Negro y descarga de firmware La arquitectura BeeStack se basa en el modelo OSI de siete capas , lo que garantiza la interoperabilidad entre dispositivos en red . En la implementación ZigBee , la pila IEEE 802.15.4 proporciona el control físico ( PHY) y el control de acceso a medios ( MAC ). Los qu , junto con la red ( NWK ) en la capa de la pila ZigBee ,dan las bases para los (APL) capas de aplicación . El combinado PHY , MAC , NWK , y la capa de aplicación elementos comprenden el BeeStack completo implementación. Las capas BeeStack se comunican mediante el envío de mensajes primitivos a través de puntos de acceso de servicio (SAP). La TCC permite al desarrollador para poner a prueba los manipuladores y los PAE SAP específicos pero el usuario debe estar muy familiarizado con los conceptos empleados en toda la ZigBee BeeStack BlackBox Para que se utiliza El ZTC es una pequeña aplicación de ejecución por separado de cada capa en la pila, si ese nodo es un ZigBee Coordinador ( ZC ) , ZigBee Router ( ZR ) , dispositivo final ZigBee ( ZED ) o Combo . ( Zx ) . El PC host o anfitrión procesador se conecta al dispositivo bajo prueba ( DUT ) a través de un USB , UART , cable RS-232 o I 2C (dependiendo del tipo de tarjeta ) en el modo de serie . El dispositivo puede entonces ser controlado por llamadas a la API generados por un dispositivo host para probar. Las interfaces entre capas BeeStack o implementar una aplicación ZigBee en la CPU host mediante la BeeStack Aplicación BlackBox . La TCC permite características de servicio comunes para cada dispositivo y permite la monitorización de BeeStack específica sus interfaces y llamadas a la API . Diagrama ZTC-StartNwkEx.Request Cuando la tarjeta inicia solicita una conexión inicial de datos mandando un mensaje y solicitando el estado de conexión. Después cuando se le solicita unirse a una red la tarjeta envía un beacon para informar a todos los demás dentro de la red que se encuentra activo y listo para la comunicación. El sniffer detecta que un evento ha ocurrido pero no identifica que tipo de evento, hasta que la tarjeta envía una solicitud de MAC y después envía su misma MAC a través de una notificación por medio del beacon y después espera una confirmación de que el mensaje ha sido recibido. En este caso específico como la tarjeta es un coordinador también envía solicitudes y atributos para configurar la red entre ellos un network discovery con su respectiva notificación de evento y después un request esperando la confirmación de otros dispositivos que pretendan unirse a la red. Este proceso se repetirá hasta que ocurra un cambio significante en la red o hasta que se reciba una interrupción dentro del sistema. IEEE_addr_req.Request Después la tarjeta solicita mensajes de confirmación de que la trama ha sido recibida a continuación procede a solicitar las direcciones MAC de otros dispositivos que se encuentran dentro de su misma red. La información que se recibe por respuesta incluye entre otras cosas un byte identificador para la sincronización en el grupo en el que se encuentra el código de operación, la longitud del mensaje, La dirección en el que encuentra, el modo, punto de inicio y fin del paquete, estado en el que se encuentra comparándolo con una variable de nombre "gApsTableFull_c", el tiempo de vida del paquete y finalmente una flag para indicar la confirmación del paquete. De igual manera estos mensajes se envían de manera regular para solicitar información de otros dispositivos que requieran unirse a la red enviando dataRequest y solicitudes de dirección MAC continuamente. NodeDesciptor_request Después de que otro dispositivo se ha unido a la red en la primera tarjeta que cumple con la función de coordinador se agregan las direcciones MAC a un pool de memoria después de que la dirección del todos los dispositivo han sido agregados a este pool se envían unos bytes de notificación para indicar las funciones específicas del nuevo dispositivo, por ejemplo, si se trata de un dispositivo final se enviará un mensaje identificador y el coordinador procederá a mandar las funciones específicas de configuración, todo esto en base a los bits que describen al dispositivo después de solicitar la dirección MAC. ZDP-Match_Desc_req.Request Esta función es ejecutada dentro del coordinador y solicita al endpoint, o en esta caso dispositivo final, y envía un mensaje para asegurarse de que la dirección del dispositivo final concuerde con la que se tiene dentro del pool de la MAC, en este caso específico, se utiliza la dirección de broadcast de la red pero para verificar la conectividad de un dispositivo único se puede especificar una dirección de tipo unicast, en ese caso la dirección de 16 bits contenida en u16AddrInterest tendrá que ser la dirección MAC específica del dispositivo final. ZDP-DeviceAnnce.Indication Este mensaje usualmente se limita a los dispositivos finales, en este caso, solo lo podemos encontrar cuando encontramos la segunda tarjeta que servirá como end-device. Sus funciones específicas son simplemente anunciar sobre la red que se encuentran operativos y listos para comunicarse, de igual forma, se utilizó la dirección broadcast sobre la red como método para transmitir la información. ZDP-BIND.Request Después de que ambos dispositivos se han unido a la red podemos hacer que la tarjeta que cumple la función de coordinador propague una solicitud de binding dentro de la red, después habilitamos la end-point para que haga binding dentro de la red ambos dispositivos se unirán siempre y cuando pertenezcan al mismo cluster. Para esto es necesario que las direcciones que tienen que ver con la función específica a desempeñar pertenezcan al mismo tipo, en otras palabras, el match debe ser exitoso para que los dispositivos sean capaz de hacer binding, por ejemplo, las funciones que tienen que ver con prendido y apagado de switch, las funciones de termostato, etc. ZDP-Mgmt_Permit_Join.Request enable/disable
Comandos
Después de que se ha mandado una solicitud de binding depende del coordinador si acepta la solicitud del nuevo dispositivo para abrirse a la red. Usualmente norepresentará restricción alguna si las demás condiciones como la dirección de MAC y la solicitud de binding hacen match, en nuestro caso en ninguna de las circunstancias rechazó el nuevo dispositivo por lo tanto el coordinador envía el mensaje esta vez utilizando la dirección unicast del dispositivo final habilitando para que se uniera a la red. Si después de que el dispositivo final mandó un mensaje de confirmación la red término de visualizarse dentro del sniffer.
Vulnerabilidades SSL
EL protocolo SSL fue introducido en 1996 y su función es la de permitir la comunicación segura mediante un cifrado de la información. SSL significa "Secure ...
Programación y TI hace 8 años
Daniel Gtz
