[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wireshark-dev
Subject:    Re: [Wireshark-dev] Suppress [TCP segment of a reassembled PDU] in COL_INFO
From:       <david_aggeler () hispeed ! ch>
Date:       2019-02-11 10:05:11
Message-ID: 000a01d4c1f1$475ea0d0$d61be270$ () hispeed ! ch
[Download RAW message or body]


> -----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


[prev in list] [next in list] [prev in thread] [next in thread]