On Nov 18, 2021, at 10:53 AM, X Q <xq1xq1xq1@xxxxxxxxx> wrote:
> This is a question fairly deep in the guts of Wireshark that I could not find an answer to.
It's so deep in the guts of Wireshark that it's not even in Wireshark!
> When a capture filter is implemented are ALL packets sent to Wireshark/Dumpcap/TShark at the software level for filtering
No, they're not.
> or
>
> are the packets not matching the filter shedded/ignored by the Network Interface card itself thus reducing strain on the CPU/Network Fabric?
No, they're not.
On UN*Xes, the operating system itself provides a packet capture mechanism. Not all UN*Xes provide the same capture mechanism; the libpcap library, which is *not* part of Wireshark (it's a separate project with a separate development team, although there are people who work on both projects), provides a programming interface that supports those capture mechanisms, so that the same code can work on *BSD, macOS, Linux, etc..
On Windows, the operating system itself doesn't have such a capture mechanism, but it's possible to add drivers that provide such a mechanism. That's what both WinPcap and Npcap do; they provide a driver plus a user-mode library to communicate with the driver plus libpcap built to use that user-mode library as the capture mechanism.
In the capture mechanisms in most UN*Xes (*BSD, macOS, Linux, Solaris, AIX, and Tru64 UNIX), and in the capture mechanism provided by the WinPcap and Npcap drivers, all packets received by an interface on which capturing is being done are delivered to the capture mechanism in the kernel. That capture mechanism applies the filter, and only packets that pass the filter are put in a buffer to be delivered to user mode. The libpcap user-mode code then just sees only the packets that pass the filter, and provides those packets to the program using it, such as tcpdump or dumpcap. In the case of dumpcap, it writes batches of packets to a capture file as they arrive, and notifies Wireshark or TShark that a batch of packets has arrived.
The filtering is *not* done in the network adapter (which isn't necessarily a card - it could be built into the computer); an adapter that does the filtering itself could probably be built, and libpcap could be modified to recognize cards that can do filtering and to tell the adapter's driver, rather than the kernel's packet capture mechanism, what the filter program is. I don't know of any adapters of that sort, however, and libpcap currently has no code to do so.
It's also *not* done in tcpdump or dumpcap; it's done in libpcap.
Thus, the filtering process consumes some CPU on the host, as the packet has to be delivered to the capture mechanism (taking some CPU) and must be filtered (taking some CPU), but, if the packet doesn't pass the filter, no *further* work has to be done on the packet, saving the CPU effort required for that.