On 02/08/2011 22:36, Chris Miller wrote:
> Hi,
>
> I have come across an issue whilst attempting to write a custom dissector
> for the XCP protocol. The protocol sits on top of TCP and I am using the
> tcp_dissect_pdus function to handle the reassembly of TCP packets to allow
> successful dissecting of my PDUs.
>
> The protocol includes a packet counter and I am adding these packet numbers
> to the info column. Everything works as expected except when a packet has
> been reassembled. In this case I only get the first packet number added to
> the info column but the detailed information is still added as expected.
> The screenshot at the URL below illustrates the problem.
>
> http://postimage.org/image/uih7wfc4/
>
> I should note that adding the packet numbers to the info column was not
> initially my intention. I was attempting to debug a sequence check in my
> code. This sequence check had a similar problem in that reassembled TCP
> packets would fail the sequence check becuase I was comparing against the
> first packet number rather than the subsequent packets.
>
> This issue is a continuation of the forum thread below. It was sugested to
> add it to the mailing list for some further assistance.
>
> http://ask.wireshark.org/questions/5382/custom-dissector-and-info-column
>
> I have uploaded the source code, build files, dll and an example log file
> extract to the following online storage repository.
>
> http://www.mediafire.com/?cr32k2cgox06r91
>
> Any help greatly appreciated.
>
> Regards,
> Chris
>
>
I added your dissector to my build, cut down the capture file to only include
frames 1 & 3 and attached a debugger to see what was happening.
This might be a bug. In the tcp reassembly code around line 2013 there is
code "if(another_pdu_follows)" that marks all columns as unwriteable. This is
being called after the pdu with the count value of 0x2700 has been processed,
so subsequent calls to add stuff into the info column fail. This pdu is the
one that's split over the 2 frames, so is being reassembled.
I'm not sure of the intent of this code, so can't confirm that it's a bug, or
working as intended.
--
Regards,
Graham Bloice
