最近有很多都跟小編反映LibPcap丟包的情況，那么LibPcap丟包怎么辦呢？我們要如何去解決，那么我們現(xiàn)在就跟小編一起去看看LibPcap丟包的具體解決方法，想了解的朋友們一起跟小編去看看吧。

　　環(huán)境描述：Snapgear-3.5.0 / kernel: linux-2.6.x / uClibc / Module: XSCALE/Intel IXP400 / LibPcap-0.9.2 / Snort-2.6.1.1

　　測試過程：先將板子設(shè)置成透明網(wǎng)橋模式，再讓Snort工作在日志記錄模式下（snort –A none -N），然后由eth1(PC1)->eth2(PC2)跑Chariot TCP/High_Performance，此時平均速度約為93Mbps，最后跑完整個腳本中斷Snort，顯示Dropped: ≈86%。丟包率如此駭人，于是我不得不踏上調(diào)查征程。

　　進入snapgear/user/snort/src，打開until.c找到Dropped出處DropStats()，發(fā)現(xiàn)“Snort received”和“Dropped”均通過pcap_stats()得來，因此我覺得事情有些不妙了。

　　上網(wǎng)查找資料，有不少敘述關(guān)于LibPcap丟包問題的文章，其中《Improving Passive Packet Capture: Beyond Device Polling》（可在http://luca.ntop.org/中找到）這篇文章敘述得很清楚。但各位先行者所講的就是我碰到的問題嗎？不行，我得看看。

　　接著我注釋掉了snapgear/user/snort/src/snort.c/OpenPcap()中的pcap_setfilter()，再次測試，結(jié)果一樣。于是我再讓snapgear/user/snort/src/snort.c/PcapProcessPacket()直接return，再測試，結(jié)果并無改觀。我失望了，難道非得讓我去看LibPcap嗎？沒辦法，看就看吧。

　　進入snapgear/lib/libpcap/一路查找，終于發(fā)現(xiàn)pcap_stats()鏈著下面pcap-linux.c中的pcap_stats_linux()，閱讀了下面一大段注釋，再debugging確定，天呀，難道要我去看kernel嗎？“投之亡地而后存，陷之死地然后生”，我已經(jīng)走上這條路了。

　　沒有多想，按注釋直接全文通緝“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證明了懷疑的正確性，并發(fā)現(xiàn)sk_rmem_alloc會突然降為零。那么為什么會出現(xiàn)sk_rmem_alloc不夠用呢？為此，我不得不弄清楚正常情況下sk_rmem_alloc是怎么被釋放的。atomic_read()該死的原子操作，我還不得不感謝它，因為在查看它的時候發(fā)現(xiàn)了它的兄弟atomic_sub()并最終找到了sock_rfree()大人，debugging證明sk_rmem_alloc確實是由這位大人釋放的。那什么時候這位大人才會露面呢？我真的對Linux認識太少了，慚愧呀！

　　正因為見識少，所以才容易才發(fā)現(xiàn)許多驚奇：天呀，原來這么多內(nèi)聯(lián)函數(shù)都被定義在了頭文件中呀。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上。通過最笨拙的辦法，繼續(xù)查找destructor，終于確定了__kfree_skb()并踩到了更淺的支點kfree_skb()，事實證明，愚蠢的人自作聰明的后果往往令人慘不忍睹——可愛的kfree_skb()漫山遍野。我該怎么辦呀？甚至有點后悔自己潛水太深了。冷靜冷靜，再找新的突破口吧。

　　干脆由pcap_open_live()出發(fā)，看看這個handle怎么得來，socket如何被創(chuàng)建的。碰到了socket()，于是我再次沖進kernel，可是找來找去都沒socket()的原型，我再次迷惑——坦白，此前我根本不知道系統(tǒng)調(diào)用這檔子事。查找資料，又是他——九賤，真真感謝這位大哥，在此推薦下他的論壇http://www.skynet.org.cn/。在他的“Linux內(nèi)核探索”版塊中有關(guān)于socket()的介紹。snapgear/linux-2.6.x/net/socket.c中的sys_socketcall()是與socket有關(guān)的所有系統(tǒng)調(diào)用的入口，這個文件中定義了許多socket系統(tǒng)調(diào)用，我也是在這里找到了sys_socket()并確認LibPcap中創(chuàng)建socket便是通過這個函數(shù)實現(xiàn)的。當我尋訪到__sock_create()時，又發(fā)現(xiàn)此處煙波浩淼，真的是傷心透了。一時半會是看不明白的了，扭頭。

　　既然pcap_open_live()巷子太深，那么我再從pcap_dispatch()突破。追蹤到snapgear/lib/libpcap/pcap-linux.c中的pcap_read_packet()，發(fā)現(xiàn)在callback()調(diào)用用戶程序前是通過recvfrom()取得包的。郁悶，又找不到原型，又是系統(tǒng)調(diào)用。再次感謝九賤，還有《UDP Socket Creation》的作者，正是看了他們的文章，sk->sk_prot->recvmsg才被鎖定。遍地找尋了recvmsg，再根據(jù)LibPcap創(chuàng)建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()調(diào)用sock_recvmsg()調(diào)用__sock_recvmsg()時，sock->ops->recvmsg更多時候并不等于sock_common_recvmsg，一團迷霧驟然升起——天呀！

　　我深切地觀望著packet_rcv()。我找不到更好的突破口了，就拿recvmsg當救命稻草了，再次搜尋recvmsg，終于，終于在snapgear/linux-2.6.x/net/packet/af_packet.c中發(fā)現(xiàn)了.recvmsg=packet_recvmsg。Debugging，打印函數(shù)地址，確認！更喜人的是在packet_recvmsg()中發(fā)現(xiàn)了最終出口skb_free_datagram(),snapgear/linux-2.6.x/net/core/datagram.c中的它顯示它直接返回kfree_skb()。Debugging確認！

　　至此，LibPcap捕獲數(shù)據(jù)包的出入口已經(jīng)找到了，之前贅述，無非是展現(xiàn)本人在尋找這兩扇大門時的經(jīng)過，以及犯下的愚蠢錯誤，旨在告誡與我一樣還不了解Linux的朋友不要重蹈我的覆轍，也希望廣大高手能夠不吝賜教。

　　總結(jié)：LibPcap通過pcap_open_live()系統(tǒng)調(diào)用socket()創(chuàng)建一個socket.而系統(tǒng)調(diào)用socket()則是通過sys_socketcall()這個入口找到sys_socket()->sock_create()->__sock_create()->rcu_dereference(net_families[family])根據(jù)協(xié)議簇執(zhí)行create。LibPcap選用的協(xié)議簇PF_PACKET通過af_packet.c中的packet_init()調(diào)用snapgear/linux-2.6.x/net/socket.c中的sock_register()被初始化注冊進net_families[]，其.create=packet create。因此LibPcap創(chuàng)建socket最終調(diào)用了packet_create()，在packet_create()中創(chuàng)建了sk并有sock->ops = &packet_ops; po->prot_hook.func=packet_rcv;而static const struct proto_ops packet_ops.recvmsg=packet_recvmsg，這便是用戶程序通過LibPcap從socket取得數(shù)據(jù)包的入口。因此用戶程序通過LibPcap獲取數(shù)據(jù)包的整個過程可以簡易描述為：由packet_rcv()接收來自底層的包（具體什么位置，我沒有搞明白），并分配出一段buffer，在sk_receive_queue資源不足以再容納下一段數(shù)據(jù)時，直接將數(shù)據(jù)丟棄kfree_skb()，并記錄tp_drops（即我們通過pcap_stats()得到的ps_drop）；而用戶程序則是不時調(diào)用packet_recvmsg()從隊列中一次性獲取數(shù)據(jù)，并最后釋放資源skb_free_datagram()。

　　其實到這里，我還未交代主題，那么導致LibPcap丟包的原因在哪里呢？了解了LibPcap捕獲數(shù)據(jù)包的過程再來查找就沒那么茫然了，debugging發(fā)現(xiàn)packet_recvmsg()的執(zhí)行頻度遠小于packet_rcv()，所以在packet_rcv()接收數(shù)據(jù)并充盈sk_rmem_alloc后，packet_recvmsg()并不能及時將其清空，在這個時間差中只能丟包了。那么為什么packet_recvmsg()執(zhí)行的頻度不夠呢？這可能是更底層的問題，限于能力，我在此無法給出解釋。

　　再談?wù)勗趺唇鉀Q這個問題。由于底層的原因我不得而知，所以我只能對我所了解的做出調(diào)整了——加大sk_rmem_alloc，利用其空間來容納packet_rcv()的積極動作，但這個做法是以犧牲速度為代價的。在本人的測試環(huán)境中，啟用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。

　　LibPcap丟包怎么辦？如果有朋友也在關(guān)心此問題，就不妨跟小編一起看看，望讀者能對文中謬誤之處提出批評并指正。

標簽： LibPcap 丟包

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。