For a long time, we see this annoying -Wstringop-truncation warning:
In function ‘parse_rsp’,
inlined from ‘trx_ctrl_read_cb’ at trx_if.c:647:6:
trx_if.c:416:2: warning: ‘strncat’ output may be truncated copying
between 0 and 45 bytes from a string of length 1495
416 | strncat(rsp->cmd, buf_in + 4, p - buf_in - 4);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There is no real need to use strncat() in parse_rsp(), because we
do not concatenate any strings but simply copy TRXC response parts
from the input buffer to the corresponding 'name' and 'parameters'
buffers. Let's use memcpy() instead. This also fixes the warning.
Change-Id: Ia10adf7d76abe9a423b07e828852fbfb53b95125
We need curly braces becausee1inp_line_get2() is basically a macro
that calls OSMO_ASSERT(), which in its turn contains an 'if' stmt.
Change-Id: I41a5fd13a7fa40e16bcf1a8099624b654274cee3
If the PHY is not powered on and we are not supposed to send any
bursts to it, then trx_if_send_burst() should just return early.
Change-Id: I578bd5a731ad88ebff283c75bb7eb268d9e7e787
Related: SYS#4895, OS#4941, OS#4006
If somehow the TRXC logic negotiates a non-supported TRXD PDU version,
then it's a serious bug in the code. Let's add an assert() for that.
Change-Id: I301377bcebd5e2bbcfc18b3637253ef261bb5b2e
Starting from TRXDv2, several PDUs may be batched together and sent in
all together a single datagram. This requires us to increase the buffer
size that we use for sending and receiving TRXD messages. Let's use
65536 matching the default MTU value for 'lo' interface on Linux.
Given that 65536 is quite a big number, let's allocate a shared Rx/Tx
buffer statically to avoid [potential] stack overflow.
Change-Id: I729451c8ecdc7ff2631beb423f15523db16b3ee3
Related: SYS#4895, OS#4941, OS#4006
This is a preparatory change for the upcoming TRXDv2 support:
* move common TRXDv0/v1 header parser into a separate function;
* move burst handling into a single, version independent function;
** determine modulation and burst length in trx_data_parse_pdu_v0();
Change-Id: I7aedd85a8d4f6d6191cd3b75272a688208fb2879
Related: SYS#4895, OS#4941, OS#4006
This significantly simplifies setups in which not only the IP DSCP
but also the IEEE 802.1Q PCP is to be set for RTP packets.
Depends: libosmo-abis.git I52c08f4b2a46981d002ef0c21e6549445d845a6e
Change-Id: Ia3a91e6788285be3e2e73defee63e6bd79c6258e
Related: SYS#5427
The current usage is to make osmo-bts-omldummy indicate BTS_FEAT_VAMOS
on OML, so that we can test osmo-bsc's behavior when VAMOS is enabled.
Related: SYS#4895
Depends: I699cd27512887d64d824be680303e70fff3677c1 (libosmocore)
Change-Id: Ib50990109f07884ef999ba5a4566f5d1d457b0ae
All these functions need the PHY instance pointer for logging,
they don't really need a pointer to 'struct trx_l1h'.
Change-Id: I626b4392a8bc57a3fe5e8c931aa1ce9dd505676c
Related: SYS#4895, OS#4941, OS#4006
The 'CHDR' stands for 'Common Header', but this does not apply to
TRXDv2 because TDMA frame number may not be present in the batched
PDUs. Let's avoid potential confusion by removing it.
Change-Id: I80495df474c432f4c0a4cfa6f917821d7b35859a
We do have TRXC/TRXD documentation in osmo-gsm-manuals repository.
This big comment is out of sync with what we have in the manuals,
so let's better remove it to avoid maintaining docs in several places.
Change-Id: Ibfcefcbb5f30fe9b6c691578a93e6fedd5644b30
Related: SYS#4895, OS#4941, OS#4006
TRXDv2 brings significant changes to the whole PDU structure, not
just the header. Let's highlight this in the code / strings.
Change-Id: Id0274bd1ae5c419548596ed1852e6a28ec62b713
Related: SYS#4895, OS#4941, OS#4006
New channel mode values have recently been added with change [1]
to 'enum gsm48_chan_mode'. The lack of default branch in
lchan2lch_par() caused build failures on Jenkins:
oml.c:956:2: error: enumeration value ‘GSM48_CMODE_SPEECH_V2_VAMOS’
not handled in switch [-Werror=switch]
oml.c:956:2: error: enumeration value ‘GSM48_CMODE_SPEECH_V3_VAMOS’
not handled in switch [-Werror=switch]
oml.c:956:2: error: enumeration value ‘GSM48_CMODE_SPEECH_V5_VAMOS’
not handled in switch [-Werror=switch]
This function is duplicated in osmo-bts-{lc15,oc2g,octphy,sysmo},
so we unfortunately need to apply the same fix to all copy-pasted files.
Change-Id: I557ff8cac6564d22485c101fba9212f5f0e95bb7
Related: [1] Ie0ea592da5610ae70290106d004e549cf3212a89
In change [1] I added the missing 'default' branch to the 'switch'
statement in lchan_tchmode_from_cmode(). This caused massive
regressions in ttcn3-bts-test, because osmo-bts started to NACK
some RSL CHANnel ACTIVation messages.
What caused a lot of regressions in ttcn3-bts-test is actually the
missing branch for RSL_CMOD_SPD_SIGN in the 'switch' statement.
It was not a problem before [1], because the 'default' branch was
not there. I was about to add the missing 'cause' when I realized
that this function needs to be reworked first...
First of all, lchan_tchmode_from_cmode() does a bit more than just
deriving RR (TS 44.018) channel mode from RSL (TS 48.058) channel
mode. It additionally stores the 'Speech or data indicator' to
the logical channel state, and also changes some global DTXd related
flags in 'struct gsm_bts'. Let's use a more precise name.
lchan_tchmode_from_cmode() -> rsl_handle_chan_mod_ie()
Together with renaming, it becomes logical to have the IE presence
check in rsl_handle_chan_mod_ie(), so that we can reduce code
duplication in the calling functions a bit.
Finally, the main problem is that coding and interpretation of the
6-th octet 'Speech coding algor./data rate + transp ind' depends on
the 4-th octet of the Channel Mode IE. We cannot handle all values
in one 'switch' statement without proper discrimination:
a) If octet 4 indicates Speech, then octet 6 shall be interpreted
as the GSM speech coding algorithm (FR, HR, AMR, etc.).
b) If octet 4 indicates Signalling, then octet 6 shall be set
to '00'O, because this is the only value defined in version
16.0.0 of 3GPP TS 48.058. All other values are reserved.
c) If octet 4 indicates Data, then octet 6 shall be interpreted
as CSD data rate further discriminated by service transparency.
Therefore, we need take both values into account. This can be
achieved by mixing them together using the bitwise operators,
just like we do in L1SAP code.
Change-Id: Iba967f5bd0cc8ad6cd3ccd40cca38b15ffe96b2c
Related: [1] I67a70132999be6580a29e6b814763309a6df4ae9
Related: SYS#4895, OS#4941
In [1] I introduced a regression, so osmo-bts started to complain:
This PHY does not support lchan TSC 3 != BSIC-TSC 7
on channel activation, despite the TSC in RSL_IE_CHAN_IDENT was 7.
The problem is that this statement:
cd = (const struct gsm48_chan_desc *) TLVP_VAL(tp, RSL_IE_CHAN_IDENT) + 1;
is basically equivalent to:
cd = ((const struct gsm48_chan_desc *) TLVP_VAL(tp, RSL_IE_CHAN_IDENT)) + 1;
so we actually shift the pointer by sizeof(struct gsm48_chan_desc)
and skip 3 octets instead of just one (IEI octet). Fix this.
Change-Id: Ic3a81396b60577e03c541d32839d07dc6d45c838
Fixes: [1] Id100f4c56fd5c1adad5d925d97240bed82981b9b
Fixes: OS#5121
* Calling l1if_provision_transceiver_trx() yelds nothing.
* It does not apply immediately, full restart required.
Change-Id: I93c9e19d0543f19528cec842b8be332b4d93214e
As the prefix in 'GSM48_IE_CHANDESC_2' implies, this IE belongs
to 3GPP TS 04.08 (or TS 44.018), so it can be used in the Radio
Resource assignment messages sent to the MS. While in this
function we're dealing with 3GPP TS 48.058, and thus the IEI
may be (and actually is) different for the RSL messages.
Also, according to 3GPP TS 48.058, section 9.3.5, the Channel
Description IE is included together with its element identifier,
so we need to skip one byte when doing the pointer casting.
Change-Id: Id100f4c56fd5c1adad5d925d97240bed82981b9b
Related: SYS#4895, OS#4941
Instead of blindly assuming what the PHY does support, and what
it does not, let's check the related feature vector.
Change-Id: I699cdddbfab111855998853548d9cfe956f7c60c
Related: SYS#4895, OS#4941
If for whatever reason it fails to initialize the TRXD or TRXC
interface, trx_phy_inst_open() would return an error. This
would cause bts_model_phy_link_open() to call trx_if_close()
on each of the PHY links, including those that were never
opened. This leads to a segfault in trx_if_close().
Make sure that in trx_if_init() we properly init 'struct trx_l1h',
so it's safe to call trx_if_close() at any time and in any state.
Change-Id: I1f128813528f505fede04799e84456f6271058d0
The measurement results / TCH indications that are handed when decoding
the TCH/H are off by two bursts. Since a measurement result / TCH block
is expected every two bursts anyway the problem can only be noticed when
a FACCH transmission is going on and the frame numbers of the BFI TCH
blocks appear to be missaligned towards the FACCH block.
The reason is that the incoming bursts are shifted into a 6 burst wide
buffer. The decoding functions always look at the beginning of that
buffer while the bursts are shifted into the buffer from the end. A
facch will always fit exactly in that buffer but TCH/H blocks are only
4 bursts wide and thereofre they need two additional bursts until they
reach the coverage of the decoding function. Lets fix this by putting
the correct frame number (from two bursts before) into the remap
functions in order to get the correct beginning of the block.
Since the FACCH transmission uses six blocks it takes out two TCH
blocks. This means that if we count the FACCH block we end up with a gap
of one TCH voice block. Lets generate a dummy measurement to compensate
the gap. This will also match the behavior of the osmo-bts-sysmo phy.
Change-Id: I1ad9fa3815feb2b4da608ab7df716a87ba1f2f91
Related: OS#4799
By reordering the instruction, we scheduler the timerfd prior to
processing the FN on the upper layers. This means the first timerfd
expiration even will happen more inline with the expected time, that is,
CLOCK IND time + GSM_TDMA_FN_DURATION_nS.
Let T(trx_sched_fn) be the time spent executing function trx_sched_fn().
With previous order, the timerfd would have been scheduled later, which
in the end would mean expiration would happen at time CLOCK_IND +
GSM_TDMA_FN_DURATION_nS + T(trx_sched_fn), hence ending up with an extra
skew of T(trx_sched_fn) added by ourselves.
This extra skew added may be important specially at startup time (when
this code path is used), since usually the load in the system is high
and skew is usually already higher, which means helping crossing
unacceptable thresholds which may end up in osmo-bts-trx stopping with
"No clock from osmo-trx" reason.
Change-Id: Ie2ba35cd87f0bd4078ac3b4b5ec2eacad36c4258
These fields are always aready set by the only caller of the function
trx_setup_clock(), so there's no use in re-setting them.
Change-Id: Id8a7141984e07eb11abae08e0c63ae7ebc333511
It can happen that the first burst we receive after enabling the PDCH
channel (when PCU connects to the BTS) is bid!=0. As a result,
chan_state->ul_first_fn is never set and defautl value 0 in there is
passed to the upper layers. As a result, when the 2nd block is
transmitted, this time with correct FN, the PCU will see a huge jump in
FNs. Since in PDCH the bursts are always consecutive, let's simply use
bi->fn - 3 as a first_fn and be done with the issue.
Related: OS#5020
Change-Id: Ie982caeb29f3ffd880b44e88a89b85ea3e6e6947
Vadim Yanitskiy
Harald Welte
Neels Hofmeyr
Philipp Maier
Pau Espin