General question about grgsm and airprobe

[DH]

Hello list,

It's be a while since I finally bought a RTL-SDR and started exploring the world of GSM and as you may know there's not a lot of information regarding general informations unless you have the time to read the whole GSM specification which is a lot obviously !

I've setup my gr-gsm and did a lot of capture and inspection by wireshark and still couldn't figure out a lot of things. So if anyone knows the answers please do let me know or point me to the right direction. so here it goes :

Question regarding gr-gsm:

1- regarding the installation of gr-gsm there were 2 options to choose from, install with pybombs or use the manual mode. I installed gr-gsm a lot time ago and don't remember exactly how it went but i remember i ran into a lot of difficulties with pybombs (i specifically remember apache module and i still don't know where it's used.) and had to correct a lot of them manually. so right now gr-gsm works very well on my system but i've decided to start making my own flowgraphs and I ran into the problem of GRC not knowing where grgsm module is installed. (I don't have /usr/local/lib/python2.7/dist-packages/grgsm) but gr-gsm works. (i suppose i installed it as non root ?). what's the easiest way to solve this ?

2- when using grgsm_capture.py I don't get anything in the console as a result wireshark doesn't show anything but after capture i can see packets with grgsm_decode. what could cause this problem?

3- both grgsm_capture.py has a -v option but when i give it as an argument i get this error :

Traceback (most recent call last):
  File "/home/daniel/gr-gsm/bin/grgsm_capture.py", line 264, in <module>
    rec_length=options.rec_length, args=options.args)
  File "/home/daniel/gr-gsm/bin/grgsm_capture.py", line 89, in __init__
    self.gsm_clock_offset_control = grgsm.clock_offset_control(fc-shiftoff, sample_rate, osr=4)
NameError: global name 'sample_rate' is not defined

4-the same happens for trying to capture as burst (-b)

Question regarding GSM

5- if you have a samsung phone and you dial *#0011# it gives you a simple GSM info screen. i can see MCC, MNC , BAND , ARFCN , NOM , Rac , etc
what are NOM and Rac? mine shows NOM:2 and Rac:1 . also i see the Timing Advance parameter which is 0 for me (right now at least). is this the
same Timing advance parameter in the L1 header? if yes how would this be related to the packets send from BTS to my MS? should i inspect packets with TA:0 for myself?

6- how can i use subslot to make a better filter to find the right Immediate Assignment? i saw this video that the guy said you can only use
the same subslots if i were to use a specific tool from srlabs. 

7- i used the test file from srlabs (vf_call6_a725_d174_g5_Kc1EF00BAB3BAC7002) with both grgsm_decode and the old gsm_receive.py which is run by go.sh command from airprobe. both outputs in the console and wireshark were exactly the same but when i try my own capture the outputs are very different. for example grgsm_decode outputs 21 rows to wireshark wile gsm_receive.py outputs only 10 raw. some information like paging response and some SI were missing in gsm_receive.
I captured my file with grgsm but i thought there should be no differnces in the decoding process. is such a thing possible ? can someone please confirm this ? i can provide sample capture data if needed.
also in gsm_receive sometimes i got these warnings:
WRN: errors=7 fn=1381758 , sch.c:260 ERR: conv_decode 1

but the output is still there for that frame and is identical to the one from grgsm_decode

8- SI5/5tier/6 are known to be repeated every 204 frames. I looked at SI1/SI2/SI3/SI4 and it seems they all follow the same pattern. (if not each 204 frames at least it's a multiply of 102). can someone confirm this ? what about empty packets ? if there's no pattern for empty packets which i guess is the case , isn't there any other ways to identify them after encryption is turned on ?

9- can we say the first packet after ciphering mode command is the first one after the cipher completed command from uplink ? the first packet that is again presented in plain-text.

10- if you look at the frame numbers in grgsm_decode when -p -v options are given in BCCH mode, I see there are sometimes single gaps between them. are these gaps due the the SDR not being able to capture that burst or are there other reasons? If I decode in SDCCH8 the gaps become even more but i think that's because frame numbers are continues in all Time Slots so since I decode a single timeslot . Would you say that's true ?

Sorry for the long post , I'd really appreciate any help

Best regards,
DH

[Tomcsányi Domonkos]

Hello Daniel,

I’ll try to answer as many of your questions as possible.

> 1- regarding the installation of gr-gsm there were 2 options to choose from, install with pybombs or use the manual mode. I installed gr-gsm a lot time ago and don't remember exactly how it went but i remember i ran into a lot of difficulties with pybombs (i specifically remember apache module and i still don't know where it's used.) and had to correct a lot of them manually. so right now gr-gsm works very well on my system but i've decided to start making my own flowgraphs and I ran into the problem of GRC not knowing where grgsm module is installed. (I don't have /usr/local/lib/python2.7/dist-packages/grgsm) but gr-gsm works. (i suppose i installed it as non root ?). what's the easiest way to solve this ?

PyBOMBS installation had some issue in the beginning, but it has been improved since then and it works fine. I installed and upgraded grgsm a week ago without any problems using it.

>
> 2- when using grgsm_capture.py I don't get anything in the console as a result wireshark doesn't show anything but after capture i can see packets with grgsm_decode. what could cause this problem?

Capture is for capturing, decode is for decoding :).

>
> 3- both grgsm_capture.py has a -v option but when i give it as an argument i get this error :
> Traceback (most recent call last):
> File "/home/daniel/gr-gsm/bin/grgsm_capture.py", line 264, in <module>
> rec_length=options.rec_length, args=options.args)
> File "/home/daniel/gr-gsm/bin/grgsm_capture.py", line 89, in __init__
> self.gsm_clock_offset_control = grgsm.clock_offset_control(fc-shiftoff, sample_rate, osr=4)
> NameError: global name 'sample_rate' is not defined
>
> 4-the same happens for trying to capture as burst (-b)

That’s probably a bug, Roman should fix it when he has time. Meanwhile I guess changing the code to

self.gsm_clock_offset_control = grgsm.clock_offset_control(fc-shiftoff, samp_rate, osr=4)
should fix your issue, but I’m not sure.

>
> Question regarding GSM
>
> 5- if you have a samsung phone and you dial *#0011# it gives you a simple GSM info screen. i can see MCC, MNC , BAND , ARFCN , NOM , Rac , etc
> what are NOM and Rac? mine shows NOM:2 and Rac:1 . also i see the Timing Advance parameter which is 0 for me (right now at least). is this the
> same Timing advance parameter in the L1 header? if yes how would this be related to the packets send from BTS to my MS? should i inspect packets with TA:0 for myself?

NOM is Network Operation Mode, nothing you need to care about. RAC could be UMTS/3G terminology for Routing Area Code - again nothing to worry about. Timing Advance is indeed the parameter you should see in the L1 header, but in 99% of the cases it will be 0 (except if you are truly out in nowhere without any civilization and the tower is really far..in an urban environment that’s not likely).

>
> 6- how can i use subslot to make a better filter to find the right Immediate Assignment? i saw this video that the guy said you can only use
> the same subslots if i were to use a specific tool from srlabs.

You don’t need to worry much about subslots, it’s still easy to find the right Assignment.

>
> 7- i used the test file from srlabs (vf_call6_a725_d174_g5_Kc1EF00BAB3BAC7002) with both grgsm_decode and the old gsm_receive.py which is run by go.sh command from airprobe. both outputs in the console and wireshark were exactly the same but when i try my own capture the outputs are very different. for example grgsm_decode outputs 21 rows to wireshark wile gsm_receive.py outputs only 10 raw. some information like paging response and some SI were missing in gsm_receive.

A little correction: the file is not from srlabs, it is from Piotr (creator of this project). The difference you see in the output is because grgsm is a lot better in decoding captures then gsm_receive. Since you did a capture on an RTL-SDR the difference became obvious (the old file was recorded using a USRP hence it could be decoded by both tools quite well).

> I captured my file with grgsm but i thought there should be no differnces in the decoding process. is such a thing possible ? can someone please confirm this ? i can provide sample capture data if needed.
> also in gsm_receive sometimes i got these warnings:
> WRN: errors=7 fn=1381758 , sch.c:260 ERR: conv_decode 1
>
> but the output is still there for that frame and is identical to the one from grgsm_decode

Again, leave gsm_receive alone, it is an old piece of code that has multiple issues (pointed out by Piotr himself as well). For example the error you see is exactly a result of one of the bugs.

>
> 8- SI5/5tier/6 are known to be repeated every 204 frames. I looked at SI1/SI2/SI3/SI4 and it seems they all follow the same pattern. (if not each 204 frames at least it's a multiply of 102). can someone confirm this ? what about empty packets ? if there's no pattern for empty packets which i guess is the case , isn't there any other ways to identify them after encryption is turned on ?

That’s incorrect. Read Sylvain’s explanation and open and read the standard he mentions (it’s just 5 pages or so): https://lists.srlabs.de/pipermail/a51/2010-July/000804.html

>
> 9- can we say the first packet after ciphering mode command is the first one after the cipher completed command from uplink ? the first packet that is again presented in plain-text.

I don’t understand what you mean here.

>
> 10- if you look at the frame numbers in grgsm_decode when -p -v options are given in BCCH mode, I see there are sometimes single gaps between them. are these gaps due the the SDR not being able to capture that burst or are there other reasons? If I decode in SDCCH8 the gaps become even more but i think that's because frame numbers are continues in all Time Slots so since I decode a single timeslot . Would you say that's true ?

No. Frame numbers are called frame numbers because they are the number of a frame :). Meaning that in all timeslots the frame number will be the same. I’m not sure what you see, but since a single GSM message is transmitted in multiple frames you must see gaps in the frame numbers (frame1 comes in, containing 1/4th of a message, then frame2 with the second fourth etc. so in the end 4 frames need to be decoded to get the full message which is then sent to wireshark).

Cheers,
Domi