关于一块网卡收包，另一块网卡转发数据包的问题

shank941

回复 9# Arm_Linux_boy


    看你描述的现象，个人猜测应该原因可能是这样：

   1.由于引用计数不对，有增加引用计数，但没减少的地方，因此出现内存泄漏。
   2.由于你强制将skb的引用计数清0，并直接kfree了skb，而其他模块本来对这个skb有引用计数的，因此这部分内存可能会重入，小流量时不一定冲突，
大流量时就产生冲突了，导致这里同步访问的内存可能异常。


正常报文发送后skb的释放，应该是通过网卡发送完成的中断来触发的，此时会去释放skb，正常时候skb的引用计数应该是1，此时正好释放掉了这个buffer。
建议先看看不改引用计数，引用计数为什么没减成0，为什么内存没释放掉，不用大流量，加个打印看看就行了，应该引用计数是有增有减的，没有你这样直接set 0这么玩的。。。

Arm_Linux_boy

回复 10# Godbach
还有一个现象就是当调用dev_queue_xmit来发送skb的时候，如果把网线拔掉也就是现在的网卡状态是down的时候，电脑不死机，然后插上也不会死机程序继续正常工作。但是插上网线即网卡up就会死掉

Godbach

down 的估计就没有触发发包的程序，当然不会死机了。
应该就是你的 skb 处理的有问题，导致调用 dev_queue_xmit 出问题。

Godbach

对了，你可以这样测试一下：
用个 Netfilter 的 hook 函数，在这个里面拦截数据包，然后修改一下数据包，从另外一个网口转发出去。这样可以做成模块的方式，便于调试。

BTW，你的实际需求是什么

Arm_Linux_boy

回复 14# Godbach
我是网卡的驱动层直接抓的包，在网卡驱动准备调用netif_receive_skb(old_skb);
将数据包发送到协议栈之前被我截下，然后我使用
skb_push(old_skb, SIZE_ETHERNET);       
struct sk_buff *skb = skb_copy(old_skb, GFP_ATOMIC);
然后我再调用dev_queue_xmit发送也是会死机的

我的需求就是现在将A网卡收到的数据包直接从B网卡发走

Arm_Linux_boy

回复 13# Godbach
那么SKB怎么处理？我之前收到数据包的时候，会将数据包交给应用程序检测下，然后再交给驱动程序由B网卡发走，这时候是没有问题的，不会死机

Godbach

感觉你说的不清楚。
你的数据包不是到了网卡驱动需要直接转发给另外一个网口吗。怎么还有交给应用层程序检测啊

Godbach

回复 16# Arm_Linux_boy


    NF 收到 skb，修改一下 skb，调用 dev_queue_xmit 发出去，并且给 NF  返回一个 NF_STOLEN 即可

Arm_Linux_boy

Netfilter我没有使用过，我们现在在做一个检测数据包协议的东西。数据数据包收到后需要交给应用程序检测，但有时候应用程序还没有开启的情况下就需要直接将数据包从另外一块网卡转发走。所以整个过程都是驱动程序里面添加模块来实现这些功能的

dreamice

图中那个发出来是一个表情的，其实是数字8
Arm_Linux_boy 发表于 2011-03-07 16:50

    发帖的时候，左边选择“禁用 Smilies”就可以解决这个问题了