Why does Airprobe no longer work with current GNU Radio?

Hi all,

I’m new here to use GNU Radio. And I’m trying to decode GSM signal with
airprobe.

In GSoC page of GNU Radio, I found these words:

“It no longer works with current GNU Radio versions, and doesn’t make
use
of any of the new GNU Radio features.”

What are the detailed reasons? Moreover, what are the new features?

Best wishes,
Zhenhua HAN

On 02/09/2014 09:11 PM, zhenhua han wrote:

What are the detailed reasons? Moreover, what are the new features?

Best wishes,
Zhenhua HAN


Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
The Gnu Radio API changed between 3.6.5.1 and 3.7.0

http://gnuradio.org/redmine/projects/gnuradio/wiki/Move_3-6_to_3-7

Since very few of us here know exactly which features are used by
gr-airprobe, it’s hard to say which new features it might be avoiding
using…

I tried building airprobe with the latest 3.6 build (3.6.5.1) and even
that failed.
Can someone probably point us to a gnuradio version that definitely
works with airprobe ?
regards,
Mark

Hi,

     I met the same problem with airprobe and GNU Radio 3.7.

     I think its due to GNU Radio 3.7 is restructured, which leads 

the airprobe no longer work with GNU radio.

     You may try GNU Radio 3.6 series. For changes and new features 

in 3.7, you can check the release note.

Best Regards,
Jiang Pin

From: discuss-gnuradio-bounces+pin.a.jiang=removed_email_address@domain.invalid
[mailto:discuss-gnuradio-bounces+pin.a.jiang=removed_email_address@domain.invalid]
On Behalf Of zhenhua han
Sent: 2014210 10:12
To: [email protected]
Subject: [Discuss-gnuradio] Why does Airprobe no longer work with
current GNU Radio?

Hi all,

I’m new here to use GNU Radio. And I’m trying to decode GSM signal with
airprobe.

In GSoC page of GNU Radio, I found these words:

“It no longer works with current GNU Radio versions, and doesn’t make
use of any of the new GNU Radio features.”

What are the detailed reasons? Moreover, what are the new features?

Best wishes,
Zhenhua HAN

Hi,

Following this website:

http://www.rtl-sdr.com/rtl-sdr-tutorial-analyzing-gsm-with-airprobe-and-wireshark/

I’ve applied the patch mentioned and could run airprobe with gnuradio
3.7. However, I couldn’t decode the example file nor live signals using
RTL-SDR. When I run:

./go.sh capture_941.8M_112.cfile 64 0b

I get:

Using Volk machine: ssse3_32_orc
Key: ‘0000000000000000’
Configuration: ‘0B’
Configuration TS: 0
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.

And after a few seconds the prompt returns. In the mean, nothing
appeears in wireshark sniffing in lo, as it should. I’ve also tried
using gsmdecode instead of wireshark and this is what I got:

gr::buffer::allocate_buffer: warning: tried to allocate
115 items of size 568. Due to alignment requirements
0: ac WARN: packet to short
512 were allocated. If this isn’t OK, consider padding
your structure to a power-of-two bytes.
HEX l2_data_out_Bbis:462 Format Bbis DATA
On this platform, our allocation granularity is 4096 bytes.
000: ac ee 33 2c 00 00 00 00 - 00 00 00 00 00 00 00 00
001: 00 00 00 00 00 00 00
0: ac 101011-- Pseudo Length: 43
1: ee 1------- Direction: To originating site
1: ee -110---- 6 TransactionID
1: ee ----1110 Extension of the PD to one octet length [FIXME]
1: ee XXXXXXXX UNKNOWN DATA (3 bytes)
1: ee YYYYYYYY REST OCTETS (22)
0: e0 WARN: packet to short
HEX l2_data_out_Bbis:462 Format Bbis DATA
000: e0 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
001: 00 00 00 00 00 00 00
0: e0 111000-- Pseudo Length: 56
1: 00 0------- Direction: From originating site
1: 00 -000---- 0 TransactionID
1: 00 ----0000 Group Call Control [FIXME]
1: 00 XXXXXXXX UNKNOWN DATA (7 bytes)
1: 00 YYYYYYYY REST OCTETS (22)
0: cf WARN: packet to short
HEX l2_data_out_Bbis:462 Format Bbis DATA
000: cf a0 b0 00 00 00 00 00 - 00 00 00 00 00 00 00 00
001: 00 00 00 00 00 00 00
0: cf 110011-- Pseudo Length: 51
1: a0 1------- Direction: To originating site
1: a0 -010---- 2 TransactionID
1: a0 ----0000 Group Call Control [FIXME]
1: a0 XXXXXXXX UNKNOWN DATA (1 bytes)
1: a0 YYYYYYYY REST OCTETS (22)
0: cf WARN: packet to short
HEX l2_data_out_Bbis:462 Format Bbis DATA
000: cf a0 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
001: 00 00 00 00 00 00 00
0: cf 110011-- Pseudo Length: 51
1: a0 1------- Direction: To originating site
1: a0 -010---- 2 TransactionID
1: a0 ----0000 Group Call Control [FIXME]
1: a0 XXXXXXXX UNKNOWN DATA (1 bytes)
1: a0 YYYYYYYY REST OCTETS (22)
0: cf WARN: packet to short
HEX l2_data_out_Bbis:462 Format Bbis DATA
000: cf ee ce e0 00 00 00 00 - 00 00 00 00 00 00 00 00
001: 00 00 00 00 00 00 00
0: cf 110011-- Pseudo Length: 51
1: ee 1------- Direction: To originating site
1: ee -110---- 6 TransactionID
1: ee ----1110 Extension of the PD to one octet length [FIXME]
1: ee XXXXXXXX UNKNOWN DATA (2 bytes)
1: ee YYYYYYYY REST OCTETS (22)

I don’t know if this list is appropriate for this, but I’m not sure
which is the airprobe mailing list. I’d appreciate any hints. Thanks!

Gabriel

El 10/02/14 08:19, Marcus M. escribi:

On Wed, Feb 19, 2014 at 10:32 AM, Gabriel T [email protected] wrote:

Following this website:

http://www.rtl-sdr.com/rtl-sdr-tutorial-analyzing-gsm-with-airprobe-and-wireshark/

I’ve applied the patch mentioned and could run airprobe with gnuradio 3.7.
However, I couldn’t decode the example file nor live signals using RTL-SDR.

Did you verify that the sample rates of airprobe and the capture file
match? This is probably the most common reason for airprobe not
decoding anything.

-TT

Hi Tom, thanks for your replay.

In fact, I’m not sure which are the sample rates of the example files
I’m using:

capture_941.8M_112.cfile

vf_call6_a725_d174_g5_Kc1EF00BAB3BAC7002.cfile

However, I’ve tried with different decimation rates, including typical
112, and nothing happens.

Gabriel

El 20/02/14 00:39, Tom T. escribi:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Um, no, sorry, but I think it used to work with the same GR
installations as OpenBTS in general, which IIRC was the now ancient
3.4.2. Sadly, the ccc’s SVN browser doesn’t talk to me, so I can’t
have a look right now.

As to the useful GR features it can’t use if it is that old, I can
think of quite a few… There’s a reason GR development didn’t stop a
couple of years ago :slight_smile:

    • Stream tags,
    • message passing, both very useful if you’re dealing with bursts of
      transmissions, and if you asynchronously want to pass information
      between blocks (e.g. channel estimates etc), compare the gr-digital
      OFDM code
    • python blocks, totally useful if you want to speed up development of
      “logical” functions such as understanding of channel management
      information, compare gr-lte,
    • a lot of standard blocks that ease tasks like frequency translation,
      control loops etc.,
    • a stable and versatile build framework (CMake-based) with powerful
      tools to do standard tasks like adding and removing blocks, generating
      GRC files (ohhhh GRC is a nice new feature, too, I guess) and even
      some source control integration (gr_modtool)

Greetings,
Marcus

On 10.02.2014 10:26, M Dammer wrote:

the airprobe no longer work with GNU radio.
[email protected] Subject: [Discuss-gnuradio] Why does
make use of any of the new GNU Radio features."

_______________________________________________ Discuss-gnuradio
mailing list [email protected]
Discuss-gnuradio Info Page

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS+LW4AAoJEAFxB7BbsDrLvDMH/RWPitF68jC+DNSyHiidIqIi
4/T0UZ3CWMSkVAKoXPSMIdRb6rA+ih1fJvuvrTkLlrYpCONTCEOR8wQdb3uRFNu4
soAVnblOKo9OzqZ0Uckw3FzZq1Kdqje40+gYQHxDBFUPWYavG2uTYROkiBq5qlRW
PlKE6nwYF0Ia3YHTF4JGvWlLlOzMo20zX92Y6OtXZruVqvAzAOfLo9wkvdEojdre
Z2Cwu4tWohu54gJF6gQ+zfkJy71EBZJ8rpLGm6jyVtu9vvLgiCPMcrhCnV0Ncf41
Avp5jT4fw+CHsxMt2es83+3EvG/q2yfjrI0yToLsjF1g+Zhwyfu5goxc8wlb7sM=
=kwQZ
-----END PGP SIGNATURE-----