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

[Graham Bloice <graham.bloice () trihedral com>]

On Sun, 21 Nov 2021 at 19:07, Guy Harris <gharris () sonic net> wrote:

> 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.
There is a native capture mechanism, ETW, and some support has been added
to Wireshark for that recently, the extcap ETW Reader (via ETWDump.exe).
Captures can be made using ETW and the subsequent file read by the ETW
Reader.  Live capture isn't supported at present.


> 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.


I think there are also specialized capture cards that can filter in
hardware, e.g. Endace DAG cards, but these can't be used as general purpose
NICs.

-- 
Graham Bloice

___________________________________________________________________________
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