[srslte-users] Trying to pickup broadcast messages [2]

Paul Sutton paul at softwareradiosystems.com
Fri Feb 19 15:34:20 UTC 2016

Hi Anthony,

Another approach which might be useful would be to use srsUE -
www.github.com/srslte/srsue - our full UE application which builds on
top of srsLTE. srsUE supports MAC layer packet captures directly - these
can be opened with wireshark.

The RRC layer manages the UE behaviour and instructs the MAC to look for
specific RNTIs. If you take a look at ue/src/upper/rrc.cc, you can see
where it receives MIB from lower layers (write_pdu_bcch_bch - line 167)
and SIB messages (write_pdu_bcch_dlsch - line 183). At the end of
write_pdu_bcch_dlsch, you'll see that send_con_request is called to
start the attachment procedure. Instead you could call
rrc_connection_release (line 612) to instruct the MAC to start looking
for paging messages. These will then be captured at the MAC layer in the
pcap file.

I haven't tried this myself but let me know if you run into any problems.


On 19/02/16 14:44, Ronning, Anthony wrote:
> Ismael,
> Thank you SO much! The srslte_vec_fprint_byte() function was the
> missing key for me. I'm going to try to combine it with lameditor
> (http://sdr-x.github.io/LTE-SIB-decoding-by-asn1c/) to streamline the
> process a bit more.
> But thank you again! Really enjoying working with srsLTE.
> Anthony
> ------------------------------------------------------------------------
> *From:* Ismael Gomez <ismael.gomez at softwareradiosystems.com>
> *Sent:* Thursday, February 18, 2016 6:46 AM
> *To:* Ronning, Anthony; srslte-users at lists.softwareradiosystems.com
> *Subject:* Re: [srslte-users] Trying to pickup broadcast messages [2]
> Hi Anthony, 
> I think the best way to sniff PDCCH packets is modifying the pdsch_ue
> example, just like the authors of the paper did. Actually it's really
> easy. 
> First thing to do is to instruct the pdsch_ue example to look for
> paging messages in PDSCH, just past the paging RNTI (0xFFFE) with the
> option "-r" to the program. 
> Then you need to modify the pdsch_ue example to print or save the
> decoded messages. If you look at file srslte/examples/pdsch_ue.c, line
> 499, when the program gets there it means it has successfully decoded
> a packet in PDSCH. The packet should be in the "data" pointer. You can
> use the function srslte_vec_fprint_byte() to print the hex string to
> stdout. Then you can use your ASN decoder to decode the message. This
> site is also
> useful: http://www.marben-products.com/asn.1/services/decoder-asn1-lte.html.
> Just copy & paste the hex string there and you'll get the decoded
> message. 
> <http://www.marben-products.com/asn.1/services/decoder-asn1-lte.html>
> MARBEN ASN.1 Solutions: 3GPP LTE Messages Decoder
> <http://www.marben-products.com/asn.1/services/decoder-asn1-lte.html>
> www.marben-products.com
> Free Online 3GPP LTE ASN.1 Messages Decoder. This online decoder
> allows decoding of ASN.1 encoded messages (PDU) of a LTE network. No
> ASN.1 syntaxes are required.
> Ismael
> On Thu, 18 Feb 2016 at 08:04 Ronning, Anthony
> <AnthonyRonning at my.unt.edu <mailto:AnthonyRonning at my.unt.edu>> wrote:
>     Sending again because there were problems sending the first time
>     and it seems to be working again..
>     Hello,
>     I'm an undergraduate researcher entering grad school next fall and
>     I've picked up an interest in LTE networks and this srsLTE
>     library. I have a USRP B200 and what I'm trying to do is pickup
>     broadcast messages from LTE networks around me.
>     I've used "cell_search" to find a couple frequencies I want to
>     test on and then used pdsch_ue and cell_measurement on those
>     frequencies. There's a couple things I have been trying to do but
>     the end goal is all the same.
>     Goal: Grab the GUTI/IMSI from broadcast messages that are being
>     sent from the eNodeB.
>     Possible solutions:
>         1) I'd like to view all of these messages in wireshark, but
>     nothing shows up when I scan the localhost in wireshark. I tried
>     using the '-s' option with pdsch_ue/cell_measurement to send UDP
>     packets somewhere on the localhost, in an attempt for the data to
>     go through wireshark, but nothing shows up. This might be out of
>     the scope of srslte, but if anyone has any clue on doing so,
>     that'd be great.
>         2) Alternatively, if I could extract them from within the
>     program itself to a file, that'd be great. I have C knowledge and
>     was looking through the header files from ue_dl.h, but I had
>     trouble finding anything, and not sure if that's even the right
>     place to look.
>         3)If there's a way to get the binary of the messages instead,
>     I've seen some library's used to decode ASN.1 LTE messages so
>     maybe I could use those.
>     I'm tasked with some research based on a research paper a couple
>     months ago (http://arxiv.org/pdf/1510.07563v1.pdf) where it says
>     on page 4:
>     "In order to sniff LTE broadcast channels, we utilized parts of
>     srsLTE.  It  is  a  free  library  for  software-defined  radio
>     mobile  terminals  and  base  stations.  Currently,  the  project 
>     is developing a UE-side LTE baseband implementation.srsLTEuses
>     Universal Hardware Device library to communicate with the USRP
>     B210. Since all the passive sniffing is done in real-time, it is
>     recommended to have a high-speed host (laptop) in order to handle
>     the high (30.72 MHz) sampling rates with out data  loss  and 
>     also  to  maintain  constant  sync  with  eNodeBs.In  particular, 
>     we  used  the pdsch-ue application  to  scan a  specified 
>     frequency  and  detect  surrounding  eNodeBs. *It can  listen 
>     and  decode  SIB  messages  broadcast  by  eNodeB.Further, we
>     modified pdsch-ue to decode paging messages which are identified
>     over-the-air with a Paging-Radio Network Temporary  Identifier 
>     (P-RNTI).  Upon  its  detection,  GUTI(s)and/or IMSI(s) can be
>     extracted out of paging messages*"
>     Any insight as to how to go about this, or places to look within
>     the code, would be greatly appreciated. I have researched out to
>     one of those researchers just in case, but no response back (which
>     is fine and to be expected). I've been at it for a couple weeks
>     now, also researching other software, but no luck so far. I'm
>     assuming it's the 65534 RNTI value I should be looking for here,
>     but don't know how I would get any data from it when I use the
>     pdsch-ue application. 
>     Thanks in advance,
>     Anthony
>     _______________________________________________
>     srslte-users mailing list
>     srslte-users at lists.softwareradiosystems.com
>     <mailto:srslte-users at lists.softwareradiosystems.com>
>     http://www.softwareradiosystems.com/mailman/listinfo/srslte-users
> _______________________________________________
> srslte-users mailing list
> srslte-users at lists.softwareradiosystems.com
> http://www.softwareradiosystems.com/mailman/listinfo/srslte-users

Paul Sutton Ph.D.

Software Radio Systems (SRS)

+353-87-9813473 | paul at softwareradiosystems.com

PGP Key ID: 3B4A5292
Fingerprint: B0AC 19C9 B228 A6EB 86E1 82B2 90C7 EC95 3B4A 5292

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.softwareradiosystems.com/pipermail/srslte-users/attachments/20160219/c6b8a454/attachment-0001.html>

More information about the srslte-users mailing list