aboutsummaryrefslogtreecommitdiffstats
path: root/include/osmocom
AgeCommit message (Collapse)AuthorFilesLines
2020-10-08vty: add attributes to VTY commands indicating when they applyVadim Yanitskiy1-0/+7
Change-Id: I3bf9223295fc4a2fcb4046a1f29f792ff6a41d51 Related: SYS#4937, OS#1601
2020-10-07LCS: implement re-use of existing A-interface connNeels Hofmeyr1-0/+1
Location Services brings a new scenario to OsmoBSC: the MSC may create an A-interface conn for a subscriber without an lchan being established (N-CONNECT from MSC to BSC, so far only for an incoming inter-BSC handover). If an MS becomes active while an A-interface conn is already established, associate with an existing conn. Change-Id: I42290f519a419ed7e8dd02a5ed0a5261b30a51e6
2020-10-07cosmetic: fix naming of GSCON_EV_A_CONN_REQ -> GSCON_EV_MO_COMPL_L3Neels Hofmeyr1-1/+1
The N-CONNECT.req on the A interface is a possible *consequence* of the event being handled, namely the incoming RSL ESTablish INDication containing the Complete Layer 3 message: dispatched by bsc_compl_l3(). If an (LCS related) connection is already present on the A-interface when the lchan is established, there will be no N-CONNECT but an N-DATA sending the Complete Layer 3. See BSC_Tests.TC_cm_service_during_lcs_loc_req(). Change-Id: Ic43aabeb0d3c58ac62249ad9d3718363d32508f9
2020-10-07introduce osmo_use_count for bsc_subscrNeels Hofmeyr3-13/+23
During LCS development, I'm getting use count bugs and would like to see use token strings to figure it out. Change-Id: I29bf60059d4cf7bb99a00753e6cdc149baf95f94
2020-10-07LCS: add paging reason, return in paging_request_stop()Neels Hofmeyr1-2/+15
To distinguish between the CN requiring a Complete Layer 3 response, or just the BSC requiring a TA, allow recording a separate for-LCS paging reason. Change-Id: Ib28d1599ae4e483727398859d07de4490fbc31f0
2020-10-07refactor paging: add bsc_subscr to bsc_paging_paramsNeels Hofmeyr1-4/+4
Get a bsub once at start of paging. Change-Id: I13621cd51d934846ff6556e1f2f8839da73a5dbb
2020-10-07refactor paging: introduce bsc_paging_start()Neels Hofmeyr1-0/+1
Allow starting a paging from elsewhere than a BSSMAP Paging Request. For upcoming Location Services (LCS), a BSSLAP TA Request from the SMLC may require triggering a Paging. Change-Id: Iaff91584699d163bd1963927280ff3a8ddd43073
2020-10-07refactor paging: introduce bsc_paging_paramsNeels Hofmeyr1-2/+20
For LCS, I would like to add an enum indicating the paging reason. Instead of modifying extremely many function signatures to pass the reason across all levels of paging, introduce a struct combining these. Change-Id: I27ca78fc6ff8ef1101554c0a8429e34945ca6f3c
2020-10-07compl l3: move Paging Response handling out of bsc_find_msc()Neels Hofmeyr1-7/+1
Instead of iterating the llist of gsm_paging_requests first to find an MSC, and then again right away to mark the paging as served, do both in the same step. Change-Id: I447e61afc9934f3a5a82f6076e41c155d3328041
2020-10-07compl l3: allocate conn in gsm_08_08.c, not gsm_04_08_rr.cNeels Hofmeyr1-1/+1
Move conn allocation to bsc_compl_l3(), from gsm0408_rcvmsg(). Drop dispatch of GSCON_EV_A_DISC_IND, because a) we did not receive such DISC.IND, and b) the lchan release will discard the conn in the regular fashion. In upcoming LCS patch, bsc_compl_l3() will decide whether to allocate a new conn or whether a conn from a Perform Location Request already exists for the subscriber. In this patch, it becomes clear that the conn->bsub is always NULL in bsc_compl_l3(), and that the 'log_set_context(LOG_CTX_BSC_SUBSCR, conn->bsub);' never has the intended effect. An upcoming patch will change that. Change-Id: I92af0f0d54c4282d782f2b29d524a64006c3b674
2020-10-05pcuif_proto: version 10: add support for IPv6 NSVCsAlexander Couzens1-1/+11
Introduce a address_type in the NSVC configuration pass the given protocol. The remote_ip is network byte order, the default encoding for in_addr and in6_addr. Related: Iae854875a45dbc29cd46a267ccaf60f1f2ac2973 Related: SYS#4915 Change-Id: I740be0a401612bb5ed4e8ccd7f4be8176b936449
2020-10-05pcuif_proto: version 10: add frequency hopping parametersAlexander Couzens1-3/+12
Related: SYS#4868, OS#4546, OS#4547 Change-Id: I5540fae66a116cbb25ec75b35145c36137146ffd
2020-10-05oml: encode IPv6 NSVC using the new OML attribute NM_ATT_OSMO_NS_LINK_CFGAlexander Couzens1-3/+2
The old IE NM_ATT_IPACC_NS_LINK_CFG didn't support IPv6 NSVC. Depends: Ic261bc43a07fa741b97a9c6ec5a9ed6f5ecae588 (libosmocore) Depends: I9e279bb20940c66eea5196f281184cb4f8a5cc5f (libosmocore) Change-Id: I6529876a3c1116a79dd624312243d8ae48a41fe2
2020-10-03pcuif_proto: protocol 9: add missing fieldsAlexander Couzens1-0/+22
The protocol 9 was extended (compatible) with * app info request * suspend request (ETWS) * rach indition (add fields ts / trx) Only copy the relevant parts but no implementation. Related: OS#4766, OS#4767, OS#4768 Change-Id: Ia81310326b093a8e473b6c69045304667b3b60f1
2020-10-03remove unused signature gsm48_handle_paging_resp()Neels Hofmeyr1-2/+0
Change-Id: Ib221e34afe08d87e43ac7ddc73d6894bbe36dc4b
2020-09-20oml: Fix premature Opstart to Radio CarrierPau Espin Pedrol1-0/+1
During the A-bis/OML bootstrapping, osmo-bsc sends Opstart to the Radio Carrier MO twice. The first Opstart is triggered by the State Changed Event Report, originated by the Radio Carrier itself. The second is triggered by Software Activated Report. According to 3GPP TS 12.21, figure 2, we shall send it only once, after the "Attribute setting" step. Therefore, the first Opstart is premature, and we shall not send it. Related: SYS#5063, OS#4755 Change-Id: If69393551117266ecb726d8961153560b2b3cc59
2020-09-18clean up timer definitions: introduce groups, move some T to XNeels Hofmeyr1-0/+2
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-16drop bsc_subscr.lacNeels Hofmeyr1-1/+0
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 Hofmeyr1-5/+0
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-11abis_rsl.c: flush channel request queue on RSL bootstrapPhilipp Maier1-0/+1
When RSL link is bootstrapped the BSC should clear the channel request queue. Change-Id: Iefb333817033e8d376184b58d89b186d875b968f Related: OS#4549
2020-09-07abis_rsl: prioritize emergency calls over regular callsPhilipp Maier4-0/+6
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-03lchan_fsm: make rsl mode-modify working againPhilipp Maier2-4/+11
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-03drop some unused members and function declsNeels Hofmeyr2-9/+0
Change-Id: I0de2c8a3ee6c693a5a321f0ea2a8a75fbe64a1c2
2020-08-31bssap: do not send a Clear Request after a Clear CommandNeels Hofmeyr1-0/+2
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 Hofmeyr2-0/+4
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-29CBSP: add local bind to client modeNeels Hofmeyr1-0/+1
Add the ability to set a local bind address for the CBSP client mode. Change-Id: I56a420d204a9a487b27dd460f4cc52e0b4093d69
2020-08-29CBSP: rewrite the CBSP link setup and 'cbc' VTY sectionNeels Hofmeyr2-10/+18
Firstly, make CBSP server and client mutually exclusive: Do not allow osmo-bsc to be configured as CBC client *and* CBC server at the same time. cbsp_link.c expects at most one CBSP link to be established, and, upon sending CBSP messages, probes whether to send the message to a CBSP server or client link. When both listen-port and remote-ip are configured (regardless of an actual CBSP connection), osmo-bsc gets confused about where to send CBSP messages. One solution would be more accurate probing for an actual established TCP connection. But the simpler and less confusing solution is to force the user to configure only server or only client mode, never both. Introduce 'cbc' / 'mode (server|client|disabled)'. Secondly, clarify the 'cbc' config structure into distinct 'server' and 'client' subnodes. Refactor the 'cbc' VTY node in such a way that the IP addresses for server and client mode can remain configured when the CBSP link is switched between server/client/disabled modes. To implement the above, switch the struct bsc_cbc_link to use osmo_sockaddr_str for address configuration. Related: OS#4702 Related: I7eea0dd39de50ed80af79e0f10c836b8685d8644 (osmo-ttcn3-hacks) Related: I9e9760121265b3661f1c179610e975cf7a0873f1 (docker-playground) Change-Id: Icaa2775cc20a99227dabe38a775ff808b374cf98
2020-08-28Allow storing IPv6 address strings in BSSAP structsPau Espin Pedrol1-3/+3
Related: SYS#4915 Change-Id: I95601f24e3c658aab328e1c55dc514f553c297b8
2020-08-26bsc_subscr_conn_fsm: use proper cause values in SAPI N REJECTVadim Yanitskiy1-1/+1
As 3GPP TS 48.058 clearly states, an RLL RELease INDication is only sent if the datalink is released by the MS. Thre's no cause value giving further diagnostics, but if the MS releases the link, it is clearly not the BSS's fault, and hence "BSS not equipped" is wrong. Change-Id: I38222e60071841abcd06046a472ddb35907164a4 Related: OS#4728
2020-08-26fix bsc_sapi_n_reject(): dlci is unsigned, use uint8_tVadim Yanitskiy1-1/+1
Change-Id: I5f04f16caecb58a28e119512267999fdc18ff172
2020-08-24Add bts counters to count BTS events where we don't have a btsDaniel Willmann1-0/+10
In some (error-) cases we might be unable to determine which BTS to use when counting handover events. We don't want to loose these events because then ctr(bsc) == sum(ctr(bsc->bts)) would not be true anymore. Those events are now counted by a counter in struct gsm_network which uses an index that is out of range for regular BTS (65536). Change-Id: Ic0f3edd5dc014c4eac5e8423133633a3e5d4c13e Related: SYS#4877
2020-08-24Count intra-cell and intra-bsc handover separatelyDaniel Willmann2-0/+116
Currently the counters don't distinguish between intra-cell and intra-bsc handover. Add _CTR_INTRA_CELL_HO_ and _CTR_INTRA_BSC_HO_ counters to track intra-cell/bsc handover separately. Change-Id: I3a1195640b99813036c9f1426ee5f07548e26547 Related: SYS#4877
2020-08-24Count handover per BTS as well as per BSCDaniel Willmann1-0/+47
Our current handover counters only count success/failures per BSC. It would be nice to also count which BTS is part of a (successful/failed) handover. This patch duplicates the BSC counters for the BTS and changes the ho_count and related macros to also count per BTS. If a BTS is NULL (when conn->lchan is NULL) counting for the BTS is ignored. Change-Id: I025ef14e2cfd2eea8880212c9406372ce0bf9296 Related: SYS#4877
2020-08-20Remove punctuation in counter descriptionDaniel Willmann1-35/+35
Change-Id: I304dcc9e88afc5e607d5b010df3e95f40fb8c49b
2020-08-17Implement support for receiving BSSMAP CommonID from MSCHarald Welte2-0/+3
The MSC may at any time send a BSSMAP CommonID message via a SCCP connection to inform us of the IMSI of the subscriber. Let's make use of that information by associating a related bsc_subscr and updating the identity of the bsc_subscr_conn_fsm for improved logging / filtering. Closes: OS#2969 Change-Id: I52c43fb940f0db796adf4c0adb2260321c721c39
2020-08-06lchan_rtp_fsm: use E1 endpoints if the BTS is not ipaccess typePhilipp Maier1-1/+1
When the BTS is is not an ipaccess BTS, the BTS can only be an E1 bts. In that case E1 endpoints must be used and there will be no RTP stream setup towards the BTS. Change-Id: I4f1f39bf90b0a7c9ea448dab255daf99cd36bb4a Related: OS#2547
2020-07-31Introduce support for ACC ramping during whole BTS life cyclePau Espin Pedrol1-6/+18
Prior to this patch, ACC ramping was only used to go 0->N in the number of allowed ACCs during BTS startup. It could optionally dynamically stretch or extend the ramping time based on channel load. With this patch, ACC ramping is kept alive during the entire time the BTS is active, and subset of allowed ACCs can now be incresed or decreased based on channel load. A new VTY command "access-control-class-ramping-chan-load" is added to configure a lower and an upper threshold. Channel load under the low threshold will potentially trigger an increment of the subset size of allowed ACCs, while a channel load over the upper threshold will potentially trigger the opposite (a decrease in size). The time between checks is kept fixed per VTY command (reusing old "access-control-class-ramping-step-size"), but the "dynamic" option is deprecated and ignored from now on since it provides nothing valuable in the new implementation, because the size always dynamically changes based on channel load (configured thresholds). Related: SYS#4912 Change-Id: Id17f947c92cdfc0eb9541a9bf066338169caaeb5
2020-07-29Introduce support for ACC subset rotationPau Espin Pedrol2-38/+35
See updated documentation section in manuals/chapters/bts.adoc regarding an explanation on how the system works. Related: SYS#4911 Change-Id: I952c9eeae02809c7184078c655574ec817902e06
2020-07-20rename files acc_ramp.* -> acc.c*Pau Espin Pedrol3-2/+2
With upcoming next commit, the file will contain far more code that simply ramping, so rename it to be more generic. Change-Id: I8c368ab87e264439dea4ccf556821a44664cdbb0
2020-07-18Move gsm_bts_{trx_}set_system_infos APIs to bts{_trx}.*Pau Espin Pedrol3-3/+4
Change-Id: I2aa83b499d6e5d06a0fa1001fee3111f7e639c94
2020-07-18Move struct gsm_bts_trx: gsm-data.* => bts_trx.*Pau Espin Pedrol4-74/+95
See rant fro similar recent commit moving stuff to bts.*. Change-Id: I11758ca3d255d849d77bd068f24bb68bde1f89a5
2020-07-18bts: Drop duplicated function to get trx by numberPau Espin Pedrol2-2/+1
In the big mess of gsm_data we reached a point where we have multiple functions doing the same thing, most probably because it's hard finding stuff in there. Let's drop one of them (the one which less callers) and move it to bts.*, where it belongs. Change-Id: I9071a0ab250844619280fbe2be63ed99f2c87eb1
2020-07-18Move struct gsm_bts: gsm_data.* => bts.*Pau Espin Pedrol3-626/+641
Place all code related to the object into the related file. Having all the data model in one file made sense in early stage of development to make progress quickly, but nowadays it hurts more than helps, due to constantly growing size and more and more bits being added to the model, gaining in complexity. Currently, having lots of different objects mixed up in gsm_data.h is a hole of despair, where nobody can make any sense were to properly put new stuff in, ending up with functions related to same object in different files or with wrong prefixes, declarations of non-existing functions, etc. because people cannot make up their mind on strict relation to objects in the data model. Splitting them in files really helps finding code operating on a specific object and helping with logically splitting in the future. Change-Id: I00c15f5285b5c1a0109279b7ab192d5467a04ece
2020-07-16propagate RSL error cause codes to RR Channel Release causeNeels Hofmeyr1-0/+1
In various places that receive an error cause from RSL and place it in lchan.release.rsl_error_cause, translate it to an RR cause and place that in the recently added lchan.release.rr_cause. Hence the RR Channel Release message now reflects more specific error causes when the reason for the error was received in an RSL message's cause value. Change-Id: I46eb12c91a8c08162b43dd22c7ba825ef3bbc6ac
2020-07-16RR Channel Release: pass Cause code from BSSMAP Clear to the BTSNeels Hofmeyr2-1/+11
In lchan.release, add 'cause_rr', and set RR Channel Release message's cause value to lchan.release.cause_rr. In lchan_release(), do not set lchan.release.rsl_error_cause to the RR cause value, these are unrelated. Store in new lchan.release.cause_rr instead. The rsl_error_cause is apparently only used for logging, except for one place in lchan_fsm_wait_activ_ack() that compares it to RSL_ERR_RCH_ALR_ACTV_ALLOC, so there should not be a functional difference by this fix. Propagate the BSSMAP Clear Command cause to the RR Channel Release: Add struct gscon_clear_cmd_data as event data for GSCON_EV_A_CLEAR_CMD -- so far it sent the is_csfb flag, add the gsm0808_cause; invoking the event happens in bssmap_handle_clear_cmd(). Adjust event handling in gscon_fsm_allstate(); there, pass the cause to gscon_release_lchans(). In gscon_release_lchans(), pass the cause to gscon_release_lchan(), and then lchan_release(), which sets the new lchan.release.cause_rr to the passed cause value. As soon as the lchan FSM enters the proper state, it calls gsm48_send_rr_release(). There, set the cause value in the encoded message to lchan.release.cause_rr. Interworking with osmo-msc: so far, osmo-msc fails to set the Clear Command cause code for normal release, it just passes 0 which amounts to GSM0808_CAUSE_RADIO_INTERFACE_MESSAGE_FAILURE. Before this patch, osmo-bsc always sent GSM48_RR_CAUSE_NORMAL in the RR Channel Release, and after this patch it will receive 0 == GSM0808_CAUSE_RADIO_INTERFACE_MESSAGE_FAILURE from osmo-msc and more accurately translate that to GSM48_RR_CAUSE_PROT_ERROR_UNSPC. This means in practice that we will now see an error cause in RR Channel Release instead of GSM48_RR_CAUSE_NORMAL when working with osmo-msc. For changing osmo-msc to send GSM0808_CAUSE_CALL_CONTROL instead (which translates to GSM48_RR_CAUSE_NORMAL), see OS#4664 and change-id I1347ed72ae7d7ea73a557b866e764819c5ef8c42 (osmo-msc). A test for this is in Ie6c99f28b610a67f2d59ec00b3541940e882251b (osmo-ttcn3-hacks). Related: SYS#4872 Change-Id: I734cc55c501d61bbdadee81a223b26f9df57f959
2020-07-15Fix trailing whitespace in several filesPau Espin Pedrol1-2/+2
Change-Id: Ide9921dfce3b6d7c580edaa612a3063c94319a02
2020-07-15gsm_data.h: Drop duplicated include stdint.hPau Espin Pedrol1-1/+0
Change-Id: I7610cffc3a641975e05ba4ea9f469e12c99e407f
2020-07-08SI2quater: allow storing 48 EARFCNsNeels Hofmeyr1-1/+4
Up to 16 SI2quater are multiplexed; each fits 3 EARFCNS, so the practical maximum is 48 (of course depending on how many bits are used by other SI2quater elements). Change-Id: Iabeed10053ee5899b4def3509aedd25abb2410a9
2020-07-03system_information: publicly declare generate_cell_chan_list()Vadim Yanitskiy1-0/+1
Change-Id: Idc7a9ed558ed6897e15a0f6d3c23418db7cee0d0
2020-06-23fix crashes due to OSMO_ASSERT(conn->lchan)Vadim Yanitskiy1-1/+2
Starting from ttcn3-bsc-test-sccplite build #777, it was noticed that osmo-bsc crashes with the following message: Assert failed conn->lchan include/osmocom/bsc/gsm_data.h:1376 The cause of this is a recently merged patch that calls conn_get_bts() during assignment_fsm rate counter dispatch: "Count assignment rates per BTS as well" commit b5ccf09fc4042c7fb1fdaaa6263961c40b32564e Change-Id I0009e51d4caf68e762138d98e2e23d49acc3cc1a The root cause being that the assignment_fsm attempts to count an Assignment event for a BTS after the lchan has already been released and disassociated from the conn. The assertion is found in conn_get_bts(), which is used in various places. In fact, each caller is a potential DoS risk -- though most are in code paths that are guaranteed to have an lchan and bts present, having an OSMO_ASSERT() on the relatively volatile presence of an lchan is not a good idea for osmo-bsc's stability and error resilience. - Change conn_get_bts() to return NULL in the lack of an lchan. - Adjust all callers of conn_get_bts() to gracefully handle a NULL return val. - Same for cgi_for_msc() and callers, closely related. Here is a backtrace: Program received signal SIGABRT pwndbg> bt 0x0000555555be6e52 in conn_get_bts (conn=0x622000057160) at include/osmocom/bsc/gsm_data.h:1376 0x0000555555c1edc8 in assignment_fsm_timer_cb (fi=0x612000060220) at assignment_fsm.c:758 0x00007ffff72b1104 in fsm_tmr_cb (data=0x612000060220) at libosmocore/src/fsm.c:325 0x00007ffff72ab062 in osmo_timers_update () at libosmocore/src/timer.c:257 0x00007ffff72ab5d2 in _osmo_select_main (polling=0) at libosmocore/src/select.c:260 0x00007ffff72abd2f in osmo_select_main_ctx (polling=<optimized out>) at libosmocore/src/select.c:291 0x0000555555e1b81b in main (argc=3, argv=0x7fffffffe1b8) at osmo_bsc_main.c:953 0x00007ffff6752002 in __libc_start_main () from /usr/lib/libc.so.6 0x0000555555b61bbe in _start () In the case of the assignment_fsm counter, we now miss a chance to increase a BTS counter for a failed Assignment, but this is a separate problem. The main point of this patch is that osmo-bsc must not crash. Related: OS#4620, OS#4619 Patch-by: fixeria Tweaked-by: neels Fixes: I0009e51d4caf68e762138d98e2e23d49acc3cc1a Change-Id: Id681dfb0ad654bdb4b71805d1ad4f39a8bf6bbd1
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-21 03:41:06 +0000