Cuando usamos Arduino como cliente HTTP, simplemente se programa la petición o http request. A la hora de recibir la respuesta o http response, dado que puede ser un número de datos muy grande podemos establecer varias estrategias:
Recoger toda la respuesta en un string o array de caracteres. Esto tiene un consumo muy alto de memoria.
Analizar línea a línea, puesto que el protocolo http se define por líneas, de forma que el consumo de memoria es pequeño y me puede permitir descartar el resto de respuesta http si ya no me interesa, para ello con un close() se cierra el socket y se descarta el resto de respuesta.
Leer a media que llega y usar alguna función que lea todo hasta que detecte lo que buscamos. Usa menos memoria, pero es más difícil de programar y es menos flexible.
Mandar datos periódicamente a un servidor público que los almacene en una base de datos o un fichero. Luego montar una web en el servidor que muestre los datos. En este caso Arduino es un cliente y usamos un servidor externo
Además esta técnica me permite tener un histórico de datos que con un Arduino está limitado a la memoria o sino habría que usar una tarjeta SD u otro almacenamiento externo.
En caso que queramos controlar un elemento remotamente, como encender una luz o la calefacción o mover un servo, la problemática es la misma que en el caso anterior si queremos acceder directamente al Arduino, en caso de estar en otra red y no tener IP pública nos obliga a abrir puertos en nuestro router.
Otra opción sería usar VPNs, pero Arduino no soporta VPN, así que necesitaríamos un elemento adicional.
Dos técnicas para control remoto:
Mandar datos directamente al Arduino. Arduino como web server y abrir puertos.
Usar un servidor intermedio al que se manda la orden y arduino pregunta periódicamente (Pull). Esto supone que el control acumula un retraso máximo del periodo que configuramos Arduino para que consulte al servidor.
Una tercera opción es montar un websocket entre Arduino y el servidor, de forma que el servidor comunica inmediatamente el cambio a Arduino (Push). Habría que buscar una librería que funcione bien.
Servidor. Eventos (Push/ Pull)
Cuando queremos que un Arduino mande un evento, por ejemplo una puerta abierta o una alta temperatura, Arduino lanza un aviso contra otro Arduino para que ejecute una acción como por ejemplo mandar un SMS si la puerta se abre o encender el aire acondicionado si hay mucha temperatura.
Ocurre lo mismo que con el control remoto, dos formas de hacerlo:
Como Push el Arduino que detecta el evento manda aviso cuando ocurre. Hay que abrir puertos si no hay conectividad directa.
Como Pull Arduino que detecta evento es un servidor y el cliente le pregunta periódicamente. Pero también hay que abrir puertos en el Arduino que actúa como servidor.
Una opción intermedia es que el Arduino que detecta eventos manda datos a un servidor público (Push) y el Arduino que debe actuar consulta periódicamente al servidor a ver si tiene que hacer algo (Pull)
El wifi es un mecanismo de conexión de dispositivos electrónicos de forma inalámbrica. Los dispositivos habilitados con wifi como Arduino, pueden conectarse a internet a través de un punto de acceso de red inalámbrica.
Wi-Fi es una marca de la Alianza Wi-Fi, la organización comercial que adopta, prueba y certifica que los equipos cumplen con los estándares 802.11 relacionados a redes inalámbricas de área local.
Los estándares IEEE 802.11b, IEEE 802.11g e IEEE 802.11n disfrutan de una aceptación internacional debido a que la banda de 2,4 GHz está disponible casi universalmente, con una velocidad de hasta 11 Mbit/s, 54 Mbit/s y 300 Mbit/s, respectivamente.
En la actualidad ya se maneja también el estándar IEEE 802.11ac, conocido como WIFI 5, que opera en la banda de 5 GHz y que disfruta de una operatividad con canales relativamente limpios. La banda de 5 GHz ha sido recientemente habilitada y, además, no existen otras tecnologías (Bluetooth, microondas, ZigBee) que la estén utilizando, por lo tanto existen muy pocas interferencias. Su alcance es algo menor que el de los estándares que trabajan a 2,4 GHz (aproximadamente un 10 %), debido a que la frecuencia es mayor (a mayor frecuencia, menor alcance).
Existen otras tecnologías inalámbricas como Bluetooth que también funcionan a una frecuencia de 2,4 GHz, por lo que puede presentar interferencias con la tecnología wifi. Debido a esto, en la versión 1.2 del estándar Bluetooth actualizó su especificación para que no existieran interferencias con la utilización simultánea de ambas tecnologías, además se necesita tener 40 000 kbit/s.
Existen varias alternativas para garantizar la seguridad de estas redes. Las más comunes son la utilización de protocolos de cifrado de datos para los estándares wifi como el WEP, el WPA, o el WPA2 que se encargan de codificar la información transmitida para proteger su confidencialidad, proporcionados por los propios dispositivos inalámbricos. La mayoría de las formas son las siguientes:
WEP, cifra los datos en su red de forma que sólo el destinatario deseado pueda acceder a ellos. Los cifrados de 64 y 128 bits son dos niveles de seguridad WEP. WEP codifica los datos mediante una “clave” de cifrado antes de enviarlo al aire. Este tipo de cifrado no está recomendado debido a las grandes vulnerabilidades que presenta ya que cualquier cracker puede conseguir sacar la clave, incluso aunque esté bien configurado y la clave utilizada sea compleja.
WPA: presenta mejoras como generación dinámica de la clave de acceso. Las claves se insertan como dígitos alfanuméricos.
WPA2 (estándar 802.11i): que es una mejora relativa a WPA. En principio es el protocolo de seguridad más seguro para Wi-Fi en este momento. Sin embargo requieren hardware y software compatibles, ya que los antiguos no lo son. Utiliza el algoritmo de cifrado AES (Advanced Encryption Standard).
IPSEC (túneles IP) en el caso de las VPN y el conjunto de estándares IEEE 802.1X, que permite la autenticación y autorización de usuarios.
Filtrado de MAC, de manera que solo se permite acceso a la red a aquellos dispositivos autorizados. Es lo más recomendable si solo se va a usar con los mismos equipos, y si son pocos.
Ocultación del punto de acceso: se puede ocultar el punto de acceso (router) de manera que sea invisible a otros usuarios.
Dispositivos de distribución o de red en wifi son:
Los puntos de acceso son dispositivos que generan un set de servicio, que podría definirse como una red wifi a la que se pueden conectar otros dispositivos. Los puntos de acceso permiten, en resumen, conectar dispositivos de forma inalámbrica a una red existente. Pueden agregarse más puntos de acceso a una red para generar redes de cobertura más amplia, o conectar antenas más grandes que amplifiquen la señal.
Los repetidores inalámbricos son equipos que se utilizan para extender la cobertura de una red inalámbrica, éstos se conectan a una red existente que tiene señal más débil y crean una señal limpia a la que se pueden conectar los equipos dentro de su alcance. Algunos de ellos funcionan también como punto de acceso.
Los enrutadores inalámbricos son dispositivos compuestos, especialmente diseñados para redes pequeñas (hogar o pequeña oficina). Estos dispositivos incluyen, un enrutador (encargado de interconectar redes, por ejemplo, nuestra red del hogar con Internet), un punto de acceso (explicado más arriba) y generalmente un conmutador que permite conectar algunos equipos vía cable (Ethernet y USB). Su tarea es tomar la conexión a Internet, y brindar a través de ella acceso a todos los equipos que conectemos, sea por cable o en forma inalámbrica.
Los estándares 802.11b y 802.11g utilizan la banda de 2,4 GHz. En esta banda se definieron 11 canales utilizables por equipos wifi, que pueden configurarse de acuerdo a necesidades particulares. Sin embargo, los 11 canales no son completamente independientes (un canal se superpone y produce interferencias hasta un canal a 4 canales de distancia). El ancho de banda de la señal (22 MHz) es superior a la separación entre canales consecutivos (5 MHz), por eso se hace necesaria una separación de al menos 5 canales con el fin de evitar interferencias entre celdas adyacentes, ya que al utilizar canales con una separación de 5 canales entre ellos (y a la vez cada uno de estos con una separación de 5 MHz de su canal vecino) entonces se logra una separación final de 25 MHz, lo cual es mayor al ancho de banda que utiliza cada canal del estándar 802.11, el cual es de 22 MHz. Tradicionalmente se utilizan los canales 1, 6 y 11, aunque se ha documentado que el uso de los canales 1, 5, 9 y 13 (en dominios europeos) no es perjudicial para el rendimiento de la red.
Esta asignación de canales usualmente se hace sólo en el Punto de acceso, pues los “clientes” automáticamente detectan el canal, salvo en los casos en que se forma una red “Ad-Hoc” o punto a punto cuando no existe punto de acceso.
Canales en 802.11 (wifi) frente a 802.15.4 (zigbee):
Y dentro del espectro electromagnético:
Además, el 802.11n puede utilizar la banda de 5 GHz, que es casi siempre menos concurrida y con menos interferencia que la banda de 2,4 GHz. Pero también funciona en 2,4 GHz, y los clientes 802.11n pueden asociarse con facilidad allí. La Tabla 1 muestra las frecuencias disponibles para los diferentes tipos de clientes inalámbricos.
IEEE 802.11ac (también conocido como WiFi 5G o WiFi Gigabit) es una mejora a la norma IEEE 802.11n, se ha desarrollado entre el año 2011 y el 2013, y finalmente aprobada en enero de 2014.
El estándar consiste en mejorar las tasas de transferencia hasta 433 Mbit/s por flujo de datos, consiguiendo teóricamente tasas de 1.3 Gbit/s empleando 3 antenas. Opera dentro de la banda de 5 GHz, amplía el ancho de banda hasta 160 MHz (40 MHz en las redes 802.11n), utiliza hasta 8 flujos MIMO e incluye modulación de alta densidad (256 QAM).
A un Arduino es posible añadirle conectividad Wifi de forma muy sencilla y ampliar las posibilidades de este microcontrolador con comunicación inalámbrica Wifi.
Hay varias formas de añadir hardware Wifi a Arduino, ya sea con un shield, una breakout board específica, con microcontroladores que tenga wifi integrado o con placas Arduinos que tenga chip wifi en la misma placa. Veamos varios casos de estos tipos, como conectarlos y usarlos, así como las librerías a usar en cada caso.
Buena parte de los visto en Ethernet con Arduino, es válido para wifi, puesto que el protocolo tcp/ip usado es el mismo y solo cambia el medio de comunicación. Trasladar un proyecto de ethernet a wifi es sencillo, solo cambiando la librería para usar el hardware y adaptar los comando en función de los métodos que tengan las librerías.
Wifi 5G
La banda de frecuencia de 5GHz es muy diferente a la de 2.4GHz. Como se puede ver en la siguiente ilustración, ofrece mucho más espacio de frecuencia, que proporciona hasta 25 canales posibles. Como se dará cuenta, sin embargo, hay muchas advertencias a la utilización de 5GHz, y el número de canales configurables en los puntos de acceso pueden ser significativamente menos de 25.
Esta ilustración muestra los canales de 5GHz WiFi disponibles en la actualidad en los diferentes anchos de canal. Cortesía de Security Uncorked
Lo más evidente es el esquema de numeración distinto. El primer canal de conexión WiFi es del 36 y el último es el 165. Sin embargo, no todos los canales están disponibles. En lugar de permitir que usted elija cada canal consecutivo (36, 37, 38, etc.), los dispositivos WiFi están configurados para funcionar solo en canales que no se superponen (36, 40, 44, etc.) si se utilizan los canales 20MHz legados. Todos los canales configurables están separados entre sí por cuatro canales, pero hay lagunas (como el salto del canal 64 al 100) debido a que el espacio de frecuencia dado a WiFi no es totalmente continuo.
WiFi Shield
El WiFi Shield de Arduino conecta Arduino a Internet de forma inalámbrica.
Un proyecto hecho con Ethernet pasarlo a wifi con el wifi shield, simplemente se trata de cambiar las líneas de código de la parte de red de la librería ethernet a las equivalentes de la librería wifi.
Arduino WiFi Shield 101 es un shield potente para aplicaciones IoT con autenticación criptográfica, desarrollado con ATMEL, que conecta la placa Arduino a Internet de forma inalámbrica. La conexión a una red WiFi es simple, no se necesita ninguna configuración adicional además del SSID y la contraseña. El WiFi Shield 101 viene con una biblioteca fácil de usar que permite conectar la placa Arduino a Internet con pocas instrucciones. Como siempre, cada elemento de la plataforma – hardware, software y documentación está libremente disponible y de código abierto. Se basa en el módulo Atmel SmartConnect-WINC1500, compatible con la norma IEEE 802.11 b/g/n
Características:
Operating voltage both 3.3V and 5V (supplied from the host board)
Connection via: IEEE 802.11 b/g/n for up to 72 Mbps networks
El módulo wifi WINC1500 integrado es un controlador de red capaz de protocolos TCP y UDP. El Wifi Shield 101 también cuenta con un hardware de seguridad de cifrado / descifrado proporcionado por el chip ATCC508A CryptoAuthentication que es un método ultra seguro para proporcionar un acuerdo clave para el cifrado/descifrado, diseñado específicamente para el mercado de IoT.
El pin digital 7 se utiliza como un pin de handshake entre el shield WiFi 101 y Arduino, y no se debe utilizar. El pin digital 5 se utiliza como pin RESET entre el shield WiFi 101 yArduino, y no debe utilizarse.
Tener en cuenta que Uno + WiFi Shield 101 no es compatible con la biblioteca Serial de software. El WiFi Shield 101 usa una biblioteca que es muy compleja y ocupa más del 60% de la memoria disponible, dejando poco espacio para los sketches. Tener en cuenta que para un uso básico es compatible con el Uno, pero para proyectos complejos se recomienda usar el shield WiFi 101 con un Arduino / Genuino Zero, 101 o Mega 2560.
Es un nuevo Arduino con un microcontrolador que lleva integrado wifi y mucho más. El Arduino MKR1000 ha sido diseñado para ofrecer una solución práctica y económica buscando conectividad WiFi para gente con mínima experiencia en redes.
Este Arduino está basado en la MCU ATSAMW25 especialmente diseñado para proyectos IoT. Este SoC está compuesto de tres bloques principales:
SAMD21 Cortex-M0+ 32bit low power ARM MCU
WINC1500 low power 2.4GHz IEEE® 802.11 b/g/n Wi-Fi
Este Arduino también incluye un circuito para cargar baterías Li-Po y utilizar el MKR1000 alimentándose con este tipo de baterías.
IMPORTANTE: Arduino MKR1000 funciona a 3.3V, el máximo voltaje que pueden tolerar los pines es de 3.3V y aplicar voltajes mayores podría dañar la placa. Mientras que una salida de 5V digital es posible, para una comunicación bidireccional de 5V es necesario level shifting.
Para programar el MKR1000 es necesario añadir al IDE de Arduino soporte para esta placa, ya que el microcontrolador no es un AVR sino un ARM Cortex-M0 de 32 bits. SAMD Core.
El MKR1000 y Arduino Zero tienen unas librerías específicas por su microcontrolador:
El ESP8266 es un chip Wi-Fi de bajo coste con pila TCP/IP completa y capacidad de MCU (Micro Controller Unit) producida por el fabricante chino Espressif Systems, con sede en Shanghai.
El chip primero llegó a la atención de los fabricantes occidentales en agosto de 2014 con el módulo ESP-01. Este pequeño módulo permite a los microcontroladores conectarse a una red Wi-Fi y realizar conexiones TCP/IP sencillas utilizando comandos de tipo Hayes.
En siguientes capítulos se tratará en profundidad.
ESP32 el sucesor de ESP8266
ESP32 es una serie de bajo costo, sistema de bajo consumo de energía en un microcontrolador chip con Wi-Fi integrado y Bluetooth de modo dual. La serie ESP32 utiliza un microprocesador Xtensa LX6 de Tensilica de doble núcleo.
Características:
Processors:
CPU: Xtensa dual-core (or single-core) 32-bit LX6 microprocessor, operating at 160 or 240 MHz and performing at up to 600 DMIPS
Wake up from GPIO interrupt, timer, ADC measurements, capacitive touch sensor interrupt
El ESP32 trae ventajas muy claras frente al modelo anterior, tales como la inclusión de un segundo procesador (es decir, posee 2 núcleos). Además se ha añadido la posibilidad de utilizar Bluetooth Low Energy (BLE), el cual es un atractivo para proyectos de tipo IoT. Se ha expandido la cantidad de GPIOs; y ahora se cuentan con más pines de lecturas análogas a digitales (ADC). Se incluyeron dos pines de salida digital a análoga (DAC), lo cual es sumamente atractivo para ciertos proyectos con audio. Se debe resaltar el hecho que hasta ahora, casi ningún modelo de Arduino o microcontrolador similar posee un DAC integrado.
Al poseer un segundo núcleo, este se dedica únicamente para manejar los eventos de WiFi (por defecto), aunque se le pueden asignar tareas específicas. Esto permite una ventaja contra el ESP8266, el cual tiene que detener ciertos eventos para procesar las actividades del WiFi. Otra de las ventajas es la posibilidad de utilizar más sensores de lecturas analógicas sin la necesidad de utilizar multiplexores.
Hypertext Transfer Protocol o HTTP (en español protocolo de transferencia de hipertexto) es el protocolo de comunicación que permite las transferencias de información en la WWW. Se trata de un protocolo de capa 7 de aplicación.
En arduino con la librería ethernet solo trabajamos con la capa de aplicación, todas las otras capas de la pila TCP/IP ya están implementadas por Hardware, ya sea con la ethernet shield o el módulo WiFi correspondiente. Aunque si queremos realizar algunas funciones de capas inferiores, podemos hacerlo con los comandos adecuados comunicándonos con el chip ethernet o wifi via SPI.
Veamos algunos protocolos de la capa de aplicación que serán los que tengamos que implementar en nuestro arduino directamente o usando la librería adecuada:
HTTP es un protocolo muy importante puesto que es el que se va a usar para comunicar Arduino con cualquier elemento de la WWW o de una intranet. En el IoT es uno de los protocolos más usados y sobre todo si queremos obtener o mandar datos a servidores o usar las APIs que nos ofrecen algunos servicios para obtención de información, por ejemplo, para obtener el tiempo meteorológico de la AEMET https://opendata.aemet.es/centrodedescargas/inicio y con esos datos que Arduino actúe de una forma u otra.
Hypertext Transfer Protocol o HTTP (en español protocolo de transferencia de hipertexto) es el protocolo usado en cada transacción de la World Wide Web. HTTP fue desarrollado por el World Wide Web Consortium y la Internet Engineering Task Force.
HTTP define la sintaxis y la semántica que utilizan los elementos de software de la arquitectura web (clientes, servidores, proxies) para comunicarse. Es un protocolo orientado a transacciones y sigue el esquema petición-respuesta entre un cliente y un servidor. Al cliente que efectúa la petición (un navegador web) se lo conoce como «user agent» (agente del usuario). A la información transmitida se la llama recurso y se la identifica mediante un localizador uniforme de recursos (URL).
HTTP es un protocolo sin estado, es decir, que no guarda ninguna información sobre conexiones anteriores. El desarrollo de aplicaciones web necesita frecuentemente mantener estado. Para esto se usan las cookies, que es información que un servidor puede almacenar en el sistema cliente. Esto le permite a las aplicaciones web instituir la noción de «sesión», y también permite rastrear usuarios ya que las cookies pueden guardarse en el cliente por tiempo indeterminado.
Una transacción HTTP está formada por un encabezado seguido, opcionalmente, por una línea en blanco y algún dato. El encabezado especificará cosas como la acción requerida del servidor, o el tipo de dato retornado, o el código de estado. El uso de campos de encabezados enviados en las transacciones HTTP le dan gran flexibilidad al protocolo. Estos campos permiten que se envíe información descriptiva en la transacción, permitiendo así la autenticación, cifrado e identificación de usuario. Ejemplos de encabezados: HTTP_ACCEPT y HTTP_USER_AGENT.
Lo más importante para comunicar arduino por HTTP con otros dispositivos, ya sean servidores, ordenadores, otros Arduinos, etc… es conocer los métodos GET y POST del protocolo HTTP. HTTP define 8 métodos que indica la acción que desea que se efectúe sobre el recurso identificado. Lo que este recurso representa, si los datos pre-existentes o datos que se generan de forma dinámica, depende de la aplicación del servidor. A menudo, el recurso corresponde a un archivo o la salida de un ejecutable que residen en el servidor.
GET
GET: Pide una representación del recurso especificado. Por seguridad no debería ser usado por aplicaciones que causen efectos ya que transmite información a través de la URI agregando parámetros a la URL. La petición puede ser simple, es decir en una línea o compuesta de la manera que muestra el ejemplo.
Ejemplo simple:
GET /images/logo.png HTTP/1.1 obtiene un recurso llamado logo.png
Ejemplo con parámetros:
GET /index.php?page=main&lang=es HTTP/1.1
POST
POST: Envía los datos para que sean procesados por el recurso identificado. Los datos se incluirán en el cuerpo de la petición. Esto puede resultar en la creación de un nuevo recurso o de las actualizaciones de los recursos existentes o ambas cosas.
Un cliente HTTP debe formar una petición HTTP (request) al servidor de una forma determinada para que sea entendida por el servidor. Cuando Arduino trabaja como cliente hay que programar esta petición correctamente, sino el servidor nos mandará un mensaje de error.
Formación de un HTTP request, esta petición habrá que programar en Arduino:
HTTP/1.1 se definió en el estándar RFC2616,que es la más usada actualmente. En junio de 2014 RFC2616 se retiró y HTTP/1.1 se redefinió en RFCs 7230, 7231, 7232, 7233, 7234, and 7235, HTTP/2 está en proceso de definición.
Para cumplir con el protocolo HTTP, arduino debe implementar estas respuestas cuando lo uso como servidor web, como devolución a un request mandado por un cliente como puede ser un browser o navegador. De esta forma puedo implementar en Arduino una web embebida.
Por lo tanto Arduino podemos programarlo para comportarse como cliente, como servidor o como ambos.
Veamos esto gráficamente:
Ejercicio: Ver las tramas HTTP con las funciones de depuración del navegador y también con wireshark, un web sniffer on-line y algún plugin para el navegador.
Para poder implementar un servidor web embebido en un Arduino e interactuar con él, se debe programar los mensajes http en Arduino para responder al navegador de forma adecuada.
La secuencia que se produce en una web embebida para encender y apagar un led es:
El navegador manda un http request GET a la IP de Arduino cuando pongo su IP en el navegador. p.e. http://192.168.1.15
Arduino recibe la petición que comienza por «GET / HTTP/1.1»
Arduino devuelve el http response con «HTTP/1.0 200K» y luego la web con el código html, haciendo print sobre el cliente ethernet y cierra la comunicación.
El navegador recibe el http respnse y muestra la web, en este caso un botón.
Al pulsar el botón en el navegador, el código HTML ya está configurado para mandar una petición POST.
Arduino recibe la petición que comienza por «POST / HTTP/1.1” y enciende o apaga el led según corresponda.
Luego Arduino muestra la web con el estado del led actualizado.
Ver este proceso con wireshark o con las herramienta de desarrollador del navegador pulsando F12.
Para poder añadir conectividad de Ethernet a Arduino disponemos de varios tipos de Ethernet Shield y breakout boards, pero principalmente el chip que tiene el interfaz ethernet y la pila de protocolos TCP/IP es el chip Wiznet W5100 y más recientemente el W5500, pero podemos encontrarnos shields intermedios basados en el W5200. La librería a usar dependerá del chip ethernet usado al estilo de un driver en un ordenador.
Existen otras shields o breakout boards basadas en otros chips y con otras librerías como el ENC28J60:
El Arduino Ethernet Shield V1 nos da la capacidad de conectar un Arduino a una red ethernet. Es la parte física que implementa la pila de protocolos TCP/IP.
Ethernet Shield permite a una placa Arduino conectarse a internet. Está basada en el chip ethernet Wiznet W5100. El Wiznet W5100 provee de una pila de red IP capaz de soportar TCP y UDP. Soporta hasta cuatro conexiones de sockets simultáneas. Usa la librería Ethernet para escribir programas que se conecten a internet usando la shield.
El shield provee un conector ethernet estándar RJ45. La ethernet shield dispone de unos conectores que permiten conectar a su vez otras placas encima y apilarlas sobre la placa Arduino.
Arduino usa los pines digitales 10, 11, 12, y 13 (SPI) para comunicarse con el W5100 en la ethernet shield. Estos pines no pueden ser usados para e/s genéricas. El botón de reset en la shield resetea ambos, el W5100 y la placa Arduino.
El jumper soldado marcado como “INT” puede ser conectado para permitir a la placa Arduino recibir notificaciones de eventos por interrupción desde el W5100, pero esto no está soportado por la librería Ethernet. El jumper conecta el pin INT del W5100 al pin digital 2 de Arduino.
La shield contiene varios LEDs para información:
ON: indica que la placa y la shield están alimentadas
LINK: indica la presencia de un enlace de red y parpadea cuando la shield envía o recibe datos
100M: indica la presencia de una conexión de red de 100 Mb/s (de forma opuesta a una de 10Mb/s)
Opera a 5V suministrados desde la placa de Arduino
El controlador ethernet es el W5100 con 16K de buffer interno. No consume memoria.
El shield se comunica con el microcontrolador por el bus SPI, por lo tanto para usarlo siempre debemos incluir la libreria SPI.h: http://arduino.cc/en/Reference/SPI
El shield dispone de un lector de tarjetas micro-SD que puede ser usado para guardar ficheros y servirlos sobre la red. Para ello es necesaria la librería SD: http://arduino.cc/en/Reference/SD
Al trabajar con la SD, el pin 4 es usado como SS.
Nuestro Arduino UNO se comunica con W5100 y la tarjeta SD usando el bus SPI a través del conector ICSP. Por este motivo los pines 10, 11, 12 y 13 en el UNO y los 50, 51, 52 y 53 en el Mega no podrán usarse. En ambas placas los pines 10 y 4 se usan para seleccionar el W5100 y la tarjeta SD.
El W5100 y el SD no pueden trabajar simultáneamente y debemos tener cuidado al usar ambos de forma conjunta.
El Ethernet shield es compatible con PoE gracias a un módulo adicional que extrae la energía eléctrica del cable ethernet, anteriormente inyectada desde el switch.
Las características del módulo PoE:
IEEE802.3af compliant
Low output ripple and noise (100mVpp)
Input voltage range 36V to 57V
Overload and short-circuit protection
9V Output
High efficiency DC/DC converter: typ 75% @ 50% load
Arduino Ethernet Shield V1 es una placa que aparece en la web de arduino.cc como retirado, pero sigue estando disponible como clones o versiones derivadas.
El Ethernet shield es compatible con PoE gracias a un módulo adicional que extrae la energía eléctrica del cable ethernet, anteriormente inyectada desde el switch.
Las características del módulo PoE:
IEEE802.3af compliant
Low output ripple and noise (100mVpp)
Input voltage range 36V to 57V
Overload and short-circuit protection
9V Output
High efficiency DC/DC converter: typ 75% @ 50% load
Configurar Arduino con el ethernet shield de forma que le asignamos una IP fija con la siguiente configuración:
IP: 192.168.6.1YY. Siendo YY el número = 30 + número del kit. Por ejemplo para el kit 4 la IP es la 192.168.6.134 y para el kit 16 la IP es es 192.168.6.146.
El Ethernet shield tiene disponible una ranura para tarjetas microSD. Arduino es capaz de leer y escribir en la tarjeta microSD mediante la librería SD: https://www.arduino.cc/en/Reference/SD
Leer la documentación de la librería SD y entender qué hace cada una de las clases y sus métodos.
Insertar una tarjeta microSD y hacer un programa que grabe los datos de temperatura en un archivo llamado temp_log.csv cada 5 segundos. Los datos a guardar son: segundos desde inicio con la función millis() y la temperatura del sensor TMP36.
Opcionalmente crear un menú con 3 opciones:
1 – Muestra el último dato guardado en la SD
2 – Vuelca el contenido del fichero temp_log.csv por consola
El modelo TCP/IP describe un conjunto de guías generales de diseño e implementación de protocolos de red específicos para permitir que un equipo pueda comunicarse en una red. TCP/IP provee conectividad de extremo a extremo especificando como los datos deberían ser formateados, direccionados, transmitidos, enrutados y recibidos por el destinatario.
La importancia del modelo TCP/IP es que es el modelo usado para acceder a Internet o a redes internas (Intranet) de ordenadores. Arduino va a permitir conectarse a Internet o a una red interna mediante TCP/IP y poder realizar múltiples operaciones o usarse como pasarela para conectar a Internet dispositivos que no tienen esa capacidad. La implementación de la pila de protocolos de TCP/IP en Arduino se hace mediante un shield o HW adicional que nos da la capa de acceso a red (ethernet o WiFi), internet (IP) y transporte. La capa de aplicación deberemos implementarla dentro de Arduino ya sea directamente o mediante una librería.
En el caso del protocolo TCP/IP la pila OSI se simplifica:
Capa de Aplicación.
Invoca programas que acceden servicios en la red. Interactúan con uno o más protocolos de transporte para enviar o recibir datos, en forma de mensajes o bien en forma de flujos de bytes.
Capa de Transporte.
Provee comunicación extremo a extremo desde un programa de aplicación a otro. Regula el flujo de información. Puede proveer un transporte confiable asegurándose que los datos lleguen sin errores y en la secuencia correcta. Coordina a múltiples aplicaciones que se encuentren interactuando con la red simultáneamente de tal manera que los datos que envíe una aplicación sean recibidos correctamente por la aplicación remota, esto lo hace añadiendo identificadores de cada una de las aplicaciones. Realiza además una verificación por suma, para asegurar que la información no sufrió alteraciones durante su transmisión.
Capa Internet.
Controla la comunicación entre un equipo y otro, decide qué rutas deben seguir los paquetes de información para alcanzar su destino. Conforma los paquetes IP que será enviados por la capa inferior. Desencapsula los paquetes recibidos pasando a la capa superior la información dirigida a una aplicación.
Capa de Interfaz de Red.
Emite al medio físico los flujos de bit y recibe los que de él provienen. Consiste en los manejadores de los dispositivos que se conectan al medio de transmisión.
Los elementos de red (switches, routers, etc…) no llegan hasta la última capa y se podría representar así la comunicación entre dos dispositivos.
Algunos elementos de la red de comunicación pueden llegar a capas superiores a la de red e incluso hasta la capa de aplicación como los firewalls para detectar ataques en capas superiores. Es el caso de firewalls de estado y de aplicación. Un cortafuegos de aplicación puede filtrar protocolos de capas superiores tales como FTP, TELNET, DNS, DHCP, HTTP, TCP, UDP y TFTP (GSS). Por ejemplo, si una organización quiere bloquear toda la información relacionada con una palabra en concreto, puede habilitarse el filtrado de contenido para bloquear esa palabra en particular. No obstante, los cortafuegos de aplicación resultan más lentos que los de estado.
Direccionamiento IP
TCP/IP utiliza un identificador denominado dirección internet o dirección IP, cuya longitud es de 32 bytes. La dirección IP identifica tanto a la red a la que pertenece una computadora como a ella misma dentro de dicha red.
Longitud de 32 bits.
Identifica a las redes y a los nodos conectados a ellas.
Especifica la conexión entre redes.
Se representan mediante cuatro octetos, escritos en formato decimal, separados por puntos.
Existen ciertas direcciones en cada clase de dirección IP que no están asignadas y que se denominan direcciones privadas. Las direcciones privadas pueden ser utilizadas por los hosts que usan traducción de dirección de red (NAT) para conectarse a una red pública o por los hosts que no se conectan a Internet. En una misma red no pueden existir dos direcciones iguales, pero sí se pueden repetir en dos redes privadas que no tengan conexión entre sí o que se conecten mediante el protocolo NAT. Las direcciones privadas son:
Clase B: 172.16.0.0 a 172.31.255.255 (16 bits red, 16 bits hosts). 16 redes clase B contiguas, uso en universidades y grandes compañías.
Clase C: 192.168.0.0 a 192.168.255.255 (24 bits red, 8 bits hosts). 256 redes clase contiguas, uso de compañías medianas y pequeñas además de pequeños proveedores de internet (ISP).
Clases de direcciones IP:
Clases
Número de Redes
Número de Nodos
Rango de Direcciones IP
A
127
16,777,215
1.0.0.0 a la 127.0.0.0
B
4095
65,535
128.0.0.0 a la 191.255.0.0
C
2,097,151
255
192.0.0.0 a la 223.255.255.0
Subredes en IP:
Las subredes deben identificarse usando una máscara de subred.
La máscara de subred es de cuatro bytes y para obtener el número de subred se realiza un operación AND lógica entre ella y la dirección IP de algún equipo.
La máscara de subred deberá ser la misma para todos los equipos de la red IP.
El enrutamiento sirve para alcanzar redes distantes. Las direcciones IP se agrupan en clases. Ahora bien para cada clase se pueden contar con un número determinados de subredes. Las subredes son redes físicas independientes que comparten la misma dirección IP (es decir aquella que identifica a la red principal). La pregunta entonces es ¿cómo se logra que equipos que comparten el mismo identificador de red pero se sitúan en redes físicas diferentes podrán comunicarse usando compuertas? La solución a este problema es determinando una máscara de dirección.
Supóngase que la dirección IP de una equipo es 148.206.257.2. La máscara de subred es 255.255.255.0. El equipo por tanto está en la subred 148.206.257.0
Una dirección IP dinámica es una IP asignada mediante un servidor DHCP (Dynamic Host Configuration Protocol) al usuario. La IP que se obtiene tiene una duración máxima determinada. El servidor DHCP provee parámetros de configuración específicos para cada cliente que desee participar en la red IP. Entre estos parámetros se encuentra la dirección IP del cliente.
Las IP dinámicas son las que actualmente ofrecen la mayoría de operadores. El servidor del servicio DHCP puede ser configurado para que renueve las direcciones asignadas cada tiempo determinado.
Protocolo de Mensajes de Control de Internet ICMP (Internet Control Message Protocol)
Reporta sobre destinos inalcanzables.
Control de flujo de datagramas y congestión.
Controla los requerimiento de cambio de rutas entre compuertas.
Detecta rutas circulares o excesivamente largas.
Verifica la existencia de trayectorias hacia alguna red y el estatus de la misma.
La función de la dirección IPv6 es exactamente la misma que la de su predecesor IPv4, pero dentro del protocolo IPv6. Está compuesta por 128 bits y se expresa en una notación hexadecimal de 32 dígitos. IPv6 permite actualmente que cada persona en la Tierra tenga asignados varios millones de IPs, ya que puede implementarse con 3.4×10E38 hosts direccionables. La ventaja con respecto a la dirección IPv4 es obvia en cuanto a su capacidad de direccionamiento.
IPv6 admite 340.282.366.920.938.463.463.374.607.431.768.211.456 (340 sextillones de direcciones) —cerca de 6,7E17 (670 mil billones) de direcciones por cada milímetro cuadrado de la superficie de La Tierra.
Su representación suele ser hexadecimal y para la separación de cada par de octetos se emplea el símbolo «:». Un bloque abarca desde 0000 hasta FFFF. Algunas reglas de notación acerca de la representación de direcciones IPv6 son:
En las redes, la dirección MAC (siglas en inglés de media access control; en español «control de acceso al medio») es un identificador de 48 bits (6 bloques hexadecimales) que corresponde de forma única a una tarjeta o dispositivo de red. Se conoce también como dirección física, y es única para cada dispositivo. Está determinada y configurada por el IEEE (los últimos 24 bits) y el fabricante (los primeros 24 bits) utilizando el organizationally unique identifier. La mayoría de los protocolos que trabajan en la capa 2 del modelo OSI usan una de las tres numeraciones manejadas por el IEEE: MAC-48, EUI-48, y EUI-64, las cuales han sido diseñadas para ser identificadores globalmente únicos. No todos los protocolos de comunicación usan direcciones MAC, y no todos los protocolos requieren identificadores globalmente únicos.
Las direcciones MAC son únicas a nivel mundial, puesto que son escritas directamente, en forma binaria, en el hardware en su momento de fabricación.
En Arduino es importante poner la dirección MAC correcta para evitar problemas.
En el caso del shield ethernet, la MAC no está incluida en el integrado que implementa la pila de protocolos TCP/IP, sino que se debe configurar y eso lo hace Arduino desde el setup().
El protocolo UDP es un protocolo no orientado a conexión. Es decir cuando una máquina A envía paquetes a una máquina B, el flujo es unidireccional. La transferencia de datos es realizada sin haber realizado previamente una conexión con la máquina de destino (maquina B), y el destinatario recibirá los datos sin enviar una confirmación al emisor (la máquina A). Esto es debido a que la encapsulación de datos enviada por el protocolo UDP no permite transmitir la información relacionada al emisor. Por ello el destinatario no conocerá al emisor de los datos excepto su IP.
Su uso principal es para protocolos como DHCP, BOOTP, DNS y demás protocolos en los que el intercambio de paquetes de la conexión/desconexión son mayores, o no son rentables con respecto a la información transmitida, así como para la transmisión de audio y vídeo en real, donde no es posible realizar retransmisiones por los estrictos requisitos de retardo que se tiene en estos casos.
Al contrario que UDP, el protocolo TCP está orientado a conexión. Cuando una máquina A envía datos a una máquina B, la máquina B es informada de la llegada de datos, y confirma su buena recepción. Aquí interviene el control CRC de datos que se basa en una ecuación matemática que permite verificar la integridad de los datos transmitidos. De este modo, si los datos recibidos son corruptos, el protocolo TCP permite que los destinatarios soliciten al emisor que vuelvan a enviar los datos corruptos.
Muchos programas dentro de una red de datos compuesta por redes de ordenadores, pueden usar TCP para crear “conexiones” entre sí a través de las cuales puede enviarse un flujo de datos. El protocolo garantiza que los datos serán entregados en su destino sin errores y en el mismo orden en que se transmitieron. También proporciona un mecanismo para distinguir distintas aplicaciones dentro de una misma máquina, a través del concepto de puerto.
TCP da soporte a muchas de las aplicaciones más populares de Internet (navegadores, intercambio de ficheros, clientes FTP, etc.) y protocolos de aplicación HTTP, SMTP, SSH y FTP.
TCP usa el concepto de número de puerto para identificar a las aplicaciones emisoras y receptoras. Cada lado de la conexión TCP tiene asociado un número de puerto (de 16 bits sin signo, con lo que existen 65536 puertos posibles) asignado por la aplicación emisora o receptora. Los puertos son clasificados en tres categorías:
bien conocidos,
registrados, y
dinámicos/privados.
Los puertos bien conocidos son asignados por la Internet Assigned Numbers Authority (IANA), van del 0 al 1023 y son usados normalmente por el sistema o por procesos con privilegios. Las aplicaciones que usan este tipo de puertos son ejecutadas como servidores y se quedan a la escucha de conexiones. Algunos ejemplos son: FTP (21), SSH (22), Telnet (23), SMTP (25) y HTTP (80).
Los puertos registrados son normalmente empleados por las aplicaciones de usuario de forma temporal cuando conectan con los servidores, pero también pueden representar servicios que hayan sido registrados por un tercero (rango de puertos registrados: 1024 al 49151).
Los puertos dinámicos/privados también pueden ser usados por las aplicaciones de usuario, pero este caso es menos común. Los puertos dinámicos/privados no tienen significado fuera de la conexión TCP en la que fueron usados (rango de puertos dinámicos/privados: 49152 al 65535.
Los protocolos TCP y UDP usan el concepto de puerto. Un lista de los puertos bien conocidos es
El proceso de establecimiento de una conexión TCP se denomina “three way handshake” Durante el establecimiento de la conexión, se configuran algunos parámetros tales como el número de secuencia con el fin de asegurar la entrega ordenada de los datos y la robustez de la comunicación.
El método “three way handshake” crea una conexión entre cliente y servidor que se realiza mediante tres pasos donde el cliente y servidor intercambian paquetes SYN y ACK (acknowledgment) antes de de que la comunicación real comience.
Aunque es posible que un par de entidades finales comiencen una conexión entre ellas simultáneamente, normalmente una de ellas abre un socket en un determinado puerto TCP y se queda a la escucha de nuevas conexiones. Es común referirse a esto como apertura pasiva, y determina el lado servidor de una conexión.
El lado cliente de una conexión realiza una apertura activa de un puerto enviando un paquete SYN inicial al servidor como parte de la negociación en tres pasos. En el lado del servidor (este receptor también puede ser una PC o alguna estación terminal) se comprueba si el puerto está abierto, es decir, si existe algún proceso escuchando en ese puerto, pues se debe verificar que el dispositivo de destino tenga este servicio activo y esté aceptando peticiones en el número de puerto que el cliente intenta usar para la sesión. En caso de no estarlo, se envía al cliente un paquete de respuesta con el bit RST activado, lo que significa el rechazo del intento de conexión. En caso de que sí se encuentre abierto el puerto, el lado servidor respondería a la petición SYN válida con un paquete SYN/ACK. Finalmente, el cliente debería responderle al servidor con un ACK, completando así la negociación en tres pasos (SYN, SYN/ACK y ACK) y la fase de establecimiento de conexión. Es interesante notar que existe un número de secuencia generado por cada lado, ayudando de este modo a que no se puedan establecer conexiones falseadas (spoofing).
La fase de finalización de la conexión utiliza una negociación en cuatro pasos (four-way handshake), terminando la conexión desde cada lado independientemente. Sin embargo, es posible realizar la finalización de la conexión en 3 fases; enviando el segmento FIN y el ACK en uno solo. Cuando uno de los dos extremos de la conexión desea parar su «mitad» de conexión transmite un segmento con el flag FIN en 1, que el otro interlocutor confirmará con un ACK. Por tanto, una desconexión típica requiere un par de segmentos FIN y ACK desde cada lado de la conexión.
Una conexión puede estar «medio abierta» en el caso de que uno de los lados la finalice pero el otro no. El lado que ha dado por finalizada la conexión no puede enviar más datos pero la otra parte si podrá.
Es importante conocer este apartado porque a pesar que esta negociación la hace el shield de Ethernet o Wifi y no se programa en Arduino, sirve para saber qué está pasando cuando Arduino actúa como cliente o servidor y poder hacer depuración cuando tenemos errores.
Todo este proceso o cualquier otro podemos verlo con una analizado de protocolos como wireshark: https://www.wireshark.org/
Práctica: Three Way Handshake
Ver con el wireshark el proceso de 3 way handshake:
Cargar el sketch de ejemplo de Arduino WebServer que puede encontrarse en Archivo — Ejemplos — Ethernet — Webserver
Desde el ordenador donde hemos instalado wireshark, abrir y comenzar a capturar datos. Para evitar la saturación de datos poner en wireshark el filtro: “ip.addr == 192.168.1.177” o la IP que hayamos configurado el Arduino.
NOTA: recordar que deben estar en la misma red y debemos configurar la IP correcta a nuestra red en el sketch Webserver.
Ver en wireshark el intercambio de paquetes y los número de secuencia, así como la finalización de la comunicación.
Aprendiendo Arduino 