["Martin Mathieson" <martin.r.mathieson@xxxxxxxxxxxxxx>]

Hi,

The FP dissector is implemented in epan/dissectors/packet-umts_fp.c.
packet-umts_fp.h defines this struct containing all of the values needed by the dissector:

/* Info attached to each FP packet */
typedef struct fp_info
{
    enum fp_interface_type iface_type;
    guint8  release;                     /* e.g. 99, 4, 5, 6 */
    guint16 release_year;                /* e.g. 2001 */
    guint8  release_month;               /* 
e.g. 12 for December */
    gboolean is_uplink;
    gint channel;                       /* see definitions above */
    guint8  dch_crc_present;            /* 0=No, 1=Yes, 2=Unknown */
    gint paging_indications;
    gint num_chans;
#define MAX_FP_CHANS  64
    gint chan_tf_size[MAX_FP_CHANS];
    gint chan_num_tbs[MAX_FP_CHANS];

#define MAX_EDCH_DDIS 16
    gint   no_ddi_entries;
    guint8 edch_ddi[MAX_EDCH_DDIS];
    guint  edch_macd_pdu_size[MAX_EDCH_DDIS];
} fp_info;

packet-catapult_dct2000.c and packet-k12.c have examples of using information found in the file format (approach (a)) to fill in parts of this stuct and attaching it to the frame before passing it (eventually) to the FP dissector.

The approach you'd need to take is to:
- record in tables somewhere the configuration of the channels (as seen in RRC or NBAP  or ALCAP messages), i.e. transport info -> (channel type, transport formats, CRC included, etc)
- modify the dissector so that if it doesn't find a struct attached, it will use transport info (VPI/VCI/CID or IP/UDP addresses/ports) to look up the channel tables
- infer what the various values should be in the struct  and attach it to the frame
- dissect the actual frame

For MAC, you'd need to define a struct that had maybe:
- the transport channel type
- TB size
- whether a CT field was present
- etc

I hope this helps.  Good luck,
Martin

On 09-Jan-2008 10:42:42 ZE5B, <munish.dayal@xxxxxxxxxxx> wrote:

Hi,
My requirement is basically the whole stack (no ciphering for the time
being).
  RRC
  RLC
  MAC
  FP
  UDP

Could you pls share the details of the approach you took with FP. What kind
of "filled-in-struct", and how it can be filled from NBAP configuration
messages.
For RLC/MAC also, I am more interested in a generalised solution (approach
(b)), where configuration info can be gleaned from RRC messages, and filled
in a "filled-in-struct".

Regards,
Munish




            "Martin
            Mathieson"
            <martin.r.mathies                                          To
            on@xxxxxxxxxxxxxx         "Developer support list for
            >                         Wireshark"
            Sent by:                  < wireshark-dev@xxxxxxxxxxxxx>
            wireshark-dev-bou                                          cc
            nces@xxxxxxxxxxxx
            g                                                     Subject

                                      Re: [Wireshark-dev] 3GPP RLC and
                                      MAC protocols support

            01/09/2008 12:19
            AM


            Please respond to

            Developer support
                list for
                Wireshark

            <wireshark-dev@wi
              reshark.org>

On Jan 8, 2008 6:05 PM, Neil Piercy < Neil.Piercy@xxxxxxxxxxxx> wrote:
 I'm looking at the same issue for my company and came to similar
 conclusion. At present we've gone down the route of (c) for a quick try,
 but I think it will soon be coming unstuck - it certainly isn't general
 enough to feed back yet.  We haven't yet got any MAC/RLC dissection, but
 would be happy to work with somebody to do so - even if we only leave the
 glue to transports as proprietary for now.


If it were to be done, I'd like to use the approach as I took with FP,
where a filled-in-struct is attached to each frame with the info the
dissector needs to know.  As you say, this can be filled in from wherever
it is available or can be guessed.

I'd be interested in discussing what these fields should be if you like..
The FP dissector has been very useful to me - I'm not convinced that MAC
and RLC would be as useful to me (one reason is that we have separate
primitives/frames for the messages exchanged between the layers, so its not
obvious how I'd be able to associate the frames and show the whole stack,
i.e.

RLC
MAC
FP
UDP or AAL

in one Wireshark frame.  Ciphering is another complication.

Regards,
Martin




 BTW is anyone planning on hooking RRC NAS message IEs into gsm_a_dtap ?
 Since RRC is from the ASN.1, I've not tried it yet, but any pointers
 appreciated.

 Neil

 From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:
 wireshark-dev-bounces@xxxxxxxxxxxxx ] On Behalf Of Martin Mathieson
 Sent: 08 January 2008 11:26

 To: Developer support list for Wireshark
 Subject: Re: [Wireshark-dev] 3GPP RLC and MAC protocols support

 Hi,
 I don't know of anyone working on MAC or RLC dissectors.

 FP is currently only available for Catapult DCT2000 and Tektronix K12
 file formats, since those formats include the information needed to
 interpret the message payloads.  This amounts to using Wireshark as a
 different log viewer, rather than as a passive network analyser.

 In order to decode the MAC and RLC layers, you'd need to either:
 (a) use a file format that gives you this information directly (as
 above), OR
 (b) infer the FP/MAC/RLC layer configuration/state using information
 gleaned from RRC configuration messages, OR MAYBE
 (c) guess from the message size/timing/contents that common transport
 formats have been used, e.g. there are standard settings using with AMR
 co-ordinated channels? OR EVEN LESS LIKELY
 (d) get all of this information from preference settings.  I think this
 is probably a non-starter since so much of the information is per-channel
 or even per-frame.

 I'd love to see someone do this, but know that it isn't trivial - my
 company (Catapult) built such an analyser (using (b) - before I joined).

 I could have extended the approach of (a) for the DCT2000 format, i.e.
 dissect our own proprietary primitive headers then use this and other
 information in the file format to hand off to pure MAC or RLC dissectors
 (that would use attached information, as the FP dissector does), but this
 would still just be using Wireshark as a different log viewer, I don't
 know of any other file formats that would then be able to take advantage
 of these dissectors in the same way (possibly K12 again...).  I believe
 the headers for MAC and RLC are quite short, and that it would take more
 effort to dissect the proprietary headers than it would for the actual
 protocol headers.

 Regards,
 Martin

 On Jan 8, 2008 10:41 AM, Anders Broman < anders.broman@xxxxxxxxxxxx>
 wrote:
   Hi,
   An RRC dissector (packet-rrc.c) exists but only partly used. Some time
   ago some one
   asked about MAC and probably did something with it but nothing was
   commited back to WS.
   These are somewhere in the middle of the tread
   http://www.wireshark.org/lists/wireshark-dev/200708/msg00121.html
   http://www.wireshark.org/lists/wireshark-dev/200708/msg00275.html
   Regards
   Anders

   -----Original Message-----
   From: wireshark-dev-bounces@xxxxxxxxxxxxx
   [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx ] On Behalf Of
   munish.dayal@xxxxxxxxxxx
   Sent: den 8 januari 2008 15:35
   To: Developer support list for Wireshark
   Subject: [Wireshark-dev] 3GPP RLC and MAC protocols support





   Hi,

   Is anybody working on dissectors for 3GPP-UMTS- RLC and MAC protocols ?

   Or are these dissectors already available somewhere ?

   Thanks & Regards,
   Munish





   ***********************  Aricent-Unclassified   ***********************

   "DISCLAIMER: This message is proprietary to Aricent  and is intended
   solely for the use of the individual to whom it is addressed. It may
   contain privileged or confidential information and should not be
   circulated or used for any purpose other than for what it is intended.
   If you have received this message in error, please notify the
   originator
   immediately. If you are not the intended recipient, you are notified
   that you are strictly prohibited from using, copying, altering, or
   disclosing the contents of this message. Aricent accepts no
   responsibility for loss or damage arising from the use of the
   information transmitted by this email including damage from virus."


   _______________________________________________
   Wireshark-dev mailing list
   Wireshark-dev@xxxxxxxxxxxxx
   http://www.wireshark.org/mailman/listinfo/wireshark-dev
   _______________________________________________
   Wireshark-dev mailing list
   Wireshark-dev@xxxxxxxxxxxxx
    http://www.wireshark.org/mailman/listinfo/wireshark-dev


 _______________________________________________
 Wireshark-dev mailing list
 Wireshark-dev@xxxxxxxxxxxxx
 http://www.wireshark.org/mailman/listinfo/wireshark-dev

_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev



***********************  Aricent-Unclassified   ***********************

"DISCLAIMER: This message is proprietary to Aricent  and is intended solely
for the use of
the individual to whom it is addressed. It may contain privileged or
confidential information and should not be
circulated or used for any purpose other than for what it is intended. If
you have received this message in error,
please notify the originator immediately. If you are not the intended
recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of
this message. Aricent accepts no responsibility for
loss or damage arising from the use of the information transmitted by this
email including damage from virus."


_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev