[Guy Harris <gharris@xxxxxxxxx>]

On Wed, Apr 07, 2004 at 08:59:36PM +0200, metatech wrote:
> This is a problem that I have also encountered as well.
> - The WebSphere MQ dissector heuristics should be very reliable, but the 
> likelihood that another protocol uses the port 1414 is very high since 
> usely machines start outgoing TCP connections from port 1025 onwards. But 
> the problem is that the heuristics does not apply to every packet in a 
> conversation, although only one (for instance the first one) is enough to 
> mark it as "MQ" for the rest of the conversation.  So the heuristics cannot 
> be checked easily on every packet.
> Or if there was a "likelihood" value for each protocol, I would register as 
> "lowest possible" so that only the heuristics would call it.  In a general 
> sense I think it would make sense to define a "likelihood" for each 
> protocol so that we could put HTTP, FTP and POP3 on top priorities and 
> mitigate false detections (statistically speaking).

We've discussed the notion of allowing heuristic dissectors to register
as "strong" (i.e., a heuristic unlikely to get false positives) or
"weak" (one more likely to get false positives); a "likelihood" might
also be useful.

> - I tried to remove the registration of the 1414 port, but in that case it 
> is impossible to do a "Decode as..." with MQ... (for instance
> if another dissector stole the packet).  Is there any trick (like creating 
> two protocol handles, one is dummy and the other one is real) ?

There's a "dissector_add_handle()" call, which takes a dissector table
name and a handle; it indicates that there's no port number in that
dissector table to which the protocol in question should be permanently
assigned, but that doing a "Decode as..." on that dissector table should
be allowed.

> - Also I haven't found a way to "NAK" a packet once it is passed to a 
> dissector through a port match, is there a way to pass it to another 
> dissector ? (like the return boolean for the heuristic method).

No, but there is a way to NAK the packet; the API isn't documented as I
haven't yet decided whether it's the right way to handle it.

You can declare a dissector that returns an "int" rather than a "void";
if it returns 0, it means it rejects the packet, otherwise it means that
it accepted the packet *and* dissected the specified number of bytes in
the tvbuff handed to it as being for that protocol (most dissectors
would just return "tvb_length(tvb)").  You create a dissector handle for
that type of dissector with "new_register_dissector()"; you can use
those handles the same way you use handles created with
"register_dissector()".

One problem with the API is that there are, as I remember, some places
(I forget where) where 0 is a legitimate number of bytes for the
dissector to say it's dissected, but that's indistinguishable from
rejecting the packet.

The other possibilities for the API would be:

	1) return a Boolean, but there are some places where we
	   currently use the length information;

	2) have dissector handles include pointers to *two* functions, a
	   "test" function that checks whether the packet is for that
	   protocol or not and returns a Boolean and a "dissect"
	   function that returns "void".  The "test" function pointer
	   could be null, meaning "accept all packets.

	   This might simplify some other things (e.g., dissectors that
	   use "tcp_dissect_pdus()" wouldn't have to worry about testing
	   whether the packet is for them).

Both of those would let heuristic dissectors use the same type of handle
as other dissectors.