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》（可在中找到）这篇文章叙述得很清楚。但各位先行者所讲的就是我碰到的问题吗？不行，我得看看。

　　接着我注释掉了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()的原型，我再次迷惑——坦白，此前我根本不知道系统调用这档子事。查找资料，又是他——九贱，真真感谢这位大哥，在此推荐下他的论坛。在他的“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()执行的频度不够呢？这可能是更底层的问题，限于能力，我在此无法给出解释。

　　再谈谈怎么解决这个问题。由于底层的原因我不得而知，所以我只能对我所了解的做出调整了——加大sk_rmem_alloc，利用其空间来容纳packet_rcv()的积极动作，但这个做法是以牺牲速度为代价的。在本人的测试环境中，启用snort中提供的所有rule，将sk_rmem_alloc扩至10M（echo 10485760 > /proc/sys/net/core/rmem_default && echo 10485760 > /proc/sys/net/core/rmem_max）能保证Dropped: 0.00%，但此时平均速度降至≈16Mbps。

　　结束语：此文是本人对此问题进行查寻的笔记，走了很多弯路，如果有朋友也在关心此问题，那么不妨以本人为一反面材料，并希望读者能对文中谬误之处提出批评并指正。既然走了这么多弯路，当然浪费了大量宝贵时间，十分感谢我们老大在此过程中对我提供的大量帮助和对我所持的极大耐心。这些都是我决定写下本文的原因。