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

Wireshark-users: Re: [Wireshark-users] [Fwd: Wireshark to K12 comparison]

From: "AMEAUME ALAIN" <Alain.Ameaume@xxxxxxxxxxxxxxxxx>
Date: Wed, 3 Oct 2007 18:35:01 +0200

Thanks for your help !

< These ares my questions on the whireshark :
<
< - is there any possibility to know on which ITU, ETSI, 3GPP
< recommandations releases have been coded the dissectors to be used for
< MAP, CAMEL, ISUP, BSSMAP, RANAP, etc.. Application Parts ?

> For the most part, the versions used by the dissectors are listed in the header of each source file.
> For example, you can read at the top of the GSM-MAP dissector:
>
http://anonsvn.wireshark.org/viewvc/viewvc.py/trunk/epan/dissectors/packet-gsm_map.c?view=markup
>  * References GSM MAP:
>  * ETSI TS 129 002
>  * Updated to ETSI TS 129 002 V7.5.0 (3GPP TS 29.002 V7.5.0 (2006-09)
> Release 7)
>  * Updated to ETSI TS 129 002 V8.1.0 (3GPP TS 29.002 V8.1.0 (2007-06)
> Release 8)
>  * References GSM SS
>  * References: 3GPP TS 24.080
> For dissectors generated from the ASN.1 source (such as GSM MAP) you can check the ASN source, too:

OK, one suggestion could be to access these release data informations from the WireShark Preferences Window ! (see capture file below)



< - The K12 Tektronix analyzer give us the way to build ourself the
< protocol stack corresponding to a specific GSM.xx or TS.xx
< recommandation release ! Is it possible to add in your project a tool
< to manage these protocol stacks, specialy because, for training and
< pedagogic objectives, it should be nice to control exactly the output
< of a trace decoding ?

> I think the assumption has been that the protocols are backwards compatible
> Interworking of GSM systems would be difficult otherwise I suppose.

Well, all the protocols are not systematically "backward compatible" ! the GSM system interworking is based on a special feature introducing the "fall back" scenario : when two Network Equipments do not support simultaneously the same MAP Application Context (AC) release, then, according White Book TCAP capability, it becomes possible to restart the dialogue using lower version of this AC !
The consequence is that interworking control (specialy during test agreement phases for a new feature between two Mobile Telecom Operators) needs to know on which AC version should be handled this new feature ==> by the way starting SS7 exchange analysis using the "best = max" MAP AC version available is not all the times efficient !

> In case of GSM MAP the dissector automatically handles differences in the versions
> For CAMEL there is an open BUG about one problem but it looks solvable without
> introducing a version option.
> For the other dissectors there has been no bug reports on version problems.

<PS: I know that some of wireshark users would like to have some K12
<style traces (rf5 file type) ==< I can proposed some examples on Mobile
<Telecom Network (DTAP, BSSMAP, ISUP, CAMEL, MAP) issued fom different countries.

> New example traces to the wiki samples page are always welcome.

See attached zip file

Additional questions :
- I don't succeed to build a filter to isolate a complete TCAP transaction based on "Original transcation id" and "Destination transaction id" parameters ==> very, very, very helpfull to retrieve among several records one GSM MAP procedure (i.e. a complete "Update Location" with its "Insert Subscriber Data" messages) + the same request for a SCCP connected oriented procedure base on "SCFid" (i.e. to follow a complete BSSMAP call establishment from the Connection Request to the Connection Release) : is it possible ? or do we have to imagine a macro mechanism ? like ==>
- Is it possible to build a kind of "filter macro script " where wireshark could pause its process, asking to the user one reference, and resuming its filter action by using the user response in the filtering macro ?

Best regards

Alain.

Attachment: from K12.zip
Description: from K12.zip