Wireshark · Wireshark-dev: Re: [Wireshark-dev] A question related to conversations

[Richard Achmatowicz <rachmato@xxxxxxxxxx>]

Qualifier: Concerning the fact that TCP segments are never reassembled in my example, I think I found the answer.
JGroups generally writes a length field followed by data when writing to the TCP stream - except in
one case - when it initially opens a TCP connection. It does it's own little handshake with the 
remote peer, and this handshake packet does not include a length field. I assume that my dissector 
is interpreting it as a length field (and it turns out to be a huge length) and so segment 
reassembly is failing for that reason.  

Richard

----- Original Message -----
From: "Richard Achmatowicz" <rachmato@xxxxxxxxxx>
To: "Developer support list for Wireshark" <wireshark-dev@xxxxxxxxxxxxx>
Sent: Wednesday, July 16, 2008 12:00:44 PM GMT -05:00 US/Canada Eastern
Subject: Re: [Wireshark-dev] A question related to conversations

Sake

Thanks for your help so far.

1. JGroups can use UDP or TCP as a transport, but not both. Assume for the time being that it uses TCP only.
2. By a two process interaction, I just mean a TCP connection between some addr1/port1 and some addr2/port2.

I initially wrote a dissector which worked for UDP packets which contained a single, complete JGroups PDU.
Because of TCP segmentation, I had to modify this dissector to call tcp_dissect_pdus() before calling the 
JGroups PDU dissector, so that TCP segment reassembly could take place. With this in place, I get captures 
which look like the attached screenshot (JGroupsDissector).

For example, packets 22,23,24 are the start of a TCP connection between 192.168.0.101:46272 and 
192.168.0.101:asr. Packets 25, 27 and 29 are JGroups PDUs being sent from 46272 to asr; packet 31 is 
a JGroups PDU being sent from asr to 46272. Only the packet from asr to 46272 is dissected as a JGroups PDU;
the packets from 46272 to asr are not. This is consistent throughout the whole dissection. This is what 
I meant by "only one side of the exchange is being dissected". 

On the other hand, for the TCP packets from 46272 to asr, they are marked as "TCP segment of a reassembled PDU" 
- but never seem to get processed as a JGROUPS PDU. I assume that these reassembled PDU messages are a result 
of using tcp_dissect_pdus(). Does this look suspicious?

In the dissector, I have registered the dissector with TCP using a specified TCP port. In the example screenshot, it 
is set to the value of asr (actually 7800). If I change the specified TCP port to 1234, no JGROUPS level dissection takes 
place. 

So one question: if TCP creates the conversations automatically, how does Wireshark know to apply the JGROUPS dissector 
to both directions of a conversation, which I specifically associated the disector with a single port (which happens to be
the port of one side of the connection)?

Richard

----- Original Message -----
From: "Sake Blok" <sake@xxxxxxxxxx>
To: "Developer support list for Wireshark" <wireshark-dev@xxxxxxxxxxxxx>
Sent: Tuesday, July 15, 2008 5:57:37 PM GMT -05:00 US/Canada Eastern
Subject: Re: [Wireshark-dev] A question related to conversations

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
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
https://wireshark.org/mailman/listinfo/wireshark-dev

_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
https://wireshark.org/mailman/listinfo/wireshark-dev