Cara Fix Tcpdump Capture Filter di Linux – Panduan Troubleshooting BPF Step-by-Step

Jadi gini, kemarin sore lagi santai-santai nggarap laporan shift, eh dapat ticket masuk. Gateway load tinggi, tapi CPU dan RAM normal. Lha, itu mah tandanya yang naik itu trafik, bukan resource. Yaudah, langkah standar: colokin tcpdump biar kelihatan siapa yang rame-rame. Abis aku ketik perintahnya, dibales syntax error. Udah aku perbaiki, jalan lagi. Nol paket. Ah.

Pernah ngalamin gak? Kamu yakin udah nulis perintah yang bener, tapi tcpdump-nya nolak mentah-mentah, atau malah jadi tukang diem. Datang ticket, jam terus jalan, dan yang nunggu jawaban gak sabaran. Nah, artikel ini sengaja aku tulis buat siapa aja yang lagi belajar cara fix tcpdump capture filter di Linux, biar gak muter-muter kayak aku dulu. Kita bongkar pelan-pelan: penyebabnya apa, gimana solusinya step by step, plus beberapa trik biar capture filtermu makin mumpuni.

Masalah Capture Filter yang Sebenarnya Terjadi

Satu hal yang wajib kamu pegang dari sekarang: capture filter tcpdump itu bukan teks bebas yang dibaca shell biasa. Dia diterjemahkan jadi rangkaian instruksi BPF (Berkeley Packet Filter), di-compile, lalu ditempel ke kernel tiap kali tcpdump jalan. Karena itu, kesalahan kecil di sintaks aja – primitif yang kepotong, kurung gak nutup, operator yang prioritasnya beda dari dugaan – bakal ditolak mentah-mentah. Di lingkungan produksi, artinya makin banyak waktu emas buat diagnosa yang kebuang sia-sia.

Dan yang lebih halus: ada kasus di mana filter-nya bisa di-compile tanpa error, tapi hasilnya tetep nol paket. Nol! Padahal trafik di interface lagi rame banget. Nah, ini yang bahaya, karena biasanya orang langsung nebak-nebak ke arah firewall, hapus rules, restart service – semua keputusan yang berisiko – padahal akar masalahnya cuma di filter yang nyasar arah.

Kalau aku rangkum dari pengalaman nangani ratusan server, penyebab utamanya selalu jatuh ke tiga kubangan besar: kekeliruan sintaks dan precedence BPF, izin atau capability yang gak cukup buat ngambil paket, dan pemilihan interface atau arah trafik yang salah. Jangan lupa satu dua jebakan performa yang biasanya muncul belakangan, kayak resolusi DNS yang bikin capture ngadat atau buffer kernel yang kepenuhan. Enaknya, gak ada yang misterius di sini. Semuanya bisa kamu bedah sendiri, kok.

Gejala yang Sering Muncul

• tcpdump: syntax error – filter-nya ditolak, gak ada pilihan lain.
• You don’t have permission… – masalah capability atau user yang salah.
• Nol paket padahal trafik jelas ada – interface, arah, atau VLAN yang keliru.
• Capture lambat atau banyak “dropped by kernel” di summary.

Solusi Step-by-Step

Oke, sekarang masuk ke bagian yang kamu tunggu. Urutannya aku susun dari penyebab yang paling sering ke yang paling jarang. Ikuti berurutan aja biar enak dan gak bolak-balik.

Langkah 1: Beresin Sintaks BPF dan Precedence

Ini penyebab nomor satu, dan contoh klasik yang selalu aku temuin di ticket adalah ini:

tcpdump -i eth0 port 80 or 443

Error-nya udah bisa ditebak:

tcpdump: syntax error

Kenapa? Karena 443 di ujung kalimat itu bukan primitif yang lengkap. Di bahasa BPF, tiap bagian harus punya jenis filter yang jelas: port 443, host 10.0.0.1, net 192.168.1.0/24. Angka telanjang kayak 443 gak dikenali sama compiler, jadi tcpdump nolak mentah-mentah. Solusinya gampang:

tcpdump -i eth0 'port 80 or port 443'

Nah, begitu kamu mulai pakai and, or, sama not, ada satu aturan yang harus kamu inget terus: precedence. Di BPF urutannya not paling kuat, terus and, terakhir or. Jadi filter kayak gini:

tcpdump -i eth0 'host 192.168.1.10 and not port 22 or port 443'

itu sebenernya dibaca sebagai (host 192.168.1.10 and not port 22) or port 443. Kemungkinan besar bukan itu maumu kan? Buat mastiin bacaannya sesuai harapan, lengkapi dengan kurung:

tcpdump -i eth0 'host 192.168.1.10 and not (port 22 or port 443)'

Baru bener: semua paket dari host itu kecuali yang lewat port 22 sama 443. Penting banget ini, dan jarang banget dibahas orang.

Single Quotes vs Double Quotes

Ini kecil tapi sering bikin orang gatel. Di shell, ekspresi BPF paling aman dibungkus single quotes. Kenapa? Karena isinya kadang ada karakter yang gampang disangkutin shell: tanda seru (!) buat negasi bisa kena history expansion di bash interaktif, tanda dolar ($) bakal di-expand, dan kombinasi kayak [13] atau tanda & bisa jadi tebakan sia-sia. Contoh filter BPF beneran:

tcpdump -i eth0 'tcp[13] & 2 != 0'

Filter di atas minta paket yang flag TCP SYN-nya nyala. Coba kamu tulis tanpa kutip di bash, bisa-bisa malah dapet error dari shell, bukan dari tcpdump. Jadi biasakan: selalu single quotes buat ekspresi BPF.

Oh iya, kalau filter-mu kepanjangan dan dipakai berulang-ulang, tcpdump punya opsi -F buat baca filter dari file:

tcpdump -i eth0 -F /etc/tcpdump/filter.txt

Isi file itu persis ekspresi BPF yang mau dipakai, tanpa kutip. Satu catatan: kalau -F dipakai, ekspresi filter yang kamu tulis bareng di command line bakal diabaikan. Jadi pilih salah satu, jangan dua-duanya.

Langkah 2: Cek Izin dan Capability

Error kedua yang paling sering muncul di lapangan:

tcpdump: eth0: You don't have permission to perform this capture on that device

Masalahnya bukan di filternya sama sekali. tcpdump butuh akses mentah ke network socket, dan di Linux itu berarti butuh capability CAP_NET_RAW (plus CAP_NET_ADMIN buat beberapa kasus). User biasa gak punya itu. Cara paling praktis ya pakai sudo atau jadi root:

sudo tcpdump -i eth0 -c 20 'tcp port 443'

Tapi di sebagian tim NOC, ngetik sudo tiap menit itu ganggu kerjaan, apalagi kalau lagi capture panjang. Alternatifnya, kasih capability ke binary tcpdump biar user tertentu bisa capture tanpa root:

sudo setcap cap_net_raw,cap_net_admin=eip /usr/sbin/tcpdump
getcap /usr/sbin/tcpdump

Output dari getcap yang bener harus kayak gini:

/usr/sbin/tcpdump cap_net_admin,cap_net_raw=eip

Setelah itu user biasa udah bisa jalanin tcpdump. Tapi inget ya, ini pedang bermata dua. Capability kayak gini artinya siapa pun yang bisa ngejalanin tcpdump bisa ngintip trafik. Di environment yang penuh data sensitif, pikir-pikir dulu. Nek gak yakin, mending stay di sudo plus user dalam grup khusus, bukan mbukak akses buat semua orang.

Langkah 3: Pastikan Interface dan Arah Trafik Benar

Sekarang kasus yang paling bikin kesel: filter gak error, tapi nol paket. Pertanyaan pertama yang harus kamu tanyain ke diri sendiri: interface-nya bener gak? Jebakan ini lebih sering kejadian daripada yang kamu kira, apalagi di server yang interface-nya numpuk.

tcpdump -D

Perintah di atas nampilin daftar interface yang bisa di-capture. Bandingin sama ip -br link buat mastiin nama interface-nya emang ada dan statusnya up. Nah, kalau trafik sebenernya lewat bridge padahal fisiknya di interface lain, atau kamu masih ragu, pakai joker pembantu:

tcpdump -i any 'tcp port 443'

-i any bikin tcpdump ngambil dari semua interface sekaligus. Praktis buat mulai ngecek di awal sebelum ngunci ke interface spesifik.

Terus, kalau server-mu narima trafik pake VLAN (trunk ke switch), filter biasa sering kelewat karena BPF gak otomatis nembus header VLAN. Tambahin kata kunci vlan di depan:

tcpdump -i eth0 'vlan and host 10.0.0.5'

Soal arah, ini yang sering bikin orang mikir “lha kok gak ke-capture sih?”. Filter port 443 itu artinya port 443 di sisi source ATAU destination. Kalau kamu cuma mau lihat trafik satu arah, sebutkan jelas:

tcpdump -i eth0 'tcp dst port 443'   # outbound
tcpdump -i eth0 'tcp src port 443'   # inbound response

Dan kalau kamu yakin trafiknya IPv6, filter host 10.0.0.x yang IPv4-based bakal diem aja. Kasih awalan jenis protokol biar jelas:

tcpdump -i eth0 'ip host 10.0.0.5'
tcpdump -i eth0 'ip6 host 2001:db8::5'

Oke, ini yang paling penting di bagian ini: filter yang gak error itu belum tentu bener. Verifikasinya butuh sedikit sabar, dan itu kita bahas di langkah berikut.

Langkah 4: Bongkar Isi Filter dengan -d

Kalau semua udah dites tapi masih penasaran “sebenernya filter ini mau ngomong apa?”, tcpdump punya fitur buat nampilin hasil compile BPF:

tcpdump -d 'tcp dst port 443'

Kamu bakal lihat daftar instruksi BPF mentah, contohnya kaya gini:

(000) ldh      [12]
(001) jeq      #0x86dd          jt 2 jf 4
(002) jeq      #0x800           jt 5 jf 6

Gak perlu hapal artinya baris per baris, buat aku sih intinya satu: kalau -d bisa nge-compile tanpa error, berarti sintaks-mu valid. Kalau error di sini, kamu langsung tahu masalahnya di filter, bukan di tempat lain. Ada juga varian -dd (bentuk C code) dan -ddd (decimal) kalau butuh buat dijadiin program. Fitur diagnosa yang jarang dipakai tapi jujur aja ampuh.

Langkah 5: Jaga Capture Tetap Stabil dan Cepat

Terakhir, dua setting kecil yang bikin hidup lebih enak. Pertama, -nn buat matiin resolusi nama host dan layanan:

tcpdump -i eth0 -nn -c 50 'tcp port 443'

Tanpa -nn, tcpdump nyoba ngebalikin IP ke hostname dan port ke nama layanan. Itu artinya ada DNS lookup, itu lambat, apalagi pas lookup-nya timeout. Di produksi, -nn itu judul lagu wajib.

Kedua, buffer capture. Kalau di baris summary kamu lihat kalimat kayak:

10 packets captured
52 packets received by filter
41 packets dropped by kernel

itu artinya kernel buang paket gara-gara buffer kepenuhan. Naikin buffernya:

tcpdump -i eth0 -nn -B 4096 -w /tmp/capture.pcap 'tcp port 443'

-B 4096 artinya 4 MB buffer untuk kernel capture buffer. Buat capture panjang, kombinasikan dengan -w biar hasilnya nulis ke file, gak nimpa terminal, terus analisis belakangan pake tcpdump -r atau Wireshark. Biar stabil, cukup semene aja setting-nya.

Cheatsheet Filter BPF Biar Cepat Ingat

Filter	Artinya
host 10.0.0.5	Paket dengan source ATAU destination 10.0.0.5
src host 10.0.0.5	Hanya paket yang asalnya dari 10.0.0.5
dst host 10.0.0.5	Hanya paket yang tujuannya ke 10.0.0.5
net 192.168.1.0/24	Paket yang melibatkan segmen 192.168.1.0/24
tcp port 443	Paket TCP dengan port 443 di salah satu sisi
udp port 53	Paket UDP dengan port 53 (DNS)
ip6 host 2001:db8::5	Hanya trafik IPv6 ke/dari host itu
vlan and host 10.0.0.5	Host tersebut meskipun dibungkus header VLAN
ether proto 0x0806	Frame ARP

Tabel Troubleshooting Cepat

Gejala	Kemungkinan Penyebab	Solusi Cepat
tcpdump: syntax error	Primitif BPF kepotong, contoh port 80 or 443	Kutip ekspresi + lengkapi jadi port 80 or port 443
You don’t have permission…	User gak punya CAP_NET_RAW	sudo, atau setcap cap_net_raw,cap_net_admin=eip
Nol paket padahal trafik ada	Interface salah, VLAN, atau arah src/dst salah	tcpdump -D cek interface, -i any, tambah vlan, tegasin dst/src
Hasil capture aneh di port	Resolusi layanan via /etc/services	Pakai -nn
Banyak dropped by kernel	Buffer capture kekecilan	-B 4096 atau lebih
Filter valid tapi gak sesuai ekspektasi	Precedence and/or beda dari dugaan	Pakai kurung, verifikasi pake -d

Baca Juga

• Memahami BPF (Berkeley Packet Filter) buat pemula
• Panduan troubleshooting network Linux buat NOC
• tcpdump vs Wireshark: kapan pakai yang mana
• Monitoring bandwidth realtime dengan iftop

Yaudah, cukup semene aja dulu ya. Kalau kamu ngalamin kasus yang mirip tapi jalan keluarnya beda, cerita di kolom komentar, siapa tahu bisa nyelametin temen lain yang lagi bingung di depan terminal. Bookmark halaman ini buat referensi, terus pelan-pelan praktek. Mugi bermanfaat!