Re: Are Capture Filters Implemented in Software or the Network Card?

[Guy Harris <gharris () sonic net>]

On Nov 18, 2021, at 10:53 AM, X Q <xq1xq1xq1 () gmail com> 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.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe