Add missing conn->assignment.created_ci_for_msc to
gscon_forget_mgw_endpoint_ci().
Before this patch, when assignment.created_ci_for_msc lingers after a
DLCX, it can cause a use-after-free on assignment_reset(). Possible
scenario is rx BSSMAP Clear Cmd during ongoing Assignment.
In assignment_reset(), locally cache the ci pointer, because
gscon_forget_mgw_endpoint_ci() now NULLs created_ci_for_msc.
Related: OS#5572
Change-Id: If89610020f47fd6517081dd11b83911b043bd0f1
The proper way to fix this is having a use count on the SCCP conn, one
each for a busy lchan and a busy Location Request. That would require a
bunch more work and testing.
This patch is the least-effort way to avoid the following scenario:
Emergency call is started;
Location Request is started to locate the emergency;
lchan releases early for any reason;
Perfectly fine Location Request gets canceled by Clear Request;
The information was there, but we did not forward the location;
No help at emergency because of my code.
Allow Location Request to complete for these cases:
- rx RLL REL IND (or any other reason for gscon_lchan_releasing())
- rx RSL CONN FAIL
Related: SYS#5912
Related: Idea690a4aa4aecbe4642a16e96d086cc0538564a (osmo-ttcn3-hacks)
Change-Id: Ib44dd05b0adee84234f671313b156ff6625357cc
After the lchan release, the gscon would go into the Clear dance with an
arbitrary cause value. Instead, explicitly ask for a Clear upon
pre-emption, with the proper cause value.
Related: OS#5535
Change-Id: I20108f7b4769400b89b7b0d65c8dab883bf87c46
If we receive something unexpected, log it (and free the msgb!)
Change-Id: I43fab6a3a1c5e7a6545d6ef848636f5ba1be1576
Related: OS#5530 (only tangentially related)
"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
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
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
The SAPI "n" REJECT messages were being sent with DLCI keeping the RSL
LINK ID format, which is not the same for CC bits.
With this patch, TTCN3 test BSC_Tests.TC_rll_sapi_n_reject_dlci_cc
passes again.
Related: OS#4728
Related: SYS#5047
Change-Id: Icc187f594743040a3d9b8beff7d9cfc21dd6eb08
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
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
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
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
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
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
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: b0d854556d
Change-Id: I8859c6cb9b3b15287e339ce4b6815b946965d0d9
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
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
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
This change will allow handling more IEs in the future, like
"Last used E-UTRAN PLMN ID" one.
Related: SYS#5337
Change-Id: I96a0e1a7491fabf7aaad62207886821ad6194927
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
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
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
During LCS development, I'm getting use count bugs and would like to see use
token strings to figure it out.
Change-Id: I29bf60059d4cf7bb99a00753e6cdc149baf95f94
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Neels Hofmeyr
Harald Welte
Pau Espin
Neels Hofmeyr
Oliver Smith
Philipp Maier
Vadim Yanitskiy
Daniel Willmann