上篇组播分片报文重组后丢包问题，分析到最后是接口eth0和eth1在同一个广播域，且两个接口都处于混杂模式导致。解决方案是关闭接口的混杂模式。

kmalloc-128 slab内存泄漏定位过程问题现象进展受阻现网排查分析coredump后记问题现象前几天，技术团队告知，线上几台ARM CentOS设备内存占用高，比其他相同设备占用高约200M。查看 free，meminfo和slabinfo后，怀疑是slab kmalloc-128存在内存泄漏。进展受阻我们发现正常设备和内存占用高设备的 kmalloc-128 占用已经超过177万，粗算下来200多M，刚好是多占用的内存大小。//异常设备的slabkmalloc-128

为了便于定位内存问题，使用/proc/meminfo中的一些关键变量值，来计算用户态内存占用，内核态内存占用（包含slab占用和vmalloc占用等），以及黑洞内存占用。(详见内存泄漏定位思路与方法)。公司技术同事使用该方法定位了很多项目内存问题。今天技术同事说有个设备内存占用很高，使用定位方法发现存在隐形内存。我登录设备初步排查了黑洞内存常见的几个怀疑点，没有发现问题。随后我再次查看meminfo确认，发现了一个奇怪的现象。[root@localhost ~]# cat /proc/meminfo

交叉编译tcpreplay前言下载tcpreplay源码配置编译环境前言二级目录三级目录前言最近项目上出现个问题，其中一个报文发出去后，在互联网中被丢包。后续的重传也被丢包。因为该连接只有该数据包被丢弃，前面和后面的数据包都正常传送。怀疑是该报文被网络中某个设备拦截并丢弃。为了验证猜想，准备对被丢弃的报文进行重放测试。设备是arm64的openwrt定制系统，需要交叉编译tcpreplay。在编译过程中颇费了一些周章，所以记录下踩过的这些雷，希望能够帮助到有同样困扰的人。下载tcpreplay源码

定制业务程序prog，在客户设备上运行后出现Segmentation fault。