Pega hexadecimal de Wireshark, tcpdump o xxd y decodifica Ethernet, IPv4, IPv6, TCP, UDP, ICMP y ARP con cada suma verificada. Corre en tu navegador.
Las columnas de desplazamiento y ASCII se eliminan automáticamente. Los separadores, prefijos 0x y saltos de línea no son problema.
La decodificación ocurre por completo en tu navegador. El paquete nunca se sube, así que las capturas de tráfico de producción permanecen en tu equipo.
También podrías encontrar útiles estas calculadoras
Red, difusión, máscara y hosts utilizables de una subred IPv4
Convierte CIDR en rango, divide un bloque o agrega bloques
Prefijo, rango, subredes /64 y tipo de dirección según IANA
Convierte, suma y enmascara hex, binario, octal y decimal
Pega el hexadecimal de una trama capturada y este decodificador la separa en capas de protocolo, campo por campo, y recalcula cada suma de verificación para que veas de un vistazo si el paquete está bien formado. Acepta los formatos que tus herramientas producen realmente —volcados de Wireshark, tcpdump -X, xxd y arreglos de bytes en C— eliminando por ti las columnas de desplazamiento y ASCII. Todo ocurre dentro de tu navegador; el paquete nunca se sube.
Un paquete de red es una secuencia de bytes cuyo significado lo fijan sus cabeceras de protocolo. Un decodificador recorre esas cabeceras en orden —primero la trama Ethernet, luego la capa IP que anuncia y después la capa de transporte— y etiqueta cada campo. Lo útil no es solo el etiquetado, sino la aritmética: longitudes de cabecera, longitudes totales y sumas de verificación son valores derivados, y cuando uno no concuerda con los bytes que lo rodean, has encontrado el fallo.
Suma de verificación de Internet
Las tarjetas de red que calculan sumas por hardware suelen mostrar valores inválidos en una captura local porque el campo se rellena después de capturar el paquete. Verificar te dice si el cable llevó realmente un paquete defectuoso.
El hexadecimal pegado en un ticket rara vez llega limpio. Ponerlo aquí lo decodifica sin tener que borrar a mano los desplazamientos del texto.
Cuando construyes tramas en un script, la suma de verificación es lo primero que sale mal. Pega el resultado y confirma cada capa antes de enviarla por la red.
Cada campo muestra su desplazamiento y longitud en bytes, y la cuadrícula de bytes se alinea al lado, lo que hace concretos los diagramas abstractos de cabeceras.
Cada capa se recalcula según el RFC 1071 y se informa como válida, inválida, no presente o truncada. Un paquete mal formado suele serlo por una suma incorrecta, y leer cuatro dígitos hexadecimales no dice nada por sí solo.
Los volcados de Wireshark, tcpdump -X, xxd y los arreglos en C se pegan tal cual. Las columnas de desplazamiento y ASCII se reconocen y se eliminan, y la herramienta te dice qué formato detectó en lugar de reinterpretar tus bytes en silencio.
La decodificación se ejecuta en el navegador. No hay subida ni análisis en un servidor, que es lo que la hace utilizable con capturas que no tienes permitido enviar a un tercero.
Los bytes por encima de la capa de transporte se muestran como carga útil sin analizar en vez de adivinarse, y una captura demasiado corta para comprobarse se informa como truncada en lugar de fallida.
Sí. Usa Copiar > como volcado hexadecimal y pega todo, incluidas las columnas de desplazamiento y ASCII. El analizador reconoce la columna de desplazamiento, usa su paso para deducir cuántos bytes lleva cada línea y descarta lo que viene después. tcpdump -X, xxd y los arreglos de bytes en C funcionan igual, al igual que una cadena hexadecimal simple con espacios, dos puntos o prefijos 0x.
No. La decodificación se ejecuta por completo en tu navegador mediante JavaScript en esta página. No se envía nada a un servidor, algo que importa cuando la captura proviene de tráfico de producción o de clientes.
Recalcula la suma a partir de los bytes del paquete usando la suma en complemento a uno definida en el RFC 1071 y la compara con el valor que lleva el paquete. En IPv4 cubre la cabecera. En TCP y UDP cubre una pseudocabecera formada por las direcciones de origen y destino, el número de protocolo y la longitud del segmento, más la cabecera de transporte y sus datos.
Porque el RFC 768 define una suma transmitida con todos los bits en cero como que el emisor no generó ninguna suma. Eso es legal sobre IPv4, así que informarlo como fallo marcaría tráfico correcto como defectuoso.
El RFC 8200, sección 8.1, invierte la regla: los receptores IPv6 deben descartar los paquetes UDP con suma de verificación cero. Los mismos dos bytes son legítimos sobre IPv4 y un error sobre IPv6, así que el veredicto debe depender de la versión de IP.
La cabecera IP declara una longitud mayor que los bytes que pegaste, normalmente porque la captura se recortó por un snaplen. Esos bytes ausentes forman parte del rango cubierto por la suma, así que no es posible dar un veredicto honesto. Informar un fallo ahí sería inventarlo.
Ethernet II, etiquetas VLAN 802.1Q, ARP, IPv4 con opciones, IPv6, TCP, UDP, ICMP e ICMPv6. Los bytes por encima de la capa de transporte se muestran como carga útil sin analizar, en hexadecimal y ASCII, en lugar de adivinarlos.
De forma deliberada. El análisis de protocolos de aplicación ya lo cubren bien las herramientas basadas en el motor de Wireshark, y hacerlo a medias sería peor que no hacerlo. Esta página se centra en acertar con las capas inferiores y en decirte si el paquete es válido.
Son ocho bits en el orden CWR, ECE, URG, ACK, PSH, RST, SYN y FIN, tal como los enumera el RFC 9293. Un SYN solo es un intento de conexión, SYN más ACK es la respuesta, y RST significa que el otro extremo rechazó o cerró la conexión.
Cuenta palabras de 32 bits en la cabecera TCP, así que un valor de 5 significa una cabecera de 20 bytes sin opciones. Multiplica por cuatro para obtener bytes. El campo IHL de IPv4 funciona igual.
Sí. Si el primer nibble es 4 o 6, los bytes se leen directamente como un paquete IP, que es lo que obtienes de capturas tomadas en una interfaz de túnel o de bucle invertido.
El campo de longitud total de IP describe el paquete tal como se envió. Si tu pegado es más corto, la captura se truncó. Si es más largo, los bytes extra suelen ser relleno de Ethernet, que se añade para alcanzar el tamaño mínimo de trama de 60 bytes y no forma parte del paquete IP.