Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Improve Tcap session management

From: "Luis EG Ontanon" <luis.ontanon@xxxxxxxxx>
Date: Mon, 30 Jul 2007 12:25:07 +0200
TCAP uses the same mechanism for mantaining sessions that SCCP uses
(also SUA, ALCAP, GTP-C and others do)

A->B SETUP (orig-key=keyA)
B->A SETUP-CONFIRM (orig-key=keyB, dest-key=keyA)
...
A->B MSG (dest-key=keyB)
B->A MSG(dest-key=keyA)
...
A->B RELEASE ([orig-key=keyA],dest-key=keyB)
B->A RELEASE-COMPLETE ([orig-key=keyB],dest-key=keyA)

all these protocols use uint32 keys, The SCCP implementation (mine) I
needed originally to be able to decode payload over SCCP in
Connection-Oriented messages that do not carry an SSN. Later I used it
for to a single (articicial) filter for a connection and to add RANAP
and BSSAP to have the The VoIP Calls Dialog (yes I know that neither
BSSAP nor RANAP are VoIP, but then Neither is ISUP that is in there
anyway).

I been thinking in adding MAP,  INAP, and CAMEL [and may be ALCAP] to
the VoIP Calls as well that woul nmean tht I shoyuld re-use the code I
use for tracing SCCP for TCAP, that code
would do (almost) the same that this code does.

Should we unite efforts and come up with a single se_tree-based
persistent transaction handling of TCAP transactions that can be used
for filtering, tracing and statistics?

Luis

 On 7/30/07, Florent Drouin <florent.drouin@xxxxxxxxxxxxxxxxx> wrote:
>     Hi,
>
> I have found the problem, so I did add the same protection, found in
> expert.c, again "read filter" in the tcap tap. Thanks for pointing this bug.
> I did rename the decoding function for ANSI and ITU as suggested.
> And by the way, I did correct when a dissector want's to unregister it's
> ssn.
> As the ITU, and ANSI table for sccp.ssn is common, you can not
> unregister an ssn(ITU) in the SCCP table if it is used by an ANSI
> subdissector.
>
> For the use of se_tree, I will see, but a bit later..
>
> Regards
> Florent
>
> Jeff Morriss wrote:
> > Wow, that was fast, thanks!
> >
> > By the way, why not rename these functions with "ANSI" and "ITU" in the
> > name?
> >
> >
> >> +/*
> >> + * Call ITU Subdissector to decode the Tcap Component
> >> + */
> >>  static int
> >>  dissect_tcap_TheComponent(gboolean implicit_tag _U_, tvbuff_t *tvb, int offset, asn1_>
> >>
> >
> > [...]
> >
> >
> >> +/*
> >> + * Call ANSI Subdissector to decode the Tcap Component
> >> + */
> >> +static int
> >> +dissect_tcap_TheComponentPDU(gboolean implicit_tag _U_, tvbuff_t *tvb, int offset, as>
> >>
> >
> > (maybe there's a good reason they're named that way, but...)
> >
> >
> > Also, while I was testing the patch on an ANSI TCAP capture I had handy,
> > I noticed that if I use a read filter ("wireshark -r /some/file -Rsccp"
> > for example), none of the TCAP statistics stuff works--I get a bunch of
> > noise about sessions starting in frame 0 and the responses don't get
> > matched to the queries.  Maybe there's some code in there that assumes
> > that frame numbers are continuous (e.g., frame 3 follows frame 2) which
> > may not be the case if you have a read filter?  If you don't have any
> > immediate ideas, maybe I'll file a bug report so we don't forget.
> >
> > One other thing that I've read before:
> >
> > http://anonsvn.wireshark.org/viewvc/viewvc.py?view=rev&revision=20758
> >
> > is that the g_hash's should be replaced with se_tree's (see
> > README.binarytrees).  Something to think about going forward.
> >
> > Anyway, checked in rev 22415, merci!
> >
> >
>
>
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
>
>


-- 
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan