[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wireshark-dev
Subject:    Re: [Wireshark-dev] Are Capture Filters Implemented in Software or the Network Card?
From:       Guy Harris <gharris () sonic ! net>
Date:       2021-11-21 19:06:34
Message-ID: B90A31E0-FCF7-4EAF-8183-CD8FA6C46D3F () sonic ! net
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]