Wireshark-dev: Re: [Wireshark-dev] Reassembly of messages

From: Andreas <AndreasSander1@xxxxxxx>
Date: Sun, 28 Nov 2010 17:05:48 +0100
Am 26.11.2010 17:51, schrieb Stephen Fisher:
On Thu, Nov 25, 2010 at 09:13:20AM +0100, news.gmane.com wrote:

I want to reassemble messages in a TCP stream. I use the function
tcp_dissect_pdus for this purpose. This works fine to populate the
packet details tree. But what is the best way to collect all message
summaries and write it to the packet list INFO column?

I'm not sure if I understand your question correctly.  TCP reassembly
will gather the entire stream and present it to your dissection code all
at once.
Well that's true, I get reassembled segments. But I want to show a summary about the segments in the info column, when I am asked to fill it. My code checks that with the "check_col(pinfo->cinfo, COL_INFO)" call. Let's call it COL_INFO value.

>
>> I have seen that my dissect function has been called multiple times
>> for a specific packet. What is the best point of time to evaluate
>>    check_col(pinfo->cinfo, COL_INFO)
>> and put the summary to packet list info column?
>
> Typically you don't worry about that and just do it every time. If
> necessary, you can check the pinfo->fd->flags.visited variable,
> which is changed from FALSE to TRUE after the first time a packet
> is dissected.

I dump the information you mentioned and some short info, in a log. It shows additionally the length of the PDU and the type of message in the PDU. I try to comment, what I understood ...


When loading the file (or during live capture) each packet is handed to my dissector. The dissector function calls tcp_dissect_pdus, that calls the pdu_dissector function as expected. During all these calls COL_INFO is 0, also the tree parameter is NULL. The visited flags is also false.

After reading the entire file, Wireshark calls the dissector for the displayed packets. The visited flag is now always true, the tree parameter points to the current tree to be filled.

packet #1, offset:20 len:192, COL_INFO:1, visited:1 tree:!=NULL
pdu length: 32	-> MessageA
pdu length: 160 -> MessageB

packet #2, offset:20 len:12, COL_INFO:1, visited:1 tree:!=NULL
pd length: 12 -> MessageC

packet #3, offset:20 len:151, COL_INFO:1, visited:1 tree:!=NULL
pdu length: 153 -> MessageD

packet #4, offset:20 len:12, COL_INFO:1, visited:1 tree:!=NULL
pdu lenbgth: 12 -> MessageE

packet #5, offset:20 len:1460, COL_INFO:1, visited:1 tree:!=NULL
pdu length: 42403 -> ''

The last packet (#5) is the first packet of a segment, that must be reassembled. Since the message is incomplete, only an empty string is written to the INFO column. Bit that's overwritten by the TCP dissector with [TCP segment of reassembled PDU].

packet #1, offset:20 len:192, COL_INFO:0, visited:1 tree:!=NULL

The dissector is invoked once again, COL_INFO is now false. I assume this is used for the actual population of the packet details tree. (My dissector fills it every time, when the tree parameter is not NULL.


Now I can scroll until packet #116 is visible or make this packet visible by a "GO-TO 116" jump with the user interface (Ctrl-G). My dissector is than called twice with these parameters:

packet #116, offset:0 len:42403, COL_INFO:1, visited:1 tree:1
pdu length: 42403 -> MessageF

packet #116, len:197, offset:1283 len:197, COL_INFO:0, visited:1 tree:1
pdu length: 68 -> MessageG
pdu length: 36 -> MessageH
pdu length: 36 -> MessageH
pdu length: 36 -> MessageH
pdu length: 36 -> MessageH

After this (I admit) long session, my dissector has added the MessageF to the INFO column. But the other messages that are also in this packet are not shown.

Two problems arise:
- The COL_INFO is false. No text can be added to the INFO column.
- The second call for packet #116 should add the information about message G,H,H,H and H. It does not get an indication, that it should add some text instead of replacing it.

Do you have any suggestion, how I can manage to display "Message F,G,H,H,H,H" in the info column for packet #116?

BTW. I have to do this with Wireshark 1.2 as well as 1.4.

--
Andy