Ethereal-users: Re: [Ethereal-users] Feature Request: Pre-flight capture filter expressions
Richard E. Brown wrote:
1) One of my biggest frustrations when I first started using the program was the
fact that you can enter an invalid capture filter expression. Then you start a
capture, and you're confronted with a "Sorry, that's wrong..." message.
It would be very nice to have Ethereal run this string through the tcpdump
parser right when you enter it, so they could be assured that it'll work "first
time".
"Assured" as long as they're not color-blind. :-) I.e., this would be
like display filters, where the background color would indicate whether
the expression is valid or not. Obviously you can't just *prevent*
people from typing invalid filters, as that'd prevent them from entering
many valid filters - you can't type "host 192.9.200.2" with a single
keystroke, and "h", by itself, isn't a valid capture filter.
Note also that what filter expressions are allowed depends on the type
of interface on which you're capturing, so if no interface is selected,
no checking can be done, and if you type in an expression and then
change the interface, the expression might suddenly change to being
tagged as invalid.
This requires that the capture device be opened - you can't compile a
filter expression without having a device open.
This should happen in the Capture... window, or when specifying capture
filters.
Fully checking them when editing your list of capture filters can't be
done, at present. As indicated above, there exist filters that are
valid on some devices but not on others - "ether host 00:a0:95:3b:00:02"
is, for example, valid on Ethernet (and Token Ring and FDDI and 802.11)
devices, but not on PPP devices. With the current libpcap API, checking
them at all without having an interface in mind isn't possible, as that
API requires you to supply an indication of the type of device on which
you're capturing (a pcap_t pointer for a live capture or capture file
or, in newer versions of libpcap, a "dead" pcap_t with a specific device
type); a future version of libpcap will probably support some checking,
as it'll probably split parsing of the filter and generation of code
into two functions, but the checking would not do any checking of
particular interface types (and won't necessarily catch filters that mix
stuff that works only on some particular interface types and stuff that
only works on other interface types).
4) The documentation refers the reader to the tcpdump page for detailed
information about capture filters. I imagine that the tcpdump filter format is
sufficiently stable that it would be worth incorporating it into the Ethereal
help page.
I would not necessarily imagine that, but that's because I'm one of the
core libpcap developers, and have added new filter expression
capabilities and have some other ones I plan to add in the future. :-)
Note also that the capabilities of libpcap (the library that Ethereal,
tcpdump, and a number of other applications use to capture network
traffic; that library is what implements capture filters) depend on the
version of libpcap you have installed, so some features (e.g., "vlan")
might be available on some systems but not others.