25 Nov
2012
25 Nov
'12
5:29 p.m.
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
26 Nov
26 Nov
1:34 p.m.
New subject: Fix some ugliness
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
28 Nov
28 Nov
4:08 p.m.
New subject: Fix some ugliness
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
29 Nov
29 Nov
2:52 a.m.
New subject: Fix some ugliness
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.
1 Dec
1 Dec
8:48 a.m.
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?
--
- 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)
1:12 p.m.
On Sat, 2012-12-01 at 14:48 +0100, Harald Welte wrote:
Hi Frank,
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
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?
4618
days inactive
4624
days old
5 comments
3 participants
participants (3)
-
Frank A. Stevenson -
Harald Welte -
Holger Hans Peter Freyther