LibPcap丢包问题

最新推荐文章于 2022-03-01 16:33:47 发布

wfqxx

最新推荐文章于 2022-03-01 16:33:47 发布

阅读量2.6k

点赞数

分类专栏： TCP/IP linux 文章标签： debugging socket struct destructor linux内核测试

linux 同时被 2 个专栏收录

13 篇文章 0 订阅

订阅专栏

TCP/IP

7 篇文章 0 订阅

订阅专栏

http://yuzhu428.spaces.live.com/blog/cns!C75B8C7D675DDD53!207.entry

这段时间查看了下 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. r ecvmsg=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 。