aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2020-09-17lchan_fsm, lchan_rtp_fsm: make all timers configurableneels/timersOliver Smith4-6/+24
Choose saner timer numbers before exposing to the user config. Related: SYS#4897 Change-Id: I637fcdde93c11158de46157d494c060bb36bdcfb
2020-09-17clean up timer definitions: introduce groups, move some T to XNeels Hofmeyr7-75/+150
Backwards compatibly, introduce timer groups in OsmoBSC, and move some non-specified T timers to new X timers: T993111 -> X3111 T993210 -> X3210 T999 -> X4 Why X4? because there already is an X3 used elsewhere in Osmocom, and I find it less confusing if X-numbers don't repeat across programs. See https://osmocom.org/projects/cellular-infrastructure/wiki/List_of_Timer_numbers Drop unused timers from g_mgw_tdefs. Only X2427 has an actual effect. (libosmo-mgcp-client recently moved T2427001 to X2427.) Put libosmo-mgcp-client related timers to the 'mgw' group, like in osmo-msc. This makes the MGCP timeout configurable for the first time. Keep previous timer commands as DEFUN_HIDDEN, and also translate the moved T timers to X timers on-the-fly. All previous VTY commands still work, and new 'timer [(net|mgw)] ...' commands are added. timer.vty shows this. Remove the "_OPTIONAL" from the legacy "timer" and "show timer" commands, so that they don't ambiguously overload the new "timer [(net|mgw)] ..." commands. Related: OS#4539 Related: If097f52701fd81f29bcca1d252f4fb4fca8a04f7 (osmo-mgw) Change-Id: I4beec47502afa193dee343869c4be55dc6a4b536
2020-09-17abis_nm: improve logging message in abis_nm_get_attr()Vadim Yanitskiy1-4/+5
Change-Id: I10ef08e7d01ed27e05ef30c0bb876c0197a30500
2020-09-17abis_nm: use LOGPFOH()/DEBUGPFOH() in parse_attr_resp_info_unreported()Vadim Yanitskiy1-7/+10
Change-Id: Ib0c95c6c52122de06fa164f7a5fcb09ec7ad384a
2020-09-16add timer.vtyNeels Hofmeyr1-0/+95
Before transitioning some unspecified T timers to X timers, and to introduce timer groups, first add this timer VTY test. Changes here will illustrate that the legacy commands will still work and redirect to new timer definitions. Related: OS#4539 Change-Id: Ie1bc635e16dc9a4040d063e1d9a51cdc76d9d1f2
2020-09-16drop unused Tdef for 992427Neels Hofmeyr1-1/+0
Change-Id: I22a18662392545ba69f48e7fd8474c7c06d529cb
2020-09-16drop bsc_subscr.lacNeels Hofmeyr3-5/+3
It does not make sense to set the bsc_subscr's LAC from a Paging Request, especially since the paging code has loops that possibly kick off several pagings. At this point, there remains no code setting bsub->lac anywhere. We could set it during rx of Complete Layer 3, but since there is no use for it besides a vty dump, let's just drop the bsub->lac completely, and the vty dump of it. Change-Id: Id017bd494d329b6fc254d7135b4074ac2b224d66
2020-09-16dissolve bsc_grace_paging_request()Neels Hofmeyr3-45/+6
RF-locking: simply ask bsc_grace_allow_new_connection() at the start of page_subscriber(). Before this patch, we would log an INFO of "Paging request failed" when RF-locked, for each BTS. Instead log "RF-locked". (An upcoming patch will introduce a LOG_PAGING() macro that will trivially add more log context there, so not bothering now.) Drop LAC condition: since Stefan introduced page_subscriber() starting 2018 Ic3c62ff0fccea586794ea4b3c275a0685cc9326e, matching a requested LAC to a specific BTS is done *before* calling page_subscriber(). BTW: the msc->core_lac (config 'core-location-area-code') has not had an effect on Paging maybe ever. I opened OS#4751. Change-Id: Ic8696414a1db8f4b1be502d6434599f684746ed6
2020-09-15abis_nm: use DEBUGPFOH() in abis_nm_rx_sw_act_req()Vadim Yanitskiy1-1/+1
Change-Id: Ib148a451edee88350f09895a85a9d1bc03f3ac00
2020-09-15abis_nm: use btstype2str() in abis_nm_rcvmsg_manuf()Vadim Yanitskiy1-1/+1
Change-Id: I6858480fb8343a4862601ef48ff1778c4e4b0275
2020-09-15abis_nm: abis_nm_get_ts(): use LOGPFOH() instead of generic LOGP()Vadim Yanitskiy1-4/+2
Change-Id: I510506a5b2c9493d3473dd2b0fcb16a90aeb8c21
2020-09-15abis_nm: LOGPFOH()/DEBUGPFOH(): remove redundant context infoVadim Yanitskiy1-22/+17
Change-Id: I3531a0da3c64aea8bf4df5ffa1d8768f7e70c87b
2020-09-15abis_nm: fix msgb memleak in _abis_nm_sendmsg()Vadim Yanitskiy1-0/+1
Change-Id: I8e9c5d32e9bc43c760cb71efb8cab4982a305f0e
2020-09-15abis_nm: fix erroneous use of LOGPC() instead of LOGP()Vadim Yanitskiy1-3/+3
Change-Id: I8b6f791e423d1f7fcdabcaaaab48fc9586c1dc7b
2020-09-15gsm 04.08: correct calculate the Cell Selection Indicator after release of ↵Alexander Couzens1-4/+4
all TCH and SDCCH When the measurement bandwidth was added the calculation of the maximum length wasn't increased. Fixes: 27a887f666ad ("gsm 04.08: encode the LTE neighbors measurement bandwindth in Channel Release") Change-Id: Ic8132fd988140c34b8e0fd8349f4518fcbaecc31
2020-09-14bsc_vty: improve manual activation of lchans (debug / labtest)Philipp Maier1-41/+215
The VTY already has a method available to activate lchans manually, however, this method does not support proper activation of signalling channels. Also additional commands to activate multiple lchans at once are helpful to make labtesting simpler and more efficient. Change-Id: I66b874736c8c456eb82ccc26d5209987d8ed706c Related: SYS#4910
2020-09-11vty: clarify NM state owner printed by 'show trx N' commandVadim Yanitskiy1-1/+1
Change-Id: Ib17d1e98cfa1f293cf76cd9614722b6dec538960
2020-09-11abis_rsl: fix memleak in rach dos reduction functionPhilipp Maier1-1/+4
The function reduce_rach_dos() only removes the tossed channel requests from the list, but does not free them. Change-Id: I0a62fc897c07e118dd637b156b6f2822c44db731 Related: OS#4549
2020-09-11abis_rsl: inform user when expired channel requests get tossedPhilipp Maier1-2/+6
At the moment expired channel requests are dropped silently, however, it might help to know when this happens - not only for debugging. Change-Id: Ib49df551a4cd7d5652e85c8ce29ef132385d4ae4 Related: OS#4549
2020-09-11abis_rsl.c: flush channel request queue on RSL bootstrapPhilipp Maier3-0/+16
When RSL link is bootstrapped the BSC should clear the channel request queue. Change-Id: Iefb333817033e8d376184b58d89b186d875b968f Related: OS#4549
2020-09-10gsm 04.08: encode the LTE neighbors measurement bandwindth in Channel ReleaseAlexander Couzens1-2/+8
Encoding missing measurement bandwidth of LTE neighbors in Channel Release (Cell selection indicator after release of all TCH and SDCCH value part). The measurement bandwidth was encoded in the neighbors description transmitted in SI2quater while missing in the Channel Release which would overwrite the SI2quater measurement bandwidth. Change-Id: I4847d840ba9d5ac56bd00e4f405dc47792008c0d
2020-09-10gsm_data: always set spare bits in channel descriptionAlexander Couzens1-0/+1
The spare bits were never encoded even when the spec says it must be 00. Most caller of _chan_desc_fill_tail() initialized the struct with memset(), but not all. The SI4 did not initialize it. Change-Id: Ib03d6d2cdadc49e49aa94917d17f81ef3c83f11c
2020-09-09abis_om2000: check result of gsm_bts_trx_set_system_infos()Vadim Yanitskiy1-4/+19
Ensure that osmo-bsc would not continue to work as usual, if for some reason we cannot encode or send System Information messages. Introduce transitional state OM2K_TRX_S_SEND_SI, from where we can generate and send System Information messages. Otherwise it's confusing if we fail to do something when we're already in state OM2K_TRX_S_DONE. Change-Id: Ia6df539d0914c57ea80fdb29882832678b47f267
2020-09-09lchan_rtp_fsm: Deferr IPACC MDCX after BTS side MGCP MDCXPau Espin Pedrol3-35/+36
This is needed to be able to force MGW to provide an IPv4 address during MDCX, since IPACC protocol on the BTS side only supports IPv4, but one may need IPv6 side at the same time on the core side. By moving the IPACC MDCX request to a later step, the BSC gains knowledge of the local address on each side (BTS, MGW), and if they don't match (ie. BTS uses IPv4 and MGW uses IPv6), it can then get MGW to offer an IPv4 address during MGCP MDCX containing the BTS IPv4 address. At that point, the MGW can see the mismatch and provide an IPv4 address in the MGCP MDCX ACK, which can then finally be communicated to the BTS during IPACC MDCX phase. Previous order: BSC -> MGW: CRCX BSC <- MGW: CRCX ACK (get MGW local IP addr) BSC -> BTS: IPACC CRCX BSC <- BTS: IPACC CRCX ACK (get BTS local IP addr) BSC -> BTS: IPACC MDCX (set MGW IP addr) BSC <- BTS: IPACC MDCX ACK BSC -> MGW: MDCX (set BTS IP addr) BSC <- MGW: MDCX ACK New order: BSC -> MGW: CRCX BSC <- MGW: CRCX ACK (get MGCP local IPv6 addr) BSC -> BTS: IPACC CRCX BSC <- BTS: IPACC CRCX ACK (get BTS local IPv4 addr) BSC -> MGW: MDCX (set BTS IPv4 addr) BSC <- MGW: MDCX ACK (here MGW changes its local addr to IPv4) BSC -> BTS: IPACC MDCX (set MGW IPv4 addr) BSC <- BTS: IPACC MDCX ACK Change-Id: I4de5ea5c94c1482c9cb0b6386997a942edc60e32
2020-09-08fix bootstrap_rsl(): check result of gsm_bts_trx_set_system_infos()Vadim Yanitskiy1-1/+4
Ensure that osmo-bsc would not continue to work as usual, if for some reason we cannot encode or send System Information messages. Change-Id: I7d3458fb10760e33411f2074a6b2df1c257438d5
2020-09-08vty: propagate result of gsm_bts_set_system_infos()Vadim Yanitskiy1-2/+10
We should not return CMD_SUCCESS if this functions fails. Change-Id: Id8a761593fe89cc07c2fb6e69558f44494537c47
2020-09-08SI Type 4: prevent potential buffer overflowVadim Yanitskiy1-0/+3
Make sure that in generate_si4() we do not corrupt other SI buffers by limiting maximum length of the Mobile Allocation to 2 octets. This would preserve at least 2 octets for the Rest Octets, what should be enough to encode at least GPRS Indicator. Change-Id: I2e3553865096faecda6bb22fc25b83fd47b738c4 Related: SYS#4868, OS#4545
2020-09-07Fix creating MGCP proxy socket if MGW listens on an IPv6 addressPau Espin Pedrol1-2/+2
If for instance "mgw remote-ip ::1" is configured, the MGCP IPA proxy socket towards the MGW will use ::1 as the destination address, but it was being created as AF_INET. Let's use AF_UNSPEC instead and let osmo_sock_init2 decide the best socket type to create. Moreover, change the default local address from "0.0.0.0" to NULL to also let osmo_sock_init2 pick an IPv6 address if necessary. Change-Id: Ide88c7358a38702ef11c84145518794e75870ef8
2020-09-07abis_rsl: prioritize emergency calls over regular callsPhilipp Maier8-50/+284
when an emergency call arrives while all TCH are busy, the BSC should pick an arbitrary (preferably the longest lasting) call / lchan and release it in favor of the incoming emergancy call. The release of the existing call is a process that can not be done synchronously while the ChanRQD is handled sonce multiple messages are exchanged between BTS and MSC and multiple FSMs need to do their work. To be able to release one lchan while handling a ChanRQD a queue is implemented in which the incomming channel requests are collected. If an emergency call is established while all channels are busy, an arbitrary lchan is picked and freed. When freeing the lchan is done, the queue is checked again and the emergency call is put on the free lchan (TCH/H or TCH/F). Change-Id: If8651265928797dbda9f528b544931dcfa4a0b36 Related: OS#4549
2020-09-06generate_ma_for_ts(): fix: properly encode ARFCN 0 (corner case)Vadim Yanitskiy1-2/+1
According to 3GPP TS 44.018, table 10.5.2.21.1 "Mobile Allocation information element", in the cell allocation frequency list the absolute RF channel numbers are placed in increasing order, except that ARFCN 0, if included in the set, is put in the last position. This basically means that the last bit of the Mobile Allocation (MSB on the wire) corresponds to ARFCN 0, if it's included in the cell allocation frequency list, or the last channel otherwise. Recently introduced TTCN-3 test cases uncover the following problems: a) ARFCN 0 is encoded twice: as MSB and LSB of the bit-mask, b) ARFCN 0 is encoded one bit off its expected location. Change-Id: I264a66a1405e72940a79e9e20ad6ad8f269a7bbc Related: SYS#4868, OS#4545
2020-09-06generate_ma_for_ts(): use OSMO_BYTES_FOR_BITS() macroVadim Yanitskiy1-3/+1
Change-Id: I119f930e9cb5d6e52d4b0e1160604c709d942a18
2020-09-03lchan_fsm: make rsl mode-modify working againPhilipp Maier10-47/+252
osmo-nitb supports the modification of an lchan if the lchan is compatible but in the wrong mode. This feature was dropped in the transition to AoIP/bsc-split. However, osmo-bsc still has code to generate and parse the messeages, but the FSMs do not support a mode modify yetm Lets add handling for mode-modify to the lchan_fsm and assignment_fsm in order to support mode modify again Change-Id: I2c5a283b1ee33745cc1fcfcc09a0f9382224e2eb Related: OS#4549
2020-09-03CBSP VTY: re-add legacy cbc config for backwards compatNeels Hofmeyr2-0/+157
In commit [1], I replaced the way the CBSP link is configured in the VTY. But that configuration was already part of a release, hence I should only have deprecated the old commands. Re-add the legacy config as deprecated. Try to make the legacy commands take a similar effect as they previously would be intended for, i.e. switching to server/client/disabled modes, and take effect immediately when commands are read from telnet. [1] 641f7f08450f2d0c4b8e8a9f6a36b0a6b2788816 Icaa2775cc20a99227dabe38a775ff808b374cf98 "CBSP: rewrite the CBSP link setup and 'cbc' VTY section" Related: OS#4702 Change-Id: If6b742f28191b3f19ff1d87a217037a305133f4b
2020-09-03CBSP: adjust manual to reflect new 'cbc' VTY configNeels Hofmeyr1-20/+42
Related: OS#4702 Change-Id: I101144dc4ebf151fa23d05743398aeea4a26834b
2020-09-03SI Type 4: fix missing CBCH Mobile Allocation IEVadim Yanitskiy1-7/+16
According to 3GPP TS 44.018, section 9.1.36.2, the CBCH Mobile Allocation IE shall be present if CBCH Channel Description IE indicates frequency hopping. For some reason it was missing. This change makes BSC_Tests.TC_fh_params_si4_cbch pass. Change-Id: I8dce506a07d9d291b631b44fa2177c9deff6aa88 Related: SYS#4868, OS#4545
2020-09-03gsm_04_08_rr: fix hopping parameters in RR Handover CommandVadim Yanitskiy1-9/+10
A similar problem has already been fixed in [1]: - include GSM48_IE_MA_AFTER instead of GSM48_IE_MA_BEFORE, - fix position of the Mobile Allocation (after time) IE. This problem was uncovered by (not yet merged) TTCN-3 test case verifying handling of the hopping parameters [2]. This change makes it pass. [1] I43ef66c109b107ebcaa1cb6197637701b13b3787 [2] BSC_Tests.TC_fh_params_handover_cmd Change-Id: I7569eead9760b6fd4bb91fc2d8d0b8200bebe374 Related: SYS#4868, OS#4545
2020-09-03vty: add a command to clear hopping ARFCN listVadim Yanitskiy1-0/+14
Change-Id: I05b0adc407a2808e5fdfac1cf9cd4dba67daa0f0 Related: SYS#4868, OS#4545
2020-09-03drop some unused members and function declsNeels Hofmeyr2-9/+0
Change-Id: I0de2c8a3ee6c693a5a321f0ea2a8a75fbe64a1c2
2020-09-02Fail on invalid IP addresses passed to IPACC MDCXPau Espin Pedrol1-2/+8
IPACC protocol supports only IPv4 addresses, so make sure if an IPv6 address (or whatever malformed address) is caught is not sent without noticing. Prior to this patch, faulty addresses would be sent over the wire as 255.255.255.255 (-1 returned from inet_addr()). Change-Id: Iee84e8b40cdede1cacd8e8a9e26dda0d85383ec8
2020-09-01vty: Hide show running-config ACC ramping params if not enabledPau Espin Pedrol1-6/+8
If the feature is not enabled there's no real use in displaying default values for it. Related: SYS#4912 Change-Id: I759eb0c31dd3c9b6f5f3d2bf57c6efc9ac5f74f1
2020-08-31CBSP: fix link startup when enabled in config fileNeels Hofmeyr1-1/+6
Restart the CBSP link from the VTY only from telnet sessions, not when reading in the config file. When reading the config file, link startup might happen too early and twice -- rather rely only on the CBSP startup invoked from main(). This is fixing a bug introduced recently in "CBSP: rewrite the CBSP link setup and 'cbc' VTY section" commit 641f7f08450f2d0c4b8e8a9f6a36b0a6b2788816 Change-Id Icaa2775cc20a99227dabe38a775ff808b374cf98 Change-Id: Ia0bb507c8468048789a446df09185ad8565c5ad8
2020-08-31handover: fix detection for ambiguous HO neighbor identNeels Hofmeyr1-19/+21
Adding rate counter checks to TC_ho_neighbor_config_1 (1.c) uncovers that the test passes for the wrong reason. The ambiguous cell identification should be the cause for the handover error, but the log shows that instead a handover is attempted to BTS 3 which is not connected. find_handover_target_cell() first tries to find a precise match of values, and in a second pass applies wildcards like BSIC_ANY and NEIGHBOR_IDENT_KEY_ANY_BTS. That second pass lacks detection of ambiguous matches. Use the same code for both passes, by encapsulating in a loop of two, which first runs with exact_match == true and then false. Proper detection of the ambiguous target cell identification in TC_ho_neighbor_config_1() is shown by the resulting 'handover:error' count, see I10bc0b67ca8dcf41dbb02332ed18017e819c2b32 (osmo-ttcn3-hacks). Related: OS#4736 Related: I10bc0b67ca8dcf41dbb02332ed18017e819c2b32 (osmo-ttcn3-hacks) Change-Id: Ib0087b6566ae4d82f8c3ef272c1256bcd1d08bf1
2020-08-31handover_fsm: signal Clear from gscon, for proper HO result countsNeels Hofmeyr2-0/+7
An inter-BSC-OUT handover ends with a Clear Command, which HO_OUT_ST_WAIT_CLEAR waits for. Actually tell the handover_fsm.c about an incoming Clear Command, so that the inter-BSC-OUT success can be counted. Similarly, count failing handover results for an unexpected Clear Command from the MSC. Related: OS#4736 Change-Id: I0c489838a99f930e2104619ca745191d2a736f1b
2020-08-31bssap: do not send a Clear Request after a Clear CommandNeels Hofmeyr2-0/+9
During handover cleanup due to a Clear Command from the MSC, do not send another Clear Request to the MSC. Only send that when no Clear Command was received yet. Add a flag rx_clear_command per gscon instance, indicating whether a Clear Command was received, and exit early in gscon_bssmap_clear() when true. This is part of patches fixing the rate counters around handover, which uncover some bugs: - Another patch enables proper handover result handling when receiving a Clear Command. - After that, the handover_end() handling would always cause sending a Clear Request, even if a Clear Command was already received. - This patch removes the extraneous Clear Request, for this scenario and for all other corner cases that might still exist. Related: OS#4736 Change-Id: Iab82cac0a7ffa7d36338c8ff7c0618a813025f13
2020-08-31add {BTS,BSC}_CTR_INTER_BSC_HO_OUT_FAILED for RR HO FailureNeels Hofmeyr3-0/+8
So far, during inter-BSC outgoing handover, when receiving an RR Handover Failure from the MS, it would be counted as 'error'. Instead, add the 'failed' counter like for all other HO types. It may make sense to omit the 'failed' counter for inter-BSC *incoming* handover, because then we won't receive an RR Handover Failure message. I probably got those two mixed up during initial development. Related: OS#4736 Change-Id: I9a61d5cc7273a830ba4e66e43e4aac6cdb707471
2020-08-31fix HO inter-BSC-IN target bts for countersNeels Hofmeyr1-0/+5
Related: OS#4736 Change-Id: Id38c69695c4ab93733571c0c288a2d5c10624ace
2020-08-31fix 'handover:*' counters: remove bogus incrementsNeels Hofmeyr1-10/+8
To handle cases of unknown handover type (like failure to find the target cell), return -1 as counter code; treat -1 as skipping in ho_count_bsc() and ho_count_bts(). The handover:* counters indicate overall counts, without knowing whether inter- or intra-BSC, or whether the target ARFCN even exists. So they need to be counted separately, and must not serve as fallback category in result_counter_bsc() and result_counter_bts(). Related: OS#4736 Change-Id: Ie311e599d7bd35d33cf471c6c63e649246e8396a
2020-08-30fix 'handover:*' counters: add missing / move incrementsNeels Hofmeyr2-7/+4
Move initial 'handover:attempted' counts from bsc_subscr_conn_fsm.c to handover_fsm.c, where all the other counters are handled. Add missing increments for the overall 'handover:*' counts. Related: OS#4736 Change-Id: I783bdedafc0eb8f2df9ea100792846fecc7ccbf7
2020-08-30ho counters: count invalid target cell as 'error', not 'no_channel'Neels Hofmeyr1-1/+1
Related: OS#4736 Change-Id: If6d6b7262536831ebb2b638efe521dd5a8153cdb
2020-08-30cosmetic: dissolve error-goto with single source in handover_start()Neels Hofmeyr1-5/+4
Change-Id: I9c7d10c36f3f868100c1aa2d0433ceed74161175
generated by cgit v1.2.1 (git 2.18.0) at 2021-02-26 10:55:58 +0000