Wireshark-users: Re: [Wireshark-users] LTE MAC Packet capture in WireShark
From: Martin Mathieson <martin.r.mathieson@xxxxxxxxxxxxxx>
Date: Fri, 20 Mar 2009 08:55:48 +0000
I'm sending this to the list as the reply I sent yesterday went straight to Dinesh.


On Thu, Mar 19, 2009 at 12:33 AM, Dinesh Arora <dineshk_arora@xxxxxxxxx> wrote:
Hi Martin,
 
Thanks for the initial clarfication. If you have any sample packet.out file for LTE MAC then it will be helpful.
 
I do not have any specific constraint to use a particular format and fine with using something that is already supported and tested.
 
My initial understanding was to make a simple TCP Client that is injecting the packets to TCP Server:9999 with following format
 
TCP Header + MAC LTE Info + MAC PDU
 
Where, MAC PDU is the actual MAC message as per 36.321 and containing a sequence of MAC Subheader + MAC Payload.
 
 
TCP Header + DCT2000 Format indicating protocol as MAC_LTE + MAC LTE Info + MAC PDU.
 

You seem to have 2 choices:

(1) Send some frames from whichever machine is seeing the MAC PDUs (over TCP, or I suggest, UDP) to some other machine and capture using wireshark on that machine

(2) On whichever machine is seeing the MAC PDUs, write out a file in the DCT2000 format containing the MAC PDUs you see, and load that file into Wireshark once the run has ended


If you go with (1), I suggest you consider UDP rather than TCP:
- you would end up with more useful timestamps in wireshark
- the dissector you'd need to write would be simpler since you wouldn't need to do TCP reassembly to re-discover the start of each MAC PDU record
- you can avoid needing to write a program to accept the TCP connection.  With UDP you could either write a program that just binds the port, or ignore the ICMP errors when you're capturing

This probably depends upon whether you're sending these frames purely to log them, or if you're sending them bypass the PHY and test the higher layers.  I'd probably use UDP for either case if I was only sending the frames over a LAN.


(1) also has the benefit that you could see the PDUs during a live capture, whereas (2) will give you a log file at the end of the run.


If you go with (2), you'd need to:
- write the file header out at the start of a run (with real or dummy absolute time)
- for each PDU, you'd need to write out a new line in the file.  This involves filling in:
    - a timestamp (relative to the start of the test)
    - the context information (see the example and how its parsed in packet-catapult-dct2000.c)
    - the MAC PDU itself (as ascii hex characters)

Here is an example line. I hope you can work out what it means by adding it into the .out file you have and looking at the attach_mac_lte_info() function I mentioned in my previous email.

testsector.2/mac_r8_lte/1,1,3,0,0,0,28,2,0,875/// s tm 10.7487 l $2004210d230d2405250626072704280529062a071fffffffff111111111111111111111111112222222222222222222222222233333333334444444444445555555555555566666666777777777788888888888899999999999999

If you wanted to use (2), but still wanted to see the PDUs during the run, you *may* be able to redirect the file to stdout and use that as a pipe input to Wireshark, but I haven't tried it and am not sure it would work.

    
 
Can you confirm if the release 1.1.6 supports MAC LTE protocol dissector?
 


Yes, but I always use up-to-date SVN.  And I'm still making some improvements to the dissector.

If you get any further with this, probably best to address any queries to the dev list.

Regards,
Martin


 
Regards,
Dinesh
 
Regards,
Dinesh
 
 


--- On Wed, 3/18/09, Martin Mathieson <martin.r.mathieson@xxxxxxxxxxxxxx> wrote:

From: Martin Mathieson <martin.r.mathieson@xxxxxxxxxxxxxx>
Subject: Re: [Wireshark-users] LTE MAC Packet capture in WireShark
To: dineshk_arora@xxxxxxxxx, "Community support list for Wireshark" <wireshark-users@xxxxxxxxxxxxx>
Date: Wednesday, March 18, 2009, 3:56 PM


Hi Dinesh,

I don't think details about how the PDUs were framed were posted in the previous discussion, so this is more of a dev question at the moment.

Here are the extra pieces of information that MAC dissector currently uses to help with the decode (this is taken from epan/dissectors/packet-mac-lte.h) :

/* radioType */
#define FDD_RADIO 1
#define TDD_RADIO 2

/* direction */
#define DIRECTION_UPLINK   0
#define DIRECTION_DOWNLINK 1

/* rntiType */
#define NO_RNTI 0
#define P_RNTI  1
#define RA_RNTI 2
#define C_RNTI  3
#define SI_RNTI 4


/* Context info attached to each LTE MAC frame */
typedef struct mac_lte_info
{
    /* Needed for decode */
    guint8          radioType;
    guint8          direction;
    guint8          rntiType;

    /* Extra info to display */
    guint16         rnti;
    guint16         ueid;
    guint16         subframeNumber;
    guint8          isPredefinedData;
    guint16         length;
    guint8          reTxCount;
} mac_lte_info;


So you'd need to define a header format that encoded some or all of these fields before each frame.  A simple dissector would:
- read the header
- allocate a mac_lte_info struct and attach it to the frame
- call the mac-lte dissector for the payload

For help with this see the function attach_mac_lte_info() in epan/dissectors/packet-catapult-dct2000.c

If you could provide details of how you're framing these PDUs and could provide a sample capture, I should be able to help develop a simple dissector that calls mac-lte.

Best regards,
Martin




On Tue, Mar 17, 2009 at 11:19 PM, Dinesh Arora <dineshk_arora@xxxxxxxxx> wrote:
Hi,
 
I am new to WireShark tool and joined this mailing list recently.
 
I have seen some discussion in the list related to LTE-MAC/RLC/PDCP packet layers monitoring using TCP port 9999. Can you please let me know some sample packet formats that I can inject inside TCP packet containing some LTE MAC PDUs and then see the live capture in WireShark?
 
I want to make a tool that sends LTE MAC PDUs over TCP and this format will help me in understanding that how it will be decoded by WireShark? Unfortunately, Wiki does not have info related to the same.
 
Thanks in Advance.
 
Regards,
Dinesh


___________________________________________________________________________
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