tetra April 2011

tetra@lists.osmocom.org

6 participants
4 discussions

tetra-rx was missing the LLC layer
by Harald Welte 27 Apr '11

27 Apr '11

Hi! during some work over the last weekend on OsmocomTETRA and reading through many hours of real-world TETRA captures, I have realized that a lot of the data we displayed about the higher protocol layers (like MM, CMCE, ...) was completely bogus. The reason for it is simple and quite obvious: My old code made the assumption that the MLE layer is directly on top of the MAC layer - whereas in reality, there is the LLC layer in between. Not only that, but LLC also takes care of fragmentation and re-assembly, i.e. we were just printing some general nonsense. I've started to fix this in the git master banch and I have some local uncommitted code that actually implements re-assembly. I've successfully decoded some NTP/UDP/IP-in-SNDCP-over-TETRA frames from a real network, but the implementation is a big ugly hack and has many constraints. I will try to clean this up asap and commit it (maybe even later today). This posting is JFYI, so you are not surprised if you now get some completely different output with the same input data. The good part is that we actually get the CMCE messages that tell us when and where will be voice frames that belong together, i.e. we can identify start and end of indivdiual push-to-talk 'segments'. This could be a nice base for extracting them in a useful format. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 1

educational samples and theoreticaly ways to get them
by Marius Ciepluch 26 Apr '11

26 Apr '11

Hi! My name is Marius and yesterday, though I was in a hurry to catch my train back to HL, I was in Harald's ETSI Tetra presentation. It was great; and I do have a USRP2, portable power supply, a sailing license (there're these big coast-guard towers here). Any implications are theoretically of course at this point. Just a small question: can one expect legal trouble if... accidently though... some Tetra signals found their way into a GR cfile onto some web server and would be shared (here)? Afaik it's not excactly ISM band. And to the second question: what was the name of the recommendable book, that was not marketing foo? I'd like to give the cryptanalysis a try, but before I can say that I have to look at the standards and algorithms. Did anyone already review that? I know that Stephen Glass of the OP25 project did some research on APCO 25. - Which isn't ETSI. Best, Marius -- pgp id: 0xCCCA5E74, mc - at - sandokai.eu http://crazylazy.info/blog, twitter: @wishinet

5 5

Where to store the stack "state"
by Sylvain Munaut 25 Apr '11

25 Apr '11

Hi, To add support for traffic extraction, it's necessary to introduce some nothing of "state" in the MAC layer (since the DL_USAGE must be 'remembered' to know how to interpret further data) ... Any suggestion how to achieve that as cleanly as possible ? Having a global doesn't sound that nice, but passing a struct around either. Maybe introduce a pointer to a 'tetra_state' in the primitive struct ? Cheers, Sylvain

2 1

neighboring cells information
by Зайцев Андрей 07 Apr '11

07 Apr '11

Hello and sorry for my english. Please help me. I need to decode the message D-NWRK-BROADCAST (chapter 18.4.1.4.1 from ETSI EN 300 392-2 V2.3.2). The fact is that I want to receive information of neighboring cells, but do not know how to do it. Standard called following about this message: “Upon receipt from the SwMI, the message shall inform the MS-MLE about parameters for the serving cell…” How to modify the source code in order to decode this message. Thank you. With best regards Zaytcev Andrey.

2 3

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tetra April 2011