LibPcap经常丢包怎么办?

最近经常遇到LibPcap丢包的情况,那么LibPcap丢包怎么办呢?我们要如何去解决,那么我们现在就跟小编一起去看看LibPcap丢包的具体解决方法,想了解的朋友们一起跟小编去看看吧。  测试过程:先将板子设置成透明网桥模式,再让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的朋友不要重蹈我的覆辙,也希望广大高手能够不吝赐教。

追加问题
    3 人参与回答

不懂,帮不了你。

柠檬可乐
柠檬可乐 · 2021年祝搜外的-每一位大哥大嫂过年好▄█▀█●——帮小弟点一下—▄█▀█●——感激不尽——▄█▀█●☛☛☛☛☛☛

不懂,不好意思

SEO培训招生中
153