tcpdump: Các gói tin bị bắt giữ


11

Chúng tôi có một kịch bản gọi

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

trên nhiều IP trong khi các phần khác của tập lệnh khởi tạo một số lưu lượng trong nền. Chúng tôi muốn kiểm tra xem các gói có quay trở lại với chúng tôi không và chỉ kiểm tra thủ công những trường hợp đó khi chúng tôi nhận được gói. Đầu ra lỗi của tcpdump có vẻ tốt cho việc này lúc đầu, nhưng.

Câu hỏi là, như chủ đề gợi ý, sự khác biệt giữa "các gói được bắt" và "các gói được nhận bởi bộ lọc" là gì? Có các bản chụp, không ghi lại bất kỳ gói nào, nhưng xuất ra "0 gói được chụp, 2 gói được nhận bởi bộ lọc" nghe có vẻ mâu thuẫn, vì nếu không có gói nào được chụp, 2 trong số chúng được lọc như thế nào? Lúc đầu, chúng tôi đã tìm kiếm "0 gói được nhận bởi bộ lọc" nhưng điều đó không được ghi vào đầu ra lỗi, khi không có gói nào nhận được. Vậy những con số này cho thấy gì?

Tôi cần biết những gì cần tìm nếu chúng tôi muốn lọc những trường hợp đó khi không nhận được gói trả lời.

Câu trả lời:


12

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_recvsố từ cuộc gọi đến pcap_stats(); với BPF , đó là bs_recvsố 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 Ncờ báo cho tcpdump thoát khi Ngó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 libpcaptrự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.captệ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 ...


1
Ngoài ra, nếu việc xử lý gói chậm, có thể các gói sẽ bị loại bỏ trong phần cứng NIC trước khi hạt nhân nhìn thấy.
Craig

@Craig: Hộp chạy tập lệnh này được ảo hóa, vì vậy tôi không biết về tốc độ NIC.
Alex Biro

@sr_: ý tưởng tốt với các dòng, quá dễ dàng :) Tôi đoán rằng chúng ta không phải sử dụng công tắc -w, mà chỉ cần chuyển hướng đầu ra sang một tệp và đếm số dòng. Sẽ kiểm tra càng sớm càng tốt.
Alex Biro

@ tuareg85: để phân tích các gói bị bắt, -wthật tuyệt. Bạn có thể sử dụng Wireshark với nó.
sr_

1
Giết quá trình quá sớm có lẽ không phải là vấn đề, vì chúng tôi đợi 3 giây sau khi dừng lưu lượng, tôi nghĩ rằng điều đó là đủ. Ngoài ra tcpdump cũng có thời gian để hoàn thành đầu ra lỗi và các gói bị bỏ bởi kernel luôn là 0.
Alex Biro
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.