Wireshark-dev: Re: [Wireshark-dev] Enabling TCP Out-of-Order reassembly by default
From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Sun, 3 Jun 2018 11:02:58 -0700
On Jun 3, 2018, at 10:30 AM, Peter Wu <peter@xxxxxxxxxxxxx> 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.