Bug ID |
12006
|
Summary |
desegment_tcp can't defragment PDU if fragments come oit of order
|
Product |
Wireshark
|
Version |
Git
|
Hardware |
x86
|
OS |
All
|
Status |
CONFIRMED
|
Severity |
Major
|
Priority |
Low
|
Component |
Dissection engine (libwireshark)
|
Assignee |
[email protected]
|
Reporter |
[email protected]
|
Created attachment 14236 [details]
pcap file to illustrate the bug
Build Information:
TShark (Wireshark) 2.1.0 (v2.1.0rc0-1474-g1f0c9f6 from master)
Compiled (64-bit) with libpcap, with POSIX capabilities (Linux), with libnl 3,
with libz 1.2.8, with GLib 2.46.2, without SMI, without c-ares, without ADNS,
with Lua 5.2, with GnuTLS 3.3.17, with Gcrypt 1.6.3, with MIT Kerberos, without
GeoIP.
Running on Linux 4.3.2-gentoovit, with locale sv_SE.utf8, with libpcap version
1.7.4, with libz 1.2.8, with GnuTLS 3.3.17, with Gcrypt 1.6.3.
Intel(R) Core(TM)2 Duo CPU U9600 @ 1.60GHz
Built using gcc 4.9.3.
--
desegment_tcp function (dissectors/packet-tcp.c)) decides whether the new
packet continues the higher-level PDU or the normal dissector shall be called.
The logic is to find tcp_multisegment_pdu *msp in the
tcpd->fwd->multisegment_pdus tree:
msp = (struct
tcp_multisegment_pdu*)wmem_tree_lookup32_le(tcpd->fwd->multisegment_pdus,
seq-1);
If msp is not found, the normal dissector is called.
But in order for the packet to be classified as continuation of existing PDU
it's not enough for msp to be found. It requires the newly arrived packet to
contain the next part of PDU. [E.g. if we have got N parts of PDUs, newly
arrived segment shall carry (N+1)th PDU. Not (N+2)th or later]:
if (msp && msp->seq <= seq && msp->nxtpdu > seq) {
....
/* OK, this PDU was found, which means the segment continues
* a higher-level PDU and that we must desegment it.
*/
....
} else {
/* This segment was not found in our table, so it doesn't
* contain a continuation of a higher-level PDU.
* Call the normal subdissector.
*/
.....
}
As a result if the packet in the middle is missed the whole logic breaks - the
packet which comes is handled by normal dissector and does not become part of a
larger PDU (which was collected).
This behavior is visible with the pcap file attached to this bug.
(I added some debug logs):
desegment_tcp: 3, msp = 0x7f7701617ea0
desegment_tcp: msp->seq: 1, seq: 56936, msp->nxtpdu: 55529
As you see msp is not null, hence several fragments were collected.
But msp->nxtpdu < seq and this is the reason normal dissector is called.
As a result, the packet is not being dissected. The missed packet comes long
after (exists in pcap file) and client application (wget) perfectly handles the
situation. However, wireshark can not dissect this scenario.
I have to say that it's not some kind of network error - I constantly see this
scenario with news site (newsru.com) when I try to download its index page. I
tested from two different providers located in different countries. It looks
like it's the way they send the content and it is perfectly OK for the
browsers.
You are receiving this mail because:
- You are watching all bug changes.