协议解析Bug分析

       源自邮件协议RPC（远程过程调用）处理的Request请求数据包的bug。

       一、Bug描写叙述

       腾讯收购的Foxmailclient能够作为outlookclient的替代品与Exchange服务端进行交互完毕邮件收发。而我们所要做的就是让邮件经过我们代理的优化处理。

       这时候问题来了，Outlookclient经由我们代理没有不论什么问题；可是换成Foxmail就会有错误弹窗。错误号：0x000006BE。

可是假设不经过代理，Foxmail收发邮件一切正常。

       非常明显，是代理出了问题。

       二、不知道怎样排查？

       又是面对不熟悉的6万行以上的代码，又是不熟悉的框架，又是文档混杂。又是项目进度很赶……

       还好是必现的环境，还好还有日志、还有wireshark的分析。

       初始的时候因为不知道虚拟机开启了混杂模式，导致wireshark抓的数据包有大量的Retransmit数据包以及非常多out of order（失序）数据包。所以抓住的点是某个包被重传了两次，然后找日志哪个包重传了两次？

        因为日志里确实没有找到重传数据包，再来怀疑之前的分析？这才找到了混杂模式导致了误分析。

特将混杂模式和普通模式定义列举例如以下：

        混杂模式就是接收全部经过网卡的数据包，包含不是发给本机的包。即不验证MAC地址。

普通模式下网卡仅仅接收发给本机的包（包含广播包）传递给上层程序，其他的包一律丢弃。

一般来说，混杂模式不会影响网卡的正常工作，多在网络监听工具上使用。

        三、根本原因

        最后思路还是结合日志分析抓包，看到对于RPC的请求数据包（request）的加密数据长度和日志打印不一致，顺着代码去读，发现是Foxmail较outlook多了一个比特标记位置为1（此为根本原因），导致多出了表示回话UUID的16个字节的数据。在数据处理中取长度和取数据段结构体赋值的时候导致偏移出错。

       四、阶段小结

       尽管找到偏移出错的根本原因，可是要彻底解决bug还有非常长的路要走。代理中有几十处能搜到的和偏移有关的数据项。有些变量不能见名识意，还须要跟读代码逻辑。

       深刻体会到协议解析常犯的两个错误：

        1）对于协议的解析。马虎不得。偏移一个比特可能剩余的解析会所有出错；

        2）协议解析有些字段或者标记位是可选项，比方大多是情况用户不去选择则该字段就没有意义。

可是作为程序猿的我们要考虑到一旦用户选择的情况，做好分支判定处理。

协议解析必须严格參考协议文档，考虑相当全面，马虎不得。

        2014-10-26 pm8:39思于家中床前

作者：铭毅天下

转载请标明出处，原文地址：http://blog.csdn.net/laoyang360/article/details/40480235

假设感觉本文对您有帮助，请点击‘顶’支持一下，您的支持是我坚持写作最大的动力，谢谢！