Attached is a patch that fixes some global ugliness. The dependencies are a bit iffy, so you need a make clean after applying this.
This fix needs to be in place before you decode multiple carriers. I would like to suggest that tetra-rx.c be changed so that it can receive multiplexed streams of input. Byte values of 0 / 1 will be the primary stream, but other values can be used to encode the multiplexed streams.
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.
Does this sound like a decent solution ?
f
On Sun, 2012-11-25 at 23:29 +0100, Frank A. Stevenson wrote:
Attached is a patch that fixes some global ugliness. The dependencies are a bit iffy, so you need a make clean after applying this.
This fix needs to be in place before you decode multiple carriers. I would like to suggest that tetra-rx.c be changed so that it can receive multiplexed streams of input. Byte values of 0 / 1 will be the primary stream, but other values can be used to encode the multiplexed streams.
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.
Does this sound like a decent solution ?
f
I made changes such as outlined in my previous mail, which allows tetra-rx to decode 16 carriers from a multiplexed stream. This works quite well, but my emacs config is a bit off so I have spaces where there ought to be tabs, and the uint16_t for GSMTAP arfcn value is a bit mysterious, since I get arfcn 0,256,768,1024 etc :-) so I need a better system for assigning arfcn values to the different carriers in the multiplex. My git status is currently something like:
# modified: tetra-rx.c # modified: tetra_common.h # modified: tetra_gsmtap.c # modified: tetra_gsmtap.h # modified: tetra_upper_mac.c
(including the ugliness fix), so it may be better to keep the cleaned up patch off the list when it is ready for submission. Who would like to review the changes ?
f
I put up a patch with my changes here:
http://traxme.net/usrp/multiplex.diff.gz
I hope this passes muster, functionally it is the same as before, but tetra-rx now accepts multiplexed input. Make clean is required.
f
On Mon, 2012-11-26 at 19:34 +0100, Frank A. Stevenson wrote:
I made changes such as outlined in my previous mail,... ...so it may be better to keep the cleaned up patch off the list when it is ready for submission. Who would like to review the changes ?
f
On Wed, Nov 28, 2012 at 10:08:18PM +0100, Frank A. Stevenson wrote: Hi Frank,
I hope this passes muster, functionally it is the same as before, but tetra-rx now accepts multiplexed input. Make clean is required.
My two cents..
+ carrier_table[cid] = talloc_zero(tetra_tall_ctx, struct tetra_rx_carrier); + init_carrier(carrier_table[cid],(uint16_t)cid);
should become carrier_table[cid] = tetra_create_carrier(cid); and the deinit then just tetra_delete_carrier(carrier_table[cid]) which then talloc free's the root. This way you can skip the NULL check and you stop to delete memory. talloc_free(NULL) will not cause a crash.
holger
PS: Feel free to send the entire patch to the ML.
Hi Frank,
On Sun, Nov 25, 2012 at 11:29:11PM +0100, Frank A. Stevenson wrote:
Attached is a patch that fixes some global ugliness. The dependencies are a bit iffy, so you need a make clean after applying this.
thanks, I'll merge it, it looks clean.
btw: It might be a good idea to send me your ssh public key, so i can give you commit access to the repository. You could then push your patches in a private branch...
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?
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
-
Frank A. Stevenson -
Harald Welte -
Holger Hans Peter Freyther