[USRP-users] Problems using Airprobe with USRP1

GSM Research gsm.research.group at gmail.com
Thu Apr 11 12:39:37 EDT 2013


Hello,

We are trying to use Airprobe to capture gsm traffic from an OpenBSC setup
using an IP.Access nanoBTS PCS 1900 as our cell tower.

For the Airprobe setup, we have a USRP1 with two FLEX900 daughter cards
(both of which have been modified to work as RFX1800 cards) attached to a
workstation on which we have installed GnuRadio.  We have also downloaded
the Airprobe repository and the additional USRP drivers and programs found
on the Ettus website.

We have tested the USRP1 and using uhd_fft, we can see that we are
detecting the carrier signals put out by the nanoBTS.

We are trying to use uhd_rx_cfile for the capture.  When running the
program, it does appear to be capturing data (at least a large file is
created), but we are unable to decode the datafile that is created.

A typical run of uhd_rx_cfile that we have tried (for ARFCN 800) is:
    root# uhd_rx_cfile -g 52 -N 2000000 -f 1987800000 output.cfile

When we try to decode the output.cfile using gsm_receive.py, we get the
following:
    root# ./gsm_receive.py -I output.cfile
    input_rate: 406250.0 sample rate: 0.375  filter_cutoff: 145000.0
filter_t_width: 10000.0
    >>> gr_fir_ccc: using SSE
    >>> gr_fir_ccf: using SSE
    Key: 'ad6a3ec2b442e400'
    Configuration: ''
      No configuration set.
    configure_receiver
    gr_buffer::allocate_buffer: warning: tried to allocate
       115 items of size 568. Due to alignment requirements
       512 were allocated.  If this isn't OK, consider padding
       your structure to a power-of-two bytes.
       On this platform, our allocation granularity is 4096 bytes.

The cfile2.out file that gets created automatically from running
gsm_receive.py is empty (size 0), and nothing appears in a Wireshark
capture.

Obviously, we are missing something (a parameter? using the wrong
program/script?).  We have tried many different combinations of parameters
and earlier versions of airprobe programs that mailing lists have said are
now deprecated, but we have not been able to get one successful run.

At this point, we don't know whether we are capturing the data correctly,
or decoding it improperly (or both).  When we compare (using a hexdump) our
output file with the sample capture given on the SR Labs Airprobe How-To (
https://srlabs.de/airprobe-how-to/), we notice differences (odd numbered
columns in the SR Labs file are for the most part 0000):
Our output.cfile:
0000000 810b bc85 012c bb96 0140 baa0 0108 bc04
0000010 01c8 3b64 0100 bc80 01dc bbee 4174 bcba
0000020 0176 bc3b 0122 bc91 c174 bcb9 c116 bc8a
0000030 c12e bc96 01e2 bc71 0154 bc2a 4110 bc88
0000040 41c2 bce1 01d8 bcec 416a 3cb5 01c0 ba60

SR Labs sample file:
0000000 0000 3b04 0000 3b20 0000 3b3a 0000 3b26
0000010 0000 3b48 0000 3b2a 0000 3ae8 0000 3b76
0000020 0000 baf4 0000 3b52 0000 bb24 0000 3b3a
0000030 0000 bbab 0000 bbb9 0000 3ac8 0000 3b82
0000040 0000 bb98 c000 bca2 0000 3c44 4000 3cde

However, we don't know if this is due to different hardware (SR Labs is
using a USRP2) or something else (improper capture).

Any suggestions on what we could try on our captures or decodes would be
greatly appreciated!

Thanks,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130411/b39698b8/attachment-0002.html>


More information about the USRP-users mailing list