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/bssmap_reset.c

264 lines
7.5 KiB
C
Raw Normal View History

BSSMAP RESET: generalize a_reset FSM Separate the a_reset FSM implementation from BSSMAP and MSC specifics, so that it can be re-used on the Lb interface. Move the FSM implementation to bssmap_reset.c and tweak, to match common practices we have generally established in our osmo_fsm implementations. Keep a_reset.h and a_reset.c and redirect to bssmap_reset.c. A difficulty is setting a proper logging category: the FSM definition allows only one fixed logging category for FSM state transitions and events. Ideally, the BSSMAP reset fsm would log on DMSC, and the BSSMAP-LE reset fsm would log on DLCS. Since that is not possible, introduce a separate DRESET logging category. This in fact matches an item on my wishlist, because if a given MSC is configured but currently not connected, the previous RESET FSM would continuously "spam" log LOGL_NOTICE messages indicating that it is resending RESET, and I often want to silence those messages without silencing the entire DMSC category. This is now easily possible by setting DRESET logging to LOGL_ERROR. There is additional "link up" / "link lost" logging on DMSC, so all interesting info is still visible on DMSC. Change-Id: Ib3c3a163186c40a93be0dea666230431172136df
2020-10-04 19:32:52 +00:00
/* (C) 2020 by sysmocom s.f.m.c. GmbH <info@sysmocom.de>
* All Rights Reserved
*
* Authors: Philipp Maier, Neels Hofmeyr
*
* This program is free software; you can redistribute it and/or modify
* 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
* (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
* GNU Affero General Public License for more details.
*
* 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/>.
*
*/
#include <osmocom/core/fsm.h>
#include <osmocom/core/tdef.h>
#include <osmocom/bsc/debug.h>
#include <osmocom/bsc/bssmap_reset.h>
#include <osmocom/bsc/gsm_data.h>
static struct osmo_fsm bssmap_reset_fsm;
enum bssmap_reset_fsm_state {
BSSMAP_RESET_ST_DISC,
BSSMAP_RESET_ST_CONN,
};
static const struct value_string bssmap_reset_fsm_event_names[] = {
BSSMAP RESET: move RESET-ACK into reset fsm The Lb interface will need the same RESET-ACK logic. Change-Id: Idf4682319a0af5665e867dbc0515d1fe343d9daf
2020-10-09 15:18:29 +00:00
OSMO_VALUE_STRING(BSSMAP_RESET_EV_RX_RESET),
BSSMAP RESET: generalize a_reset FSM Separate the a_reset FSM implementation from BSSMAP and MSC specifics, so that it can be re-used on the Lb interface. Move the FSM implementation to bssmap_reset.c and tweak, to match common practices we have generally established in our osmo_fsm implementations. Keep a_reset.h and a_reset.c and redirect to bssmap_reset.c. A difficulty is setting a proper logging category: the FSM definition allows only one fixed logging category for FSM state transitions and events. Ideally, the BSSMAP reset fsm would log on DMSC, and the BSSMAP-LE reset fsm would log on DLCS. Since that is not possible, introduce a separate DRESET logging category. This in fact matches an item on my wishlist, because if a given MSC is configured but currently not connected, the previous RESET FSM would continuously "spam" log LOGL_NOTICE messages indicating that it is resending RESET, and I often want to silence those messages without silencing the entire DMSC category. This is now easily possible by setting DRESET logging to LOGL_ERROR. There is additional "link up" / "link lost" logging on DMSC, so all interesting info is still visible on DMSC. Change-Id: Ib3c3a163186c40a93be0dea666230431172136df
2020-10-04 19:32:52 +00:00
OSMO_VALUE_STRING(BSSMAP_RESET_EV_RX_RESET_ACK),
OSMO_VALUE_STRING(BSSMAP_RESET_EV_CONN_CFM_FAILURE),
OSMO_VALUE_STRING(BSSMAP_RESET_EV_CONN_CFM_SUCCESS),
{}
};
static const struct osmo_tdef_state_timeout bssmap_reset_timeouts[32] = {
[BSSMAP_RESET_ST_DISC] = { .T = 4 },
};
#define bssmap_reset_fsm_state_chg(FI, STATE) \
osmo_tdef_fsm_inst_state_chg(FI, STATE, \
bssmap_reset_timeouts, \
(bsc_gsmnet)->T_defs, \
bssmap_reset: make T4 user configurable The timer (T4) that controls the re-sending of the BSSMAP RESET can not be changed via the VTY, althrough it is defined via a tdef struct. Lets add a description along with default values to make it configurable via the VTY. Change-Id: I1fb5699220ab8a643a168567a89c6f381fe433a7 Related: SYS#5796
2022-02-08 10:41:55 +00:00
-1)
BSSMAP RESET: generalize a_reset FSM Separate the a_reset FSM implementation from BSSMAP and MSC specifics, so that it can be re-used on the Lb interface. Move the FSM implementation to bssmap_reset.c and tweak, to match common practices we have generally established in our osmo_fsm implementations. Keep a_reset.h and a_reset.c and redirect to bssmap_reset.c. A difficulty is setting a proper logging category: the FSM definition allows only one fixed logging category for FSM state transitions and events. Ideally, the BSSMAP reset fsm would log on DMSC, and the BSSMAP-LE reset fsm would log on DLCS. Since that is not possible, introduce a separate DRESET logging category. This in fact matches an item on my wishlist, because if a given MSC is configured but currently not connected, the previous RESET FSM would continuously "spam" log LOGL_NOTICE messages indicating that it is resending RESET, and I often want to silence those messages without silencing the entire DMSC category. This is now easily possible by setting DRESET logging to LOGL_ERROR. There is additional "link up" / "link lost" logging on DMSC, so all interesting info is still visible on DMSC. Change-Id: Ib3c3a163186c40a93be0dea666230431172136df
2020-10-04 19:32:52 +00:00
struct bssmap_reset *bssmap_reset_alloc(void *ctx, const char *label, const struct bssmap_reset_cfg *cfg)
{
struct bssmap_reset *bssmap_reset;
struct osmo_fsm_inst *fi;
fi = osmo_fsm_inst_alloc(&bssmap_reset_fsm, ctx, NULL, LOGL_DEBUG, label);
OSMO_ASSERT(fi);
bssmap_reset = talloc_zero(fi, struct bssmap_reset);
OSMO_ASSERT(bssmap_reset);
*bssmap_reset = (struct bssmap_reset){
.fi = fi,
.cfg = *cfg,
};
fi->priv = bssmap_reset;
/* Immediately (1ms) kick off reset sending mechanism */
osmo_fsm_inst_state_chg_ms(fi, BSSMAP_RESET_ST_DISC, 1, 0);
return bssmap_reset;
}
Lb: stop RESET FSM when sccp_user is unbound A crash was reported in bssmap_le_tx_reset() sending a RESET with sccp_user == NULL. Looking at the issue I noticed that when the sccp_user is torn down, the RESET FSM should also be terminated. Add bssmap_reset_term_and_free() to the generic RESET FSM implementation and call from lb_stop() before sccp_user is set to NULL. Related: OS#5134 Change-Id: If412ef990fcdde8ff88098a5169e86f05cd1c7f0
2021-04-27 15:26:34 +00:00
void bssmap_reset_term_and_free(struct bssmap_reset *bssmap_reset)
{
if (!bssmap_reset)
return;
osmo_fsm_inst_term(bssmap_reset->fi, OSMO_FSM_TERM_REQUEST, NULL);
talloc_free(bssmap_reset);
}
BSSMAP RESET: generalize a_reset FSM Separate the a_reset FSM implementation from BSSMAP and MSC specifics, so that it can be re-used on the Lb interface. Move the FSM implementation to bssmap_reset.c and tweak, to match common practices we have generally established in our osmo_fsm implementations. Keep a_reset.h and a_reset.c and redirect to bssmap_reset.c. A difficulty is setting a proper logging category: the FSM definition allows only one fixed logging category for FSM state transitions and events. Ideally, the BSSMAP reset fsm would log on DMSC, and the BSSMAP-LE reset fsm would log on DLCS. Since that is not possible, introduce a separate DRESET logging category. This in fact matches an item on my wishlist, because if a given MSC is configured but currently not connected, the previous RESET FSM would continuously "spam" log LOGL_NOTICE messages indicating that it is resending RESET, and I often want to silence those messages without silencing the entire DMSC category. This is now easily possible by setting DRESET logging to LOGL_ERROR. There is additional "link up" / "link lost" logging on DMSC, so all interesting info is still visible on DMSC. Change-Id: Ib3c3a163186c40a93be0dea666230431172136df
2020-10-04 19:32:52 +00:00
static void link_up(struct bssmap_reset *bssmap_reset)
{
LOGPFSML(bssmap_reset->fi, LOGL_NOTICE, "link up\n");
bssmap_reset->conn_cfm_failures = 0;
if (bssmap_reset->cfg.ops.link_up)
bssmap_reset->cfg.ops.link_up(bssmap_reset->cfg.data);
}
static void link_lost(struct bssmap_reset *bssmap_reset)
{
LOGPFSML(bssmap_reset->fi, LOGL_NOTICE, "link lost\n");
if (bssmap_reset->cfg.ops.link_lost)
bssmap_reset->cfg.ops.link_lost(bssmap_reset->cfg.data);
}
static void tx_reset(struct bssmap_reset *bssmap_reset)
{
if (bssmap_reset->cfg.ops.tx_reset)
bssmap_reset->cfg.ops.tx_reset(bssmap_reset->cfg.data);
}
BSSMAP RESET: move RESET-ACK into reset fsm The Lb interface will need the same RESET-ACK logic. Change-Id: Idf4682319a0af5665e867dbc0515d1fe343d9daf
2020-10-09 15:18:29 +00:00
static void tx_reset_ack(struct bssmap_reset *bssmap_reset)
{
if (bssmap_reset->cfg.ops.tx_reset_ack)
bssmap_reset->cfg.ops.tx_reset_ack(bssmap_reset->cfg.data);
}
BSSMAP RESET: generalize a_reset FSM Separate the a_reset FSM implementation from BSSMAP and MSC specifics, so that it can be re-used on the Lb interface. Move the FSM implementation to bssmap_reset.c and tweak, to match common practices we have generally established in our osmo_fsm implementations. Keep a_reset.h and a_reset.c and redirect to bssmap_reset.c. A difficulty is setting a proper logging category: the FSM definition allows only one fixed logging category for FSM state transitions and events. Ideally, the BSSMAP reset fsm would log on DMSC, and the BSSMAP-LE reset fsm would log on DLCS. Since that is not possible, introduce a separate DRESET logging category. This in fact matches an item on my wishlist, because if a given MSC is configured but currently not connected, the previous RESET FSM would continuously "spam" log LOGL_NOTICE messages indicating that it is resending RESET, and I often want to silence those messages without silencing the entire DMSC category. This is now easily possible by setting DRESET logging to LOGL_ERROR. There is additional "link up" / "link lost" logging on DMSC, so all interesting info is still visible on DMSC. Change-Id: Ib3c3a163186c40a93be0dea666230431172136df
2020-10-04 19:32:52 +00:00
static void bssmap_reset_disc_onenter(struct osmo_fsm_inst *fi, uint32_t prev_state)
{
struct bssmap_reset *bssmap_reset = (struct bssmap_reset*)fi->priv;
if (prev_state == BSSMAP_RESET_ST_CONN)
link_lost(bssmap_reset);
}
static void bssmap_reset_disc_action(struct osmo_fsm_inst *fi, uint32_t event, void *data)
{
BSSMAP RESET: move RESET-ACK into reset fsm The Lb interface will need the same RESET-ACK logic. Change-Id: Idf4682319a0af5665e867dbc0515d1fe343d9daf
2020-10-09 15:18:29 +00:00
struct bssmap_reset *bssmap_reset = (struct bssmap_reset*)fi->priv;
switch (event) {
case BSSMAP_RESET_EV_RX_RESET:
tx_reset_ack(bssmap_reset);
bssmap_reset_fsm_state_chg(fi, BSSMAP_RESET_ST_CONN);
break;
case BSSMAP_RESET_EV_RX_RESET_ACK:
bssmap_reset_fsm_state_chg(fi, BSSMAP_RESET_ST_CONN);
break;
BSSMAP RESET: also accept conn cfm events during ST_DISC We don't really expect connection attempts during ST_DISC, but if the user happens to dispatch those events for whatever obscure reasons, treat them instead of erroring about an unallowed event. Change-Id: Ic7c60a40ff25ae647ee659259dfea769bc4592e4
2020-10-09 15:24:50 +00:00
case BSSMAP_RESET_EV_CONN_CFM_FAILURE:
/* ignore */
break;
case BSSMAP_RESET_EV_CONN_CFM_SUCCESS:
/* A connection succeeded before we managed to do a RESET handshake?
* Then the calling code is not taking care to check bssmap_reset_is_conn_ready().
*/
LOGPFSML(fi, LOGL_ERROR, "Connection success confirmed, but we have not seen a RESET-ACK; bug?\n");
break;
BSSMAP RESET: move RESET-ACK into reset fsm The Lb interface will need the same RESET-ACK logic. Change-Id: Idf4682319a0af5665e867dbc0515d1fe343d9daf
2020-10-09 15:18:29 +00:00
default:
OSMO_ASSERT(false);
}
BSSMAP RESET: generalize a_reset FSM Separate the a_reset FSM implementation from BSSMAP and MSC specifics, so that it can be re-used on the Lb interface. Move the FSM implementation to bssmap_reset.c and tweak, to match common practices we have generally established in our osmo_fsm implementations. Keep a_reset.h and a_reset.c and redirect to bssmap_reset.c. A difficulty is setting a proper logging category: the FSM definition allows only one fixed logging category for FSM state transitions and events. Ideally, the BSSMAP reset fsm would log on DMSC, and the BSSMAP-LE reset fsm would log on DLCS. Since that is not possible, introduce a separate DRESET logging category. This in fact matches an item on my wishlist, because if a given MSC is configured but currently not connected, the previous RESET FSM would continuously "spam" log LOGL_NOTICE messages indicating that it is resending RESET, and I often want to silence those messages without silencing the entire DMSC category. This is now easily possible by setting DRESET logging to LOGL_ERROR. There is additional "link up" / "link lost" logging on DMSC, so all interesting info is still visible on DMSC. Change-Id: Ib3c3a163186c40a93be0dea666230431172136df
2020-10-04 19:32:52 +00:00
}
static void bssmap_reset_conn_onenter(struct osmo_fsm_inst *fi, uint32_t prev_state)
{
struct bssmap_reset *bssmap_reset = (struct bssmap_reset*)fi->priv;
if (prev_state != BSSMAP_RESET_ST_CONN)
link_up(bssmap_reset);
}
static void bssmap_reset_conn_action(struct osmo_fsm_inst *fi, uint32_t event, void *data)
{
struct bssmap_reset *bssmap_reset = (struct bssmap_reset*)fi->priv;
switch (event) {
BSSMAP RESET: move RESET-ACK into reset fsm The Lb interface will need the same RESET-ACK logic. Change-Id: Idf4682319a0af5665e867dbc0515d1fe343d9daf
2020-10-09 15:18:29 +00:00
case BSSMAP_RESET_EV_RX_RESET:
/* We were connected, but the remote side has restarted. */
link_lost(bssmap_reset);
tx_reset_ack(bssmap_reset);
link_up(bssmap_reset);
break;
BSSMAP RESET: generalize a_reset FSM Separate the a_reset FSM implementation from BSSMAP and MSC specifics, so that it can be re-used on the Lb interface. Move the FSM implementation to bssmap_reset.c and tweak, to match common practices we have generally established in our osmo_fsm implementations. Keep a_reset.h and a_reset.c and redirect to bssmap_reset.c. A difficulty is setting a proper logging category: the FSM definition allows only one fixed logging category for FSM state transitions and events. Ideally, the BSSMAP reset fsm would log on DMSC, and the BSSMAP-LE reset fsm would log on DLCS. Since that is not possible, introduce a separate DRESET logging category. This in fact matches an item on my wishlist, because if a given MSC is configured but currently not connected, the previous RESET FSM would continuously "spam" log LOGL_NOTICE messages indicating that it is resending RESET, and I often want to silence those messages without silencing the entire DMSC category. This is now easily possible by setting DRESET logging to LOGL_ERROR. There is additional "link up" / "link lost" logging on DMSC, so all interesting info is still visible on DMSC. Change-Id: Ib3c3a163186c40a93be0dea666230431172136df
2020-10-04 19:32:52 +00:00
case BSSMAP_RESET_EV_RX_RESET_ACK:
BSSMAP RESET: move RESET-ACK into reset fsm The Lb interface will need the same RESET-ACK logic. Change-Id: Idf4682319a0af5665e867dbc0515d1fe343d9daf
2020-10-09 15:18:29 +00:00
LOGPFSML(fi, LOGL_INFO, "Link is already up, ignoring RESET ACK\n");
BSSMAP RESET: generalize a_reset FSM Separate the a_reset FSM implementation from BSSMAP and MSC specifics, so that it can be re-used on the Lb interface. Move the FSM implementation to bssmap_reset.c and tweak, to match common practices we have generally established in our osmo_fsm implementations. Keep a_reset.h and a_reset.c and redirect to bssmap_reset.c. A difficulty is setting a proper logging category: the FSM definition allows only one fixed logging category for FSM state transitions and events. Ideally, the BSSMAP reset fsm would log on DMSC, and the BSSMAP-LE reset fsm would log on DLCS. Since that is not possible, introduce a separate DRESET logging category. This in fact matches an item on my wishlist, because if a given MSC is configured but currently not connected, the previous RESET FSM would continuously "spam" log LOGL_NOTICE messages indicating that it is resending RESET, and I often want to silence those messages without silencing the entire DMSC category. This is now easily possible by setting DRESET logging to LOGL_ERROR. There is additional "link up" / "link lost" logging on DMSC, so all interesting info is still visible on DMSC. Change-Id: Ib3c3a163186c40a93be0dea666230431172136df
2020-10-04 19:32:52 +00:00
break;
case BSSMAP_RESET_EV_CONN_CFM_FAILURE:
bssmap_reset->conn_cfm_failures++;
if (bssmap_reset->conn_cfm_failures > bssmap_reset->cfg.conn_cfm_failure_threshold)
bssmap_reset_fsm_state_chg(fi, BSSMAP_RESET_ST_DISC);
break;
case BSSMAP_RESET_EV_CONN_CFM_SUCCESS:
bssmap_reset->conn_cfm_failures = 0;
break;
default:
OSMO_ASSERT(false);
}
}
static int bssmap_reset_fsm_timer_cb(struct osmo_fsm_inst *fi)
{
struct bssmap_reset *bssmap_reset = (struct bssmap_reset*)fi->priv;
tx_reset(bssmap_reset);
/* (re-)enter disconnect state to resend RESET after timeout. */
bssmap_reset_fsm_state_chg(fi, BSSMAP_RESET_ST_DISC);
/* Return 0 to not terminate the fsm */
return 0;
}
#define S(x) (1 << (x))
static struct osmo_fsm_state bssmap_reset_fsm_states[] = {
[BSSMAP_RESET_ST_DISC] = {
vty: show mscs: add BSSMAP state New output: OsmoBSC> show mscs MSC 0: RI=SSN_PC,PC=0.23.3,SSN=BSSAP <-> RI=SSN_PC,PC=0.23.1,SSN=BSSAP ASP protocol: m3ua BSSMAP state: CONNECTED Closes: OS#6741 Change-Id: I23ddba7d935e5cc5dae041458207c674ccb9d013
2024-01-16 18:01:54 +00:00
.name = "DISCONNECTED",
BSSMAP RESET: generalize a_reset FSM Separate the a_reset FSM implementation from BSSMAP and MSC specifics, so that it can be re-used on the Lb interface. Move the FSM implementation to bssmap_reset.c and tweak, to match common practices we have generally established in our osmo_fsm implementations. Keep a_reset.h and a_reset.c and redirect to bssmap_reset.c. A difficulty is setting a proper logging category: the FSM definition allows only one fixed logging category for FSM state transitions and events. Ideally, the BSSMAP reset fsm would log on DMSC, and the BSSMAP-LE reset fsm would log on DLCS. Since that is not possible, introduce a separate DRESET logging category. This in fact matches an item on my wishlist, because if a given MSC is configured but currently not connected, the previous RESET FSM would continuously "spam" log LOGL_NOTICE messages indicating that it is resending RESET, and I often want to silence those messages without silencing the entire DMSC category. This is now easily possible by setting DRESET logging to LOGL_ERROR. There is additional "link up" / "link lost" logging on DMSC, so all interesting info is still visible on DMSC. Change-Id: Ib3c3a163186c40a93be0dea666230431172136df
2020-10-04 19:32:52 +00:00
.in_event_mask = 0
BSSMAP RESET: move RESET-ACK into reset fsm The Lb interface will need the same RESET-ACK logic. Change-Id: Idf4682319a0af5665e867dbc0515d1fe343d9daf
2020-10-09 15:18:29 +00:00
| S(BSSMAP_RESET_EV_RX_RESET)
BSSMAP RESET: generalize a_reset FSM Separate the a_reset FSM implementation from BSSMAP and MSC specifics, so that it can be re-used on the Lb interface. Move the FSM implementation to bssmap_reset.c and tweak, to match common practices we have generally established in our osmo_fsm implementations. Keep a_reset.h and a_reset.c and redirect to bssmap_reset.c. A difficulty is setting a proper logging category: the FSM definition allows only one fixed logging category for FSM state transitions and events. Ideally, the BSSMAP reset fsm would log on DMSC, and the BSSMAP-LE reset fsm would log on DLCS. Since that is not possible, introduce a separate DRESET logging category. This in fact matches an item on my wishlist, because if a given MSC is configured but currently not connected, the previous RESET FSM would continuously "spam" log LOGL_NOTICE messages indicating that it is resending RESET, and I often want to silence those messages without silencing the entire DMSC category. This is now easily possible by setting DRESET logging to LOGL_ERROR. There is additional "link up" / "link lost" logging on DMSC, so all interesting info is still visible on DMSC. Change-Id: Ib3c3a163186c40a93be0dea666230431172136df
2020-10-04 19:32:52 +00:00
| S(BSSMAP_RESET_EV_RX_RESET_ACK)
BSSMAP RESET: also accept conn cfm events during ST_DISC We don't really expect connection attempts during ST_DISC, but if the user happens to dispatch those events for whatever obscure reasons, treat them instead of erroring about an unallowed event. Change-Id: Ic7c60a40ff25ae647ee659259dfea769bc4592e4
2020-10-09 15:24:50 +00:00
| S(BSSMAP_RESET_EV_CONN_CFM_FAILURE)
| S(BSSMAP_RESET_EV_CONN_CFM_SUCCESS)
BSSMAP RESET: generalize a_reset FSM Separate the a_reset FSM implementation from BSSMAP and MSC specifics, so that it can be re-used on the Lb interface. Move the FSM implementation to bssmap_reset.c and tweak, to match common practices we have generally established in our osmo_fsm implementations. Keep a_reset.h and a_reset.c and redirect to bssmap_reset.c. A difficulty is setting a proper logging category: the FSM definition allows only one fixed logging category for FSM state transitions and events. Ideally, the BSSMAP reset fsm would log on DMSC, and the BSSMAP-LE reset fsm would log on DLCS. Since that is not possible, introduce a separate DRESET logging category. This in fact matches an item on my wishlist, because if a given MSC is configured but currently not connected, the previous RESET FSM would continuously "spam" log LOGL_NOTICE messages indicating that it is resending RESET, and I often want to silence those messages without silencing the entire DMSC category. This is now easily possible by setting DRESET logging to LOGL_ERROR. There is additional "link up" / "link lost" logging on DMSC, so all interesting info is still visible on DMSC. Change-Id: Ib3c3a163186c40a93be0dea666230431172136df
2020-10-04 19:32:52 +00:00
,
.out_state_mask = 0
| S(BSSMAP_RESET_ST_DISC)
| S(BSSMAP_RESET_ST_CONN)
,
.onenter = bssmap_reset_disc_onenter,
.action = bssmap_reset_disc_action,
},
[BSSMAP_RESET_ST_CONN] = {
vty: show mscs: add BSSMAP state New output: OsmoBSC> show mscs MSC 0: RI=SSN_PC,PC=0.23.3,SSN=BSSAP <-> RI=SSN_PC,PC=0.23.1,SSN=BSSAP ASP protocol: m3ua BSSMAP state: CONNECTED Closes: OS#6741 Change-Id: I23ddba7d935e5cc5dae041458207c674ccb9d013
2024-01-16 18:01:54 +00:00
.name = "CONNECTED",
BSSMAP RESET: generalize a_reset FSM Separate the a_reset FSM implementation from BSSMAP and MSC specifics, so that it can be re-used on the Lb interface. Move the FSM implementation to bssmap_reset.c and tweak, to match common practices we have generally established in our osmo_fsm implementations. Keep a_reset.h and a_reset.c and redirect to bssmap_reset.c. A difficulty is setting a proper logging category: the FSM definition allows only one fixed logging category for FSM state transitions and events. Ideally, the BSSMAP reset fsm would log on DMSC, and the BSSMAP-LE reset fsm would log on DLCS. Since that is not possible, introduce a separate DRESET logging category. This in fact matches an item on my wishlist, because if a given MSC is configured but currently not connected, the previous RESET FSM would continuously "spam" log LOGL_NOTICE messages indicating that it is resending RESET, and I often want to silence those messages without silencing the entire DMSC category. This is now easily possible by setting DRESET logging to LOGL_ERROR. There is additional "link up" / "link lost" logging on DMSC, so all interesting info is still visible on DMSC. Change-Id: Ib3c3a163186c40a93be0dea666230431172136df
2020-10-04 19:32:52 +00:00
.in_event_mask = 0
BSSMAP RESET: move RESET-ACK into reset fsm The Lb interface will need the same RESET-ACK logic. Change-Id: Idf4682319a0af5665e867dbc0515d1fe343d9daf
2020-10-09 15:18:29 +00:00
| S(BSSMAP_RESET_EV_RX_RESET)
BSSMAP RESET: generalize a_reset FSM Separate the a_reset FSM implementation from BSSMAP and MSC specifics, so that it can be re-used on the Lb interface. Move the FSM implementation to bssmap_reset.c and tweak, to match common practices we have generally established in our osmo_fsm implementations. Keep a_reset.h and a_reset.c and redirect to bssmap_reset.c. A difficulty is setting a proper logging category: the FSM definition allows only one fixed logging category for FSM state transitions and events. Ideally, the BSSMAP reset fsm would log on DMSC, and the BSSMAP-LE reset fsm would log on DLCS. Since that is not possible, introduce a separate DRESET logging category. This in fact matches an item on my wishlist, because if a given MSC is configured but currently not connected, the previous RESET FSM would continuously "spam" log LOGL_NOTICE messages indicating that it is resending RESET, and I often want to silence those messages without silencing the entire DMSC category. This is now easily possible by setting DRESET logging to LOGL_ERROR. There is additional "link up" / "link lost" logging on DMSC, so all interesting info is still visible on DMSC. Change-Id: Ib3c3a163186c40a93be0dea666230431172136df
2020-10-04 19:32:52 +00:00
| S(BSSMAP_RESET_EV_RX_RESET_ACK)
| S(BSSMAP_RESET_EV_CONN_CFM_FAILURE)
| S(BSSMAP_RESET_EV_CONN_CFM_SUCCESS)
,
.out_state_mask = 0
| S(BSSMAP_RESET_ST_DISC)
| S(BSSMAP_RESET_ST_CONN)
,
.onenter = bssmap_reset_conn_onenter,
.action = bssmap_reset_conn_action,
},
};
static struct osmo_fsm bssmap_reset_fsm = {
.name = "bssmap_reset",
.states = bssmap_reset_fsm_states,
.num_states = ARRAY_SIZE(bssmap_reset_fsm_states),
.log_subsys = DRESET,
.timer_cb = bssmap_reset_fsm_timer_cb,
.event_names = bssmap_reset_fsm_event_names,
};
bool bssmap_reset_is_conn_ready(const struct bssmap_reset *bssmap_reset)
{
return bssmap_reset->fi->state == BSSMAP_RESET_ST_CONN;
}
vty: add "msc N bssmap reset" command Allow resetting the BSSMAP link from VTY, for BSC_Tests.ttcn. In the field, detecting that an MSC is lost is done by getting three connection failures in a row. For the BSC_Tests, it is easier to just provide a VTY command to reset an MSC's link status. I want to add tests that verify the stat items reflecting the MSC connection status. To be able to run a test expecting fewer connected MSC after a test that launched more MSCs requires the links to be reset. Related: SYS#5542 Related: Ice3056dc46c94f9399f8379db7aeb7193782f2f2 (osmo-ttcn3-hacks) Change-Id: I1975941b790d2b30d0904d41e456220cba26ecff
2021-08-23 18:42:27 +00:00
void bssmap_reset_resend_reset(struct bssmap_reset *bssmap_reset)
{
BSSMAP: add assert to reset resending There seems to be no way for this function to be called with NULL parameter despite unreproducible crash observed in the past. Let's add assert to show this explicitly. Fixes: OS#5551 Change-Id: I235bdd42ea82e7b5a1a40f437ca34c49ad239c48
2022-08-02 12:07:57 +00:00
OSMO_ASSERT(bssmap_reset);
vty: add "msc N bssmap reset" command Allow resetting the BSSMAP link from VTY, for BSC_Tests.ttcn. In the field, detecting that an MSC is lost is done by getting three connection failures in a row. For the BSC_Tests, it is easier to just provide a VTY command to reset an MSC's link status. I want to add tests that verify the stat items reflecting the MSC connection status. To be able to run a test expecting fewer connected MSC after a test that launched more MSCs requires the links to be reset. Related: SYS#5542 Related: Ice3056dc46c94f9399f8379db7aeb7193782f2f2 (osmo-ttcn3-hacks) Change-Id: I1975941b790d2b30d0904d41e456220cba26ecff
2021-08-23 18:42:27 +00:00
/* Immediately (1ms) kick off reset sending mechanism */
osmo_fsm_inst_state_chg_ms(bssmap_reset->fi, BSSMAP_RESET_ST_DISC, 1, 0);
}
SCCP N-PCSTATE: trigger MSC status on PC availability Related: SYS#6319 Related: Ia1aea4e33230d6a685b72ea5ba20dd9c7d265d44 osmo-ttcn3-hacks Related: Ib4a5330df30a73e744c316898817b2fa3271d75e osmo-ttcn3-hacks Change-Id: I3a0869598b8395601a16d78dbc46eec400c0ea84
2023-03-30 03:18:53 +00:00
void bssmap_reset_set_disconnected(struct bssmap_reset *bssmap_reset)
{
/* Go to disconnected state, with the normal RESET timeout to re-send RESET. */
bssmap_reset_fsm_state_chg(bssmap_reset->fi, BSSMAP_RESET_ST_DISC);
}
Support building with -Werror=strict-prototypes / -Werror=old-style-definition Unfortunately "-std=c99" is not sufficient to make gcc ignore cold that uses constructs of earlier C standards, which were abandoned in C99. See https://lwn.net/ml/fedora-devel/Y1kvF35WozzGBpc8@redhat.com/ for some related discussion. Change-Id: Ic92aa70d569778a776f4c5d24c455f71fd50b61b
2022-11-03 10:50:48 +00:00
static __attribute__((constructor)) void bssmap_reset_fsm_init(void)
BSSMAP RESET: generalize a_reset FSM Separate the a_reset FSM implementation from BSSMAP and MSC specifics, so that it can be re-used on the Lb interface. Move the FSM implementation to bssmap_reset.c and tweak, to match common practices we have generally established in our osmo_fsm implementations. Keep a_reset.h and a_reset.c and redirect to bssmap_reset.c. A difficulty is setting a proper logging category: the FSM definition allows only one fixed logging category for FSM state transitions and events. Ideally, the BSSMAP reset fsm would log on DMSC, and the BSSMAP-LE reset fsm would log on DLCS. Since that is not possible, introduce a separate DRESET logging category. This in fact matches an item on my wishlist, because if a given MSC is configured but currently not connected, the previous RESET FSM would continuously "spam" log LOGL_NOTICE messages indicating that it is resending RESET, and I often want to silence those messages without silencing the entire DMSC category. This is now easily possible by setting DRESET logging to LOGL_ERROR. There is additional "link up" / "link lost" logging on DMSC, so all interesting info is still visible on DMSC. Change-Id: Ib3c3a163186c40a93be0dea666230431172136df
2020-10-04 19:32:52 +00:00
{
OSMO_ASSERT(osmo_fsm_register(&bssmap_reset_fsm) == 0);
}