Workflow-wise, iteration is slower at first (compile → load → fail verifier ), but once the patterns are in place it actually simplifies things a lot. The ability to run this safely in production without noticeable overhead has been the biggest impact.

Cerberus targets a different layer: always-on, low-overhead network classification in CNI environments. It attaches at TC, limits L7 inspection intentionally, and focuses on predictable performance rather than rich event streams.

They’re complementary rather than competing tools.

Yes, tcpdump and Wireshark do use libpcap for packet capture and filtering. libpcap compiles the familiar tcpdump filter syntax into classic BPF (cBPF) programs that run in the kernel to decide which packets should be passed up to userspace.

On newer Linux kernels, libpcap can translate those classic BPF filters into eBPF, but that’s mostly an internal optimization. From a user point of view, you’re still just writing simple packet filters, and packets are still being copied to userspace for analysis. libpcap itself is not really an eBPF framework.

That’s where Cerberus is different.

Cerberus uses native eBPF programs directly, not just for filtering packets, but for running logic inside the kernel. Instead of copying packets out and decoding them later, it works with structured kernel events and can correlate network activity with processes, syscalls, and security context. In many cases it can even act or block things in real time.

So while tcpdump/Wireshark are great for debugging and traffic inspection, they’re fundamentally packet sniffers. Cerberus is more of an in-kernel observability and security system, built on eBPF as a programmable platform rather than just a fast filter.

In short: tcpdump uses BPF to filter packets. Cerberus uses eBPF to run logic.

Hope that helps clear it up