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()。