Wireshark-dev: Re: [Wireshark-dev] TCAP SRT incorrectly matches TC_BEGINs and TC_ENDs

From: Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>
Date: Thu, 25 May 2017 14:38:05 -0400


On Wed, May 24, 2017 at 12:19 PM, Conall Prendergast <conall.prendergast@xxxxxxxx> wrote:
Hi All,

I have been analyzing a TCAP trace with wireshark with the tcap.srt and tcap.persistentsrt options set to "TRUE".

This should correctly match TCAP Begins (using 2 pass analysis) with their associated TCAP Ends, and vise-versa.

I have attached two files, "correct_matches.pcap" and "incorrect_matches.pcap", that demonstrate some spurious behavior. These two files are from the same feed, and "correct_matches.pcap" contains packets 5, 11, 15, and 19 from "incorrect_matches.pcap".

"correct_matches.pcap" will correctly match packet 1 (TC_BEGIN) with packet 4 (TC_END), and packets 2 and 3 similarly, however, when these packets are analysed with the rest of the feed (incorrect_matches.pcap), these very same packets do not match up. 

Instead, packet 5 (packet 1 from "correct_matches") matches with packet 15 (3) instead of packet 19 (4).

As you can guess, this is unexpected behavior.

So in summary, correct_maches.pcap contains:
1 => 4
2 => 3

incorrect_matches contains:
5 => 15
11 => x
x => 19

and the mapping of correct_matches to incorrect_matches is:
1 => 5
2 => 11
3 => 15
4 => 19


Any and all help is appreciated.

It appears that the problem is that the TCAP dissector, when looking for an END in the SRT tables, only uses the (destination) TID--it completely ignores the source and destination addresses (check out tcaphash_end_calchash()).  This despite the fact that tcaphash_end_matching() goes through the trouble of storing an address in the hash key before calling tcaphash_end_calchash().

Care must be used here because of the way source and destination (L3 and L4) addresses can (and often do) change during a transaction (it should be noted that the other _calchash() functions also ignore the addresses--the _begin_ function has code to include the address in the hash but it's commented out).  I'm not quite sure how to fix it; I'd suggest opening a bug report at https://bugs.wireshark.org .