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

[Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>]

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 .