ฉันหวังว่านี่จะให้ความกระจ่างในเรื่องนี้ จากmanpage :
เมื่อ tcpdump เสร็จสิ้นการจับแพ็คเก็ตมันจะรายงานจำนวน:
แพ็กเก็ตที่จับ (นี่คือจำนวนของแพ็กเก็ตที่ tcpdump ได้รับและประมวลผล)
แพ็คเก็ตที่ได้รับจากตัวกรอง (ความหมายของสิ่งนี้ขึ้นอยู่กับระบบปฏิบัติการที่คุณใช้งาน tcpdump และอาจเป็นไปได้ที่วิธีการตั้งค่าระบบปฏิบัติการ - หากตัวกรองถูกระบุในบรรทัดคำสั่งในบางระบบจะนับจำนวนแพ็กเก็ต พวกมันถูกจับคู่โดย expression ของตัวกรองและแม้ว่าพวกมันจะถูกจับคู่กับ expression ของตัวกรองโดยไม่คำนึงว่า tcpdump ได้อ่านและประมวลผลแล้วหรือยังใน OS อื่น ๆ จะนับเฉพาะแพ็กเก็ตที่จับคู่โดย expression ของตัวกรองโดยไม่คำนึงว่า และประมวลผลมันและใน OS อื่น ๆ จะนับเฉพาะแพ็กเก็ตที่จับคู่โดยนิพจน์ตัวกรองและถูกประมวลผลโดย 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
ไฟล์คุณสามารถดูการวิ่งที่มันไม่ว่างเปล่าและตรวจสอบสิ่งเหล่านี้เช่น uhm นับจำนวนบรรทัดได้หรือไม่
tcpdump -r capture.cap | wc -l
อาจมีวิธีที่ดีกว่าในการใช้ libpcap เพื่อส่งคืนจำนวนรายการในไฟล์การจับภาพ ...