Leer un paquete
Un paquete en el cable es una pila de cabeceras, cada una de las cuales dice qué viene después: el campo de tipo de Ethernet indica IPv4, el campo de protocolo de IP indica TCP, el puerto TCP sugiere DNS o HTTP. El decodificador sigue esa cadena. Cada cabecera se muestra con sus campos, sus desplazamientos en bytes y, en los campos empaquetados como los flags de IP o el data offset de TCP, los bits exactos. Pasa el ratón sobre un campo para ver dónde está en el volcado hex de abajo.
Conseguir los bytes
| Fuente | Comando / acción | Capa de enlace |
|---|---|---|
| tcpdump, un paquete con cabecera Ethernet | tcpdump -c1 -xx -ni eth0 port 53 | Ethernet |
| tcpdump sin capa de enlace | tcpdump -c1 -x -ni eth0 … | IPv4/IPv6 en bruto (detectado) |
| tcpdump en «any» | tcpdump -c1 -xx -ni any … | Linux cooked (SLL) |
| Wireshark | Clic derecho en el paquete → Copiar → …como volcado hex, o Archivo → Exportar disecciones de paquetes | Ethernet |
| Captura completa | tcpdump -c100 -w out.pcap port 53 | Leída del archivo |
| Scapy / Python | bytes(pkt).hex() | Depende de la primera capa |
Sumas de comprobación
IPv4 cubre solo su cabecera; TCP, UDP e ICMPv6 cubren su cabecera, sus datos y una pseudocabecera con direcciones IP, protocolo y longitud, por eso un NAT que reescribe direcciones tiene que reescribir también las sumas de transporte. Una suma incorrecta en una captura hecha en la máquina emisora es casi siempre checksum offloading: el kernel deja el campo a la tarjeta de red, que lo rellena después del punto de captura. En una captura de otra máquina o de un puerto espejo, una suma incorrecta significa corrupción real. UDP sobre IPv4 puede llevar 0, que significa «no calculada».
Lo que señala el decodificador
- Valores de TTL que revelan el sistema operativo del emisor (64 Linux/macOS, 128 Windows, 255 equipos de red) y a cuántos saltos está.
- Direcciones privadas, link-local, multicast y de documentación; MAC administradas localmente (máquinas virtuales, direcciones Wi-Fi aleatorias).
- Estado del handshake TCP a partir de los flags, escalado de ventana y MSS de las opciones, bloques SACK, timestamps.
- Paquetes IP fragmentados, en los que el decodificador se detiene (la cabecera de transporte solo está en el primer fragmento).
- En los errores ICMP se decodifica también el datagrama original citado, para que veas a qué conexión se refiere un «port unreachable» o «TTL exceeded».
- En el TLS ClientHello, el nombre de host SNI, las versiones ofrecidas, los grupos y los protocolos ALPN: todo lo que aún es visible en claro.
Preguntas
¿Por qué el decodificador dice que mi suma de comprobación TCP es incorrecta?
Si la captura se hizo en la máquina que envió el paquete, la tarjeta de red debía rellenar la suma después de la captura (checksum offloading); Wireshark muestra lo mismo. Desactívalo con ethtool -K eth0 tx off si necesitas valores reales en las capturas, o captura en el lado receptor.
¿Puede leer un archivo pcap completo?
Sí, arrastra un .pcap o .pcapng (hasta 8 MB, 5000 paquetes listados). Haz clic en un paquete de la lista para decodificarlo. El archivo nunca sale de tu navegador.
¿Y las tramas Wi-Fi 802.11 o Radiotap?
Aún no se decodifican; las capturas con esos tipos de enlace listan los paquetes pero muestran los bytes como carga útil. Ethernet, Linux cooked, IP en bruto y loopback BSD están soportados.
¿Reensambla flujos TCP o sigue conexiones?
No. Decodifica un paquete cada vez. Para análisis de flujos usa Wireshark; para entender exactamente qué dice una cabecera, esto es más rápido.
Mi carga útil aparece como «TCP payload» aunque es HTTP.
HTTP se reconoce por los primeros bytes (un método o HTTP/1.x), independientemente del puerto. El tráfico cifrado en el 443 se muestra como registros TLS, todo lo demás como bytes en bruto con columna ASCII.