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)
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
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
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.
