tcpdump: "paket ditangkap" vs "paket diterima oleh filter"


11

Kami memiliki skrip yang memanggil

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

pada banyak IP-s sedangkan bagian lain dari skrip memulai beberapa lalu lintas di latar belakang. Kami ingin memeriksa apakah paket kembali kepada kami, dan memeriksa hanya kasus-kasus secara manual ketika kami menerima paket. Output kesalahan tcpdump tampaknya bagus untuk ini pada awalnya, tapi.

Pertanyaannya adalah, seperti yang ditunjukkan subjek, apa perbedaan antara "paket yang ditangkap" dan "paket yang diterima oleh filter"? Ada tangkapan, yang tidak merekam paket apa pun, tetapi keluaran "0 paket ditangkap, 2 paket diterima oleh filter" yang terdengar seperti kontradiksi, karena jika tidak ada paket yang ditangkap, bagaimana 2 di antaranya disaring? Pada awalnya, kami telah mencari "0 paket yang diterima oleh filter" tetapi itu tidak selalu ditulis untuk output kesalahan, ketika tidak ada paket yang diterima. Jadi, apa yang ditunjukkan angka-angka ini?

Saya perlu tahu apa yang harus dicari jika kami ingin menyaring kasus-kasus itu ketika tidak ada paket balasan yang diterima.

Jawaban:


12

Saya harap ini menjelaskan masalah ini. Dari halaman manual :

Ketika tcpdump selesai menangkap paket, ia akan melaporkan jumlah:

paket yang ditangkap (ini adalah jumlah paket yang diterima dan diproses oleh tcpdump);

paket yang diterima oleh filter (artinya tergantung pada OS tempat Anda menjalankan tcpdump, dan mungkin pada cara OS dikonfigurasikan - jika filter ditentukan pada baris perintah, pada beberapa OS ia menghitung paket terlepas dari apakah mereka dicocokkan dengan ekspresi filter dan, bahkan jika mereka cocok dengan ekspresi filter, terlepas dari apakah tcpdump telah membaca dan memprosesnya, pada OS lain itu hanya menghitung paket yang cocok dengan ekspresi filter terlepas dari apakah tcpdump telah membaca dan memprosesnya, dan pada OS lain hanya menghitung paket yang cocok dengan ekspresi filter dan diproses oleh tcpdump);

paket yang dijatuhkan oleh kernel (ini adalah jumlah paket yang dijatuhkan, karena kurangnya ruang buffer, oleh mekanisme penangkapan paket di OS di mana tcpdump berjalan, jika OS melaporkan informasi itu ke aplikasi; jika tidak, itu akan dilaporkan sebagai 0).

Dan ada entri milis dari tahun 2009 yang menjelaskan:

Nomor "paket yang diterima oleh filter" adalah ps_recvnomor dari panggilan ke pcap_stats(); dengan BPF , itu bs_recvnomor dari BIOCGSTATS ioctl. Hitungan itu termasuk semua paket yang diserahkan ke BPF; paket-paket itu mungkin masih dalam buffer yang belum dibaca oleh libpcap (dan karenanya tidak diserahkan ke tcpdump), atau mungkin dalam buffer yang telah dibaca oleh libpcap tetapi belum diserahkan ke tcpdump, sehingga dapat menghitung paket-paket yang tidak dilaporkan sebagai "ditangkap".

Mungkin prosesnya terbunuh terlalu cepat? Ada juga -c Nflag yang memberitahu tcpdump untuk keluar ketika Npaket ditangkap.

Karena masalah Anda tampaknya sangat terspesialisasi, Anda juga dapat menggunakan libpcapsecara langsung atau melalui salah satu dari ratusan ikatan bahasa .

Untuk pertanyaan Anda, karena semua yang Anda dapatkan adalah paket yang diambil dalam capture.capfile, Anda bisa melihat run yang tidak kosong dan memeriksa ini, yaitu, uhm, menghitung baris?

tcpdump -r capture.cap | wc -l

Mungkin ada cara yang lebih baik menggunakan libpcap untuk mengembalikan jumlah entri dalam file tangkap ...


1
Juga, jika penanganan paket lambat, paket-paket mungkin akan jatuh di perangkat keras NIC sebelum dilihat oleh kernel.
Craig

@Craig: Kotak yang menjalankan skrip ini divirtualisasi, jadi saya tidak tahu tentang kecepatan NIC.
Alex Biro

@ sr_: ide bagus dengan baris, terlalu mudah :) Saya kira kita tidak perlu menggunakan -w switch, tetapi cukup mengarahkan output ke file dan menghitung nomor baris. Akan memeriksa ASAP itu.
Alex Biro

@ tuareg85: untuk menganalisis paket yang ditangkap, -wsangat bagus. Anda dapat misalnya menggunakan Wireshark dengannya.
sr_

1
Membunuh proses terlalu cepat mungkin bukan masalah, karena kita menunggu 3s setelah menghentikan lalu lintas, saya pikir itu sudah cukup. Juga tcpdump punya waktu untuk menyelesaikan output kesalahan juga, dan paket-paket yang dijatuhkan oleh kernel selalu 0.
Alex Biro
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.