aboutsummaryrefslogtreecommitdiffstats
path: root/src/osmo-bsc/bsc_subscr_conn_fsm.c
AgeCommit message (Collapse)AuthorFilesLines
2022-03-04tweak error msg: s/inter-BSC MT/inter-BSC incomingNeels Hofmeyr1-2/+2
"inter-BSC MT" was the terminology of an early development stage of inter-BSC handover, code review requested "incoming" instead. This one was missed when applying code review. Same in a code comment. Related: SYS#5864 Change-Id: I1ca810542e89980ffda11876fd30626467e452d1
2022-03-04support "empty" SCCP N-Connect from MSCNeels Hofmeyr1-36/+108
Teach osmo-bsc to handle empty N-Connect. So far we were always expecting user data in an SCCP N-Connect from an MSC. However, it is perfectly valid for an initial BSSMAP request to follow later. This is relevant for: - Handover Request (incoming inter-BSC handover) - Perform Location Request (query physical location of the MS) Add state WAIT_INITIAL_USER_DATA with new timeout net X25. Always enter this state so that we don't have two separate code paths for handling initial user data. Related: SYS#5864 Change-Id: I535c791fa01e99a2226392eb05f676ba6c3cc16e
2022-03-04add counter for inter-BSC incoming Handover RequestNeels Hofmeyr1-0/+1
Related: SYS#5864 Change-Id: Icdde2bb339a5e367a4d297802214a1ef3f36eefa
2022-03-04add missing counter increment for Perform Location RequestNeels Hofmeyr1-0/+1
Also increment message counter for the case that a Perform Location Request came in the initial SCCP N-Connect message. Related: SYS#5864 Change-Id: I3f78ce73eb16fdff1f19359963405b2235000fc4
2022-03-04tweak logl to ERROR for invalid initial BSSMAPNeels Hofmeyr1-4/+4
Related: SYS#5864 Change-Id: Idd7d763129a5acdf19cd0ae86e82b77ee0073f2f
2022-03-04gscon clear: without SCCP conn, no need to wait for RLSD timeoutNeels Hofmeyr1-0/+4
Skip the BSSMAP Clear and SCCP RLSD parts and immediately deallocate the gscon when there is no SCCP connection present. Before this patch, such conn would stick around for a minute before a timeout deallocates it. Related: OS#5337 Change-Id: I8c8537acf6b47b121903197608636c43ae601a57
2022-03-04fix gscon clear 3/n: separate state for SCCP RLSDNeels Hofmeyr1-54/+71
Properly implement the separate conn release stages in separate FSM states: x) sent Clear Request, wait for a Clear Command from the MSC. Timeout after a configurable 60s. y) after a Clear Command and sending a Clear Complete, wait for the SCCP RLSD. Timeout after a configurable 60s. z) terminate after the RLSD is received / after timeout. handover_test.c needs a little tweak to make the MGCP release work with its fake MGCP client, because cleanup now ensures to invoke gscon_forget_mgw_endpoint() in all cases. Related: I680ec4ed866aa5f0b1ff29e7e98322615cfb288d (osmo-ttcn3-hacks) Related: OS#5337 Change-Id: Ie975117d37f38ba853589dc7f8d3e94f8f9586b2
2022-03-04fix gscon clear 2/n: proper state transition to ST_CLEARINGNeels Hofmeyr1-15/+20
The way the ST_CLEARING is entered before this patch has various symptoms of how I / we used osmo_fsm when we were still FSM amateurs in Osmocom. Patch that up: - In gscon_bssmap_clear(), ask for a state transition to ST_CLEARING first. Go ahead only if it is allowed. - move the Clear Request messaging to ST_CLEARING's onenter function. - Fix the timeout behavior: by using conn_fsm_state_chg(), use the actual proper X4 timer value for ST_CLEARING from VTY configuration instead of hardcoded magic numbers. Related: OS#5337 Change-Id: I234b2a754d0c98031056981823cdbc187e977741
2022-03-04fix gscon clear 1/n: store clear cause in gsconNeels Hofmeyr1-3/+5
Allow returning a context sensitive cause instead of a hardcoded one in gscon pre_term(). Also, the conn->cause is needed to move message dispatch to an "onenter" function in patch I234b2a754d0c98031056981823cdbc187e977741. I Split this part off as a separate patch for better readability. Related: OS#5337 Change-Id: Ib6432746040899129d1d73ae8dc59add2d88a915
2021-11-24bsc_subscr_conn_fsm: fix crash if !connOliver Smith1-0/+5
Do not crash in gscon_ensure_mgw_endpoint() if conn is NULL. Related: SYS#5728 Change-Id: Id579243cc9ebbe8f315cd11754166970329dc9cf
2021-10-29bsc_subscr_conn_fsm: fix mgw-pool ref countingPhilipp Maier1-0/+6
When the gsm_subscr_conn_fsm (GSCO) terminates abormally it might not go through the forget-mgw-endpoint mechanism. It might be terminated forcefully, which means only the pre_term callback runs. The pre_term callback clears the endpoint, but it does not put the mgcp_client reference back into the pool. This results into a wrong ref-count in the mgw-pool. Change-Id: I5a7ce6a1880a1060df74d03dd4eb38b51fd85c69 Related: SYS#5675
2021-09-03osmo_bsc_main: integrate MGW pooling into osmo-bscPhilipp Maier1-10/+25
Since the libosmo-mgcp-client now supports MGW pooling, lets use this feature in osmo-bsc. Large RAN installations may benefit from distributing the RTP voice stream load on multiple media gateways. Depends: osmo-mgw Icaaba0e470e916eefddfee750b83f5f65291a6b0 Change-Id: I8f33ab2cea04b545c403a6fe479aa963a0fc0d0d Related: SYS#5091
2021-08-02coverity: quench null deref warning in gscon_change_primary_lchan()Neels Hofmeyr1-2/+4
The if conditions for logging an lchan change made it look like new_lchan might actually be NULL, which it never is. So rather pin new_lchan as non-NULL with an assert and simplify the logic. Related: CID#237146 Related: b0d854556dafe885d740346b1b34ab247cb09d56 Change-Id: I8859c6cb9b3b15287e339ce4b6815b946965d0d9
2021-07-24debug log: indicate change of primary lchan on a connNeels Hofmeyr1-0/+8
Change-Id: Ib4e9a1cde9248f5d3fd8d7d8277623b42670b059
2021-06-17Introduce VTY command to disable srvcc fast-return on target BTSPau Espin Pedrol1-3/+4
Related: SYS#5337 Change-Id: I2ac91b5dffc9b6de60576aabe21a15f24fea38cb
2021-06-04Use new stat item/ctr getter APIsPau Espin Pedrol1-3/+3
Generated with following and similar spatch snippets: """ @@ expression E1, E2; @@ - &E2->ctr[E1] + rate_ctr_group_get_ctr(E2, E1) """ Change-Id: I0b43f922a595d694ac0aeda80107ef9bf4e755e7
2021-05-28RSL link: explicitly select rsl_link based on lchanNeels Hofmeyr1-1/+0
Prepare for VAMOS, where there will be secondary "shadow" lchans serving secondary MS on the same timeslots. For those, RSL messages will need to reflect a different stream ID aka TEI, via an rsl_link_vamos. Make sure that every code path that sends an RSL message for a specific lchan selects the RSL link via the new function rsl_chan_link(). When VAMOS is implemented, this function can select the proper RSL stream. Rename gsm_bts_trx.rsl_link to rsl_link_primary. This makes sure I'm not missing any uses of the RSL link, and clarifies the code. Related: SYS#5315 OS#4940 Change-Id: Ifbf16bb296e91f151d19e15e39f5c953ad77ff17
2021-05-21gscon MGCP: properly skip redundant MDCX towards MSCNeels Hofmeyr1-1/+3
So far we were comparing the requested MSC side RTP address+port with the MGW side's address+port, which would practically always fail, and hence we always issued redundant MDCX even if for unchanged MSC side. Skip the MDCX if the MSC side remains unchanged. Emit the success event immediately if the MDCX is skipped. Depends: Ibb488925827d9dc0ccb1f8d6d84728745d086793 (osmo-mgw/libosmo-mgcp-client) Change-Id: If994ecef9d4269a8120b0575de9b6d0c3be19146
2021-04-19Send EUTRAN neighs based on whether Common Id msg contained Last used ↵Pau Espin Pedrol1-6/+11
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 "3.2.1.21 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-15bssap: pass whole tlv_parsed to event GSCON_EV_A_COMMON_ID_INDPau Espin Pedrol1-4/+10
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-03-24refactor handover penalty timersNeels Hofmeyr1-2/+2
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
2020-10-09LCS: allow RSL EST IND during GSCON_ST_ACTIVENeels Hofmeyr1-1/+10
If an A-interface conn is already active (for Location Services), an RSL EST IND may arrive during GSCON_ST_ACTIVE. Pass it on instead of rejecting. This allows establishing Layer 3 on an already active A-interface conn. Change-Id: Ib18a12f8b8bcfb356188b2c0d97d555c1850f23e
2020-10-09LCS: implement the bulk of Location ServicesNeels Hofmeyr1-10/+50
Depends: I4d7302a4853518916b6b425e710c10568eb2ffe5 (libosmocore) Change-Id: I28314ba97df86a118497e9b2770e2e6e2484e872
2020-10-07cosmetic: fix naming of GSCON_EV_A_CONN_REQ -> GSCON_EV_MO_COMPL_L3Neels Hofmeyr1-3/+3
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 Hofmeyr1-2/+3
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-07compl l3: populate conn's bsc subscr from MINeels Hofmeyr1-5/+0
Set conn->bsub as indicated by the Mobile Identity. Now the 'log_set_context(LOG_CTX_BSC_SUBSCR, conn->bsub);' becomes useful. Upcoming patch to support Perform Location Request will use the subscriber to retrieve an already established conn via the bsub. Drop fixme in gscon_fsm_init(), MI now extracted and id updated. Change-Id: I00d4c7e8284b745368a432a7ec176aa99f79db47
2020-10-07gscon_bssmap_clear(): guard against NULL mscNeels Hofmeyr1-0/+6
Change-Id: I95b16cebb6ff78649f72a09b5d6c7c7e403233fa
2020-09-18clean up timer definitions: introduce groups, move some T to XNeels Hofmeyr1-8/+8
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-08-31handover_fsm: signal Clear from gscon, for proper HO result countsNeels Hofmeyr1-0/+5
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 Hofmeyr1-0/+7
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-30fix 'handover:*' counters: add missing / move incrementsNeels Hofmeyr1-7/+0
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-26bsc_subscr_conn_fsm: use proper cause values in SAPI N REJECTVadim Yanitskiy1-2/+7
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-26bsc_subscr_conn_fsm: fix a memleak in rll_ind_cb()Vadim Yanitskiy1-1/+3
Change-Id: I9ce35c1e446b0dfdb5b01651466ccaafc23c9318
2020-08-24Add bts counters to count BTS events where we don't have a btsDaniel Willmann1-0/+2
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 handover per BTS as well as per BSCDaniel Willmann1-0/+4
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-17Implement support for receiving BSSMAP CommonID from MSCHarald Welte1-1/+16
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-13gscon timeout: use proper cause code for lchan releaseNeels Hofmeyr1-1/+1
Since we verify the cause code of the RSL channel release in ttcn3-bsc-tests, BSC_Tests.TC_chan_act_ack_est_ind_noreply shows an invalid release cause code of 127. Fix that. On gscon timeout, don't send the unrelated RSL code RSL_ERR_INTERWORKING, but a proper RR cause code. GSM48_RR_CAUSE_ABNORMAL_TIMER is defined as the proper cause for an expired timer (3GPP TS 44.018 10.5.2.31). Should fix this error in BSC_Tests.TC_chan_act_ack_est_ind_noreply: BSC_Tests.ttcn:1590 Dynamic test case error: Assigning invalid numeric value 127 to a variable of enumerated type @GSM_RR_Types.RR_Cause. Change-Id: Ic2e4b692e78f7b134fe57d1077a08adb48398e06
2020-08-13cosmetic: bscon: use GSM48_RR_CAUSE_NORMAL instead of 0Neels Hofmeyr1-1/+1
Change-Id: Ia0e23bbc5506e9be3e0682c4dab5b9ecb91cf477
2020-08-12e1: encode line number as trunk number in MGCP endpointPhilipp Maier1-2/+5
The MGCP endpoint name, that is generated when an E1 endpoint is selected does have a hardcoded trunk id number, which is permanantly set to 1. Lets use the E1 line number instead. Related: OS#2547 Change-Id: Ic5447bb4426e31d119667bdfddfd2c91fd591fc6
2020-08-06lchan_rtp_fsm: use E1 endpoints if the BTS is not ipaccess typePhilipp Maier1-4/+12
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-18Move struct gsm_bts_trx: gsm-data.* => bts_trx.*Pau Espin Pedrol1-0/+1
See rant fro similar recent commit moving stuff to bts.*. Change-Id: I11758ca3d255d849d77bd068f24bb68bde1f89a5
2020-07-16propagate RSL error cause codes to RR Channel Release causeNeels Hofmeyr1-0/+2
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 Hofmeyr1-5/+10
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-06-17log: add MSC number to bsc_subscr_conn_fsm idNeels Hofmeyr1-1/+4
Change-Id: Iae232d0616d6c0009e3abe2dcfcb9c51ddfc761e
2020-05-28bsc_subscr_conn_fsm: Fix crash in gscon_forget_lchan()Alexander Chemeris1-1/+1
conn->fi might be NULL and thus can't be safely dereferenced. E.g. we're checking if it's NULL or not just a few lines above. so we should here as well. Here is a backtrace for the crash: (gdb) bt 0 0x000055b948002772 in gscon_forget_lchan (conn=0x55b949c6b870, lchan=lchan@entry=0x7f00ae9ade68) at bsc_subscr_conn_fsm.c:718 1 0x000055b948036c84 in lchan_fsm_wait_rf_release_ack_onenter (fi=<optimized out>, prev_state=<optimized out>) at lchan_fsm.c:1040 2 0x00007f00afc6a599 in state_chg (fi=fi@entry=0x55b949bcfe10, new_state=new_state@entry=8, keep_timer=keep_timer@entry=false, timeout_ms=2000, T=3111, file=<optimized out>, line=1344) at fsm.c:699 3 0x00007f00afc6aa5d in _osmo_fsm_inst_state_chg (fi=fi@entry=0x55b949bcfe10, new_state=new_state@entry=8, timeout_secs=<optimized out>, T=<optimized out>, file=<optimized out>, line=<optimized out>) at fsm.c:748 4 0x00007f00afc78e62 in _osmo_tdef_fsm_inst_state_chg (fi=fi@entry=0x55b949bcfe10, state=state@entry=8, timeouts_array=timeouts_array@entry=0x55b9482b56a0 <lchan_fsm_timeouts>, tdefs=<optimized out>, default_timeout=140730455622800, default_timeout@entry=5, file=file@entry=0x55b948079d39 "lchan_fsm.c", line=1344) at tdef.c:346 5 0x000055b9480341eb in lchan_fsm_timer_cb (fi=0x55b949bcfe10) at lchan_fsm.c:1344 6 0x00007f00afc6b84a in fsm_tmr_cb (data=0x55b949bcfe10) at fsm.c:325 7 0x00007f00afc65926 in osmo_timers_update () at timer.c:257 8 0x00007f00afc65cda in _osmo_select_main (polling=0) at select.c:260 9 0x00007f00afc66526 in osmo_select_main_ctx (polling=<optimized out>) at select.c:291 10 0x000055b947fdcadf in main (argc=<optimized out>, argv=<optimized out>) at osmo_bsc_main.c:953 (gdb) p conn->fi $1 = (struct osmo_fsm_inst *) 0x0 Change-Id: I2427266ef4660935cde899462fa6df8d785c420e
2020-05-11stats: Add counters for Tx BSSMAP messages.Alexander Chemeris1-0/+3
We already have counters for Rx side, now we also count Tx side. See comments in the msc_ctr_description array implementation for the details. Change-Id: I89a173f6bdd9a3c21233fe01d07ab2ff0442bb10
2020-05-09bsc_subscr_conn_fsm: Fix a typo in the comment life->liveAlexander Chemeris1-1/+1
Change-Id: Ideba357678a59e3f314a0d618d181a233a43b4de
2019-11-13Fix some typosMartin Hauke1-1/+1
Fix typos and common misspellings in code comments and in the manual. Change-Id: I46fc9d424620c77ae9ccf78b58081bd303386d7c
2019-09-18bsc_subscr_conn_fsm: Cleanly clear BSSAP conn if associated channel closed ↵Pau Espin Pedrol1-5/+28
during WAIT_CC TTCN3 BSC_Tests.TC_ms_rel_ind_does_not_cause_bssmap_reset seems to sometimes run into a race condition on the order of messages received by osmo-bsc comming from MSC and BTS. Usual (expected) scenario): BTS->BSC EST IND BSC->MSC CL3 Info BSC<-MSC CC BTS->BSC REL IND BTS<-BSC DEACT SACCH BSC->MSC ClearRequest BSC<-MSC ClearCommand BSC->MSC ClearComplete BTS<-BSC RF Chan Release BTS->BSC RF Chan Release ACK Sometimes CC message and REL IND message are received swapped (because they are sent by different components asynchronously in TTCN3). As a result, osmo-bsc was failing to go into CLEARING state and was unable to send the ClearRequest because CC was still not received. So the idea is to stay in WAIT_CC until CC is received, then check if the lchan was dropped and in that case go into clearing state. Change-Id: Id1abf5ee44c60925b478123409f26bd29006202b
2019-07-09remove double BSSMAP Clear on HO failureNeels Hofmeyr1-8/+0
If a handover fails when the new lchan is already fully established, osmo-bsc so far caused two BSSMAP Clear Requests to be sent out to the MSC: one caused by detaching the lchan from the gscon, one from returning the gscon back to ST_ACTIVE, which detects that no lchan is present and Clears. In fact only one of those is necessary. Checking for the presence of an lchan when entering ST_ACTIVE is an earlier attempt to catch insane situations. Since then, osmo-bsc has acquired other logic that will ensure sending a Clear Request in all cases, see gscon_forget_lchan(). Sending another BSSMAP Clear Request in ST_ACTIVE's onenter is simply not necessary. Drop gscon_fsm_active_onenter() entirely. Note: the double Clear Request is currently hit by TC_ho_out_fail_no_ho_detect(), which currently fails and will pass again after this patch; however, osmo-bsc should actually not release the lchan at all during this test, see OS#4093. In other words, osmo-bsc behavior for this scenario as well as TC_ho_out_fail_no_ho_detect() need to be changed, and the test will, once fixed, not be useful to trigger this issue anymore. Related: OS#4078 Change-Id: Iac1519eb8b24e8523caec682f9ac8e6dcf1327ce
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-22 03:49:55 +0000