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

LibPcap丟包怎么辦

2019-10-29    來源:愛站科技

容器云強勢上線!快速搭建集群,上萬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

  測試過程:先將板子設(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)系。

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

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