AgeCommit message (Collapse)AuthorFilesLines
2021-10-20lchan_fsm: fix potential NULL-pointer dereference2021q1Vadim Yanitskiy1-0/+12
Test case TC_lost_sdcch_during_assignment from ttcn3-bsc-test causes osmo-bsc to crash due to for_conn being NULL. Change-Id: I373855b95f8bde0ce8f9c2ae7bf95c9135d33484 Related: SYS#5526, OS#5255
2021-10-20assignment_fsm: Check for conn->lchanPhilipp Maier1-0/+9
When the SDCCH gets released while the TCH still beeing activated, then the ChanActivACK that is received after the TCH is activated will trigger a segmentation fault in the assignment_fsm. The reason for this is that conn->lchan, which holds the SDCCH at that point in time, is now NULL. To prevent osmo-bsc from crashing, the FSM should check for the presence of conn->lchan first. If it does not exist, the FSM should terminate. (Assignment failed) Change-Id: I3b1cd88bea62ef0032f6c035bac95d3df9fdca7a Related: SYS#5627, OS#5255
2021-05-01manual: Include QoS chapter and add osmo-bsc specific exampleHarald Welte2-0/+48
Change-Id: I3b1d44fc545725172142b903190a3ff5094805dd Requires: osmo-gsm-manuals.git Id344c29eda2a9b3e36376302b425e9db1f6c0f28 Requires: libosmo-abis.git I8991dd6eb406a5b9a70498974fc1ad339452f871
2021-04-30fix test_gsm48_multirate_config: dump the complete AMR lv bufferNeels Hofmeyr2-8/+8
It's acceptable to verify an outcome by printing to an expected output. It's unacceptable to commit those expected outputs without first verifying that they are in fact correct! In this case, the output has obviously not been even read, since the length byte clearly indicates that one byte is missing from each buffer dump. I have now verified by hand against 3GPP TS 44.018 that each one of the generated octets are indeed correct. Change-Id: I92fcc7afe018a4a8dc91f0f2167e3a7835f623c9
2021-04-28lchan_fsm: mode modify: fix missing timeouts and error transitionsNeels Hofmeyr3-2/+10
Change-Id: I6364cfb78f661f5f7473dcec488e361e6a1dc9e4
2021-04-28lchan_release(): do not release UNUSED lchanNeels Hofmeyr1-1/+1
I noticed that lchan_release() is generally called in varying error situations, so it makes sense to generally skip the release procedure when the lchan is already in the UNUSED state. Change-Id: I6e9faf682d1668388d5470419110408a098b9900
2021-04-28comment: tweak pchan_subslots() descriptionNeels Hofmeyr1-2/+2
Change-Id: I4d3ca6efc7b4fadd6711ae80502027cec1b7b84e
2021-04-28log: drop duplicate logging in ts_setup_lchans()Neels Hofmeyr1-2/+0
Change-Id: I569229328229047d399033d1483d09d323826692
2021-04-28gsm_lchan_name_compute with ctxNeels Hofmeyr3-10/+5
Use a talloc ctx directly without an intermediate static buffer. A subsequent patch will add a name tweak for VAMOS secondary lchans, so it felt appropriate to first clean this. Change-Id: Idb922605c15242a2cdc7c34668c845a179a15660
2021-04-28Lb: make sure we never have missing timer configurabilityNeels Hofmeyr1-1/+1
After I found that X12 was missing from the VTY config, make sure that no timers have been forgotten in lcs_ta_req.c: change the default timeout to -1. We will notice missing timers during testing. Change-Id: I7c0b098622548bf0f0374c304522e6a9db0331e3
2021-04-28Lb: add missing X12 timer configurabilityNeels Hofmeyr2-0/+3
While adding timers for Channel Mode Modify, I notice that X12 is used in lcs_ta_req.c, but missing in net_init.c. Add it so that it is exposed on the VTY configuration. Change-Id: I19540f64de4937b39963bb66bebb1b5d433c2be2
2021-04-27Lb: RESET FSM: never send sccp_user == NULLNeels Hofmeyr1-0/+5
A crash was reported in bssmap_le_tx_reset() sending a RESET with sccp_user == NULL. A previous patch fixes what I infer as the root cause, but I thought let's also have this additional safeguard. Related: OS#5134 Change-Id: I13834c4e576e8d33e67cb63e222b41255cd94875
2021-04-27Lb: stop RESET FSM when sccp_user is unboundNeels Hofmeyr4-0/+17
A crash was reported in bssmap_le_tx_reset() sending a RESET with sccp_user == NULL. Looking at the issue I noticed that when the sccp_user is torn down, the RESET FSM should also be terminated. Add bssmap_reset_term_and_free() to the generic RESET FSM implementation and call from lb_stop() before sccp_user is set to NULL. Related: OS#5134 Change-Id: If412ef990fcdde8ff88098a5169e86f05cd1c7f0
2021-04-27abis_nm_ipaccess_rsl_connect(): use msgb to compose attrNeels Hofmeyr1-13/+10
So far the function uses insane byte array magic numbers to compose the OML "RSL Connect" message. For VAMOS, I intend to modify that message. To ensure sanity, first change the attr composition to msgb_put*(). Related: OS#4940 Change-Id: Iba005635cf86aee1fde77d58ef203e28eed92281
2021-04-27manual: Location Services: clarify BSC side addressNeels Hofmeyr1-2/+19
A clarification that I promised a while back but forgot to submit. Related: SYS#4876 Change-Id: I9b06ac7a2f2cb34cabfcec10af761322b8e962fb
2021-04-24SRVCC: Forward Last EUTRAN PLMN Id in Handover RequiredPau Espin Pedrol2-4/+12
""" The old BSS shall inform the new BSS of the MS's last used E-UTRAN PLMN in the "Last used E-UTRAN PLMN ID" information element included in the "Old BSS to New BSS information" Information Element if this information is present. """ Depends: libosmocore.git Change-Id I6280ce1abc283f1491bc6f391b2dd952df33a16b Related: SYS#5337 Change-Id: I6cf54f9a16d598f98dc56b25f0fef56225a25a28
2021-04-24SRVCC: Parse Last Used E-UTRAN PLMN Id in Handover RequestPau Espin Pedrol3-0/+39
Whenever SRVCC EUTRAN->GERAN is performed by the CN, it will set the Last Used E-UTRAN PLMN Id in order for the BSS to inform the MS about EUTRAN neighbors once the call is over. The last part (sending EUTRAN neighs) is already implemented, since same thing is done as per CSFB. However, we lacked the first part, where the EUTRAN PLMN Id is recorded for later use. Actually, in both cases, we end up building the list of neighbors without taking into accound the PLMN value (hence no filtering of configured neighs), but it only sends such a list if any PLMN was stored there, which means this patch is still necessary for a quick fallback to 4G after the call is over. Related: SYS#5337 Depends: libosmocore.git Change-Id I0e55e947b6fef6dad0cf1a6c16b781bef4cc76c5 Change-Id: Ia5008f11a4c36ef8085a2037d4abddd131086e6e
2021-04-23Revert "update neighbor ARFCNs on startup and config changes"Pau Espin Pedrol7-48/+3
This patch caused major breakage in my setup, with BSC printing at startup: "(bts=0,trx=0) Failed to generate System Information". And bts-trx printing all the time: "sysinfo.c:162 PH-RTS-IND: Unable to determine actual BS_AG_BLKS_RES value as SI3 is not available yet, fallback to 1" This reverts commit c1a5310a3ed75ff24dc2d6a48c09d8dfc89d944c. Change-Id: I5da365c93aedc6668a77b82ee9b68cbec64967e3
2021-04-22update neighbor ARFCNs on startup and config changesNeels Hofmeyr7-3/+48
The effects of the neighbor configuration depend on the LAC, Cell Identity, ARFCN, BSIC configuration of neighbor cells. Make sure that the neighbor ARFCN list in the System Information is updated. This may seem rather aggressive: updating the SI of all BTS if only one config item changed. But indeed even modifying one config item of one BTS may cause a change in the neighbor relations that many other BTS may have to the changed BTS. For example, if many BTS configure a 'neighbor lac-ci 42 23', and this cell's config changes to LAC 43, all of those other BTS need to update their neighbor ARFCNs. Also update the system information even before the BTS are connected and started up. The main benefit here is that the VTY 'show bts N' command then already lists the correct neighbor ARFCNs. In gsm_bts_trx_set_system_infos(), make sure that the updated SI is only sent to TRXes that are actually usable, otherwise abis_rsl_sendmsg() spams the log with complaints that a message's dst == NULL. Still return an error rc in case a TRX is not connected, so that the CTRL command bts.N.send-new-system-informations accurately returns whether SI were actually sent to all TRXes. The desire to have the ARFCNs listed in the VTY before starting up BTSes came during analysis for Ifb54d9a91e9bca032c721f12c873c6216733e7b1, which fixes a bug that is now much easier to verify being fixed. Change-Id: I2222e029fc225152e124ed1e8887f1ffd4a107ef
2021-04-19Send EUTRAN neighs based on whether Common Id msg contained Last used ↵Pau Espin Pedrol13-47/+76
E-UTRAN PLMN ID From 3GPP TS 48.008 sec 3.1.30 "Common ID": """ If the SCCP connection is established due to CSFB from E-UTRAN and the MSC supports return to the last used PLMN after CS fallback, then it should send the COMMON ID message to the BSS including the Last used E-UTRAN PLMN ID information element if available at the MSC immediately following the successful SCCP connection setup. """ Furthermore, 3GPP TS 48.008 version 16.0.0 Release 16 " CLEAR COMMAND", for field CSFB Indication, states: """ NOTE: This information element doesn't serve any useful purpose. MSCs should not send the information element unless it is required by the recipients (due to the need to interwork with older versions of the protocol). It is expected that in future versions of the present document, this information element will be deleted from this message. """ Hence, build up the EUTRAN neighbor list based on whether we received the Last E-UTRAN PLMN ID IE during Common Id. In the future, we should probably filter the list while populating it based on the received IE. This change will also allow reusing same mechanism for SRVCC EUTRAN->GERAN support, where te Last E-UTRAN PLMN ID IE can be found inside "Old BSS to New BSS information" IE in msg HANDOVER REQUEST. Related: SYS#5337 Change-Id: I5d290ac55eca5adde1c33396422f4c10b83c03d5
2021-04-18fix wrong ARFCNs in local-cell neighbor configNeels Hofmeyr1-3/+5
For neighbors configured without explicit ARFCN+BSIC ('neighbor bts N', 'neighbor lac-ci N M', ...), actually use the local neighbor cell's ARFCN. So far the code looked correct on first sight, but passed an unused part of the struct neighbor union, always resulting in ARFCN 0. Related: SYS#5367 Change-Id: Ifb54d9a91e9bca032c721f12c873c6216733e7b1
2021-04-15bssap: pass whole tlv_parsed to event GSCON_EV_A_COMMON_ID_INDPau Espin Pedrol2-12/+11
This change will allow handling more IEs in the future, like "Last used E-UTRAN PLMN ID" one. Related: SYS#5337 Change-Id: I96a0e1a7491fabf7aaad62207886821ad6194927
2021-04-15cosmetic: Fix typo in func descriptionPau Espin Pedrol1-1/+1
Change-Id: I26cd31bc3e127cba17be508d10a5fd3cf6498901
2021-04-14deprecation: use osmo_bts_features_*()Neels Hofmeyr3-2/+3
For "reported feature '%s'...", use the short feature name, which better matches the message. Change-Id: Ie09506fbf3a1f0e899f9f4c8070e3139fd1d5e9d
2021-04-14drop unused gsm_bts_trx->descriptionNeels Hofmeyr3-11/+0
Change-Id: I3c0778322b8c630b0eb9d9cd3ac3cc71386c9c12
2021-04-14drop unused func decl rsl_lchan_mark_broken()Neels Hofmeyr1-2/+0
Change-Id: Ib08e69720e2b9a6ea5f5b5d13baa9920c415f078
2021-04-12Replace all references to 'sysmobts' with 'osmo-bts'Vadim Yanitskiy8-27/+27
sysmoBTS is a BTS model sold by Sysmocom, which runs osmo-bts. The later may also work with some other back-ends, including the genaral purpose SDR hardware. Therefore, it's more logical to call it 'osmo-bts'. Change-Id: I93ab4dbf483e0786c35685b75ee4ea83bd591f7b
2021-04-12vty: deprecate BTS type 'sysmobts' in favor of 'osmo-bts'Vadim Yanitskiy8-11/+26
Change-Id: I60d5ff887a7c830180088904c2458f7e73ce3893
2021-04-12stats: Count transitions from BORKEN state due to LCHAN_EV_TS_ERROR signal.Alexander Chemeris3-0/+11
Change-Id: Ice3379020039dc3634aa3887939740729d720dee
2021-04-12[hopping] bootstrap_rsl(): do not call generate_ma_for_ts() againVadim Yanitskiy1-1/+0
It's already being called in inp_sig_cb(), once the A-bis/OML link is established. There is no need to do this on the A-bis/RSL link establishment again. Change-Id: I435018f439181cdd046ca99fe7e01ac85e226cce
2021-04-12[hopping] Rework generation of Cell/Mobile AllocationVadim Yanitskiy5-36/+93
Calculating the Cell Allocation (basically a bit-vector of all the frequencies allocated to a cell) on the OML link establishment has several downsides and potential problems: * Theoretically, more than 64 ARFCNs can be allocated for a cell via the VTY interface. The problem here is that the Mobile Allocation IE cannot contain more than 64 channels. * The BSC's operator will neither be warned by the interactive VTY shell during configuration, nor during the startup. * The BSC will accept such a configuration, but then will be unable to encode the Mobile Allocation IEs at run-time. This change aims to improve the situation by separating part of the logic from generate_cell_chan_list(), and invoking this part directly from the VTY commands. This way it will become impossible to configure more than 64 ARFCNs, neither via the config file, nor interactively from the VTY. Change-Id: I98211fb0684a973239f5760e1de52a24a1f4c33c
2021-04-08fixup for neighbor config for coverityNeels Hofmeyr1-2/+4
Check against NULL pointers to allow only resolving local or only remote neighbors in resolve_neighbors(). (Though no caller exists currently that would need this feature, it is trivial and more future-safe.) Related: CID#220459 CID#220460 Change-Id: I8c2046335ec6f8a5d6b757446c98d8e630ee015f
2021-04-07abis_nm: cosmetic: use osmo_bts_feature_name()Vadim Yanitskiy1-1/+1
Change-Id: I15078ac030b0b824a554239b19bc501c624e2a87
2021-04-07abis_nm: rework warnings about unknown / not supported featuresVadim Yanitskiy1-5/+14
The reported feature vector may contain new features the BSC is not aware of. Report each of them individually as NOTICE. It's normal when some BTS feature is considered as not supported by the BSC, but a BTS reports that it is - do not log this. Change-Id: I2f925bcdb010cb10d074bf7c82619e3ae1f8818b
2021-04-06[hopping] generate_ma_for_ts() returns no meaningful valueVadim Yanitskiy1-4/+2
Change-Id: Ic3ba3323459bba1336adb1f902cb2371edea1f71
2021-04-06[hopping] gsm48_send_rr_ass_cmd(): use Cell Channel Description from SI1Vadim Yanitskiy1-3/+5
Calling generate_cell_chan_list() on each Assignment Command is quite expensive, because this function basically re-constructs the Cell Allocation (using bitvec API) and the Frequency List from scratch. This IE can be borrowed from pre-calculated SI1 message, so let's do this. Change-Id: I9c8c5ae9059ff096765412b3f3c7181a94163afc
2021-04-06[hopping] generate_cell_chan_list(): make some pointers constVadim Yanitskiy1-2/+2
Change-Id: Ied4ee60224d71567ec613942ba1c03088e9b02f3
2021-04-06[hopping] vty: ensure no duplicate hopping ARFCN entriesVadim Yanitskiy1-0/+10
Change-Id: Ie27c859e3f16ada08a5cdc8ab4ac6e20a885a378
2021-04-04debug log, lchan_fsm: explain leaving wait_rll_rtp_establish stateNeels Hofmeyr1-1/+6
Before, it is not clear whether the RTP is already done setting up or the RTP is skipped entirely. This log message clarifies that. Change-Id: I18ffcf93e82ee47413e4b2f741ffbfbb18322e1d
2021-04-04Ignore CHANnel ReQuireD with Access Delay IE > 63Keith4-0/+33
It is observed that a CHANnel ReQuireD with access delay greater than 63 can be received from the Ericsson RBS. This results in osmo-bsc sending back a CHANnel ACTIVation with a Timing Advance IE containing the access delay value. The RBS NACKs this, leading to a BORKEN Channel. This patch makes the maximum acceptable access delay vty-configurable and Ignores CHANnel ReQuireD RSL Messages with Access Delay IE greater than that configured. Default value is 63. Related: OS#5096 Change-Id: Ie8987bcc0e43921bc753162b77a0efc68799b3ce
2021-03-24fix/refactor neighbor configNeels Hofmeyr19-1007/+907
The neighbor configuration storage is fundamentally broken: it requires all local cells to be configured before being able to list them as neighbors of each other. Upon config write-back, the neighbor config however is placed back inline with the other config, and hence a written-out neighbor config no longer works on program restart. The cause of this problem is that the config is stored as explicit pointers between local cells (struct gsm_bts), which of course requires the pointer to exist before being able to reference it. Instead, store the actual configuration that the user entered as-is, without pointers or references to objects that need to be ready. Resolve the neighbors every time a neighbor is needed. Hence the user may enter any config at any place in the config file, even non-working config (like a BTS number that doesn't exist), and the relation to actual local or remote neighbor cells is made at runtime. Abort program startup if the initial neighbor configuration contains errors. Related: OS#5018 Change-Id: I9ed992f8bfff888b3933733c0576f92d50f2625b
2021-03-24drop neighbor_ident_test.cNeels Hofmeyr5-478/+0
This tests the opaquely designed neighbor config storage. However, a subsequent patch will refactor the neighbor config storage, and this neighbor ident API will change fundamentally. No need to test this. The new storage will use the usual scheme of transparent struct and llist, the opaque design is not necessary and just bloats. There is no need to test a plain llist, so this test needs no replacement. Related: OS#5018 Change-Id: I6522796bf0bbb9ab83e49168bcbff7bc70fd6c6d
2021-03-24refactor handover penalty timersNeels Hofmeyr9-131/+135
So far the list of penalty timers was stored for an opaque target pointer. That was either a gsm_bts pointer for a local BTS, or a cell identifier list pointer for a remote-BSS cell. Reasons to refactor penalty timers: - The cell identifier list pointer came from the neighbor configuration storage, but the way cell neighbor config is stored will change in a subsequent patch. There will be no more cell identifier lists there. - Storing object pointers is inherently unsafe -- if an object gets removed and another gets allocated, the penalty timer could theoretically remain in force for an unrelated object. Rather store penalty timers for specific Cell IDs. Since remote-BSS neighbors can be requested by a cell identifier *list*, use a gsm0808_cell_id_list2 as key in the list of penalty timers. Fix handover_test.c: have different CI for each local BTS. So far it was the same LAC+CI for all BTSes, which now would make the test fail, because any penalty timer would appear to apply to all local cells. Related: OS#5018 Change-Id: I72dd6226a6d69c3f653a3174c6f55bf4eecc6885
2021-03-17stats: T3122 related: num_values 16 -> 60Oliver Smith1-20/+20
Increase the number of values saved in the FIFO from 16 to 60, so there is more time to read them out. Related: SYS#4877 Change-Id: Ic5fd7c0fa030004fd88fee74f0028fb93c9f2d10
2021-03-15Add command to enable RX diversity to RBS2000Javi5-2/+65
Allow selection of RX diversity from VTY Options are a,ab,b Default is 'a' so there is no change from previous behavior Change-Id: I430762b8cfa51060841d90ba4446de73bd557c6c
2021-03-13Add vty command for Ericsson RBS2000 syncJavi4-2/+37
This commit adds support for Selection of syncronization source. Options are internal for E1 and external for GPS Change-Id: Ia3d1acd6b3442238b35fc911092e12a6ac989adb
2021-02-23remove obsolete dependency on libosmo-sccpHarald Welte3-3/+0
We only use libosmo-sigtran these days, so we can remove the depdency to the old libosmo-sccp from osmo-bsc. We don't use LIBOSMO_SCCP_* variables in any Makefile.am, nor do we #include <osmocom/sccp/...> anywhere [anymore]. Change-Id: Ie478016ffb6e767ba10968c1ee2ab98db15a45a3 Related: OS#2601
2021-02-23Bump version: → Espin Pedrol5-29/+614
Change-Id: I0afcb06f8a7466f98cac26ff939a3813d4add1cc
2021-02-22CBSP: document rate counters and their mapping to basic/extended CBCHHarald Welte1-0/+26
Change-Id: Id298d547a90bb5d8e40f2cd300b7e1303bb43fdc
2021-02-20abis_nm: enrich debug messages with contextual infoVadim Yanitskiy1-41/+44
Change-Id: I68f64e6cae061a49733c4885ba383d2b9b4cfca9