最近有很多都跟小編反映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

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

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

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

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

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

　　沒(méi)有多想，按注釋直接全文通緝“tp_drops”，在snapgear/linux-2.6.x/net/packet/af_packet.c packet_rcv()中抓住了它。懷疑問(wèn)題出在：

　　if (atomic_read(&sk->sk_rmem_alloc) + skb->truesize >=
　　　　(Unsigned)sk->sk_rcvbuf)
　　　　goto drop_n_acct;

　　debugging證明了懷疑的正確性，并發(fā)現(xiàn)sk_rmem_alloc會(huì)突然降為零。那么為什么會(huì)出現(xiàn)sk_rmem_alloc不夠用呢？為此，我不得不弄清楚正常情況下sk_rmem_alloc是怎么被釋放的。atomic_read()該死的原子操作，我還不得不感謝它，因?yàn)樵诓榭此�的時(shí)候發(fā)現(xiàn)了它的兄弟atomic_sub()并最終找到了sock_rfree()大人，debugging證明sk_rmem_alloc確實(shí)是由這位大人釋放的。那什么時(shí)候這位大人才會(huì)露面呢？我真的對(duì)Linux認(rèn)識(shí)太少了，慚愧呀！

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

　　干脆由pcap_open_live()出發(fā)，看看這個(gè)handle怎么得來(lái)，socket如何被創(chuàng)建的。碰到了socket()，于是我再次沖進(jìn)kernel，可是找來(lái)找去都沒(méi)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)用的入口，這個(gè)文件中定義了許多socket系統(tǒng)調(diào)用，我也是在這里找到了sys_socket()并確認(rèn)LibPcap中創(chuàng)建socket便是通過(guò)這個(gè)函數(shù)實(shí)現(xiàn)的。當(dāng)我尋訪到__sock_create()時(shí)，又發(fā)現(xiàn)此處煙波浩淼，真的是傷心透了。一時(shí)半會(huì)是看不明白的了，扭頭。

　　既然pcap_open_live()巷子太深，那么我再?gòu)膒cap_dispatch()突破。追蹤到snapgear/lib/libpcap/pcap-linux.c中的pcap_read_packet()，發(fā)現(xiàn)在callback()調(diào)用用戶程序前是通過(guò)recvfrom()取得包的。郁悶，又找不到原型，又是系統(tǒng)調(diào)用。再次感謝九賤，還有《UDP Socket Creation》的作者，正是看了他們的文章，sk->sk_prot->recvmsg才被鎖定。遍地找尋了recvmsg，再根據(jù)LibPcap創(chuàng)建Socket時(shí)選用的類型SOCK_RAW，snapgear/linux-2.6.x/net/ipv4/raw.c中的raw_recvmsg()被相中了，因?yàn)樗�的老家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確認(rèn)時(shí)令我失望了，snapgear/linux-2.6.x/net/socket.c sys_recvfrom()調(diào)用sock_recvmsg()調(diào)用__sock_recvmsg()時(shí)，sock->ops->recvmsg更多時(shí)候并不等于sock_common_recvmsg，一團(tuán)迷霧驟然升起——天呀！

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

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

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

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

　　再談?wù)勗趺唇鉀Q這個(gè)問(wèn)題。由于底層的原因我不得而知，所以我只能對(duì)我所了解的做出調(diào)整了——加大sk_rmem_alloc，利用其空間來(lái)容納packet_rcv()的積極動(dòng)作，但這個(gè)做法是以犧牲速度為代價(jià)的。在本人的測(cè)試環(huán)境中，啟用snort中提供的所有rule，將sk_rmem_alloc擴(kuò)至10M（echo 10485760 > /proc/sys/net/core/rmem_default && echo 10485760 > /proc/sys/net/core/rmem_max）能保證Dropped: 0.00%，但此時(shí)平均速度降至≈16Mbps。

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

標(biāo)簽： LibPcap 丟包

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