Re: Suppress [TCP segment of a reassembled PDU] in COL_INFO

[<david_aggeler () hispeed ch>]

> -----Original Message-----
> From: Wireshark-dev <wireshark-dev-bounces () wireshark org> On Behalf
> Of Guy Harris
> Sent: Sunday, February 10, 2019 8:58 PM
> To: Developer support list for Wireshark <wireshark-dev () wireshark org>
> Subject: Re: [Wireshark-dev] Suppress [TCP segment of a reassembled PDU]
> in COL_INFO
>
> On Feb 10, 2019, at 11:44 AM, <david_aggeler () hispeed ch>
> <david_aggeler () hispeed ch> 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. 


___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe