On Mon, Apr 21, 2003 at 11:37:47AM -0500, Turner, Jay wrote:
> [ ethereal 0.9.11 for Windows on Windows 2000 ] I am creating a
> plug-in (for our company's mainframe traffic) and find that it can
> access the TCP data. However it only allows me to decode TCP data
> packets whose source/destination/both ports match the current packet. I
> would like to decode ALL TCP data packets according to my plug-in.
We don't have a mechanism to force *all* TCP data to be dissected by
some particular dissector.
You could, however, use a heuristic dissector for that. The TCP
dissector checks for dissectors registered with particular port numbers
before checking heuristic dissectors, so it won't arrange that *all* TCP
traffic be seen by your dissector, but it will arrange that all TCP
traffic not to or from a port for which there's a dissector registered
will be seen by your dissector. (You could disable other dissectors
from the UI if you don't want them to dissect your traffic.)
If, as I suspect is the case, *not* all TCP traffic on your network is
for your protocol, you should probably have the heuristic dissector
attempt to determine, by looking at the TCP data, whether it's data for
your protocol or not, and return FALSE if it isn't.
A heuristic dissector for TCP would be registered with
heur_dissector_add("tcp", dissect_XXX_heur, proto_XXX);
where "dissect_XXX_heur()" is the top-level dissector routine - which
returns a gboolean, not void - and "proto_XXX" is the return value from
the "proto_register_protocol()" call for your protocol.
A heuristic dissector should, before any dissection is done and before
anything is put into any columns or the protocol tree, do whatever tests
it does to see whether the packet has data for its protocol or not.
Before the dissector fetches *ANY* data whatsoever from the packet, it
should call "tvb_bytes_exist()" to make sure that data is available from
the packet; if not, it should probably return FALSE. If the data it
fetches doesn't match what it'd expect to be there for that protocol, it
should return FALSE.
If all tests pass, it should do the dissection and return TRUE.
> I suspect this has to do with doing "dissector_add( "tcp.port", 0,
> myhandle );".
If there were such a mechanism, it'd probably work that way. However,
as there is no such mechanism, it has nothing to do with that, or
anything else.
> I have tried "tcp.data" and "data" but they are illegal.
> Where can I read about the correct syntax and choices for
> dissector_add?
The syntax is referred to in "doc/README.developer".
The choices are documented only in the source code, as the set of valid
first arguments depends on what dissector tables happen to be registered
by the dissectors in Ethereal *and* by any plugin dissectors are loaded
by Ethereal - it's not a static built-in table. Any 32-bit unsigned
integer value is syntactically valid as a second argument; no value has
any special meaning. The values that are *semantically* valid depend on
the definition of the protocol whose dissector owns that table, but if
you supply a semantically invalid value, the worst thing that'll happen
is that your dissector will never be called as the protocol field
associated with the dissector table never has that value.
