On Wed, Jun 28, 2000 at 06:54:35PM +0100, Ben Fowler wrote:
> At 04:21 AM 6/28/00, David Frascone wrote:
> >One simple fix would be to change the dissectors to return a boolean stating
> >whether or not they handled the packet. Then the dissector call could loop
> >through all the handlers till one handled it.
>
> This may be possible, but it is not simple; as you also have to have
> ethereal call the dissectors in the right order. In the general case you
> cannot be certain that you can modify a third party dissector (your
> suggestion 2) and have it still work.
Agreed, but see below
>
> I would suggest an ethereal.conf which has a table rather like ld.so.conf
> or the modules section in httpd.conf in which various characteristics of
> a packet could be compared sequentially in arbitrary order until the
> first match, which is taken as the true one. I assume that e-mail filters
> or news reader scoring systems work like this; but our system should
> have a design goal that is robust and that it give one answer, the right
> one, every time!
That would be very nice!
>
> I am not saying that it is wrong to return a status code from a dissection,
> but the fact that the packet could not be fully dissected does not mean that
> it was mis-classified.
>
Well, I was suggesting that the handler return a boolean stating whether or not
the message was destined for it. Not returning an error on failure.
An alternative would be to compare the data and add that to the filter. Is
there a way in the filter syntax to do that?
Maybe ("udp.port == 1812 and udp.data[0] != 0xfe")
