Wireshark-dev: Re: [Wireshark-dev] Suppress [TCP segment of a reassembled PDU] in COL_INFO
> -----Original Message-----
> From: Wireshark-dev <wireshark-dev-bounces@xxxxxxxxxxxxx> On Behalf
> Of Guy Harris
> Sent: Sunday, February 10, 2019 8:58 PM
> To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
> Subject: Re: [Wireshark-dev] Suppress [TCP segment of a reassembled PDU]
> in COL_INFO
>
> On Feb 10, 2019, at 11:44 AM, <david_aggeler@xxxxxxxxxx>
> <david_aggeler@xxxxxxxxxx> wrote:
>
> > I’m cleaning up the re-assembly in the DICOM decoder (I haven’t
> > touched it for years, so it was overdue) DICOM data elements are usually
> pretty big, and I need more than TCP level re-assembly.
> >
> > To have COL_INFO focus on what is relevant for DICOM, I’d like to suppress
> the postfix of “[TCP segment of a reassembled PDU]”.
>
> From the screenshot, I suspect the problem is that the frame in question
> contains data from more than one DICOM PDU, so that it contains the last
> octets of one DICOM PDU and the beginning octets of another PDU, and
> that, at the TCP reassembly layer, more data is needed for the second PDU.
>
> So, technically, that frame is a TCP segment of a (to be-)reassembled PDU.
That is correct. All of the frames flagged as '[TCP segment of a reassembled PDU]' are part of two DICOM PDUs
> However, given that it's the finishing segment of a PDU, at a layer above TCP,
> and thus would have information about *that* PDU, the fact that it also
> happens to be the first TCP segment of the PDU following that PDU is not of
> interest.
Ok. I can agree to that. This is the behavior since I know it, and I kind of assumed that
it job of the next level dissector to deal with it.
> Note that, except in the first paragraph, I didn't use the name "DICOM" - i.e.,
> this isn't a problem with DICOM, it's a problem with the TCP dissector; that's
> where the "[TCP segment of a reassembled PDU]” is generated, and that's
> where it needs to be suppressed.
>
> Please file a bug on that (and don't speak of it as a DICOM-specific problem,
> as the same problem could occur with any other protocol that runs over TCP).
I've submitted bug 15494 and attached the .pcap in question.
