Fix some uglyness

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/tetra@lists.osmocom.org/.

Frank A. Stevenson frank at hvitehus.no
Sat Dec 1 18:12:36 UTC 2012


On Sat, 2012-12-01 at 14:48 +0100, Harald Welte wrote:
> Hi Frank,
> > The easiest method is to use the high order bits of the input as a
> > "stream id", and dynamically create new state structs as they appear in
> > the stream.
> 
> I'm not really sure if the high-order bits is the best way to go ahead
> with this.  How many 'high order' bits are there?  Is it sufficient for
> number of channels that one might receive, even in a massive parallel
> receiver?
> 

The current 'hack' allows for 128 concurrent channels, which can be
packed in 3.2 MHz of spectrum so it may or may not be enough. I think if
you need more it might be an idea to start packing the bits into bytes
and multiplex at the levels of strings of packed bytes. But that is a
bit theoretical, since tetra-rx will start to use considerable CPU time
before this limit is reached.

In the current code the bursts could very well be identified with arfcn
in the printed output also, especially if you wish to process the stdout
stream for further analysis.

My original plan with this was to analyze the CMCE messages with an eye
to perform traffic analysis, and I have added some code to
macpdu_decode_resource() to analyze the LLC PDU, but it didn't take me
long to realize that the TM-SDU is actually encrypted, something the
source code comment fails to mention :-) Wireshark has also been serving
me complete garbage because of this :-(

I could clean up the little code I have written here for a commit, but
it is a line of research that I can't continue for lack of unencrypted
data.

  f









More information about the tetra mailing list