Wireshark-bugs: [Wireshark-bugs] [Bug 7653] New: ANSI TCAP Return Result message is matched with
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7653
Summary: ANSI TCAP Return Result message is matched with the
wrong invoke when IDs are reused
Product: Wireshark
Version: 1.8.1
Platform: x86
OS/Version: Windows 7
Status: NEW
Severity: Major
Priority: Low
Component: Dissection engine (libwireshark)
AssignedTo: bugzilla-admin@xxxxxxxxxxxxx
ReportedBy: allan.lawrie@xxxxxxxxxx
Build Information:
Version 1.8.1 (SVN Rev 43946 from /trunk-1.8)
Copyright 1998-2012 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
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 GTK+ 2.24.10, with Cairo 1.10.2, with Pango 1.30.0, with
GLib 2.32.2, with WinPcap (4_1_2), with libz 1.2.5, without POSIX capabilities,
with SMI 0.4.8, with c-ares 1.7.1, with Lua 5.1, without Python, with GnuTLS
2.12.18, with Gcrypt 1.4.6, without Kerberos, with GeoIP, with PortAudio
V19-devel (built Jul 23 2012), with AirPcap.
Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version
4.1.2 (packet.dll version 4.1.0.2001), based on libpcap version 1.0 branch
1_0_rel0b (20091008), GnuTLS 2.12.18, Gcrypt 1.4.6, without AirPcap.
Built using Microsoft Visual C++ 10.0 build 40219
--
I'm getting decodes that display the return result for an ANLYZD as whatever
was decoded in an earlier packet with a matching TCAP ID.
Here's one edited example, using the text decode and some hex to show the
message going wrong:
Earlier in the data this is seen, using the same TCAP ID:
No. Time Protocol Length
1647 2012-06-06 01:18:33.628606 ANSI MAP 266
T Disconnect Invoke
...
ANSI Transaction Capabilities Application Part
queryWithPerm
identifier: 61060e24
componentPortion: 1 item
ComponentPDU: invokeLast (9)
invokeLast
componentIDs: 59
operationCode: private (17)
private: 2390 T Disconnect
ANSI Mobile Application Part
tDisconnect
triggerType: t-Disconnect (70)
...
No. Time Protocol Length
1656 2012-06-06 01:18:33.783474 ANSI MAP 326
T Disconnect ReturnResult
T Disconnect ReturnResult
...
Data: e40fc70461060e24e807ea05cf0159f200
Padding: 000000
ANSI Transaction Capabilities Application Part
response
identifier: 61060e24
componentPortion: 1 item
ComponentPDU: returnResultLast (10)
returnResultLast
componentID: 59
[private: 2390 T Disconnect]
ANSI Mobile Application Part
tDisconnectRes
...
These two messages are fine. The return result is generic and correctly
identified as being a tDisconnectRes for the earlier packet.
e40f c704 61060e24 e807 ea05 cf01 59 f200
Later on the TCAP ID is reused. This starts as expected with:
No. Time Protocol Length
22168 2012-06-06 01:22:22.239092 ANSI MAP 354
Analyzed Information Request Invoke
...
ANSI Transaction Capabilities Application Part
queryWithPerm
identifier: 61060e24
componentPortion: 1 item
ComponentPDU: invokeLast (9)
invokeLast
componentIDs: 5b
operationCode: private (17)
private: 2368 Analyzed Information Request
ANSI Mobile Application Part
analyzedInformation
...
The return result response to this is where it goes wrong:
No. Time Protocol Length
22211 2012-06-06 01:22:22.510063 ANSI MAP 622
SACK
Analyzed Information Request ReturnResult
T Disconnect ReturnResult
Analyzed Information Request ReturnResult
T Disconnect ReturnResult
...
Data: e40fc70461060e24e807ea05cf015bf200
Padding: 000000
ANSI Transaction Capabilities Application Part
response
identifier: 61060e24
componentPortion: 1 item
ComponentPDU: returnResultLast (10)
returnResultLast
componentID: 5b
[private: 2390 T Disconnect]
ANSI Mobile Application Part
tDisconnectRes
...
Apart from the component ID (used as a correlation ID), the return result looks
the same:
e40f c704 61060e24 e807 ea05 cf01 5b f200
It should be displayed as an analyzedInformationRes not a tDisconnectRes
I'd guess that the information from the previous use of the TCAP ID is being
picked up later on and used where it shouldn't. This is over SCTP, which allows
for multiple TCAP messages in a single packet, so that could be part of the
problem.
I have the Type matching set to "Transaction ID Only" but since this is all
between the same two addresses I tried Source & Destination as well but that
made no difference.
I do wonder if the component ID should also be used for matching in cases where
the spec says that it is "echoed" back as a correlation ID. The problem I see
with that is that longer conversations and IVR interactions start using the
component ID in more complicated ways.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
