[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: Graham Bloice <graham.bloice () trihedral ! com>
Date: 2021-11-21 19:32:16
Message-ID: CALcKHKoUxj_6qEZvur2DBqepAiEwRV=VswfjbQ4EOOxbQYEAig () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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
[Attachment #5 (text/html)]
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Sun, 21 Nov 2021 at 19:07, Guy Harris <<a \
href="mailto:gharris@sonic.net">gharris@sonic.net</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">On Nov 18, 2021, at 10:53 AM, X Q <<a \
href="mailto:xq1xq1xq1@gmail.com" target="_blank">xq1xq1xq1@gmail.com</a>> \
wrote:<br> <br>
> This is a question fairly deep in the guts of Wireshark that I could not find an \
answer to.<br> <br>
It's so deep in the guts of Wireshark that it's not even in Wireshark!<br>
<br>
> When a capture filter is implemented are ALL packets sent to \
Wireshark/Dumpcap/TShark at the software level for filtering<br> <br>
No, they're not.<br>
<br>
> or <br>
> <br>
> are the packets not matching the filter shedded/ignored by the Network Interface \
card itself thus reducing strain on the CPU/Network Fabric?<br> <br>
No, they're not.<br>
<br>
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..<br> <br>
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.<br> <br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> 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.<br> <br>
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.<br> <br>
It's also *not* done in tcpdump or dumpcap; it's done in libpcap.<br>
<br>
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.</blockquote></div><div><br></div><div>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.</div><div><br></div>-- <br><div dir="ltr" \
class="gmail_signature"><div dir="ltr"><div>Graham Bloice</div></div></div></div>
[Attachment #6 (text/plain)]
___________________________________________________________________________
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic