On Wed, Feb 04, 2004 at 04:44:20PM +0100, Biot Olivier wrote:
> That's not as simple as it looks like. Ethereal display filters apply to
> *any* occurrence of the named header or protocol, which can be tricky in
> ip-over-ip and the likes. This implies that compiling a capture filter from
> a display filter will not always return the same packets as when using a
> display filter in Ethereal. The example you mention (dhcp <--> udp.port ==
> 67 or udp.port == 68) *must* imply 802.xyzzy/udp/ip for a capture filter.
Of course, but this is something I could live with - it would still be
significantly better than it is today.
> If we want to provide useful capture filters, I am afraid we'd better offer
> some default capture filters (cfilters file) anyway, and give them useful
> and meaningful names.
I'm still more in favour of my idea of giving each dissector a possiility
to provide its own capture filter, assuming that it is running on "toplevel".
Otherwise we would have a problem to add this to tethereal.
> I am afraid that this inevitably results in time loss and duplicate effort.
What are the alternatives? IMO, they are worse. Also, on the duplication:
The duplication of work done between tcpdump and ethereal is serveral
orders of magnitude bigger, and it works out fine. I'm quite sure that
the "waste of time" is marginal.
Ciao
Jï¿œrg
--
Joerg Mayer <jmayer@xxxxxxxxx>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.