Nicolas ended up with linker issues due abis_rsl_sendmsg being
defined twice. Rename our version of the function and update the
code.
Patched with:
@i@
expression E;
@@
- abis_rsl_sendmsg(E)
+ abis_bts_rsl_sendmsg(E)
Currently it takes some time (around 30s) until it is detected that
the radio link is down after mute. Not till then the BSC is informed
and the call terminated.
This patch modifies this behaviour by sending a RSL_MT_CONN_FAIL
message with cause RSL_ERR_RADIO_LINK_FAIL for each muted and active
lchan immediately after the corresponding Change Administrative State
Request has been acknowledged.
Ticket: OW#976
Sponsored-by: On-Waves ehf
Currently only mute_state[0] (refers to ts[0]) is inspected to
determine, whether the Radio Carrier's state is set to LOCK.
This patch changes this by looking at all channels and using LOCK
if (and only if) all channels have been muted successfully.
Sponsored-by: On-Waves ehf
Currently the LEDs are being accessed directly from within the
l1_if.c file. So the handling of rf mute and activate/deactivate both
access LED_RF_ACTIVE directly. This may lead to an inconsistent LED
status.
This patch replaces these calls to sysmobts_led_set() by an abstract
equivalent bts_update_status(), that uses a set of independant status
ids. The associated values can than be combined into a visible LED
status. Currently LED_RF_ACTIVE is on iff BTS_STATUS_RF_ACTIVE is set
and BTS_STATUS_RF_MUTE is not set.
Sponsored-by: On-Waves ehf
Currently a Change Administrative State Request is just applied
unconditionally to the object's state object and then acknowledged.
This patch implements the special handling of setting the Radio
Carriers state to LOCK or UNLOCK. This is done by passing the
appropriate mute command to the L1 layer. Always all radio channels
are affected, it is not possible to lock single radio channels.
On success, an ACK is sent back to the bsc with the new state (based
on the state passed in the callback by the L1 layer). If something
went wrong or the firmware doesn't support RF mute, a NACK
(REQ_NOT_GRANTED) is sent instead.
Note that a NACK for such a request hasn't been sent by the BTS to
the BSC yet, so (albeit it's spec conformant to do so) the BSC must
be prepared to handle this correctly.
Ticket: OW#976
Sponsored-by: On-Waves ehf
This adds a new function
l1if_mute_rf(femtol1_hdl, ch_mute[8])
to set the mute state for each radio channel. On completion and iff
l1if_mute_rf() returned 0 the callback
oml_mo_rf_lock_chg(mo, ch_mute_state[8], success)
is invoked when the response from the superfemto DSP is received.
Ticket: OW#976
Sponsored-by: On-Waves ehf
This add the mappings for SuperFemto_PrimId_MuteRfReq and
SuperFemto_PrimId_MuteRfCnf to the arrays femtobts_sysprim_type,
femtobts_sysprim_names, and femtobts_sysprim_req2conf.
Sponsored-by: On-Waves ehf
Currently uninitialized elements of the femtobts_sysprim_type array
are mistaken as L1P_T_REQ (which is accidently the first element and
thus 0).
This patch adds a new element to the enum that has the value 0 to
detect uninitialized elements of the femtobts_sysprim_type array.
Those will then show up in the log as 'SYS Prim XXX is not a
Request!'.
This patch also adds missing definitions of the CalibTbl messages
in the femtobts_sysprim_type mapping so that the requests can still
be identified as such.
Sponsored-by: On-Waves ehf
The PCU is not capable of cleaning up properly. For now simply
exit the PCU in case the sysmobts has exited. This requires
osmo-pcu a30f47613abb7c22a26d534d66e478265a8c2c09 or later.
The PCU is forcing the activation of a PDCH. Currently the BSC
will receive a channel act ack for a channel that was not
activated at all. Use the "release_reason" flag of the lchan
to see if we have requested a normal activation or a silent
one.
It feels a bit odd to do it in the TX function but it is the
most easy solution right now. I have added logging so it will
not be totally silent.
This is used in the sysmoBTS 2050, where the maximum power is 40 dBm
We might want to add a safeguard of some kind to prevent people from
overdriving their transmitters.
The TRX nominal output power (as seen by OML) is the aggregate power
of any gain internal to the sysmoBTS (and managed by L1) and any
external PA. This is what is used in trx->nominal_power;
fl1h->l1_power is the transmit power to which we configure the sysmoBTS
L1. This is 23 dBm (200mW) by default in the sysmoBTS 1002, and 40 dBm
(5W) in the sysmoBTS 2050. However, if sysmoBTS 2050 is used in
single-TRX configuration, it may be used with higher power, which we can
now configure in the config file / vty.
TODO: A separate, additional field that keeps track of any gain added by
an external PA, e.g. if the sysmoBTS 1002 is used with a sysmoAMP.
If the clock is provided by an external (like GPS) clock, we should not
use the calibration value. The latter is only used in context of the
OCXO or VCTCXO.
If the EEPROM tells us that a given unit doesn't support a given band,
we shouldn't try to use it, even if the BSC tells us to use an ARFCN in
such an unsupported band.
The reason is simple: The given BTS unit might have band specific
filter / duplexer / PA.
This introduces a new get_signlink_remote_ip() function whcih we also
use in the RSL code to determine the RTP remote address if the CRCX/MDCX
contains no remote IP address IE.
libosmoabis has a BTS-side implementation of the IPA protocol for years,
and osmo-bts should have used that all the time. Unfortunately it had
its own local hack, this patch is migrating to the libosmocore
implementation.
For the sysmoBTS 2050 this appears to have a different sign. We can't
test this with NWL right now so we will need to see if this is a case
of ping/pong.
By default read the clock calibration from the EEPROM. It is
still possible to set it using the cli.
Signed-off-by: Nicolas J. Bouliane <nicolas.bouliane@nutaq.com>
Coverity wants us to check that fscanf has scanned the amount of
variables we want to have. Initialize the scan result to 0/0.0f
and warn if the scan has failed.
Fixes: Coverity CID 1040774, CID 1040773
Coverity insists that we should check the return value of the
calls to fseek. In general this is a good idea.
Fixes: Coverity CID 1040770, CID 1040771, CID 1040772
Calling eeprom_write would either re-use g_file or newly open the
file and set g_file but it will close the file as well. This will
lead to other code using fseek/fread on a closed file.
On top of that the general rule for the eeprom code now is that
read and write may not be mixed (due caching and other bits).
The issue got introduced in fcdba6bfac
when moving from the uint32_t pointer to a plain int. The code
was now like this:
if (connect_ip > 0) {
if (connect_ip == 0)
lookup_ip_based_on_rsl
...
Coverity detected this as logically dead code and it was breaking
audio handling for the osmo-bsc case. Remove the tristate handling,
the RSL behavior is that leaving out port/ip is like specifying it
as zero.
Fixes: Coverity CID 1040769
The array has three elements but check was for > _NUM_TEMP_TYPES (3)
so an access at array[3] was possible. It is unlikely to have
happened due the usage of enums. Use ARRAY_SIZE and >= on the real
array to avoid this problem.
Fixes: Coverity CID 1040760
The current code has 26 fseek/fread. Only the minority really results
in a call to read. Nevertheless the time for reading during the bootstrap
can take up to 7.82 seconds. Caching the header (which is already done
by fopen/fread) will result in one call to fseek/fread and only
consumes 0.784 seconds.
Commit 5643130664 by Daniel changed
the ciphering to go through the command queue. In this commit the
direction for the ciphering got turned around and was not spotted
by review. It worked in testing due the usage of A5/0 and in that
case the direction did not matter.
Holger Hans Peter Freyther
Harald Welte