2018-04-03 00:12:23 +00:00
|
|
|
#
|
2018-04-27 17:35:17 +00:00
|
|
|
# -*- coding: utf-8 -*-
|
2018-04-03 00:12:23 +00:00
|
|
|
# Wireshark tests
|
|
|
|
# By Gerald Combs <gerald@wireshark.org>
|
|
|
|
#
|
|
|
|
# Ported from a set of Bash scripts which were copyright 2005 Ulf Lamping
|
|
|
|
#
|
|
|
|
# SPDX-License-Identifier: GPL-2.0-or-later
|
|
|
|
#
|
|
|
|
'''Dissection tests'''
|
|
|
|
|
|
|
|
import os.path
|
|
|
|
import subprocesstest
|
|
|
|
import unittest
|
2018-10-15 14:07:30 +00:00
|
|
|
import fixtures
|
2018-04-03 00:12:23 +00:00
|
|
|
|
2018-10-15 14:07:30 +00:00
|
|
|
@fixtures.mark_usefixtures('test_env')
|
|
|
|
@fixtures.uses_fixtures
|
2018-04-03 00:12:23 +00:00
|
|
|
class case_dissect_http2(subprocesstest.SubprocessTestCase):
|
2018-11-13 01:17:33 +00:00
|
|
|
def test_http2_data_reassembly(self, cmd_tshark, features, dirs, capture_file):
|
2018-04-03 00:12:23 +00:00
|
|
|
'''HTTP2 data reassembly'''
|
2018-10-15 14:07:30 +00:00
|
|
|
if not features.have_nghttp2:
|
2018-04-03 00:12:23 +00:00
|
|
|
self.skipTest('Requires nghttp2.')
|
2018-10-15 14:07:30 +00:00
|
|
|
key_file = os.path.join(dirs.key_dir, 'http2-data-reassembly.keys')
|
|
|
|
self.runProcess((cmd_tshark,
|
2018-11-13 01:17:33 +00:00
|
|
|
'-r', capture_file('http2-data-reassembly.pcap'),
|
2018-09-13 15:40:27 +00:00
|
|
|
'-o', 'tls.keylog_file: {}'.format(key_file),
|
|
|
|
'-d', 'tcp.port==8443,tls',
|
2018-04-03 00:12:23 +00:00
|
|
|
'-Y', 'http2.data.data matches "PNG" && http2.data.data matches "END"',
|
2018-10-15 14:07:30 +00:00
|
|
|
))
|
2018-04-03 00:12:23 +00:00
|
|
|
self.assertTrue(self.grepOutput('DATA'))
|
tcp: add support for reassembling out-of-order segments
Currently out-of-order segments will result in cutting a stream into
two pieces while the out-of-order segment itself is ignored. For
example, a stream of segments "ABDCE" is interpreted as "AB", "DE" with
"C" ignored. This behavior breaks TLS decryption or prevent application
layer PDUs (such as HTTP requests/responses) from being reconstructed.
To fix this, buffer segments when a gap is detected.
The proposed approach extends the "multi-segment PDU" (MSP) mechanism
which is normally used for linking multiple, sequential TCP segments
into a single PDU. When a gap is detected between segments, it is
assumed that the segments within this gap are out-of-order and will be
received (or retransmitted) later.
The current implementation has a limitation though, if multiple gaps
exist, then the subdissector will only be called when all gaps are
filled (the subdissector will receive segments later than necessary).
For example with "ACEBD", "ABC" can already be processed after "B" is
received (with "E" still buffered), but due to how MSP are extended, it
must receive "D" too before it reassembles "ABCDE". In practice this
could mean that the request/response times between HTTP requests and
responses are slightly off, but at least the stream is correct now.
(These limitations are documented in the User's Guide.)
As the feature fails at least the 802.11 decryption test where packets
are missing (instead of OoO), hide this feature behind a preference.
Tested with captures containing out-of-order TCP segments from the
linked bug reports, comparing the effect of toggling the preference on
the summary output of tshark, the verbose output (-V) and the two-pass
output (-2 or -2V). Captures marked with "ok" just needed "simple"
out-of-order handling. Captures marked with "ok2" additionally required
the reassembly API change to set the correct reassembled length.
This change does "regress" on bug 10289 though when the preference is
enabled as retransmitted single-segment PDUs are now passed to
subdissectors. I added a TODO comment for this unrelated cosmetic issue.
Bug: 3389 # capture 2907 (HTTP) ok
Bug: 4727 # capture 4590 (HTTP) ok
Bug: 9461 # capture 12130 (TLS/HTTP/RPC-over-HTTP +key 12131) ok
Bug: 12006 # capture 14236 (HTTP) ok2; capture 15261 (HTTP) ok
Bug: 13517 # capture 15370 (HTTP) ok; capture 16059 (MQ) ok
Bug: 13754 # capture 15593 (MySQL) ok2
Bug: 14649 # capture 16305 (WebSocket) ok
Change-Id: If3938c5c1c96db8f7f50e39ea779f623ce657d56
Reviewed-on: https://code.wireshark.org/review/27943
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-06-01 13:11:47 +00:00
|
|
|
|
2018-10-15 14:07:30 +00:00
|
|
|
@fixtures.mark_usefixtures('test_env')
|
|
|
|
@fixtures.uses_fixtures
|
tcp: add support for reassembling out-of-order segments
Currently out-of-order segments will result in cutting a stream into
two pieces while the out-of-order segment itself is ignored. For
example, a stream of segments "ABDCE" is interpreted as "AB", "DE" with
"C" ignored. This behavior breaks TLS decryption or prevent application
layer PDUs (such as HTTP requests/responses) from being reconstructed.
To fix this, buffer segments when a gap is detected.
The proposed approach extends the "multi-segment PDU" (MSP) mechanism
which is normally used for linking multiple, sequential TCP segments
into a single PDU. When a gap is detected between segments, it is
assumed that the segments within this gap are out-of-order and will be
received (or retransmitted) later.
The current implementation has a limitation though, if multiple gaps
exist, then the subdissector will only be called when all gaps are
filled (the subdissector will receive segments later than necessary).
For example with "ACEBD", "ABC" can already be processed after "B" is
received (with "E" still buffered), but due to how MSP are extended, it
must receive "D" too before it reassembles "ABCDE". In practice this
could mean that the request/response times between HTTP requests and
responses are slightly off, but at least the stream is correct now.
(These limitations are documented in the User's Guide.)
As the feature fails at least the 802.11 decryption test where packets
are missing (instead of OoO), hide this feature behind a preference.
Tested with captures containing out-of-order TCP segments from the
linked bug reports, comparing the effect of toggling the preference on
the summary output of tshark, the verbose output (-V) and the two-pass
output (-2 or -2V). Captures marked with "ok" just needed "simple"
out-of-order handling. Captures marked with "ok2" additionally required
the reassembly API change to set the correct reassembled length.
This change does "regress" on bug 10289 though when the preference is
enabled as retransmitted single-segment PDUs are now passed to
subdissectors. I added a TODO comment for this unrelated cosmetic issue.
Bug: 3389 # capture 2907 (HTTP) ok
Bug: 4727 # capture 4590 (HTTP) ok
Bug: 9461 # capture 12130 (TLS/HTTP/RPC-over-HTTP +key 12131) ok
Bug: 12006 # capture 14236 (HTTP) ok2; capture 15261 (HTTP) ok
Bug: 13517 # capture 15370 (HTTP) ok; capture 16059 (MQ) ok
Bug: 13754 # capture 15593 (MySQL) ok2
Bug: 14649 # capture 16305 (WebSocket) ok
Change-Id: If3938c5c1c96db8f7f50e39ea779f623ce657d56
Reviewed-on: https://code.wireshark.org/review/27943
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-06-01 13:11:47 +00:00
|
|
|
class case_dissect_tcp(subprocesstest.SubprocessTestCase):
|
2018-10-15 14:07:30 +00:00
|
|
|
def check_tcp_out_of_order(self, cmd_tshark, dirs, extraArgs=[]):
|
|
|
|
capture_file = os.path.join(dirs.capture_dir, 'http-ooo.pcap')
|
|
|
|
self.runProcess([cmd_tshark,
|
tcp: add support for reassembling out-of-order segments
Currently out-of-order segments will result in cutting a stream into
two pieces while the out-of-order segment itself is ignored. For
example, a stream of segments "ABDCE" is interpreted as "AB", "DE" with
"C" ignored. This behavior breaks TLS decryption or prevent application
layer PDUs (such as HTTP requests/responses) from being reconstructed.
To fix this, buffer segments when a gap is detected.
The proposed approach extends the "multi-segment PDU" (MSP) mechanism
which is normally used for linking multiple, sequential TCP segments
into a single PDU. When a gap is detected between segments, it is
assumed that the segments within this gap are out-of-order and will be
received (or retransmitted) later.
The current implementation has a limitation though, if multiple gaps
exist, then the subdissector will only be called when all gaps are
filled (the subdissector will receive segments later than necessary).
For example with "ACEBD", "ABC" can already be processed after "B" is
received (with "E" still buffered), but due to how MSP are extended, it
must receive "D" too before it reassembles "ABCDE". In practice this
could mean that the request/response times between HTTP requests and
responses are slightly off, but at least the stream is correct now.
(These limitations are documented in the User's Guide.)
As the feature fails at least the 802.11 decryption test where packets
are missing (instead of OoO), hide this feature behind a preference.
Tested with captures containing out-of-order TCP segments from the
linked bug reports, comparing the effect of toggling the preference on
the summary output of tshark, the verbose output (-V) and the two-pass
output (-2 or -2V). Captures marked with "ok" just needed "simple"
out-of-order handling. Captures marked with "ok2" additionally required
the reassembly API change to set the correct reassembled length.
This change does "regress" on bug 10289 though when the preference is
enabled as retransmitted single-segment PDUs are now passed to
subdissectors. I added a TODO comment for this unrelated cosmetic issue.
Bug: 3389 # capture 2907 (HTTP) ok
Bug: 4727 # capture 4590 (HTTP) ok
Bug: 9461 # capture 12130 (TLS/HTTP/RPC-over-HTTP +key 12131) ok
Bug: 12006 # capture 14236 (HTTP) ok2; capture 15261 (HTTP) ok
Bug: 13517 # capture 15370 (HTTP) ok; capture 16059 (MQ) ok
Bug: 13754 # capture 15593 (MySQL) ok2
Bug: 14649 # capture 16305 (WebSocket) ok
Change-Id: If3938c5c1c96db8f7f50e39ea779f623ce657d56
Reviewed-on: https://code.wireshark.org/review/27943
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-06-01 13:11:47 +00:00
|
|
|
'-r', capture_file,
|
|
|
|
'-otcp.reassemble_out_of_order:TRUE',
|
|
|
|
'-Y', 'http',
|
2018-10-15 14:07:30 +00:00
|
|
|
] + extraArgs)
|
tcp: add support for reassembling out-of-order segments
Currently out-of-order segments will result in cutting a stream into
two pieces while the out-of-order segment itself is ignored. For
example, a stream of segments "ABDCE" is interpreted as "AB", "DE" with
"C" ignored. This behavior breaks TLS decryption or prevent application
layer PDUs (such as HTTP requests/responses) from being reconstructed.
To fix this, buffer segments when a gap is detected.
The proposed approach extends the "multi-segment PDU" (MSP) mechanism
which is normally used for linking multiple, sequential TCP segments
into a single PDU. When a gap is detected between segments, it is
assumed that the segments within this gap are out-of-order and will be
received (or retransmitted) later.
The current implementation has a limitation though, if multiple gaps
exist, then the subdissector will only be called when all gaps are
filled (the subdissector will receive segments later than necessary).
For example with "ACEBD", "ABC" can already be processed after "B" is
received (with "E" still buffered), but due to how MSP are extended, it
must receive "D" too before it reassembles "ABCDE". In practice this
could mean that the request/response times between HTTP requests and
responses are slightly off, but at least the stream is correct now.
(These limitations are documented in the User's Guide.)
As the feature fails at least the 802.11 decryption test where packets
are missing (instead of OoO), hide this feature behind a preference.
Tested with captures containing out-of-order TCP segments from the
linked bug reports, comparing the effect of toggling the preference on
the summary output of tshark, the verbose output (-V) and the two-pass
output (-2 or -2V). Captures marked with "ok" just needed "simple"
out-of-order handling. Captures marked with "ok2" additionally required
the reassembly API change to set the correct reassembled length.
This change does "regress" on bug 10289 though when the preference is
enabled as retransmitted single-segment PDUs are now passed to
subdissectors. I added a TODO comment for this unrelated cosmetic issue.
Bug: 3389 # capture 2907 (HTTP) ok
Bug: 4727 # capture 4590 (HTTP) ok
Bug: 9461 # capture 12130 (TLS/HTTP/RPC-over-HTTP +key 12131) ok
Bug: 12006 # capture 14236 (HTTP) ok2; capture 15261 (HTTP) ok
Bug: 13517 # capture 15370 (HTTP) ok; capture 16059 (MQ) ok
Bug: 13754 # capture 15593 (MySQL) ok2
Bug: 14649 # capture 16305 (WebSocket) ok
Change-Id: If3938c5c1c96db8f7f50e39ea779f623ce657d56
Reviewed-on: https://code.wireshark.org/review/27943
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-06-01 13:11:47 +00:00
|
|
|
self.assertEqual(self.countOutput('HTTP'), 5)
|
|
|
|
# TODO PDU /1 (segments in frames 1, 2, 4) should be reassembled in
|
|
|
|
# frame 4, but it is currently done in frame 6 because the current
|
|
|
|
# implementation reassembles only contiguous segments and PDU /2 has
|
|
|
|
# segments in frames 6, 3, 7.
|
|
|
|
self.assertTrue(self.grepOutput(r'^\s*6\s.*PUT /1 HTTP/1.1'))
|
|
|
|
self.assertTrue(self.grepOutput(r'^\s*7\s.*GET /2 HTTP/1.1'))
|
|
|
|
self.assertTrue(self.grepOutput(r'^\s*10\s.*PUT /3 HTTP/1.1'))
|
|
|
|
self.assertTrue(self.grepOutput(r'^\s*11\s.*PUT /4 HTTP/1.1'))
|
|
|
|
self.assertTrue(self.grepOutput(r'^\s*15\s.*PUT /5 HTTP/1.1'))
|
|
|
|
|
2018-10-15 14:07:30 +00:00
|
|
|
def test_tcp_out_of_order_onepass(self, cmd_tshark, dirs):
|
|
|
|
self.check_tcp_out_of_order(cmd_tshark, dirs)
|
tcp: add support for reassembling out-of-order segments
Currently out-of-order segments will result in cutting a stream into
two pieces while the out-of-order segment itself is ignored. For
example, a stream of segments "ABDCE" is interpreted as "AB", "DE" with
"C" ignored. This behavior breaks TLS decryption or prevent application
layer PDUs (such as HTTP requests/responses) from being reconstructed.
To fix this, buffer segments when a gap is detected.
The proposed approach extends the "multi-segment PDU" (MSP) mechanism
which is normally used for linking multiple, sequential TCP segments
into a single PDU. When a gap is detected between segments, it is
assumed that the segments within this gap are out-of-order and will be
received (or retransmitted) later.
The current implementation has a limitation though, if multiple gaps
exist, then the subdissector will only be called when all gaps are
filled (the subdissector will receive segments later than necessary).
For example with "ACEBD", "ABC" can already be processed after "B" is
received (with "E" still buffered), but due to how MSP are extended, it
must receive "D" too before it reassembles "ABCDE". In practice this
could mean that the request/response times between HTTP requests and
responses are slightly off, but at least the stream is correct now.
(These limitations are documented in the User's Guide.)
As the feature fails at least the 802.11 decryption test where packets
are missing (instead of OoO), hide this feature behind a preference.
Tested with captures containing out-of-order TCP segments from the
linked bug reports, comparing the effect of toggling the preference on
the summary output of tshark, the verbose output (-V) and the two-pass
output (-2 or -2V). Captures marked with "ok" just needed "simple"
out-of-order handling. Captures marked with "ok2" additionally required
the reassembly API change to set the correct reassembled length.
This change does "regress" on bug 10289 though when the preference is
enabled as retransmitted single-segment PDUs are now passed to
subdissectors. I added a TODO comment for this unrelated cosmetic issue.
Bug: 3389 # capture 2907 (HTTP) ok
Bug: 4727 # capture 4590 (HTTP) ok
Bug: 9461 # capture 12130 (TLS/HTTP/RPC-over-HTTP +key 12131) ok
Bug: 12006 # capture 14236 (HTTP) ok2; capture 15261 (HTTP) ok
Bug: 13517 # capture 15370 (HTTP) ok; capture 16059 (MQ) ok
Bug: 13754 # capture 15593 (MySQL) ok2
Bug: 14649 # capture 16305 (WebSocket) ok
Change-Id: If3938c5c1c96db8f7f50e39ea779f623ce657d56
Reviewed-on: https://code.wireshark.org/review/27943
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-06-01 13:11:47 +00:00
|
|
|
|
|
|
|
@unittest.skip("MSP splitting is not implemented yet")
|
2018-10-15 14:07:30 +00:00
|
|
|
def test_tcp_out_of_order_twopass(self, cmd_tshark, dirs):
|
|
|
|
self.check_tcp_out_of_order(cmd_tshark, dirs, extraArgs=['-2'])
|
tcp: add support for reassembling out-of-order segments
Currently out-of-order segments will result in cutting a stream into
two pieces while the out-of-order segment itself is ignored. For
example, a stream of segments "ABDCE" is interpreted as "AB", "DE" with
"C" ignored. This behavior breaks TLS decryption or prevent application
layer PDUs (such as HTTP requests/responses) from being reconstructed.
To fix this, buffer segments when a gap is detected.
The proposed approach extends the "multi-segment PDU" (MSP) mechanism
which is normally used for linking multiple, sequential TCP segments
into a single PDU. When a gap is detected between segments, it is
assumed that the segments within this gap are out-of-order and will be
received (or retransmitted) later.
The current implementation has a limitation though, if multiple gaps
exist, then the subdissector will only be called when all gaps are
filled (the subdissector will receive segments later than necessary).
For example with "ACEBD", "ABC" can already be processed after "B" is
received (with "E" still buffered), but due to how MSP are extended, it
must receive "D" too before it reassembles "ABCDE". In practice this
could mean that the request/response times between HTTP requests and
responses are slightly off, but at least the stream is correct now.
(These limitations are documented in the User's Guide.)
As the feature fails at least the 802.11 decryption test where packets
are missing (instead of OoO), hide this feature behind a preference.
Tested with captures containing out-of-order TCP segments from the
linked bug reports, comparing the effect of toggling the preference on
the summary output of tshark, the verbose output (-V) and the two-pass
output (-2 or -2V). Captures marked with "ok" just needed "simple"
out-of-order handling. Captures marked with "ok2" additionally required
the reassembly API change to set the correct reassembled length.
This change does "regress" on bug 10289 though when the preference is
enabled as retransmitted single-segment PDUs are now passed to
subdissectors. I added a TODO comment for this unrelated cosmetic issue.
Bug: 3389 # capture 2907 (HTTP) ok
Bug: 4727 # capture 4590 (HTTP) ok
Bug: 9461 # capture 12130 (TLS/HTTP/RPC-over-HTTP +key 12131) ok
Bug: 12006 # capture 14236 (HTTP) ok2; capture 15261 (HTTP) ok
Bug: 13517 # capture 15370 (HTTP) ok; capture 16059 (MQ) ok
Bug: 13754 # capture 15593 (MySQL) ok2
Bug: 14649 # capture 16305 (WebSocket) ok
Change-Id: If3938c5c1c96db8f7f50e39ea779f623ce657d56
Reviewed-on: https://code.wireshark.org/review/27943
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-06-01 13:11:47 +00:00
|
|
|
|
2018-11-13 01:17:33 +00:00
|
|
|
def test_tcp_out_of_order_twopass_with_bug(self, cmd_tshark, capture_file):
|
tcp: add support for reassembling out-of-order segments
Currently out-of-order segments will result in cutting a stream into
two pieces while the out-of-order segment itself is ignored. For
example, a stream of segments "ABDCE" is interpreted as "AB", "DE" with
"C" ignored. This behavior breaks TLS decryption or prevent application
layer PDUs (such as HTTP requests/responses) from being reconstructed.
To fix this, buffer segments when a gap is detected.
The proposed approach extends the "multi-segment PDU" (MSP) mechanism
which is normally used for linking multiple, sequential TCP segments
into a single PDU. When a gap is detected between segments, it is
assumed that the segments within this gap are out-of-order and will be
received (or retransmitted) later.
The current implementation has a limitation though, if multiple gaps
exist, then the subdissector will only be called when all gaps are
filled (the subdissector will receive segments later than necessary).
For example with "ACEBD", "ABC" can already be processed after "B" is
received (with "E" still buffered), but due to how MSP are extended, it
must receive "D" too before it reassembles "ABCDE". In practice this
could mean that the request/response times between HTTP requests and
responses are slightly off, but at least the stream is correct now.
(These limitations are documented in the User's Guide.)
As the feature fails at least the 802.11 decryption test where packets
are missing (instead of OoO), hide this feature behind a preference.
Tested with captures containing out-of-order TCP segments from the
linked bug reports, comparing the effect of toggling the preference on
the summary output of tshark, the verbose output (-V) and the two-pass
output (-2 or -2V). Captures marked with "ok" just needed "simple"
out-of-order handling. Captures marked with "ok2" additionally required
the reassembly API change to set the correct reassembled length.
This change does "regress" on bug 10289 though when the preference is
enabled as retransmitted single-segment PDUs are now passed to
subdissectors. I added a TODO comment for this unrelated cosmetic issue.
Bug: 3389 # capture 2907 (HTTP) ok
Bug: 4727 # capture 4590 (HTTP) ok
Bug: 9461 # capture 12130 (TLS/HTTP/RPC-over-HTTP +key 12131) ok
Bug: 12006 # capture 14236 (HTTP) ok2; capture 15261 (HTTP) ok
Bug: 13517 # capture 15370 (HTTP) ok; capture 16059 (MQ) ok
Bug: 13754 # capture 15593 (MySQL) ok2
Bug: 14649 # capture 16305 (WebSocket) ok
Change-Id: If3938c5c1c96db8f7f50e39ea779f623ce657d56
Reviewed-on: https://code.wireshark.org/review/27943
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-06-01 13:11:47 +00:00
|
|
|
# TODO fix the issue below, remove this and enable
|
|
|
|
# "test_tcp_out_of_order_twopass"
|
2018-10-15 14:07:30 +00:00
|
|
|
self.runProcess((cmd_tshark,
|
2018-11-13 01:17:33 +00:00
|
|
|
'-r', capture_file('http-ooo.pcap'),
|
tcp: add support for reassembling out-of-order segments
Currently out-of-order segments will result in cutting a stream into
two pieces while the out-of-order segment itself is ignored. For
example, a stream of segments "ABDCE" is interpreted as "AB", "DE" with
"C" ignored. This behavior breaks TLS decryption or prevent application
layer PDUs (such as HTTP requests/responses) from being reconstructed.
To fix this, buffer segments when a gap is detected.
The proposed approach extends the "multi-segment PDU" (MSP) mechanism
which is normally used for linking multiple, sequential TCP segments
into a single PDU. When a gap is detected between segments, it is
assumed that the segments within this gap are out-of-order and will be
received (or retransmitted) later.
The current implementation has a limitation though, if multiple gaps
exist, then the subdissector will only be called when all gaps are
filled (the subdissector will receive segments later than necessary).
For example with "ACEBD", "ABC" can already be processed after "B" is
received (with "E" still buffered), but due to how MSP are extended, it
must receive "D" too before it reassembles "ABCDE". In practice this
could mean that the request/response times between HTTP requests and
responses are slightly off, but at least the stream is correct now.
(These limitations are documented in the User's Guide.)
As the feature fails at least the 802.11 decryption test where packets
are missing (instead of OoO), hide this feature behind a preference.
Tested with captures containing out-of-order TCP segments from the
linked bug reports, comparing the effect of toggling the preference on
the summary output of tshark, the verbose output (-V) and the two-pass
output (-2 or -2V). Captures marked with "ok" just needed "simple"
out-of-order handling. Captures marked with "ok2" additionally required
the reassembly API change to set the correct reassembled length.
This change does "regress" on bug 10289 though when the preference is
enabled as retransmitted single-segment PDUs are now passed to
subdissectors. I added a TODO comment for this unrelated cosmetic issue.
Bug: 3389 # capture 2907 (HTTP) ok
Bug: 4727 # capture 4590 (HTTP) ok
Bug: 9461 # capture 12130 (TLS/HTTP/RPC-over-HTTP +key 12131) ok
Bug: 12006 # capture 14236 (HTTP) ok2; capture 15261 (HTTP) ok
Bug: 13517 # capture 15370 (HTTP) ok; capture 16059 (MQ) ok
Bug: 13754 # capture 15593 (MySQL) ok2
Bug: 14649 # capture 16305 (WebSocket) ok
Change-Id: If3938c5c1c96db8f7f50e39ea779f623ce657d56
Reviewed-on: https://code.wireshark.org/review/27943
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-06-01 13:11:47 +00:00
|
|
|
'-otcp.reassemble_out_of_order:TRUE',
|
|
|
|
'-Y', 'http',
|
|
|
|
'-2',
|
2018-10-15 14:07:30 +00:00
|
|
|
))
|
tcp: add support for reassembling out-of-order segments
Currently out-of-order segments will result in cutting a stream into
two pieces while the out-of-order segment itself is ignored. For
example, a stream of segments "ABDCE" is interpreted as "AB", "DE" with
"C" ignored. This behavior breaks TLS decryption or prevent application
layer PDUs (such as HTTP requests/responses) from being reconstructed.
To fix this, buffer segments when a gap is detected.
The proposed approach extends the "multi-segment PDU" (MSP) mechanism
which is normally used for linking multiple, sequential TCP segments
into a single PDU. When a gap is detected between segments, it is
assumed that the segments within this gap are out-of-order and will be
received (or retransmitted) later.
The current implementation has a limitation though, if multiple gaps
exist, then the subdissector will only be called when all gaps are
filled (the subdissector will receive segments later than necessary).
For example with "ACEBD", "ABC" can already be processed after "B" is
received (with "E" still buffered), but due to how MSP are extended, it
must receive "D" too before it reassembles "ABCDE". In practice this
could mean that the request/response times between HTTP requests and
responses are slightly off, but at least the stream is correct now.
(These limitations are documented in the User's Guide.)
As the feature fails at least the 802.11 decryption test where packets
are missing (instead of OoO), hide this feature behind a preference.
Tested with captures containing out-of-order TCP segments from the
linked bug reports, comparing the effect of toggling the preference on
the summary output of tshark, the verbose output (-V) and the two-pass
output (-2 or -2V). Captures marked with "ok" just needed "simple"
out-of-order handling. Captures marked with "ok2" additionally required
the reassembly API change to set the correct reassembled length.
This change does "regress" on bug 10289 though when the preference is
enabled as retransmitted single-segment PDUs are now passed to
subdissectors. I added a TODO comment for this unrelated cosmetic issue.
Bug: 3389 # capture 2907 (HTTP) ok
Bug: 4727 # capture 4590 (HTTP) ok
Bug: 9461 # capture 12130 (TLS/HTTP/RPC-over-HTTP +key 12131) ok
Bug: 12006 # capture 14236 (HTTP) ok2; capture 15261 (HTTP) ok
Bug: 13517 # capture 15370 (HTTP) ok; capture 16059 (MQ) ok
Bug: 13754 # capture 15593 (MySQL) ok2
Bug: 14649 # capture 16305 (WebSocket) ok
Change-Id: If3938c5c1c96db8f7f50e39ea779f623ce657d56
Reviewed-on: https://code.wireshark.org/review/27943
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-06-01 13:11:47 +00:00
|
|
|
self.assertEqual(self.countOutput('HTTP'), 3)
|
|
|
|
self.assertTrue(self.grepOutput(r'^\s*7\s.*PUT /1 HTTP/1.1'))
|
|
|
|
self.assertTrue(self.grepOutput(r'^\s*7\s.*GET /2 HTTP/1.1'))
|
|
|
|
# TODO ideally this should not be concatenated.
|
|
|
|
# Normally a multi-segment PDU (MSP) covers only a single PDU, but OoO
|
|
|
|
# segments can extend MSP such that it covers two (or even more) PDUs.
|
|
|
|
# Until MSP splitting is implemented, two PDUs are shown in a single
|
|
|
|
# packet (and in case of -2, they are only shown in the last packet).
|
|
|
|
self.assertTrue(self.grepOutput(r'^\s*11\s.*PUT /3 HTTP/1.1'))
|
|
|
|
self.assertTrue(self.grepOutput(r'^\s*11\s.*PUT /4 HTTP/1.1'))
|
|
|
|
self.assertTrue(self.grepOutput(r'^\s*15\s.*PUT /5 HTTP/1.1'))
|
2018-08-27 13:31:03 +00:00
|
|
|
|
2018-11-13 01:17:33 +00:00
|
|
|
def test_tcp_out_of_order_data_after_syn(self, cmd_tshark, capture_file):
|
2018-08-27 13:31:03 +00:00
|
|
|
'''Test when the first non-empty segment is OoO.'''
|
2018-10-15 14:07:30 +00:00
|
|
|
proc = self.runProcess((cmd_tshark,
|
2018-11-13 01:17:33 +00:00
|
|
|
'-r', capture_file('dns-ooo.pcap'),
|
2018-08-27 13:31:03 +00:00
|
|
|
'-otcp.reassemble_out_of_order:TRUE',
|
|
|
|
'-Y', 'dns', '-Tfields', '-edns.qry.name',
|
2018-10-15 14:07:30 +00:00
|
|
|
))
|
2018-08-27 13:31:03 +00:00
|
|
|
self.assertEqual(proc.stdout_str.strip(), 'example.com')
|