Tcpdump

Sinopsis

[ -C file_size ] [ -G rotate_seconds ] [ -F archivo ]

[ -i interfaz [] -m módulo ] [ -M secreto ]

[ -r archivo ] [ -s snaplen ] [ -T tipo ] [ -w archivo ]

[ -W filecount ]

[ E- spi @ ipaddr algoritmo: secreto, … ]

[ -y datalinktype ] [ -z postrotate-comando ] [ -Z usuario ] [ expresión ]

Descripción

Tcpdump imprime una descripción de los contenidos de los paquetes sobre una interfaz de red que coinciden con el valor booleano expresión . También se puede ejecutar con el -w bandera, lo que hace que para guardar el paquete de datos a un archivo para su posterior análisis, y / o con el r- bandera, que hace que se lee de un archivo de paquetes guardados en lugar de leer los paquetes a partir de una interfaz de red. En todos los casos, sólo los paquetes que cumplen la expresión será procesada por tcpdump .

Tcpdump será, si no se ejecuta con la c- bandera, continuar la captura de paquetes hasta que es interrumpida por una señal SIGINT (generada, por ejemplo, al escribir su carácter de interrupción, generalmente control-C) o una señal SIGTERM (normalmente generado con la matanza (1) de comandos); si se ejecuta con el c- bandera, capturará los paquetes hasta que es interrumpido por un SIGINT o señal SIGTERM o el número especificado de paquetes han sido procesados.

Cuando tcpdump termina la captura de paquetes, se informe cargos de:

paquetes capturados»» (este es el número de paquetes que tcpdump ha recibido y procesado);paquetes recibidos por» filtro» (el significado de esto depende del sistema operativo en el que se ejecuta tcpdump , y posiblemente en la forma en que el sistema operativo ha sido configurado – si se ha especificado un filtro en la línea de comandos, en algunos sistemas operativos que cuenta paquetes, independientemente de si han sido igualados por la expresión de filtro y, aunque hayan sido igualadas por la expresión de filtro, sin importar si tcpdump ha leído y que ha procesado todavía, en otros sistemas operativos porque cuenta sólo los paquetes que fueron agrupados por la expresión de filtro, independientemente de si tcpdump ha leído y que ha procesado todavía, y en otros sistemas operativos que cuenta solamente los paquetes que fueron igualadas por la expresión de filtro y se procesaron mediante tcpdump );

paquetes» lanzadas por kernel» (este es el número de paquetes que se cayó, debido a la falta de espacio de amortiguación, por el mecanismo de captura de paquetes en el sistema operativo sobre el que tcpdump se está ejecutando, si el sistema operativo informa que la información de las aplicaciones; si no, se informó como 0).

En las plataformas que soportan la señal SIGINFO, como la mayoría de los sistemas BSD (incluyendo Mac OS X) y Digital/Tru64 UNIX, reportará los conteos cuando recibe una señal SIGINFO (generados, por ejemplo, escribiendo tu personaje» estado» , controlar-T normalmente, aunque en algunas plataformas, como Mac OS X, el estado»» personaje no se establece de forma predeterminada, por lo que debe establecer con stty (1) con el fin de usarlo) y continuará capturando paquetes.La lectura de los paquetes de una interfaz de red puede requerir que usted tiene privilegios especiales; ver el pcap (3PCAP) página de manual para más detalles. Lectura de un archivo de paquetes guardados no requiere privilegios especiales.

Opciones

-UnImprimir cada paquete (menos su cabecera del nivel de enlace) en ASCII. Útil para capturar páginas web.

-B

Ajuste el tamaño del búfer de captura del sistema operativo para buffer_size .

-C

Salir después de recibir recuento de paquetes.

-C

Antes de escribir un paquete de primas a un archivo de salvar, compruebe si el archivo es actualmente mayor que file_size y, si es así, cierre el archivo de salvar actual y abrir una nueva. Archivos de salvar después del primer archivo de salvar tendrán el nombre especificado con el -w bandera, con un número después de que, a partir de 1 y continuando hacia arriba. Las unidades de file_size millones de bytes (1.000.000 bytes, no 1.048.576 bytes).

Tenga en cuenta que cuando se utiliza con -Z opción (activado por defecto), los privilegios se quitan antes de abrir primero archivo de salvar.

-DVolcar el código de paquete de coincidencia compilado en un formato legible por humanos en la salida estándar y se detendrá.

-Dd

Volcado de código de paquete de coincidencia como C fragmento de programa.

-Ddd

Volcado de código de paquete de coincidencia como números decimales (precedido con un recuento).

-D

Imprimir la lista de las interfaces de red disponibles en el sistema y en la que tcpdump puede capturar paquetes. Para cada interfaz de red, un número y un nombre de interfaz, posiblemente seguido de una descripción de texto de la interfaz, se imprime. El nombre de la interfaz o el número se pueden suministrar a la i- bandera para especificar una interfaz en la que capturar.

Esto puede ser útil en sistemas que no tienen un comando para enumerarlas (por ejemplo, los sistemas de Windows, o que carecen de sistemas UNIX ifconfig-a ); el número puede ser de utilidad en Windows 2000 y los sistemas posteriores, en los que el nombre de la interfaz es una cadena un tanto compleja.El D- bandera no se admite si tcpdump fue construido con una versión anterior de libpcap que carece de los () pcap_findalldevs función.

-EImprimir la cabecera del nivel de enlace en cada línea de descarga.

-E

Utilice spi @ ipaddr algoritmo: secreto para descifrar los paquetes IPsec ESP que se dirigen a addr y contienen Seguridad Índice de parámetros de valor spi . Esta combinación se puede repetir con coma o separación de nueva línea.

Fíjate en que establecer el secreto para paquetes IPv4 ESP se admite en este momento.Los algoritmos pueden ser des-cbc , 3des-cbc , blowfish-cbc , RC3-cbc , cast128-cbc , o ninguno . El valor predeterminado es DES-CBC . La capacidad para descifrar los paquetes sólo está presente si tcpdump fue compilado con la criptografía activada.

secreto es el texto ASCII de la clave secreta ESP. Si precedido por 0x, entonces un valor hexadecimal será leído.

La opción asume RFC2406 ESP, no RFC1827 ESP. La opción es sólo para fines de depuración, y se desalienta el uso de esta opción con una llave verdadera «secreto».Con la presentación de la clave secreta IPsec a la línea de comandos que hará visible para los demás, a través de ps (1) y en otras ocasiones.

Además de la sintaxis anterior, la sintaxis de nombre de archivo se puede utilizar para tener tcpdump leer el archivo proporcionado pulg El archivo se abre al recibir el primer paquete ESP, por lo que los permisos especiales que se pudo haber dado tcpdump ya debería haber sido abandonado .

-FImprimir «extranjero» direcciones IPv4 numéricamente más que simbólicamente (esta opción está destinada a desarrollar daño cerebral grave en torno servidor NIS de Sun – por lo general se cuelga para siempre la traducción de números de Internet no locales).

La prueba para las direcciones IPv4 «extranjeros» se hace usando la dirección IPv4 y la máscara de red de la interfaz en la que se está realizando la captura. Si esa dirección o máscara de red no están disponibles, disponible, ya sea porque la interfaz en la que se está realizando la captura no tiene dirección o máscara de red o porque la captura se está haciendo en el Linux «cualquier» interfaz, que puede capturar más de una interfaz, esta opción no funcionará correctamente.

-FUtilice el archivo como entrada para la expresión de filtro. Una expresión adicional dado en la línea de comando se ignora.

-G

Si se especifica, hace girar el archivo de volcado especificado con el -w opción cada rotate_seconds segundos. Archivos de salvar tendrán el nombre especificado por -w que debería incluir un formato de hora definido por strftime (3). Si no se especifica el formato de hora, cada archivo nuevo sobrescribirá el anterior.

Si se utiliza junto con el C- opción, los nombres de archivo tomarán la forma de ‘ archivo <recuento> ‘.

-IEscuchar en el interfaz . Si no se especifica, tcpdump busca en la lista de la interfaz del sistema para el número más bajo, configurado por interfaz (con exclusión de bucle de retorno). Los empates se rompen por la elección de la primera coincidencia.

En los sistemas Linux con 2.2 o posterior núcleos, una interfaz argumento de» cualquier» puede ser usado para capturar los paquetes de todas las interfaces. Tenga en cuenta que en el dispositivo de captura» cualquier» no llevará a cabo en modo promiscuo.Si el -D está soportado bandera, un número de interfaz como impreso por que la bandera se puede utilizar como el interfaz de argumento.

-MePonga la interfaz en modo «monitor»; esto sólo es compatible con IEEE 802.11 interfaces de conexión Wi-Fi y admite sólo en algunos sistemas operativos.

Tenga en cuenta que en el modo de monitor del adaptador puede desvincularse de la red con la que se asocia, de manera que usted no será capaz de utilizar las redes inalámbricas con el adaptador. Esto podría impedir el acceso a archivos en un servidor de red, o la resolución de nombres de host o direcciones de red, si está capturando en modo monitor y no está conectado a otra red con otro adaptador.Esta bandera afectará a la salida de la L- bandera. Si -I no se especifica, cuando no está en modo monitor sólo se mostrarán aquellos tipos de capa de enlace disponibles; si -I se especifica, sólo los tipos de capa de enlace disponibles en el modo de pantalla se mostrará.

-KNo intente verificar IP, TCP o UDP de comprobación. Esto es útil para las interfaces que realizan todos o algunos de los cálculos de suma de comprobación en el hardware; de lo contrario, todas las sumas de comprobación TCP salientes serán marcados como malos.

-L

Haga línea stdout amortiguada. Útil si quiere ver los datos mientras capturarla. Por ejemplo,

» Tcpdump-l | tee dat» o» tcpdump-l> dat y tail-f dat».

-LEnumere los tipos conocidos de enlace de datos de la interfaz, en el modo especificado, y salir. La lista de tipos conocidos de enlace de datos puede depender del modo especificado; por ejemplo, en algunas plataformas, una interfaz Wi-Fi podría apoyar un conjunto de tipos de enlace de datos cuando no está en modo monitor (por ejemplo, podría apoyar cabeceras Ethernet sólo falsas, o podría apoyar 802.11 cabeceras, pero es compatible con 802.11 cabeceras con información de radio ) y otro conjunto de tipos de enlace de datos cuando están en modo monitor (por ejemplo, podría apoyar 802.11 encabezados, o 802,11 cabeceras con información de radio, sólo en el modo de monitor).

-M

Cargue definiciones del módulo MIB SMI de archivo del módulo . Esta opción se puede usar varias veces para cargar varios módulos MIB en tcpdump .

-M

Utilice secreto como un secreto compartido para la validación de los resúmenes se encuentran en segmentos TCP con la opción TCP-MD5 (RFC 2385), si está presente.

-N

No convierta las direcciones de host a los nombres. Esto puede ser usado para evitar las búsquedas DNS.

-Nn

No convierta protocolo y números de puerto, etc a los nombres tampoco.

-N

No imprima nombre de dominio calificación de nombres de host. Por ejemplo, si se le da este indicador luego tcpdump imprime» nic» en lugar de»» nic.ddn.mil.

-O

No ejecute el código de paquete de coincidencia optimizador. Esto es útil sólo si se sospecha que hay un error en el optimizador.

-P

No poner la interfaz en modo promiscuo. Tenga en cuenta que la interfaz puede estar en el modo promiscuo por alguna otra razón; por lo tanto, ‘-p’ no se puede usar como una abreviatura de «anfitrión éter {locales-hw-addr} o emisión de éter ‘.

-Q

Rápida salida (? Tranquilo). Imprima menos información de protocolo así que las líneas de salida son más cortos.

-R

Asumir los paquetes ESP / AH se basen en edad especificación (RFC1825 RFC1829 a). Si se especifica, tcpdump no imprimirá campo de la prevención de repetición. Dado que no hay ningún campo de versión del protocolo en la especificación ESP / AH, tcpdump no puede deducir la versión del protocolo ESP / AH.

-R

Lea paquetes de archivo (que fue creado con el -w opción). Entrada estándar se utiliza si el archivo es» -».

-S

Imprimir absoluta, en lugar de los números relativos, secuencia TCP.

-S

Snarf snaplen bytes de datos de cada paquete en lugar del predeterminado de 65.535 bytes. Los paquetes truncados debido a una instantánea limitada se indican en la salida con» [| proto ]», donde proto es el nombre del nivel de protocolo en el que se ha producido el truncamiento. Tenga en cuenta que la toma de instantáneas de mayor tamaño tanto incrementa la cantidad de tiempo que se tarda en procesar los paquetes y, efectivamente, disminuye la cantidad de almacenamiento en búfer de paquetes. Esto puede causar que los paquetes se pierden. Usted debe limitar snaplen al número más pequeño que capturará la información de protocolo que está interesado pulg Ajuste snaplen a 0 la establece en el valor predeterminado de 65535, para la compatibilidad con versiones anteriores de los últimos tcpdump .

-T

Paquetes Fuerza seleccionados por » expresión «se interpreten la especificada tipo . Actualmente los tipos conocidos son AODV (Ad-hoc protocolo On-demand vector de distancia), CNFP (protocolo de Cisco NetFlow), RPC (Remote Procedure Call), RTP (Real-Time Aplicaciones protocolo), RTCP (protocolo de control de aplicaciones en tiempo real), snmp (Simple Network Management Protocol), TFTP (Trivial File Transfer Protocol), el IVA (Herramienta Audio Visual), y wb (distribuido Tarjeta Blanca).

-T

No imprimir una marca de tiempo en cada línea de descarga.

-Tt

Imprimir una marca de tiempo sin formato en cada línea de descarga.

-Ttt

Imprimir un delta (resolución micro-segundos) entre la línea actual y la anterior en cada línea de descarga.

-Tttt

Imprimir una marca de tiempo en el formato predeterminado procedido por fecha en cada línea de descarga.

-Ttttt

Imprimir un delta (resolución micro-segundos) entre la línea actual y la primera en cada línea de descarga.

-U

Imprimir sin decodificar manijas NFS.

-U

Hacer salida salvado a través de la -w opción» paquetes» buffer; es decir, como se guarda cada paquete, se escribe en el archivo de salida, en lugar de ser escrito sólo cuando el búfer de salida se llena.

El U- bandera no se admite si tcpdump fue construido con una versión anterior de libpcap que carece de la () pcap_dump_flush función.

-VAl analizar e impresión, producir (un poco más) salida detallada. Por ejemplo, el tiempo para vivir, la identificación, la longitud y opciones en un paquete IP se imprime. También permite controles adicionales de integridad de paquetes tales como la verificación de la IP e ICMP cabecera de comprobación.

Cuando se escribe en un archivo con el -w opción, el informe, cada 10 segundos, el número de paquetes capturados.

-VvAún más detallado de salida. Por ejemplo, los campos adicionales se imprimen desde NFS los paquetes de respuesta, y los paquetes SMB están totalmente decodificado.

-Vvv

Aún más detallado de salida. Por ejemplo, telnet SB … SE opciones están impresos en su totalidad. Con -X las opciones de Telnet se imprimen en formato hexadecimal también.

-W

Escribe el flujo de paquetes a presentar en lugar de analizar y imprimirlos. Más tarde se pueden imprimir con la opción-r. Salida estándar se utiliza si el archivo es» -». Ver pcap-archivo de salvar (5) para una descripción del formato de archivo.

-W

Se utiliza junto con el C- opción, esto limitará el número de archivos creados con el número especificado, y comenzar a sobrescribir archivos desde el principio, lo que crea un buffer ‘de rotación’. Además, será nombrar los archivos con suficientes 0s líderes para apoyar el número máximo de archivos, lo que les permite ordenar correctamente.

Se utiliza junto con el -G opción, esto limitará el número de archivos de volcado rotados que se crean, que sale con el estado 0 cuando se alcanza el límite. Si se utiliza con -C , así, el comportamiento resultará en archivos cíclicos por porción de tiempo.

-XAl analizar e impresión, además de la impresión de los encabezados de cada paquete, imprimir los datos de cada paquete (menos su cabecera del nivel de enlace) en hexadecimal. Las más pequeñas de todo el paquete o snaplen se imprimirán bytes. Tenga en cuenta que se trata de todo el paquete de nivel de enlace, por lo que para las capas de enlace de ese pad (por ejemplo, Ethernet), los bytes de relleno se imprimirá también cuando el paquete de la capa superior es más corto que el relleno deseado.

-Xx

Al analizar e impresión, además de la impresión de los encabezados de cada paquete, imprimir los datos de cada paquete, incluyendo la cabecera del nivel de enlace, en hexadecimal.

-X

Al analizar e impresión, además de la impresión de los encabezados de cada paquete, imprimir los datos de cada paquete (menos su cabecera del nivel de enlace) en hexadecimal o ASCII. Esto es muy útil para el análisis de nuevos protocolos.

-XX

Al analizar e impresión, además de la impresión de los encabezados de cada paquete, imprimir los datos de cada paquete, incluyendo la cabecera del nivel de enlace, en hexadecimal o ASCII.

-Y

Ajuste el tipo de enlace de datos para utilizar durante la captura de paquetes a datalinktype .

-Z

Se utiliza junto con el C- o -G opciones, esto hará que tcpdump run » archivo de comandos «donde archivo es el archivo de salvar de ser cerrado después de cada rotación. Por ejemplo, especificar -z gzip o bzip2-z comprimirá cada archivo de salvar utilizando gzip o bzip2.

Tenga en cuenta que tcpdump se ejecutará el comando en paralelo a la captura, utilizando la prioridad más baja para que esto no perturben el proceso de captura.Y en caso de que quiera usar un comando que en sí lleva banderas o diferentes argumentos, siempre se puede escribir un script de shell que llevará el nombre de archivo de salvar como único argumento, realice las banderas y argumentos arreglos y ejecutar el comando que desee.

-ZGotas privilegios (si la raíz) y cambia el ID de usuario a usuario y el ID de grupo para el grupo primario del usuario .

Este comportamiento está activado por defecto ( -Z tcpdump ), y se puede desactivar -Z raíz .

expresión

selecciona qué paquetes se dejó. Si no hay expresión se da, se volcarán todos los paquetes en la red. De lo contrario, sólo los paquetes para los que la expresión se volcarán es ‘true’.Para la expresión de la sintaxis, consulte pcap-filtro (7).

Argumentos de expresión se pueden pasar a tcpdump , ya sea como un solo argumento o como múltiples argumentos, el que sea más conveniente. En general, si la expresión contiene metacaracteres de shell, es más fácil que pasar como una sola, el argumento citado. Varios argumentos se concatenan con espacios antes de ser analizado.

Ejemplos

Para imprimir todos los paquetes que lleguen a ellas o zarpen desde la puesta del sol :

tcpdump ocaso de acogida

Para imprimir el tráfico entre helios y, o bien caliente o ace :

helios anfitrionas tcpdump y \ (caliente o ace \)

Para imprimir todos los paquetes IP entre as y cualquier host excepto helios :

tcpdump as ip host y no helios

Para imprimir todo el tráfico entre hosts y hosts locales en Berkeley:

tcpdump ucb-éter net

Para imprimir todo el tráfico ftp a través de la puerta de enlace a Internet snup : (tenga en cuenta que la expresión es citado para prevenir que el shell (mal) interpretación de los paréntesis):

tcpdump 'snup gateway y (ftp-data puerto o ftp)'

Para imprimir el tráfico ni el origen ni de destino a los ejércitos locales (si puerta de entrada a otra red, estas cosas nunca se debe dejar en su red local).

tcpdump ip y no neta  localnet

Para imprimir los paquetes de inicio y fin (los paquetes SYN y FIN) de cada conversación TCP que implica una gran cantidad de no-local.

tcpdump 'tcp [tcpflags] y (tcp-syn |-tcp fin)! = 0 y no src y dst red  localnet '

Para imprimir todos los paquetes HTTP IPv4 desde y hacia el puerto 80, es decir, imprimir sólo los paquetes que contienen datos, no, por ejemplo, SYN y paquetes FIN y paquetes ACK-solamente. (IPv6 se deja como ejercicio para el lector.)

tcpdump 'puerto TCP 80 y (((ip [02:02] - ((ip [0] y 0xf) << 2)) - ((tcp [12] y 0xf0) >> 2)) = 0!)'

Para imprimir los paquetes IP de más de 576 bytes enviados a través de la puerta de enlace snup :

tcpdump 'snup puerta de enlace y ip [02:02]> 576'

Para imprimir difusión IP o paquetes de multidifusión que se no se envían a través de broadcast o multicast Ethernet:

tcpdump 'éter [0] y 1 = 0 y ip [16]> = 224'

Para imprimir todos los paquetes ICMP que no son peticiones de eco / respuestas (es decir, no hacer ping paquetes):

'icmp [icmptype]! = icmp echo-e ICMP [icmptype]! = icmp-echoreply' tcpdump

Formato de salida

La salida de tcpdump es depende del protocolo. A continuación se presenta una breve descripción y los ejemplos de la mayoría de los formatos.

Enlace Nivel Encabezados

Si se da la opción ‘-e’, la cabecera del nivel de enlace se imprime. En redes Ethernet, la fuente y las direcciones de destino, protocolo y la longitud del paquete se imprimen.

En las redes FDDI, la opción ‘-e’ causa tcpdump para imprimir el campo ‘de control de trama’, las direcciones de origen y de destino, y la longitud de paquete. (El campo ‘control de la trama’ rige la interpretación del resto del paquete de los paquetes normales (como los que contienen datagramas IP) son paquetes «async», con un valor de prioridad entre 0 y 7;. Por ejemplo, ‘ async4 ‘. Tal los paquetes se supone que contienen un Control de Enlace Lógico (LLC) de paquetes 802,2; la cabecera LLC se imprime si es no un datagrama ISO o un denominado paquete de SNAP.

En redes Token Ring, la opción ‘-e’ causa tcpdump para imprimir el «control de acceso» y los campos de control de la trama ‘, la fuente y las direcciones de destino, y la longitud de paquete. Como en las redes FDDI, se supone que los paquetes para contener un paquete de LLC. Independientemente de si se especifica o no la opción ‘-e’, la fuente de información de enrutamiento se imprime para los paquetes de encaminamiento de origen.

En las redes 802.11, la opción ‘-e’ causa tcpdump para imprimir los campos de control de la trama ‘, todas las direcciones en el encabezado de 802.11, y la longitud de paquete.Como en las redes FDDI, se supone que los paquetes para contener un paquete de LLC.

(Nota: La siguiente descripción supone familiaridad con el algoritmo de compresión SLIP se describe en el RFC-1144.)

En enlaces SLIP, un indicador de dirección (» I» para entrante,» O» de salida), el tipo de paquete, y la información de compresión se imprimen. El tipo de paquete se imprimió por primera vez. Los tres tipos son ip , utcp y CTCP . No hay información adicional enlace se imprime para ip paquetes. Para paquetes TCP, el identificador de conexión se imprime dependiendo del tipo. Si el paquete se comprime, su cabecera codificada se imprime. Los casos especiales se imprimen como * S + N y SA * + n , donde n es la cantidad por la cual el número de secuencia (o número de secuencia y ACK) ha cambiado. Si no es un caso especial, se imprimen cero o más cambios. Un cambio se indica con T (puntero urgente), W (ventana), A (ACK), S (número de secuencia), y I (ID de paquete), seguido por un delta (n + o-N), o un nuevo valor (= N). Finalmente, la cantidad de datos en el paquete y longitud de la cabecera comprimida se imprimen.

Por ejemplo, la siguiente línea muestra un paquete TCP saliente comprimido, con un identificador de conexión implícita; el acuse de recibo ha cambiado en un 6, el número de secuencia de 49, y el ID de paquete por 6; hay 3 bytes de datos y 6 bytes de cabecera comprimida:

O CTCP * A 6 S 49 I 6 3 (6)

ARP / RARP paquetesSalida Arp / rarp muestra el tipo de solicitud y sus argumentos. El formato está diseñado para ser auto explicativo. He aquí una pequeña muestra tomada del inicio de una «rlogin» de acogida rtsg de acoger la MECA :

arp who-has CSAM tell rtsg
MECA arp respuesta es-en la MECA

La primera línea dice que rtsg envía un paquete ARP preguntando por la dirección Ethernet de internet CSAM host. MECA responde con su dirección Ethernet (en este ejemplo, las direcciones Ethernet están en mayúsculas y las direcciones de Internet en minúsculas).Esto se vería menos redundante si hubiéramos hecho tcpdump-n :

arp who-has 128.3.254.6 decir 128.3.254.68
Respuesta de ARP 128.3.254.6 es-a 02:07:01:00:01: c4

Si hubiéramos hecho tcpdump-e , el hecho de que se transmite el primer paquete y el segundo es de punto a punto sería visible:

RTSG Broadcast 0806 64: arp who-has CSAM tell rtsg
CSAM RTSG 0806 64: arp respuesta MECA es-en la MECA

Para el primer paquete que dice la dirección de origen Ethernet es RTSG, el destino es la dirección de difusión de Ethernet, el campo de tipo hexagonal contenían 0806 (tipo ETHER_ARP) y la longitud total fue de 64 bytes.Los paquetes TCP

(Nota: La siguiente descripción supone familiaridad con el protocolo TCP se describe en el RFC-793 Si usted no está familiarizado con el protocolo, ni esta descripción ni tcpdump serán de mucha utilidad para usted.).

El formato general para una línea del protocolo tcp es:

src> dst: opciones urgentes ventana ack banderas datos seqno

Src y dst son la fuente y las direcciones IP de destino y puertos. Banderas son una combinación de S (SYN), F (FIN), P (PUSH), R (RST), W (ECN CWR) o E (ECN-Echo) , o un solo ‘.’ (sin marcas). Data-seqno describe la porción de secuencia espacio cubierto por los datos en este paquete (ver ejemplo abajo). Ack es el número de secuencia de los próximos datos que se espera la otra dirección en esta conexión. Window es el número de bytes de recibir espacio de búfer disponible la otra dirección en esta conexión. Urgindica que hay datos «urgentes» en el paquete. Opciones son opciones tcp encerrados entre paréntesis angulares (por ejemplo, <mss 1024>).Src, dst y banderas están siempre presentes. Los otros campos dependen del contenido de cabecera de protocolo TCP del paquete y se emiten solamente si es apropiado.

Aquí está la parte de apertura de un rlogin desde el host rtsg de acoger la MECA .

rtsg.1023> csam.login: S 768.512: 768.512 (0) ganan 4.096 <mss 1024>
csam.login> rtsg.1023: S 947.648: 947.648 (0) ack 768.513 ganar 4.096 <mss 1024>
rtsg.1023> csam.login:. ack 1 victoria 4096
rtsg.1023> csam.login: P 1: 2 (1) ack 1 win 4096
csam.login> rtsg.1023:. ack 2 ganar 4096
rtsg.1023> csam.login: P 2: 21 (19) ack 1 win 4096
csam.login> rtsg.1023: P 1: 2 (1) ack 21 ganan 4077
csam.login> rtsg.1023: P 2: 3 (1) ack 21 ganar 4.077 urg 1
csam.login> rtsg.1023: P 3: 4 (1) ack 21 ganar 4.077 urg 1

La primera línea dice que el puerto TCP 1023 en rtsg envía un paquete al puerto de inicio de sesión en la MECA. La S indica que el SYN flag se estableció. El número de secuencia de paquetes era 768.512 y no contenía datos. (La notación es ‘primero: último (nbytes)’ que significa ‘los números de secuencia primero hasta, pero no incluyendo la última , que es nbytes . bytes de datos de usuario ‘) No hubo ack respaldado por dedito, la ventana de recepción disponible era 4.096 bytes y había una opción max-segmento de tamaño solicitando una mss de 1.024 bytes.MECA responde con un paquete similar, excepto que incluye un ack alcancía respaldados por SYN de rtsg. Rtsg entonces ACK SYN de la MECA. El ‘.’ significa no se fijaron las banderas. El paquete no contenía los datos para que no haya el número de secuencia de datos. Tenga en cuenta que el número de secuencia de acuse de recibo es un entero pequeño (1). La primera vez tcpdump ve un tcp «conversación», se imprime el número de secuencia del paquete. En los paquetes subsiguientes de la conversación, la diferencia entre el número de secuencia del paquete actual y este número de secuencia inicial se imprime. Esto significa que los números de secuencia después de que el primero se puede interpretar como posiciones de bytes relativos en la secuencia de datos de la conversación (con el primer byte de datos cada dirección siendo ‘1 ‘). ‘S’ anulará esta característica, causando la secuencia de números originales se impriman.

En la sexta línea, rtsg envía MECA 19 bytes de datos (bytes 2 a 20 en el lado de la MECA rtsg → de la conversación). El indicador PUSH se encuentra en el paquete. En la línea 7 de la MECA dice que ha recibido los datos enviados por rtsg hasta, pero sin incluir el byte 21. La mayoría de estos datos se aparentemente sentado en el buffer del socket dado que la MECA de la ventana de recepción ha conseguido 19 bytes más pequeña. MECA también envía un byte de datos a rtsg en este paquete. En las líneas 8 y 9, la MECA envía dos bytes de urgencia, empujado datos para rtsg.

Si la instantánea era lo suficientemente pequeño que tcpdump no capturó la cabecera TCP completa, se interpreta como gran parte de la cabecera, tal como se puede y luego informa» [| TCP ]» para indicar el resto no podía interpretarse. Si el encabezado contiene una opción falsa (una con una longitud que es demasiado pequeño o más allá del final de la cabecera), tcpdump lo notifica como» [ mala opt ]» y no interpreta las opciones adicionales (ya que es imposible decir donde empiezan). Si la longitud de la cabecera indica las opciones están presentes, pero la longitud del datagrama IP no es tiempo suficiente para que las opciones sean realmente allí, tcpdump lo notifica como» [ mala longitud hdr]».

Capturar los paquetes TCP con combinaciones particulares de la bandera (SYN-ACK, URG-ACK, etc)

Hay 8 bits en la sección de los bits de control de la cabecera TCP:

CWR | ECE | URG | ACK | PSH | RST | SYN | FIN

Supongamos que queremos ver los paquetes utilizados en el establecimiento de una conexión TCP. Recordemos que TCP utiliza un protocolo de enlace de 3 vías cuando se inicializa una nueva conexión; la secuencia de conexión con respecto a los bits de control TCP es

1) del llamante envía SYN

2) destinatario responde con SYN, ACK

3) del llamante envía ACK

Ahora estamos interesados ​​en la captura de paquetes que tienen sólo el conjunto SYN bit (Paso 1). Tenga en cuenta que no queremos que los paquetes de la etapa 2 (SYN-ACK), sólo un SYN inicial normal. Lo que necesitamos es una expresión de filtro correcto para tcpdump .Recordemos la estructura de una cabecera TCP sin opciones:

 0 15 31
-------------------------------------------------- ---------------
| Puerto de origen | puerto de destino |
-------------------------------------------------- ---------------
| Número de secuencia |
-------------------------------------------------- ---------------
| Número de reconocimiento |
-------------------------------------------------- ---------------
| NS | RSVD | C | E | U | A | P | R | S | M | tamaño de la ventana |
-------------------------------------------------- ---------------
| Checksum TCP | puntero urgente |
-------------------------------------------------- ---------------

Un encabezado TCP por lo general tiene 20 octetos de datos, a menos que las opciones están presentes. La primera línea de la gráfica contiene octetos de 0 – 3, la segunda línea muestra octetos 4-7 etcEmpezar a contar con 0, los bits de control TCP pertinentes figuran en el octeto 13:

 0 7 | 15 | 23 | 31
---------------- | --------------- | --------------- | - ---------------
| NS | RSVD | C | E | U | A | P | R | S | M | tamaño de la ventana |
---------------- | --------------- | --------------- | - ---------------
| | 13 octeto | | |

Vamos a echar un vistazo más de cerca en el octeto no. 13:

| |
| --------------- |
| C | E | U | A | P | R | S | M |
| --------------- |
| 7 5 3 0 |

Estos son los bits de control de TCP que estamos interesados ​​pulg Hemos enumerado los bits de este octeto de 0 a 7, de derecha a izquierda, por lo que el bit PSH es poco el número 3, mientras que el bit URG es el número 5.Recordemos que queremos capturar paquetes con SYN único conjunto. Vamos a ver lo que sucede a octeto 13 si un datagrama TCP llega con el bit SYN activo en su encabezado:

| C | E | U | A | P | R | S | M |
| --------------- |
| 0 0 0 0 0 0 1 0 |
| --------------- |
| 7 6 5 4 3 2 1 0 |

En cuanto a los bits de control de sección, vemos que sólo el bit número 1 (SYN) se establece.Si se asume que el número de octeto 13 es un entero de 8 bits sin signo en orden de bytes de red, el valor binario de este octeto es

00000010

y su representación decimal es

   7 6 5 4 3 2 1 0
0 * 2 + 0 * 2 + 0 * 2 + 0 * 2 + 0 * 2 + 0 * 2 + 1 * 2 + 0 * 2 = 2

Ya casi hemos terminado, porque ahora sabemos que si sólo SYN está activado, el valor del octeto número 13 en la cabecera TCP, cuando se interpreta como un entero sin signo de 8 bits orden de bytes de red, debe ser exactamente 2.Esta relación se puede expresar como

tcp [13] == 2

Podemos utilizar esta expresión como el filtro de tcpdump para ver los paquetes que tengan solo conjunto SYN:

tcpdump-i xl0 tcp [13] == 2

La expresión dice «dejar que el octeto 13 de un datagrama TCP tiene el valor decimal 2», que es exactamente lo que queremos.Ahora, vamos a suponer que tenemos que capturar paquetes SYN, pero no nos importa si ACK o cualquier otro bit de control de TCP se establece al mismo tiempo. Vamos a ver lo que sucede a octeto 13 cuando un datagrama TCP con juego de SYN-ACK llega:

| C | E | U | A | P | R | S | M |
| --------------- |
| 0 0 0 1 0 0 1 0 |
| --------------- |
| 7 6 5 4 3 2 1 0 |

Ahora los bits 1 y 4 están colocados en el octeto 13. El valor binario del octeto 13 es

00010010

que se traduce en decimales

   7 6 5 4 3 2 1 0
0 * 2 + 0 * 2 + 0 * 2 + 1 * 2 + 0 * 2 + 0 * 2 + 1 * 2 + 0 * 2 = 18

Ahora no podemos simplemente usar ‘tcp [13] == 18’ en el tcpdump expresión de filtro, porque eso sería seleccionar solamente aquellos paquetes que tienen set SYN-ACK, pero no los que sólo conjunto SYN. Recuerde que nosotros no nos importa si ACK o cualquier otro bit de control está establecido, siempre y cuando se establece SYN.Con el fin de lograr nuestro objetivo, necesitamos de manera lógica y el valor binario del octeto 13 con algún otro valor de preservar el bit SYN. Sabemos que queremos SYN que se fijará en todo caso, por lo que vamos lógica y el valor en el octeto 13 con el valor binario de un SYN:

     00010010 SYN-ACK SYN 00000010
Y 00000010 (queremos SYN) Y 00000010 (queremos SYN)
     ----------------
= 00000010 = 00000010

Vemos que esta operación AND proporciona el mismo resultado sin importar si ACK u otro bit de control de TCP está establecido. La representación decimal del valor de Y, así como el resultado de esta operación es de 2 (binario 00000010), así que sabemos que para los paquetes con SYN establecen la relación siguiente debe ser cierto:

((Valor del octeto 13) Y (2)) == (2)

Esto nos señala el tcpdump expresión de filtro

‘tcp [13] y 2 == 2’ xl0 tcpdump-i

Tenga en cuenta que debe utilizar comillas simples o una barra invertida en la expresión de ocultar el carácter especial Y (‘y’) de la cáscara.Paquetes UDP

Formato UDP se ilustra por este paquete rwho:

actinide.who> broadcast.who: udp 84

Esto nos dice que el puerto que en el host actínidos envió un datagrama UDP al puerto que en el sistema principal de difusión , la dirección de difusión de Internet. El paquete contenía 84 bytes de datos de usuario.Algunos servicios UDP se reconocen (a partir de la fuente o número de puerto de destino) y la información de protocolo de nivel superior impresos. En particular, las solicitudes de servicio de nombres de dominio (RFC-1034/1035) y Sun llamadas RPC (RFC-1050) para NFS.

Las peticiones UDP del servidor de nombres

(Nota: La siguiente descripción supone familiaridad con el protocolo de servicio de dominio se describe en el RFC-1035 Si usted no está familiarizado con el protocolo, la siguiente descripción se parece estar escrito en griego.).

Peticiones al servidor Nombre se formatean como

src> dst: id op? banderas QTYPE QCLASS nombre (len)
 h2opolo.1538> helios.domain: 3 + A? ucbvax.berkeley.edu. (37)

Anfitrión h2opolo pregunté al servidor de dominio en helios para un registro de dirección (QTYPE = A) asociado con el nombre ucbvax.berkeley.edu. El id consulta era ‘3 ‘. El ‘+’ indica la deseada recursividad bandera fue creada. La longitud de la consulta fue de 37 bytes, sin incluir los encabezados de protocolo UDP e IP. La operación de consulta era la normal, de consulta , por lo que el campo OP se omitió. Si la op había sido otra cosa, hubiera sido impresa entre el ‘3 ‘y el’ + ‘. Del mismo modo, la QCLASS era la normal, C IN, y omite. Cualquier otro QCLASS habría sido impresa inmediatamente después de la ‘A’.Algunas anomalías se comprueban y pueden dar lugar a campos adicionales entre corchetes: Si una consulta contiene una sección de registros adicionales respuesta, los registros de autoridad o, ANCOUNT , NSCOUNT o ARCOUNT se imprimen como ‘[ n a] «,» [ n n ] «o» [ n au] «, donde n es el número apropiado. Si cualquiera de los bits de respuesta figuran (AA, AR o rcode) o cualquiera de los ‘cero debe ser’ bits se establecen en bytes dos y tres, ‘[b2 y 3 = x ] ‘se imprime, donde x es el valor hexadecimal de cabecera de bytes de dos y tres.

Respuestas UDP del servidor de nombres

Las respuestas del servidor Nombre tienen el formato

src> dst: flags Identificación op RCODE a / datos n / clase de tipo au (LEN)
 helios.domain> h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273)
helios.domain> h2opolo.1537: 2 NXDomain * 0/1/0 (97)

En el primer ejemplo, helios responde a consultar 3 Identificación de h2opolo con 3 registros de respuestas, 3 registros del servidor de nombres y 7 registros adicionales. El primer registro de respuesta es de tipo A (dirección) y sus datos es la dirección de Internet 128.32.137.3. El tamaño total de la respuesta fue de 273 bytes, excluidos cabeceras UDP e IP. La op (consulta) y el código de respuesta (NoError) fueron omitidos, al igual que la clase (C IN) del registro A.En el segundo ejemplo, helios responde a consultar 2 con un código de respuesta de dominio inexistente (NXDomain) sin respuestas, un servidor de nombres y no hay registros de autoridad. El ‘*’ indica que la respuesta autorizada poco se estableció. Dado que no había respuestas, no el tipo, clase o los datos se imprimieron.

Otros personajes bandera que pueden aparecer son ‘-‘ (recursividad disponible, RA, no establecido) y ‘|’ (mensaje truncado, TC, establecido). Si la sección ‘question’ no contiene exactamente una entrada, «[ n q] ‘se imprime.

Decodificación de SMB / CIFS

tcpdump incluye ahora bastante extensa decodificación de SMB / CIFS / NBT para los datos sobre UDP/137, UDP/138 y TCP/139. Algunos decodificación primitiva de datos IPX y NetBEUI SMB también se hace.

Por defecto una decodificación bastante mínimo se hace, con una decodificación mucho más detallado hecho si-v es utilizado. Ten en cuenta que con el paquete-va sola SMB puede tardar hasta una página o más, por lo que sólo utilice-v si realmente quieres todos los detalles sangrientos.

Para obtener información sobre formatos de paquetes SMB y lo que todos los campos del te quieren decir ver www.cifs.org o especificaciones directorio / pub / samba / en su sitio espejo samba.org favorito. Los parches SMB fueron escritas por Andrew Tridgell ( tridge@samba.org ).

Las solicitudes y respuestas de NFS

Sun NFS (Network File System) solicitudes y respuestas se imprimen como:

src.xid> dst.nfs: args op len
src.nfs> dst.xid: stat respuesta resultados op len

sushi.6709> wrl.nfs: 112 readlink fh 21,24 / 10.73165
wrl.nfs> sushi.6709: responder ok 40 readlink ".. / var"
sushi.201b> wrl.nfs:
     144 lookup fh 9,74 / 4096.6878 "xcolors"
wrl.nfs> sushi.201b:
     responder ok 128 lookup fh 9,74 / 4134.3150

En la primera línea, el anfitrión sushi envía una transacción con id 6709 a wrl (tenga en cuenta que el número que sigue al anfitrión src es una identificación de la transacción, noel puerto de origen). La solicitud fue de 112 bytes, excluidos los encabezados UDP e IP. La operación fue un readlink (leer el enlace simbólico) de identificador de archivo ( fh ) 21,24 / 10.731657119. (Si uno tiene suerte, como en este caso, el identificador de archivo se puede interpretar como una de las principales, el par número menor de dispositivo, seguido por el número de inodo y la generación de números.) Wrl responde «bien» con el contenido del enlace.En la tercera línea, sushi pide wrl para buscar el nombre de ‘ xcolors ‘en el archivo de directorio 9,74 / 4096.6878. Tenga en cuenta que los datos impresos depende del tipo de operación. El formato está destinado a ser explica por sí mismo si se lee en conjunción con un protocolo de especificación de NFS.

Si se da la opción-v (verbose) bandera, la información adicional se imprime. Por ejemplo:

sushi.1372a> wrl.nfs:
     148 leer fh 21,11 / 12,195 8,192 bytes @ 24576
wrl.nfs> sushi.1372a:
     responder ok 1472 leer REG 100.664 ids 417/0 sz 29388

(-V también imprime el TTL de la cabecera IP, ID, longitud y campos de fragmentación, que se han omitido en este ejemplo.) En la primera línea, sushi pide wrl a leer 8192 bytes del archivo 21,11 / 12,195, en el desplazamiento de bytes . 24576 Wrl responde «bien»; el paquete se muestra en la segunda línea es el primer fragmento de la respuesta, y por lo tanto es de sólo 1.472 bytes de longitud (los otros bytes seguirán en fragmentos siguientes, pero esos fragmentos no tienen NFS o incluso cabeceras UDP y por tanto no puede ser impreso, dependiendo de la expresión de filtro utilizado). Porque se da la opción-v, algunos de los atributos de archivo (que se devuelven, además de los datos del archivo) se imprimen: el tipo de archivo (»» REG, en archivo regular), el modo de archivo (en octal), el uid y gid, y el tamaño del archivo.Si la opción-v se da más de una vez, incluso más detalles se imprimen.

Tenga en cuenta que las peticiones NFS son muy grandes y muchos de los detalles no se imprimirá a menos snaplen se incrementa. Trate de usar ‘ s-192 ‘para ver el tráfico NFS.

Paquetes de respuesta de NFS no identifican explícitamente la operación RPC. En cambio, tcpdump realiza un seguimiento de las últimas peticiones»», y los compara con las respuestas utilizando el ID de la transacción. Si la respuesta no se sigue de cerca la correspondiente solicitud, que podría no ser apta para su procesamiento.

Las solicitudes y respuestas de AFS

Solicitudes y respuestas Transarc AFS (Andrew File System) se imprimen como:

src.sport> dst.dport: rx-tipo de paquete
src.sport> dst.dport: rx llamada de servicio de tipo de paquete args llamada nombre-
src.sport> dst.dport: rx-tipo de paquete de respuesta del servicio de llamada-nombre args

elvis.7001> pike.afsfs:
     fs datos rx llaman renombrar viejo fid 536876964/1/1 ". newsrc.new"
     nueva fid 536876964/1/1 ". newsrc"
pike.afsfs> elvis.7001: fs datos rx responden renombrar

En la primera línea, el anfitrión elvis envía un paquete de RX para el lucio. Este fue un paquete de datos RX a los fs (fileserver) servicio, y es el inicio de una llamada RPC. La llamada RPC fue un cambio de nombre, con la vieja Identificación del directorio de 536876964/1/1 y un antiguo nombre de ‘. Newsrc.new’, y una nueva identificación de archivos del directorio de 536876964/1/1 y un nuevo nombre de archivo ‘. newsrc ‘. El lucio host responde con una respuesta RPC para la llamada de cambio de nombre (que fue un éxito, ya que se trataba de un paquete de datos y no un paquete de interrupción).En general, todos los AFS RPCs son decodificadas por lo menos en nombre de la llamada RPC. La mayoría de AFS RPC tienen por lo menos algunos de los argumentos decodificados (por lo general sólo los argumentos «interesantes», por alguna definición de interesante).

El formato está destinado a ser uno mismo-descripción, pero probablemente no será útil para las personas que no están familiarizados con el funcionamiento de AFS y RX.

Si la opción-v (verbose) bandera se da dos veces, paquetes de confirmación e información adicional de encabezado se imprime, como los de la ID de llamada RX, el número de llamadas, número de secuencia, número de serie y la de paquetes RX banderas.

Si la opción-v se da dos veces, la información adicional se imprime, como el ID de la llamada RX, número de serie, y las banderas de paquetes RX. La información la negociación MTU también se imprime desde paquetes ACK RX.

Si la opción-v se administra tres veces, el índice de seguridad y la identificación del servicio se imprimen.

Los códigos de error se imprimen para los paquetes de abortar, con la excepción de los paquetes beacon Ubik (porque los paquetes de abortar se utilizan para significar un voto afirmativo para el protocolo Ubik).

Tenga en cuenta que las solicitudes de AFS son muy grandes y muchos de los argumentos no se imprimirá a menos snaplen se incrementa. Trate de usar ‘ s-256 ‘para ver el tráfico de AFS.

Paquetes de respuesta de AFS no identifican explícitamente la operación RPC. En cambio, tcpdump realiza un seguimiento de las últimas peticiones»», y los compara con las respuestas utilizando el número de la llamada y el ID de servicio. Si la respuesta no se sigue de cerca la correspondiente solicitud, que podría no ser apta para su procesamiento.

KIP AppleTalk (DDP en UDP)

Paquetes AppleTalk DDP encapsulados en datagramas UDP se encapsulan-des y arrojados como paquetes DDP (es decir, toda la información de la cabecera UDP se descarta). El archivo / etc / atalk.names se utiliza para traducir red AppleTalk y números de nodo a los nombres. Las líneas en el archivo tienen la forma

nombre número

1.254 éter
16.1 ICSD-net
1.254.110 as

Las dos primeras líneas dan los nombres de redes AppleTalk. La tercera línea le da el nombre de un host en particular (un host se distingue de una red por la tercera octeto en el número – un número de red debe tener dos octetos y un número de host debe . tener tres octetos) El número y el nombre deben ser separados por espacios en blanco (espacios o tabuladores). El / etc / atalk.names archivo puede contener líneas en blanco o las líneas de comentarios (líneas que comienzan con un ‘#’).Direcciones AppleTalk se imprimen en forma

net.host.port

144.1.209.2> ICSD-net.112.220
office.2> ICSD-net.112.220
jssmag.149.235> ICSD-net.2

(Si los archivos / etc / atalk.names no existe o no contiene una entrada para algunos de acogida número AppleTalk / net, las direcciones se imprimirán en formato numérico.) En el primer ejemplo, NBP (puerto DDP 2) en la red de 144,1 nodo 209 está enviando a lo que se escucha en el puerto 220 de nodo ICSD neta 112. La segunda línea es la misma, excepto el nombre completo del nodo de origen se conoce («oficina»). La tercera línea es un envío desde el puerto 235 en el nodo jssmag neta 149 para transmitir en el puerto NBP ICSD-net (tenga en cuenta que la dirección de difusión (255) se indica mediante un nombre de red sin número de host – por esta razón es una buena idea para mantener los nombres de nodo y nombres netos distintos en / etc / atalk.names).NBP (protocolo vinculante nombre) y ATP (protocolo de transacción AppleTalk) paquetes tienen sus contenidos interpretados. Otros protocolos simplemente vierten el nombre del protocolo (o número, si no hay ningún nombre registrado para el protocolo) y el tamaño de los paquetes.

Paquetes NBP se formatean como los ejemplos siguientes:

ICSD-net.112.220> jssmag.2: NBP-LKUP 190: "=: LaserWriter @ *"
jssmag.209.2> ICSD-net.112.220: NBP-respuesta 190: "RM1140: LaserWriter @ *" 250
techpit.2> ICSD-net.112.220: NBP-respuesta 190: "techpit: LaserWriter @ *" 186

La primera línea es una solicitud de búsqueda de nombre para LaserWriters enviados por el anfitrión ICSD neta 112 y transmitido por jssmag red. El id nbp para la búsqueda es de 190. La segunda línea muestra una respuesta para esta solicitud (en cuenta que tiene el mismo id) de jssmag.209 anfitrionas diciendo que tiene un recurso LaserWriter llamado «RM1140», registrada en el puerto 250. La tercera line es otra respuesta a la misma petición diciendo techpit anfitrión tiene LaserWriter «techpit», registrada en el puerto 186.Paquete ATP formato se demuestra en el siguiente ejemplo:

jssmag.209.165> helios.132: atp-req 12266 <0-7> 0xae030001
helios.132> jssmag.209.165:-atp resp 12266:0 (512) 0xae040000
helios.132> jssmag.209.165:-atp resp 12266:1 (512) 0xae040000
helios.132> jssmag.209.165:-atp resp 12266:2 (512) 0xae040000
helios.132> jssmag.209.165:-atp resp 12266:3 (512) 0xae040000
helios.132> jssmag.209.165:-atp resp 12266:4 (512) 0xae040000
helios.132> jssmag.209.165:-atp resp 12266:5 (512) 0xae040000
helios.132> jssmag.209.165:-atp resp 12266:6 (512) 0xae040000
helios.132> jssmag.209.165: atp-resp * 12266:7 (512) 0xae040000
jssmag.209.165> helios.132: atp-req 12266 <3,5> 0xae030001
helios.132> jssmag.209.165:-atp resp 12266:3 (512) 0xae040000
helios.132> jssmag.209.165:-atp resp 12266:5 (512) 0xae040000
jssmag.209.165> helios.132: atp-rel 12266 <0-7> 0xae030001
jssmag.209.133> helios.132: atp-req * 12267 <0-7> 0xae030002

Jssmag.209 inicia identificación de la transacción 12266 con helios acogida mediante la solicitud hasta 8 paquetes (el ‘<0-7>’). El número hexadecimal al final de la línea es el valor del campo «datos de usuario ‘en la solicitud.Helios responde con 8 paquetes de 512 bytes. El ‘: Dígito’ después de la identificación de la transacción da el número de secuencia de paquetes en la transacción y el número de parens es la cantidad de datos en el paquete, excluyendo la cabecera atp. El ‘*’ en el paquete de 7 indica que el bit EOM se estableció.

Jssmag.209 solicita entonces que los paquetes 3 ​​y 5 serán retransmitidos. Helios les reenvía entonces jssmag.209 estrenos de la transacción. Finalmente, jssmag.209 inicia la siguiente solicitud. El ‘*’ en la solicitud se indica que la XO (‘una sola vez’) fue no ajustado.

Fragmentación IP

Datagramas fragmentados de Internet se imprimen como

(Frag  Identificación : tamaño @ compensado +)
(Frag  Identificación : tamaño @ compensar )

(La primera forma indica que hay más fragmentos. La segunda indica que es el último fragmento.)Id es el identificador de fragmento. tamaño es el tamaño de los fragmentos (en bytes) excluyendo la cabecera IP. Offset es este fragmento de desplazamiento (en bytes) en el datagrama original.

La información de fragmento es de salida para cada fragmento. El primer fragmento contiene el encabezado de protocolo de nivel superior y de la información de fragmentación se imprime después de que la información del protocolo. Los fragmentos después de la primera contiene ningún encabezado de protocolo de nivel superior y la información de fragmentación se imprime después de la direcciones de origen y de destino. Por ejemplo, aquí es parte de un ftp desde arizona.edu a LBL-rtsg.arpa través de una conexión CSNET que no aparece para manejar datagramas 576 bytes:

-datos arizona.ftp> rtsg.1170:. 1024: 1332 (308) ack 1 victoria 4096 (595A frag: 328 @ 0 +)
arizona> rtsg: (595A frag: 204 @ 328)
rtsg.1170> arizona.ftp-data:. ack 1536 ganan 2560

Hay un par de cosas a destacar aquí: En primer lugar, las direcciones de la segunda línea no incluyen números de puerto. Esto se debe a que la información del protocolo TCP es todo en el primer fragmento y no tenemos idea de lo que los números de puerto o de secuencia son cuando imprimimos los fragmentos posteriores. En segundo lugar, la información de la secuencia TCP en la primera línea se imprime como si no hubiera 308 bytes de datos de usuario cuando, de hecho, hay 512 bytes (308 en la primera fragmentación y 204 en el segundo). Si usted está buscando para los agujeros en el espacio de secuencias o tratando de hacer coincidir acks con paquetes, esto puede engañar a usted.Un paquete con la IP no fragmentar bandera está marcado con un trailing (DF) .

Las marcas de tiempo

De forma predeterminada, todas las líneas de salida están precedidos por una marca de tiempo. La indicación de la hora es la hora actual en forma

hh: mm: ss.frac

y es tan preciso como el reloj del núcleo. La marca de tiempo refleja el momento en que el kernel por primera vez el paquete. No se intenta dar cuenta del tiempo que transcurre entre el momento en la interfaz Ethernet elimina el paquete del alambre y cuando el núcleo reparado el «nuevo paquete de ‘interrumpir.

Vea también

stty (1), pcap (3PCAP), bpf (4), nit (4P), pcap-archivo de salvar (5), pcap-filtro (7)

Autores

Los autores originales son:

Van Jacobson, Craig Leres y Steven McCanne, todos del Laboratorio Nacional Lawrence Berkeley, Universidad de California, Berkeley, CA.

Se está manteniendo actualmente por tcpdump.org.

La versión actual está disponible a través de http:

http://www.tcpdump.org/

La distribución original está disponible a través de ftp anónimo:

ftp://ftp.ee.lbl.gov/tcpdump.tar.Z

Apoyo IPv6/IPsec es añadido por proyecto WIDE / KAME. Este programa utiliza la biblioteca SSLeay de Eric Young, en configuraciones específicas.

Errores

Por favor, envíe los problemas, errores, dudas, mejoras deseables, parches etc a:

tcpdump-workers@lists.tcpdump.org

NIT no le permite ver su propio tráfico saliente, BPF hará. Le recomendamos que use estos últimos.[.] X En sistemas Linux con kernel 2.0:

paquetes en el dispositivo de bucle de retorno se verá dos veces;filtrado de paquetes no se puede hacer en el kernel, por lo que todos los paquetes se deben copiar desde el núcleo para ser filtrado en modo de usuario;

todo de un paquete, no sólo la parte que está dentro de la longitud de instantáneas, se copiarán desde el kernel (el 2,0 [. x] mecanismo de captura de paquetes, si se le pide copiar sólo una parte de un paquete al espacio de usuario, no reportar la longitud verdadera del paquete, lo que haría que la mayoría de los paquetes IP para obtener un error de tcpdump );

capturar en algunos dispositivos PPP no funcionará correctamente.

Le recomendamos que actualice a un 2.2 o posterior del kernel.Algunos se debe intentar volver a ensamblar los fragmentos IP o, al menos, para calcular la longitud adecuada para el protocolo de nivel superior.

Consultas inversas servidor de nombres no son objeto de dumping correctamente: el (vacío) sección de preguntas se imprime en lugar de consulta real en la sección de respuestas. Algunos creen que las consultas inversas son en sí mismos un error y prefieren fijar el programa de generación de ellos en lugar de tcpdump .

Una traza de paquetes que atraviesa un cambio de hora de ahorro dará marcas de tiempo sesgadas (se ignora el cambio de hora).

Filtrar expresiones en campos distintos de aquellos en los encabezados de Token Ring no manejar correctamente los paquetes Token Ring de encaminamiento de origen.

Filtrar expresiones en campos distintos de aquellos en 802,11 encabezados no manejar correctamente los paquetes de datos 802,11 con ambos para DS y DS De conjunto.

ip6 proto debe perseguir la cadena de cabecera, pero en este momento no es así. ip6 protochain se suministra para este comportamiento.

Expresión aritmética contra cabeceras de capa de transporte, como TCP [0] , no funciona en contra de los paquetes IPv6. Sólo mira a los paquetes IPv4.