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.
