There are plans to register signal handlers in acc_ramp_init(). Once we
do that, the acc_ramp_init() function should only be called once to
avoid duplicate signal handlers on the handler list.
However, the acc_ramp_init() function currently serves a dual-purpose:
1) Initialize the acc_ramp structure for a bts
2) Enable or disable ACC ramping
Add new functions to support use case 2, and call acc_ramp_init()
just once while reading the configuration file. The VTY commands
which enable/disable ACC ramping use the new APIs instead.
Also, rename acc_ramp_start() to acc_ramp_trigger() and tweak its
semantics so that it can always be called regardless of what the
current configuration settings are. This prepares us for triggering
ACC ramping upon events other than "RSL link-up".
Change-Id: Ia25bff85d9e5c277da76bffa11d31972e9fdc323
Related: OS2591
It can be obtained from cmd field, so no need to store it in pending.
This way we simplify the ad-hoc struct bsc_cmd_list.
Change-Id: I6de64fc128ad623ca30b9e6cebebaff8de18f95d
Silence log messages about no-op changes to access granted to access
control classes. For example, these always occur while configuration
files are being loaded.
Change-Id: I37580f4058f6e3a21d338234b1e22ea46f9538c6
Related: OS#2591
Remove a redundant call to acc_ramp_init() during bootstrap_bts().
ACC ramping state is already initialized during VTY config parsing,
and bootstrap_bts() accidentally disabled ACC ramping again even
if it was enabled in the configuration.
This bug was introduced in last-minute refactoring during
review of https://gerrit.osmocom.org/#/c/6324/ when the
acc_ramping_enabled flag was moved from struct gsm_bts to
the acc_ramp structure itself.
Also remove an acc_ramp_init() call in bootstrap_rsl().
It is no longer needed as it serves no purpose other than
initializing the bitmasks of barred ACCs. To ensure that
ACC ramping configuration provided to the BTS via system
information stays correct, we move the call to acc_ramp_start(),
which has the same effect on barred ACCs, further up.
Change-Id: Ib7d99c9d3d5d424e21bb7710f719c42f9aef3e95
Fixes: 6442e4327b
Related: OS#2591
In a debug log message, an unsigned 64-bit value was printed with
%lu but it should be printed with PRIu64 from inttypes.h instead.
Change-Id: I09bb519e68886e650647b1369fd49d1964e76c7e
So far we only used to show the current mode of the timeslot for IPA
style dynamic PDCH, but not for osmocom-style.
Old output for osmocom-style dyn PDCH:
BTS 0, TRX 0, Timeslot 6, phys cfg TCH/F_TCH/H_PDCH, TSC 7
NM State: Oper 'Enabled', Admin 'Unlocked', Avail 'OK'
new output with this patch:
BTS 0, TRX 0, Timeslot 6, phys cfg TCH/F_TCH/H_PDCH, TSC 7 (PDCH mode)
NM State: Oper 'Enabled', Admin 'Unlocked', Avail 'OK'
where "PDCH mode" changes from "NONE mode" to "TCH/F mode" to "TCH/H mode"
depending on the current state.
Change-Id: If5044d6bec76b869bd6a7c0260a4c77e229dcd0d
Related: OS#3099
We used to start the dynamic PDCH initialization right after the
respective OML initialization of the related timeslot. However, this
is problematic as the RSL link may very well not even be up yet at
that point. So let's do this at RSL link esetablishment time, not
from OML.
Change-Id: I8ac30ca075a1db4b624dc38a423d844d705fda7e
Closes: OS#1841
The S_L_INP_TEI_UP signal was generated when the first message from a BTS
arrives on the OML/RSL link, rather than when the OML/RSL link comes up.
Instead, generate this signal when the link is brought up, so we
intitialize state regardless of how a particular BTS behaves.
Tested with osmo-bts-virtual and virtphy/mobile programs,
and with a sysmobts.
This was already committed in faf0982ae2
but subsequently reverted in 383a059a12
because it introduced a regression. The underlying problem causing this
regression has now been addressed by https://gerrit.osmocom.org/#/c/7462/
(libosmo-abis commit 49917c129b1456585258b0ebe89a513ecef823a8).
Change-Id: I78a152671a00b95c997830f7161fca92bb898fa3
Depends: I52f7c903212b38e9c87e4d45e52b231b6f1ae9f5
Related: OS#2719
Legacy VTY commands were removed in commit
c74a5616bf
== I5cf3fec31cc774c902f3cfe6d16fb85ef301694a
Removing the dead VTY commands currently breaks our ttcn3-bts-test and is
likely to create problems with users of osmo-bsc, when their config osmo-bsc
stops working with a mere upgrade.
Instead, add deprecated dummy commands that don't do anything, to not break
existing configs.
Catch all of these legacy commands:
timeout-ping <number>
timeout-pong <number>
timeout-ping advanced
no timeout-ping
no timeout-ping advanced
by defining
timeout-ping ARG
timeout-pong ARG
no timeout-ping [ARG]
I verified manually that starting osmo-bsc with all the abovementioned VTY
commands in the config file works (and produces the deprecation messages).
Change-Id: I95a5bad1ade66ded849cfc20bebb7fc522aecc38
There is a lot of dead code in osmo_bsc_msc.c that used to handle
the IPA multiplexed SSCP lite A interface.
- remove portions of the dead code
- remove IPA Ping related VTY commands
Change-Id: I5cf3fec31cc774c902f3cfe6d16fb85ef301694a
Fix various sanitizer complaints about memory leaks using a sanitizer build
with gcc (Debian 7.3.0-12) 7.3.0.
Also fix deprecation warnings on osmo_init_logging().
Depends: I216837780e9405fdaec8059c63d10699c695b360 (libosmocore)
Change-Id: I970c6f8a0e36a8b63e42349dbc92baff649e5cef
gsm_bts_alloc() ought to do all static initialization, so that e.g. unit tests
can use an initialized bts struct that is fully usable, just not registered at
the gsm_network.
For example, two INIT_LLIST_HEAD() and various system information data pointers
(pointing to proper places within the same bts struct) should definitely never
be omitted.
This fixes the remaining errors of gsm0408_test's SI tests, as revealed by a
sanitizer build using gcc (Debian 7.3.0-12) 7.3.0.
Fixes:
../../../../src/osmo-bsc/src/libbsc/system_information.c:613:3: runtime error: null pointer passed as argument 1, which is declared to never be null
Initializing the bts->si_common.rach_control results in different expected
bytes for SI2. The initialized values are
bts->si_common.rach_control.re = 1; /* no re-establishment */
bts->si_common.rach_control.tx_integer = 9; /* 12 slots spread - 217/115 slots delay */
bts->si_common.rach_control.max_trans = 3; /* 7 retransmissions */
bts->si_common.rach_control.t2 = 4; /* no emergency calls */
Causing a change to e5 04. 04 is t2 = 4, and the remaining values are verified by:
uint8_t re :1,
cell_bar :1,
tx_integer :4,
max_trans :2;
>>> hex(1 + (9 << 2) + (3 << 6))
'0xe5'
Change-Id: I13ef24bbe0f1fbe49465e67a0b67d6fd69fff3b1
Add missing deletion of osmo_stat_item_group_free(bts->bts_statg).
Add missing bts free after test_si_ba_ind().
Log deallocation, update expected test output.
This fixes some of the errors of gsm0408_test's SI tests, as revealed by a
sanitizer build using gcc (Debian 7.3.0-12) 7.3.0.
Fixes:
=================================================================
==19273==ERROR: AddressSanitizer: heap-use-after-free on address 0x60d0000004b8 at pc 0x7f1561a94621 bp 0x7ffe7a7a64a0 sp 0x7ffe7a7a6498
WRITE of size 8 at 0x60d0000004b8 thread T0
#0 0x7f1561a94620 in __llist_add ../../../src/libosmocore/include/osmocom/core/linuxlist.h:75
#1 0x7f1561a94620 in llist_add ../../../src/libosmocore/include/osmocom/core/linuxlist.h:90
#2 0x7f1561a94620 in osmo_stat_item_group_alloc ../../../src/libosmocore/src/stat_item.c:141
#3 0x5574f6a19935 in gsm_bts_alloc ../../../../src/osmo-bsc/src/libbsc/gsm_data.c:728
#4 0x5574f6a12920 in bts_init ../../../../src/osmo-bsc/tests/gsm0408/gsm0408_test.c:123
#5 0x5574f6a0ddb3 in test_si2q_e ../../../../src/osmo-bsc/tests/gsm0408/gsm0408_test.c:192
#6 0x5574f6a0ddb3 in main ../../../../src/osmo-bsc/tests/gsm0408/gsm0408_test.c:824
#7 0x7f156061aa86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21a86)
#8 0x5574f6a10339 in _start (/n/s/dev/make/osmo-bsc/tests/gsm0408/gsm0408_test+0xfc339)
Change-Id: I1ebbd8cc0622ce1a061e933813829b1f770072dc
If size <= 1, avoid allocating arfcns_left[size / 2], which results in a zero
size and causes, with gcc 7.3.0 sanitizer, runtime errors:
../../../../src/osmo-bsc/src/libbsc/arfcn_range_encode.c:95:6: runtime error: variable length array bound evaluates to non-positive value 0
../../../../src/osmo-bsc/src/libbsc/arfcn_range_encode.c:96:6: runtime error: variable length array bound evaluates to non-positive value 0
This fixes some of the errors of gsm0408_test, as revealed by a sanitizer build
using gcc (Debian 7.3.0-12) 7.3.0.
Change-Id: Idab2a194fb9d7c41ed3367f935080eaae4ce367f
We deliberately ignore errors from page_subscriber() so there is
no point in having a non-void return value.
Provide more context in the error message logged if paging failed.
Add a comment in an implementation override of base_grace_paging_request()
in the test suite to make return value semantics more clear.
Change-Id: Ie18c2ba53d2055d3eaff8c9ed939eb844af6dd2e
Related: I48f5efbcddd98e15256edfca06ba0ae6acb5bab1
The GSCON fsm has two illegal state transions. The transions
themselves are logically legal but theur respective entries
in out_state_mask are missing.
- remove unnecessary transition from ST_ACTIVE to ST_ACTIVE
- Add ST_CLEARING to the out_state_mask of ST_WAIT_HO_COMPL
Change-Id: I165c3e8b4b268b50e5f4a482b0fe890e940637b3
Closes: OS#3109
Fixes following compilation warning:
bts_nokia_site.c:1248:9: error: ‘ret’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
return ret;
This could happen if parameter len is passed with value 0.
If we reach the end of the function, it means everything went fine, so
we can return 0 instead of using ret, which is only used to store error
code before returning.
Change-Id: Ic60c8c632a6ddadb8f197d56cc68c2dbfc121d05
The BS-11 related tool bs11_config is currently not built due
to dependancy issues added by GSCON FSM.
- Re-Add bs11_config to makefile.am
- Add dependencies and stubs
Change-Id: I77ee8d2d36813ad98542317d003a9057c4f84e75
Related: OS#2823
The nanobts related tool ipaccess-config is currently not built due
to dependancy issues added by GSCON FSM.
- Re-Add ipacces-config to makefile.am
- Add dependencies and stubs
Change-Id: I1d0a45bed61b45352ed305b6b1fd8d9b3d3cecae
Related: OS#2823
The LAI encoding test in gsm0408_test.c uses deprecated API, and a more
thorough test for LAI encoding has been added in libosmocore/test/gsm0408/.
Change-Id: I8a55d717ab15ba23943a2639accaadc33a4f731a
Correctly compute the TS 48.008 "speech mode" (codec) for AMR on TCH/F.
There are way too many different ways how to express a given voice
codec. There are two different schemes in TS 48.008 alone, plus one
on TS 48.058 and one in 04.08 / 44.018. Let's avoid unneeded
conversion (that we might get wrong) and avoid storing information in
a sub-struct of the lchan if we can simply derive it from the lchan
at the time we need it.
Also, move BSSAP related encoding/conversion functions closer to the
user (osmo_bsc_bssap), rather than in libbsc.
Without this patch, TCH/F with AMR was erroneously reported as TCH/H
with AMR in the BSSMAP ASSIGNMENT COMPLETE. After this patch, it's
reported correctly.
Change-Id: I6feebfae77fdc93a7ce333a25dd9b9267c5a4a2e
Related: OS#3094
Related: OS#3095
Related: OS#3096
The first argument is the channel mode (codec), the second one is
a flag whether or not it's a full-rate channel.
Before this patch the two arguments are reversed, resulting in
* all assignments being TCH/F in general
* all assignments have FR1 as codec, as the full_Rate=1 is interpreted as FR1
Change-Id: I80f2a016a7646252bce8d86ed0bab236f3adbfca
Related: OS#3094
In AMR-type cahnels, the gsm0808_speech_codec doesn't only include
the codec (like EFR/FR/AMR) but also the specific codec configuration,
i.e. the sub-set of AMR modes.
Hence, we cannot convert from a channel type (just the codec) to the
full gsm0808_speech_codec and then memcmp() that with the codec config
received from the MSC. Rather, we must only compare the *type*.
Change-Id: I0a3f362667a689135d5b62d151d491490dfd2976
Related: OS#3094
The order of the arguments for forward_dtap() differs from
submit_dtap() and sigtran_send()
- bring arguments into a uniform order for all three functions
Change-Id: Ida77c82e600f99d690ffa1850450925359e33ae8
Related: OS#2823
Preceding commit I38ac98a4d25159cfd4f686efbfbaf8f00625a6d8 changed the
ipac_bcch_info.cgi type to osmo_cell_global_id, but did not carry out
corresponding changes in ipaccess/network_listen.c.
The reason this was not caught is that recent commit
I68286d26e2014048b054f39ef29c35fef420cc97 adding the new gscon FSM actually
disables ipaccess-config in the build.
Fix the build, given that ipaccess-config were re-enabled.
Change-Id: I15cd58e8ba0563ce4e42a61e79d01394b61593dd
Instead of a local redefinition, use osmo_cell_global_id.
This change is cosmetic because the decoded PLMN is currently actually never
used.
Change-Id: I38ac98a4d25159cfd4f686efbfbaf8f00625a6d8
This error message suggested that parsing a cell identifier list
failed because the list was too short. While, in fact, this code
has no insight into the reason behind the parsing failure.
A generic error message is more appropriate.
Change-Id: I033747e2183984159f1505e772d7c9494b759058
Related: OS#3073
Stefan Sperling
Pau Espin
Harald Welte
Neels Hofmeyr
Philipp Maier