本文主要是介绍【C语言踩坑】PCAP发送ARP包之 --多出的字节,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
PCAP发送ARP包之多出的字节
-------------------------------------------------------------------------------------------------------------------
最近接触了一些计算机网络的底层协议,试着做了一个发送和接收ARP报文的demo,刚开始没注意,后来使用wireshark抓包才发现,发送出去的arp包全是无效的,难怪局域网中没有主机响应。我百度了数篇讲解ARP发包的博客,没有一个发现这个问题的,有的甚至就是直接复制的别人的源码。
-------------------------------------------------------------------------------------------------------------------
问题出现的根源在于cpu的内存优化策略,关于内存优化的详细解释你们可以看一下这篇博客https://blog.csdn.net/cyousui/article/details/17655051?utm_source=blogxgwz2
-------------------------------------------------------------------------------------------------------------------
构造的ARP包结构如图
图中标明了初始化的数据
按理说发送的数据应该能被解析为一个arp广播请求,但是实际就是如下图的状况
很明显,报文无法被解析,但是能被判定为是一个arp报文,图中也可以清楚看出,目的mac地址和源mac地址以及协议类型都能被正确识别,但是值本应该是0001的arp操作类型字段却变成了0000,。是初始化出错了吗?仔细看这段报文的十六进制编码,你会发现,在08 06 00 00后面就有00 01的编码,而且后面的编码和初始化的数据一致,只是在本地mac地址编码后面又多出了两个00 00,从这里可以得出结论:00 00这个编码是被强行加进来的,并不是读取错误导致的。
但是这两字节的数据时怎么被加进去的呢?看下面这张程序运行时的内存值图你就清楚了。
这是我在arp包刚初始化结束的断点查看到的内存分布图,这说明,我在初始化后数据就已经被加了两字节的00数据。而罪魁祸首就是内存对齐和补齐策略,因为我是创建的32位程序,所以默认的是4bit补齐。因为arp包中的第三个字段结束后才14bit,所以系统就自动加了2bit的数据补齐16bit,使之变成4的整数倍。
既然问题找到了,那解决办法就好找了。
直接在代码的开头声明 按照1bit对齐就能解决这个问题。
#pragma pack(push) // 保持对齐方式
#pragma pack(1) // 设定1位对齐
-------------------------------------------------------------------------------------------------------------------
设置以后的内存分布图是这样的
没有多余的数据了
-------------------------------------------------------------------------------------------------------------------
wireshark抓取的arp正确报文是这样的
实践出真知,国内就是喜欢抄袭,你好歹把错误改正下吧,真的是害人。我查这个错误查了一天。。。。
这篇关于【C语言踩坑】PCAP发送ARP包之 --多出的字节的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!