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.
For my fix it would be easy.
1) Modify all dissectors to return TRUE (handled).
2) Modify packet-radius to return false if first byte is 0xfe.
3) Modify packet-diameter to return false if first byte is NOT 0xfe.
> Actually, there is another issue here. It would be useful if we could pass
> information in on the command line (or in the preferences file) saying to
> associate a particular protocol with a particular port. For people who are
> testing their protocol implementation on a different port than correct one
> no changes would be required to Ethereal to debug their code.
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!
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.
Ben.
--
Leedsnet - The information resource for Leeds and the West Riding
< URL:http://www.leedsnet.com/mobile/ >
