Wireshark mailing list archives
Re: Enabling TCP Out-of-Order reassembly by default
From: Peter Wu <peter () lekensteyn nl>
Date: Sun, 3 Jun 2018 22:36:08 +0200
On Sun, Jun 03, 2018 at 11:02:58AM -0700, Guy Harris wrote:
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 it does, the actual code change is rather small since the reassembly API performs tracking. Most of the LoC are from comments, documentation and tests.
Yes, that's the right thing to do; I'd been thinking about the same thing.
If possible, please check if the code (and documentation) matches what you would do (or whether it should be done in a different way).
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.
OK, I'll enable it by default then. There are some known (documented) edge cases were the setting causes issues, but users are more likely to encounter OoO issues I think.
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.
Implementation-wise both options independently have some effect, but indeed it seems strange to enable OoO handling, but at the same time disable reassembly. I guess I'll go for making OoO depend on reassembly. That way, if you would like to make sure that segments are dissected independently, then only one preference has to be toggled. -- Kind regards, Peter Wu https://lekensteyn.nl ___________________________________________________________________________ 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
Current thread:
- Enabling TCP Out-of-Order reassembly by default Peter Wu (Jun 03)
- Re: Enabling TCP Out-of-Order reassembly by default Guy Harris (Jun 03)
- Re: Enabling TCP Out-of-Order reassembly by default Peter Wu (Jun 03)
- Re: Enabling TCP Out-of-Order reassembly by default Guy Harris (Jun 03)