[Sake Blok <sake@xxxxxxxxxx>]

On Tue, Jul 15, 2008 at 11:06:58AM -0400, Richard Achmatowicz wrote:
> 
> I've created a basic dissector for the JGroups group communication 
> protocol which can dissect JGroups PDU when running atop TCP or UDP. At 
> present, the dissection is based on specifying a port number (either udp 
> port or tcp port, depending on the transport used) in the preferences 
> section, in order to indicate to wireshark which packets it captures 
> should have the JGroups PDU dissector applied. However, this results in 
> PDUs in only one direction of a two process interaction to be dissected.

As I am not aware of the way JGroups communication is implemented, could
you explain what you mean with "two process interaction". Do the two 
processes communicate over 1 TCP or UDP "connection"? If this is true
then the dissection of both sides of a TCP connection should be dissected
as the tcp dissector creates a conversation per tcp connection.

For an UDP session, the protocol atop UDP is responsible for creating
a conversation to link returning traffic to the same dissector.

> I'm trying to achieve two things at present:
> (i) as a first step, have both directions of a two process interaction 
> dissected

See above, for tcp sessions it should work automagically and for udp
sessions, you should use conversations. Have a look at the 
doc/README.developer file under chapter 2.2

> (ii) as a second step, within the larger context of a two process 
> interaction, where we can view the interaction as consisting of a 
> sequence of known, prototcol specific phases (e.g in the case of 
> JGroups, discover peers, join group, exchange data with group members, 
> leave group)

Are all these interactions separate TCP/UDP sessions? Or are they
phases within one session? If they are phases within one TCP/UDP
session, you can add state information to the conversation. Make
you only update state information when the flag pinfo->fd->flags.visited
is FALSE, as packets will be read once in sequence (with this
flag FALSE) and then can be accessed randomly when a user clicks on 
a packet (then the flag will be TRUE).

> I want to be able to have wireshark identify and mark 
> those phases, say, with colours

Once you have dissected all the data and added fields, people can
then creat coloring rules for these fields/values. It is not possible
to let the dissector change the coloring of packets.

> I'll limit my question to the first part, as it is my immediate problem.
> 
> Are conversations the principal way of achieving (i) - namely, getting 
> two sides of an interaction to be dissected, as opposed to one specified 
> by a single port number?

Yes, see above...

> Is there any special coding of the conversation logic required in order 
> to get this effect? For example, in a JGroups capture session, there may 
> be several addr1/port1 addr2/port2 combinations which are interacting, 
> and i'd like each side of these exchanges to be dissected. Do I just 
> need to try and find a conversation for each packet I encounter, and if 
> it doesn't belong to one, then create one?

All conversations have "addr1/port1 addr2/port2 framenumber" to identify
the session. The frame number is used when there are two or more
conversations that use the same "addr1/port1 addr2/port2" combination.
Of course these two conversations should not be overlapping.

Hope this helps,
Cheers,
    Sake