El Blog de Marcelo!

En el trabajo me encontré con la necesidad de utilizar un puerto serial (por ejemplo, un dispositivo con un adaptador USB/Serie en /dev/ttyUSB0, un módem 3G o una placa Arduino en /dev/ttyACM0, etc.) conectado físicamente a una máquina en mi red, que por diferentes motivos (distancia, pereza, lo que sea), lo quería acceder con un programa en mi máquina, pero como si fuera local.

Es decir, tenía un programa en mi máquina que usa pySerial para acceder al Arduino en /dev/ttyACM0, pero por diferentes motivos el Arduino está conectado en otra máquina de mi red y quería que, sin tocar mi programa, éste acceda al Arduino como si estuviera directamente conectado a mi PC, haciendo de alguna manera «transparente» la red que nos separaba. Por suerte lo pude resolver, y quizás esta herramienta y acercamiento sirva a más de uno para resolver algún otro problema similar.

Para esto vamos a utilizar la herramienta socat, que es como netcat pero para streams bidireccionales. Los pasos son:

• Instalar socat (apt-get install socat), tanto en la máquina que tiene el dispositivo serie real (vamos a llamarlo «servidor») como en el «cliente».
• Ejecutar en el servidor: «socat -d -d -d OPEN:/dev/ttyACM0 TCP4-LISTEN:31337»:

usuario@servidor:~$ socat -d -d -d OPEN:/dev/ttyACM0 TCP4-LISTEN:31337
2013/05/27 10:40:53 socat[2703] I socat by Gerhard Rieger - see www.dest-unreach.org
2013/05/27 10:40:53 socat[2703] I This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)
2013/05/27 10:40:53 socat[2703] I This product includes software written by Tim Hudson (tjh@cryptsoft.com)
2013/05/27 10:40:53 socat[2703] N opening character device "/dev/ttyACM0" for reading and writing
2013/05/27 10:40:53 socat[2703] I open("/dev/ttyACM0", 02, 0666) -> 3
2013/05/27 10:40:53 socat[2703] I socket(2, 1, 6) -> 4
2013/05/27 10:40:53 socat[2703] I starting accept loop
2013/05/27 10:40:53 socat[2703] N listening on AF=2 0.0.0.0:31337
2013/05/27 10:40:58 socat[2703] I accept(4, {2, AF=2 192.168.1.150:44624}, 16) -> 5
2013/05/27 10:40:58 socat[2703] N accepting connection from AF=2 192.168.1.150:44624 on AF=2 192.168.1.93:31337
2013/05/27 10:40:58 socat[2703] I permitting connection from AF=2 192.168.1.150:44624
2013/05/27 10:40:58 socat[2703] I close(4)
2013/05/27 10:40:58 socat[2703] I resolved and opened all sock addresses
2013/05/27 10:40:58 socat[2703] N starting data transfer loop with FDs [3,3] and [5,5]

Esto hace que socat abra el archivo /dev/ttyACM0 (el dispositivo serie a compartir), y además abra un socket en modo LISTEN (escuchando por conexiones) en todas las interfaces del equipo, particularmente en el puerto 31337. Las opciones -d -d -d son opcionales y sirve para habilitar los mensajes de debug.

• Ejecutar en el cliente «socat -d -d -d TCP4:192.168.1.93:31337 PTY,link=/dev/ttyACM0»:

usuario@cliente:~$ socat -d -d -d TCP4:192.168.1.93:31337 PTY,link=/tmp/ttyACM0
2013/05/27 11:52:34 socat[8408] I socat by Gerhard Rieger - see www.dest-unreach.org
2013/05/27 11:52:34 socat[8408] I This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)
2013/05/27 11:52:34 socat[8408] I This product includes software written by Tim Hudson (tjh@cryptsoft.com)
2013/05/27 11:52:34 socat[8408] N opening connection to AF=2 192.168.1.93:31337
2013/05/27 11:52:34 socat[8408] I starting connect loop
2013/05/27 11:52:34 socat[8408] I socket(2, 1, 6) -> 3
2013/05/27 11:52:34 socat[8408] N successfully connected from local address AF=2 192.168.1.150:45293
2013/05/27 11:52:34 socat[8408] I setting option "symbolic-link" to "/tmp/ttyACM0"
2013/05/27 11:52:34 socat[8408] I openpty({4}, {5}, {"/dev/pts/4"},,) -> 0
2013/05/27 11:52:34 socat[8408] N PTY is /dev/pts/4
2013/05/27 11:52:34 socat[8408] I resolved and opened all sock addresses
2013/05/27 11:52:34 socat[8408] N starting data transfer loop with FDs [3,3] and [4,4]

Este comando hace que el socat de mi máquina se conecte a la IP 192.168.1.93 (allí debe estar el servidor), al puerto 31337, y que localmente lo haga ver como un nuevo dispositivo serial (pseudo terminal) creado por socat mismo en /dev/pts/X, y además haga un symlink de éste al archivo /tmp/ttyACM0. A partir de éste momento en /tmp/ttyACM0 existe un archivo que puede ser abierto con pyserial (por ejemplo, puede ser minicom, etc.) y ser utilizado como un dispositivo serie local.

Un detalle, cuando se cierra la conexión del socat en el cliente hacia el servidor, en el servidor también se termina la ejecución del socat (y viceversa), por lo que en caso de volver a establecer la sesión, es necesario ejecutar nuevamente en ambos equipos.

Saludos

Si bien SPDY/4 todavía está en desarrollo, por lo que se deduce de este hilo y por lo que puede apreciarse en la forma que tienen ambos drafts, éste va a dejar de ser un trabajo separado de HTTP/2.0 como sucedía hasta la versión anterior, sino que será un protocolo que implementará progresivamente lo que se vaya definiendo y ganando adhesiones en la discusión que se está teniendo en el marco del IETF.

Es por esto que además de los cambios previamente definidos para SPDY/4, se le suma un «port» o «sincronización» de características definidas desde HTTP/2.0 hacia SPDY/4.  Los elementos que «se mudan» para desplazar a aquellos definidos en SPDY/3 cuentan con un relativo acuerdo general dentro del HTTPbis WG para ser parte de HTTP/2.0, y son:

• SYN_STREAM, SYN_REPLY, HEADERS pasan a ser reemplazados por HEADERS+PRIORITY* y HEADERS. Ya había un frame de HEADERS en SPDY/3, pero no se usaban en casos comunes; ahora pasan a eliminarse los frames SYN_STREAM y SYN_REPLY, unificando todas las formas de envío de headers HTTP (ya sea para iniciar/responder peticiones) en el frame de HEADERS que ya existía (entiendo que sólo se le agrega un campo de prioridad). En resumen, en SPDY/4 (y en HTTP/2.0), las peticiones se pedirán y responderán con un frame de HEADERS.
• Unificaron los frames de RST_STREAM y GOAWAY. Eran redundantes, claramente.
• Después de ciertas pruebas (ejemplo)(**), ya está definido el magic byte para inicializar una conexión directamente en HTTP/2.0 (o SPDY/4): «FOO * HTTP/2.0\r\n\r\nBAR\r\n\r\n». Pasando en limpio, la idea es que (en principio) haya 3 mecanismos de uso de HTTP/2.0:
  • Vía TLS+NPN, como SPDY/3. De todas maneras, NPN se envió hace unos meses al TLS WG y lo modificaron levemente, dándole forma a lo que se llama ALPN. Para el caso, hará lo mismo que NPN. Claro está, esto funciona sobre SSL/TLS (puerto 443), con sus pros y contras.
  • Si el servidor con el que hablamos no sabemos si soporta HTTP/2.0, se intentaría un upgrade mediante el mecanismo estándar de Upgrade de HTTP, como se hace con WebSockets (ejemplo). Esto funciona sobre puerto 80, en claro.
  • Si el servidor con el que hablamos sí sabemos de antemano que soporta HTTP/2.0, directamente se envía el magic byte luego de establecer la conexión TCP, para comenzar a intercambiar frames HTTP/2.0. La idea es ahorrar el tiempo (valioso) de upgrade. El magic byte está elegido en base a que si lo enviamos por equivocación a un server que sólo soporta HTTP/1.1, éste cause el cierre de la conexión inmediatamente.
  • Hay otras propuestas para ahorrarse el tiempo de upgrade sin saber de antemano si el server soporta 2.0, como publicar el soporte de HTTP/2.0 vía DNS (y así el navegador podría saber si el server habla 2.0 al momento de hacer la resolución DNS), pero por el momento la propuesta está en stand-by.
• Incluirá control de flujo por stream (además del control de flujo por sesión de SPDY/3).
• Un algoritmo de compresión de encabezados no basado en el stream completo de éstos, sino basado en cambios (diferencias entre los headers), para evitar los ataques del estilo CRIME. Sobre esto se está trabajando en el HTTPbis WG (principalmente por cosas como el requisito del mantenimiento de estado) y hay dos algoritmos con posibilidades (HeaderDiff y Delta). SPDY/4 incluiría este último.

*: Este frame está en discusión en estos momentos, quizá se defina un nuevo frame PRIORITY para soportar repriorización «al vuelo» de streams.
**: Es interesante comentar que en las pruebas de búsqueda del magic byte realizadas se intentó encontrar un stream de bytes que haga que la gran mayoría de web servers actuales que soporten HTTP/1.1 cierren la conexión inmediatamente o al menos devuelvan un código HTTP de error (4xx). La idea es que si un cliente envía ese stream de bytes, éste se asegure de una respuesta satisfactoria que asegure que el server es HTTP/2.0, y en caso contrario (por error, al suponer que el server soporta 2.0 pero no es así), el efecto producido en el server (y en la comunicación en sí) sea el mínimo posible.

Vamos a ver cómo evoluciona, y si SPDY/4 se hace «estable» en un futuro próximo para poder ir haciendo pruebas. Pero parece ser claro que va a ser bastante diferente a SPDY/3.

Saludos