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

On Wed, Jul 1, 2009 at 11:43 AM, Sumanth Balakrishna C <sumanthbc@xxxxxxxxxxxxxxx> wrote:

Hello All,

      I am new to this Wireshark tool. From the RLC-LTE link
on wiki (http://wiki.wireshark.org/RLC-LTE), I came to know
that support is provided for RRC,PDCP,RLC and MAC layers
of LTE. However, in one of the discussions on this mailing list
it was mentioned that the PDCP dissector might call the RRC
dissector to decode the RRC PDUs. The link for this
discussion is :
http://www.wireshark.org/lists/wireshark-users/200905/msg00104.html

   Hence, I would like to know if support has been added in
version 1.2.0 for the MAC dissector to call the RLC dissector
for decoding the MAC PDU which in turn calls the PDCP dissector
to decode the PDCP PDU which would then call the RRC dissector
to decode the RRC PDU.

Yes, see the PDCP-LTE wiki page - it is an option that is switched off by default.  I think I made some important fixes/improvements since the 1.2 branch was created, so I'd suggest using the latest svn sources or automated developement builds.

At the moment:
- MAC calls RRC for CCCH, BCH, PCH (i.e. when we know the RLC mode is transparent)
- RLC could do the same, but doesn't yet (it'll be easy to add once people start using the proper 3GPP RRC spec)
- PDCP can call RRC (for all signalling messages) or IP (for user plane messages) (assuming no ciphering)

This is mostly because the product I work with allows logging at all of those levels.  And its nice to set a display filter to look at one RLC flow (e.g. UL SRB1 and their DL status PDUs) without cluttering the display with MAC PDUs that have control PDUs and other SDUs that don't relate to the flow I'm interesting in.  Or just to look at the PDCP flow for a channel (without having to rely upon RLC re-assembly).

It should be possible to make this all work by reading the RRC messages and remembering the config information.  This has been done for UMTS IuB by Tobias Witek, but not yet committed (neither I nor anyone else has properly reviewed it yet).  See https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3495 - a similar approach may be feasible for LTE S1.

 

   Also, my other query is as follows. What is the use or idea behind
adding the UDP framing format for the MAC-LTE PDUs? As per
my understanding, Wireshark cannot identify a PDU as MAC-LTE
PDU without this framing format. Please do correct me if I am wrong.

There are several items of context information that must be known in order to successfully decode MAC-LTE PDUs (and other information that is optional, but useful to display).  The same thing applies to RLC, PDCP and RRC.

The file format I work with (http://wiki.wireshark.org/DCT2000) supplies this information.  Several people asked about logging MAC PDUs by sending them over UDP or TCP, but it never went anywhere.  So I added an example format over UDP that Wireshark can understand and an example program that sends UDP frames using this format  (at least one person is so far using this format).  In this format, several fields are mandatory, others are optional and use tags to indicate their presence.  I don't use this format.

I didn't want to register a UDP port for this format, so I made it a heuristic dissector (i.e. there is a special string that appears at the front of the frame).  Another approach would have been to use a configurable port number.

Hope this helps,
Martin

Thanks & Regards,

Sumanth


___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
            mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe