Linux tcpdump命令详解

转自：http://blog.csdn.net/gkingzheng/article/details/8892108

简介

用简单的话来定义tcpdump，就是：dump the traffic on a network，根据使用者的定义对网络上的数据包进行截获的包分析工具。 tcpdump可以将网络中传送的数据包的“头”完全截获下来提供分析。它支持针对网络层、协议、主机、网络或端口的过滤，并提供and、or、not等逻辑语句来帮助你去掉无用的信息。

实用命令实例

默许启动

普通情况下，直接启动tcpdump将监视第1个网络接口上所有流过的数据包。

eg: tcpdump -i any -Xs0 -n udp and host 10.128.65.143 

监视指定网络接口的数据包

如果不指定网卡，默许tcpdump只会监视第1个网络接口，1般是eth0，下面的例子都没有指定网络接口。　

监视指定主机的数据包

打印所有进入或离开sundown的数据包.

也能够指定ip,例如截获所有210.27.48.1 的主机收到的和发出的所有的数据包

打印helios 与 hot 或与 ace 之间通讯的数据包

截获主机210.27.48.1 和主机210.27.48.2 或210.27.48.3的通讯

打印ace与任何其他主机之间通讯的IP 数据包, 但不包括与helios之间的数据包.

如果想要获得主机210.27.48.1除和主机210.27.48.2以外所有主机通讯的ip包，使用命令：

截获主机hostname发送的所有数据

监视所有送到主机hostname的数据包

监视指定主机和端口的数据包

如果想要获得主机210.27.48.1接收或发出的telnet包，使用以下命令

对本机的udp 123 端口进行监视 123 为ntp的服务端口

监视指定网络的数据包

打印本地主机与Berkeley网络上的主机之间的所有通讯数据包(nt: ucb-ether, 此处可理解为'Berkeley网络'的网络地址,此表达式最原始的含义可表达为: 打印网络地址为ucb-ether的所有数据包)

打印所有通过网关snup的ftp数据包(注意, 表达式被单引号括起来了, 这可以避免shell对其中的括号进行毛病解析)

打印所有源地址或目标地址是本地主机的IP数据包

(如果本地网络通过网关连到了另外一网络, 则另外一网络其实不能算作本地网络.(nt: 此句翻译曲折,需补充).localnet 实际使用时要真正替换本钱地网络的名字)

监视指定协议的数据包

打印TCP会话中的的开始和结束数据包, 并且数据包的源或目的不是本地网络上的主机.(nt: localnet, 实际使用时要真正替换本钱地网络的名字))

打印所有源或目的端口是80, 网络层协议为IPv4, 并且含有数据,而不是SYN,FIN和ACK-only等不含数据的数据包.(ipv6的版本的表达式可做练习)

(nt: 可理解为, ip[2:2]表示全部ip数据包的长度, (ip[0]&0xf)<<2)表示ip数据包包头的长度(ip[0]&0xf代表包中的IHL域, 而此域的单位为32bit, 要换算

成字节数需要乘以4,　即左移2.　(tcp[12]&0xf0)>>4 表示tcp头的长度, 此域的单位也是32bit,　换算成比特数为 ((tcp[12]&0xf0) >> 4)　<<　２,　
即 ((tcp[12]&0xf0)>>2).　((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0　表示: 全部ip数据包的长度减去ip头的长度,再减去
tcp头的长度不为0, 这就意味着, ip数据包中确切是有数据.对ipv6版本只需斟酌ipv6头中的'Payload Length' 与 'tcp头的长度'的差值, 并且其中表达方式'ip[]'需换成'ip6[]'.)

打印长度超过576字节, 并且网关地址是snup的IP数据包

打印所有IP层广播或多播的数据包， 但不是物理以太网层的广播或多播数据报

打印除'echo request'或'echo reply'类型之外的ICMP数据包( 比如,需要打印所有非ping 程序产生的数据包时可用到此表达式 .
(nt: 'echo reuqest' 与 'echo reply' 这两种类型的ICMP数据包通常由ping程序产生))

tcpdump 与wireshark

Wireshark(之前是ethereal)是Windows下非常简单易用的抓包工具。但在Linux下很难找到1个好用的图形化抓包工具。
还好有Tcpdump。我们可以用Tcpdump + Wireshark 的完善组合实现：在 Linux 里抓包，然后在Windows 里分析包。

(1)tcp: ip icmp arp rarp 和 tcp、udp、icmp这些选项等都要放到第1个参数的位置，用来过滤数据报的类型
(2)-i eth1 : 只抓经过接口eth1的包
(3)-t : 不显示时间戳
(4)-s 0 : 抓取数据包时默许抓取长度为68字节。加上-S 0 后可以抓到完全的数据包
(5)-c 100 : 只抓取100个数据包
(6)dst port ! 22 : 不抓取目标端口是22的数据包
(7)src net 192.168.1.0/24 : 数据包的源网络地址为192.168.1.0/24
(8)-w ./target.cap : 保存成cap文件，方便用ethereal(即wireshark)分析

使用tcpdump抓取HTTP包

0x4745 为"GET"前两个字母"GE",0x4854 为"HTTP"前两个字母"HT"。

tcpdump 对截获的数据并没有进行完全解码，数据包内的大部份内容是使用106进制的情势直接打印输出的。明显这不利于分析网络故障，通常的解决办法是先使用带-w参数的tcpdump 截获数据并保存到文件中，然后再使用其他程序(如Wireshark)进行解码分析。固然也应当定义过滤规则，以免捕获的数据包填满全部硬盘。

输出信息含义

首先我们注意1下，基本上tcpdump总的的输出格式为：系统时间 来源主机.端口 > 目标主机.端口 数据包参数

tcpdump 的输出格式与协议有关.以下扼要描写了大部份经常使用的格式及相干例子.

链路层头

对FDDI网络, '-e' 使tcpdump打印出指定数据包的'frame control' 域, 源和目的地址, 和包的长度.(frame control域
控制对包中其他域的解析). 1般的包(比如那些IP datagrams)都是带有'async'(异步标志)的数据包，并且有取值0到7的优先级;
比如 'async4'就代表此包为异步数据包，并且优先级别为4. 通常认为,这些包们会内含1个 LLC包(逻辑链路控制包); 这时候,如果此包
不是1个ISO datagram或所谓的SNAP包，其LLC头部将会被打印(nt:应当是指此包内含的 LLC包的包头).

对Token Ring网络(令牌环网络), '-e' 使tcpdump打印出指定数据包的'frame control'和'access control'域, 和源和目的地址,
外加包的长度. 与FDDI网络类似, 此数据包通常内含LLC数据包. 不管 是不是有'-e'选项.对此网络上的'source-routed'类型数据包(nt:
意译为:源地址被追踪的数据包,具体含义未知,需补充), 其包的源路由信息总会被打印.

对802.11网络(WLAN,即wireless local area network), '-e' 使tcpdump打印出指定数据包的'frame control域,
包头中包括的所有地址, 和包的长度.与FDDI网络类似, 此数据包通常内含LLC数据包.

(注意: 以下的描写会假定你熟习SLIP紧缩算法 (nt:SLIP为Serial Line Internet Protocol.), 这个算法可以在
RFC⑴144中找到相干的蛛丝马迹.)

对SLIP网络(nt:SLIP links, 可理解为1个网络, 即通过串行线路建立的连接, 而1个简单的连接也可看成1个网络),
数据包的'direction indicator'('方向唆使标志')("I"表示入, "O"表示出), 类型和紧缩信息将会被打印. 包类型会被首先打印.

类型分为ip, utcp和ctcp(nt:未知, 需补充). 对ip包,连接信息将不被打印(nt:SLIP连接上,ip包的连接信息可能无用或没有定义.
reconfirm).对TCP数据包, 连接标识紧接着类型表示被打印. 如果此包被紧缩, 其被编码过的头部将被打印.
此时对特殊的紧缩包,会以下显示:
*S+n 或 *SA+n, 其中n代表包的(顺序号或(顺序号和应对号))增加或减少的数目(nt | rt:S,SA拗口, 需再译).
对非特殊的紧缩包,0个或更多的'改变'将会被打印.'改变'被打印时格式以下:
'标志'+/-/=n 包数据的长度 紧缩的头部长度.
其中'标志'可以取以下值:
U(代表紧急指针), W(指缓冲窗口), A(应对), S(序列号), I(包ID),而增量表达'=n'表示被赋予新的值, +/-表示增加或减少.

比如, 以下显示了对1个外发紧缩TCP数据包的打印, 这个数据包隐含1个连接标识(connection identifier); 应对号增加了6,
顺序号增加了49, 包ID号增加了6; 包数据长度为3字节(octect), 紧缩头部为6字节.(nt:如此看来这应当不是1个特殊的紧缩数据包).

ARP/RARP 数据包

tcpdump对Arp/rarp包的输出信息中会包括要求类型及该要求对应的参数. 显示格式简洁明了. 以下是从主机rtsg到主机csam的'rlogin'
(远程登录)进程开始阶段的数据包样例:
arp who-has csam tell rtsg
arp reply csam is-at CSAM
第1行表示:rtsg发送了1个arp数据包(nt:向全网段发送,arp数据包）以询问csam的以太网地址
Csam（nt:可从下文看出来, 是Csam）以她自己的以太网地址做了回应(在这个例子中, 以太网地址以大写的名字标识, 而internet
地址(即ip地址)以全部的小写名字标识).

如果使用tcpdump -n, 可以清晰看到以太网和ip地址而不是名字标识:
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, 则可以清晰的看到第1个数据包是全网广播的, 而第2个数据包是点对点的:
RTSG Broadcast 0806 64: arp who-has csam tell rtsg
CSAM RTSG 0806 64: arp reply csam is-at CSAM
第1个数据包表明:以arp包的源以太地址是RTSG, 目标地址是全以太网段, type域的值为16进制0806(表示ETHER_ARP(nt:arp包的类型标识)),
包的总长度为64字节.

TCP 数据包

(注意:以下将会假定你对 RFC⑺93所描写的TCP熟习. 如果不熟, 以下描写和tcpdump程序可能对你帮助不大.(nt:正告可疏忽,
只需继续看, 不熟习的地方可回头再看.).

通常tcpdump对tcp数据包的显示格式以下:
src > dst: flags data-seqno ack window urgent options

src 和 dst 是源和目的IP地址和相应的端口. flags 标志由S(SYN), F(FIN), P(PUSH, R(RST),
W(ECN CWT(nt | rep:未知, 需补充))或 E(ECN-Echo(nt | rep:未知,　需补充))组成,
单唯一个'.'表示没有flags标识. 数据段顺序号(Data-seqno)描写了此包中数据所对应序列号空间中的1个位置(nt:全部数据被分段,
每段有1个顺序号, 所有的顺序号构成1个序列号空间)(可参考以下例子). Ack 描写的是同1个连接,同1个方向,下1个本端应当接收的
(对方应当发送的)数据片断的顺序号. Window是本端可用的数据接收缓冲区的大小(也是对方发送数据时需根据这个大小来组织数据).
Urg(urgent) 表示数据包中有紧急的数据. options 描写了tcp的1些选项, 这些选项都用尖括号来表示(如 <mss 1024>).

src, dst 和 flags 这3个域总是会被显示. 其他域的显示与否依赖于tcp协议头里的信息.

这是1个从trsg到csam的1个rlogin利用登录的开始阶段.
rtsg.1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024>
csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024>
rtsg.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
第1行表示有1个数据包从rtsg主机的tcp端口1023发送到了csam主机的tcp端口login上(nt:udp协议的端口和tcp协议的端
口是分别的两个空间, 虽然取值范围1致). S表示设置了SYN标志. 包的顺序号是768512, 并且没有包括数据.(表示格式
为:'first:last(nbytes)', 其含义是'此包中数据的顺序号从first开始直到last结束，不包括last. 并且总共包括nbytes的
用户数据'.) 没有捎带应对(nt:从下文来看，第2行才是有捎带应对的数据包), 可用的接受窗口的大小为4096bytes, 并且要求端(rtsg)
的最大可接受的数据段大小是1024字节(nt:这个信息作为要求发向应对端csam, 以便双方进1步的协商).

Csam 向rtsg 回复了基本相同的SYN数据包, 其区分只是多了1个' piggy-backed ack'(nt:捎带回的ack应对, 针对rtsg的SYN数据包).

rtsg 一样针对csam的SYN数据包回复了1ACK数据包作为应对. '.'的含义就是此包中没有标志被设置. 由于此应对包中不含有数据, 所以
包中也没有数据段序列号. 提示! 此ACK数据包的顺序号只是1个小整数1. 有以下解释:tcpdump对1个tcp连接上的会话, 只打印会话两真个
初始数据包的序列号,其后相应数据包只打印出与初始包序列号的差异.即初始序列号以后的序列号,　可被看做此会话上当前所传数据片断在全部
要传输的数据中的'相对字节'位置(nt:双方的第1个位置都是1, 即'相对字节'的开始编号).　'-Ｓ'将覆盖这个功能,　
使数据包的原始顺序号被打印出来.

第6行的含义为:rtsg 向 csam发送了19字节的数据(字节的编号为2到20，传送方向为rtsg到csam). 包中设置了PUSH标志. 在第7行,
csam 喊到， 她已从rtsg中收到了21以下的字节, 但不包括21编号的字节. 这些字节寄存在csam的socket的接收缓冲中, 相应地,
csam的接收缓冲窗口大小会减少19字节(nt:可以从第5行和第7行win属性值的变化看出来). csam在第7行这个包中也向rtsg发送了1个
字节. 在第8行和第9行, csam 继续向rtsg 分别发送了两个只包括1个字节的数据包, 并且这个数据包带PUSH标志.

如果所抓到的tcp包(nt:即这里的snapshot)太小了，以致tcpdump没法完全得到其头部数据, 这时候, tcpdump会尽可能解析这个不完全的头,
并把剩下不能解析的部份显示为'[|tcp]'. 如果头部含有虚假的属性信息(比如其长度属性其实比头部实际长度长或短), tcpdump会为该头部
显示'[bad opt]'. 如果头部的长度告知我们某些选项(nt | rt:从下文来看， 指tcp包的头部中针对ip包的1些选项, 回头再翻)会在此包中,
而真实的IP(数据包的长度又不够容纳这些选项, tcpdump会显示'[bad hdr length]'.

抓取带有特殊标志的的TCP包(如SYN-ACK标志, URG-ACK标志等).

在TCP的头部中, 有8比特(bit)用作控制位区域, 其取值为:
CWR | ECE | URG | ACK | PSH | RST | SYN | FIN
(nt | rt:从表达方式上可推断:这8个位是用或的方式来组合的, 可回头再翻)

现假定我们想要监控建立1个TCP连接全部进程中所产生的数据包. 可回想以下:TCP使用3次握手协议来建立1个新的连接; 其与此3次握手
连接顺序对应，并带有相应TCP控制标志的数据包以下:
1) 连接发起方(nt:Caller)发送SYN标志的数据包
2) 接收方(nt:Recipient)用带有SYN和ACK标志的数据包进行回应
3) 发起方收到接收方回应后再发送带有ACK标志的数据包进行回应

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 |
-----------------------------------------------------------------

1个TCP头部,在不包括选项数据的情况下通常占用20个字节(nt | rt:options 理解为选项数据，需回译). 第1行包括0到3编号的字节,
第2行包括编号4⑺的字节.

如果编号从0开始算, TCP控制标志位于13字节(nt:第4行左半部份).

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|

这里有我们感兴趣的控制标志位. 从右往左这些位被顺次编号为0到7, 从而 PSH位在3号, 而URG位在5号.

提示1下自己, 我们只是要得到包括SYN标志的数据包. 让我们看看在1个包的包头中, 如果SYN位被设置, 到底
在13号字节产生了甚么:

|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(bit number 1)被置位.

假定编号为13的字节是1个8位的无符号字符型,并且依照网络字节号排序(nt:对1个字节来讲，网络字节序同等于主机字节序), 其2进制值
以下所示:
00000010

并且其10进制值为:

0*2^7 + 0*2^6 + 0*2^5 + 0*2^4 + 0*2^3 + 0*2^2 + 1*2^1 + 0*2^0 = 2(nt: 1 * 2^6 表示1乘以2的6次方, 或许这样更
清楚些, 即把原来表达中的指数7 6 ... 0挪到了下面来表达)

接近目标了, 由于我们已知道, 如果数据包头部中的SYN被置位, 那末头部中的第13个字节的值为2(nt: 依照网络序, 即大头方式, 最重要的字节
在前面(在前面,即该字节实际内存地址比较小, 最重要的字节,指数学表示中数的高位, 如356中的3) ).

表达为tcpdump能理解的关系式就是:
tcp[13] 2

从而我们可以把此关系式当作tcpdump的过滤条件, 目标就是监控只含有SYN标志的数据包:
tcpdump -i xl0 tcp[13] 2 (nt: xl0 指网络接口, 如eth0)

这个表达式是说"让TCP数据包的第13个字节具有值2吧", 这也是我们想要的结果.

现在, 假定我们需要抓取带SYN标志的数据包, 而疏忽它是不是包括其他标志.(nt:只要带SYN就是我们想要的). 让我们来看看当1个含有
SYN-ACK的数据包(nt:SYN 和 ACK 标志都有), 来到时产生了甚么:
|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号位被置位, 其2进制的值为:
00010010

转换成10进制就是:

0*2^7 + 0*2^6 + 0*2^5 + 1*2^4 + 0*2^3 + 0*2^2 + 1*2^1 + 0*2 = 18(nt: 1 * 2^6 表示1乘以2的6次方, 或许这样更
清楚些, 即把原来表达中的指数7 6 ... 0挪到了下面来表达)

现在, 却不能只用'tcp[13] 18'作为tcpdump的过滤表达式, 由于这将致使只选择含有SYN-ACK标志的数据包, 其他的都被抛弃.
提示1下自己, 我们的目标是: 只要包的SYN标志被设置就行, 其他的标志我们不理睬.

为了到达我们的目标, 我们需要把13号字节的2进制值与其他的1个数做AND操作(nt:逻辑与)来得到SYN比特位的值. 目标是:只要SYN 被设置
就行, 因而我们就把她与上13号字节的SYN值(nt: 00000010).

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

我们可以发现, 不管包的ACK或其他标志是不是被设置, 以上的AND操作都会给我们相同的值, 其10进制表达就是2(2进制表达就是00000010).
从而我们知道, 对带有SYN标志的数据包, 以下的表达式的结果总是真(true):

( ( value of octet 13 ) AND ( 2 ) ) ( 2 ) (nt: value of octet 13, 即13号字节的值)

灵感随之而来, 我们因而得到了以下的tcpdump 的过滤表达式
tcpdump -i xl0 'tcp[13] & 2 2'

注意, 单引号或反斜杆(nt: 这里用的是单引号)不能省略, 这可以避免shell对&的解释或替换.

UDP 数据包

UDP 数据包的显示格式，可通过rwho这个具体利用所产生的数据包来讲明:
actinide.who > broadcast.who: udp 84

其含义为:actinide主机上的端口who向broadcast主机上的端口who发送了1个udp数据包(nt: actinide和broadcast都是指Internet地址).
这个数据包承载的用户数据为84个字节.

1些UDP服务可从数据包的源或目的端口来辨认，也可从所显示的更高层协议信息来辨认. 比如, Domain Name service requests(DNS 要求,
在RFC⑴034/1035中), 和Sun RPC calls to NFS(对NFS服务器所发起的远程调用(nt: 即Sun RPC)，在RFC⑴050中有对远程调用的描写).

UDP 名称服务要求

(注意:以下的描写假定你对Domain Service protoco(nt:在RFC⑴03中有所描写), 否则你会发现以下描写就是天书(nt:希腊文天书,
没必要理睬, 吓吓你的, 接着看就行))

名称服务要求有以下的格式:
src > dst: id op? flags qtype qclass name (len)
(nt: 从下文来看, 格式应当是src > dst: id op flags qtype qclass? name (len))
比如有1个实际显示为:
h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)

主机h2opolo 向helios 上运行的名称服务器查询ucbvax.berkeley.edu 的地址记录(nt: qtype等于A). 此查询本身的id号为'3'. 符号
'+'意味着递归查询标志被设置(nt: dns服务器可向更高层dns服务器查询本服务器不包括的地址记录). 这个终究通过IP包发送的查询要求
数据长度为37字节, 其中不包括UDP和IP协议的头数据. 由于此查询操作为默许值(nt | rt: normal one的理解), op字段被省略.
如果op字段没被省略, 会被显示在'3' 和'+'之间. 一样, qclass也是默许值, C_IN, 从而也没被显示, 如果没被疏忽, 她会被显示在'A'以后.

异常检查会在方括中显示出附加的域:　如果1个查询同时包括1个回应(nt: 可理解为, 对之前其他1个要求的回应), 并且此回应包括权威或附加记录段,　
ancount, nscout, arcount(nt: 具体字段含义需补充) 将被显示为'[na]', '[nn]', '[nau]', 其中n代表适合的计数. 如果包中以下
回应位(比如AA位, RA位, rcode位), 或字节2或3中任何1个'必须为0'的位被置位(nt: 设置为1), '[b2&3]=x' 将被显示, 其中x表示
头部字节2与字节3进行与操作后的值.

UDP 名称服务应对

对名称服务应对的数据包，tcpdump会有以下的显示格式
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)

第1行表示: helios 对h2opolo 所发送的3号查询要求回应了3条回答记录(nt | rt: answer records), 3条名称服务器记录,
和7条附加的记录. 第1个回答记录(nt: 3个回答记录中的第1个)类型为A(nt: 表示地址), 其数据为internet地址128.32.137.3.
此回应UDP数据包, 包括273字节的数据(不包括UPD和IP的头部数据). op字段和rcode字段被疏忽(nt: op的实际值为Query, rcode, 即
response code的实际值为NoError), 一样被疏忽的字段还有class 字段(nt | rt: 其值为C_IN, 这也是A类型记录默许取值)

第2行表示: helios 对h2opolo 所发送的2号查询要求做了回应. 回应中, rcode编码为NXDomain(nt: 表示不存在的域)), 没有回答记录,
但包括1个名称服务器记录, 不包括权威服务器记录(nt | ck: 从上文来看, 此处的authority records 就是上文中对应的additional
records). '*'表示权威服务器回答标志被设置(nt: 从而additional records就表示的是authority records).
由于没有回答记录, type, class, data字段都被疏忽.

flag字段还有可能出现其他1些字符, 比如'-'(nt: 表示可递归地查询, 即RA 标志没有被设置), '|'(nt: 表示被截断的消息, 即TC 标志
被置位). 如果应对(nt | ct: 可理解为, 包括名称服务应对的UDP数据包, tcpdump知道这类数据包该怎样解析其数据)的'question'段1个条
目(entry)都不包括(nt: 每一个条目的含义, 需补充),'[nq]' 会被打印出来.

要注意的是:名称服务器的要求和应对数据量比较大, 而默许的68字节的抓取长度(nt: snaplen, 可理解为tcpdump的1个设置选项)可能不足以抓取
数据包的全部内容. 如果你真的需要仔细查看名称服务器的负载, 可以通过tcpdump 的-s 选项来扩大snaplen值.

SMB/CIFS 解码

tcpdump 已可以对SMB/CIFS/NBT相干利用的数据包内容进行解码(nt: 分别为'Server Message Block Common', 'Internet File System'
'在TCP/IP上实现的网络协议NETBIOS的简称'. 这几个服务通常使用UDP的137/138和TCP的139端口). 原来的对IPX和NetBEUI SMB数据包的
解码能力仍然可以被使用(nt: NetBEUI为NETBIOS的增强版本).

tcpdump默许只依照最简约模式对相应数据包进行解码, 如果我们想要详实的解码信息可使用其-v 启动选现. 要注意的是, -v 会产生非常详细的信息,
比如对单1的1个SMB数据包, 将产生1屏幕或更多的信息, 所以此选项, 确有需要才使用.

关于SMB数据包格式的信息, 和每一个域的含义可以参看www.cifs.org 或samba.org 镜像站点的pub/samba/specs/ 目录. linux 上的SMB 补钉
(nt | rt: patch)由 Andrew Tridgell (tridge@samba.org)提供.

NFS 要求和回应

tcpdump对Sun NFS(网络文件系统)要求和回应的UDP数据包有以下格式的打印输出:
src.xid > dst.nfs: len op args
src.nfs > dst.xid: reply stat len op results

以下是1组具体的输出数据
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

第1行输出表明: 主机sushi向主机wrl发送了1个'交换要求'(nt: transaction), 此要求的id为6709(注意, 主机名字后是交换
要求id号, 而不是源端口号). 此要求数据为112字节, 其中不包括UDP和IP头部的长度. 操作类型为readlink(nt: 即此操作为读符号链接操作),
操作参数为fh 21,24/10.73165(nt: 可按实际运行环境, 解析以下, fd 表示描写的为文件句柄, 21,24 表示此句柄所对应设
备的主/从装备号对, 10表示此句柄所对应的i节点编号(nt:每一个文件都会在操作系统中对应1个i节点, 限于unix类系统中),
73165是1个编号(nt: 可理解为标识此要求的1个随机数, 具体含义需补充)).

第2行中, wrl 做了'ok'的回应, 并且在results 字段中返回了sushi想要读的符号连接的真实目录(nt: 即sushi要求读的符号连接实际上是1个目录).

第3行表明: sushi 再次要求 wrl 在'fh 9,74/4096.6878'所描写的目录中查找'xcolors'文件. 需要注意的是, 每行所显示的数据含义依赖于其中op字段的
类型(nt: 不同op 所对应args 含义不相同), 其格式遵守NFS 协议, 寻求简洁明了.

如果tcpdump 的-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 选项1般还会打印出IP头部的TTL, ID， length, 和fragmentation 域, 但在此例中, 都略过了(nt: 可理解为,简洁起见, 做了删减))
在第1行, sushi 要求wrl 从文件 21,11/12.195(nt: 格式在上面有描写)中, 自偏移24576字节处开始, 读取8192字节数据.
Wrl 回应读取成功; 由于第2行只是回应要求的开头片断, 所以只包括1472字节(其他的数据将在接着的reply片断中到来, 但这些数据包不会再有NFS
头, 乃至UDP头信息也为空(nt: 源和目的应当要有), 这将致使这些片断不能满足过滤条件, 从而没有被打印). -v 选项除显示文件数据信息, 还会显示
附加显示文件属性信息: file type(文件类型, ''REG'' 表示普通文件), file mode(文件存取模式, 8进制表示的), uid 和gid(nt: 文件属主和
组属主), file size (文件大小).

如果-v 标志被屡次重复给出(nt: 如-vv)， tcpdump会显示更加详细的信息.

必须要注意的是, NFS 要求包中数据比较多, 如果tcpdump 的snaplen(nt: 抓取长度) 取太短将不能显示其详细信息. 可以使用
'-s 192'来增加snaplen, 这可用以监测NFS利用的网络负载(nt: traffic).

NFS 的回应包其实不严格的紧随之前相应的要求包(nt: RPC operation). 从而, tcpdump 会跟踪最近收到的1系列要求包, 再通过其
交换序号(nt: transaction ID)与相应要求包相匹配. 这可能产生1个问题， 如果回应包来得太迟, 超越tcpdump 对相应要求包的跟踪范围,
该回应包将不能被分析.

AFS 要求和回应

AFS(nt: Andrew 文件系统, Transarc , 未知, 需补充)要求和回应有以下的答应

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

在第1行, 主机elvis 向pike 发送了1个RX数据包.
这是1个对文件服务的要求数据包(nt: RX data packet, 发送数据包 , 可理解为发送包过去, 从而要求对方的服务), 这也是1个RPC
调用的开始(nt: RPC, remote procedure call). 此RPC 要求pike 履行rename(nt: 重命名) 操作, 并指定了相干的参数:
原目录描写符为536876964/1/1, 原文件名为 '.newsrc.new', 新目录描写符为536876964/1/1, 新文件名为 '.newsrc'.
主机pike 对此rename操作的RPC要求作了回应(回应表示rename操作成功, 由于回应的是包括数据内容的包而不是异常包).

1般来讲, 所有的'AFS RPC'要求被显示时, 会被冠以1个名字(nt: 即decode, 解码), 这个名字常常就是RPC要求的操作名.
并且, 这些RPC要求的部份参数在显示时, 也会被冠以1个名字(nt | rt: 即decode, 解码, 1般来讲也是取名也很直接, 比如,
1个interesting 参数, 显示的时候就会直接是'interesting', 含义拗口, 需再翻).

这类显示格式的设计初衷为'1看就懂', 但对不熟习AFS 和 RX 工作原理的人可能不是很
有用(nt: 还是不用管, 书面吓吓你的, 往下看就行).

如果 -v(详细)标志被重复给出(nt: 如-vv), tcpdump 会打印出确认包(nt: 可理解为, 与应对包有区分的包)和附加头部信息
(nt: 可理解为, 所有包, 而不单单是确认包的附加头部信息), 比如, RX call ID(要求包中'要求调用'的ID),
call number('要求调用'的编号), sequence number(nt: 包顺序号),
serial number(nt | rt: 可理解为与包中数据相干的另外一个顺信号, 具体含义需补充), 要求包的标识. (nt: 接下来1段为重复描写,
所以略去了), 另外确认包中的MTU协商信息也会被打印出来(nt: 确认包为相对要求包的确认包, Maximum Transmission Unit, 最大传输单元).

如果 -v 选项被重复了3次(nt: 如-vvv), 那

生活不易，码农辛苦
如果您觉得本网站对您的学习有所帮助,可以手机扫描二维码进行捐赠