LibPcap丢包怎么办
最近有很多都跟小编反映LibPcap丢包的情况,那么LibPcap丢包怎么办呢?
我们要如何去解决,那么我们现在就跟小编一起去看看LibPcap丢包的具体解决方法,想了解的朋友们一起跟小编去看看吧。
环境描述:Snapgear-3.5.0 / kernel: linux-2.6.x / uClibc / Module: XSCALE/Intel IXP400 / LibPcap-0.9.2 / Snort-2.6.1.1
测试过程:先将板子设置成透明网桥模式,再让Snort工作在日志记录模式下(snort –A none -N),然后由eth1(PC1)->eth2(PC2)跑Chariot TCP/High_Performance,此时平均速度约为93Mbps,最后跑完整个脚本中断Snort,显示Dropped: ≈86%。丢包率如此骇人,于是我不得不踏上调查征程。
进入snapgear/user/snort/src,打开until.c找到Dropped出处DropStats(),发现“Snort received”和“Dropped”均通过pcap_stats()得来,因此我觉得事情有些不妙了。
上网查找资料,有不少叙述关于LibPcap丢包问题的文章,其中《Improving Passive Packet Capture: Beyond Device Polling》(可在http://luca.ntop.org/中找到)这篇文章叙述得很清楚。但各位先行者所讲的就是我碰到的问题吗?不行,我得看看。
接着我注释掉了snapgear/user/snort/src/snort.c/OpenPcap()中的pcap_setfilter(),再次测试,结果一样。于是我再让snapgear/user/snort/src/snort.c/PcapProcessPacket()直接return,再测试,结果并无改观。我失望了,难道非得让我去看LibPcap吗?没办法,看就看吧。
进入snapgear/lib/libpcap/一路查找,终于发现pcap_stats()链着下面pcap-linux.c中的pcap_stats_linux(),阅读了下面一大段注释,再debugging确定,天呀,难道要我去看kernel吗?“投之亡地而后存,陷之死地然后生”,我已经走上这条路了。
没有多想,按注释直接全文通缉“tp_drops”,在snapgear/linux-2.6.x/net/packet/af_packet.c packet_rcv()中抓住了它。怀疑问题出在:
if (atomic_read(&sk->sk_rmem_alloc) + skb->truesize >=
(Unsigned)sk->sk_rcvbuf)
goto drop_n_acct;
debugging证明了怀疑的正确性,并发现sk_rmem_alloc会突然降为零。那么为什么会出现sk_rmem_alloc不够用呢?为此,我不得不弄清楚正常情况下sk_rmem_alloc是怎么被释放的。atomic_read()该死的原子操作,我还不得不感谢它,因为在查看它的时候发现了它的兄弟atomic_sub()并最终找到了sock_rfree()大人,debugging证明sk_rmem_alloc确实是由这位大人释放的。那什么时候这位大人才会露面呢?我真的对Linux认识太少了,惭愧呀!
正因为见识少,所以才容易才发现许多惊奇:天呀,原来这么多内联函数都被定义在了头文件中呀。sock_rfree()便是通过snapgear/linux-2.6.x/include/net/sock.h中的static inline void skb_set_owner_r(struct sk_buff *skb, struct sock *sk)挂在了skb->destructor上。通过最笨拙的办法,继续查找destructor,终于确定了__kfree_skb()并踩到了更浅的支点kfree_skb(),事实证明,愚蠢的人自作聪明的后果往往令人惨不忍睹——可爱的kfree_skb()漫山遍野。我该怎么办呀?甚至有点后悔自己潜水太深了。冷静冷静,再找新的突破口吧。
干脆由pcap_open_live()出发,看看这个handle怎么得来,socket如何被创建的。碰到了socket(),于是我再次冲进kernel,可是找来找去都没socket()的原型,我再次迷惑——坦白,此前我根本不知道系统调用这档子事。查找资料,又是他——九贱,真真感谢这位大哥,在此推荐下他的论坛http://www.skynet.org.cn/。在他的“Linux内核探索”版块中有关于socket()的介绍。snapgear/linux-2.6.x/net/socket.c中的sys_socketcall()是与socket有关的所有系统调用的入口,这个文件中定义了许多socket系统调用,我也是在这里找到了sys_socket()并确认LibPcap中创建socket便是通过这个函数实现的。当我寻访到__sock_create()时,又发现此处烟波浩淼,真的是伤心透了。一时半会是看不明白的了,扭头。
既然pcap_open_live()巷子太深,那么我再从pcap_dispatch()突破。追踪到snapgear/lib/libpcap/pcap-linux.c中的pcap_read_packet(),发现在callback()调用用户程序前是通过recvfrom()取得包的。郁闷,又找不到原型,又是系统调用。再次感谢九贱,还有《UDP Socket Creation》的作者,正是看了他们的文章,sk->sk_prot->recvmsg才被锁定。遍地找寻了recvmsg,再根据LibPcap创建Socket时选用的类型SOCK_RAW,snapgear/linux-2.6.x/net/ipv4/raw.c中的raw_recvmsg()被相中了,因为它的老家struct proto raw_prot[]所在的老窝snapgear/linux-2.6.x/net/ipv4/af_inet.c中static struct inet_protosw inetsw_array[]的.ops所指向的inet_dgram_ops.recvmsg正好等于sock_common_recvmsg。欢呼——高兴得太早了,debugging确认时令我失望了,snapgear/linux-2.6.x/net/socket.c sys_recvfrom()调用sock_recvmsg()调用__sock_recvmsg()时,sock->ops->recvmsg更多时候并不等于sock_common_recvmsg,一团迷雾骤然升起——天呀!
我深切地观望着packet_rcv()。我找不到更好的突破口了,就拿recvmsg当救命稻草了,再次搜寻recvmsg,终于,终于在snapgear/linux-2.6.x/net/packet/af_packet.c中发现了.recvmsg=packet_recvmsg。Debugging,打印函数地址,确认!更喜人的是在packet_recvmsg()中发现了最终出口skb_free_datagram(),snapgear/linux-2.6.x/net/core/datagram.c中的它显示它直接返回kfree_skb()。Debugging确认!
至此,LibPcap捕获数据包的出入口已经找到了,之前赘述,无非是展现本人在寻找这两扇大门时的经过,以及犯下的愚蠢错误,旨在告诫与我一样还不了解Linux的朋友不要重蹈我的覆辙,也希望广大高手能够不吝赐教。
总结:LibPcap通过pcap_open_live()系统调用socket()创建一个socket.而系统调用socket()则是通过sys_socketcall()这个入口找到sys_socket()->sock_create()->__sock_create()->rcu_dereference(net_families[family])根据协议簇执行create。LibPcap选用的协议簇PF_PACKET通过af_packet.c中的packet_init()调用snapgear/linux-2.6.x/net/socket.c中的sock_register()被初始化注册进net_families[],其.create=packet create。因此LibPcap创建socket最终调用了packet_create(),在packet_create()中创建了sk并有sock->ops = &packet_ops; po->prot_hook.func=packet_rcv;而static const struct proto_ops packet_ops.recvmsg=packet_recvmsg,这便是用户程序通过LibPcap从socket取得数据包的入口。因此用户程序通过LibPcap获取数据包的整个过程可以简易描述为:由packet_rcv()接收来自底层的包(具体什么位置,我没有搞明白),并分配出一段buffer,在sk_receive_queue资源不足以再容纳下一段数据时,直接将数据丢弃kfree_skb(),并记录tp_drops(即我们通过pcap_stats()得到的ps_drop);而用户程序则是不时调用packet_recvmsg()从队列中一次性获取数据,并最后释放资源skb_free_datagram()。
其实到这里,我还未交代主题,那么导致LibPcap丢包的原因在哪里呢?了解了LibPcap捕获数据包的过程再来查找就没那么茫然了,debugging发现packet_recvmsg()的执行频度远小于packet_rcv(),所以在packet_rcv()接收数据并充盈sk_rmem_alloc后,packet_recvmsg()并不能及时将其清空,在这个时间差中只能丢包了。那么为什么packet_recvmsg()执行的频度不够呢?这可能是更底层的问题,限于能力,我在此无法给出解释。