Tetra decoding

[grosminet]

unknown errors after too many installations

I tried to migrate from Kali 1.10 a to Kali V2 . It scratched and I have to re install .

For now , forget gnuradio 3.7 in kali V2.0 . It took me some late evening to understand the way gnuradio is installed on Kali V2 . It is a mess . nothing is working even TETRA

I re installed a Kali 1.1.0 a 32 bits . This was working fine before my kali V2 tests .With my same routines and installations , I have the following errors running this script :

#!/bin/sh
export TETRA_HACK_PORT=7379
export TETRA_HACK_RXID=$1
ulimit -c unlimited
./osmo-tetra-sq5bpf/src/demod/python/fcdp-tetra_demod_fft_plus.py -D hw:1 -o /dev/stdout | ./osmo-tetra-sq5bpf/src/float_to_bits /dev/stdin /dev/stdout | ./osmo-tetra-sq5bpf/src/tetra-rx /dev/stdin

./osmo-tetra-sq5bpf/src/float_to_bits: error while loading shared libraries: libosmocore.so.4: cannot open shared object file: No such file or directory
./osmo-tetra-sq5bpf/src/tetra-rx: error while loading shared libraries: libosmocore.so.4: cannot open shared object file: No such file or directory

First error below

>>> gr_fir_ccc: using SSE
sample rate: 192000
>>> gr_fir_ccf: using SSE
audio_alsa_source[hw:1]: snd_pcm_hw_params failed: Erreur d'entrée/sortie (means I/O error) :

comments:

alsamixer is working fine

Traceback (most recent call last):
File "./osmo-tetra-sq5bpf/src/demod/python/fcdp-tetra_demod_fft_plus.py", line 96, in <module>
app = stdgui2.stdapp(my_top_block, "OsmoTETRA FCDP", nstatus=1)
File "/usr/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py", line 38, in __init__
wx.App.__init__ (self, redirect=False)
File "/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 7981, in __init__
self._BootstrapApp()
File "/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 7555, in _BootstrapApp
return _core_.PyApp__BootstrapApp(*args, **kwargs)
File "/usr/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py", line 42, in OnInit
self._max_noutput_items)
File "/usr/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py", line 64, in __init__
self.panel = stdpanel (self, self, top_block_maker, max_nouts)
File "/usr/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py", line 94, in __init__
self.top_block.start ()
File "/usr/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", line 97, in start
self._tb.start(max_noutput_items)
File "/usr/lib/python2.7/dist-packages/gnuradio/gr/gnuradio_core_runtime.py", line 3035, in start
return _gnuradio_core_runtime.gr_top_block_sptr_start(self, max_noutput_items)
RuntimeError: check topology failed on audio_alsa_source(1) using ninputs=0, noutputs=2

any ideas ?

 

[grosminet]

additional comment to previous message

Error libosmocore solved using sq5bpf version of liboscomore . Means can't run telive/tetra and last version of gr-gsm

alsa error is only for funcube pro + / RTL fine / funcube : OK

hardware pb on my funcube pro plus : could be

 

[sm0vec]

I think I fixed that bug last night, let me know if it's still there and I'll take a look.

Installed, I'll run it over night, then I'll have a some 100's calls to check.

Hmm, you mean the leading zero? That's how tetra-rx sends it. I can try to strip it, but is it guaranteed that no number will ever start with a zero? I should probably look better at the telive code here...

Well, the original osmo-tetra messages have leading zeros (01517210) like D-SETUP and D-CONNECT, while the messages written by SQ5BPF only have the number (1517210), like DSETUPDEC and DRELEASEDEC. So in this case the same number might appear twice in the filename.

I was originally thinking of doing this (IIRC, the GSSI can be gotten just by looking at the SSI parameter to D-SETUP) but from the standard it looked like group-IDs were temporarily assigned and not persistent. Is it still useful to implement this?

The current implementation from SQ5BPF doesn't fully decode all commands (I've done my own modifications to include more so I don't remember exactly which are in the original code), but at least by looking at D-SETUP with IDT:6 will at least give a quite good match of GSSI's

Thanks for your feedback, looks like I have to read more of the ETSI standards...

Yes, especially D-CONNECT can give more information, but I have really tried to understand how to transfer the ETSI standard to the code. I've found several bit-patterns which have helped me to get the GSSI also from D-CONNECT. Different bit-patterns makes the GSSI appear on different positions, but I can't figure out what the bits mean... even while looking at the standard at the same time, it just doesn't match up. (I'm almost start to think it's a but somewhere in the original osmo-tetra code)

 

[sm0vec]

Installed, I'll run it over night, then I'll have a some 100's calls to check.

It's still crash after some time (305 recordings during 2 hours and 20 minutes... only tested once). I didn't see any special reason for the crash. It could be worth to mention that I've modified some parts myself of the receiver software, but since Telive never crashes and your script actually works quite long time, I think it's some bug remaining.

 

[asgard]

hi again, after loots of hours i managed to install telive and gnu radio on kali 2.0.all but still have some problems.. in gnuradio companion i have missing block marked with red :
key: osmosdr_source_c
wx gui fft sink
frequency xlating fir filter
gr_fractional_interpolator_xx
key: gr_file_sink

how to solve this?
br

 

[grosminet]

hi again, after loots of hours i managed to install telive and gnu radio on kali 2.0.all but still have some problems.. in gnuradio companion i have missing block marked with red :
key: osmosdr_source_c
wx gui fft sink
frequency xlating fir filter
gr_fractional_interpolator_xx
key: gr_file_sink

how to solve this?
br

I gave up Kali 2.0 . It is a mess . I didn't understand what part and where gnuradio 3.7 is installed .
I tried several installations using pybombs to reinstall Gnuradio . It is not a standard gnuradio installation . Only gnuradiocompanion is working .

I put a request on kali 2.0 forum with no answer . I moved back to kali 1.1.0a

 

[grosminet]

I tried to migrate from Kali 1.10 a to Kali V2 . It scratched and I have to re install .

For now , forget gnuradio 3.7 in kali V2.0 . It took me some late evening to understand the way gnuradio is installed on Kali V2 . It is a mess . nothing is working even TETRA

I re installed a Kali 1.1.0 a 32 bits . This was working fine before my kali V2 tests .With my same routines and installations , I have the following errors running this script :

#!/bin/sh
export TETRA_HACK_PORT=7379
export TETRA_HACK_RXID=$1
ulimit -c unlimited
./osmo-tetra-sq5bpf/src/demod/python/fcdp-tetra_demod_fft_plus.py -D hw:1 -o /dev/stdout | ./osmo-tetra-sq5bpf/src/float_to_bits /dev/stdin /dev/stdout | ./osmo-tetra-sq5bpf/src/tetra-rx /dev/stdin

./osmo-tetra-sq5bpf/src/float_to_bits: error while loading shared libraries: libosmocore.so.4: cannot open shared object file: No such file or directory
./osmo-tetra-sq5bpf/src/tetra-rx: error while loading shared libraries: libosmocore.so.4: cannot open shared object file: No such file or directory

First error below

>>> gr_fir_ccc: using SSE
sample rate: 192000
>>> gr_fir_ccf: using SSE
audio_alsa_source[hw:1]: snd_pcm_hw_params failed: Erreur d'entrée/sortie (means I/O error) :

comments:

alsamixer is working fine

Traceback (most recent call last):
File "./osmo-tetra-sq5bpf/src/demod/python/fcdp-tetra_demod_fft_plus.py", line 96, in <module>
app = stdgui2.stdapp(my_top_block, "OsmoTETRA FCDP", nstatus=1)
File "/usr/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py", line 38, in __init__
wx.App.__init__ (self, redirect=False)
File "/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 7981, in __init__
self._BootstrapApp()
File "/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 7555, in _BootstrapApp
return _core_.PyApp__BootstrapApp(*args, **kwargs)
File "/usr/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py", line 42, in OnInit
self._max_noutput_items)
File "/usr/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py", line 64, in __init__
self.panel = stdpanel (self, self, top_block_maker, max_nouts)
File "/usr/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py", line 94, in __init__
self.top_block.start ()
File "/usr/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", line 97, in start
self._tb.start(max_noutput_items)
File "/usr/lib/python2.7/dist-packages/gnuradio/gr/gnuradio_core_runtime.py", line 3035, in start
return _gnuradio_core_runtime.gr_top_block_sptr_start(self, max_noutput_items)
RuntimeError: check topology failed on audio_alsa_source(1) using ninputs=0, noutputs=2

any ideas ?

USB 3.0 error . restart laptop on an USB 2.0 and I is working fine

 

[asgard]

I gave up Kali 2.0 . It is a mess . I didn't understand what part and where gnuradio 3.7 is installed .
I tried several installations using pybombs to reinstall Gnuradio . It is not a standard gnuradio installation . Only gnuradiocompanion is working .

I put a request on kali 2.0 forum with no answer . I moved back to kali 1.1.0a

hmm i bill go back to ubuntu 15.02 and give another try..it will blank my hair.. )

 

[nam-shub]

sm0vec,

Thanks for your info and suggestions, they are really helpful. Haven't had much time to work on this but should soon.

It's still crash after some time (305 recordings during 2 hours and 20 minutes... only tested once). I didn't see any special reason for the crash. It could be worth to mention that I've modified some parts myself of the receiver software, but since Telive never crashes and your script actually works quite long time, I think it's some bug remaining.

Could you post the traceback that gets printed to the console when it crashes? I've not had any crashes here yet, but I have noticed other bugs regarding SSI handling that I haven't had time to fix yet, might be another case of filename-too-long.

- The 'channel / index' as you used, and also SQ5BPF have based Telive, should only be used to separate different streams. It's the Call ID which makes each session unique and a call (identified by the Call ID) can span over several 'channels / indexes'. On a site with several physical channels (frequencies), there can more than one simultaneous call on the same 'channel /index' since this only have to be unique per physical channel (many systems have indeed different indexes allocated to each physical channel, but many new systems I've use the same range of indexes on each physical channel which makes the audio unintelligible since it's a mix between two voice streams when index is used as the identifier)

Do you think you could send me a short capture of such a system where a call moves between channels?

Ideally a pcap capture of the port your tetra-rx outputs from, for example:
tcpdump -n -i lo -s 0 -w tetra.pcap 'port 7381'

Then I can replay it on my end for testing.

 

[texas95]

/gnuradio/gr-blocks/lib/file_source_impl.cc] fseek failed EOF
what is mot ok?

 

[texas95]

/gnuradio/gr-blocks/lib/file_source_impl.cc] fseek failedEOF

 

[sameehosen]

Hello all
I got this letter today may be useful to work
**** Log start ****
20151007 22:18:57 FUNC: SDS [010011111010101100110001111000000000000011111100000011111010011]
20151007 22:18:57 FUNC: SDSDEC [CPTI: 2 CalledSSI: 9871190 CallingSSI: 11323264 CallingEXT: 258110 UserData3: 0x6E 0xCB 0xEF 0x33 0x41 0x00 0x00 0x00] RX: 3
20151007 22:19:20 FUNC: DRELEASEDEC SSI: 214675 CID: 9451 NID: 7 [Forwarding (diversion) activated] RX: 3

20151007 22:49:46 FUNC:SDS [0100111111110110010110101000011010000010111011010000000011010010]
20151007 22:49:48 FUNCRELEASEDEC SSI:298213 CID:7357 NID:11 [Call put on hold (remote hold)] RX:1

 

[sameehosen]

Hello to everyone again
All calls expire after 58 seconds.
Is this a problem or is it a natural

 

[sq5bpf]

Hello to everyone again
All calls expire after 58 seconds.
Is this a problem or is it a natural

active calls should not expire, calls which don't have any more traffic do.

if you want to change this time for some reason, then look into the internal tuning parameters briefly documented in rxx, or RTFS. this can be changed by the TETRA_SSI_TIMEOUT env variable (and while you're at it, look also at TETRA_REC_TIMEOUT, TETRA_IDX_TIMEOUT and TETRA_CURPLAYING_TIMEOUT)

also sometimes a call will jump to a new usage identifier, and this will cause the previous one to expire. this will be solved in the future by using the call identifiers (already present in the telive protocol). btw i am back, and will probably start working on the next version within a few weeks

 

[jlxsolutions]

This dosent look like it is decoded correctly then again i might be wrong
20151013 13:34:31 FUNC:SDS [010011110010001000111111111010101111101010100110001011001110101]
20151013 13:34:31 FUNC:SDSDEC [CPTI:0 CalledSSI:9510901 CallingSSI:136 CallingEXT:0 UserData4: len:2029 protoid:7D(Other Reserved) DATA:[0x53 0x16 0x75 0x20 0xDA 0xEB 0x6D 0x4F 0x4D 0x42 0x7E 0x64 0xF6 0x3A 0x01 0xD4 0x7B 0xCC 0x68 0xF7 0x07 0x37 0xA5 0x95 0x1D 0x3D 0xA4 0xA0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x80 0x1C 0x1C 0x00 0x00 0x00 0x00 0xC0 0x00 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x20 0x38 0xFE 0x9E 0x0A 0x7F 0x1C 0x00 0xC0 0x1C 0x1C 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x30 0x30 0x02 0x33 0x80 0x1C 0x1C 0x00 0x00 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x22 0x26 0x10 0x20 0x01 0x10 0x7F 0x00 0x00 0x80 0x1C 0x1C 0x20 0x01 0x00 0xFF 0x88 0x00 0x00 0x40 0x00 0x00 0xA0 0x40 0x00 0x40 ]] RX:2

or theese
20151013 14:02:17 FUNC:SDS [010011111101111010010010010000110010001010010001110100000000110000011110100110110000111110100000]
20151013 14:03:43 FUNC:SDS [010011111101111010110101011111010100101110111100110101011001010110010011010001010101001110001110]
20151013 14:05:33 FUNC:SDS [0100111110001011001110100110000010010111001000000100000110100001010100110010110100011101100011]
20151013 14:05:33 FUNC:SDSDEC [CPTI:2 CalledSSI:14864024 CallingSSI:2943362 CallingEXT:6062342 UserData3: 0x15 0x32 0xD1 0xD8 0xFE 0xB3 0x71 0x29] RX:3

Also what does this meen haven't seen it before
20151013 15:43:23 FUNCRELEASEDEC SSI:7076401 CID:13821 NID:7 [Forwarding (diversion) activated] RX:2
?

 

[jlxsolutions]

this is also new
20151013 17:18:45 FUNCRELEASEDEC SSI:14066116 CID:13736 NID:8 [Identity presentation restricted] RX:2
wondering what identity presentation restricted means

(would'nt let me edit previous post anymore)

P.S
found the etsi docs and think i know what the [Forwarding (diversion) activated] is
some sort of call forwarding simply put lol

 

[bommel]

@jlxsolutions

SDS = Short Data Service (SDS) | TETRA network services

is that a new network or did they now start to encrypt their complete traffic ?

 

[jlxsolutions]

Well not new network but the SDS-Lip stopped appearing so i assume thoose got encrypted recently
but thoose kind of SDS type 4 (SDS-TL) messages started appearing instead just a few in a whole days log thou

 

[CqDx]

Anyone tried running this on Mac?

 

[sq5bpf]

Well not new network but the SDS-Lip stopped appearing so i assume thoose got encrypted recently
but thoose kind of SDS type 4 (SDS-TL) messages started appearing instead just a few in a whole days log thou

i don't think they got encrypted, because this would require a major reconfiguration of all devices. most probably the device that receives the LIP messages just moved to another cell, or is connected via some other means.

but if it did get encrypted because of telive, then i would consider this to be a big success (everything should be encrypted by default anyway, software like this forces people to do it)