中文字幕在线观看,亚洲а∨天堂久久精品9966,亚洲成a人片在线观看你懂的,亚洲av成人片无码网站,亚洲国产精品无码久久久五月天

LibPcap丟包怎么辦

2019-10-29    來(lái)源:愛(ài)站科技

容器云強(qiáng)勢(shì)上線!快速搭建集群,上萬(wàn)Linux鏡像隨意使用

  最近有很多都跟小編反映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)樵诓榭此臅r(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)樗睦霞襰truct 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)系。

上一篇:Linux服務(wù)器socket端口無(wú)法釋放

下一篇:Linux下如何查看網(wǎng)卡的實(shí)時(shí)流量