Re: Enabling TCP Out-of-Order reassembly by default

[Guy Harris <guy () alum mit edu>]

On Jun 3, 2018, at 10:30 AM, Peter Wu <peter () lekensteyn nl> wrote:

> A long standing issue is that the TCP dissector is unable to reassemble
> out-of-order segments, resulting in missing HTTP objects and breaking
> TLS decryption (among other things).
>
> In order to tackle this, I wrote a patch to buffer segments until all
> missing segments are found: https://code.wireshark.org/review/27943
> (Reviews are welcome, especially for the User's Guide changes and the
> idea itself.)

I.e., leverage the existing reassembly code to handle out-of-order segments?

Yes, that's the right thing to do; I'd been thinking about the same thing.

> This behavior is currently disabled by default and put behind an
> additional preference. I was wondering though if you would be okay with
> enabling correct out-of-order handling by default.

If "Allow subdissector to reassemble TCP streams" is the default, I'd say that reassembling out-of-order segments 
should be the default as well.

> I could also make it depend on the "Allow subdissector to reassemble TCP
> streams" preference if desired. Then users who are only doing TCP
> analysis do not have to disable an additional preference.

That *might* make sense.  Some people *might* think it's weird that they can't have out-of-order segment handling 
without reassembly, however.  On the other hand, some *other* people might wonder why you'd *want* to have out-of-order 
segment handling without reassembly - I'm not sure in how many cases one of them would cause a problem but not the 
other.

___________________________________________________________________________
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