| Bug ID |
10841
|
| Summary |
Enhance TCAP session matching
|
| Product |
Wireshark
|
| Version |
Git
|
| Hardware |
x86
|
| OS |
Mac OS X 10.9
|
| Status |
UNCONFIRMED
|
| Severity |
Major
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Created attachment 13379 [details]
tcap-confirm-forwardsm.erf
Build Information:
TShark (Wireshark) 1.99.2 (v1.99.2rc0-536-g5d610b5 from master)
Copyright 1998-2015 Gerald Combs <[email protected]> and contributors.
License GPLv2+: GNU GPL version 2 or later
<http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with libpcap, without POSIX capabilities, with libz 1.2.5,
with GLib 2.42.1, with SMI 0.4.8, with c-ares 1.10.0, without Lua, with GnuTLS
3.3.11, with Gcrypt 1.6.2, with MIT Kerberos, without GeoIP.
Running on Mac OS X 10.10.1, build 14B25 (Darwin 14.0.0), with locale
C/en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/en_US.UTF-8, with libpcap
version 1.5.3 - Apple version 47, with libz 1.2.5, with GnuTLS 3.3.11, with
Gcrypt 1.6.2.
Intel(R) Core(TM) i7-4650U CPU @ 1.70GHz (with SSE4.2)
Built using clang 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.54).
--
TCAP session matching doesn't cope with TCAP dialogue confirmation.
See ITU-T Q.771 (06/97) clause 3.1.2.2.2.2 "Confirmation of the dialogue" for
more details.
This is because the current implementation uses the destination address for
TCAP BEGIN matching (tcaphash_begin_info_key_t.dpc_hash), and origin address
for TCAP END matching (tcaphash_end_info_key_t.opc_hash).
When TCAP sessions (transactions) aren't correctly matched, then higher level
dissectors can mistakenly decode packets part-way through the session because
of assumptions about protocol versions (etc).
There are other Wireshark bugs in TCAP (and higher layer) that may be fixed by
addressing this.
I'll attach a sanitised ERF test containing an mo-forwardSM SMS over 4 packets.
The preference erf.hdlc_type:SS7 MTP2 must be set to process the ERF as
erf:mtp2:mtp3:sccp:tcap ...
In order to exercise the session matching, the following options were used with
tshark:
-o 'erf.hdlc_type:SS7 MTP2' -o sccp.set_addresses:TRUE -o tcap.srt:TRUE -o
tcap.persistentsrt:TRUE
The existing behaviour doesn't correctly decode the IMSI in packet 3 because
the Application Context isn't known at that point (it's in the dialogue setup
in packets 1 & 2 as "shortMsgMO-RelayContext-v3").
The packets past the first don't display a TCAP [Session ID:] either.
You are receiving this mail because:
- You are watching all bug changes.