linux下最全抓包命令使用方式学习和拓展

时间:2025-02-25 15:20:50

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

时间戳

默认情况下,所有输出行前面都有一个时间戳。时间戳是表单中的当前时钟时间

hh:mm:
并且与内核的时钟一样准确。时间戳反映内核对数据包应用时间戳的时间。没有尝试考虑网络接口完成从网络接收数据包到内核对数据包应用时间戳之间的时间延迟;该时间延迟可能包括网络接口完成从网络接收数据包的时间与将中断传递给内核以使其读取数据包的时间之间的延迟,以及内核服务于“新数据包”中断和它对数据包应用时间戳的时间。

链接级别标头

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

在 FDDI 网络上,“-e”选项使tcpdump打印“帧控制”字段、源地址和目标地址以及数据包长度。(“帧控制”字段控制对数据包其余部分的解释。普通数据包(例如包含 IP 数据报的数据包)是“异步”数据包,优先级值在 0 到 7 之间;例如,“ async4 ”。这样的假设数据包包含 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”表示出站)、数据包类型和压缩信息。首先打印数据包类型。这三种类型是iputcpctcp。没有为ip数据包打印更多的链接信息。对于 TCP 数据包,连接标识符打印在类型之后。如果数据包被压缩,则打印出其编码的标头。特殊情况打印为 *S+ n*SA+ n,其中n是序列号(或序列号和确认)已更改的量。如果不是特殊情况,则打印零个或多个更改。更改由 U(紧急指针)、W(窗口)、A(确认)、S(序列号)和 I(数据包 ID)指示,后跟 delta(+n 或 -n)或新值(=n)。最后,打印数据包中的数据量和压缩包头长度。

例如,以下行显示了一个出站压缩 TCP 数据包,带有一个隐式连接标识符;ack 变了 6,sequence number 变了 49,packet ID 变了 6;有 3 个字节的数据和 6 个字节的压缩头:

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

ARP/RARP 数据包

ARP/RARP 输出显示请求的类型及其参数。该格式旨在自我解释。这是从主机rtsg到主机csam的“rlogin”开始时的一个简短示例:


arp 谁有 csam 告诉 rtsg
arp 回复 csam is-at CSAM

第一行表示 rtsg 发送了一个 ARP 数据包,询问 Internet 主机 csam 的以太网地址。Csam 用它的以太网地址回复(在这个例子中,以太网地址大写,互联网地址小写)。

如果我们执行了tcpdump -n ,这看起来就不那么多余了:


arp 谁拥有 128.3.254.6 告诉 128.3.254.68
arp 回复 128.3.254.6 is-at 02:07:01:00:01:c4

如果我们执行了tcpdump -e,那么第一个数据包是广播的,第二个是点对点的这一事实将是可见的:


RTSG 广播 0806 64:arp who-has csam tell rtsg
CSAM RTSG 0806 64:arp 回复 csam is-at CSAM

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

IPv4 数据包

如果没有打印链路层报头,对于 IPv4 数据包, IP将在时间戳之后打印。

如果指定了 -v标志,来自 IPv4 标头的信息将显示在IP或链路层标头 之后的括号中。该信息的一般格式为:


tos tos , ttl ttl , id id , offset offset , flags [ flags ], proto proto , length长度, options ( options )

tos是服务字段的类型;如果 ECN 位不为零,则报告为ECT(1)ECT(0)CE。 ttl是生存时间;如果为零,则不报告。 id是 IP 标识字段。 offset是片段偏移量字段;无论这是否是分段数据报的一部分,都会打印出来。 flags是 MF 和 DF 标志;如果设置了MF,则报告+ ,如果设置了F,则报告DF。如果两者都没有设置,被报道。 proto是协议 ID 字段。 length是总长度字段。 选项是 IP 选项(如果有)。

接下来,对于 TCP 和 UDP 数据包,将打印源 IP 地址和目标 IP 地址以及 TCP 或 UDP 端口,每个 IP 地址与其对应的端口之间有一个点,将用 > 分隔源和目标。对于其他协议,将打印地址,并用 > 分隔源和目标。之后将打印更高级别的协议信息(如果有)。

对于分段的 IP 数据报,第一个分段包含更高级别的协议头;第一个之后的片段不包含更高级别的协议头。 如上所述, 分段信息将仅在 IP 标头信息中使用 -v标志打印。

TCP 数据包

(注意:以下描述假定您熟悉 RFC 793 中描述的 TCP 协议。如果您不熟悉该协议,则此描述对您没有多大用处。)

TCP 协议行的一般格式是:

src > dst : 标志 [ tcpflags ], seq data-seqno , ack ackno , win window , urg紧急, options [ opts ], length len

srcdst是源 IP 地址和目标 IP 地址和端口。 Tcpflags是 S (SYN)、F (FIN)、P (PUSH)、R (RST)、U (URG)、W (ECN CWR)、E (ECN-Echo) 或 `.' 的某种组合。(ACK),如果没有设置标志,则为“无”。 Data-seqno描述了这个数据包中的数据所覆盖的序列空间部分(参见下面的示例)。 Ackno是此连接上另一个方向预期的下一个数据的序列号。 Window是此连接上另一个方向可用的接收缓冲区空间的字节数。 Urg表示数据包中有“紧急”数据。 选项是 TCP 选项(例如,mss 1024)。 是有效载荷数据的长度。

IptypeSrcdst标志始终存在。其他字段取决于数据包的 TCP 协议标头的内容,并且仅在适当时才输出。

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


IP rtsg.1023 > : 标志 [S], seq 768512:768512, win 4096, opts [mss 1024]
IP  > rtsg.1023: 标志 [S.], seq, 947648:947648, ack 768513, win 4096, opts [mss 1024]
IP rtsg.1023 > : 标志 [.], ack 1, win 4096
IP rtsg.1023 > : Flags [P.], seq 1:2, ack 1, win 4096, length 1
IP  > rtsg.1023: 标志 [.], ack 2, win 4096
IP rtsg.1023 > :标志 [P.],seq 2:21,ack 1,win 4096,长度 19
IP  > rtsg.1023:标志 [P.],seq 1:2,ack 21,win 4077,长度 1
IP  > rtsg.1023:标志 [P.],seq 2:3,ack 21,win 4077,urg 1,长度 1
IP  > rtsg.1023:标志 [P.],seq 3:4,ack 21,win 4077,urg 1,长度 1

第一行表示 rtsg 上的 TCP 端口 1023 向 csam 上的登录端口发送了一个数据包 。S表示设置了SYN标志。数据包序列号是 768512,它不包含任何数据。(符号是 `first:last',意思是 `sequence numbers first up to but not include last '。)没有捎带 ACK,可用的接收窗口是 4096 字节,并且有一个 max-segment-size 选项请求1024 字节的 MSS。

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

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

如果快照足够小以至于tcpdump没有捕获完整的 TCP 标头,它会尽可能多地解释标头,然后报告 ``[| tcp ]'' 表示无法解释余数。如果标头包含一个虚假选项(一个长度太小或超出标头末尾的选项),tcpdump 会将其报告为 ``[ bad opt ]'' 并且不会解释任何进一步的选项(因为无法分辨他们从哪里开始)。如果标头长度表明存在选项,但 IP 数据报长度不足以使选项实际存在,则tcpdump将其报告为 ``[ bad hdr length ]''。

捕获具有特定标志组合(SYN-ACK、URG-ACK 等)的 TCP 数据包

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

CWR | 欧洲经委会 | 急需 | 确认 | PSH | RST | 同步 | 鳍

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

1) 调用者发送 SYN

2) 接收方用 SYN、ACK 响应

3) 调用者发送 ACK

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

回想一下没有选项的 TCP 标头的结构:

0 15 31
-------------------------------------------------- ---------------
| 源港 | 目的港|
-------------------------------------------------- ---------------
| 序号 |
-------------------------------------------------- ---------------
| 确认号码 |
-------------------------------------------------- ---------------
| HL | rsvd |C|E|U|A|P|R|S|F| 窗口大小 |
-------------------------------------------------- ---------------
| TCP 校验和 | 紧急指针 |
-------------------------------------------------- ---------------

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

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

0 7| 15| 23| 31
----------------|---------------|----------------|- ---------------
| HL | rsvd |C|E|U|A|P|R|S|F| 窗口大小 |
----------------|---------------|----------------|- ---------------
| | 第 13 个八位字节 | | |

让我们仔细看看八位字节。13:

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

这些是我们感兴趣的 TCP 控制位。我们将这个八位字节中的位从右到左从 0 到 7 编号,所以 PSH 位是位号 3,而 URG 位是位号 5。

回想一下,我们想要捕获仅设置了 SYN 的数据包。让我们看看如果 TCP 数据报到达时在其标头中设置了 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 (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 数据报到达时,八位字节 13 会发生什么:

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

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


     00010010

转换为十进制

   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 的数据包。请记住,只要设置了 SYN,我们就不会关心是否设置了 ACK 或任何其他控制位。

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


          00010010 SYN-ACK 00000010 SYN
     AND 00000010(我们想要 SYN)和 00000010(我们想要 SYN)
          -------- --------
     = 00000010 = 00000010

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

( ( 八位字节 13 的值 ) AND ( 2 ) ) == ( 2 )

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


     tcpdump -i xl0 'tcp[13] & 2 == 2'

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

这可以证明为:


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

请注意,您应该在表达式中使用单引号或反斜杠来隐藏 shell 中的 AND ('&') 特殊字符。

UDP 数据包

这个 rwho 数据包说明了 UDP 格式:


 > 广播.who: udp 84

这表示主机actinide上的端口主机广播的端口发送了 UDP 数据报即 Internet 广播地址。该数据包包含 84 字节的用户数据。

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

TCP 或 UDP 名称服务器请求

(注意:以下描述假定您熟悉 RFC 1035 中描述的域服务协议。如果您不熟悉该协议,则以下描述似乎是用希腊语编写的。)

名称服务器请求的格式为

src > dst: id op? 标志 qtype qclass 名称 (len)

h2opolo.1538 > : 3+ A? 。(37)

主机h2opolo向helios上的域服务器询问与名称关联的地址记录 (qtype=A) 。 查询 ID 为“3”。`+' 表示设置了递归所需的标志。查询长度为 37 个字节,不包括 TCP 或 UDP 和 IP 协议标头。查询操作是正常的Query,因此省略了 op 字段。如果 op 是其他东西,它会被打印在 '3' 和 '+' 之间。同样, qclass 是正常的 C_IN,因此被省略。任何其他 qclass 都将在“A”之后立即打印。

检查了一些异常情况,并可能导致方括号中包含额外字段:如果查询包含答案、规范记录或附加记录部分, 则 ancount、 nscount或 arcount 打印为 `[ n a]'、`[ n n ]' 或 `[ n au]' 其中n 是适当的计数。如果设置了任何响应位(AA、RA 或 rcode)或在字节 2 和 3 中设置了任何“必须为零”位,则打印“[b2&3= x ]”,其中x是头字节二和三。

TCP 或 UDP 名称服务器响应

名称服务器响应的格式为

src > dst: id op rcode flags a/n/au type class data (len)

 > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273)
 > h2opolo.1537: 2 NXDomain* 0/1/0 (97)

在第一个示例中,helios 使用 3 条答案记录、3 条名称服务器记录和 7 条附加记录来响应来自h2opolo的查询 id 3 。第一个答复记录是类型 A(地址),其数据是 Internet 地址 128.32.137.3。响应的总大小为 273 字节,不包括 TCP 或 UDP 和 IP 标头。操作(查询)和响应代码(NoError)被省略,A 记录的类(C_IN)也是如此。

在第二个示例中,helios使用不存在域 (NXDomain) 的响应代码响应查询 2,没有答案、一个名称服务器和没有权限记录。`*' 表示已设置权威答案位。由于没有答案,因此没有打印任何类型、类别或数据。

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

SMB/CIFS 解码

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

默认情况下,会进行相当少的解码,如果使用 -v,则会进行更详细的解码。请注意,使用 -va 单个 SMB 数据包可能会占用一页或更多页面,因此如果您真的想要所有血腥细节,请仅使用 -v。

有关 SMB 数据包格式的信息以及所有字段的含义,请参阅 Index of /pub/samba/specs和其他在线资源。SMB 补丁由 Andrew Tridgell ( tridge@ ) 编写。

NFS 请求和回复

Sun NFS(网络文件系统)请求和回复打印为:

 > :NFS 请求 xid xid len op args 
 > :NFS 回复 xid xid 回复 stat len op 结果


sushi.1023 > : NFS 请求 xid 26377
        112 读取链接 fh 21,24/10.73165
 > sushi.1023:NFS 回复 xid 26377
        回复 ok 40 读取链接“../var”
sushi.1022 > : NFS 请求 xid 8219
        144 查找 fh 9,74/4096.6878 “xcolors”
 > sushi.1022:NFS 回复 xid 8219
        回复 ok 128 查找 fh 9,74/4134.3150


在第一行中,主机sushi 向wrl发送一个 id为26377的事务。请求为 112 字节,不包括 UDP 和 IP 标头。该操作是文件句柄 ( fh ) 21,24/10.731657119的 读取链接(读取符号链接) 。(如果幸运的话,在这种情况下,文件句柄可以解释为主要、次要设备号对,后跟索引节点号和世代号。)在第二行,wrl用相同的事务回复“ok” id 和链接的内容。

在第三行中,sushi要求(使用新的事务 id)wrl在目录文件 9,74/4096.6878 中查找名称“ xcolors ”。在第四行,wrl发送一个带有相应事务 id 的回复。

请注意,打印的数据取决于操作类型。如果与 NFS 协议规范一起阅读,则该格式旨在自我解释。另请注意,旧版本的 tcpdump 以稍微不同的格式打印 NFS 数据包:将打印事务 id (xid) 而不是数据包的非 NFS 端口号。

如果给出 -v(详细)标志,则打印附加信息。例如:



sushi.1023 > : NFS 请求 xid 79658
        148 读取 fh 21,11/12.195 8192 字节 @ 24576
 > sushi.1023:NFS 回复 xid 79658
        回复 ok 1472 读取 REG 100664 ids 417/0 sz 29388


(-v 还打印 IP 标头 TTL、ID、长度和分段字段,这些字段已在本示例中省略。)在第一行中, sushi要求wrl从文件 21,11/12.195 中读取 8192 个字节,位于字节偏移处24576. Wrl回复‘ok’;第二行显示的数据包是回复的第一个片段,因此只有 1472 字节长(其他字节将在后续片段中跟随,但这些片段没有 NFS 甚至 UDP 标头,因此可能不会打印,取决于使用的过滤器表达式)。因为给出了 -v 标志,所以打印了一些文件属性(除了文件数据之外还返回):文件类型(``REG'',用于常规文件),文件模式(八进制), UID 和 GID 以及文件大小。

如果多次给出 -v 标志,则会打印更多详细信息。

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

AFS 请求和回复

Transarc AFS(安德鲁文件系统)请求和回复打印为:

 > : rx 数据包类型
 > : rx 数据包类型服务调用名称参数
 > : rx 数据包类型服务回复调用名称参数


elvis.7001 > :
        rx data fs call rename old fid 536876964/1/1 "."
        新的 fid 536876964/1/1 “.newsrc”
 > elvis.7001:rx 数据 fs 回复重命名


在第一行中,主机 elvis 向 pike 发送一个 RX 数据包。这是到 fs(文件服务器)服务的 RX 数据包,并且是 RPC 调用的开始。RPC 调用是重命名,旧目录文件 id 为 536876964/1/1,旧文件名 `.',新目录文件 id 536876964/1/1 和新文件名`。新闻频道”。主机 pike 以 RPC 回复来响应重命名调用(这是成功的,因为它是一个数据包而不是一个中止包)。

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

该格式旨在进行自我描述,但对于不熟悉 AFS 和 RX 工作原理的人可能没有用处。

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

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

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

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

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

KIP AppleTalk(UDP 中的 DDP)

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

号码名称

1.254 以太币
16.1 ICSD 网
1.254.110 王牌

前两行给出了 AppleTalk 网络的名称。第三行给出特定主机的名称(主机与网络的区别在于数字中的第 3 个八位位组 - 网络号必须有两个八位位组,主机号必须 有三个八位位组。)数字和名称应该分开通过空格(空格或制表符)。/etc/ 文件可能包含空行或注释行(以“#”开头的行) 。

AppleTalk 地址以表格形式打印

网络主机端口

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

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

NBP(名称绑定协议)和 ATP(AppleTalk 事务协议)数据包对其内容进行解释。其他协议只是转储协议名称(或数字,如果没有为协议注册名称)和数据包大小。

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


icsd-net.112.220 > jssmag.2:nbp-lkup 190:“=:LaserWriter@*”
jssmag.209.2 > icsd-net.112.220:nbp 回复 190:“RM1140:LaserWriter@*”250
techpit.2 > icsd-net.112.220:nbp 回复 190:“techpit:LaserWriter@*”186

第一行是由 net icsd 主机 112 发送并在 net jssmag 上广播的激光写入器的名称查找请求。查找的 nbp id 是 190。第二行显示来自主机 jssmag.209 的对该请求的回复(注意它具有相同的 id),说明它在端口 250 上注册了一个名为“RM1140”的激光写入器资源。第三该行是对同一请求的另一个回复,称主机 techpit 已在端口 186 上注册了激光写入器“techpit”。

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


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

Jssmag.209 通过请求最多 8 个数据包(“<0-7>”)向主机 helios 发起事务 id 12266。行尾的十六进制数是请求中“userdata”字段的值。

Helios 以 8 512 字节的数据包响应。事务 id 后面的 `:digit' 给出了事务中的数据包序列号,括号中的数字是数据包中的数据量,不包括 ATP 标头。数据包 7 上的“*”表示 EOM 位已设置。

Jssmag.209 然后请求重新传输数据包 3 和 5。Helios 重新发送它们,然后 jssmag.209 释放交易。最后,jssmag.209 发起下一个请求。请求中的“*”表示设置 XO(“恰好一次”)。