2017-04-14 18:16:10 +00:00
|
|
|
/* Core SS7 Instance/Linkset/Link/AS/ASP VTY Interface */
|
|
|
|
|
|
|
|
/* (C) 2015-2017 by Harald Welte <laforge@gnumonks.org>
|
|
|
|
* All Rights Reserved
|
|
|
|
*
|
2017-11-12 16:25:47 +00:00
|
|
|
* SPDX-License-Identifier: GPL-2.0+
|
|
|
|
*
|
2017-04-14 18:16:10 +00:00
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation; either version 2 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 General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <stdlib.h>
|
|
|
|
#include <unistd.h>
|
|
|
|
#include <errno.h>
|
|
|
|
#include <stdint.h>
|
|
|
|
#include <string.h>
|
|
|
|
|
|
|
|
#include <arpa/inet.h>
|
|
|
|
|
|
|
|
#include <osmocom/vty/vty.h>
|
|
|
|
#include <osmocom/vty/command.h>
|
|
|
|
#include <osmocom/vty/logging.h>
|
|
|
|
#include <osmocom/vty/telnet_interface.h>
|
|
|
|
#include <osmocom/vty/misc.h>
|
|
|
|
|
|
|
|
#include <osmocom/sigtran/osmo_ss7.h>
|
|
|
|
#include <osmocom/sigtran/protocol/mtp.h>
|
|
|
|
|
SCCP: implement variable limit on Optional Data (CR,CC,CREF,RLSD)
When the Optional Data surpasses 130 bytes, it is not sent as part of
SCCP CR, CC, CREF or RLSD messages, but gets sent separately in a Data
Form 1.
Make this 130 user configurable. This is specified to be 130 bytes
exactly, but to interop with non-conforming peers, make this limit
adjustable per cs7 instance, via osmo_sccp_vty_init().
Add and test new VTY config:
cs7 instance N
sccp max-optional-data (<0-999999>|standard)
Related: ITU-T Q.713 4.2 to 4.5
Related: Ia68dad973ef18513b52f5accb5264c557c7295ea osmo-ttcn3-hacks
Related: SYS#6423
Change-Id: If35697234796af8943691b2de62218e7dc93a08c
2023-04-18 19:59:41 +00:00
|
|
|
#include <osmocom/sccp/sccp_types.h>
|
|
|
|
|
2017-04-14 18:16:10 +00:00
|
|
|
#include "xua_internal.h"
|
|
|
|
#include "sccp_internal.h"
|
|
|
|
|
|
|
|
static void show_user(struct vty *vty, struct osmo_sccp_user *user)
|
|
|
|
{
|
|
|
|
struct osmo_sccp_instance *sccp = user->inst;
|
|
|
|
|
2017-07-26 15:31:53 +00:00
|
|
|
if (osmo_ss7_pc_is_valid(user->pc))
|
2017-04-14 18:16:10 +00:00
|
|
|
vty_out(vty, "SSN %3u %7s : %s%s", user->ssn,
|
|
|
|
osmo_ss7_pointcode_print(sccp->ss7, user->pc),
|
|
|
|
user->name, VTY_NEWLINE);
|
|
|
|
else
|
|
|
|
vty_out(vty, "SSN %3u ANY : %s%s", user->ssn, user->name, VTY_NEWLINE);
|
|
|
|
}
|
|
|
|
|
|
|
|
DEFUN(show_sccp_users, show_sccp_users_cmd,
|
|
|
|
"show cs7 instance <0-15> sccp users",
|
2018-09-26 21:30:44 +00:00
|
|
|
SHOW_STR CS7_STR INST_STR INST_STR SCCP_STR
|
2017-04-14 18:16:10 +00:00
|
|
|
"Show List of SCCP Users registered\n")
|
|
|
|
{
|
|
|
|
int id = atoi(argv[0]);
|
|
|
|
struct osmo_ss7_instance *inst;
|
|
|
|
struct osmo_sccp_instance *sccp;
|
|
|
|
struct osmo_sccp_user *scu;
|
|
|
|
|
|
|
|
inst = osmo_ss7_instance_find(id);
|
|
|
|
if (!inst) {
|
|
|
|
vty_out(vty, "No SS7 instance %d found%s", id, VTY_NEWLINE);
|
|
|
|
return CMD_WARNING;
|
|
|
|
}
|
|
|
|
|
|
|
|
sccp = inst->sccp;
|
|
|
|
if (!sccp) {
|
|
|
|
vty_out(vty, "SS7 instance %d has no SCCP%s", id, VTY_NEWLINE);
|
|
|
|
return CMD_WARNING;
|
|
|
|
};
|
|
|
|
|
|
|
|
llist_for_each_entry(scu, &sccp->users, list)
|
|
|
|
show_user(vty, scu);
|
|
|
|
|
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
DEFUN(show_sccp_user_ssn, show_sccp_user_ssn_cmd,
|
|
|
|
"show cs7 instance <0-15> sccp ssn <0-65535>",
|
2018-09-26 21:30:44 +00:00
|
|
|
SHOW_STR CS7_STR INST_STR INST_STR SCCP_STR
|
2018-09-27 01:28:19 +00:00
|
|
|
"Find an SCCP User registered for the given SSN\n"
|
|
|
|
"Subsystem Number (SSN)\n")
|
2017-04-14 18:16:10 +00:00
|
|
|
{
|
|
|
|
int id = atoi(argv[0]);
|
|
|
|
int ssn = atoi(argv[1]);
|
|
|
|
struct osmo_ss7_instance *inst;
|
|
|
|
struct osmo_sccp_instance *sccp;
|
|
|
|
struct osmo_sccp_user *scu;
|
|
|
|
|
|
|
|
inst = osmo_ss7_instance_find(id);
|
|
|
|
if (!inst) {
|
|
|
|
vty_out(vty, "No SS7 instance %d found%s", id, VTY_NEWLINE);
|
|
|
|
return CMD_WARNING;
|
|
|
|
}
|
|
|
|
|
|
|
|
sccp = inst->sccp;
|
|
|
|
if (!sccp) {
|
|
|
|
vty_out(vty, "SS7 instance %d has no SCCP%s", id, VTY_NEWLINE);
|
|
|
|
return CMD_WARNING;
|
|
|
|
};
|
|
|
|
|
|
|
|
scu = sccp_user_find(sccp, ssn, 0);
|
|
|
|
if (!scu) {
|
|
|
|
vty_out(vty, "Can't find SCCP User in instance %d%s", id, VTY_NEWLINE);
|
|
|
|
return CMD_WARNING;
|
|
|
|
}
|
|
|
|
|
|
|
|
show_user(vty, scu);
|
|
|
|
|
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
DEFUN(show_sccp_connections, show_sccp_connections_cmd,
|
|
|
|
"show cs7 instance <0-15> sccp connections",
|
2018-09-26 21:30:44 +00:00
|
|
|
SHOW_STR CS7_STR INST_STR INST_STR SCCP_STR
|
2018-09-27 01:28:19 +00:00
|
|
|
"Show List of active SCCP connections\n")
|
2017-04-14 18:16:10 +00:00
|
|
|
{
|
|
|
|
int id = atoi(argv[0]);
|
|
|
|
struct osmo_ss7_instance *inst;
|
|
|
|
struct osmo_sccp_instance *sccp;
|
|
|
|
|
|
|
|
inst = osmo_ss7_instance_find(id);
|
|
|
|
if (!inst) {
|
|
|
|
vty_out(vty, "No SS7 instance %d found%s", id, VTY_NEWLINE);
|
|
|
|
return CMD_WARNING;
|
|
|
|
}
|
|
|
|
|
|
|
|
sccp = inst->sccp;
|
|
|
|
if (!sccp) {
|
|
|
|
vty_out(vty, "SS7 instance %d has no SCCP%s", id, VTY_NEWLINE);
|
|
|
|
return CMD_WARNING;
|
|
|
|
};
|
|
|
|
|
|
|
|
sccp_scoc_show_connections(vty, sccp);
|
|
|
|
|
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
make SCCP timers configurable
The previous hardcoded SCCP timers may cause SCCP connection releases, if the
peer is configured with far lower timers than libosmo-sccp. Testing with a
specific SCCPlite MSC, I experienced an iar of just over three minutes, meaning
that calls would be cut off by the MSC, since the osmo-bsc failed to send an
Inactivity Timer message until seven minutes have passed.
With this patch, SCCP timers are configurable by the user.
Define constant global default timers, and variable user-configurable timers
with each osmo_sccp_instance.
Add VTY UI to configure the timers. Users must call osmo_sccp_vty_init() to get
the sccp-timer config nodes under the 'cs7' node. Show the new UI in
ss7_asp_test.vty.
Note that even though this function is not new at all, until recently, all of
our SCCP users (osmo-bsc, osmo-msc, osmo-sgsn, osmo-hnbgw) failed to call
osmo_sccp_vty_init(), and thus also missed out on the various 'show' commands
defined in sccp_vty.c. In other words, to benefit from the timer
configurability, the patches to call osmo_sccp_vty_init() must first be merged
to the corresponding master branches.
If a 'sccp-timer' config command occurs, the cs7 instance must allocate an SCCP
instance in order to store the timer config. Do that by calling the recently
added osmo_ss7_ensure_sccp() function.
Hence remove the limitation that the SCCP instance must not be populated from
the "simple" setup function. If we want to configure SCCP timers beforehand,
there must be an SCCP instance for that, and there is no hard reason to require
a NULL SCCP instance, besides the desire to prevent this function from being
invoked twice.
Change-Id: I28a7362aa838e648ecc9b26ee53dbcade81a9d65
2018-09-26 15:12:23 +00:00
|
|
|
/* sccp-timer <name> <1-999999>
|
|
|
|
* (cmdstr and doc are dynamically generated from osmo_sccp_timer_names.) */
|
2020-10-06 17:49:37 +00:00
|
|
|
DEFUN_ATTR(sccp_timer, sccp_timer_cmd,
|
|
|
|
NULL, NULL, CMD_ATTR_IMMEDIATE)
|
make SCCP timers configurable
The previous hardcoded SCCP timers may cause SCCP connection releases, if the
peer is configured with far lower timers than libosmo-sccp. Testing with a
specific SCCPlite MSC, I experienced an iar of just over three minutes, meaning
that calls would be cut off by the MSC, since the osmo-bsc failed to send an
Inactivity Timer message until seven minutes have passed.
With this patch, SCCP timers are configurable by the user.
Define constant global default timers, and variable user-configurable timers
with each osmo_sccp_instance.
Add VTY UI to configure the timers. Users must call osmo_sccp_vty_init() to get
the sccp-timer config nodes under the 'cs7' node. Show the new UI in
ss7_asp_test.vty.
Note that even though this function is not new at all, until recently, all of
our SCCP users (osmo-bsc, osmo-msc, osmo-sgsn, osmo-hnbgw) failed to call
osmo_sccp_vty_init(), and thus also missed out on the various 'show' commands
defined in sccp_vty.c. In other words, to benefit from the timer
configurability, the patches to call osmo_sccp_vty_init() must first be merged
to the corresponding master branches.
If a 'sccp-timer' config command occurs, the cs7 instance must allocate an SCCP
instance in order to store the timer config. Do that by calling the recently
added osmo_ss7_ensure_sccp() function.
Hence remove the limitation that the SCCP instance must not be populated from
the "simple" setup function. If we want to configure SCCP timers beforehand,
there must be an SCCP instance for that, and there is no hard reason to require
a NULL SCCP instance, besides the desire to prevent this function from being
invoked twice.
Change-Id: I28a7362aa838e648ecc9b26ee53dbcade81a9d65
2018-09-26 15:12:23 +00:00
|
|
|
{
|
|
|
|
struct osmo_ss7_instance *ss7 = vty->index;
|
|
|
|
enum osmo_sccp_timer timer = get_string_value(osmo_sccp_timer_names, argv[0]);
|
|
|
|
|
2023-07-07 15:14:16 +00:00
|
|
|
if (timer <= 0 || timer >= OSMO_SCCP_TIMERS_LEN) {
|
make SCCP timers configurable
The previous hardcoded SCCP timers may cause SCCP connection releases, if the
peer is configured with far lower timers than libosmo-sccp. Testing with a
specific SCCPlite MSC, I experienced an iar of just over three minutes, meaning
that calls would be cut off by the MSC, since the osmo-bsc failed to send an
Inactivity Timer message until seven minutes have passed.
With this patch, SCCP timers are configurable by the user.
Define constant global default timers, and variable user-configurable timers
with each osmo_sccp_instance.
Add VTY UI to configure the timers. Users must call osmo_sccp_vty_init() to get
the sccp-timer config nodes under the 'cs7' node. Show the new UI in
ss7_asp_test.vty.
Note that even though this function is not new at all, until recently, all of
our SCCP users (osmo-bsc, osmo-msc, osmo-sgsn, osmo-hnbgw) failed to call
osmo_sccp_vty_init(), and thus also missed out on the various 'show' commands
defined in sccp_vty.c. In other words, to benefit from the timer
configurability, the patches to call osmo_sccp_vty_init() must first be merged
to the corresponding master branches.
If a 'sccp-timer' config command occurs, the cs7 instance must allocate an SCCP
instance in order to store the timer config. Do that by calling the recently
added osmo_ss7_ensure_sccp() function.
Hence remove the limitation that the SCCP instance must not be populated from
the "simple" setup function. If we want to configure SCCP timers beforehand,
there must be an SCCP instance for that, and there is no hard reason to require
a NULL SCCP instance, besides the desire to prevent this function from being
invoked twice.
Change-Id: I28a7362aa838e648ecc9b26ee53dbcade81a9d65
2018-09-26 15:12:23 +00:00
|
|
|
vty_out(vty, "%% Invalid timer: %s%s", argv[0], VTY_NEWLINE);
|
|
|
|
return CMD_WARNING;
|
|
|
|
}
|
|
|
|
|
|
|
|
osmo_ss7_ensure_sccp(ss7);
|
|
|
|
if (!ss7->sccp) {
|
|
|
|
vty_out(vty, "%% Error: cannot instantiate SCCP instance%s", VTY_NEWLINE);
|
|
|
|
return CMD_WARNING;
|
|
|
|
}
|
|
|
|
|
2023-07-07 15:14:16 +00:00
|
|
|
OSMO_ASSERT(ss7->sccp->tdefs);
|
|
|
|
osmo_tdef_set(ss7->sccp->tdefs, timer, atoi(argv[1]), OSMO_TDEF_S);
|
make SCCP timers configurable
The previous hardcoded SCCP timers may cause SCCP connection releases, if the
peer is configured with far lower timers than libosmo-sccp. Testing with a
specific SCCPlite MSC, I experienced an iar of just over three minutes, meaning
that calls would be cut off by the MSC, since the osmo-bsc failed to send an
Inactivity Timer message until seven minutes have passed.
With this patch, SCCP timers are configurable by the user.
Define constant global default timers, and variable user-configurable timers
with each osmo_sccp_instance.
Add VTY UI to configure the timers. Users must call osmo_sccp_vty_init() to get
the sccp-timer config nodes under the 'cs7' node. Show the new UI in
ss7_asp_test.vty.
Note that even though this function is not new at all, until recently, all of
our SCCP users (osmo-bsc, osmo-msc, osmo-sgsn, osmo-hnbgw) failed to call
osmo_sccp_vty_init(), and thus also missed out on the various 'show' commands
defined in sccp_vty.c. In other words, to benefit from the timer
configurability, the patches to call osmo_sccp_vty_init() must first be merged
to the corresponding master branches.
If a 'sccp-timer' config command occurs, the cs7 instance must allocate an SCCP
instance in order to store the timer config. Do that by calling the recently
added osmo_ss7_ensure_sccp() function.
Hence remove the limitation that the SCCP instance must not be populated from
the "simple" setup function. If we want to configure SCCP timers beforehand,
there must be an SCCP instance for that, and there is no hard reason to require
a NULL SCCP instance, besides the desire to prevent this function from being
invoked twice.
Change-Id: I28a7362aa838e648ecc9b26ee53dbcade81a9d65
2018-09-26 15:12:23 +00:00
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
SCCP: implement variable limit on Optional Data (CR,CC,CREF,RLSD)
When the Optional Data surpasses 130 bytes, it is not sent as part of
SCCP CR, CC, CREF or RLSD messages, but gets sent separately in a Data
Form 1.
Make this 130 user configurable. This is specified to be 130 bytes
exactly, but to interop with non-conforming peers, make this limit
adjustable per cs7 instance, via osmo_sccp_vty_init().
Add and test new VTY config:
cs7 instance N
sccp max-optional-data (<0-999999>|standard)
Related: ITU-T Q.713 4.2 to 4.5
Related: Ia68dad973ef18513b52f5accb5264c557c7295ea osmo-ttcn3-hacks
Related: SYS#6423
Change-Id: If35697234796af8943691b2de62218e7dc93a08c
2023-04-18 19:59:41 +00:00
|
|
|
DEFUN_ATTR(sccp_max_optional_data, sccp_max_optional_data_cmd,
|
|
|
|
"sccp max-optional-data (<0-999999>|standard)",
|
|
|
|
"Configure SCCP behavior\n"
|
|
|
|
"Adjust the upper bound for the optional data length (the payload) for CR, CC, CREF and RLSD messages."
|
|
|
|
" For any Optional Data part larger than this value in octets, send CR, CC, CREF and RLSD"
|
|
|
|
" messages without any payload, and send the data payload in a separate Data Form 1 message."
|
|
|
|
" ITU-T Q.713 sections 4.2 thru 4.5 define a limit of 130 bytes for the 'Data' parameter. This limit can be"
|
|
|
|
" adjusted here. May be useful for interop with nonstandard SCCP peers.\n"
|
|
|
|
"Set a non-standard maximum allowed number of bytes\n"
|
|
|
|
"Use the ITU-T Q.713 4.2 to 4.5 standard value of 130\n",
|
|
|
|
CMD_ATTR_IMMEDIATE)
|
|
|
|
{
|
|
|
|
struct osmo_ss7_instance *ss7 = vty->index;
|
|
|
|
int val;
|
|
|
|
|
|
|
|
if (!strcmp(argv[0], "standard"))
|
2023-05-09 23:58:42 +00:00
|
|
|
val = -1;
|
SCCP: implement variable limit on Optional Data (CR,CC,CREF,RLSD)
When the Optional Data surpasses 130 bytes, it is not sent as part of
SCCP CR, CC, CREF or RLSD messages, but gets sent separately in a Data
Form 1.
Make this 130 user configurable. This is specified to be 130 bytes
exactly, but to interop with non-conforming peers, make this limit
adjustable per cs7 instance, via osmo_sccp_vty_init().
Add and test new VTY config:
cs7 instance N
sccp max-optional-data (<0-999999>|standard)
Related: ITU-T Q.713 4.2 to 4.5
Related: Ia68dad973ef18513b52f5accb5264c557c7295ea osmo-ttcn3-hacks
Related: SYS#6423
Change-Id: If35697234796af8943691b2de62218e7dc93a08c
2023-04-18 19:59:41 +00:00
|
|
|
else
|
|
|
|
val = atoi(argv[0]);
|
|
|
|
|
|
|
|
osmo_ss7_ensure_sccp(ss7);
|
|
|
|
if (!ss7->sccp) {
|
|
|
|
vty_out(vty, "%% Error: cannot instantiate SCCP instance%s", VTY_NEWLINE);
|
|
|
|
return CMD_WARNING;
|
|
|
|
}
|
|
|
|
|
2023-05-09 23:58:42 +00:00
|
|
|
osmo_sccp_set_max_optional_data(ss7->sccp, val);
|
SCCP: implement variable limit on Optional Data (CR,CC,CREF,RLSD)
When the Optional Data surpasses 130 bytes, it is not sent as part of
SCCP CR, CC, CREF or RLSD messages, but gets sent separately in a Data
Form 1.
Make this 130 user configurable. This is specified to be 130 bytes
exactly, but to interop with non-conforming peers, make this limit
adjustable per cs7 instance, via osmo_sccp_vty_init().
Add and test new VTY config:
cs7 instance N
sccp max-optional-data (<0-999999>|standard)
Related: ITU-T Q.713 4.2 to 4.5
Related: Ia68dad973ef18513b52f5accb5264c557c7295ea osmo-ttcn3-hacks
Related: SYS#6423
Change-Id: If35697234796af8943691b2de62218e7dc93a08c
2023-04-18 19:59:41 +00:00
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
make SCCP timers configurable
The previous hardcoded SCCP timers may cause SCCP connection releases, if the
peer is configured with far lower timers than libosmo-sccp. Testing with a
specific SCCPlite MSC, I experienced an iar of just over three minutes, meaning
that calls would be cut off by the MSC, since the osmo-bsc failed to send an
Inactivity Timer message until seven minutes have passed.
With this patch, SCCP timers are configurable by the user.
Define constant global default timers, and variable user-configurable timers
with each osmo_sccp_instance.
Add VTY UI to configure the timers. Users must call osmo_sccp_vty_init() to get
the sccp-timer config nodes under the 'cs7' node. Show the new UI in
ss7_asp_test.vty.
Note that even though this function is not new at all, until recently, all of
our SCCP users (osmo-bsc, osmo-msc, osmo-sgsn, osmo-hnbgw) failed to call
osmo_sccp_vty_init(), and thus also missed out on the various 'show' commands
defined in sccp_vty.c. In other words, to benefit from the timer
configurability, the patches to call osmo_sccp_vty_init() must first be merged
to the corresponding master branches.
If a 'sccp-timer' config command occurs, the cs7 instance must allocate an SCCP
instance in order to store the timer config. Do that by calling the recently
added osmo_ss7_ensure_sccp() function.
Hence remove the limitation that the SCCP instance must not be populated from
the "simple" setup function. If we want to configure SCCP timers beforehand,
there must be an SCCP instance for that, and there is no hard reason to require
a NULL SCCP instance, besides the desire to prevent this function from being
invoked twice.
Change-Id: I28a7362aa838e648ecc9b26ee53dbcade81a9d65
2018-09-26 15:12:23 +00:00
|
|
|
static void gen_sccp_timer_cmd_strs(struct cmd_element *cmd)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
char *cmd_str = NULL;
|
|
|
|
char *doc_str = NULL;
|
|
|
|
|
|
|
|
OSMO_ASSERT(cmd->string == NULL);
|
|
|
|
OSMO_ASSERT(cmd->doc == NULL);
|
|
|
|
|
|
|
|
osmo_talloc_asprintf(tall_vty_ctx, cmd_str, "sccp-timer (");
|
|
|
|
osmo_talloc_asprintf(tall_vty_ctx, doc_str,
|
|
|
|
"Configure SCCP timer values, see ITU-T Q.714\n");
|
|
|
|
|
|
|
|
for (i = 0; osmo_sccp_timer_names[i].str; i++) {
|
2023-07-07 15:14:16 +00:00
|
|
|
const struct osmo_tdef *def;
|
make SCCP timers configurable
The previous hardcoded SCCP timers may cause SCCP connection releases, if the
peer is configured with far lower timers than libosmo-sccp. Testing with a
specific SCCPlite MSC, I experienced an iar of just over three minutes, meaning
that calls would be cut off by the MSC, since the osmo-bsc failed to send an
Inactivity Timer message until seven minutes have passed.
With this patch, SCCP timers are configurable by the user.
Define constant global default timers, and variable user-configurable timers
with each osmo_sccp_instance.
Add VTY UI to configure the timers. Users must call osmo_sccp_vty_init() to get
the sccp-timer config nodes under the 'cs7' node. Show the new UI in
ss7_asp_test.vty.
Note that even though this function is not new at all, until recently, all of
our SCCP users (osmo-bsc, osmo-msc, osmo-sgsn, osmo-hnbgw) failed to call
osmo_sccp_vty_init(), and thus also missed out on the various 'show' commands
defined in sccp_vty.c. In other words, to benefit from the timer
configurability, the patches to call osmo_sccp_vty_init() must first be merged
to the corresponding master branches.
If a 'sccp-timer' config command occurs, the cs7 instance must allocate an SCCP
instance in order to store the timer config. Do that by calling the recently
added osmo_ss7_ensure_sccp() function.
Hence remove the limitation that the SCCP instance must not be populated from
the "simple" setup function. If we want to configure SCCP timers beforehand,
there must be an SCCP instance for that, and there is no hard reason to require
a NULL SCCP instance, besides the desire to prevent this function from being
invoked twice.
Change-Id: I28a7362aa838e648ecc9b26ee53dbcade81a9d65
2018-09-26 15:12:23 +00:00
|
|
|
enum osmo_sccp_timer timer;
|
|
|
|
|
|
|
|
timer = osmo_sccp_timer_names[i].value;
|
2023-07-07 15:14:16 +00:00
|
|
|
def = osmo_tdef_get_entry((struct osmo_tdef *)&osmo_sccp_timer_defaults, timer);
|
|
|
|
OSMO_ASSERT(def);
|
make SCCP timers configurable
The previous hardcoded SCCP timers may cause SCCP connection releases, if the
peer is configured with far lower timers than libosmo-sccp. Testing with a
specific SCCPlite MSC, I experienced an iar of just over three minutes, meaning
that calls would be cut off by the MSC, since the osmo-bsc failed to send an
Inactivity Timer message until seven minutes have passed.
With this patch, SCCP timers are configurable by the user.
Define constant global default timers, and variable user-configurable timers
with each osmo_sccp_instance.
Add VTY UI to configure the timers. Users must call osmo_sccp_vty_init() to get
the sccp-timer config nodes under the 'cs7' node. Show the new UI in
ss7_asp_test.vty.
Note that even though this function is not new at all, until recently, all of
our SCCP users (osmo-bsc, osmo-msc, osmo-sgsn, osmo-hnbgw) failed to call
osmo_sccp_vty_init(), and thus also missed out on the various 'show' commands
defined in sccp_vty.c. In other words, to benefit from the timer
configurability, the patches to call osmo_sccp_vty_init() must first be merged
to the corresponding master branches.
If a 'sccp-timer' config command occurs, the cs7 instance must allocate an SCCP
instance in order to store the timer config. Do that by calling the recently
added osmo_ss7_ensure_sccp() function.
Hence remove the limitation that the SCCP instance must not be populated from
the "simple" setup function. If we want to configure SCCP timers beforehand,
there must be an SCCP instance for that, and there is no hard reason to require
a NULL SCCP instance, besides the desire to prevent this function from being
invoked twice.
Change-Id: I28a7362aa838e648ecc9b26ee53dbcade81a9d65
2018-09-26 15:12:23 +00:00
|
|
|
|
|
|
|
osmo_talloc_asprintf(tall_vty_ctx, cmd_str, "%s%s",
|
|
|
|
i ? "|" : "",
|
2023-07-07 15:14:16 +00:00
|
|
|
osmo_sccp_timer_names[i].str);
|
|
|
|
osmo_talloc_asprintf(tall_vty_ctx, doc_str, "%s (default: %lu)\n",
|
|
|
|
def->desc,
|
|
|
|
def->default_val);
|
make SCCP timers configurable
The previous hardcoded SCCP timers may cause SCCP connection releases, if the
peer is configured with far lower timers than libosmo-sccp. Testing with a
specific SCCPlite MSC, I experienced an iar of just over three minutes, meaning
that calls would be cut off by the MSC, since the osmo-bsc failed to send an
Inactivity Timer message until seven minutes have passed.
With this patch, SCCP timers are configurable by the user.
Define constant global default timers, and variable user-configurable timers
with each osmo_sccp_instance.
Add VTY UI to configure the timers. Users must call osmo_sccp_vty_init() to get
the sccp-timer config nodes under the 'cs7' node. Show the new UI in
ss7_asp_test.vty.
Note that even though this function is not new at all, until recently, all of
our SCCP users (osmo-bsc, osmo-msc, osmo-sgsn, osmo-hnbgw) failed to call
osmo_sccp_vty_init(), and thus also missed out on the various 'show' commands
defined in sccp_vty.c. In other words, to benefit from the timer
configurability, the patches to call osmo_sccp_vty_init() must first be merged
to the corresponding master branches.
If a 'sccp-timer' config command occurs, the cs7 instance must allocate an SCCP
instance in order to store the timer config. Do that by calling the recently
added osmo_ss7_ensure_sccp() function.
Hence remove the limitation that the SCCP instance must not be populated from
the "simple" setup function. If we want to configure SCCP timers beforehand,
there must be an SCCP instance for that, and there is no hard reason to require
a NULL SCCP instance, besides the desire to prevent this function from being
invoked twice.
Change-Id: I28a7362aa838e648ecc9b26ee53dbcade81a9d65
2018-09-26 15:12:23 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
osmo_talloc_asprintf(tall_vty_ctx, cmd_str, ") <1-999999>");
|
|
|
|
osmo_talloc_asprintf(tall_vty_ctx, doc_str,
|
|
|
|
"Timer value, in seconds\n");
|
|
|
|
|
|
|
|
cmd->string = cmd_str;
|
|
|
|
cmd->doc = doc_str;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void write_sccp_timers(struct vty *vty, const char *indent,
|
|
|
|
struct osmo_sccp_instance *inst, bool default_if_unset)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2023-07-07 15:14:16 +00:00
|
|
|
for (i = 0; osmo_sccp_timer_names[i].str; i++) {
|
|
|
|
const struct osmo_tdef *tdef = osmo_tdef_get_entry(inst->tdefs, osmo_sccp_timer_names[i].value);
|
|
|
|
if (!tdef)
|
|
|
|
continue;
|
|
|
|
if (!default_if_unset && tdef->val == tdef->default_val)
|
make SCCP timers configurable
The previous hardcoded SCCP timers may cause SCCP connection releases, if the
peer is configured with far lower timers than libosmo-sccp. Testing with a
specific SCCPlite MSC, I experienced an iar of just over three minutes, meaning
that calls would be cut off by the MSC, since the osmo-bsc failed to send an
Inactivity Timer message until seven minutes have passed.
With this patch, SCCP timers are configurable by the user.
Define constant global default timers, and variable user-configurable timers
with each osmo_sccp_instance.
Add VTY UI to configure the timers. Users must call osmo_sccp_vty_init() to get
the sccp-timer config nodes under the 'cs7' node. Show the new UI in
ss7_asp_test.vty.
Note that even though this function is not new at all, until recently, all of
our SCCP users (osmo-bsc, osmo-msc, osmo-sgsn, osmo-hnbgw) failed to call
osmo_sccp_vty_init(), and thus also missed out on the various 'show' commands
defined in sccp_vty.c. In other words, to benefit from the timer
configurability, the patches to call osmo_sccp_vty_init() must first be merged
to the corresponding master branches.
If a 'sccp-timer' config command occurs, the cs7 instance must allocate an SCCP
instance in order to store the timer config. Do that by calling the recently
added osmo_ss7_ensure_sccp() function.
Hence remove the limitation that the SCCP instance must not be populated from
the "simple" setup function. If we want to configure SCCP timers beforehand,
there must be an SCCP instance for that, and there is no hard reason to require
a NULL SCCP instance, besides the desire to prevent this function from being
invoked twice.
Change-Id: I28a7362aa838e648ecc9b26ee53dbcade81a9d65
2018-09-26 15:12:23 +00:00
|
|
|
continue;
|
2023-07-07 15:14:16 +00:00
|
|
|
vty_out(vty, "%ssccp-timer %s %lu%s", indent, osmo_sccp_timer_names[i].str,
|
|
|
|
tdef->val, VTY_NEWLINE);
|
make SCCP timers configurable
The previous hardcoded SCCP timers may cause SCCP connection releases, if the
peer is configured with far lower timers than libosmo-sccp. Testing with a
specific SCCPlite MSC, I experienced an iar of just over three minutes, meaning
that calls would be cut off by the MSC, since the osmo-bsc failed to send an
Inactivity Timer message until seven minutes have passed.
With this patch, SCCP timers are configurable by the user.
Define constant global default timers, and variable user-configurable timers
with each osmo_sccp_instance.
Add VTY UI to configure the timers. Users must call osmo_sccp_vty_init() to get
the sccp-timer config nodes under the 'cs7' node. Show the new UI in
ss7_asp_test.vty.
Note that even though this function is not new at all, until recently, all of
our SCCP users (osmo-bsc, osmo-msc, osmo-sgsn, osmo-hnbgw) failed to call
osmo_sccp_vty_init(), and thus also missed out on the various 'show' commands
defined in sccp_vty.c. In other words, to benefit from the timer
configurability, the patches to call osmo_sccp_vty_init() must first be merged
to the corresponding master branches.
If a 'sccp-timer' config command occurs, the cs7 instance must allocate an SCCP
instance in order to store the timer config. Do that by calling the recently
added osmo_ss7_ensure_sccp() function.
Hence remove the limitation that the SCCP instance must not be populated from
the "simple" setup function. If we want to configure SCCP timers beforehand,
there must be an SCCP instance for that, and there is no hard reason to require
a NULL SCCP instance, besides the desire to prevent this function from being
invoked twice.
Change-Id: I28a7362aa838e648ecc9b26ee53dbcade81a9d65
2018-09-26 15:12:23 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void osmo_sccp_vty_write_cs7_node(struct vty *vty, const char *indent, struct osmo_sccp_instance *inst)
|
|
|
|
{
|
|
|
|
write_sccp_timers(vty, indent, inst, false);
|
SCCP: implement variable limit on Optional Data (CR,CC,CREF,RLSD)
When the Optional Data surpasses 130 bytes, it is not sent as part of
SCCP CR, CC, CREF or RLSD messages, but gets sent separately in a Data
Form 1.
Make this 130 user configurable. This is specified to be 130 bytes
exactly, but to interop with non-conforming peers, make this limit
adjustable per cs7 instance, via osmo_sccp_vty_init().
Add and test new VTY config:
cs7 instance N
sccp max-optional-data (<0-999999>|standard)
Related: ITU-T Q.713 4.2 to 4.5
Related: Ia68dad973ef18513b52f5accb5264c557c7295ea osmo-ttcn3-hacks
Related: SYS#6423
Change-Id: If35697234796af8943691b2de62218e7dc93a08c
2023-04-18 19:59:41 +00:00
|
|
|
if (inst->max_optional_data != SCCP_MAX_OPTIONAL_DATA)
|
|
|
|
vty_out(vty, "%ssccp max-optional-data %u%s", indent, inst->max_optional_data, VTY_NEWLINE);
|
make SCCP timers configurable
The previous hardcoded SCCP timers may cause SCCP connection releases, if the
peer is configured with far lower timers than libosmo-sccp. Testing with a
specific SCCPlite MSC, I experienced an iar of just over three minutes, meaning
that calls would be cut off by the MSC, since the osmo-bsc failed to send an
Inactivity Timer message until seven minutes have passed.
With this patch, SCCP timers are configurable by the user.
Define constant global default timers, and variable user-configurable timers
with each osmo_sccp_instance.
Add VTY UI to configure the timers. Users must call osmo_sccp_vty_init() to get
the sccp-timer config nodes under the 'cs7' node. Show the new UI in
ss7_asp_test.vty.
Note that even though this function is not new at all, until recently, all of
our SCCP users (osmo-bsc, osmo-msc, osmo-sgsn, osmo-hnbgw) failed to call
osmo_sccp_vty_init(), and thus also missed out on the various 'show' commands
defined in sccp_vty.c. In other words, to benefit from the timer
configurability, the patches to call osmo_sccp_vty_init() must first be merged
to the corresponding master branches.
If a 'sccp-timer' config command occurs, the cs7 instance must allocate an SCCP
instance in order to store the timer config. Do that by calling the recently
added osmo_ss7_ensure_sccp() function.
Hence remove the limitation that the SCCP instance must not be populated from
the "simple" setup function. If we want to configure SCCP timers beforehand,
there must be an SCCP instance for that, and there is no hard reason to require
a NULL SCCP instance, besides the desire to prevent this function from being
invoked twice.
Change-Id: I28a7362aa838e648ecc9b26ee53dbcade81a9d65
2018-09-26 15:12:23 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
DEFUN(show_sccp_timers, show_sccp_timers_cmd,
|
|
|
|
"show cs7 instance <0-15> sccp timers",
|
|
|
|
SHOW_STR CS7_STR INST_STR INST_STR
|
|
|
|
"Signaling Connection Control Part\n"
|
|
|
|
"Show List of SCCP timers\n")
|
|
|
|
{
|
|
|
|
int id = atoi(argv[0]);
|
|
|
|
struct osmo_ss7_instance *ss7;
|
|
|
|
|
|
|
|
ss7 = osmo_ss7_instance_find(id);
|
|
|
|
if (!ss7) {
|
|
|
|
vty_out(vty, "No SS7 instance %d found%s", id, VTY_NEWLINE);
|
|
|
|
return CMD_WARNING;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!ss7->sccp) {
|
|
|
|
vty_out(vty, "SS7 instance %d has no SCCP initialized%s", id, VTY_NEWLINE);
|
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
write_sccp_timers(vty, "", ss7->sccp, true);
|
|
|
|
return CMD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2017-04-14 18:16:10 +00:00
|
|
|
void osmo_sccp_vty_init(void)
|
|
|
|
{
|
2020-10-04 09:26:37 +00:00
|
|
|
install_lib_element_ve(&show_sccp_users_cmd);
|
|
|
|
install_lib_element_ve(&show_sccp_user_ssn_cmd);
|
|
|
|
install_lib_element_ve(&show_sccp_connections_cmd);
|
make SCCP timers configurable
The previous hardcoded SCCP timers may cause SCCP connection releases, if the
peer is configured with far lower timers than libosmo-sccp. Testing with a
specific SCCPlite MSC, I experienced an iar of just over three minutes, meaning
that calls would be cut off by the MSC, since the osmo-bsc failed to send an
Inactivity Timer message until seven minutes have passed.
With this patch, SCCP timers are configurable by the user.
Define constant global default timers, and variable user-configurable timers
with each osmo_sccp_instance.
Add VTY UI to configure the timers. Users must call osmo_sccp_vty_init() to get
the sccp-timer config nodes under the 'cs7' node. Show the new UI in
ss7_asp_test.vty.
Note that even though this function is not new at all, until recently, all of
our SCCP users (osmo-bsc, osmo-msc, osmo-sgsn, osmo-hnbgw) failed to call
osmo_sccp_vty_init(), and thus also missed out on the various 'show' commands
defined in sccp_vty.c. In other words, to benefit from the timer
configurability, the patches to call osmo_sccp_vty_init() must first be merged
to the corresponding master branches.
If a 'sccp-timer' config command occurs, the cs7 instance must allocate an SCCP
instance in order to store the timer config. Do that by calling the recently
added osmo_ss7_ensure_sccp() function.
Hence remove the limitation that the SCCP instance must not be populated from
the "simple" setup function. If we want to configure SCCP timers beforehand,
there must be an SCCP instance for that, and there is no hard reason to require
a NULL SCCP instance, besides the desire to prevent this function from being
invoked twice.
Change-Id: I28a7362aa838e648ecc9b26ee53dbcade81a9d65
2018-09-26 15:12:23 +00:00
|
|
|
|
2020-10-04 09:26:37 +00:00
|
|
|
install_lib_element_ve(&show_sccp_timers_cmd);
|
make SCCP timers configurable
The previous hardcoded SCCP timers may cause SCCP connection releases, if the
peer is configured with far lower timers than libosmo-sccp. Testing with a
specific SCCPlite MSC, I experienced an iar of just over three minutes, meaning
that calls would be cut off by the MSC, since the osmo-bsc failed to send an
Inactivity Timer message until seven minutes have passed.
With this patch, SCCP timers are configurable by the user.
Define constant global default timers, and variable user-configurable timers
with each osmo_sccp_instance.
Add VTY UI to configure the timers. Users must call osmo_sccp_vty_init() to get
the sccp-timer config nodes under the 'cs7' node. Show the new UI in
ss7_asp_test.vty.
Note that even though this function is not new at all, until recently, all of
our SCCP users (osmo-bsc, osmo-msc, osmo-sgsn, osmo-hnbgw) failed to call
osmo_sccp_vty_init(), and thus also missed out on the various 'show' commands
defined in sccp_vty.c. In other words, to benefit from the timer
configurability, the patches to call osmo_sccp_vty_init() must first be merged
to the corresponding master branches.
If a 'sccp-timer' config command occurs, the cs7 instance must allocate an SCCP
instance in order to store the timer config. Do that by calling the recently
added osmo_ss7_ensure_sccp() function.
Hence remove the limitation that the SCCP instance must not be populated from
the "simple" setup function. If we want to configure SCCP timers beforehand,
there must be an SCCP instance for that, and there is no hard reason to require
a NULL SCCP instance, besides the desire to prevent this function from being
invoked twice.
Change-Id: I28a7362aa838e648ecc9b26ee53dbcade81a9d65
2018-09-26 15:12:23 +00:00
|
|
|
gen_sccp_timer_cmd_strs(&sccp_timer_cmd);
|
2020-10-04 09:26:37 +00:00
|
|
|
install_lib_element(L_CS7_NODE, &sccp_timer_cmd);
|
SCCP: implement variable limit on Optional Data (CR,CC,CREF,RLSD)
When the Optional Data surpasses 130 bytes, it is not sent as part of
SCCP CR, CC, CREF or RLSD messages, but gets sent separately in a Data
Form 1.
Make this 130 user configurable. This is specified to be 130 bytes
exactly, but to interop with non-conforming peers, make this limit
adjustable per cs7 instance, via osmo_sccp_vty_init().
Add and test new VTY config:
cs7 instance N
sccp max-optional-data (<0-999999>|standard)
Related: ITU-T Q.713 4.2 to 4.5
Related: Ia68dad973ef18513b52f5accb5264c557c7295ea osmo-ttcn3-hacks
Related: SYS#6423
Change-Id: If35697234796af8943691b2de62218e7dc93a08c
2023-04-18 19:59:41 +00:00
|
|
|
install_lib_element(L_CS7_NODE, &sccp_max_optional_data_cmd);
|
2017-04-14 18:16:10 +00:00
|
|
|
}
|