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

[Andreas <AndreasSander1@xxxxxxx>]

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