命令行大全

tcpdump

rose1 发表于 2020-07-15 18:27浏览次数:

在类似Unix的操作系统上,tcpdump收集网络流量的原始转储。 本文档介绍了tcpdump的Linux版本。

查看英文版

目录:

1 tcpdump 运行系统环境

2 tcpdump 说明

3 tcpdump 语法

4 tcpdump 例子

tcpdump 运行系统环境

Linux

tcpdump 说明

Tcpdump 在网络接口上打印出与命令行上指定的布尔表达式匹配的数据包内容的描述。它也可以与-w标志一起运行,这会导致将数据包数据保存到文件中以供以后分析;也可以与-r标志一起运行,这会使它从已保存的数据包文件中读取,而不是从其中读取数据包。网络接口。

Tcpdump (如果未与-c标志一起运行)将继续捕获数据包,直到它被SIGINT 信号(例如,当用户键入中断 字符,通常为control-C)或SIGTERM信号(通常由kill生成)中断为止命令); 如果使用-c标志运行,它将捕获数据包,直到被SIGINTSIGTERM信号中断或指定数量的数据包已被处理为止。

tcpdump完成捕获数据包时,它将报告以下计数:

  • “捕获”的数据包(tcpdump已接收和处理的数据包数);
  • “过滤器接收到的”数据包(其含义取决于您正在运行tcpdump的操作系统,并且可能取决于该操作系统的配置方式;如果在命令行上指定了过滤器,则在某些操作系统上,它将对数据包进行计数,无论它们是否与过滤器表达式匹配,以及即使它们与过滤器表达式匹配也不管tcpdump是否已读取和处理它们;在其他操作系统上,它仅计算与过滤器表达式匹配的数据包,无论是否tcpdump尚未读取并处理它们,在其他操作系统上,它仅计算与过滤器表达式匹配并由tcpdump处理的数据包);
  • “被内核丢弃的数据包” (这是由于缺少缓冲区空间而在运行tcpdump的操作系统中由数据包捕获机制丢弃的数据包的数量,如果操作系统向应用程序报告了该信息;则不是) ,则报告为0)。

在支持SIGINFO信号的平台(例如大多数BSD操作系统(包括macOS X)和Digital / Tru64 UNIX)上,它将在收到SIGINFO信号(例如,通过键入“状态”字符生成(例如))时报告这些计数,通常为control-T;尽管在某些平台上,例如macOS X,默认情况下未设置“状态”字符,因此必须使用stty进行设置才能使用它),并将继续捕获数据包。

从网络接口读取数据包可能需要您具有特殊的特权 ; 有关详细信息,请参见pcap(3PCAP)手册。读取保存的数据包文件不需要特殊的特权。

Tcpdump prints out a description of the contents of packets on a network interface that match the boolean expression specified on the command line. It can also be run with the -w flag, which causes it to save the packet data to a file for later analysis, or with the -r flag, which causes it to read from a saved packet file rather than to read packets from a network interface.

Tcpdump will, if not run with the -c flag, continue capturing packets until it is interrupted by a SIGINT signal (for example, when the user types the interrupt character, typically control-C) or a SIGTERM signal (typically generated with the kill command); if run with the -c flag, it will capture packets until it is interrupted by a SIGINT or SIGTERM signal or the specified number of packets have been processed.

When tcpdump finishes capturing packets, it will report counts of the following:

  • packets "captured" (the number of packets that tcpdump has received and processed);
  • packets "received by filter" (the meaning of this depends on the OS on which you're running tcpdump, and possibly on the way the OS was configured; if a filter was specified on the command line, on some OSes it counts packets regardless of whether they were matched by the filter expression and, even if they were matched by the filter expression, regardless of whether tcpdump has read and processed them yet; on other operating systems it counts only packets that were matched by the filter expression regardless of whether tcpdump has read and processed them yet, and on other OSes it counts only packets that were matched by the filter expression and were processed by tcpdump);
  • packets "dropped by kernel" (this is the number of packets that were dropped, due to a lack of buffer space, by the packet capture mechanism in the OS on which tcpdump is running, if the OS reports that information to applications; if not, it will be reported as 0).

On platforms that support the SIGINFO signal, such as most BSD operating systems (including macOS X) and Digital/Tru64 UNIX, it will report those counts when it receives a SIGINFO signal (generated (for example) by typing the "status" character, typically control-T; although on some platforms, such as macOS X, the "status" character is not set by default, so you must set it with stty to use it) and will continue capturing packets.

Reading packets from a network interface may require that you have special privileges; see the pcap (3PCAP) manual for details. Reading a saved packet file doesn't require special privileges.

查看英文版

查看中文版

tcpdump 语法

tcpdump [ -AbdDefhHIJKlLnNOpqRStuUvxX ] [ -B buffer_size ] [ -c count ] 
        [ -C file_size ] [ -G rotate_seconds ] [ -F file ] [ -i interface ] 
        [ -j tstamp_type ] [ -m module ] [ -M secret ] [ -r file ] 
        [ -s snaplen ] [ -T type ] [ -w file ] [ -W filecount ] 
        [ -E spi@ipaddr algo:secret,... ] [ -y datalinktype ] 
        [ -z postrotate-command ] [ -Z user ] [ expression ]

选件

-A 以ASCII格式打印每个数据包(减去其链接级标题)。方便捕获网页。
-b 以ASDOT表示法而不是ASPLAIN表示法打印BGP数据包中的AS编号。
-B buffer_size 将操作系统捕获缓冲区大小设置为buffer_size,以KiB(1024 字节)为单位。
-c count 收到计数包后退出。
-C file_size 在将原始数据包写入保存文件之前,请检查文件当前是否大于file_size,如果是,则关闭当前保存文件并打开一个新文件。第一个保存文件之后的保存文件具有用-w标志指定的名称,后跟一个数字,从1开始并一直向上。file_size的单位是数百万个字节(1,000,000字节,而不是1,048,576字节)。
-d 以人类可读的形式将编译后的数据包匹配代码转储到标准输出并停止。
-dd 将数据包匹配代码转储为C程序片段。
-ddd 将数据包匹配代码转储为十进制数字(带计数)。
-D 打印系统上可用的网络接口列表,tcpdump可以在该网络接口上捕获数据包。对于每个网络接口,将打印一个数字和一个接口名称,并可能在其后显示该接口的文本描述。可以将接口名称或编号提供给-i标志,以指定要捕获的接口。

在没有命令列出它们的系统上(例如Windows系统或缺少ifconfig -a的 UNIX系统),此选项很有用。该数字在Windows 2000及更高版本的系统上非常有用,在Windows 2000及更高版本的系统上,接口名称是一个有点复杂的字符串。

该-D标志将不被支持,如果tcpdump是使用缺少pcap_findalldevs()函数的libpcap的较早版本构建的。
-e 在每个转储行上打印链接级标题。
-E 使用SPI @ IPADDR 算法中:秘密的解密 的IPsec ESP寻址到分组地址,并包含安全参数索引值SPI。可以用逗号或换行符分隔重复此组合。

请注意,目前支持为IPv4 ESP数据包设置密钥。

算法可以是des-cbc, 3des-cbc,blowfish-cbc,rc3-cbc,cast128-cbc或无。 默认值为des-cbc。只有在启用了加密功能的情况下编译tcpdump时,才具有解密数据包的能力。

secret是ESP密钥的ASCII文本。如果以0x开头,则将读取一个十六进制值。

该选项假定使用RFC 2406 ESP,而不是RFC 1827 ESP。该选项仅用于调试目的,不建议将此选项与真正的“秘密”密钥一起使用。通过在命令行上显示IPsec秘密密钥,您可以通过ps(1)和其他场合将其公开给他人。

除上述语法外,语法文件名还可用于使tcpdump使用文件中的数据。该文件在收到第一个ESP数据包后便打开,因此tcpdump可能已赋予的任何特殊权限都应该已经放弃。
-f 用数字而不是符号打印“外部” IPv4地址(此选项旨在解决Sun NIS服务器的问题-通常,它永久挂起翻译本地的Internet号码)。

使用在其上进行捕获的接口的IPv4地址和网络掩码来完成对“外部” IPv4地址的测试。如果该地址或网络掩码不可用,或者是因为正在执行捕获的接口没有地址或网络掩码,或者是因为正在Linux的“ any ”接口上进行了捕获,而该接口可以在多个接口上进行捕获,所以此选项将无法正常工作。
-F file 将文件用作过滤器表达式的输入。命令行上给出的其他表达式将被忽略。
-G rotate_seconds 如果指定,则每隔rotate_seconds秒旋转一次使用-w选项指定的转储文件。保存文件的名称由-w指定,该名称应包含strftime定义的时间格式。如果未指定时间格式,则每个新文件都将覆盖前一个文件。

如果与-C选项一起使用,则文件名的格式为' file'。
-h 打印tcpdump和libpcap版本字符串,打印用法消息,然后退出。
-H 尝试检测802.11s草案网格标头。
-i interface 在界面上收听。如果未指定,则tcpdump在系统接口列表中搜索编号最小,配置最多的接口(不包括环回)。通过选择最早的比赛来打破关系。

在具有2.2或更高版本内核的Linux系统上,可以使用接口参数“ any ”捕获来自所有接口的数据包。注意,在“ any ”设备上的捕获不会以混杂模式进行。如果支持-D标志,则可以将该标志打印的接口号用作接口参数。
-I 将接口置于“监视模式”;仅在IEEE 802.11 Wi-Fi接口上支持此功能,并且在某些操作系统上仅支持此功能。

请注意,在监视方式下,适配器可能会与与其关联的网络解除关联,因此您将无法使用该适配器使用任何无线网络。如果您以监视方式捕获并且未使用其他适配器连接到另一个网络,则这可能会阻止访问网络服务器上的文件或解析主机名或网络地址。

该标志将影响-L标志的输出。如果未指定-I,则仅显示那些不在监视方式下可用的链路层类型;如果-I 如果指定,则仅显示在监视模式下可用的那些链路层类型。
-j tstamp_type 将捕获的时间戳类型设置为tstamp_type。在pcap-tstamp-type(7)中给出了用于时间戳类型的名称。并非所有列出的类型对于任何给定接口都必须有效。
-J 列出接口支持的时间戳类型并退出。如果无法为接口设置时间戳类型,则不会列出任何时间戳类型。
-K 列出接口支持的时间戳类型并退出。如果无法为接口设置时间戳类型,则不会列出任何时间戳类型。
-l 使标准输出行缓冲。如果要在捕获数据时查看数据,则很有用。例如,



tcpdump -l | tee dat
or

tcpdump -l > dat & tail -f dat
请注意,在Windows上,“行缓冲”表示“未缓冲”,因此,如果指定了-l,则WinDump将分别写入每个字符。

-U的行为与-l相似,但是它会导致输出被“分组缓冲”,因此输出将在每个数据包的末尾而不是在每一行的末尾写入stdout;这在包括Windows在内的所有平台上都有缓冲。
-L 列出指定模式下接口的已知数据链路类型,然后退出。已知数据链路类型的列表可能取决于指定的模式。例如,在某些平台上,Wi-Fi接口在不处于监视模式时可能支持一组数据链路类型(例如,它可能仅支持伪造的以太网标头,或者可能支持802.11标头,但不支持带有无线电信息的802.11标头。 )以及在监控器模式下的另一组数据链路类型(例如,仅在监控器模式下,它可能支持802.11标头或带有无线电信息的802.11标头)。
-m module 从文件模块加载SMI MIB模块定义。可以多次使用此选项,以将多个MIB模块加载到tcpdump中。
-M secret 如果使用TCP- MD5选项(RFC 2385),可以使用secret作为共享密钥来验证在TCP段中找到的摘要。
-n 不要将地址(即主机地址,端口号等)转换为名称。
-N 不要打印主机名的域名限定。例如,如果提供此标志,则tcpdump将打印“ nic”而不是“ nic.ddn.mil”。
-O 不要运行数据包匹配代码优化器。仅当您怀疑优化器中存在错误时,此选项才有用。
-p 不要将接口置于混杂模式。请注意,由于某些其他原因,接口可能处于混杂模式。因此,“ -p ”不能用作“以太主机{local-hw-addr}或以太广播的缩写”。
-q 快速/安静的输出。打印较少的协议信息,因此输出行更短。
-R 假设ESP / AH数据包基于旧规范(RFC1825至RFC1829)。如果指定,tcpdump将不会显示防止重放的字段。由于ESP / AH规范中没有协议版本字段,因此tcpdump无法推断ESP / AH协议的版本。
-r file 从文件(使用-w选项创建)中读取数据包。如果文件为“ - ”,则使用标准输入。
-S 打印绝对而不是相对的TCP序列号。
-s snaplen Snarf snaplen有字节的数据从每个分组而不是65535个字节的缺省值。由于快照受限而被截断的数据包在输出中以“ [| proto] ”表示,其中proto是发生截断的协议级别的名称。请注意,拍摄较大的快照既增加了处理数据包的时间,又有效地减少了数据包缓冲的时间。这可能会导致数据包丢失。您应该将snaplen限制为将捕获您感兴趣的协议信息的最小数量。将snaplen设置为0会将其设置为默认值65535,例如向后兼容最新版本的tcpdump。
-T type 强制将由“表达式”选择的数据包解释为指定的类型。当前已知的类型是aodv(临时按需距离矢量协议),cnfp(Cisco NetFlow协议),rpc(远程过程调用),rtp(实时应用协议),rtcp(实时应用控制协议),snmp(简单网络管理协议),tftp(临时文件传输协议),vat(可视音频工具)和wb(分布式白板)。
-t 不要在每个转储行上打印时间戳。
-tt 请在每个转储行上打印未格式化的时间戳。
-ttt 在每个转储行的当前行和上一行之间打印增量(微秒分辨率)。
-tttt 在每个转储行上以默认格式打印时间戳,并在日期之前加上日期。
-ttttt 在每个转储行的当前行和第一行之间打印增量(微秒分辨率)。
-u 打印未解码的NFS句柄。
-U 如果未指定-w选项,则使打印的数据包输出为“ packet-buffered”;即,当打印每个数据包内容的描述时,它将被写入标准输出,而不是在不写入终端时,仅在输出缓冲区已满时才写入。

如果指定了-w选项,则将保存的原始数据包输出设置为“ packet-buffered”;也就是说,保存每个数据包时,会将其写入输出文件,而不是仅在输出缓冲区填满时才写入。该-U如果标志将不被支持的tcpdump与旧版本的libpcap的缺乏内置pcap_dump_flush()函数。
-v 解析和打印时,产生(略多)详细输出。例如,打印IP数据包中的生存时间,标识,总长度和选项。此外,启用其他数据包完整性检查,例如验证IP和ICMP标头校验和。

当使用-w选项写入文件时,每10秒钟报告一次捕获的数据包数量。
-vv 更详细的输出。例如,从NFS答复数据包中打印其他字段,并对SMB数据包进行完全解码。
-vvv 更详细的输出。例如,telnet SB ... SE选项将完整打印。使用-X Telnet选项时,也以十六进制打印。
-w 将原始数据包写入文件,而不是解析并打印出来。以后可以使用-r选项打印它们。如果文件为“ - ”,则使用标准输出。

如果将该输出写入文件或管道,则将对其进行缓冲,因此从文件或管道读取的程序在接收到数据包后的任意时间内可能看不到它们。使用-U标志使数据包在收到后立即被写入。

有关文件格式的说明,请参见pcap-savefile(5)。
-W 与-C选项一起使用,这会将创建的文件数限制为指定的数目,并从头开始覆盖文件,从而创建“旋转”缓冲区。同样,它将以足够的前导0命名文件,以支持最大数量的文件,从而使它们能够正确排序。

与-G选项一起使用,这将限制所创建的旋转转储文件的数量,达到限制时以状态0退出。如果也与-C一起使用,则该行为将导致每个时间片产生周期性文件。
-x 解析和打印时,除了打印每个数据包的标题外,还以十六进制打印每个数据包的数据(减去其链接级别的标题)。整个数据包或快照字节中较小的一个将被打印。请注意,这是整个链路层数据包,因此对于填充(例如以太网)的链路层,当较高层数据包短于所需填充时,填充字节也将被打印出来。
-xx 解析和打印时,除了打印每个数据包的标头外,还以十六进制打印每个数据包的数据,包括其链接级别标头。
-X 解析和打印时,除了打印每个数据包的标题外,还以十六进制和ASCII打印每个数据包的数据(减去其链接级别的标题)。此选项对于分析新协议非常方便。
-XX 解析和打印时,除了打印每个数据包的标头外,还以十六进制和ASCII码打印每个数据包的数据,包括其链接级别标头。
-y datalinktype 设置将数据包捕获到datalinktype时要使用的数据链路类型。
-z postrotate-command 与-C或-G选项一起使用,这将使tcpdump运行“ command file ”,其中file是每次旋转后关闭的保存文件。例如,指定-z gzip或-z bzip2将使用gzip或bzip2压缩每个保存文件。

请注意,tcpdump将使用最低优先级与捕获并行运行命令,以免打扰捕获过程。

并且,如果您想使用本身带有标志或其他参数的命令,则始终可以编写一个以保存文件名作为唯一参数的shell脚本,并在其中添加&参数安排并执行所需的命令。
-Z user 如果tcpdump以root身份运行,则在打开捕获设备或输入保存文件之后,但在打开任何保存文件以进行输出之前,请将用户ID更改为user,将组ID更改为主要的user组。

默认情况下,也可以在编译时启用此行为。
expression 选择要转储的数据包。如果未给出任何表达式,则网络上的所有数据包都将被转储。否则,将仅转储表达式为“ true ”的数据包。

有关表达式语法,请参见pcap-filter(7)。

表达式参数可以作为单个参数或多个参数传递到tcpdump,以较方便的方式为准。 通常,如果表达式包含Shell元字符,则更容易将其作为单个引用的参数传递。多个参数在解析之前用空格连接。

输出格式

tcpdump的输出取决于协议。以下给出了大多数格式的简要说明和示例。

链接级别标题

如果给出' -e '选项,则打印出链接级别标题。在以太网上,将打印源和目标地址,协议和数据包长度。

在FDDI网络上,“- e ”选项使tcpdump打印“ 帧控制 ”字段,源和目标地址以及数据包长度。(“帧控制”字段控制其余数据包的解释。普通数据包(例如包含IP数据报的数据包)是优先级介于0到7之间的“ 异步 ”数据包;例如,“ 异步4 ”。数据包假定包含802.2逻辑链路控制(LLC)数据包;如果它不是ISO数据报或所谓的SNAP数据包,则打印LLC头。

在令牌环网络上,“- e ”选项使tcpdump打印“ 访问控制 ”和“ 帧控制 ”字段,源和目标地址以及数据包长度。与在FDDI网络上一样,假定数据包包含LLC数据包。无论是否指定了-e选项,都会为源路由包打印源路由信息。

在802.11网络上,“ -e ”选项使tcpdump打印“ 帧控制 ”字段,802.11标头中的所有地址以及数据包长度。与在FDDI网络上一样,假定数据包包含LLC数据包。

注意:以下描述假定您熟悉RFC-1144中描述的SLIP 压缩算法。

在SLIP链接上,将打印出方向指示符(“ I ”代表入站,“ O ”代表出站),数据包类型和压缩信息。首先打印数据包类型。三种类型是ip,utcp和ctcp。没有为IP数据包打印更多的链接信息。对于TCP数据包,连接标识符将按照类型打印。如果压缩了数据包,则将打印出其编码的标头。特殊情况打印为* S + n和* SA + n,其中n是序列号(或序列号和ack的数量)) 已经改变。如果不是特殊情况,则会打印零个或多个更改。更改由U(紧急指针),W(窗口),A(确认),S(序列号)和I(数据包ID)表示,后跟增量(+ n或-n)或新值(= n)。最后,将打印数据包中的数据量和压缩的报头长度。

例如,下面的行显示了出站压缩的TCP数据包,其中包含隐式连接标识符;ack更改为6,序列号更改为49,数据包ID 更改为6 ; 有3个字节的数据和6个字节的压缩头:

O ctcp * A+6 S+49 I+6 3 (6)

ARP / RARP数据包

Arp / Rarp输出显示请求的类型及其参数。该格式旨在进行自我说明。这是从主机rtsg到主机csam的' rlogin ' 开头的简短示例:

arp who-has csam tell rtsg arp reply csam is-at CSAM

第一行说rtsg发送了一个arp数据包,询问Internet主机csam的以太网地址。Csam会回复其以太网地址(在此示例中,以太网地址为大写形式,Internet地址为小写形式)。


如果我们完成了tcpdump -n,这看起来将减少冗余:

arp who-has 128.3.254.6 tell 128.3.254.68 
arp reply 128.3.254.6 is-at 02:07:01:00:01:c4

如果我们完成了tcpdump -e,则第一个数据包被广播而第二个数据包是点对点的事实将是可见的:


RTSG Broadcast 0806 64: arp who-has csam tell rtsg 
CSAM RTSG 0806 64: arp reply csam is-at CSAM

对于第一个数据包,它说以太网源地址是RTSG,目的地是以太网广播地址,类型字段包含十六进制0806(类型ETHER_ARP),总长度为64字节。

TCP数据包

注意:以下描述假定您熟悉RFC-793中描述的TCP协议。如果您不熟悉该协议,则此说明和tcpdump都不会对您有太大帮助。

TCP协议行的一般格式为:

src > dst: flags data-seqno ack window urgent options

Src和dst是源IP地址和目标IP地址和端口。标志是S(SYN),F(FIN),P(PUSH),R(RST),U(URG),W(ECN CWR),E(ECN-Echo)或'的某种组合。'(ACK),如果未设置标志,则为' none '。data-seqno描述此数据包中的数据所覆盖的序列空间的一部分(请参见下面的示例)。ack是该连接上另一个方向所期望的下一个数据的序列号。窗口是此连接上另一个方向可用的接收缓冲区空间的字节数。urg表示数据包中有“紧急”数据。选项是尖括号中包含的tcp选项(例如,)。

Src,dst和flags始终存在。其他字段取决于数据包的tcp协议标头的内容,仅在适当时才输出。

这是从主机rtsg到主机csam的rlogin的开头部分。

rtsg.1023 > csam.login: S 768512:768512(0) win 4096csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096rtsg.1023 > csam.login: . ack 1 win 4096
rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096
csam.login > rtsg.1023: . ack 2 win 4096
rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096
csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077
csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1
csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1

第一行说,TCP端口1023上RTSG发送一个数据包到端口登录上CSAM。在小号表明设置SYN标志。数据包序列号为768512,不包含任何数据。表示法是“ first:last(nbytes) ”,这表示“序列号从上至下但不包括用户数据的nbytes字节”。没有后备的ack,可用的接收窗口为4096字节,并且有一个max-segment-size选项,要求mss为1024字节。

Csam回复了一个类似的数据包,除了它包含用于rtsg的SYN的背负式ack。Rtsg然后确认csam的SYN。的' 。'表示已设置ACK标志。该数据包不包含任何数据,因此没有数据序列号。请注意,ack序列号是一个小整数。第一次tcpdump看到一个tcp“对话”,它将打印数据包中的序列号。在会话的后续数据包上,将打印当前数据包的序列号和此初始序列号之间的差异。这意味着可以将第一个之后的序列号解释为会话数据流中的相对字节位置(第一个数据字节的每个方向均为“ 1 ”)。' -S '将覆盖此功能,导致输出原始序列号。

在第6行,rtsg向csam发送19个字节的数据(对话的rtsg→csam端的字节2到20)。在分组中设置PUSH标志。在第七行,csam表示它已收到rtsg发送的数据,但不包括字节21。由于csam的接收窗口已缩小了19个字节,因此大多数数据显然位于套接字缓冲区中。Csam还在此数据包中向rtsg发送一个字节的数据。在第8和9行,csam将两个字节的紧急推送数据发送到rtsg。

如果快照足够小,以至于tcpdump无法捕获完整的TCP标头,则它将尽可能地解释标头,然后报告“ [| tcp] ”以指示无法解释其余标头。如果标头包含伪造的选项(长度太小或超出标头末尾),则tcpdump将其报告为“ [Bad opt] ”,并且不解释任何其他选项(因为无法分辨出它们的位置)开始)。如果报头长度指示存在选项,但IP数据报长度不足以使该选项实际存在,则tcpdump将其报告为“ [错误的hdr长度] ”。

使用特定标志组合(SYN-ACK,URG-ACK等)捕获TCP数据包

TCP标头的控制位部分有8位:

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

假设我们要监视建立TCP连接中使用的数据包。回想一下,TCP 在初始化新连接时使用3向握手协议。关于TCP控制位的连接顺序为

  1. 呼叫者发送SYN
  2. 收件人以SYN,ACK响应
  3. 呼叫者发送ACK

现在,我们有兴趣捕获仅设置了SYN位的数据包(第1步)。请注意,我们不希望来自第2步(SYN-ACK)的数据包是普通的初始SYN。我们需要的是tcpdump的正确过滤器表达式。

调用不带选项的TCP标头的结构:

       0                              15                              31
       -----------------------------------------------------------------
       |          source port          |       destination port        |
       -----------------------------------------------------------------
       |                        sequence number                        |
       -----------------------------------------------------------------
       |                     acknowledgment number                     |
       -----------------------------------------------------------------
       |  HL   | rsvd  |C|E|U|A|P|R|S|F|        window size            |
       -----------------------------------------------------------------
       |         TCP checksum          |       urgent pointer          |
       -----------------------------------------------------------------

除非存在选项,否则TCP标头通常包含20 个八位位组的数据。图表的第一行包含八位字节0-3,第二行显示八位字节4-7等。

从0开始计数,相关的TCP控制位包含在八位位组中:

        0             7|             15|             23|             31
       ----------------|---------------|---------------|----------------
       |  HL   | rsvd  |C|E|U|A|P|R|S|F|        window size            |
       ----------------|---------------|---------------|----------------
       |               |  13th octet   |               |               |

让我们仔细看看八位位组。13:

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

这些是您感兴趣的TCP控制位。我们已将此字节中的位从右至左从0到7进行了编号,因此PSH位是第3位,而URG位是第5位。

回想一下我们只想捕获设置了SYN的数据包。让我们看看如果TCP数据报到达时在标头中设置了SYN位,则八位位组会发生什么:

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

查看控制位部分,我们看到仅设置了位号1(SYN)。

假设八位位组号13是网络字节顺序的8位无符号整数,则此八位位组的二进制值为


00000010

其十进制表示为

         ^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

我们差不多完成了,因为现在我们知道,如果仅设置SYN,则TCP报头中的第13个八位位组的值(按网络字节顺序解释为8位无符号整数)必须恰好为2。

这种关系可以表示为:

tcp[13] == 2

我们可以将此表达式用作tcpdump的筛选器,以监视仅设置了SYN的数据包:

tcpdump -i xl0 tcp[13] == 2

该表达式表示“让TCP数据报的第13个八位字节具有十进制值2”,这正是我们想要的。


现在,让我们假设我们需要捕获SYN数据包,但是我们不在乎是否同时设置了ACK或任何其他TCP控制位。让我们看看设置了SYN-ACK的TCP数据报到达八位位组会发生什么:

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

现在,在第13个八位字节中设置了位1和4。八位位组13的二进制值为

00010010

转换为十进制18:

         ^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

现在我们不能在tcpdump过滤器表达式中使用' tcp [13] == 18 ' ,因为那样只会选择那些设置了SYN-ACK的数据包,而不选择那些仅设置SYN-ACK的数据包。请记住,只要设置了SYN,我们就不会在乎是否设置了ACK或任何其他控制位。

为了实现我们的目标,我们需要将八位位组13的二进制值与其他值进行逻辑与运算,以保留SYN位。我们知道在任何情况下都希望设置SYN,因此我们将第13个八位位组中的值与SYN的二进制值进行逻辑与:

                 00010010 SYN-ACK              00000010 SYN
            AND  00000010 (we want SYN)   AND  00000010 (we want SYN)
                 --------                      --------
            =    00000010                 =    00000010

我们看到,无论是否设置了ACK或另一个TCP控制位,此AND操作都将提供相同的结果。AND值的十进制表示形式以及此操作的结果为2(二进制00000010),因此我们知道,对于具有SYN设置的数据包,以下关系必须成立:

((八位位组13的值)AND(2))==(2)


这使我们指向了tcpdump过滤器表达式

tcpdump -i xl0 'tcp & 2 == 2'

某些偏移量和字段值可以表示为名称而不是数字值。例如,tcp]可以替换为tcp [tcpflags]。以下TCP标志字段值也可用:tcp-fin,tcp-syn,tcp-rst,tcp-push,tcp-act,tcp-urg。

这可以证明为:

tcpdump -i xl0 'tcp[tcpflags] & tcp-push != 0'

请注意,您应在表达式中使用单引号或反斜杠以保护AND(' & ')特殊字符不受外壳影响。

UDP数据包

此rwho数据包说明了UDP格式:

actinide.who > broadcast.who: udp 84

这就是说端口谁主机锕发送一个UDP数据报给端口谁主机广播,互联网广播地址。该数据包包含84字节的用户数据。

识别某些UDP服务(从源或目标端口号),并打印更高级别的协议信息。特别是,对NFS的域名服务请求(RFC-1034 / 1035)和Sun RPC调用(RFC-1050)。

UDP名称服务器请求

注意:以下描述假定您熟悉RFC-1035中描述的域服务协议。如果您不熟悉该协议,则以下描述似乎是用一种既不富音乐性又不迷人的奇怪外语编写的。

名称服务器请求的格式为

src > dst: id op? flags qtype qclass name (len)
h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)

主机h2opolo向helios上的域服务器询问与名称ucbvax.berkeley.edu相关的地址记录(qtype = A)。查询ID为“ 3 ”。“ + ”表示已设置递归期望标志。查询长度为37个字节,不包括UDP和IP协议标头。查询操作是正常的查询操作,因此省略了op字段。如果op还有其他内容,它将在' 3 '和' + ' 之间打印。类似地,qclass是普通的Cclass,C_IN,被省略。任何其他qclass会在' A ' 之后立即打印出来。

检查了一些异常,并可能导致在方括号中包含额外的字段:如果查询包含答案,权限记录或其他记录section,则ancount,nscount或arcount分别打印为' [na] ',' [nn] '或' [nau] ',其中n是适当的计数。如果设置了任何响应位(AA,RA或rcode),或者在字节2和3中设置了“必须为零”位,则将打印[[b2&3 = x] ”,其中x是十六进制值。标头字节二和三。

UDP名称服务器响应

名称服务器响应的格式为

src > dst: id op rcode flags a/n/au type class data (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)

在第一个示例中,helios使用3条应答记录,3条名称服务器记录和7条其他记录来响应来自h2opolo的查询ID 3 。第一个答案记录是类型A(地址),其数据是Internet地址128.32.137.3。响应的总大小为273个字节,不包括UDP和IP标头。省略了op(查询)和响应代码(NoError),以及A记录的类(C_IN)。

在第二示例中,太阳神响应查询2与不存在的结构域(的响应代码的NXDomain),没有回答,一个名称服务器和无规范记录。“ * ”表示已设置权威应答位。由于没有答案,因此不会打印任何类型,类别或数据。

可能出现的其他标志字符是' - '(可用递归,RA,未设置)和' |。'(已截断的消息TC)。如果“问题”部分不完全包含一个条目,则打印“ [nq] ”。

SMB / CIFS解码

tcpdump现在包括相当广泛的SMB / CIFS / NBT解码,用于UDP / 137,UDP / 138和TCP / 139上的数据。还完成了IPX和NetBEUI SMB数据的一些原始解码。

缺省情况下,会完成相当少的解码,而如果使用-v,则会完成更详细的解码。请注意,使用-v时,单个SMB数据包可能会占用一页或更多页,因此,如果您确实想要所有细节,请仅使用-v。

NFS请求和答复

Sun NFS(网络文件系统)的请求和答复显示为:

src.xid > dst.nfs: len op args
src.nfs > dst.xid: reply stat len op results
sushi.6709 > wrl.nfs: 112 readlink fh 21,24/10.73165
wrl.nfs > sushi.6709: reply ok 40 readlink "../var"
sushi.201b > wrl.nfs:
144 lookup fh 9,74/4096.6878 "xcolors"
wrl.nfs > sushi.201b:
reply ok 128 lookup fh 9,74/4134.3150

在第一行中,主机Sushi将ID为6709的事务发送到wrl(请注意,src主机后面的数字是事务id,而不是源端口)。该请求为112个字节,不包括UDP和IP标头。该操作是文件句柄(fh)21,24 / 10.73165上的readlink(读取符号链接)。如果幸运的话,在这种情况下,文件句柄可以解释为主要,次要设备编号对,然后是索引节点号和生成号。Wrl用链接的内容回复“ ok ”。

在第三行中,sushi要求wrl在目录文件9,74 / 4096.6878中查找名称“ xcolors ” 。请注意,打印的数据取决于操作类型。如果与NFS协议规范一起阅读,则该格式旨在进行自我解释。

如果给出了-v(详细)标志,则将打印其他信息。例如:

sushi.1372a > wrl.nfs:
148 read fh 21,11/12.195 8192 bytes @ 24576
wrl.nfs > sushi.1372a:
reply ok 1472 read REG 100664 ids 417/0 sz 29388

-v还显示IP头TTL,ID,length和fragmentation字段,在此示例中已将其省略。在第一行中,Sushi要求wrl从文件21,11 / 12.195读取8192字节,字节偏移量为24576。Wrl回复“ 确定 ”;第二行显示的数据包是回复的第一个片段,因此只有1472个字节长(其他字节将在后续片段中跟随,但是这些片段没有NFS甚至是UDP标头,因此可能无法打印,取决于使用的过滤器表达式)。因为-v给出标记时,将打印一些文件属性(除了文件数据外还返回):文件类型(常规文件为“ REG ”),文件模式(八进制),uid和gid,以及该文件的大小。如果多次给-v标志,则打印更多细节。

请注意,NFS请求非常大,除非增加snaplen,否则大部分细节都不会打印。尝试使用“ -s 192 ”观看NFS流量。

NFS答复数据包未明确标识RPC操作。相反,tcpdump会跟踪“最近”的请求,并使用事务ID将其与答复匹配。如果答复没有紧随相应的请求,则可能无法解析。

AFS请求和回复

Transarc AFS(Andrew文件系统)的请求和答复显示为:

src.sport > dst.dport: rx packet-type
src.sport > dst.dport: rx packet-type service call call-name args
src.sport > dst.dport: rx packet-type service reply call-name args
elvis.7001 > pike.afsfs:
rx data fs call rename old fid 536876964/1/1 ".newsrc.new"
new fid 536876964/1/1 ".newsrc"
pike.afsfs > elvis.7001: rx data fs reply rename

在第一行中,主机猫王将RX数据包发送给pike。这是发给fs(文件服务器)服务的RX数据包,是RPC调用的开始。RPC调用是重命名的,旧目录文件ID为536876964/1/1,旧文件名为'.newsrc.new',新目录文件ID为536876964/1/1,新文件名为'.newsrc'。主机派克通过对重命名调用的RPC响应进行响应(此操作成功,因为它是一个数据包,而不是中止包)。

通常,所有AFS RPC至少通过RPC调用名称进行解码。大多数AFS RPC至少解码了一些参数(对于一些有趣的定义,通常只有“有趣的”参数)。

该格式旨在进行自我描述,但是对于不熟悉AFS和RX运作方式的人来说,它可能无用。

如果两次给出-v(详细)标志,则会打印确认包和其他报头信息,例如RX呼叫ID,呼叫号,序列号,序列号和RX数据包标志。

如果两次给-v标志,则会打印其他信息,例如RX呼叫ID,序列号和RX数据包标志。MTU协商信息也会从RX ack数据包中打印出来。

如果给-v标志3次,则输出安全索引和服务ID。

为中止数据包打印错误代码,但Ubik信标数据包除外(因为中止数据包用于表示对Ubik协议的赞成票)。

请注意,AFS请求非常大,除非增加snaplen,否则不会输出许多参数。尝试使用“ -s 256 ”观看AFS流量。

AFS答复数据包未明确标识RPC操作。相反,tcpdump会跟踪“最近”的请求,并使用电话号码和服务ID将其与答复匹配。如果答复没有紧随相应的请求,则可能无法解析。

KIP AppleTalk (DDP in UDP)

封装在UDP数据报中的AppleTalk DDP数据包被解封装并作为DDP数据包转储(即,所有UDP头信息都被丢弃)。/etc/atalk.names文件用于将AppleTalk网络和节点号转换为名称。此文件中的行格式为

number    name
1.254     ether
16.1      icsd-net
1.254.110 ace

前两行给出了AppleTalk网络的名称。第三行给出了特定主机的名称,该主机的主机号与网络号的第三个八位字节不同,网络号必须具有两个八位字节,而主机号必须具有三个八位字节。数字和名称应由空格(空格或制表符)分隔。该/etc/atalk.names文件可能包含空行或注释行(开始用“ # ”)。

AppleTalk地址以以下形式打印:

net.host.port
144.1.209.2 > icsd-net.112.220
office.2 > icsd-net.112.220
jssmag.149.235 > icsd-net.2

如果/etc/atalk.names不存在或不包含某些AppleTalk主机/网络号的条目,则地址以数字形式打印。在第一个示例中,网络144.1节点209上的NBP(DDP端口2)正在发送到正在网络icsd节点112的端口220上侦听的内容。第二行是相同的,除了源节点的全名是已知的(“ office ”)。第三行是从网络jssmag节点149上的端口235发送以在icsd-net上广播NBP端口(请注意,广播地址(255)由没有主机号的网络名称指示-出于这个原因,最好在/etc/atalk.names中保持节点名称和网络名称不同)。

NBP(名称绑定协议)和ATP(AppleTalk事务协议)数据包的内容均经过解释。其他协议转储协议名称(如果没有为该协议注册任何名称,则为数字)和数据包大小。

NBP数据包的格式类似于以下示例:

icsd-net.112.220 > jssmag.2: nbp-lkup 190: "=:LaserWriter@*"
jssmag.209.2 > icsd-net.112.220: nbp-reply 190: "RM1140:LaserWriter@*" 250
techpit.2 > icsd-net.112.220: nbp-reply 190: "techpit:LaserWriter@*" 186

第一行是由网络icd主机112发送并在网络jssmag上广播的激光刻录机的名称查找请求。查找的nbp id为190。第二行显示来自主机jssmag.209的对该请求的答复(注意,它具有相同的id),表示它在端口250上注册了名为“ RM1140 ” 的Laserwriter资源。第三行是对同一请求的另一个答复,称主机techpit 在端口186上注册了laserwriter“ techpit ” 。

以下示例演示了ATP数据包格式:

jssmag.209.165 > helios.132: atp-req  122660xae030001
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  122660xae030001
jssmag.209.133 > helios.132: atp-req* 122670xae030002

Jssmag.209发起事务ID 12266与主机的Helios通过请求多达8个数据包(即'')。行尾的十六进制数字是请求中“ userdata”字段的值。Helios响应8 512字节数据包。事务ID后面的' : [digit]'给出了事务中的数据包序列号,parens中的数字是数据包中的数据量,不包括atp标头。数据包7上的“ * ” 表示EOM位置1。

然后jssmag.209请求重新发送数据包3和5。Helios重新发送它们,然后jssmag.209释放事务。最后,jssmag.209启动下一个请求。请求中的“ * ”表示未设置XO(“恰好一次”)。

IP碎片

分段的Internet数据报打印为:

(frag id:size@offset+)
(frag id:size@offset)

第一种形式表示有更多片段。第二个指示这是最后一个片段。

ID是片段ID。大小是不包括IP标头的片段大小(以字节为单位)。偏移量是此片段在原始数据报中的偏移量(以字节为单位)。

为每个片段输出片段信息。第一个片段包含更高级别的协议标头,并且在协议信息之后打印碎片信息。第一个之后的片段不包含更高级别的协议标头,并且在源地址和目标地址之后打印碎片信息。例如,这是通过CSNET连接从arizona.edu到lbl-rtsg.arpa的ftp的一部分,该连接似乎无法处理576字节数据报:

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

这里有两点需要注意:首先,第二行中的地址不包含端口号。因为TCP协议信息全部在第一个片段中,所以我们不知道在打印后面的片段时端口或序列号是什么。其次,当实际上有512个字节(第一个碎片中的308个字节和第二个碎片中的204个字节)时,第一行中的tcp序列信息被打印为好像有308个字节的用户数据。如果您在序列空间中寻找孔洞或试图将小包与小包进行匹配,这可能会让您感到愚蠢。

带有IP不分段标志的数据包带有尾随(DF)标记。

时间戳记

默认情况下,所有输出行前面都有一个timestamp。时间戳是当前时钟时间,格式为hh:mm:ss.frac,其准确性与内核的时钟相同。时间戳反映了内核第一次看到数据包的时间。从以太网接口从数据包中删除数据包到内核为“新数据包”中断提供服务之间的时间间隔,我们没有做任何尝试。

tcpdump [ -AbdDefhHIJKlLnNOpqRStuUvxX ] [ -B buffer_size ] [ -c count ] 
        [ -C file_size ] [ -G rotate_seconds ] [ -F file ] [ -i interface ] 
        [ -j tstamp_type ] [ -m module ] [ -M secret ] [ -r file ] 
        [ -s snaplen ] [ -T type ] [ -w file ] [ -W filecount ] 
        [ -E spi@ipaddr algo:secret,... ] [ -y datalinktype ] 
        [ -z postrotate-command ] [ -Z user ] [ expression ]

Options

-A Print each packet (minus its link-level header) in ASCII. Handy for capturing web pages.
-b Print the AS number in BGP packets in ASDOT notation rather than ASPLAIN notation.
-B buffer_size Set the operating system capture buffer size to buffer_size, in units of KiB (1024 bytes).
-c count Exit after receiving count packets.
-C file_size Before writing a raw packet to a savefile, check whether the file is currently larger than file_size and, if so, close the current savefile and open a new one. Savefiles after the first savefile have the name specified with the -w flag, with a number after it, starting at 1 and continuing upward. The units of file_size are millions of bytes (1,000,000 bytes, not 1,048,576 bytes).
-d Dump the compiled packet-matching code in a human readable form to standard output and stop.
-dd Dump packet-matching code as a C program fragment.
-ddd Dump packet-matching code as decimal numbers (preceded with a count).
-D Print the list of the network interfaces available on the system and on which tcpdump can capture packets. For each network interface, a number and an interface name, possibly followed by a text description of the interface, is printed. The interface name or the number can be supplied to the -i flag to specify an interface on which to capture.

This option can be useful on systems that don't have a command to list them (e.g., Windows systems, or UNIX systems lacking ifconfig -a); the number can be useful on Windows 2000 and later systems, where the interface name is a somewhat complex string.

The -D flag will not be supported if tcpdump was built with an older version of libpcap that lacks the pcap_findalldevs() function.
-e Print the link-level header on each dump line.
-E Use spi@ipaddr algo:secret for decrypting IPsec ESP packets that are addressed to addr and contain Security Parameter Index value spi. This combination may be repeated with comma or newline separation.

Note that setting the secret for IPv4 ESP packets is supported at this time.

Algorithms may be des-cbc3des-cbcblowfish-cbcrc3-cbccast128-cbc, or none. The default is des-cbc. The ability to decrypt packets is only present if tcpdump was compiled with cryptography enabled.

secret is the ASCII text for ESP secret key. If preceded by 0x, then a hex value will be read.

The option assumes RFC 2406 ESP, not RFC 1827 ESP. The option is only for debugging purposes, and the use of this option with a true 'secret' key is discouraged. By presenting IPsec secret key onto command line you make it visible to others, via ps(1) and other occasions.

In addition to the above syntax, the syntax file name may be used to have tcpdump use the data in the file. The file is opened upon receiving the first ESP packet, so any special permissions that tcpdump may have been given should already have been given up.
-f Print 'foreign' IPv4 addresses numerically rather than symbolically (this option is intended to get around a problem with Sun's NIS server — usually it hangs forever translating non-local Internet numbers).

The test for 'foreign' IPv4 addresses is done using the IPv4 address and netmask of the interface on which capturing is being done. If that address or netmask are not available, either because the interface on which capture is being done has no address or netmask or because the capture is being done on the Linux "any" interface, which can capture on more than one interface, this option will not work correctly.
-F file Use file as input for the filter expression. An additional expression given on the command line is ignored.
-G rotate_seconds If specified, rotates the dump file specified with the -w option every rotate_seconds seconds. Savefiles have the name specified by -w which should include a time format as defined by strftime. If no time format is specified, each new file will overwrite the previous.

If used in conjunction with the -C option, file names take the form of 'file'.
-h Print the tcpdump and libpcap version strings, print a usage message, and exit.
-H Attempt to detect 802.11s draft mesh headers.
-i interface Listen on interface. If unspecified, tcpdump searches the system interface list for the lowest numbered, configured up interface (excluding loopback). Ties are broken by choosing the earliest match.

On Linux systems with version 2.2 or later kernels, an interface argument of "any" can be used to capture packets from all interfaces. Note that captures on the "any" device will not be done in promiscuous mode. If the -D flag is supported, an interface number as printed by that flag can be used as the interface argument.
-I Put the interface in "monitor mode"; this is supported only on IEEE 802.11 Wi-Fi interfaces, and supported only on some operating systems.

Note that in monitor mode the adapter might disassociate from the network with which it's associated, so that you will not be able to use any wireless networks with that adapter. This could prevent accessing files on a network server, or resolving hostnames or network addresses, if you are capturing in monitor mode and are not connected to another network with another adapter.

This flag will affect the output of the -L flag. If -I isn't specified, only those link-layer types available when not in monitor mode will be shown; if -I is specified, only those link-layer types available when in monitor mode will be shown.
-j tstamp_type Set the timestamp type for the capture to tstamp_type. The names to use for the timestamp types are given in pcap-tstamp-type(7); not all the types listed there will necessarily be valid for any given interface.
-J List the supported timestamp types for the interface and exit. If the timestamp type cannot be set for the interface, no timestamp types are listed.
-K List the supported timestamp types for the interface and exit. If the timestamp type cannot be set for the interface, no timestamp types are listed.
-l Make stdout line buffered. Useful if you want to see the data while capturing it. For example,

tcpdump -l | tee dat
or

tcpdump -l > dat & tail -f dat
Note that on Windows,"line buffered" means "unbuffered", so that WinDump will write each character individually if -l is specified.

-U is similar to -l in its behavior, but it will cause output to be "packet-buffered", so that the output is written to stdout at the end of each packet rather than at the end of each line; this is buffered on all platforms, including Windows.
-L List the known data link types for the interface, in the specified mode, and exit. The list of known data link types may be dependent on the specified mode; for example, on some platforms, a Wi-Fi interface might support one set of data link types when not in monitor mode (for example, it might support only fake Ethernet headers, or might support 802.11 headers but not support 802.11 headers with radio information) and another set of data link types when in monitor mode (for example, it might support 802.11 headers, or 802.11 headers with radio information, only in monitor mode).
-m module Load SMI MIB module definitions from file module. This option can be used several times to load several MIB modules into tcpdump.
-M secret Use secret as a shared secret for validating the digests found in TCP segments with the TCP-MD5 option (RFC 2385), if present.
-n Don't convert addresses (i.e., host addresses, port numbers, etc.) to names.
-N Don't print domain name qualification of hostnames. E.g., if you give this flag then tcpdump will print "nic" instead of "nic.ddn.mil".
-O Do not run the packet-matching code optimizer. This option is useful only if you suspect a bug in the optimizer.
-p Don't put the interface into promiscuous mode. Note that the interface might be in promiscuous mode for some other reason; hence, '-p' cannot be used as an abbreviation for 'ether host {local-hw-addr} or ether broadcast.'
-q Quick/quiet output. Print less protocol information so output lines are shorter.
-R Assume ESP/AH packets to be based on old specification (RFC1825 to RFC1829). If specified, tcpdump will not print replay prevention field. Since there is no protocol version field in ESP/AH specification, tcpdump cannot deduce the version of ESP/AH protocol.
-r file Read packets from file (which was created with the -w option). Standard input is used if file is "-".
-S Print absolute, rather than relative, TCP sequence numbers.
-s snaplen Snarf snaplen bytes of data from each packet rather than the default of 65535 bytes. Packets truncated because of a limited snapshot are indicated in the output with "[|proto]", where proto is the name of the protocol level at which the truncation has occurred. Note that taking larger snapshots both increases the amount of time it takes to process packets and, effectively, decreases the amount of packet buffering. This may cause packets to be lost. You should limit snaplen to the smallest number that will capture the protocol information that interests you. Setting snaplen to 0 sets it to the default of 65535, for backward compatibility with recent older versions of tcpdump.
-T type Force packets selected by "expression" to be interpreted the specified type. Currently known types are aodv (Ad-hoc On-demand Distance Vector protocol), cnfp (Cisco NetFlow protocol), rpc (Remote Procedure Call), rtp (Real-Time Applications protocol), rtcp (Real-Time Applications control protocol), snmp (Simple Network Management Protocol), tftp (Trivial File Transfer Protocol), vat (Visual Audio Tool), and wb (distributed White Board).
-t Don't print a timestamp on each dump line.
-tt Do print an unformatted timestamp on each dump line.
-ttt Print a delta (micro-second resolution) between current and previous line on each dump line.
-tttt Print a timestamp in default format proceeded by date on each dump line.
-ttttt Print a delta (micro-second resolution) between current and first line on each dump line.
-u Print undecoded NFS handles.
-U If the -w option is not specified, make the printed packet output "packet-buffered"; i.e., as the description of the contents of each packet is printed, it will be written to the standard output, rather than, when not writing to a terminal, being written only when the output buffer fills.

If the -w option is specified, make the saved raw packet output "packet-buffered"; i.e., as each packet is saved, it will be written to the output file, rather than being written only when the output buffer fills. The -U flag will not be supported if tcpdump was built with an older version of libpcap that lacks the pcap_dump_flush() function.
-v When parsing and printing, produce (slightly more) verbose output. For example, the time to live, identification, total length and options in an IP packet are printed. Also, enables additional packet integrity checks such as verifying the IP and ICMP header checksum.

When writing to a file with the -w option, report, every 10 seconds, the number of packets captured.
-vv Even more verbose output. For example, additional fields are printed from NFS reply packets, and SMB packets are fully decoded.
-vvv Even more verbose output. For example, telnet SB ... SE options are printed in full. With -X Telnet options are printed in hex as well.
-w Write the raw packets to file rather than parsing and printing them out. They can later be printed with the -r option. Standard output is used if file is "-".

This output will be buffered if written to a file or pipe, so a program reading from the file or pipe may not see packets for an arbitrary amount of time after they are received. Use the -U flag to cause packets to be written as soon as they are received.

See pcap-savefile(5) for a description of the file format.
-W Used in conjunction with the -C option, this limits the number of files created to the specified number, and begin overwriting files from the beginning, thus creating a 'rotating' buffer. Also, it will name the files with enough leading 0s to support the maximum number of files, allowing them to sort correctly.

Used in conjunction with the -G option, this will limit the number of rotated dump files that get created, exiting with status 0 when reaching the limit. If used with -C as well, the behavior will result in cyclical files per timeslice.
-x When parsing and printing, in addition to printing the headers of each packet, print the data of each packet (minus its link level header) in hex. The smaller of the entire packet or snaplen bytes will be printed. Note that this is the entire link-layer packet, so for link layers that pad (e.g., Ethernet), the padding bytes will also be printed when the higher layer packet is shorter than the required padding.
-xx When parsing and printing, in addition to printing the headers of each packet, print the data of each packet, including its link level header, in hex.
-X When parsing and printing, in addition to printing the headers of each packet, print the data of each packet (minus its link level header) in hex and ASCII. This option is very handy for analysing new protocols.
-XX When parsing and printing, in addition to printing the headers of each packet, print the data of each packet, including its link level header, in hex and ASCII.
-y datalinktype Set the data link type to use while capturing packets to datalinktype.
-z postrotate-command Used in conjunction with the -C or -G options, this will make tcpdump run " command file " where file is the savefile being closed after each rotation. For example, specifying -z gzip or -z bzip2 will compress each savefile using gzip or bzip2.

Note that tcpdump will run the command in parallel to the capture, using the lowest priority so that this doesn't disturb the capture process.

And in case you would like to use a command that itself takes flags or different arguments, you can always write a shell script that take the savefile name as the only argument, make the flags & arguments arrangements and execute the command that you want.
-Z user If tcpdump is running as root, after opening the capture device or input savefile, but before opening any savefiles for output, change the user ID to user and the group ID to the primary group of user.

This behavior can also be enabled by default at compile time.
expression Selects which packets will be dumped. If no expression is given, all packets on the net will be dumped. Otherwise, only packets for which expression is 'true' will be dumped.

For the expression syntax, see pcap-filter(7).

Expression arguments can be passed to tcpdump as either a single argument or as multiple arguments, whichever is more convenient. Generally, if the expression contains Shell metacharacters, it is easier to pass it as a single, quoted argument. Multiple arguments are concatenated with spaces before being parsed.

Output format

The output of tcpdump is protocol-dependent. The following gives a brief description and examples of most of the formats.

Link Level Headers

If the '-e' option is given, the link level header is printed out. On Ethernets, the source and destination addresses, protocol, and packet length are printed.

On FDDI networks, the '-e' option causes tcpdump to print the 'frame control' field, the source and destination addresses, and the packet length. (The 'frame control' field governs the interpretation of the rest of the packet. Normal packets (such as those containing IP datagrams) are 'async' packets, with a priority value between 0 and 7; for example, 'async4'. Such packets are assumed to contain an 802.2 Logical Link Control (LLC) packet; the LLC header is printed if it is not an ISO datagram or a so-called SNAP packet.

On Token Ring networks, the '-e' option causes tcpdump to print the 'access control' and 'frame control' fields, the source and destination addresses, and the packet length. As on FDDI networks, packets are assumed to contain an LLC packet. Regardless of whether the '-e' option is specified or not, the source routing information is printed for source-routed packets.

On 802.11 networks, the '-e' option causes tcpdump to print the 'frame control' fields, all of the addresses in the 802.11 header, and the packet length. As on FDDI networks, packets are assumed to contain an LLC packet.

Note: The following description assumes familiarity with the SLIP compression algorithm described in RFC-1144.

On SLIP links, a direction indicator ("I" for inbound, "O" for outbound), packet type, and compression information are printed out. The packet type is printed first. The three types are iputcp, and ctcp. No further link information is printed for IP packets. For TCP packets, the connection identifier is printed following the type. If the packet is compressed, its encoded header is printed out. The special cases are printed out as *S+n and *SA+n, where n is the amount by which the sequence number (or sequence number and ack) has changed. If it is not a special case, zero or more changes are printed. A change is indicated by U (urgent pointer), W (window), A (ack), S (sequence number), and I (packet ID), followed by a delta (+n or -n), or a new value (=n). Finally, the amount of data in the packet and compressed header length are printed.

For example, the following line shows an outbound compressed TCP packet, with an implicit connection identifier; the ack has changed by 6, the sequence number by 49, and the packet ID by 6; there are 3 bytes of data and 6 bytes of compressed header:

O ctcp * A+6 S+49 I+6 3 (6)

ARP/RARP packets

Arp/Rarp output shows the type of request and its arguments. The format is intended to be self explanatory. Here is a short sample taken from the start of an 'rlogin' from host rtsg to host csam:

arp who-has csam tell rtsg arp reply csam is-at CSAM

The first line says that rtsg sent an arp packet asking for the Ethernet address of Internet host csamCsam replies with its Ethernet address (in this example, Ethernet addresses are in caps and Internet addresses in lower case).

This would look less redundant if we had done tcpdump -n:

arp who-has 128.3.254.6 tell 128.3.254.68 
arp reply 128.3.254.6 is-at 02:07:01:00:01:c4

If we had done tcpdump -e, the fact that the first packet is broadcast and the second is point-to-point would be visible:

RTSG Broadcast 0806 64: arp who-has csam tell rtsg 
CSAM RTSG 0806 64: arp reply csam is-at CSAM

For the first packet this says the Ethernet source address is RTSG, the destination is the Ethernet broadcast address, the type field contained hex 0806 (type ETHER_ARP) and the total length was 64 bytes.

TCP packets

Note: The following description assumes familiarity with the TCP protocol described in RFC-793. If you are not familiar with the protocol, neither this description nor tcpdump will be of much use to you.

The general format of a tcp protocol line is:

src > dst: flags data-seqno ack window urgent options

Src and dst are the source and destination IP addresses and ports. Flags are some combination of S (SYN), F (FIN), P (PUSH), R (RST), U (URG), W (ECN CWR), E (ECN-Echo) or '.' (ACK), or 'none' if no flags are set. data-seqno describes the portion of sequence space covered by the data in this packet (see example below). ack is sequence number of the next data expected the other direction on this connection. window is the number of bytes of receive buffer space available the other direction on this connection. urg indicates there is 'urgent' data in the packet. Options are tcp options enclosed in angle brackets (e.g., ).

Srcdst and flags are always present. The other fields depend on the contents of the packet's tcp protocol header and are output only if appropriate.

Here is the opening portion of an rlogin from host rtsg to host csam.

rtsg.1023 > csam.login: S 768512:768512(0) win 4096csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096rtsg.1023 > csam.login: . ack 1 win 4096
rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096
csam.login > rtsg.1023: . ack 2 win 4096
rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096
csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077
csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1
csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1

The first line says that tcp port 1023 on rtsg sent a packet to port login on csam. The S indicates that the SYN flag was set. The packet sequence number was 768512 and it contained no data. The notation is 'first:last(nbytes)' which means 'sequence numbers first up to but not including last that is nbytes bytes of user data'. There was no piggy-backed ack, the available receive window was 4096 bytes and there was a max-segment-size option requesting an mss of 1024 bytes.

Csam replies with a similar packet except it includes a piggy-backed ack for rtsg's SYN. Rtsg then acks csam's SYN. The '.' means the ACK flag was set. The packet contained no data so there is no data sequence number. Note that the ack sequence number is a small integer. The first time tcpdump sees a tcp 'conversation', it prints the sequence number from the packet. On subsequent packets of the conversation, the difference between the current packet's sequence number and this initial sequence number is printed. This means that sequence numbers after the first can be interpreted as relative byte positions in the conversation's data stream (with the first data byte each direction being '1'). The '-S' will override this feature, causing the original sequence numbers to be output.

On the 6th line, rtsg sends csam 19 bytes of data (bytes 2 through 20 in the rtsg → csam side of the conversation). The PUSH flag is set in the packet. On the 7th line, csam says it's received data sent by rtsg up to but not including byte 21. Most of this data is apparently sitting in the socket buffer since csam's receive window has gotten 19 bytes smaller. Csam also sends one byte of data to rtsg in this packet. On the 8th and 9th lines, csam sends two bytes of urgent, pushed data to rtsg.

If the snapshot was small enough that tcpdump didn't capture the full TCP header, it interprets as much of the header as it can and then reports "[|tcp]" to indicate the remainder could not be interpreted. If the header contains a bogus option (one with a length that's either too small or beyond the end of the header), tcpdump reports it as "[bad opt]" and does not interpret any further options (since it's impossible to tell where they start). If the header length indicates options are present but the IP datagram length is not long enough for the options to actually be there, tcpdump reports it as "[bad hdr length]".

Capturing TCP packets with particular flag combinations (SYN-ACKURG-ACK, etc.)

There are 8 bits in the control bits section of the TCP header:

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

Let's assume that we want to watch packets used in establishing a TCP connection. Recall that TCP uses a 3-way handshake protocol when it initializes a new connection; the connection sequence with regard to the TCP control bits is

  1. Caller sends SYN
  2. Recipient responds with SYN, ACK
  3. Caller sends ACK

Now we're interested in capturing packets that have only the SYN bit set (Step 1). Note that we don't want packets from step 2 (SYN-ACK), a plain initial SYN. What we need is a correct filter expression for tcpdump.

Recall the structure of a TCP header without options:

       0                              15                              31
       -----------------------------------------------------------------
       |          source port          |       destination port        |
       -----------------------------------------------------------------
       |                        sequence number                        |
       -----------------------------------------------------------------
       |                     acknowledgment number                     |
       -----------------------------------------------------------------
       |  HL   | rsvd  |C|E|U|A|P|R|S|F|        window size            |
       -----------------------------------------------------------------
       |         TCP checksum          |       urgent pointer          |
       -----------------------------------------------------------------

A TCP header usually holds 20 octets of data, unless options are present. The first line of the graph contains octets 0 - 3, the second line shows octets 4 - 7 etc.

Starting to count with 0, the relevant TCP control bits are contained in octet 13:

        0             7|             15|             23|             31
       ----------------|---------------|---------------|----------------
       |  HL   | rsvd  |C|E|U|A|P|R|S|F|        window size            |
       ----------------|---------------|---------------|----------------
       |               |  13th octet   |               |               |

Let's have a closer look at octet no. 13:

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

These are the TCP control bits that are of interest. We have numbered the bits in this octet from 0 to 7, right to left, so the PSH bit is bit number 3, while the URG bit is number 5.

Recall that we want to capture packets with only SYN set. Let's see what happens to octet 13 if a TCP datagram arrives with the SYN bit set in its header:

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

Looking at the control bits section we see that only bit number 1 (SYN) is set.

Assuming that octet number 13 is an 8-bit unsigned integer in network byte order, the binary value of this octet is

00000010

and its decimal representation is

         ^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

We're almost done, because now we know that if only SYN is set, the value of the 13th octet in the TCP header, when interpreted as a 8-bit unsigned integer in network byte order, must be exactly 2.

This relationship can be expressed as:

tcp[13] == 2

We can use this expression as the filter for tcpdump to watch packets which have only SYN set:

tcpdump -i xl0 tcp[13] == 2

The expression says "let the 13th octet of a TCP datagram have the decimal value 2", which is exactly what we want.

Now, let's assume that we need to capture SYN packets, but we don't care if ACK or any other TCP control bit is set at the same time. Let's see what happens to octet 13 when a TCP datagram with SYN-ACK set arrives:

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

Now bits 1 and 4 are set in the 13th octet. The binary value of octet 13 is

00010010

which translates to decimal 18:

         ^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

Now we can't use 'tcp[13] == 18' in the tcpdump filter expression, because that would select only those packets that have SYN-ACK set, but not those with only SYN set. Remember that we don't care if ACK or any other control bit is set as long as SYN is set.

To achieve our goal, we need to logically AND the binary value of octet 13 with some other value to preserve the SYN bit. We know that we want SYN to be set in any case, so we'll logically AND the value in the 13th octet with the binary value of a SYN:

                 00010010 SYN-ACK              00000010 SYN
            AND  00000010 (we want SYN)   AND  00000010 (we want SYN)
                 --------                      --------
            =    00000010                 =    00000010

We see that this AND operation delivers the same result regardless whether ACK or another TCP control bit is set. The decimal representation of the AND value as well as the result of this operation is 2 (binary 00000010), so we know that for packets with SYN set the following relation must hold true:

( ( value of octet 13 ) AND ( 2 ) ) == ( 2 )

This points us to the tcpdump filter expression

tcpdump -i xl0 'tcp & 2 == 2'

Some offsets and field values may be expressed as names rather than as numeric values. For example, tcp] may be replaced with tcp[tcpflags]. The following TCP flag field values are also available: tcp-fintcp-syntcp-rsttcp-pushtcp-acttcp-urg.

This can be demonstrated as:

tcpdump -i xl0 'tcp[tcpflags] & tcp-push != 0'

Note that you should use single quotes or a backslash in the expression to protect the AND ('&') special character from the shell.

UDP packets

UDP format is illustrated by this rwho packet:

actinide.who > broadcast.who: udp 84

This says that port who on host actinide sent a udp datagram to port who on host broadcast, the Internet broadcast address. The packet contained 84 bytes of user data.

Some UDP services are recognized (from the source or destination port number) and the higher level protocol information printed. In particular, Domain Name service requests (RFC-1034/1035) and Sun RPC calls (RFC-1050) to NFS.

UDP name server requests

Note: The following description assumes familiarity with the Domain Service protocol described in RFC-1035. If you are not familiar with the protocol, the following description will appear to be written in a strange foreign language that is neither musical nor charming.

Name server requests are formatted as

src > dst: id op? flags qtype qclass name (len)
h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)

Host h2opolo asked the domain server on helios for an address record (qtype=A) associated with the name ucbvax.berkeley.edu. The query id was '3'. The '+' indicates the recursion desired flag was set. The query length was 37 bytes, not including the UDP and IP protocol headers. The query operation was the normal one, Query, so the op field was omitted. If the op had been anything else, it would have been printed between the '3' and the '+'. Similarly, the qclass was the normal one, C_IN, and omitted. Any other qclass would have been printed immediately after the 'A'.

A few anomalies are checked and may result in extra fields enclosed in square brackets: If a query contains an answer, authority records or additional records sectionancountnscount, or arcount are printed as '[na]', '[nn]' or '[nau]' where n is the appropriate count. If any of the response bits are set (AARA or rcode) or any of the 'must be zero' bits are set in bytes two and three, '[b2&3=x]' is printed, where x is the hex value of header bytes two and three.

UDP name server responses

Name server responses are formatted as

src > dst: id op rcode flags a/n/au type class data (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)

In the first example, helios responds to query id 3 from h2opolo with 3 answer records, 3 name server records and 7 additional records. The first answer record is type A (address) and its data is Internet address 128.32.137.3. The total size of the response was 273 bytes, excluding UDP and IP headers. The op (Query) and response code (NoError) were omitted, as was the class (C_IN) of the A record.

In the second example, helios responds to query 2 with a response code of non-existent domain (NXDomain) with no answers, one name server and no authority records. The '*' indicates that the authoritative answer bit was set. Since there were no answers, no type, class or data were printed.

Other flag characters that might appear are '-' (recursion available, RA, not set) and '|' (truncated message, TC, set). If the 'question' section doesn't contain exactly one entry, '[nq]' is printed.

SMB/CIFS decoding

tcpdump now includes fairly extensive SMB/CIFS/NBT decoding for data on UDP/137, UDP/138 and TCP/139. Some primitive decoding of IPX and NetBEUI SMB data is also done.

By default, a fairly minimal decode is done, with a much more detailed decode done if -v is used. Be warned that with -v a single SMB packet may take up a page or more, so only use -v if you really want all the gory details.

NFS requests and replies

Sun NFS (Network File System) requests and replies are printed as:

src.xid > dst.nfs: len op args
src.nfs > dst.xid: reply stat len op results
sushi.6709 > wrl.nfs: 112 readlink fh 21,24/10.73165
wrl.nfs > sushi.6709: reply ok 40 readlink "../var"
sushi.201b > wrl.nfs:
144 lookup fh 9,74/4096.6878 "xcolors"
wrl.nfs > sushi.201b:
reply ok 128 lookup fh 9,74/4134.3150

In the first line, host sushi sends a transaction with id 6709 to wrl (note that the number following the src host is a transaction id, not the source port). The request was 112 bytes, excluding the UDP and IP headers. The operation was a readlink (read symbolic link) on file handle (fh21,24/10.73165. If one is lucky, as in this case, the file handle can be interpreted as a major,minor device number pair, followed by the inode number and generation number. Wrl replies 'ok' with the contents of the link.

In the third line, sushi asks wrl to lookup the name 'xcolors' in the directory file 9,74/4096.6878. Note that the data printed depends on the operation type. The format is intended to be self explanatory if read in conjunction with an NFS protocol spec.

If the -v (verbose) flag is given, additional information is printed. For example:

sushi.1372a > wrl.nfs:
148 read fh 21,11/12.195 8192 bytes @ 24576
wrl.nfs > sushi.1372a:
reply ok 1472 read REG 100664 ids 417/0 sz 29388

-v also prints the IP header TTLIDlength, and fragmentation fields, which have been omitted from this example. In the first line, sushi asks wrl to read 8192 bytes from file 21,11/12.195, at byte offset 24576Wrl replies 'ok'; the packet shown on the second line is the first fragment of the reply, and hence is only 1472 bytes long (the other bytes will follow in subsequent fragments, but these fragments do not have NFS or even UDP headers and so might not be printed, depending on the filter expression used). Because the -v flag is given, some of the file attributes (which are returned in addition to the file data) are printed: the file type ("REG", for regular file), the file mode (in octal), the uid and gid, and the file size. If the -v flag is given more than once, even more details are printed.

Note that NFS requests are very large and much of the detail won't be printed unless snaplen is increased. Try using '-s 192' to watch NFS traffic.

NFS reply packets do not explicitly identify the RPC operation. Instead, tcpdump keeps track of "recent" requests, and matches them to the replies using the transaction ID. If a reply does not closely follow the corresponding request, it might not be parsable.

AFS requests and replies

Transarc AFS (Andrew File System) requests and replies are printed as:

src.sport > dst.dport: rx packet-type
src.sport > dst.dport: rx packet-type service call call-name args
src.sport > dst.dport: rx packet-type service reply call-name args
elvis.7001 > pike.afsfs:
rx data fs call rename old fid 536876964/1/1 ".newsrc.new"
new fid 536876964/1/1 ".newsrc"
pike.afsfs > elvis.7001: rx data fs reply rename

In the first line, host elvis sends a RX packet to pike. This was a RX data packet to the fs (fileserver) service, and is the start of an RPC call. The RPC call was a rename, with the old directory file id of 536876964/1/1 and an old file name of '.newsrc.new', and a new directory file id of 536876964/1/1 and a new file name of '.newsrc'. The host pike responds with a RPC reply to the rename call (which was successful, because it was a data packet and not an abort packet).

In general, all AFS RPCs are decoded at least by RPC call name. Most AFS RPCs have at least some of the arguments decoded (generally only the 'interesting' arguments, for some definition of interesting).

The format is intended to be self-describing, but it will probably not be useful to people who are not familiar with the workings of AFS and RX.

If the -v (verbose) flag is given twice, acknowledgement packets and additional header information is printed, such as the RX call ID, call number, sequence number, serial number, and the RX packet flags.

If the -v flag is given twice, additional information is printed, such as the RX call ID, serial number, and the RX packet flags. The MTU negotiation information is also printed from RX ack packets.

If the -v flag is given three times, the security index and service id are printed.

Error codes are printed for abort packets, with the exception of Ubik beacon packets (because abort packets are used to signify a yes vote for the Ubik protocol).

Note that AFS requests are very large and many of the arguments won't be printed unless snaplen is increased. Try using '-s 256' to watch AFS traffic.

AFS reply packets do not explicitly identify the RPC operation. Instead, tcpdump keeps track of "recent" requests, and matches them to the replies using the call number and service ID. If a reply does not closely follow the corresponding request, it might not be parsable.

KIP AppleTalk (DDP in UDP)

AppleTalk DDP packets encapsulated in UDP datagrams are de-encapsulated and dumped as DDP packets (i.e., all the UDP header information is discarded). The file /etc/atalk.names is used to translate AppleTalk net and node numbers to names. Lines in this file have the form

number    name
1.254     ether
16.1      icsd-net
1.254.110 ace

The first two lines give the names of AppleTalk networks. The third line gives the name of a particular host a host is distinguished from a net by the 3rd octet in the number, a net number must have two octets and a host number must have three octets. The number and name should be separated by whitespace (blanks or tabs). The /etc/atalk.names file may contain blank lines or comment lines (lines starting with a '#').

AppleTalk addresses are printed in the form:

net.host.port
144.1.209.2 > icsd-net.112.220
office.2 > icsd-net.112.220
jssmag.149.235 > icsd-net.2

If the /etc/atalk.names doesn't exist or doesn't contain an entry for some AppleTalk host/net number, addresses are printed in numeric form. In the first example, NBP (DDP port 2) on net 144.1 node 209 is sending to whatever is listening on port 220 of net icsd node 112. The second line is the same except the full name of the source node is known ('office'). The third line is a send from port 235 on net jssmag node 149 to broadcast on the icsd-net NBP port (note that the broadcast address (255) is indicated by a net name with no host number - for this reason it's a good idea to keep node names and net names distinct in /etc/atalk.names).

NBP (name binding protocol) and ATP (AppleTalk transaction protocol) packets have their contents interpreted. Other protocols dump the protocol name (or number if no name is registered for the protocol) and packet size.

NBP packets are formatted like the following examples:

icsd-net.112.220 > jssmag.2: nbp-lkup 190: "=:LaserWriter@*"
jssmag.209.2 > icsd-net.112.220: nbp-reply 190: "RM1140:LaserWriter@*" 250
techpit.2 > icsd-net.112.220: nbp-reply 190: "techpit:LaserWriter@*" 186

The first line is a name lookup request for laserwriters sent by net icsd host 112 and broadcast on net jssmag. The nbp id for the lookup is 190. The second line shows a reply for this request (note that it has the same id) from host jssmag.209 saying that it has a laserwriter resource named "RM1140" registered on port 250. The third line is another reply to the same request saying host techpit has laserwriter "techpit" registered on port 186.

ATP packet formatting is demonstrated by the following example:

jssmag.209.165 > helios.132: atp-req  122660xae030001
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  122660xae030001
jssmag.209.133 > helios.132: atp-req* 122670xae030002

Jssmag.209 initiates transaction id 12266 with host helios by requesting up to 8 packets (the ''). The hex number at the end of the line is the value of the 'userdata' field in the request. Helios responds with 8 512-byte packets. The ':[digit]' following the transaction id gives the packet sequence number in the transaction and the number in parens is the amount of data in the packet, excluding the atp header. The '*' on packet 7 indicates that the EOM bit was set.

jssmag.209 then requests that packets 3 & 5 be retransmitted. Helios resends them then jssmag.209 releases the transaction. Finally, jssmag.209 initiates the next request. The '*' on the request indicates that XO ('exactly once') was not set.

IP fragmentation

Fragmented Internet datagrams are printed as:

(frag id:size@offset+)
(frag id:size@offset)

The first form indicates there are more fragments. The second indicates this is the last fragment.

Id is the fragment id. Size is the fragment size (in bytes) excluding the IP header. Offset is this fragment's offset (in bytes) in the original datagram.

The fragment information is output for each fragment. The first fragment contains the higher level protocol header and the frag info is printed after the protocol info. Fragments after the first contain no higher level protocol header and the frag info is printed after the source and destination addresses. For example, here is part of an ftp from arizona.edu to lbl-rtsg.arpa over a CSNET connection that doesn't appear to handle 576 byte datagrams:

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

There are a couple of things to note here: First, addresses in the 2nd line don't include port numbers. Because the TCP protocol information is all in the first fragment and we have no idea what the port or sequence numbers are when we print the later fragments. Second, the tcp sequence information in the first line is printed as if there were 308 bytes of user data when, in fact, there are 512 bytes (308 in the first frag and 204 in the second). If you are looking for holes in the sequence space or trying to match up acks with packets, this can fool you.

A packet with the IP don't fragment flag is marked with a trailing (DF).

Timestamps

By default, all output lines are preceded by a timestamp. The timestamp is the current clock time in the form hh:mm:ss.frac and is as accurate as the kernel's clock. The timestamp reflects the time the kernel first saw the packet. No attempt is made to account for the time lag between when the Ethernet interface removed the packet from the wire and when the kernel serviced the 'new packet' interrupt.

查看英文版

查看中文版

tcpdump 例子

tcpdump host sundown

打印到达或离开主机日落的所有数据包。

tcpdump host helios and \( hot or ace \)

打印主机Helios与hot或ace之间的流量。

tcpdump ip host ace and not helios

打印ace和除helios外的任何主机之间的所有IP数据包。


tcpdump 'gateway snup and (port ftp or ftp-data)'

通过Internet 网关snup打印所有ftp通信。注意,用引号引起来是为了防止外壳解释括号。

tcpdump ip and not net localnet

打印既不是源于主机也不是本地主机的流量。如果您网关到另一个网络,则这些东西绝对不能进入您的本地网络。

tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net localnet'

打印每个涉及非本地主机的TCP对话的开始和结束数据包(SYN和FIN数据包)。

tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'

打印所有与端口80之间的IPv4 HTTP数据包。tcpdump将仅打印包含数据的数据包。不,例如,SYN和FIN数据包以及仅ACK数据包。

tcpdump 'gateway snup and ip[2:2] > 576'

打印通过网关snup发送的超过576字节的IP数据包。

tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'

打印未通过以太网广播或多播发送的IP广播或多播数据包。

tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'

打印不是回显请求/答复的所有ICMP数据包(即,不ping数据包)。

tcpdump host sundown

Prints all packets arriving at or departing from host sundown.

tcpdump host helios and \( hot or ace \)

Prints traffic between host helios and either hot or ace.

tcpdump ip host ace and not helios

Prints all IP packets between ace and any host except helios.

tcpdump 'gateway snup and (port ftp or ftp-data)'

Prints all ftp traffic through Internet gateway snup. Note that the expression is quoted to prevent the shell from interpreting the parentheses.

tcpdump ip and not net localnet

Prints traffic neither sourced from nor destined for local hosts. If you gateway to another network, this stuff should never make it onto your local network.

tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net localnet'

Prints the start and end packets (the SYN and FIN packets) of each TCP conversation that involves a non-local host.

tcpdump 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'

Prints all IPv4 HTTP packets to and from port 80. tcpdump will print only packets that contain data; not, for example, SYN and FIN packets and ACK-only packets.

tcpdump 'gateway snup and ip[2:2] > 576'

Prints IP packets longer than 576 bytes sent through gateway snup.

tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'

Prints IP broadcast or multicast packets that were not sent via Ethernet broadcast or multicast.

tcpdump 'icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply'

Prints all ICMP packets that are not echo requests/replies (i.e., not ping packets).

查看英文版

查看中文版