wireshark使用过程无法抓取前序和FCS或出现IP报头校验和错误--原因

1.为什么wireshark抓不到帧尾的FCS 4字节和以太网V2的前序8字节

在物理层上网卡要先去掉前导同步码和帧开始定界符，然后对帧进行CRC检验，如果帧校验和错，就丢弃此帧。如果校验和正确，就判断帧的目的硬件地址是否符合自己的接收条件（目的地址是自己的物理硬件地址、广播地址、可接收的多播硬件地址等），如果符合，就将帧交“设备驱动程序”做进一步处理。这时我们的抓包软件才能抓到数据，因此，抓包软件抓到的是去掉前导同步码、帧开始分界符、FCS之外的数据。

检验和算法可以分成两步来实现。首先在发送端，有以下三步：

1. 把即将发送的IP头部中的检验和设置为0，然后以16位为一个间隔，将IP头部分成许多个16位的字段；
2. 将第1步获得的所有字段进行二进制相加求和；
3. 把最终结果取反，就得到检验和，再将该值填充到IP头部。

　　　　其次在接收端，也有相应的三步：

1. 把接收到的IP头部分成16位一个间隔的字段集合；
2. 所有字段进行二进制相加求和；
3. 将最终结果取反，判断该结果是否为0，若为0，则说明检验和正确，若不为0，则协议栈会丢掉这个包。（你没看错，这一步还是要取反）

 

 

　　　上面的步骤，很抽象，也很无聊。一起来看一个例子。

　　0                       1                        2                        3  

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 (32位，4字节）

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |　4　　|　5　　|　　　0　　　　|　　　　　28　　　　　　　|

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |　　　　　　　　1　　　　　　|　　　0　　　|　　0　　　　　|

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |　　　　4　　|　　　　17　　|　　　　0(checksum)　　　　　　|

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                       10.12.14.5                                                                  |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                    12.6.7.9                                                                        |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

　　　 这是典型的IP报头，其中各个字段的值都已经设置了。检验和先设为0。

　　　 使用二进制或者十六进制来计算它的检验和。

　　　　　　4,5,0--> 0100 0101 0000 0000

　　　　　　28 --> 0000 0000 0001 1100

　　　　　　1  -->  0000 0000 0000 0001

　　　　　　0,0-->0000 0000 0000 0000

　　　　　　4,17-->0000 0100 0001 0001

　　　　　　0    -->0000 0000 0000 0000

　　　　　　10.12-->0000 1010 0000 1100

　　　　　　14.5-->0000 1110 0000 0101

　　　　　　12.6-->0000 1100 0000 0110

　　　　　　7.9-->0000 0111 0000 1001

　　　　　　和-->0111 0100 0100 1110(744E，十六进制)

　　　　对上面的求和取反，就得到检验和，为8BB1，那么就在IP首部将16位检验和设置为8BB1。

　　　 假设数据包是完整的，接收端相应地进行操作，8BB1+744E，就得到了FFFF，取反则为0，所以验证了数据包没有被污染。

CRC----------------16 bit字的二进制反码和

1.在计算UDP校验和的时候要多加个伪UDP头的值。

I P首部的检验和，它只覆盖I P的首部—并不覆盖I P数据报中的任何数据。

U D P和T C P在首部中都有覆盖它们首部和数据的检验和。U D P的检验和是可选的，而T C P的检验和是必需的。

1.首先， U D P数据报的长度可以为奇数字节，但是检验和算法是把若干个16 bit字相加。解决方法是必要时在最后增加填充字节0，这只是为了检验和的计算（也就是说，可能增加的填充字节不被传送）。

2.其次， U D P数据报和T C P段都包含一个1 2字节长的伪首部，它是为了计算检验和而设置

的。伪首部包含I P首部一些字段。其目的是让U D P两次检查数据是否已经正确到达目的地