cellular-infrastructure
/
osmo-bsc
mirror of https://gerrit.osmocom.org/osmo-bsc
9
0
Fork 0
Code Issues Releases Wiki Activity
osmo-bsc/src/osmo-bsc/osmo_bsc_msc.c

291 lines
14 KiB
C
Raw Normal View History

bsc: Add code responsible for connecting, reconnecting to the MSC Add the code that is forwarding data, from and to the MSC, also handling ping/pong timers and authentication. Hook it into the osmo_bsc. The code is only compile tested and ported from the on-waves/bsc-master branch.
2010-09-15 18:14:41 +00:00
/*
* Handle the connection to the MSC. This include ping/timeout/reconnect
Remove 'struct bsc_msc_connection' + fix IPA-encapsulated CTRL The bsc_msc_connection dates back to the old pre-libosmo-sigtran days, and 90% of the field members weren't used at all (even the new sigtran specific ones!). Let's merge what remains into struct bsc_msc_data. As a side effect, the already dysfunctional "dest A.B.C.D" VTY command has been removed from the MSC node. There's quite a bit of fall-out in the CTRL interface, which was the code with strongest ties to bsc_msc_connection. This was resolved by properly porting CTRL handling over to libosmo-sigtran, meaning that an IPA/SCCPlite connected MSC can now again send CTRL GET/SET commands, and can also receive those selective few TRAPs that old osmo-bsc-sccplite also sent to its MSC[s]. Change-Id: I6b7354f3b23a26bb4eab12213ca3d3b614c8154f Related: OS#2012
2018-05-26 20:42:29 +00:00
* (C) 2008-2018 by Harald Welte <laforge@gnumonks.org>
bsc: Allow to use different LAC/CI for the core-network We need to use different LAC/CI towards the core network. It is a bit problematic as LAC/CI is a per BTS attribute so this feature only works if a BSC manages everything in the same LAC. Related: SYS#1398
2015-04-01 16:15:48 +00:00
* (C) 2009-2015 by Holger Hans Peter Freyther <zecke@selfish.org>
* (C) 2009-2015 by On-Waves
bsc: Add code responsible for connecting, reconnecting to the MSC Add the code that is forwarding data, from and to the MSC, also handling ping/pong timers and authentication. Hook it into the osmo_bsc. The code is only compile tested and ported from the on-waves/bsc-master branch.
2010-09-15 18:14:41 +00:00
* All Rights Reserved
*
* This program is free software; you can redistribute it and/or modify
License change: We are now AGPLv3+ instead of GPLv2+ The reason for this is quite simple: We want to make sure anyone running a customized version of OpenBSC to operate a network will have to release all custom modifiations to the source code.
2011-01-01 14:25:50 +00:00
* it under the terms of the GNU Affero General Public License as published by
* the Free Software Foundation; either version 3 of the License, or
bsc: Add code responsible for connecting, reconnecting to the MSC Add the code that is forwarding data, from and to the MSC, also handling ping/pong timers and authentication. Hook it into the osmo_bsc. The code is only compile tested and ported from the on-waves/bsc-master branch.
2010-09-15 18:14:41 +00:00
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
License change: We are now AGPLv3+ instead of GPLv2+ The reason for this is quite simple: We want to make sure anyone running a customized version of OpenBSC to operate a network will have to release all custom modifiations to the source code.
2011-01-01 14:25:50 +00:00
* GNU Affero General Public License for more details.
bsc: Add code responsible for connecting, reconnecting to the MSC Add the code that is forwarding data, from and to the MSC, also handling ping/pong timers and authentication. Hook it into the osmo_bsc. The code is only compile tested and ported from the on-waves/bsc-master branch.
2010-09-15 18:14:41 +00:00
*
License change: We are now AGPLv3+ instead of GPLv2+ The reason for this is quite simple: We want to make sure anyone running a customized version of OpenBSC to operate a network will have to release all custom modifiations to the source code.
2011-01-01 14:25:50 +00:00
* You should have received a copy of the GNU Affero General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
bsc: Add code responsible for connecting, reconnecting to the MSC Add the code that is forwarding data, from and to the MSC, also handling ping/pong timers and authentication. Hook it into the osmo_bsc. The code is only compile tested and ported from the on-waves/bsc-master branch.
2010-09-15 18:14:41 +00:00
*
*/
move libctrl from openbsc to libosmoctrl (libosmocore.git)
2014-08-20 21:47:15 +00:00
#include <osmocom/ctrl/control_cmd.h>
#include <osmocom/ctrl/control_if.h>
bsc: Check for the rand and then generate a res Check if the NAT has sent 16 bytes of RAND and if a key has been configured in the system and then generate a result using milenage. The milenage res will be sent and noth the four byte GSM SRES derivation.
2015-06-08 16:02:10 +00:00
#include <osmocom/crypt/auth.h>
move include/openbsc to include/osmocom/bsc Change-Id: I39e7b882caa98334636d19ccd104fd83d07d5055
2017-09-04 13:15:32 +00:00
#include <osmocom/bsc/debug.h>
#include <osmocom/bsc/gsm_data.h>
#include <osmocom/bsc/ipaccess.h>
#include <osmocom/bsc/bsc_msc_data.h>
Re-introduce support for IPA-encapsulated MGCP Old osmo-bsc-sccplite already supported this, but in the migration over to libosmo-sigtran and to real 3GPP AoIP, this functionality got lost. We now create a UDP proxy socket. Any MGCP commands received via IPA from MSC (or rather: bsc_nat) are retransmitted to the MGW via UDP on this socket. Any responses back from the MGW received on the UDP socket are retransmitted back to MSC/bsc_nat as MGCP inside the IPA multiplex. Closes: OS#2536 Change-Id: I38ad8fa645c08900e0e1f1b4b96136bc6d96b3ab
2018-05-26 20:56:59 +00:00
#include <osmocom/bsc/osmo_bsc_sigtran.h>
move include/openbsc to include/osmocom/bsc Change-Id: I39e7b882caa98334636d19ccd104fd83d07d5055
2017-09-04 13:15:32 +00:00
#include <osmocom/bsc/signal.h>
Move struct gsm_bts: gsm_data.* => bts.* 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-15 18:53:16 +00:00
#include <osmocom/bsc/bts.h>
bsc: Add code responsible for connecting, reconnecting to the MSC Add the code that is forwarding data, from and to the MSC, also handling ping/pong timers and authentication. Hook it into the osmo_bsc. The code is only compile tested and ported from the on-waves/bsc-master branch.
2010-09-15 18:14:41 +00:00
osmo_bsc: Use libctrl, handle ctrl cmds on port 4249 or from the nat This patch initializes libctrl to listen for connections on port 4249. Additionally, control messages arriving from the nat will also be processed.
2011-02-18 13:30:25 +00:00
#include <osmocom/core/talloc.h>
Re-introduce support for IPA-encapsulated MGCP Old osmo-bsc-sccplite already supported this, but in the migration over to libosmo-sigtran and to real 3GPP AoIP, this functionality got lost. We now create a UDP proxy socket. Any MGCP commands received via IPA from MSC (or rather: bsc_nat) are retransmitted to the MGW via UDP on this socket. Any responses back from the MGW received on the UDP socket are retransmitted back to MSC/bsc_nat as MGCP inside the IPA multiplex. Closes: OS#2536 Change-Id: I38ad8fa645c08900e0e1f1b4b96136bc6d96b3ab
2018-05-26 20:56:59 +00:00
#include <osmocom/core/socket.h>
osmo_bsc: Use libctrl, handle ctrl cmds on port 4249 or from the nat This patch initializes libctrl to listen for connections on port 4249. Additionally, control messages arriving from the nat will also be processed.
2011-02-18 13:30:25 +00:00
Fix build of bsc-nat and GPRS code after include path change The last patch changed the osmocore include paths, this fixes some build problems caused by it
2011-03-23 17:26:56 +00:00
#include <osmocom/gsm/gsm0808.h>
MSC pooling: make NRI mappings VTY configurable Use the osmo_nri_ranges API to manage each MSC's NRI ranges by VTY configuration. Change-Id: I6c251f2744d7be26fc4ad74adefc96a6a3fe08b0
2020-05-26 01:58:14 +00:00
#include <osmocom/gsm/gsm23236.h>
bsc: Add code responsible for connecting, reconnecting to the MSC Add the code that is forwarding data, from and to the MSC, also handling ping/pong timers and authentication. Hook it into the osmo_bsc. The code is only compile tested and ported from the on-waves/bsc-master branch.
2010-09-15 18:14:41 +00:00
src: port openBSC over libosmo-abis This is a big patch that ports openBSC over libosmo-abis. Sorry, the changes that are included here are all dependent of libosmo-abis, splitting them into smaller pieces would leave the repository in some intermediate state, which is not desired. The main changes are: - The directory libabis/ has been removed as it now lives in libosmo-abis. - new configuration file format for nanoBTS and HSL femto, we need to define the virtual e1_line and attach it to the OML link. - all the existing BTS drivers (nanoBTS, hsl femto, Nokia site, BS11 and rbs2000) now use the new libosmo-abis framework. - use r232 input driver available in libosmo-abis for bs11_config. - use ipa_msg_recv instead of old ipaccess_read_msg function. - delete definition of gsm_e1_subslot and input_signal_data. These structures now lives in libosmo-abis. Most of this patch are deletions of libabis/ which has been moved to libosmo-abis. This patch also modifies openBSC to use all the new definitions available in libosmocore and libosmo-abis. In order to do that, we have replaced the following: - DINP, DMI, DMIB and DMUX by their respective DL* correspondences. - SS_GLOBAL by SS_L_GLOBAL - SS_INPUT by SS_L_INPUT - S_GLOBAL_SHUTDOWN by S_L_GLOBAL_SHUTDOWN - SS_INPUT by SS_L_INPUT - S_INP_* by S_L_INP_* sub-signals - E1INP_NODE by L_E1INP_NODE vty node This patch has been tested with: - one nanoBTS - the HSL femto with the examples available under libosmo-abis - BS11 with both dahdi and misdn drivers.
2011-08-17 20:44:07 +00:00
#include <osmocom/abis/ipa.h>
Re-introduce support for IPA-encapsulated MGCP Old osmo-bsc-sccplite already supported this, but in the migration over to libosmo-sigtran and to real 3GPP AoIP, this functionality got lost. We now create a UDP proxy socket. Any MGCP commands received via IPA from MSC (or rather: bsc_nat) are retransmitted to the MGW via UDP on this socket. Any responses back from the MGW received on the UDP socket are retransmitted back to MSC/bsc_nat as MGCP inside the IPA multiplex. Closes: OS#2536 Change-Id: I38ad8fa645c08900e0e1f1b4b96136bc6d96b3ab
2018-05-26 20:56:59 +00:00
#include <osmocom/mgcp_client/mgcp_client.h>
bsc: Add code responsible for connecting, reconnecting to the MSC Add the code that is forwarding data, from and to the MSC, also handling ping/pong timers and authentication. Hook it into the osmo_bsc. The code is only compile tested and ported from the on-waves/bsc-master branch.
2010-09-15 18:14:41 +00:00
#include <sys/socket.h>
#include <netinet/tcp.h>
#include <unistd.h>
stats: Add a stats gauge for the MSC links count. Change-Id: Ibe4b29056ba704a27b925cfdba49f343ee34f428
2020-05-07 13:41:26 +00:00
static const struct rate_ctr_desc msc_ctr_description[] = {
stats: Rename BSSMAP Rx message counters to match Tx ones. Change-Id: I29e42687ac084a60007f0b1ec6ec0a102fb4007f
2020-05-09 22:49:34 +00:00
/* Rx message counters (per specific message) */
[MSC_CTR_BSSMAP_RX_UDT_RESET_ACKNOWLEDGE] = {"bssmap:rx:udt:reset:ack", "Number of received BSSMAP UDT RESET ACKNOWLEDGE messages"},
[MSC_CTR_BSSMAP_RX_UDT_RESET] = {"bssmap:rx:udt:reset:request", "Number of received BSSMAP UDT RESET messages"},
[MSC_CTR_BSSMAP_RX_UDT_PAGING] = {"bssmap:rx:udt:paging", "Number of received BSSMAP UDT PAGING messages"},
[MSC_CTR_BSSMAP_RX_UDT_UNKNOWN] = {"bssmap:rx:udt:err_unknown", "Number of received BSSMAP unknown UDT messages"},
[MSC_CTR_BSSMAP_RX_DT1_CLEAR_CMD] = {"bssmap:rx:dt1:clear:cmd", "Number of received BSSMAP DT1 CLEAR CMD messages"},
[MSC_CTR_BSSMAP_RX_DT1_CIPHER_MODE_CMD] = {"bssmap:rx:dt1:cipher_mode:cmd", "Number of received BSSMAP DT1 CIPHER MODE CMD messages"},
[MSC_CTR_BSSMAP_RX_DT1_ASSIGMENT_RQST] = {"bssmap:rx:dt1:assignment:rqst", "Number of received BSSMAP DT1 ASSIGMENT RQST messages"},
[MSC_CTR_BSSMAP_RX_DT1_LCLS_CONNECT_CTRL] = {"bssmap:rx:dt1:lcls_connect_ctrl:cmd", "Number of received BSSMAP DT1 LCLS CONNECT CTRL messages"},
[MSC_CTR_BSSMAP_RX_DT1_HANDOVER_CMD] = {"bssmap:rx:dt1:handover:cmd", "Number of received BSSMAP DT1 HANDOVER CMD messages"},
[MSC_CTR_BSSMAP_RX_DT1_CLASSMARK_RQST] = {"bssmap:rx:dt1:classmark:rqst", "Number of received BSSMAP DT1 CLASSMARK RQST messages"},
bssap: Handle BSSMAP CONFUSION message. We decode the mesage and print it to the log files at ERROR log level. We also count it in the BSSMAP message counters. There is not much else we could do about it. Depends: If8afd2d096fb66c6c2f255a08fc1129de3d09cec (libosmocore) Change-Id: Ib4cd94f185f751b2384842222678ff671ac413c4
2020-05-12 21:47:03 +00:00
[MSC_CTR_BSSMAP_RX_DT1_CONFUSION] = {"bssmap:rx:dt1:confusion", "Number of received BSSMAP DT1 CONFUSION messages"},
Implement support for receiving BSSMAP CommonID from MSC 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-06-21 16:00:23 +00:00
[MSC_CTR_BSSMAP_RX_DT1_COMMON_ID] = {"bssmap:rx:dt1:common_id", "Number of received BSSMAP DT1 COMMON ID messages"},
stats: Rename BSSMAP Rx message counters to match Tx ones. Change-Id: I29e42687ac084a60007f0b1ec6ec0a102fb4007f
2020-05-09 22:49:34 +00:00
[MSC_CTR_BSSMAP_RX_DT1_UNKNOWN] = {"bssmap:rx:dt1:err_unknown", "Number of received BSSMAP unknown DT1 messages"},
[MSC_CTR_BSSMAP_RX_DT1_DTAP] = {"bssmap:rx:dt1:dtap:good", "Number of received BSSMAP DTAP messages"},
[MSC_CTR_BSSMAP_RX_DT1_DTAP_ERROR] = {"bssmap:rx:dt1:dtap:error", "Number of received BSSMAP DTAP messages with errors"},
LCS: implement the bulk of Location Services Depends: I4d7302a4853518916b6b425e710c10568eb2ffe5 (libosmocore) Change-Id: I28314ba97df86a118497e9b2770e2e6e2484e872
2020-09-17 15:54:39 +00:00
[MSC_CTR_BSSMAP_RX_DT1_PERFORM_LOCATION_REQUEST] = {"bssmap:rx:dt1:location:request", "Number of received BSSMAP Perform Location Request messages"},
[MSC_CTR_BSSMAP_RX_DT1_PERFORM_LOCATION_ABORT] = {"bssmap:tx:dt1:location:abort", "Number of received BSSMAP Perform Location Abort messages"},
stats: Add counters for Tx BSSMAP messages. 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-09 18:27:40 +00:00
/* Tx message counters (per message type)
*
* The counters here follow the logic of the osmo_bsc_sigtran_send() function
* which receives DT1 messages from the upper layers and actually sends them to the MSC.
* These counters cover all messages passed to the function by the upper layers: */
[MSC_CTR_BSSMAP_TX_BSS_MANAGEMENT] = {"bssmap:tx:type:bss_management", "Number of transmitted BSS MANAGEMENT messages"},
[MSC_CTR_BSSMAP_TX_DTAP] = {"bssmap:tx:type:dtap", "Number of transmitted DTAP messages"},
[MSC_CTR_BSSMAP_TX_UNKNOWN] = {"bssmap:tx:type:err_unknown", "Number of transmitted messages with unknown type (an error in our code?)"},
[MSC_CTR_BSSMAP_TX_SHORT] = {"bssmap:tx:type:err_short", "Number of transmitted messages which are too short (an error in our code?)"},
/* The next counters are also counted in the osmo_bsc_sigtran_send() function and
* sum up to the exactly same number as the counters above but instead of message
* classes they split by the result of the sending attempt: */
[MSC_CTR_BSSMAP_TX_ERR_CONN_NOT_READY] = {"bssmap:tx:result:err_conn_not_ready", "Number of BSSMAP messages we tried to send when the connection was not ready yet"},
[MSC_CTR_BSSMAP_TX_ERR_SEND] = {"bssmap:tx:result:err_send", "Number of socket errors while sending BSSMAP messages"},
[MSC_CTR_BSSMAP_TX_SUCCESS] = {"bssmap:tx:result:success", "Number of successfully sent BSSMAP messages"},
/* Tx message counters (per specific message)
*
* Theoretically, the DT1 counters should sum up to the same number as the Tx counters
* above but since these counters are coming from the upper layers, there might be
* some difference if we forget some code path. */
[MSC_CTR_BSSMAP_TX_UDT_RESET] = {"bssmap:tx:udt:reset:request", "Number of transmitted BSSMAP UDT RESET messages"},
[MSC_CTR_BSSMAP_TX_UDT_RESET_ACK] = {"bssmap:tx:udt:reset:ack", "Number of transmitted BSSMAP UDT RESET ACK messages"},
[MSC_CTR_BSSMAP_TX_DT1_CLEAR_RQST] = {"bssmap:tx:dt1:clear:rqst", "Number of transmitted BSSMAP DT1 CLEAR RQSTtx messages"},
[MSC_CTR_BSSMAP_TX_DT1_CLEAR_COMPLETE] = {"bssmap:tx:dt1:clear:complete", "Number of transmitted BSSMAP DT1 CLEAR COMPLETE messages"},
[MSC_CTR_BSSMAP_TX_DT1_ASSIGMENT_FAILURE] = {"bssmap:tx:dt1:assigment:failure", "Number of transmitted BSSMAP DT1 ASSIGMENT FAILURE messages"},
[MSC_CTR_BSSMAP_TX_DT1_ASSIGMENT_COMPLETE] = {"bssmap:tx:dt1:assigment:complete", "Number of transmitted BSSMAP DT1 ASSIGMENT COMPLETE messages"},
[MSC_CTR_BSSMAP_TX_DT1_SAPI_N_REJECT] = {"bssmap:tx:dt1:sapi_n:reject", "Number of transmitted BSSMAP DT1 SAPI N REJECT messages"},
[MSC_CTR_BSSMAP_TX_DT1_CIPHER_COMPLETE] = {"bssmap:tx:dt1:cipher_mode:complete", "Number of transmitted BSSMAP DT1 CIPHER COMPLETE messages"},
[MSC_CTR_BSSMAP_TX_DT1_CIPHER_REJECT] = {"bssmap:tx:dt1:cipher_mode:reject", "Number of transmitted BSSMAP DT1 CIPHER REJECT messages"},
[MSC_CTR_BSSMAP_TX_DT1_CLASSMARK_UPDATE] = {"bssmap:tx:dt1:classmark:update", "Number of transmitted BSSMAP DT1 CLASSMARK UPDATE messages"},
[MSC_CTR_BSSMAP_TX_DT1_LCLS_CONNECT_CTRL_ACK] = {"bssmap:tx:dt1:lcls_connect_ctrl:ack", "Number of transmitted BSSMAP DT1 LCLS CONNECT CTRL ACK messages"},
[MSC_CTR_BSSMAP_TX_DT1_HANDOVER_REQUIRED] = {"bssmap:tx:dt1:handover:required", "Number of transmitted BSSMAP DT1 HANDOVER REQUIRED messages"},
[MSC_CTR_BSSMAP_TX_DT1_HANDOVER_PERFORMED] = {"bssmap:tx:dt1:handover:performed", "Number of transmitted BSSMAP DT1 HANDOVER PERFORMED messages"},
[MSC_CTR_BSSMAP_TX_DT1_HANDOVER_RQST_ACKNOWLEDGE] = {"bssmap:tx:dt1:handover:rqst_acknowledge", "Number of transmitted BSSMAP DT1 HANDOVER RQST ACKNOWLEDGE messages"},
[MSC_CTR_BSSMAP_TX_DT1_HANDOVER_DETECT] = {"bssmap:tx:dt1:handover:detect", "Number of transmitted BSSMAP DT1 HANDOVER DETECT messages"},
[MSC_CTR_BSSMAP_TX_DT1_HANDOVER_COMPLETE] = {"bssmap:tx:dt1:handover:complete", "Number of transmitted BSSMAP DT1 HANDOVER COMPLETE messages"},
[MSC_CTR_BSSMAP_TX_DT1_HANDOVER_FAILURE] = {"bssmap:tx:dt1:handover:failure", "Number of transmitted BSSMAP DT1 HANDOVER FAILURE messages"},
[MSC_CTR_BSSMAP_TX_DT1_DTAP] = {"bssmap:tx:dt1:dtap", "Number of transmitted BSSMAP DT1 DTAP messages"},
LCS: implement the bulk of Location Services Depends: I4d7302a4853518916b6b425e710c10568eb2ffe5 (libosmocore) Change-Id: I28314ba97df86a118497e9b2770e2e6e2484e872
2020-09-17 15:54:39 +00:00
[MSC_CTR_BSSMAP_TX_DT1_PERFORM_LOCATION_RESPONSE_SUCCESS] = {"bssmap:tx:dt1:location:response_success",
"Number of transmitted BSSMAP Perform Location Response messages containing a location estimate"},
[MSC_CTR_BSSMAP_TX_DT1_PERFORM_LOCATION_RESPONSE_FAILURE] = {"bssmap:tx:dt1:location:response_failure",
"Number of transmitted BSSMAP Perform Location Response messages containing a failure cause"},
MSC pooling: add rate counters Tests for these counters are added in I2006f1def5352b4b73d0159bfcaa2da9c64bfe3f (osmo-ttcn3-hacks). Change-Id: I2ded757958dfa62b502efbab765203bcadf899e2
2020-06-16 10:08:39 +00:00
/* Indicators for MSC pool usage */
[MSC_CTR_MSCPOOL_SUBSCR_NEW] = {
"mscpool:subscr:new",
"Complete Layer 3 requests assigned to this MSC by round-robin (no NRI was assigned yet).",
},
[MSC_CTR_MSCPOOL_SUBSCR_REATTACH] = {
"mscpool:subscr:reattach",
"Complete Layer 3 requests assigned to this MSC by round-robin because the subscriber indicates a"
" NULL-NRI (previously assigned by another MSC).",
},
[MSC_CTR_MSCPOOL_SUBSCR_KNOWN] = {
"mscpool:subscr:known",
"Complete Layer 3 requests directed to this MSC because the subscriber indicates an NRI of this MSC.",
},
[MSC_CTR_MSCPOOL_SUBSCR_PAGED] = {
"mscpool:subscr:paged",
"Paging Response directed to this MSC because the subscriber was recently paged by this MSC.",
},
[MSC_CTR_MSCPOOL_SUBSCR_ATTACH_LOST] = {
"mscpool:subscr:attach_lost",
"A subscriber indicates an NRI value matching this MSC, but the MSC is not connected:"
" a re-attach to another MSC (if available) was forced, with possible service failure.",
},
[MSC_CTR_MSCPOOL_EMERG_FORWARDED] = {
"mscpool:emerg:forwarded",
"Emergency call requests forwarded to this MSC.",
},
stats: Add a stats gauge for the MSC links count. Change-Id: Ibe4b29056ba704a27b925cfdba49f343ee34f428
2020-05-07 13:41:26 +00:00
};
static const struct rate_ctr_group_desc msc_ctrg_desc = {
"msc",
"mobile switching center",
OSMO_STATS_CLASS_GLOBAL,
ARRAY_SIZE(msc_ctr_description),
msc_ctr_description,
};
static const struct osmo_stat_item_desc msc_stat_desc[] = {
stat_item desc: add explicit indexes for clarity Add explicit indexes like [BSC_STAT_NUM_BTS_TOTAL] = { ... BSC_STAT_NUM_BTS_TOTAL == 0 and the first item of bsc_stat_desc of course has index 0, but when grepping the code, it looks like BSC_STAT_NUM_BTS_TOTAL is missing a name definition. Same for MSC_STAT_MSC_LINKS_ACTIVE and MSC_STAT_MSC_LINKS_TOTAL. Related: SYS#5542 Change-Id: Ie47e0857c41d517a9b37be96f6669d1825d24a6d
2021-08-19 17:25:47 +00:00
[MSC_STAT_MSC_LINKS_ACTIVE] = { "msc_links:active", "Number of active MSC links", "", 16, 0 },
[MSC_STAT_MSC_LINKS_TOTAL] = { "msc_links:total", "Number of configured MSC links", "", 16, 0 },
stats: Add a stats gauge for the MSC links count. Change-Id: Ibe4b29056ba704a27b925cfdba49f343ee34f428
2020-05-07 13:41:26 +00:00
};
static const struct osmo_stat_item_group_desc msc_statg_desc = {
.group_name_prefix = "msc",
.group_description = "mobile switching center",
.class_id = OSMO_STATS_CLASS_GLOBAL,
.num_items = ARRAY_SIZE(msc_stat_desc),
.item_desc = msc_stat_desc,
};
Re-introduce support for IPA-encapsulated MGCP Old osmo-bsc-sccplite already supported this, but in the migration over to libosmo-sigtran and to real 3GPP AoIP, this functionality got lost. We now create a UDP proxy socket. Any MGCP commands received via IPA from MSC (or rather: bsc_nat) are retransmitted to the MGW via UDP on this socket. Any responses back from the MGW received on the UDP socket are retransmitted back to MSC/bsc_nat as MGCP inside the IPA multiplex. Closes: OS#2536 Change-Id: I38ad8fa645c08900e0e1f1b4b96136bc6d96b3ab
2018-05-26 20:56:59 +00:00
int osmo_bsc_msc_init(struct bsc_msc_data *msc)
bsc: Add code responsible for connecting, reconnecting to the MSC Add the code that is forwarding data, from and to the MSC, also handling ping/pong timers and authentication. Hook it into the osmo_bsc. The code is only compile tested and ported from the on-waves/bsc-master branch.
2010-09-15 18:14:41 +00:00
{
Re-introduce support for IPA-encapsulated MGCP Old osmo-bsc-sccplite already supported this, but in the migration over to libosmo-sigtran and to real 3GPP AoIP, this functionality got lost. We now create a UDP proxy socket. Any MGCP commands received via IPA from MSC (or rather: bsc_nat) are retransmitted to the MGW via UDP on this socket. Any responses back from the MGW received on the UDP socket are retransmitted back to MSC/bsc_nat as MGCP inside the IPA multiplex. Closes: OS#2536 Change-Id: I38ad8fa645c08900e0e1f1b4b96136bc6d96b3ab
2018-05-26 20:56:59 +00:00
struct gsm_network *net = msc->network;
uint16_t mgw_port;
int rc;
if (net->mgw.conf->remote_port >= 0)
mgw_port = net->mgw.conf->remote_port;
else
mgw_port = MGCP_CLIENT_REMOTE_PORT_DEFAULT;
Fix creating MGCP proxy socket if MGW listens on an IPv6 address 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-08-31 18:09:26 +00:00
rc = osmo_sock_init2_ofd(&msc->mgcp_ipa.ofd, AF_UNSPEC, SOCK_DGRAM, IPPROTO_UDP,
Re-introduce support for IPA-encapsulated MGCP Old osmo-bsc-sccplite already supported this, but in the migration over to libosmo-sigtran and to real 3GPP AoIP, this functionality got lost. We now create a UDP proxy socket. Any MGCP commands received via IPA from MSC (or rather: bsc_nat) are retransmitted to the MGW via UDP on this socket. Any responses back from the MGW received on the UDP socket are retransmitted back to MSC/bsc_nat as MGCP inside the IPA multiplex. Closes: OS#2536 Change-Id: I38ad8fa645c08900e0e1f1b4b96136bc6d96b3ab
2018-05-26 20:56:59 +00:00
msc->mgcp_ipa.local_addr, msc->mgcp_ipa.local_port,
net->mgw.conf->remote_addr, mgw_port,
OSMO_SOCK_F_BIND | OSMO_SOCK_F_CONNECT);
if (rc < 0) {
LOGP(DMSC, LOGL_ERROR, "msc %u: Could not create/connect/bind MGCP proxy socket: %d\n",
msc->nr, rc);
return rc;
}
Implement AoIP, port to M3UA SIGTRAN (large addition and refactoring) This was originally a long series of commits converging to the final result seen in this patch. It does not make much sense to review the smaller steps' trial and error, we need to review this entire change as a whole. Implement AoIP in osmo-msc and osmo-bsc. Change over to the new libosmo-sigtran API with support for proper SCCP/M3UA/SCTP stacking, as mandated by 3GPP specifications for the IuCS and IuPS interfaces. From here on, a separate osmo-stp process is required for SCCP routing between OsmoBSC / OsmoHNBGW <-> OsmoMSC / OsmoSGSN jenkins.sh: build from libosmo-sccp and osmo-iuh master branches now for new M3UA SIGTRAN. Patch-by: pmaier, nhofmeyr, laforge Change-Id: I5ae4e05ee7c57cad341ea5e86af37c1f6b0ffa77
2017-04-09 10:32:51 +00:00
bsc: Add code responsible for connecting, reconnecting to the MSC Add the code that is forwarding data, from and to the MSC, also handling ping/pong timers and authentication. Hook it into the osmo_bsc. The code is only compile tested and ported from the on-waves/bsc-master branch.
2010-09-15 18:14:41 +00:00
return 0;
}
bsc: Prepare to have multiple MSC connections We now have a list of MSCs but in the code we will try to access the MSC with the nr 0.
2011-06-04 17:58:26 +00:00
cosmetic: rename struct osmo_msc_data to bsc_msc_data With the OsmoMSC program coming up, the name osmo_msc_data becomes even more confusing than it already is. Clearly indicate it as libbsc's data of a remote MSC by prefixing with bsc_. Also, the Osmocom community has in the meantime agreed to have the osmo_ prefix only in libosmocore, to avoid naming conflicts in case things are moved there. So while renaming anyway, also drop the osmo_ prefix. Change-Id: I0dfbcb7d1a579211180f71319982820d8700afab
2017-02-23 20:57:23 +00:00
struct bsc_msc_data *osmo_msc_data_find(struct gsm_network *net, int nr)
bsc: Prepare to have multiple MSC connections We now have a list of MSCs but in the code we will try to access the MSC with the nr 0.
2011-06-04 17:58:26 +00:00
{
cosmetic: rename struct osmo_msc_data to bsc_msc_data With the OsmoMSC program coming up, the name osmo_msc_data becomes even more confusing than it already is. Clearly indicate it as libbsc's data of a remote MSC by prefixing with bsc_. Also, the Osmocom community has in the meantime agreed to have the osmo_ prefix only in libosmocore, to avoid naming conflicts in case things are moved there. So while renaming anyway, also drop the osmo_ prefix. Change-Id: I0dfbcb7d1a579211180f71319982820d8700afab
2017-02-23 20:57:23 +00:00
struct bsc_msc_data *msc_data;
bsc: Prepare to have multiple MSC connections We now have a list of MSCs but in the code we will try to access the MSC with the nr 0.
2011-06-04 17:58:26 +00:00
flatten: move network->bsc_data->* to network->* The separate struct osmo_bsc_data is like another separate struct gsm_network for no reason. It is labeled "per-BSC data". These days, all of this is a single BSC and there will not be different sets of osmo_bsc_data. Drop struct osmo_bsc_data, move its members directly into gsm_network. Some places tested 'if (net->bsc_data)', which is always true. Modify those cases to rather do checks like 'if (net->rf_ctrl)', which are also always true AFAICT, to keep as much unmodified logic as possible in this patch. Change-Id: Ic7ae65e3b36e6e4b279eb01ad594f1226b5929e0
2020-05-26 10:41:18 +00:00
llist_for_each_entry(msc_data, &net->mscs, entry)
bsc: Prepare to have multiple MSC connections We now have a list of MSCs but in the code we will try to access the MSC with the nr 0.
2011-06-04 17:58:26 +00:00
if (msc_data->nr == nr)
return msc_data;
return NULL;
}
cosmetic: rename struct osmo_msc_data to bsc_msc_data With the OsmoMSC program coming up, the name osmo_msc_data becomes even more confusing than it already is. Clearly indicate it as libbsc's data of a remote MSC by prefixing with bsc_. Also, the Osmocom community has in the meantime agreed to have the osmo_ prefix only in libosmocore, to avoid naming conflicts in case things are moved there. So while renaming anyway, also drop the osmo_ prefix. Change-Id: I0dfbcb7d1a579211180f71319982820d8700afab
2017-02-23 20:57:23 +00:00
struct bsc_msc_data *osmo_msc_data_alloc(struct gsm_network *net, int nr)
bsc: Prepare to have multiple MSC connections We now have a list of MSCs but in the code we will try to access the MSC with the nr 0.
2011-06-04 17:58:26 +00:00
{
cosmetic: rename struct osmo_msc_data to bsc_msc_data With the OsmoMSC program coming up, the name osmo_msc_data becomes even more confusing than it already is. Clearly indicate it as libbsc's data of a remote MSC by prefixing with bsc_. Also, the Osmocom community has in the meantime agreed to have the osmo_ prefix only in libosmocore, to avoid naming conflicts in case things are moved there. So while renaming anyway, also drop the osmo_ prefix. Change-Id: I0dfbcb7d1a579211180f71319982820d8700afab
2017-02-23 20:57:23 +00:00
struct bsc_msc_data *msc_data;
osmo_bsc_msc: Set reasonable codec list defaults When the user sets no codec-list in the msc node, the configuration will end up with an empty codec list. This is a useless configuration. There should be a sane default setting. - Set all possible codecs as default for codec-list Change-Id: I3749a65828c788f38c22f0a5314533f4516da3ed Related: OS#3625
2018-10-05 08:29:53 +00:00
unsigned int i;
bsc: Prepare to have multiple MSC connections We now have a list of MSCs but in the code we will try to access the MSC with the nr 0.
2011-06-04 17:58:26 +00:00
/* check if there is already one */
msc_data = osmo_msc_data_find(net, nr);
if (msc_data)
return msc_data;
cosmetic: rename struct osmo_msc_data to bsc_msc_data With the OsmoMSC program coming up, the name osmo_msc_data becomes even more confusing than it already is. Clearly indicate it as libbsc's data of a remote MSC by prefixing with bsc_. Also, the Osmocom community has in the meantime agreed to have the osmo_ prefix only in libosmocore, to avoid naming conflicts in case things are moved there. So while renaming anyway, also drop the osmo_ prefix. Change-Id: I0dfbcb7d1a579211180f71319982820d8700afab
2017-02-23 20:57:23 +00:00
msc_data = talloc_zero(net, struct bsc_msc_data);
bsc: Prepare to have multiple MSC connections We now have a list of MSCs but in the code we will try to access the MSC with the nr 0.
2011-06-04 17:58:26 +00:00
if (!msc_data)
return NULL;
stats: Add a stats gauge for the MSC links count. Change-Id: Ibe4b29056ba704a27b925cfdba49f343ee34f428
2020-05-07 13:41:26 +00:00
/* init statistics */
msc_data->msc_ctrs = rate_ctr_group_alloc(net, &msc_ctrg_desc, nr);
if (!msc_data->msc_ctrs) {
talloc_free(msc_data);
return NULL;
}
msc_data->msc_statg = osmo_stat_item_group_alloc(net, &msc_statg_desc, nr);
if (!msc_data->msc_statg) {
rate_ctr_group_free(msc_data->msc_ctrs);
talloc_free(msc_data);
return NULL;
}
flatten: move network->bsc_data->* to network->* The separate struct osmo_bsc_data is like another separate struct gsm_network for no reason. It is labeled "per-BSC data". These days, all of this is a single BSC and there will not be different sets of osmo_bsc_data. Drop struct osmo_bsc_data, move its members directly into gsm_network. Some places tested 'if (net->bsc_data)', which is always true. Modify those cases to rather do checks like 'if (net->rf_ctrl)', which are also always true AFAICT, to keep as much unmodified logic as possible in this patch. Change-Id: Ic7ae65e3b36e6e4b279eb01ad594f1226b5929e0
2020-05-26 10:41:18 +00:00
llist_add_tail(&msc_data->entry, &net->mscs);
bsc: Prepare to have multiple MSC connections We now have a list of MSCs but in the code we will try to access the MSC with the nr 0.
2011-06-04 17:58:26 +00:00
/* Init back pointer */
msc_data->network = net;
implement support for 3-digit MNC with leading zeros Add 3-digit flags and use the new RAI and LAI API from libosmocore throughout the code base to be able to handle an MNC < 100 that has three digits (leading zeros). The changes to abis_test and gsm0408_test show that this code now handles 3-digit MNC correctly, by not dropping the leading zero as 0xf in the encoded PLMN. Re-implement CTRL commands 'mcc', 'mnc' and 'mcc-mnc-apply' to preserve the presence of the third digit of the MNC. Always reply with all leading zeros. Adjust the expected results in ctrl_test_runner.py, to show that it works. In VTY and CTRL, the parsing of MCC and MNC is inherently made stricter by use of osmo_{mcc,mnc}_from_str() -- they will no longer allow surplus characters and detect errno returned by strtol() (in contrast to atoi()). Depends: Id2240f7f518494c9df6c8bda52c0d5092f90f221 (libosmocore), Ib7176b1d65a03b76f41f94bc9d3293a8a07d24c6 (libosmocore), I020a4f11791c61742a3d795f782805f7b7e8733e (libosmocore) Change-Id: I8e722103344186fde118b26d8353db95a4581daa
2018-03-05 01:09:40 +00:00
msc_data->core_plmn = (struct osmo_plmn_id){
.mcc = GSM_MCC_MNC_INVALID,
.mnc = GSM_MCC_MNC_INVALID,
};
bsc: Prepare to have multiple MSC connections We now have a list of MSCs but in the code we will try to access the MSC with the nr 0.
2011-06-04 17:58:26 +00:00
msc_data->nr = nr;
bsc: Look for CM Service Requests with emergency cause Look for emergency calls and send them to a MSC that can handle them properly.
2011-06-08 17:25:38 +00:00
msc_data->allow_emerg = 1;
vty: Permit selection of other ASP protocol than M3UA We used to have hard-coded M3UA. Let's allow the user to configure this per MSC using a new "asp-protocol (m3ua|sua|ipa)" VTY command. For SUA this should just work 1:1 without any trouble. For IPA, this of course only changes the underlying transport without reflecting the various differences in terms of BSSMAP ASSIGNMENT, MGCP handling, etc. Change-Id: I0800c709e574cedd7f5dd98be81c78782245cd13 Related: OS#2544
2018-05-25 13:51:05 +00:00
msc_data->a.asp_proto = OSMO_SS7_ASP_PROT_M3UA;
bsc: Prepare to have multiple MSC connections We now have a list of MSCs but in the code we will try to access the MSC with the nr 0.
2011-06-04 17:58:26 +00:00
audio: Make the BSC handle the new mr_config request of the BSC API Handle the mr_config request and set the AMR multirate config for the given MSC. Initialize the mr_config with the AMR5.9 default we have been using until now.
2011-08-06 05:00:52 +00:00
/* Defaults for the audio setup */
msc_data->amr_conf.m5_90 = 1;
Make sure to default to AMR octet-aligned mode In Change-Id If6d40b2407b87aad2227ea7f15533ef01a3771b3 we introduced the support for both octet-aligned and bandwidth-efficient mode, and added a related VTY option about it. However, we accidentially also changed the default behavior. Without any explicit configuration, we should behave just like we behaved all those years before: Continue with octet-aligned mode. Change-Id: I8b6fd8bec05b35d84ad16275d84f9d363e238d2b Closes: OS#4002
2019-05-15 12:57:32 +00:00
msc_data->amr_octet_aligned = true;
audio: Make the BSC handle the new mr_config request of the BSC API Handle the mr_config request and set the AMR multirate config for the given MSC. Initialize the mr_config with the AMR5.9 default we have been using until now.
2011-08-06 05:00:52 +00:00
osmo_bsc_msc: Set reasonable codec list defaults When the user sets no codec-list in the msc node, the configuration will end up with an empty codec list. This is a useless configuration. There should be a sane default setting. - Set all possible codecs as default for codec-list Change-Id: I3749a65828c788f38c22f0a5314533f4516da3ed Related: OS#3625
2018-10-05 08:29:53 +00:00
/* Allow the full set of possible codecs by default */
msc_data->audio_length = 5;
msc_data->audio_support =
talloc_zero_array(msc_data, struct gsm_audio_support *,
msc_data->audio_length);
for (i = 0; i < msc_data->audio_length; i++) {
msc_data->audio_support[i] =
talloc_zero(msc_data->audio_support,
struct gsm_audio_support);
}
msc_data->audio_support[0]->ver = 1;
msc_data->audio_support[0]->hr = 0;
msc_data->audio_support[1]->ver = 1;
msc_data->audio_support[1]->hr = 1;
msc_data->audio_support[2]->ver = 2;
msc_data->audio_support[2]->hr = 0;
msc_data->audio_support[3]->ver = 3;
msc_data->audio_support[3]->hr = 0;
msc_data->audio_support[4]->ver = 3;
msc_data->audio_support[4]->hr = 1;
Use OSMO_FD_* instead of deprecated BSC_FD_* New define is available since libosmocore 1.1.0, and we already require 1.3.0, so no need to update dependenices. Let's change it to avoid people re-using old BSC_FD_* symbols when copy-pasting somewhere else. Change-Id: Ia5a656567d212fa265aef1375d714d0c5fee5dd6
2020-05-09 17:17:12 +00:00
osmo_fd_setup(&msc_data->mgcp_ipa.ofd, -1, OSMO_FD_READ, &bsc_sccplite_mgcp_proxy_cb, msc_data, 0);
Fix creating MGCP proxy socket if MGW listens on an IPv6 address 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-08-31 18:09:26 +00:00
msc_data->mgcp_ipa.local_addr = NULL; /* = INADDR(6)_ANY */
Re-introduce support for IPA-encapsulated MGCP Old osmo-bsc-sccplite already supported this, but in the migration over to libosmo-sigtran and to real 3GPP AoIP, this functionality got lost. We now create a UDP proxy socket. Any MGCP commands received via IPA from MSC (or rather: bsc_nat) are retransmitted to the MGW via UDP on this socket. Any responses back from the MGW received on the UDP socket are retransmitted back to MSC/bsc_nat as MGCP inside the IPA multiplex. Closes: OS#2536 Change-Id: I38ad8fa645c08900e0e1f1b4b96136bc6d96b3ab
2018-05-26 20:56:59 +00:00
msc_data->mgcp_ipa.local_port = 0; /* dynamic */
MSC pooling: make NRI mappings VTY configurable Use the osmo_nri_ranges API to manage each MSC's NRI ranges by VTY configuration. Change-Id: I6c251f2744d7be26fc4ad74adefc96a6a3fe08b0
2020-05-26 01:58:14 +00:00
msc_data->nri_ranges = osmo_nri_ranges_alloc(msc_data);
MSC pooling: add 'no allow-attach' for MSC off-loading As in 3GPP TS 23.236, to offload an MSC, the BSC must be able to avoid attaching new subscribers to it: 4.5a.1: "UEs being moved from one CN node are stopped from registering to the same CN node again by an O&M command in BSCs and RNCs connected to the pool." Change-Id: I6249201c15d0f6565aca643c21d2375c9ca58584
2020-06-11 00:36:29 +00:00
msc_data->allow_attach = true;
MSC pooling: make NRI mappings VTY configurable Use the osmo_nri_ranges API to manage each MSC's NRI ranges by VTY configuration. Change-Id: I6c251f2744d7be26fc4ad74adefc96a6a3fe08b0
2020-05-26 01:58:14 +00:00
bsc: Prepare to have multiple MSC connections We now have a list of MSCs but in the code we will try to access the MSC with the nr 0.
2011-06-04 17:58:26 +00:00
return msc_data;
}
Implement AoIP, port to M3UA SIGTRAN (large addition and refactoring) This was originally a long series of commits converging to the final result seen in this patch. It does not make much sense to review the smaller steps' trial and error, we need to review this entire change as a whole. Implement AoIP in osmo-msc and osmo-bsc. Change over to the new libosmo-sigtran API with support for proper SCCP/M3UA/SCTP stacking, as mandated by 3GPP specifications for the IuCS and IuPS interfaces. From here on, a separate osmo-stp process is required for SCCP routing between OsmoBSC / OsmoHNBGW <-> OsmoMSC / OsmoSGSN jenkins.sh: build from libosmo-sccp and osmo-iuh master branches now for new M3UA SIGTRAN. Patch-by: pmaier, nhofmeyr, laforge Change-Id: I5ae4e05ee7c57cad341ea5e86af37c1f6b0ffa77
2017-04-09 10:32:51 +00:00
Move msc related code from gsm_data to bsc_msc This way ipaccess utils can be built without requiring libosmo-sigtran. Change-Id: I508188896be58ddc3bd4e9c3c661c258c06866f4
2019-03-12 17:55:57 +00:00
struct osmo_cell_global_id *cgi_for_msc(struct bsc_msc_data *msc, struct gsm_bts *bts)
{
static struct osmo_cell_global_id cgi;
fix crashes due to OSMO_ASSERT(conn->lchan) 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
2020-06-18 15:29:56 +00:00
if (!bts)
return NULL;
Move msc related code from gsm_data to bsc_msc This way ipaccess utils can be built without requiring libosmo-sigtran. Change-Id: I508188896be58ddc3bd4e9c3c661c258c06866f4
2019-03-12 17:55:57 +00:00
cgi.lai.plmn = msc->network->plmn;
if (msc->core_plmn.mcc != GSM_MCC_MNC_INVALID)
cgi.lai.plmn.mcc = msc->core_plmn.mcc;
if (msc->core_plmn.mnc != GSM_MCC_MNC_INVALID) {
cgi.lai.plmn.mnc = msc->core_plmn.mnc;
cgi.lai.plmn.mnc_3_digits = msc->core_plmn.mnc_3_digits;
}
drop features 'core-location-area-code' and 'core-cell-identity' This feature apparently assigned a fixed LAC and CI to a specific MSC, but looking at the implementation was obviously not useful. Keep the vty commands for legacy compat, now without effect besides logging an error via vty_out(). Related: OS#4751 Change-Id: I6bee704e7e5d5b6b86473323bae1fa9fce9241ee
2020-10-15 17:17:10 +00:00
cgi.lai.lac = bts->location_area_code;
cgi.cell_identity = bts->cell_identity;
Move msc related code from gsm_data to bsc_msc This way ipaccess utils can be built without requiring libosmo-sigtran. Change-Id: I508188896be58ddc3bd4e9c3c661c258c06866f4
2019-03-12 17:55:57 +00:00
return &cgi;
}