On Jun 3, 2018, at 10:30 AM, Peter Wu <[email protected]> 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 <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
