Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Display filter alternative

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Thu, 5 Jul 2012 13:53:49 -0700
On Jul 5, 2012, at 2:38 AM, Lloyd wrote:

> I am studying about packet filtering methods. Then I came across
> NetBee library (combination of NetPDL+NetPFL+NetVM), by the developer
> of Winpcap. I have not tried the libary yet, but the authors claim
> that it is a very flexible, efficient and an extendable system (O.
> Morandi, F. Risso, M. Baldi, A. Baldini, “Enabling Flexible Packet
> Filtering Through Dynamic Code Generation”). I am interested in
> comparing Wireshark's display filter against the Netbee system for
> efficiency and extendability.
> 
> The have compared their system against BPF but not with wireshark's
> display filter.

Wireshark's display filter is different from both BPF and NetBee.  BPF and NetBee both involve code that extracts fields from packets and does tests on them; Wireshark's display filter works on an already-parsed packet, so the extracting of fields from packets has already been done by the time the display filter works on it.

I.e., the Wireshark display filter is *NOT* a standalone mechanism; it relies on Wireshark dissectors existing and having been run on the packet.

(BTW, they should perhaps have tried doing their development on a platform that implements ntohs() and ntohl() as inlines; I think glibc+GCC does that, and it appears that MSVC++ in Visual Studio 2005 and later would allow that as well:

	http://msdn.microsoft.com/en-us/library/a3140177(v=vs.80).aspx

although whether Winsock or whatever provides ntohs() and ntohl() does so is another matter.  The ability to do byte-swapping of host-byte-order quantities inline is *not* an inherent advantage of other languages over C for generating packet-filtering code....)