Tôi hy vọng điều này làm sáng tỏ vấn đề. Từ trang hướng dẫn :
Khi tcpdump kết thúc việc bắt gói tin, nó sẽ báo cáo số lượng:
các gói được thu thập (đây là số lượng gói mà tcpdump đã nhận và xử lý);
các gói được nhận bởi bộ lọc (ý nghĩa của điều này phụ thuộc vào HĐH mà bạn đang chạy tcpdump và có thể theo cách mà HĐH được định cấu hình - nếu một bộ lọc được chỉ định trên dòng lệnh, trên một số HĐH, nó sẽ đếm các gói bất kể chúng được khớp với biểu thức lọc và, ngay cả khi chúng được khớp với biểu thức lọc, bất kể tcpdump đã đọc và xử lý chúng chưa, trên các HĐH khác, nó chỉ tính các gói được khớp bởi biểu thức lọc bất kể tcpdump có đọc hay không và đã xử lý chúng và trên các HĐH khác, nó chỉ tính các gói được khớp với biểu thức lọc và được xử lý bởi tcpdump);
các gói bị bỏ bởi kernel (đây là số lượng gói bị bỏ, do thiếu không gian bộ đệm, bởi cơ chế bắt gói trong HĐH mà tcpdump đang chạy, nếu HĐH báo cáo thông tin đó cho các ứng dụng; nếu không, nó sẽ được báo cáo là 0).
Và có một mục danh sách gửi thư từ năm 2009 giải thích:
Số "gói nhận được bởi bộ lọc" là ps_recv
số từ cuộc gọi đến pcap_stats()
; với BPF , đó là bs_recv
số từ BIOCGSTATS ioctl
. Số lượng đó bao gồm tất cả các gói đã được trao cho BPF; những gói đó vẫn có thể nằm trong bộ đệm chưa được libpcap đọc (và do đó không được trao cho tcpdump) hoặc có thể nằm trong bộ đệm được libpcap đọc nhưng chưa được chuyển đến tcpdump, vì vậy nó có thể đếm các gói mà không được báo cáo là "bị bắt".
Có lẽ quá trình bị giết quá nhanh? Ngoài ra còn có một -c N
cờ báo cho tcpdump thoát khi N
gói được bắt.
Vì vấn đề của bạn có vẻ khá chuyên biệt, bạn cũng có thể sử dụng libpcap
trực tiếp hoặc thông qua một trong hàng trăm ràng buộc ngôn ngữ .
Đối với câu hỏi của bạn, vì tất cả những gì bạn nhận được là các gói bị bắt trong capture.cap
tệp, bạn có thể chỉ cần nhìn vào các lần chạy mà nó không trống và kiểm tra chúng, tức là, uhm, đếm các dòng?
tcpdump -r capture.cap | wc -l
Có lẽ có một cách tốt hơn bằng cách sử dụng libpcap để trả về số lượng mục trong tệp chụp ...