Wireshark-dev: Re: [Wireshark-dev] A question related to conversations
From: Sake Blok <sake@xxxxxxxxxx>
Date: Tue, 15 Jul 2008 23:57:37 +0200
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
- References:
- [Wireshark-dev] A question related to conversations
- From: Richard Achmatowicz
- [Wireshark-dev] A question related to conversations
- Prev by Date: Re: [Wireshark-dev] cast increases required alignment of target type in packet-diameter.c
- Next by Date: [Wireshark-dev] col_add_fence for Source/Dest columns?
- Previous by thread: [Wireshark-dev] A question related to conversations
- Next by thread: Re: [Wireshark-dev] A question related to conversations
- Index(es):