Added fixups for msgb len field whenever the tail is modified
Also, added some clarifying comments
Change-Id: Ia725edbeafe26bd2ea9b5a1810d0b26bc79d84db
The tcs (Tetra Crypto State) struct now maintains information relevant for decryption, such as the current network, colour code, hyperframe, etcetera.
Also, the upper mac now calls a stub decryption function when receiving an encrypted resource.
Change-Id: I92d718789d6b7e84c1901d09165fce59cdf8c1ca
Slot stealing is how a traffic slot can be partially or fully "stolen" by a control channel. This patch adds support for that and maintains the stealing status in the tetra_mac_state. This can be used to prevent passing a signalling half slot to the voice decoder.
Change-Id: I01a112e6e74f75401649d358b8f98c6248d2522b
According to the tetra_tdma_time struct definition, the tn should be in range 1-4. Also, tetra_burst_sync_in increments the timeslot number when in a synchronized state. The timeslot is then normalized with normalize_tn which also expects the tn to be within the 1-4 range.
Change-Id: Ib0967fdeef3bf37c612124626a74d240aa571a66
tp_sap_udata_ind now accepts a parameter designating from which block
(first or second) of the downlink burst the bits originate (not
applicable for all downlink burst types). In some cases, the upper mac
needs this information, see ETSI EN 300 392-7 clause 6.4.1
Change-Id: I5ff316a773906328e19c3530b09d7412f9c731ec
When a bad frame is received, the scrambling should not be updated,
because setting scrambling to wrong values will completely break further
decoding (until another SYNC frame is received).
Change-Id: I5e88b52fcbb98532d7ab6ca85e4f956589a595ab
Running tetra-rx on a capture with lots of bit errors is not
deterministic. Investigation with Valgrind shows various errors about
uninitialised values in libosmocore's viterbi decoder.
The cause appears to lie in @lower_mac/viterbi.c@. The only function
there allocates space for 864 symbols and then fills it with the symbols
received. However, sym_count is sometimes less than 864, leaving the
rest of the array uninitialized.
Initializing it with @int8_t vit_inp[864*4] = {0};@ fixes the problem.
Change-Id: Ib745c387e21fb81afef69efcf7e46d5d49331c8f
Fixes: OS#3410
It's more stable ... here we just need a flexible length, which we
can 'fake' by creating a local copy of the 'code' definition on the
stack.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>