En ocasiones veo sockets raw: cómo trabaja el kernel de Linux a nivel de red

Creo que este post puede ser muy interesante y además un buen ejercicio para recordar las capas del modelo TCP/IP. Surge de una necesidad de gestionar a nivel de bit paquetes de red: identificar y parsear cabeceras de las capas L3 y L4 (red y transporte). Esto hecho en C++ desde un host Linux usando la API de sockets estándar pero a un nivel más bajo de lo habitual.

Mi intención es reflejar con claridad las diferencias entre distintos tipos de sockets que podemos crear y qué aporta cada uno, para poder elegir con criterio según las necesidades de cada quien. Primero repasaremos conceptualmente dos o tres tipos de sockets y el nivel de la pila en el que trabajan; después lo aterrizaremos con ejemplos de código en C++ y algún diagrama sencillo para entender exactamente qué bytes llegan a nuestro recvfrom() en cada escenario.

Configurando un socket para recibir datagramas UDP en un puerto concreto

Una necesidad my común como la de recibir datagramas UDP en un puerto concreto puede llevarnos a crear sockets como:

#include <sys/socket.h>

int s = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);

Donde lo importante está en i) AF_INET especificando que la comunicación usará direcciones IPv4, en ii) SOCK_DGRAM especificando que las comunicaciones estarán basadas en datagramas, y en iii) IPPROTO_UDP que dice al kernel que solo nos interesan datagramas UDP. Se definien así parámetros asociados al direccionamiento IP (capa de red) y al tipo de transporte basado en datagramas. Opcionalmente, también podríamos bindear el socket a un puerto fijo en el que recibir los datagramas:

Un vistazo a SCHC para entender cómo facilita el envío de paquetes IP comprimidos en enlaces restringidos

SCHC (Static Context Header Compression) es un estándar definido en el RFC 8724 que especifica un mecanismo de compresión y fragmentación de paquetes diseñado para entornos con recursos extremadamente limitados. Su objetivo principal es reducir el tamaño de las cabeceras de protocolos de las capas de red, transporte o aplicación mediante el uso de contextos estáticos previamente compartidos entre cada nodo de la comunicación.

Más allá de la compresión de cabeceras, el esquema de fragmentación adaptado a enlaces con tamaño de trama muy reducido, como en redes LPWAN, incorpora modos de operación con confirmación (ACK-on-Error y ACK-Always). Esto permite controlar la fragmentación y recuperar fragmentos perdidos en el propio enlace, mediante confirmaciones y retransmisiones, algo especialmente útil en radioenlaces/LPWAN con pérdidas.

Cabecera IPv6 sin extensiones (40 bytes - 320 bits)

Tras la compresión/fragmentación de paquetes con SCHC, lo que viaja por el enlace no es un paquete IP/IPv6 válido, puesto que su cabecera ha sido comprimida y ya no contiene toda la información necesaria. En su lugar, es un residuo SCHC + RuleID + fragmentos (si hay), por lo que solo un receptor SCHC con el mismo contexto puede reconstruir el paquete IP/IPv6 original.

Esto se vuelve útil, incluso necesario en redes LPWAN porque las restricciones en el enlace suelen ser muy limitantes, con tamaños máximos de transferencia de unas cuantas decenas de bytes (50-200 aprox.). Teniendo en cuenta que el par de cabeceras IPv6+UDP sin extensiones ya ocupa 48 bytes, la compresión se hace muy necesaria.

Errores reales usando MAVLink en comunicaciones con UAV: qué hacer y cómo evitar perder horas innecesariamente

En las primeras pruebas con MAVLink todo parece bastante sencillo: estableces conexión, empiezas a ver llegar mensajes, ves la telemetría moverse y da la impresión de que ya tienes el sistema más o menos entendido. Los ejemplos funcionan, las herramientas responden y la sensación general es que el funcionamiento del protocolo es más básico de lo que realmente es.

El problema llega cuando pasas de un entorno de pruebas a la realidad. En cuanto aparecen varios componentes —autopiloto, estación de tierra, sensores— MAVLink podría llegar a fallar de formas raritas. Cuando esto pasa, es muy común no ver errores ni mensajes explícitos, simplemente “no funciona”, y muchas veces el código no tiene la culpa.

En este post no voy a explicar qué es MAVLink ni cómo enviar tu primer mensaje. Voy a hablar de errores reales que he visto, y sufrido jajaja, trabajando con sistemas UAV: configuraciones de puertos y baudrate que nadie revisa, XMLs que no coinciden y mensajes que desaparecen sin avisar.

Si ya estás trabajando con MAVLink en un sistema real, es muy probable que alguna de estas situaciones te suene. Y si aún no has llegado ahí, mejor tenerlas en mente antes de perder tiempo con errores que no dan ninguna pista clara.

Número 1. Configurar bien el baudrate y los puertos TELEM: no des por hecho que están bien

Por muy seguro que creas estar, nunca des por hecho que la configuración básica está bien. En general, dar por sentadas cosas en este mundillo no es muy pro tip que digamos. Es sorprendente la cantidad de tiempo que se puede perder depurando cuando, en realidad, no te está llegando ni un solo byte de MAVLink al sistema.

Concretamente, cuando trabajas con autopilotos (CubeOrange, Pixhawk, Durandal, etc.) es muy común asumir que las intefaces TELEM1 o TELEM2 están bien configuradas desde el firmware. No tiene por qué ser así. Dependiendo de la versión del firmware, del modelo o de configuraciones previas, un puerto puede estar deshabilitado, reasignado a otro protocolo o usando un baudrate distinto al que espera la estación de tierra, por ejemplo.

En proyectos reales, basta con que un día prestes el autopiloto para unas pruebas para que alguien cambie una configuración… y nadie se acuerde luego de devolverla a su estado original.

Antes de tocar una sola línea de código, verifica siempre tres cosas:

1. Qué puerto físico estás usando realmente (TELEM1/TELEM2).
2. Que la configuración de ese puerto sea la apropiada.
3. Que el baudrate coincida exactamente en origen y destino.

Cinco minutos aquí pueden ahorrarte horas luego.