tcpdump: "पैकेट पर कब्जा" बनाम "फ़िल्टर द्वारा प्राप्त पैकेट"


11

हमारे पास एक स्क्रिप्ट है जो कॉल करती है

tcpdump -v src host <IP address> and port <port number> >>out.txt 2>>err.txt -w capture.cap

मल्टीपल आईपी-एस पर जबकि स्क्रिप्ट के दूसरे हिस्से बैकग्राउंड में कुछ ट्रैफिक शुरू करते हैं। हम जांचना चाहते हैं कि क्या पैकेट हमारे पास वापस आ रहे हैं, और पैकेज प्राप्त करते समय केवल उन मामलों को मैन्युअल रूप से जांचें। tcpdump का एरर आउटपुट पहले इसके लिए ठीक था, लेकिन।

सवाल यह है कि जैसा कि विषय से पता चलता है, "पैकेट पर कब्जा कर लिया गया" और "फ़िल्टर द्वारा प्राप्त पैकेट" में क्या अंतर है? कैप्चर हैं, जो किसी भी पैकेट को रिकॉर्ड नहीं करते थे, लेकिन आउटपुट "0 पैकेट कैप्चर किया गया, 2 पैकेट फ़िल्टर द्वारा प्राप्त" जो विरोधाभास की तरह लगता है, क्योंकि अगर कोई पैकेट कैप्चर नहीं किया गया था, तो उनमें से 2 कैसे फ़िल्टर किए गए थे? सबसे पहले, हम "फ़िल्टर द्वारा प्राप्त 0 पैकेट" की तलाश में थे, लेकिन यह त्रुटि आउटपुट के लिए नहीं लिखा गया था, जब कोई पैकेट प्राप्त नहीं हुआ था। तो ये नंबर क्या दिखाते हैं?

मुझे यह जानने की आवश्यकता है कि अगर हम उन मामलों को फ़िल्टर करना चाहते हैं जब कोई उत्तर पैकेट प्राप्त नहीं हुआ था।

जवाबों:


12

मुझे उम्मीद है कि इस मुद्दे पर कुछ प्रकाश डाला जाएगा। से मैनपेज :

जब tcpdump पैकेट कैप्चरिंग समाप्त करता है, तो यह निम्न की रिपोर्ट करेगा:

कैप्चर किए गए पैकेट (यह उन पैकेटों की संख्या है जो tcpdump को प्राप्त और संसाधित किए गए हैं);

फ़िल्टर द्वारा प्राप्त पैकेट (इसका अर्थ उस OS पर निर्भर करता है जिस पर आप tcpdump चला रहे हैं, और संभवतया जिस तरह से OS कॉन्फ़िगर किया गया था - यदि कोई फ़िल्टर कमांड लाइन पर निर्दिष्ट किया गया था, तो कुछ OS पर यह परवाह किए बिना पैकेट की गणना करता है कि नहीं उन्हें फ़िल्टर अभिव्यक्ति द्वारा मिलान किया गया था, और भले ही उन्हें फ़िल्टर अभिव्यक्ति द्वारा मिलान किया गया था, भले ही tcpdump ने उन्हें पढ़ा और संसाधित किया हो, भले ही अन्य OSes पर यह केवल उन पैकेटों को गिना जाए जो फ़िल्टर अभिव्यक्ति द्वारा मिलान किए गए थे चाहे tcpdump ने पढ़ा हो। और उन्हें अभी तक संसाधित किया है, और अन्य OSes पर यह केवल उन पैकेटों की गणना करता है जो फ़िल्टर अभिव्यक्ति द्वारा मेल खाते थे और tcpdump द्वारा संसाधित किए गए थे);

कर्नेल द्वारा गिराए गए पैकेट (यह उन पैकेटों की संख्या है जो ओएस में पैकेट कैप्चर मैकेनिज्म द्वारा बफर स्पेस की कमी के कारण, जिस पर tcpdump चल रहा है, यदि OS अनुप्रयोगों की जानकारी देता है; यदि नहीं, तो यह; रिपोर्ट की जाएगी 0)।

और वहाँ 2009 से एक मेलिंग सूची प्रविष्टि है :

"फ़िल्टर द्वारा प्राप्त पैकेट" नंबर ps_recvएक कॉल से एक नंबर है pcap_stats(); BPF के साथ , यह bs_recvसंख्या है BIOCGSTATS ioctl। उस गिनती में वे सभी पैकेट शामिल हैं जो BPF को सौंपे गए थे; वे पैकेट अभी भी एक बफर में हो सकते हैं जो अभी तक libpcap द्वारा नहीं पढ़े गए हैं (और इस तरह tcpdump को नहीं दिए गए हैं), या एक ऐसे बफर में हो सकते हैं जो libpcap द्वारा पढ़ा गया है, लेकिन अभी तक tcpdump को नहीं सौंपा गया है, इसलिए यह पैकेटों की गिनती कर सकता है "कैप्चर" के रूप में रिपोर्ट नहीं किया गया।

हो सकता है कि प्रक्रिया बहुत जल्दी मार दी जाए? पैकेट कैप्चर -c Nहोने पर बाहर निकलने के लिए tcpdump को बताने वाला एक ध्वज भी है N

चूँकि आप जारी किए गए अंक काफी विशिष्ट प्रतीत होते हैं, आप सीधे या सैकड़ों भाषा बाँधों में से एक के माध्यम से भी उपयोगlibpcap कर सकते हैं ।

आपके प्रश्न के लिए, चूंकि आपके पास सभी फ़ाइल में कैप्चर किए गए पैकेज हैं capture.cap, आप केवल उन रनों को देख सकते हैं जहां यह खाली नहीं है और इन की जांच करें, अर्थात, उह, लाइनों की गणना करें?

tcpdump -r capture.cap | wc -l

संभवतः कैप्चर फ़ाइल में प्रविष्टियों की संख्या वापस करने के लिए libpcap का उपयोग करने का एक बेहतर तरीका है ...


1
इसके अलावा, यदि पैकेट हैंडलिंग धीमी है, तो संभव है कि पैकेट को एनआईसी हार्डवेयर में गिरा दिया जाए, इससे पहले कि कर्नेल को कभी भी देखा जाए।
क्रेग

@ क्रेग: इस स्क्रिप्ट को चलाने वाले बॉक्स का वर्चुअलाइजेशन किया जाता है, इसलिए मुझे एनआईसी स्पीड के बारे में पता नहीं है।
एलेक्स बिरो

@ sr_: लाइनों के साथ अच्छा विचार, बहुत आसान :) मुझे लगता है कि हमें -w स्विच का उपयोग करने की आवश्यकता नहीं है, लेकिन बस आउटपुट को एक फ़ाइल में पुन: निर्देशित करें और पंक्ति संख्याओं की गिनती करें। जाँच करेगा कि ए.एस.ए.पी.
एलेक्स बिरो

@ tuareg85: पकड़े गए पैकेट का विश्लेषण करने के लिए, -wबहुत अच्छा है। आप इसके साथ Wireshark का उपयोग कर सकते हैं।
sr_

1
इस प्रक्रिया को जल्द ही मारना शायद मुद्दा नहीं है, क्योंकि हम ट्रैफिक को रोकने के बाद 3s का इंतजार करते हैं, मुझे लगता है कि यह पर्याप्त होना चाहिए। इसके अलावा tcpdump के पास त्रुटि आउटपुट को भी समाप्त करने का समय है, और कर्नेल द्वारा गिराए गए पैकेट हमेशा 0. थे
एलेक्स बिरो
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.