Linux 杂项，记录Linux 下的一些点滴心得，以供参考

1. netfilter 看到的skb 报文非线性

问题现象

netfilter 看到的skb 报文非线性，即报文全体并不存在于skb->data 内存空间内，导致我们的应用协议处理故障

详细过程

使用tcpreplay 打包测试，HTTP Get请求包，发现部分报文的skb 非线性，即skb->data_len大于0，详细测试结果如下：


GET 请求包大小743字节(包含二层头)，skb 非线性，L7层协议的内容不在skb 线性内存中


GET response 包大小为344字节，skb 线性。


感觉上igb会按照报文大小作skb 线性非线性处理。

解决方法

在我们的应用协议处理最前面增加skb 线性化过程

遗留问题

大部分网卡都不会将单个报文拆分成非线性的skb，不清楚igb 网卡为何要如此处理，是否可以关闭网卡的某个属性达到skb 线性的效果？

2. 获取内核模块的起始地址和大小

这个问题的原由是处理内核模块panic，串口输出的函数调用栈是错误的，但展现的内存绝对地址是正确的，不过由于不知道内核模块的起始地址，故无法反汇编出出问题的代码位置。

其实过程非常简单，在模块初始化时利用__this_module这个内嵌变量，为struct module结构，其中的module_core为当前模块的起始地址，core_size为模块的大小

3. nginx负载均衡极少部分失效

问题现象

172.18.0.142为nginx接口机，接收插件的请求并转发到业务机处理，172.18.0.77是一台业务机。

观察nginx日志，发现有约1/1000的机率，tcp流转发到业务机出现connect 失败的情况，如此导致nginx负载均衡失效，选择其他业务机进行处理。

 

怀疑原因

172.18.0.142内网发送TCP syn报文时，在内网被丢包，导致connect 失败

云公司内网对TCP syn包可能有丢失，而且只在172.18.0.142这台机器上有限制，但对于icmp报文没有限制

根本原因

 nginx接口机配置错误，其掩码配置成了255.255.255.255，导致所有的报文均通过网关172.18.0.1中转，而云公司网关转发时会有丢包现象(目前尚未找到真正原因)，故出现此现象。将nginx接口机的掩码修改正确，则问题解决

详细步骤

在接口机和业务机上几乎同时抓包100000个，耗时约30秒，由于抓包时刻有非常小的差异，故以下的连接总数会有差异。

接口机172.18.0.142，连接总数8359个，有20个连接都只有一个TCP syn报文，即接口机都没有收到业务机的tcp syn/ack回应

业务机172.18.0.77，连接总数8344个，所有连接的报文数目都大于1，即172.18.0.142上发送出去的20个不同端口的TCP syn，在172.18.0.77上都没有收到。

 

在172.18.0.142上使用模拟python程序，往172.18.0.77上发送TCP syn报文，得到如上同样的结果，即TCP syn报文也会丢失。

 

以上丢包过程中，查看172.18.0.142接口机的物理接口状态，发现在发送队列中没有丢包现象。

 

在172.18.0.142上，往172.18.0.77上发送大速率的ping报文，多次试验也没有丢包。

 

在另一台业务机 172.18.0.76 上使用模拟 python 程序，往 172.18.0.77 上发送同样的 TCP syn 报文，多次试验没有任何丢包。此处可证明业务机 172.18.0.77 接收 TCP syn 报文没有问题。