0%

tcpdump进行ARP抓包

tcpdump进行ARP抓包

在学习《Linux高性能服务器编程》中,看到作者对ARP使用tcpdump进行抓包,所以本着实践出真知、多看多练的道理,也进行抓包,顺带记录一下。

ARP协议的功能是实现网络层地址到任意物理地址的转换,简单理解ARP能够实现从IP地址转化为MAC地址的转化。

arp命令

Linux当中ARP 模块维护一个硬件地址到协议地址映射的缓存,可以通过arp命令或者/proc/net/arp文件查看。

使用arp -a查看

image-20220805152235326

使用/proc/net/arp查看

image-20220805152319586

我们也可以使用arp命令对缓存进行操作。

10.0.4.6这个ip对应的MAC地址进行删除

1
arp -d 10.0.4.6

image-20220805152619382

tcpdump进行ARP抓包

上面arp命令是在云服务器上使用的,在使用tcpdump进行抓包时总是出现一些问题,感觉比不上物理机,所以专门找了个装Ubuntu的物理机进行了抓包测试。其中本机的ip:172.27.27.202,抓包抓的是ping 172.27.27.205的包。

实验过程:

一个窗口输入tcpdump命令—->另一个窗口输入ping命令—->tcpdump命令窗口获得数据包

输入抓包的tcpdump命令

1
sudo tcpdump -ent -c 2 arp

命令的参数介绍

1
2
3
4
5
-e 在每列倾倒资料上显示连接层级的文件头;
-n 不把主机的网络地址转换成名字;
-t 在每列倾倒资料上不显示时间戳记;
-c 抓包的数目
arp 表示只抓arp协议的包

最终抓到的包的结果如下图

image-20220805154805611

总共抓到2个包,一个请求包一个应答包。

第一个数据包中,ARP通讯的源端的物理地址为d4:5d:64:d0:4c:5d(本机),目的端的物理地址是ff:ff:ff:ff:ff:ff,这是以太网的广播地址,说明ARP开始是通过广播来询问的。数值0x86是以太网帧头部的类型字段的值,它表示是数据是ARP协议。length 42表示该以太网帧的长度是42字节(实际上是46字节,tcpdump没有统计以太网帧的末尾4字节的CRC字段)。length 28表示以太网帧的数据部分长度为28字节。Request表示这是ARP请求,who-has 172.27.27.205 tell 172.27.27.202就是很直白的”谁有172.27.27.205的MAC地址,请告诉172.27.27.202

第二个数据包中,ARP通讯的源端的物理地址为d2:07:ca:1b:75:58,目的端的物理地址是d4:5d:64:d0:4c:5dlength 60表示该以太网帧的长度是60字节(实际上是64字节,tcpdump没有统计以太网帧的末尾4字节的CRC字段)。length 46表示以太网帧的数据部分长度为46字节(说明ARP应答被填充字节了)。Reply表示这是ARP应答。

疑问

书上说ARP请求的报文为28字节,它属于以太网帧的数据部分,以太网帧的以太网头部+CRC校验的尾部一共18字节,所以一个携带ARP报文的以太网帧至少为46字节,但是由于实现要求以太网帧数据部分的长度至少要46字节,ARP报文此时会填充一些字节,也就是说一个携带ARP报文的以太网帧至少为60字节。这里以太网帧的大小和第二个数据包,也就是ARP应答数据相吻合。

但是第一个数据包ARP请求数据包则不符合设定,它只写了自己ARP请求的报文大小,并未进行字节填充,这里有一些不太理解。

image-20220805165516292