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.
