编写ringBuff过程中遇到的一次bug

Posted 我要出家当道士

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了编写ringBuff过程中遇到的一次bug相关的知识,希望对你有一定的参考价值。

问题描述

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

    最近在隧道项目的开发过程中遇到了一个奇怪的bug,如上图,在网关C InBound模块中收到了D主机发送给主机A的数据包(解密成功后查出),按照代码逻辑C InBound中收到的所有包都是网关B OutBound模块转发而来的,这些包肯定是B发过来的。设计中网关用户侧使用的是af_packet抓的包,之后进入OutBound转发给目标主机所在的网关,进入其InBound模块进行解封装、解密与转发,而且所有网关部署了转发策略(依据五元组),网关B的策略只允许A->D的包出去,网关C的策略只允许D->A的包出去,进来的包不受限。所以网关C解密得到D->A的包很奇怪。网关两侧都使用了我自己编写的RingBuff,由于开发语言使用的go,配合channel很容易实现RingBuff。

问题分析

    通过抓包发现,网关B的OutBound模块之所以转发D->A的数据包是因为网关B用户侧的af_packet不仅仅抓取了用户A的数据包还抓了网关B发往用户A的包,所以会出现这种现象,解决的办法是,设置BPF,控制af_packet抓包的方向,只抓取InBound的包。策略失效的原因是因为RingBuff空间被无用包侵吞。在设计RingBuff的时候,定义RingBuff的长度为(channelLen + 1) * threadNum * frameSize,OutBound抓取一个包就轮询的分配给worker线程,但当出现杂包之后这个空间明显就不够用了。所以得严格按照生产一个包消费一个包来编写代码,对于杂包要约束其固定在一个buff里,待出现有用包之后再移动buffIndex。


    自然怜幽草,人间爱晚晴。

以上是关于编写ringBuff过程中遇到的一次bug的主要内容,如果未能解决你的问题,请参考以下文章

优化器Bug?记一次慢SQL问题分析过程

接口测试:如何定位BUG的产生原因

记一次netty追源码找bug过程

接口测试:如何定位BUG的产生原因

软件测试第一次作业

恐怖!ThreadLocal引起的一次线上事故