本文主要是介绍【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包之 --多出的字节的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
