On Sun, Jan 4, 2015 at 1:32 AM, Luke Mewburn <l...@mewburn.net> wrote:
> Hi all. > > I've observed that Wireshark's TCAP session (transaction) matching > (enabled with tcap.srt:TRUE) doesn't operate correctly in various cases. > > I've been working on improving Wireshark's TCAP session handling, > and have some questions about the "best" way to do this as a new > contributor to the Wireshark development community. > > I'm not sure if it's preferable to describe all of the issues > in one 'wall of text' email or split up the discussions across > multiple messages; I've gone with the former :) > > Please let me know if the issues should be split out into separate > discussions, or if there's a better forum for this (e.g. bugzilla > tickets). > > regards, > Luke. > > > Specific fixes > -------------- > > 1. SCCP GT not set if route-on-SSN. > > DETAILS:: When sccp.set_addresses is TRUE, the GT isn't used if present > when the SCCP route-on-SSN bit is set (i.e not route-on-GT). > The GT is still useful for TCAP matching even in this case. > > PROPOSAL: I've submitted a change for this at: > https://code.wireshark.org/review/#/c/6053/ > (The second patch attempt is a minor improvement to the wording > of the preference after the changes in the original patch). > > > 2. TCAP session matching incomplete. > > DETAILS: TCAP session matching doesn't cope with TCAP dialogue > confirmation. (See "TCAP background" below for more information > about dialogue confirmation). > > 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 existing Wireshark > bugs in TCAP (and higher layer) that may be fixed by addressing this > > PROPOSAL: I have some changes to be submitted for review which > resolves this, and greatly improves transaction matching when > sccp.set_addresses:TRUE and tcap.srt:TRUE, even when the destination > address of the TCAP BEGIN changes as part of dialogue (transaction) > confirmation. > > > Future proposals > ---------------- > > (These could be moved into separate discussions). > > 1. SCCP addresses not set by default. > > DETAILS: By default, the SCCP GT is not set as the source and destination > addresses for higher layer protocols. The MTP3 (or M3UA) point codes > (PCs) are left as these addresses. > This can be changed with the preference option sccp.set_addresses. > For TCAP transaction matching, the SCCP GT is more correct than the > MTP3 PC. > > PROPOSAL: The sccp.set_addresses default could change to TRUE (and > possibly the SUA equivalent, although I haven't any experience with > SUA), but I'm not sure what ramifications that this has on protocols > other than TCAP that use SCCP. > > > 2. TCAP filters for party addresses. > > DETAILS: I've experimented with adding new filter nodes to contain the > (SCCP GT) addresses of the original calling party (from TCAP BEGIN), > the original called party (from TCAP BEGIN), and the confirmed party > (from first TCAP CONTINUE or END-after-BEGIN). > > These depend upon the SCCP addresses set (see above) and > the session matching fixed. > > PROPOSAL: Add new filters. I have a work in progress for this > which could be submitted for review. > > > 3. TCAP session matching not enabled by default. > > DETAILS: The session matching isn't enabled by default. > I suspect that this is because it has a performance impact > and that it doesn't work reliably (without my fixes :). > > PROPOSAL: Once the session matching is fixed, it could be > enabled by default. > > > 4. TCAP converted to conversation.h (after the latter is enhanced) > > DETAILS: TCAP uses its own session matching logic. If the standard > "conversation.h" implementation was used, then there may be other > benefits such as following conversation flows. > > I've experimented with this in a private branch, but ran into issues in > the current conversation.h implementation that need to be addressed > for TCAP. > > I implemented a new port type - PT_TCAP - to contain the TCAP > transaction ID (TID). > > As described below in "TCAP background": > > - TCAP BEGIN contains a src addr, otid (src port), and dst addr. > The dst addr may change in the first CONTINUE. > > We have to create the conversation with NO_ADDR2 as well as NO_PORT2, > which results in the conversation added to > conversation_hashtable_no_addr2_or_port2. > > - TCAP CONTINUE contains src addr, otid, dst addr, dtid. > > Looking this up with find_conversation() seems to work; > if it's the first CONTINUE the conversation is moved from > conversation_hashtable_no_addr2_or_port2 to > conversation_hashtable_exact. > > - TCAP END & ABORT contains the dst addr, dtid (dst port), and src addr > without src port (otid). > The dst addr may change in the first CONTINUE or an END after BEGIN. > > If the TCAP END is after a BEGIN, the conversation may be found > from conversation_hashtable_no_addr2_or_port2 if the addresses are > swapped, but if a TCAP CONTINUE is part of the transaction the > conversation will have been moved to conversation_hashtable_exact > and thus can't be found without the src port. > > PROPOSAL: Further investigation and discussion is required about how > to enhance conversation.h to resolve this. > I suspect we need special-case handling in find_conversation() (etc) > for PT_TCAP, including possibly a separate hashtable or keeping > the TCAP BEGIN in the conversation_hashtable_no_addr2_or_port2 in > parallel to the entry in conversation_hashtable_exact. > > > 5. Passing sccp_msg_info_t to child dissectors. > > DETAILS: sccp only passes the sccp_msg_info_t to child dissectors > if SCCP tracing is enabled and there's an SCCP association (i.e. > SCCP connection-based protocols). > > It could be useful to provide the sccp_msg_info_t sccp_msg member > of sccp_decode_context_t to TCAP (and possibly other connectionless) > dissectors so they can obtain SCCP addressing directly. > > I'm still experimenting with this. > > > TCAP background > --------------- > > TCAP (as described in ITU-T Q.771 (06/97) (et al)) uses SCCP for > addressing when used in SS7 networks. > Q.771 mentions that further study is required if other (non-SCCP) > networks are to be used; I'm not aware if any are. > > TCAP supports transactions (between two peers) with a structured > dialogue with transaction IDs, with each peer using its own > transaction ID, with TCAP messages BEGIN, CONTINUE, END, ABORT. > > TCAP uses originating and destination address from SCCP; > the SCCP calling party is the origination address, > the SCCP called party is the destination address. > > TCAP BEGIN has an originating transaction ID (OTID). > TCAP END & ABORT has a destination transaction ID (DTID). > TCAP CONTINUE has both an OTID and DTID. > > Common TCAP transaction patterns include: > > (1) TCAP BEGIN orig=A otid=At -> dest=B > TCAP END orig=B -> dest=A dtid=At > > (2) TCAP BEGIN orig=A otid=At -> dest=B > TCAP CONTINUE orig=B otid=Bt -> dest=A dtid=At > TCAP CONTINUE orig=A otid=At -> dest=B dtid=Bt > TCAP END orig=B -> dest=A dtid=At > > Note that the END (or ABORT) doesn't contain the otid. > > > TCAP also supports the concept of "dialogue confirmation" - > see Q.771 clause 3.1.2.2.2.2 "Confirmation of the dialogue". > This means that the first CONTINUE in a transaction can change > the orig address. The pattern for this can be: > > (3) TCAP BEGIN orig=A otid=At -> dest=B > TCAP CONTINUE orig=B2 otid=Bt -> dest=A dtid=At > TCAP CONTINUE orig=A otid=At -> dest=B2 dtid=Bt > TCAP END orig=B2 -> dest=A dtid=At > The BEGIN was to dest=B, the first CONTINUE was orig=B2. > > In practice, a transaction consisting of BEGIN then END (pattern (1) > above) can also do this in the END. > > The better is create a bug in bugtracker with subject like : Enhance TCAP dissector (and list the list of issue/change) and push your patch on gerrit with in commit log the reference to this bug (Ping-Bug: XXXX) Also attach in bug, some pcap sample for try. Regards, > > -- > > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
