ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-bugs: [Wireshark-bugs] [Bug 2804] most capture filters are inoperative when sniffing w

Date: Fri, 16 Apr 2010 10:52:59 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2804

--- Comment #8 from Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> 2010-04-16 10:52:56 PDT ---
(In reply to comment #5)
> The decryption happens in Wireshark, at least for monitor mode (if you're not
> capturing in monitor or promiscuous mode, the decryption is handled in the card
> or driver, and the filtering is done *after* that, so it works).
> 
> Implementing capture filters is actually not that hard - libpcap/WinPcap
> includes a BPF interpreter, bpf_filter(), and pcap_compile() compiles filters
> into BPF.

But once the packet's made it to *shark then there's no need to use a capture
filter any more.  We have (er, "had," and hopefully will have again if bug 2234
ever gets fixed) read filters (same as display filters but packets that don't
pass the filter are "dropped") for that.

Since 1) *pcap will never do the decryption for us; 2) dumpcap won't either
(and rightfully so); and 3) there's no benefit (beyond read filters) to
implementing capture filters in *shark, does it make sense to say we'll never
have capture filters for encrypted wireless but that read filters should be
used instead?

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.