Linux内核IP Queue机制的分析（三）——ip_queue内核模块的分析

Godbach

回复 30# yg_quantum

那你就接着本文的机制分析，看一下怎么改造吧。

感觉应该会比较复杂一些，因为你凭空会多出一个甚至多个报文。


   

yg_quantum

是啊，大师。 这是我的想法：

1  -  用户层收到packet后，对原始数据进行分包。比如将一个包拆为两个包A和B。A包的id就是原始包的id，B包的id可以设定一个特殊值。将A和B依次发送到ip_queue

2  -  ip_queue处理收到的包，先检查包的id，如果是一个特殊值，就去掉从全局的双向链表中查找原有的包的动作，直接放入NF框架；如果不是特殊值，就按照原有流程处理。

大师给看一下，这个可行吗？

Godbach

回复 32# yg_quantum

用特殊 ID 估计不行吧。IP 报文的 id 字段本身就 16bit。 你能找到协议中规定的某个保留不用的 ID 吗，如果都可以使用的话，你应该另外想别的方法了。

其实可以考虑把那个 IP Queue 中的 msg 的信息扩展一下。

至于拆分之后，再让 Netfilter 转发出去，会有什么样的问题，估计都得测试了。

   

yg_quantum

对，大师。

IP Queue在收到用户层返回的IP Queue的包以后，会从全局链表里面查找保存的原始包，我准备改一下IP Queue的接口，就是做个特殊标志，如果是拆分以后的包，就不查找原始包了，直接让Netfilter转发。

菜鸟，不懂这些，大师还有什么好的建议吗

Godbach

回复 34# yg_quantum

没有更多建议了，剩下的就是需要你动手了


   

yg_quantum

好的，大师。验证了以后，把结果通知给大家！

crazyhadoop

高端货啊

hubaohai

mark一下，下次回来看。
上周还自己用netlink实现了一个和 ipq功能类类似的模块(几乎照着ipq的源码写的)，用于硬件抓包向用户态传输数据的。
感觉丢包的概率比tcpdump高，大师能分析下原因吗。

Godbach

回复 38# hubaohai

tcpdump 是旁路模式，而 IP Queue 是直接拦截报文的，要给出处理意见，并 reinject 回去。

   

hubaohai

我的目标就是做一个抓包工具。
不过从内核态向用户态传输数据采用类似ip queue 的netlink的使用方式。
之后也做了inject功能。
我的一是netlink的丢包概率比tcpdump要高一点。

Godbach 发表于 2014-04-17 22:59
回复 38# hubaohai

tcpdump 是旁路模式，而 IP Queue 是直接拦截报文的，要给出处理意见，并 reinject  ...