Archivo de la etiqueta: Redes

Protocolo HTTP

Protocolo HTTP

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.

Más información sobre HTTP:

Para intercambio de archivos por HTTP usamos MIME: http://es.wikipedia.org/wiki/Multipurpose_Internet_Mail_Extensions

Líneas de encabezado o headers, son muy importantes y dan información adicional de la conexión y el comportamiento puede cambiar en función de ellas:

Interesante HTTP quick guide: https://www.tutorialspoint.com/http/http_quick_guide.htm

Métodos de Petición HTTP

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.

Los otros métodos de HTTP:

Más información:

Entender los métodos get y post:

Un explicación muy buena de HTTP también se puede encontrar en:  http://www.ntu.edu.sg/home/ehchua/programming/webprogramming/HTTP_Basics.html

HTTP request

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:

Trama en HTTP, fijaros en el uso de cr (retorno de carro – carriage return – ASCII 13) y lf (line feed – nueva linea – ASCII 10): http://www1.ju.edu.jo/ecourse/abusufah/cpe532_Spr06/notes/BookOnLine/HTTP%20Request%20Message.htm

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.

Y cuando usar GET o POST?: http://www.w3.org/2001/tag/doc/whenToUseGet.html#checklist

HTTP response

Después de recibir e interpretar el servidor un HTTP request, el servidor debe responder con un mensaje de respuesta:

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.

Listado de web sniffers: http://scraping.pro/web-sniffers-review/

Servidor Web Embebido en Arduino

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.

Ver sketch en: https://github.com/jecrespo/aprendiendoarduino-Curso_Arduino_2017/tree/master/Ejercicio40-Boton_Mejorado_DHCP

Diagrama de flujo:

Más información:

Programa botón para diferentes Arduino. Comparar:

Librerías HTTP

Libreria Webduino

Webduino es una librería muy popular que nos permite implementar un servidor web en nuestro Arduino.

La web del creador: https://code.google.com/p/webduino/

El reference de la librería: https://code.google.com/p/webduino/wiki/Documentation

Repositorio de la librería: https://github.com/sirleech/Webduino

Snippet Webduino en el playground: http://playground.arduino.cc/Main/WebduinoFileServer

Para Shields con Microchip ENC28J60 no es válida esta librería puesto que necesita SW adicional para implementar la pila TCP/IP.

Una presentación que explica como funciona: https://docs.google.com/presentation/d/1QUG4XJTK3jKtU-eYUfM1DvUdRaKBrp__LEwZQfz9s6E/edit#slide=id.i0

Hilo de soporte de la librería: http://forum.arduino.cc/index.php/topic,37851.0.html

Ejercicio 29-Webduino Entender cómo funciona la librería y ver el ejemplo webdemo

Luego hacer la aplicación web buzzer.

Streaming: http://arduiniana.org/libraries/streaming/

Class Templates: http://www.cprogramming.com/tutorial/templates.html

Solución en https://github.com/jecrespo/Aprendiendo-Arduino/tree/master/Ejercicio29-Webduino

Otras Librerías

Otras librerías para implementar un servidor web en Arduino:

Y una librería para implementar un cliente HTTP:

Librería http client: https://github.com/amcewen/HttpClient

Anuncios

Protocolo TCP/IP

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.

Más información: https://es.wikipedia.org/wiki/Modelo_TCP/IP

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.

Más información en: http://www.uca.edu.sv/investigacion/tutoriales/tcp-ip.html

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 A: 10.0.0.0 a 10.255.255.255 (8 bits red, 24 bits hosts).
  • 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.

Más información de DHCP: http://es.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol

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:

Los ceros iniciales se pueden obviar.

Ejemplo: 2001:0123:0004:00ab:0cde:3403:0001:0063 -> 2001:123:4:ab:cde:3403:1:63

Los bloques contiguos de ceros se pueden comprimir empleando “::”. Esta operación sólo se puede hacer una vez.

Más información en: http://es.wikipedia.org/wiki/IPv6

Más información sobre el direccionamiento IP en: http://es.wikipedia.org/wiki/Direcci%C3%B3n_IP

Ethernet: http://es.wikipedia.org/wiki/Ethernet

Dirección MAC

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().

Más información en: http://es.wikipedia.org/wiki/Direcci%C3%B3n_MAC

Tutorial TCP/IP: http://www.uca.edu.sv/investigacion/tutoriales/tcp-ip.html

Nivel de Transporte: TCP y UDP

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.

Más información:

La librería Ethernet de Arduino dispone de la clase EthernetUDP que permite enviar y recibir mensajes UDP. Ver https://www.arduino.cc/en/Reference/Ethernet

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

Más información:

Conexión y Desconexión TCP/IP

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).

Más información:

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:

Instalar wireshark de su página: https://www.wireshark.org/

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.

Tema 6 – Comunicaciones con Arduino

  • Conceptos básicos de comunicaciones. Capas OSI.
  • TCP/IP. Protocolo HTTP.
  • Librería Ethernet. Shield Ethernet y W5100.
  • I2C/TWI
  • SPI
  • Firmata (próximamente)
  • Bluetooth (próximamente)
  • ZigBee/XBee (próximamente)
  • Internet de las cosas (IoT) (próximamente)
  • Otras comunicaciones: zigbee, RF, … (próximamente)

Conceptos básicos de comunicaciones. Capas OSI

La telemática es una disciplina científica y tecnológica, originada por la convergencia entre las tecnologías de las telecomunicaciones y de la informática.

Algunas de las aplicaciones de la telemática podrían ser cualquiera de las siguientes:

  • Cualquier tipo de comunicación a través de internet (como por ejemplo el acceso a páginas web o el envío de correos electrónicos) es posible gracias al uso de las tecnologías desarrolladas en este ámbito.
  • El uso de las mensajerías instantáneas está directamente relacionado con la telemática, ya que esta materia se encarga en parte de controlar ese intercambio de mensajes entre dos entidades distintas.
  • Los sistemas GPS (Global Positioning System).

http://es.wikipedia.org/wiki/Telem%C3%A1tica

Un protocolo de comunicaciones es un conjunto de normas que están obligadas a cumplir todos las máquinas y programas que intervienen en una comunicación de datos entre ordenadores, o cualquier otro dispositivo sin las cuales la comunicación resultaría caótica y por tanto imposible.

En nuestro caso vamos a ver Arduino como el elemento para comunicar cualquier elemento físico con Internet usando diversos protocolos estándar. Es lo que se ha venido a llamar M2M, dispositivos conectados o IoT.

A continuación se esbozan algunos ejemplos de protocolos de comunicaciones con la intención de aclarar el concepto y la evolución de los mismos:

  • Protocolos punto a punto: Son los protocolos más antiguos y elementales utilizados para la comunicación mediante una línea de datos entre dos únicos ordenadores. Un ejemplo es la comunicación serie que ya hemos visto.
  • Comunicación entre redes. Además de los protocolos punto a punto, han de especificar la forma de identificar al terminal concreto de la red con el que se debe establecer la comunicación en el caso de que las máquinas que se están comunicando directamente sean servidores de una red local (LAN). Por ejemplo asignando un número a cada uno de los terminales.
  • Protocolos de transmisión de paquetes. En los protocolos de transmisión de paquetes la transmisión se apoya en la propia información contenida en los datos que transitan por las redes de comunicaciones, mientras que en los protocolos anteriores, la responsabilidad del buen funcionamiento de las comunicaciones recae sobre los equipos y las líneas de datos. Para ello los datos se “trocean” y organizan en paquetes, como cartas de correo ordinario, con sus datos de origen y destino y van de equipo en equipo como las cartas van de estafeta en estafeta, de tren correo a camión de reparto y de otra estafeta al bolso del cartero quien finalmente la hace llegar a su destinatario.
  • El protocolo TCP/IP. TCP/IP son las siglas de “Transfer Control Protocol / Internet Protocol” y éste es el conjunto de normas de transporte, estableciendo y definiendo el lenguaje para la Red Internet e incorporado por otras redes. TCP/IP es un protocolo de transmisión de paquetes. Cuando un ordenador quiere mandar a otro un fichero de datos, lo primero que hace es partirlo en trozos pequeños (alrededor de unos 4 Kb) y posteriormente enviar cada trozo por separado. Cada paquete de información contiene la dirección en la Red donde ha de llegar, y también la dirección de remite, por si hay que recibir respuesta. Los paquetes viajan por la Red de forma independiente.
    Otra consecuencia de la estructura y forma de actuar de TCP/IP es que admite la eventualidad de que algún paquete de información se pierda por el camino por algún suceso indeseado como que un ordenador intermediario se apague o se sature cuando está pasando por él un trozo de un determinado fichero en transmisión. Si esto ocurre, siempre queda abierta la posibilidad de volver a solicitar el paquete perdido, y completar la información sin necesidad de volver a transferir todo el conjunto de datos.

Más información en: http://www.desarrolloweb.com/articulos/1617.php

Si bien los protocolos pueden variar mucho en propósito y sofisticación, la mayoría especifica una o más de las siguientes propiedades:

  • Detección de la conexión física subyacente (con cable o inalámbrica), o la existencia de otro punto final o nodo.
  • Handshaking, es un proceso automatizado de negociación que establece de forma dinámica los parámetros de un canal de comunicaciones establecido entre dos entidades antes de que comience la comunicación normal por el canal. De ello se desprende la creación física del canal y precede a la transferencia de información normal.
  • Negociación de varias características de la conexión.
  • Cómo iniciar y finalizar un mensaje.
  • Procedimientos en el formateo de un mensaje.
  • Qué hacer con mensajes corruptos o formateados incorrectamente (corrección de errores).
  • Cómo detectar una pérdida inesperada de la conexión, y qué hacer entonces.
  • Terminación de la sesión y/o conexión.
  • Estrategias para mejorar la seguridad (autenticación, cifrado).
  • Cómo se construye una red física.
  • Cómo los computadores o dispositivos se conectan a la red.

Los protocolos de comunicación permiten el flujo información entre equipos que manejan lenguajes distintos, por ejemplo, dos computadores conectados en la misma red pero con protocolos diferentes no podrían comunicarse jamás, para ello, es necesario que ambas “hablen” el mismo idioma. El protocolo TCP/IP fue creado para las comunicaciones en Internet. Para que cualquier computador o dispositivo se conecte a Internet es necesario que tenga instalado este protocolo de comunicación.

Más información en: http://es.wikipedia.org/wiki/Protocolo_de_comunicaciones

En el campo de las redes informáticas, los protocolos se pueden dividir en varias categorías. Una de las clasificaciones más estudiadas es la OSI.

Según la clasificación OSI, la comunicación de varios dispositivos se puede estudiar dividiéndola en 7 niveles, que son expuestos desde su nivel más alto hasta el más bajo:

Nivel Nombre Categoría
Capa 7 Nivel de aplicación Aplicación
Capa 6 Nivel de presentación
Capa 5 Nivel de sesión
Capa 4 Nivel de transporte
Capa 3 Nivel de red Transporte de datos
Capa 2 Nivel de enlace de datos
Capa 1 Nivel físico

Pinchando en cada capa hay una explicación para cada capa.

  • Capa física: Es la que se encarga de la topología de la red y de las conexiones globales de la computadora hacia la red, tanto en lo que se refiere al medio físico como a la forma en la que se transmite la información.
    http://es.wikipedia.org/wiki/Capa_f%C3%ADsica
  • Capa de enlace de datos: Esta capa se ocupa del direccionamiento físico, del acceso al medio, de la detección de errores, de la distribución ordenada de tramas y del control del flujo. Es uno de los aspectos más importantes que revisar en el momento de conectar dos ordenadores, ya que está entre la capa 1 y 3 como parte esencial para la creación de sus protocolos básicos, para regular la forma de la conexión entre computadoras así determinando el paso de tramas (trama = unidad de medida de la información en esta capa, que no es más que la segmentación de los datos trasladándolos por medio de paquetes)
    http://es.wikipedia.org/wiki/Capa_de_enlace_de_datos
  • Capa de red: Se encarga de identificar el enrutamiento existente entre una o más redes. Las unidades de información se denominan paquetes, y se pueden clasificar en protocolos enrutables y protocolos de enrutamiento. El objetivo de la capa de red es hacer que los datos lleguen desde el origen al destino, aún cuando ambos no estén conectados directamente. Los dispositivos que facilitan tal tarea se denominan encaminadores o enrutadores, aunque es más frecuente encontrarlo con el nombre en inglés routers.
    http://es.wikipedia.org/wiki/Capa_de_red
  • Capa de transporte: Capa encargada de efectuar el transporte de los datos (que se encuentran dentro del paquete) de la máquina origen a la de destino, independizándolo del tipo de red física que esté utilizando. La PDU de la capa 4 se llama Segmento o Datagrama, dependiendo de si corresponde a TCP o UDP. Sus protocolos son TCP y UDP; el primero orientado a conexión y el otro sin conexión. Trabajan, por lo tanto, con puertos lógicos y junto con la capa red dan forma a los conocidos como Sockets, que se representa como IP:Puerto (191.16.200.54:80).
    http://es.wikipedia.org/wiki/Capa_de_transporte
  • Capa de sesión: Esta capa es la que se encarga de mantener y controlar el enlace establecido entre dos computadores que están transmitiendo datos de cualquier índole. Por lo tanto, el servicio provisto por esta capa es la capacidad de asegurar que, dada una sesión establecida entre dos máquinas, la misma se pueda efectuar para las operaciones definidas de principio a fin, reanudándolas en caso de interrupción. En muchos casos, los servicios de la capa de sesión son parcial o totalmente prescindibles.
    http://es.wikipedia.org/wiki/Capa_de_sesi%C3%B3n
  • Capa de presentación: El objetivo es encargarse de la representación de la información, de manera que aunque distintos equipos puedan tener diferentes representaciones internas de caracteres los datos lleguen de manera reconocible.
    http://es.wikipedia.org/wiki/Capa_de_presentaci%C3%B3n
  • Capa de aplicación: Ofrece a las aplicaciones la posibilidad de acceder a los servicios de las demás capas y define los protocolos que utilizan las aplicaciones para intercambiar datos, como correo electrónico (Post Office Protocol y SMTP), gestores de bases de datos y servidor de ficheros (FTP), por UDP pueden viajar (DNS y Routing Information Protocol). Hay tantos protocolos como aplicaciones distintas y puesto que continuamente se desarrollan nuevas aplicaciones el número de protocolos crece sin parar.
    Cabe aclarar que el usuario normalmente no interactúa directamente con el nivel de aplicación. Suele interactuar con programas que a su vez interactúan con el nivel de aplicación pero ocultando la complejidad subyacente.
    http://es.wikipedia.org/wiki/Capa_de_aplicaci%C3%B3n

Esta imagen explica claramente lo que ocurre al pasar de capa a capa antes de mandar los bits por el medio físico.

Más información en: http://es.wikipedia.org/wiki/Modelo_OSI

TCP/IP. Protocolo HTTP

En el caso del protocolo TCP/IP la pila OSI se simplifica:

Capa de Aplicación. Invoca programas que acceden servicios en la red. Interactuan 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.


Más información en: http://www.uca.edu.sv/investigacion/tutoriales/tcp-ip.html

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.

Aunque 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 A: 10.0.0.0 a 10.255.255.255 (8 bits red, 24 bits hosts).
  • 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 son redes físicas distintas que comparten una misma dirección IP, es decir aquella que identifica a la red principal.
  • Deben identificarse una de otra 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, gateway y servidores DNS.

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.

Más información de DHCP: http://es.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol

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:

  • Los ceros iniciales se pueden obviar.
    Ejemplo: 2001:0123:0004:00ab:0cde:3403:0001:0063 -> 2001:123:4:ab:cde:3403:1:63
  • Los bloques contiguos de ceros se pueden comprimir empleando “::”. Esta operación sólo se puede hacer una vez.

Más información en: http://es.wikipedia.org/wiki/IPv6

Más información sobre el direccionamiento IP en: http://es.wikipedia.org/wiki/Direcci%C3%B3n_IP

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.

Ethernet: http://es.wikipedia.org/wiki/Ethernet

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.

Más información en: http://es.wikipedia.org/wiki/Direcci%C3%B3n_MAC

En arduino con la librería ethernet solo trabajamos con la capa de aplicación, todas las otras capas ya están implementadas por el Hardware, ya sea la ethernet shield o el módulo WiFi. Aunque si queremos realizar algunas funciones de capas inferiores, podemos hacerlo con los comandos adecuados comunicandonos con el chip ethernet via SPI.

Veamos los protocolos de la capa de aplicación que serán los que tengamos que implemantar en nuestro arduino o usando la librería adecuada:

HTTP

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, colaboración que culminó en 1999 con la publicación de una serie de RFC, el más importante de ellos es el RFC 2616 que especifica la versión 1.1. 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.

Novedades de HTTP/1.1: http://www.apacheweek.com/features/http11

Para una explicación más amplia de lo que es HTTP: http://es.wikipedia.org/wiki/Hypertext_Transfer_Protocol

Para intercambio de archivos por HTTP usamos: http://es.wikipedia.org/wiki/Multipurpose_Internet_Mail_Extensions

Líneas de encabezado: http://trevinca.ei.uvigo.es/~txapi/espanol/proyecto/superior/memoria/node51.html

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: Pide una representación del recurso especificado. Por seguridad no debería ser usado por aplicaciones que manden datos sensbles 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:

GET /images/logo.png HTTP/1.1 obtiene un recurso llamado logo.png

Ejemplo con parámetros:

/index.php?page=main&lang=es

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.

HTTP request:

Más información en: http://www.w3schools.com/tags/ref_httpmethods.asp

Métodos get y post, como se compone:

http://blog.micayael.com/2011/02/09/metodos-get-vs-post-del-http/

Un explicación muy buena de HTTP también la puedes encontrar en:  http://www.ntu.edu.sg/home/ehchua/programming/webprogramming/HTTP_Basics.html

Veamos una trama en HTTP, fijaros en el uso de cr (retorno de carro – carriage return – ASCII 13) y lf (line feed – nueva linea – ASCII 10):

http://www1.ju.edu.jo/ecourse/abusufah/cpe532_Spr06/notes/BookOnLine/HTTP%20Request%20Message.htm

Y la versión inglesa de la wikipedia:

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.

Y cuando usar GET o POST?: http://www.w3.org/2001/tag/doc/whenToUseGet.html#checklist

Ya hemos visto las peticiones, pero ¿Como son las respuestas?

Para cumplir con el protocolo HTTP, arduino debe implementar estas respuestas cuando lo uso como servidor web.

Veamos esto gráficamente:

El siguiente paso sería usar websocket  http://en.wikipedia.org/wiki/WebSocket. En futuros post se tratará la implementación de websocket en Arduino.

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.

https://www.wireshark.org/

Chrome plugin Sniffer: http://5ms.ru/sniffer/

on-line: http://web-sniffer.me/

Listado de web sniffers: http://scraping.pro/web-sniffers-review/

Tema 6 – Comunicaciones con Arduino (2)

Librería Ethernet. Shield Ethernet y W5100.

 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.

 

Datasheet de W5100: https://www.sparkfun.com/datasheets/DevTools/Arduino/W5100_Datasheet_v1_1_6.pdf

Librería ethernet: http://arduino.cc/en/Reference/Ethernet

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.

La shield contiene un número de 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)
  • RX: parpadea cuando el shield recibe datos
  • TX: parpadea cuando el shield envía datos

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.

El slot SD en la shield usa la librería http://arduino.cc/en/Reference/SD para manejarlo.

Para usar la Ethernet Shield solo hay que montarla sobre la placa Arduino. Para cargar los sketches a la placa conectarla al ordenador mediante el cable USB como se hace normalmente. Luego conectar la Ethernet a un ordenador, a un switch o a un router utilizando un cable ethernet standard (CAT5 o CAT6 con conectores RJ45). La conexión al ordenador puede requerir el uso de un cable cruzado (aunque muchos ordenadores actuales, pueden hacer el cruce de forma interna).

Un tutorial sencillo para comenzar con el shield ethernet en: http://www.artinteractivo.com/arduino-ethernet

 Para cualquier duda sobre el ethernet Shield consultar: http://arduino.cc/en/Main/ArduinoEthernetShield

 Puntos a recordar del Ethernet Shield:

  • 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
  • Soporta hasta 4 conexiones simultaneas
  • Usar la librería Ethernet para manejar el shield: http://arduino.cc/en/Reference/Ethernet
  • 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.

Para conectar el shield, se deben seguir estas instrucciones: http://arduino.cc/en/Guide/ArduinoEthernetShield

 El esquemático lo podéis encontrar en: http://arduino.cc/en/uploads/Main/arduino-ethernet-shield-06-schematic.pdf

 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
  • 1500V isolation (input to output)

Data sheet: http://arduino.cc/en/uploads/Main/PoE-datasheet.pdf

 Más información sobre el Power Over Ethernet:

 

Como funciona PoE:

http://www.bb-elec.com/Learning-Center/All-White-Papers/Ethernet/Power-over-Ethernet-PoE.aspx

 

 WIZnet W5100

 El integrado W5100 se conecta al arduino mediante SPI.

 

Para saber todo sobre el W5100 revisar este enlace que es muy completo: http://www.ermicro.com/blog/?p=1773

Básicamente el Wiznet W5100 implementa una pila TCP con todas las funciones del estándar IEEE 802.3 (Ethernet capa fisica y de enlace de datos) dentro del chip; esto hace que el chip Wiznet W5100 sea buena opción para integrar el sistema embebido en internet. La programación del chip de Wiznet W5100 es también fácil ya que sólo tenemos que escribir y leer desde y hacia los registros internos W5100 con el fin de utilizar el construir funciones de los protocolos TCP/IP.

El Wiznet W5100 actuará como un dispositivo esclavo SPI controlado por microcontrolador ATMega328 como el SPI Maestro. Necesita el protocolo SPI al menos cuatro señales, MOSI (Master Out Serial In), MISO (Master In Serial Out), SCK (señal de reloh proporcionada por el maestro) y CS (the SPI slave chip select). El chip W5100 también proporciona el pin de interrupción.

Para inicializar el chip W5100, tenemos que escribir en cada uno de los registros comunes W5100 nombrados MR ((Mode Register), SUBR (Subnet mask Register), SAR (Source Hardware Register), SIPR (Source IP Register), RMSR (Receive Memory Size Register) y TMSR (Transmit Memory Size Register).

Todos los registros de W5100 registros de direcciones tiene 16 bits de ancho y el registro en sí es de 8 bits de ancho; como utilizamos el microcontrolador ATMega328 de 8 bits, con el fin de realizar la operación de escritura o lectura tenemos que pasar los primeros 8 bits MSB (byte más significativo) y seguir los siguientes 8-bit LSB (byte menos significativo) de la direccion de memoria del registro de W5100. El Wiznet W5100 también utiliza dos comandos para diferenciar entre la escritura (0xF0) y operación de lectura (0x0F). La escritura y lectura en el SPI de Wiznet se implementa con SPI_Write () y SPI_Read ().

Especificaciones:

 Ver en el pdf el mapa de memoria y los registros comunes.

 ¿Es posible hacer pings con arduino? Sí, pero con una librería: http://playground.arduino.cc/Code/ICMPPing

¿Soporta Arduino IPv6?

El shield oficial de arduino basado en el WizNet 5100 implementa la pila de protocolos IPv4, por lo que esta shield no puede ser utilizada para implementar la pila IPv6.

Para implementar la pila IPv6, es necesario usar un shield basado en hardware que permita la gestión de la funciones de las capas de IP y ethernet. Shields basados en el chip MicroChip ENC28J60 son adecuados para la implementación de IPv6. Esto requiere la implementación de una gestión de los estados TCP, resultando un código de arduino más complejo.

 Datasheet Chip ethernet IPv6:

 Más información sobre IPv6: https://sites.google.com/site/ghoelzl/ipv6

 IPv6WebServer: https://sites.google.com/site/ghoelzl/ipv6ethershield/ipv6_http_server

 Y aun más… http://www.tweaking4all.com/hardware/arduino/arduino-enc28j60-ethernet/

 Y otro ejemplo: http://www.fut-electronics.com/wp-content/plugins/fe_downloads/Uploads/Ethernet-Module-ENC28J60-Arduino.pdf

 Librerías:

Wifi Shield

El WiFi Shield de Arduino conecta Arduino a Internet de forma inalámbrica.

Toda la información sobre este Shield en :

Y los datasheet de los integrados:

 Para conectarte al 32UC3: http://arduino.cc/en/Hacking/WiFiShield32USerial

Y la librería para manejar el shield en: http://arduino.cc/en/Reference/WiFi

 Actualizar su firmware: http://arduino.cc/en/Hacking/WiFiShieldFirmwareUpgrading

 

Wifi library:

 Otro integrado wifi muy usado con arduino es: CC3000 

 Y la librería: https://github.com/sparkfun/SFE_CC3000_Library

 Y un buen paso a paso para usar esta shield:

 Y un ejemplo de uso práctico para hacer domótica en casa:

 Librería Ethernet

Para manejar el Ethernet Shield usaremos la librería Ethernet, deberemos conocer todos los métodos que nos ofrece la librería para poder usarla.

http://arduino.cc/en/Reference/Ethernet

 La librería ethernet se compone de 5 clases, cada una con sus métodos

 Ethernet Class: Inicializa la librería ethernet y las configuraciones de red

  • begin() – Inicializa la librería Ethernet (Constructor)
  • localIP() – Obtiene la dirección IP. Útil al usar DHCP
  • maintain() – Solicita una renovación al servidor DHCP

 IPAddress Class: trabaja con IPs locales y remotas

 Server Class: crea un servidor que puede mandar y recibir datos de los clientes conectados.

  • Server() – Constructor de la clase server. No se usa directamente
  • EthernetServer() – Crea un servidor que escucha por las conexiones entrantes del puerto definido.
  • begin() – Le dice al servidor que comience a escuchar.
  • available() – Devuelve el cliente que está conectado al servidor y tiene datos disponibles a leer.
  • write() – Escribe datos a todos los cliente conectados al servidor.
  • print() – Escribe datos a todos los cliente conectados al servidor.
  • println() – Escribe datos a todos los cliente conectados al servidor seguido de una nueva línea.

 Client Class: crea un cliente que se conecta a un servidor y puede mandar y recibir datos

  • Client – Constructor de la clase client. No se usa directamente
  • EthernetClient() – Crea un cliente que se conecta a una determinada IP y puerto
  • if (EthernetClient) – Indica si el cliente Ethernet está preparado
  • connected() – Devuelve si el cliente está o no conectado
  • connect() – Conecta a una IP y puerto especificado. Soporta DNS lookup. Devuelve unos códigos en función del éxito o fallo de la conexión.
  • write() – Escribe datos al servidor al que está conectado.
  • print() – Escribe datos al servidor al que está conectado
  • println() – Escribe datos al servidor al que está conectado, seguido de una nueva línea
  • available() – Devuelve el número de bytes disponibles para leer.
  • read() – Lee el siguiente byte recibido desde el servidor.
  • flush() – Borrar todos los bytes que han sido escritos en el cliente pero no leidos
  • stop() – Desconecta el cliente del servidor

 EthernetUDP Class: habilita el envío y recepción de mensajes UDP

  • begin() – Inicializar la librería UDP
  • read() – Lee datos UDP
  • write() – Escribe datos UDP a la conexión remota.
  • beginPacket() – Comienza una conexión para escribir paquetes UDP
  • endPacket() – Finaliza una conexión UDP después de escribir
  • parsePacket() – Comprueba la presencia de un paquete UDP
  • available() – Devuelve el nº de bytes disponible para leer en el buffer
  • stop() – Desconecta del servidor
  • remoteIP() – Obtiene la IP de la conexión remota
  • remotePort() – Obtiene el puerto de la conexión remota

 Más información sobre el protocolo UDP: http://es.wikipedia.org/wiki/User_Datagram_Protocol

 Y varios ejemplo para usar:

 Snippets para ethernet: http://playground.arduino.cc/Main/SketchList#ethernetShield

 Recordar que tenemos un arduino Ethernet que es casi igual a un arduino UNO + un ethernet shield: http://arduino.cc/en/Main/arduinoBoardEthernet

 Ejercicio25-EthernetClient Crea un cliente ethernet que se conecte a una web y escriba los datos recogidos. Guarda los datos en un string.

webclient: http://playground.arduino.cc/Code/WebClient

Prueba a conectarte a varias páginas web y usa el servicio DNS poniendo la url en lugar de la IP.

Trata de conectarte a la AEMET para ver si sería posible obtener el tiempo de logroño.

Usa la API de http://www.openweathermap.org/ para obtener los datos del tiempo en una ciudad en concreto

Tiene aemet una API?

Serías capaz de sacar la temperatura en logroño actualizada por el display LCD sin necesidad de un sensor de temperatura?

Solución: https://github.com/jecrespo

 Un poco de información:

 Ejercicio26-EthernetServer Crea un servidor web sencillo que devuelva la petición http que le ha llegado. Luego añade el valor leído por un sensor.

Implementar también un servidor de telnet simple.

webserver: http://playground.arduino.cc/Code/WebServerST

Solución: https://github.com/jecrespo

 Ejercicio27-Boton Crea una web embebida con un botón que al pulsarlo desde el navegador encienda un led.

Ejercicio: http://diymakers.es/crear-servidor-web-con-arduino/

http://www.jackbarber.co.uk/notes/arduino-web-server-led-control

Solución: https://github.com/jecrespo

Ejercicio28-ChatEthernet: Hacer el mismo chat del puerto serie con ethernet

Chat server: http://arduino.cc/en/pmwiki.php?n=Tutorial/ChatServer

y chat client: http://arduino.cc/en/Tutorial/ChatClient

Solución: https://github.com/jecrespo