|
||||||||||
|
|
|||||||||
|
|
|||||||||||||||
| | 网站首页 | 局域网教程 | 软件说明书 | 局域网论坛 | | ||
 |
||
|
||
|
|||||
| TCPDUMP中文手册 | |||||
作者：互联网 文章来源：www.98pc.com 点击数： 更新时间：2006-4-28  |
|||||
rtsg.1023>csam.login:S768512:768512(0)win4096 csam.login>rtsg.1023:S947648:947648(0)ack768513win4096 rtsg.1023>csam.login:.ack1win4096 rtsg.1023>csam.login:P1:2(1)ack1win4096 csam.login>rtsg.1023:.ack2win4096 rtsg.1023>csam.login:P2:21(19)ack1win4096 csam.login>rtsg.1023:P1:2(1)ack21win4077 csam.login>rtsg.1023:P2:3(1)ack21win4077urg1 csam.login>rtsg.1023:P3:4(1)ack21win4077urg1 第一行是说从rtsg的tcp端口1023向csam的login端口发送报文.S标志表明设置了SYN标志.报文的流序号是768512,没有数据.(这个写成`first:last(nbytes)',意思是`从流序号first到last,不包括last,有nbytes字节的用户数据'.)此时没有捎带确认(piggy-backedack),有效的接收窗口是4096字节,有一个最大段大小(max-segment-size)的选项,请求设置mss为1024字节. Csam用类似的形式应答,只是增加了一个对rtsgSYN的捎带确认.然后Rtsg确认csam的SYN.`.'意味着没有设置标志.这个报文不包含数据,因此也就没有数据的流序号.注意这个确认流序号是一个小整数(1).当tcpdump第一次发现一个tcp会话时,它显示报文携带的流序号.在随后收到的报文里,它显示当前报文和最初那个报文的流序号之差.这意味着从第一个报文开始,以后的流序号可以理解成数据流中的相对位移asrelativebytepositionsintheconversation'sdatastream(withthefirstdatabyteeachdirectionbeing`1').`-S'选项能够改变这个特性,直接显示原始的流序号. 在第六行,rtsg传给csam19个字节的数据(字节2到20).报文中设置了PUSH标志.第七行csam表明它收到了rtsg的数据,字节序号是21,但不包括第21个字节.显然大多数数据在socket的缓冲区内,因为csam的接收窗口收到的数据小于19个字节.同时csam向rtsg发送了一个字节的数据.第八和第九行显示csam发送了两个字节的紧急数据到rtsg. 如果捕捉区设置的过小,以至于tcpdump不能捕捉到完整的TCP报头,tcpdump会尽可能的翻译已捕获的部分,然后显示``[|tcp]'',表明无法翻译其余部分.如果报头包含一个伪造的选项(onewithalengththat'seithertoosmallorbeyondtheendoftheheader),tcpdump显示``[badopt]''并且不再翻译其他选项部分(因为它不可能判断出从哪儿开始).如果报头长度表明存在选项,但是IP数据报长度不够,不可能真的保存选项,tcpdump就显示``[badhdrlength]''. UDP报文 UDP格式就象这个rwho报文显示的: actinide.who>broadcast.who:udp84 就是说把一个udp数据报从主机actinide的who端口发送到broadcast,Internet广播地址的who端口.报文包含84字节的用户数据. 某些UDP服务能够识别出来(从源目端口号上),因而显示出更高层的协议信息.特别是域名服务请求(RFC-1034/1035)和NFS的RPC调用(RFC-1050). UDP域名服务请求(NameServerRequests) (注意:以下的描述中假设你熟悉RFC-1035说明的域名服务协议.如果你不熟悉这个协议,下面的内容就象是天书.) 域名服务请求的格式是 src>dst:idop?flagsqtypeqclassname(len) h2opolo.1538>helios.domain:3+A?ucbvax.berkeley.edu.(37) 主机h2opolo访问helios上的域名服务,询问和ucbvax.berkeley.edu.关联的地址记录(qtype=A).查询号是`3'.`+'表明设置了递归请求标志.查询长度是37字节,不包括UDP和IP头.查询操作是普通的Query操作,因此op域可以忽略.如果op设置成其他什么东西,它应该显示在`3'和`+'之间.类似的,qclass是普通的C_IN类型,也被忽略了.其他类型的qclass应该在`A'后面显示. Tcpdump会检查一些不规则情况,相应的结果作为补充域放在方括号内:如果某个查询包含回答,名字服务或管理机构部分,就把ancount,nscount,或arcount显示成`[na]',`[nn]'或`[nau]',这里的n代表相应的数量.如果在第二和第三字节中,任何一个回答位(AA,RA或rcode)或任何一个`必须为零'的位被置位,就显示`[b2&3=x]',这里的x是报头第二和第三字节的16进制数. UDP名字服务回答 名字服务回答的格式是 src>dst:idoprcodeflagsa/n/autypeclassdata(len) helios.domain>h2opolo.1538:33/3/7A128.32.137.3(273) helios.domain>h2opolo.1537:2NXDomain*0/1/0(97) 第一个例子里,helios回答了h2opolo发出的标识为3的询问,一共是3个回答记录,3个名字服务记录和7个管理结构记录.第一个回答纪录的类型是A(地址),数据是internet地址128.32.137.3.回答的全长为273字节,不包括UDP和IP报头.作为A记录的class(C_IN)可以忽略op(询问)和rcode(NoError). 在第二个例子里,helios对标识为2的询问作出域名不存在(NXDomain)的回答,没有回答记录,一个名字服务记录,而且没有管理结构. `*'表明设置了权威回答(authoritativeanswer).由于没有回答记录,这里就不显示type,class和data. 其他标志字符可以显示为`-'(没有设置递归有效(RA))和`|'(设置消息截短(TC)).如果`问题'部分没有有效的内容,就显示`[nq]'. 注意名字服务的询问和回答一般说来比较大,68字节的snaplen可能无法捕捉到足够的报文内容.如果你的确在研究名字服务的情况,可以使用-s选项增大捕捉缓冲区.`-s128'应该效果不错了. NFS请求和响应 SunNFS(网络文件系统)的请求和响应显示格式是: src.xid>dst.nfs:lenopargs src.nfs>dst.xid:replystatlenopresults sushi.6709>wrl.nfs:112readlinkfh21,24/10.73165 wrl.nfs>sushi.6709:replyok40readlink"../var" sushi.201b>wrl.nfs: 144lookupfh9,74/4096.6878"xcolors" wrl.nfs>sushi.201b: replyok128lookupfh9,74/4134.3150 在第一行,主机sushi向wrl发送号码为6709的交易会话(注意源主机后面的数字是交易号,不是端口).这项请求长112字节,不包括UDP和IP报头.在文件句柄(fh)21,24/10.731657119上执行readlink(读取符号连接)操作.(如果运气不错,就象这种情况,文件句柄可以依次翻译成主次设备号,i节点号,和事件号(generationnumber).)Wrl回答`ok'和连接的内容. 在第三行,sushi请求wrl在目录文件9,74/4096.6878中查找`xcolors'.注意数据的打印格式取决于操作类型.格式应该是可以自我说明的. 给出-v(verbose)选项可以显示附加信息.例如: sushi.1372a>wrl.nfs: 148readfh21,11/12.1958192bytes@24576 wrl.nfs>sushi.1372a: replyok1472readREG100664ids417/0sz29388 (-v同时使它显示IP报头的TTL,ID,和分片域,在这个例子里把它们省略了.)在第一行,sushi请求wrl从文件21,11/12.195的偏移位置24576开始,读取8192字节.Wrl回答`ok';第二行显示的报文是应答的第一个分片,因此只有1472字节(其余数据在后续的分片中传过来,但由于这些分片里没有NFS甚至UDP报头,因此根据所使用的过滤器表达式,有可能不显示).-v选项还会显示一些文件属性(它们作为文件数据的附带部分传回来):文件类型(普通文件``REG''),存取模式(八进制数),uid和gid,以及文件大小. 如果再给一个-v选项(-vv),还能显示更多的细节. 注意NFS请求的数据量非常大,除非增加snaplen,否则很多细节无法显示.试一试`-s192'选项. NFS应答报文没有明确标明RPC操作.因此tcpdump保留有``近来的''请求记录,根据交易号匹配应答报文.如果应答报文没有相应的请求报文,它就无法分析. KIPAppletalk(UDP上的DDP) AppletalkDDP报文封装在UDP数据报中,解包后按DDP报文转储(也就是说,忽略所有的UDP报头信息).文件/etc/atalk.names用来把appletalk网络和节点号翻译成名字.这个文件的行格式是 numbername 1.254ether 16.1icsd-net 1.254.110ace 前两行给出了appletalk的网络名称.第三行给出某个主机的名字(主机和网络依据第三组数字区分-网络号一定是两组数字,主机号一定是三组数字.)号码和名字用空白符(空格或tab)隔开./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,或者里面缺少有效项目,就以数字形式显示地址.)第一个例子里,网络144.1的209节点的NBP(DDP端口2)向网络icsd的112节点的220端口发送数据.第二行和上面一样,只是知道了源节点的全称(`office').第三行是从网络jssmag的149节点的235端口向icsd-net的NBP端口广播(注意广播地址(255)隐含在无主机号的网络名字中-所以在/etc/atalk.names中区分节点名和网络名是个好主意). Tcpdump可以翻译NBP(名字联结协议)和ATP(Appletalk交互协议)的报文内容.其他协议只转储协议名称(或号码,如果还没给这个协议注册名称)和报文大小. NBP报文的输出格式就象下面的例子: icsd-net.112.220>jssmag.2:nbp-lkup190:"=:LaserWriter@*" jssmag.209.2>icsd-net.112.220:nbp-reply190:"RM1140:LaserWriter@*"250 techpit.2>icsd-net.112.220:nbp-reply190:"techpit:LaserWriter@*"186 第一行是网络icsd的112主机在网络jssmag上的广播,对名字laserwriter做名字查询请求.名字查询请求的nbp标识号是190.第二行显示的是对这个请求的回答(注意它们有同样的标识号),主机jssmag.209表示在它的250端口注册了一个laserwriter的资源,名字是"RM1140".第三行是这个请求的其他回答,主机techpit的186端口有laserwriter注册的"techpit". ATP报文格式如下例所示: jssmag.209.165>helios.132:atp-req12266<0-7>0xae030001 helios.132>jssmag.209.165:atp-resp12266:0(512)0xae040000 helios.132>jssmag.209.165:atp-resp12266:1(512)0xae040000 helios.132>jssmag.209.165:atp-resp12266:2(512)0xae040000 helios.132>jssmag.209.165:atp-resp12266:3(512)0xae040000 helios.132>jssmag.209.165:atp-resp12266:4(512)0xae040000 helios.132>jssmag.209.165:atp-resp12266:5(512)0xae040000 helios.132>jssmag.209.165:atp-resp12266:6(512)0xae040000 helios.132>jssmag.209.165:atp-resp*12266:7(512)0xae040000 jssmag.209.165>helios.132:atp-req12266<3,5>0xae030001 helios.132>jssmag.209.165:atp-resp12266:3(512)0xae040000 helios.132>jssmag.209.165:atp-resp12266:5(512)0xae040000 jssmag.209.165>helios.132:atp-rel12266<0-7>0xae030001 jssmag.209.133>helios.132:atp-req*12267<0-7>0xae030002 Jssmag.209向主机helios发起12266号交易,请求8个报文(`<0-7>').行尾的十六进制数是请求中`userdata'域的值. |
|||||
| 文章录入：wuwq 责任编辑：wuwq | |||||
| 【发表评论】【加入收藏】【告诉好友】【打印此文】【关闭窗口】 | |||||
| 最新热点 | 最新推荐 | 相关文章 | ||
| QQ协议分析之TCPF包结构 QQ协议分析之TCPF包数据分析 用协议分析工具学习TCP/IP 学习如何分析进出服务器的TC 如何读懂DHCP数据报文 windows服务器启用TCP-IP筛选 注意：黑客可能利用新TCP漏洞 软交换（Softswitch）网络架 Summit Switch & Cisco Ethe 在Cisco Catalyst 交换机常见 |
| 网友评论：（只显示最新10条。评论内容只代表网友观点，与本站立场无关！） |
| | 设为首页 | 加入收藏 | 联系站长 | 友情链接 | 版权申明 | 网站公告 | | |||||
|
