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

631 lines
16 KiB
C
Raw Normal View History

SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
/* SMPP vty interface */
/* (C) 2012 by Harald Welte <laforge@gnumonks.org>
* All Rights Reserved
*
* 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/>.
*
*/
SMPP: Implement support for MO SMS Each ESME can have a number of prefix-matching routes, or it can be a 'default route' to whcih all otherwise unknown SMS destinations are routed.
2012-11-23 18:02:37 +00:00
#include <ctype.h>
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
#include <string.h>
SMPP: Implement support for MO SMS Each ESME can have a number of prefix-matching routes, or it can be a 'default route' to whcih all otherwise unknown SMS destinations are routed.
2012-11-23 18:02:37 +00:00
#include <errno.h>
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
#include <netdb.h>
#include <sys/socket.h>
#include <osmocom/vty/command.h>
#include <osmocom/vty/buffer.h>
#include <osmocom/vty/vty.h>
#include <osmocom/core/linuxlist.h>
#include <osmocom/core/utils.h>
ESME: use osmo_sock_get_name() for logging This allows us to drop single-use parameters from osmo_esme to facilitate further code changes. Related: OS#5568 Change-Id: I34bd4c145b0f6287a323e2350808feb59f1d3187
2022-07-27 13:41:00 +00:00
#include <osmocom/core/socket.h>
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
#include <osmocom/core/talloc.h>
rename include/openbsc to include/osmocom/msc Change-Id: I1f96a1285bbd1b4607614856bca935d5c26e2da9
2017-09-04 13:04:35 +00:00
#include <osmocom/msc/vty.h>
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
#include "smpp_smsc.h"
struct smsc *smsc_from_vty(struct vty *v);
static struct cmd_node smpp_node = {
SMPP_NODE,
"%s(config-smpp)# ",
1,
};
static struct cmd_node esme_node = {
SMPP_ESME_NODE,
"%s(config-smpp-esme)# ",
1,
};
DEFUN(cfg_smpp, cfg_smpp_cmd,
"smpp", "Configure SMPP SMS Interface")
{
vty->node = SMPP_NODE;
return CMD_SUCCESS;
}
sms: Add a way to always route SMS through SMPP systems default-route would only be looked at after there has been no subscriber in the local database. Depending on the setup this is not what one wants. This has been discussed at the OsmoDevCon and there have been hacks in some branches. Let's introduce a VTY command to select if SMPP should be consulted first and then fallback to the current behavior.
2015-07-06 14:41:30 +00:00
DEFUN(cfg_smpp_first, cfg_smpp_first_cmd,
"smpp-first",
"Try SMPP routes before the subscriber DB\n")
{
struct smsc *smsc = smsc_from_vty(vty);
smsc->smpp_first = 1;
return CMD_SUCCESS;
}
DEFUN(cfg_no_smpp_first, cfg_no_smpp_first_cmd,
"no smpp-first",
NO_STR "Try SMPP before routes before the subscriber DB\n")
{
struct smsc *smsc = smsc_from_vty(vty);
smsc->smpp_first = 0;
return CMD_SUCCESS;
}
smpp: refactor initialization, add bind address Make the SMPP bind address configurable (used to be harcoded as "0.0.0.0"). Add VTY command smpp local-tcp A.B.C.D <1-65535> while keeping the old command 'local-tcp-port <1-65535>'. Both the old and the new command immediately change the SMPP listening address and port. Add a LOGL_NOTICE log when the SMPP listening address and/or port change. However, to be useful, this patch has to go somewhat further: refactor the initialization procedure, because it was impossible to run the VTY commands without an already established connection. The SMPP initialization procedure was weird. It would first open a connection on the default port, and a subsequent VTY port reconfiguration while reading the config file would try to re-establish a connection on a different port. If that failed, smpp would switch back to the default port instead of failing the program launch as the user would expect. If anything else ran on port 2775, SMPP would thus refuse to launch despite the config file having a different port: the first bind would always happen on 0.0.0.0:2775. Change that. In the VTY commands, merely store address and port if no fd is established yet. Introduce several SMPP initialization stages: * allocate struct and initialize pointers, * then read config file without immediately starting to listen, * and once the main program is ready, start listening. After that, the VTY command behaves as before: try to re-establish the old connection if the newly supplied address and port don't work out. I'm not actually sure why this switch-back behavior is needed, but fair enough. In detail, replace the function smpp_smsc_init() with the various steps smpp_smsc_alloc_init() -- prepare struct for VTY commands smpp_smsc_conf() -- set addr an port only, for reading the config file smpp_smsc_start() -- establish a first connection, for main() smpp_smsc_restart() -- switch running connection, for telnet VTY smpp_smsc_stop() -- tear down connection, used by _start() twice And replace smpp_openbsc_init() smpp_openbsc_set_net() with smpp_openbsc_alloc_init() smpp_openbsc_start() I'd have picked function names like "_bind"/"_unbind", but in the SMPP protocol there is also a bind/unbind process, so instead I chose the names "_start", "_restart" and "_stop". The smsc struct used to be talloc'd outside of smpp_smsc_init(). Since the smsc code internally uses talloc anyway and employs the smsc struct as talloc context, I decided to enforce talloc allocation within smpp_smsc_alloc_init(). Be stricter about osmo_signal_register_handler() return codes.
2016-02-24 18:15:39 +00:00
static int smpp_local_tcp(struct vty *vty,
const char *bind_addr, uint16_t port)
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
{
struct smsc *smsc = smsc_from_vty(vty);
smpp: refactor initialization, add bind address Make the SMPP bind address configurable (used to be harcoded as "0.0.0.0"). Add VTY command smpp local-tcp A.B.C.D <1-65535> while keeping the old command 'local-tcp-port <1-65535>'. Both the old and the new command immediately change the SMPP listening address and port. Add a LOGL_NOTICE log when the SMPP listening address and/or port change. However, to be useful, this patch has to go somewhat further: refactor the initialization procedure, because it was impossible to run the VTY commands without an already established connection. The SMPP initialization procedure was weird. It would first open a connection on the default port, and a subsequent VTY port reconfiguration while reading the config file would try to re-establish a connection on a different port. If that failed, smpp would switch back to the default port instead of failing the program launch as the user would expect. If anything else ran on port 2775, SMPP would thus refuse to launch despite the config file having a different port: the first bind would always happen on 0.0.0.0:2775. Change that. In the VTY commands, merely store address and port if no fd is established yet. Introduce several SMPP initialization stages: * allocate struct and initialize pointers, * then read config file without immediately starting to listen, * and once the main program is ready, start listening. After that, the VTY command behaves as before: try to re-establish the old connection if the newly supplied address and port don't work out. I'm not actually sure why this switch-back behavior is needed, but fair enough. In detail, replace the function smpp_smsc_init() with the various steps smpp_smsc_alloc_init() -- prepare struct for VTY commands smpp_smsc_conf() -- set addr an port only, for reading the config file smpp_smsc_start() -- establish a first connection, for main() smpp_smsc_restart() -- switch running connection, for telnet VTY smpp_smsc_stop() -- tear down connection, used by _start() twice And replace smpp_openbsc_init() smpp_openbsc_set_net() with smpp_openbsc_alloc_init() smpp_openbsc_start() I'd have picked function names like "_bind"/"_unbind", but in the SMPP protocol there is also a bind/unbind process, so instead I chose the names "_start", "_restart" and "_stop". The smsc struct used to be talloc'd outside of smpp_smsc_init(). Since the smsc code internally uses talloc anyway and employs the smsc struct as talloc context, I decided to enforce talloc allocation within smpp_smsc_alloc_init(). Be stricter about osmo_signal_register_handler() return codes.
2016-02-24 18:15:39 +00:00
int is_running = smsc->listen_ofd.fd > 0;
int same_bind_addr;
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
int rc;
smpp: refactor initialization, add bind address Make the SMPP bind address configurable (used to be harcoded as "0.0.0.0"). Add VTY command smpp local-tcp A.B.C.D <1-65535> while keeping the old command 'local-tcp-port <1-65535>'. Both the old and the new command immediately change the SMPP listening address and port. Add a LOGL_NOTICE log when the SMPP listening address and/or port change. However, to be useful, this patch has to go somewhat further: refactor the initialization procedure, because it was impossible to run the VTY commands without an already established connection. The SMPP initialization procedure was weird. It would first open a connection on the default port, and a subsequent VTY port reconfiguration while reading the config file would try to re-establish a connection on a different port. If that failed, smpp would switch back to the default port instead of failing the program launch as the user would expect. If anything else ran on port 2775, SMPP would thus refuse to launch despite the config file having a different port: the first bind would always happen on 0.0.0.0:2775. Change that. In the VTY commands, merely store address and port if no fd is established yet. Introduce several SMPP initialization stages: * allocate struct and initialize pointers, * then read config file without immediately starting to listen, * and once the main program is ready, start listening. After that, the VTY command behaves as before: try to re-establish the old connection if the newly supplied address and port don't work out. I'm not actually sure why this switch-back behavior is needed, but fair enough. In detail, replace the function smpp_smsc_init() with the various steps smpp_smsc_alloc_init() -- prepare struct for VTY commands smpp_smsc_conf() -- set addr an port only, for reading the config file smpp_smsc_start() -- establish a first connection, for main() smpp_smsc_restart() -- switch running connection, for telnet VTY smpp_smsc_stop() -- tear down connection, used by _start() twice And replace smpp_openbsc_init() smpp_openbsc_set_net() with smpp_openbsc_alloc_init() smpp_openbsc_start() I'd have picked function names like "_bind"/"_unbind", but in the SMPP protocol there is also a bind/unbind process, so instead I chose the names "_start", "_restart" and "_stop". The smsc struct used to be talloc'd outside of smpp_smsc_init(). Since the smsc code internally uses talloc anyway and employs the smsc struct as talloc context, I decided to enforce talloc allocation within smpp_smsc_alloc_init(). Be stricter about osmo_signal_register_handler() return codes.
2016-02-24 18:15:39 +00:00
/* If it is not up yet, don't rebind, just set values. */
if (!is_running) {
rc = smpp_smsc_conf(smsc, bind_addr, port);
if (rc < 0) {
vty_out(vty, "%% Cannot configure new address:port%s",
VTY_NEWLINE);
return CMD_WARNING;
}
return CMD_SUCCESS;
}
rc = smpp_smsc_restart(smsc, bind_addr, port);
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
if (rc < 0) {
smpp: refactor initialization, add bind address Make the SMPP bind address configurable (used to be harcoded as "0.0.0.0"). Add VTY command smpp local-tcp A.B.C.D <1-65535> while keeping the old command 'local-tcp-port <1-65535>'. Both the old and the new command immediately change the SMPP listening address and port. Add a LOGL_NOTICE log when the SMPP listening address and/or port change. However, to be useful, this patch has to go somewhat further: refactor the initialization procedure, because it was impossible to run the VTY commands without an already established connection. The SMPP initialization procedure was weird. It would first open a connection on the default port, and a subsequent VTY port reconfiguration while reading the config file would try to re-establish a connection on a different port. If that failed, smpp would switch back to the default port instead of failing the program launch as the user would expect. If anything else ran on port 2775, SMPP would thus refuse to launch despite the config file having a different port: the first bind would always happen on 0.0.0.0:2775. Change that. In the VTY commands, merely store address and port if no fd is established yet. Introduce several SMPP initialization stages: * allocate struct and initialize pointers, * then read config file without immediately starting to listen, * and once the main program is ready, start listening. After that, the VTY command behaves as before: try to re-establish the old connection if the newly supplied address and port don't work out. I'm not actually sure why this switch-back behavior is needed, but fair enough. In detail, replace the function smpp_smsc_init() with the various steps smpp_smsc_alloc_init() -- prepare struct for VTY commands smpp_smsc_conf() -- set addr an port only, for reading the config file smpp_smsc_start() -- establish a first connection, for main() smpp_smsc_restart() -- switch running connection, for telnet VTY smpp_smsc_stop() -- tear down connection, used by _start() twice And replace smpp_openbsc_init() smpp_openbsc_set_net() with smpp_openbsc_alloc_init() smpp_openbsc_start() I'd have picked function names like "_bind"/"_unbind", but in the SMPP protocol there is also a bind/unbind process, so instead I chose the names "_start", "_restart" and "_stop". The smsc struct used to be talloc'd outside of smpp_smsc_init(). Since the smsc code internally uses talloc anyway and employs the smsc struct as talloc context, I decided to enforce talloc allocation within smpp_smsc_alloc_init(). Be stricter about osmo_signal_register_handler() return codes.
2016-02-24 18:15:39 +00:00
vty_out(vty, "%% Cannot bind to new port %s:%u nor to"
" old port %s:%u%s",
bind_addr? bind_addr : "0.0.0.0",
port,
smsc->bind_addr? smsc->bind_addr : "0.0.0.0",
smsc->listen_port,
VTY_NEWLINE);
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
return CMD_WARNING;
}
smpp: refactor initialization, add bind address Make the SMPP bind address configurable (used to be harcoded as "0.0.0.0"). Add VTY command smpp local-tcp A.B.C.D <1-65535> while keeping the old command 'local-tcp-port <1-65535>'. Both the old and the new command immediately change the SMPP listening address and port. Add a LOGL_NOTICE log when the SMPP listening address and/or port change. However, to be useful, this patch has to go somewhat further: refactor the initialization procedure, because it was impossible to run the VTY commands without an already established connection. The SMPP initialization procedure was weird. It would first open a connection on the default port, and a subsequent VTY port reconfiguration while reading the config file would try to re-establish a connection on a different port. If that failed, smpp would switch back to the default port instead of failing the program launch as the user would expect. If anything else ran on port 2775, SMPP would thus refuse to launch despite the config file having a different port: the first bind would always happen on 0.0.0.0:2775. Change that. In the VTY commands, merely store address and port if no fd is established yet. Introduce several SMPP initialization stages: * allocate struct and initialize pointers, * then read config file without immediately starting to listen, * and once the main program is ready, start listening. After that, the VTY command behaves as before: try to re-establish the old connection if the newly supplied address and port don't work out. I'm not actually sure why this switch-back behavior is needed, but fair enough. In detail, replace the function smpp_smsc_init() with the various steps smpp_smsc_alloc_init() -- prepare struct for VTY commands smpp_smsc_conf() -- set addr an port only, for reading the config file smpp_smsc_start() -- establish a first connection, for main() smpp_smsc_restart() -- switch running connection, for telnet VTY smpp_smsc_stop() -- tear down connection, used by _start() twice And replace smpp_openbsc_init() smpp_openbsc_set_net() with smpp_openbsc_alloc_init() smpp_openbsc_start() I'd have picked function names like "_bind"/"_unbind", but in the SMPP protocol there is also a bind/unbind process, so instead I chose the names "_start", "_restart" and "_stop". The smsc struct used to be talloc'd outside of smpp_smsc_init(). Since the smsc code internally uses talloc anyway and employs the smsc struct as talloc context, I decided to enforce talloc allocation within smpp_smsc_alloc_init(). Be stricter about osmo_signal_register_handler() return codes.
2016-02-24 18:15:39 +00:00
same_bind_addr = (bind_addr == smsc->bind_addr)
|| (bind_addr && smsc->bind_addr
&& (strcmp(bind_addr, smsc->bind_addr) == 0));
if (!same_bind_addr || port != smsc->listen_port) {
vty_out(vty, "%% Cannot bind to new port %s:%u, staying on"
" old port %s:%u%s",
bind_addr? bind_addr : "0.0.0.0",
port,
smsc->bind_addr? smsc->bind_addr : "0.0.0.0",
smsc->listen_port,
VTY_NEWLINE);
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
return CMD_WARNING;
}
return CMD_SUCCESS;
}
smpp: refactor initialization, add bind address Make the SMPP bind address configurable (used to be harcoded as "0.0.0.0"). Add VTY command smpp local-tcp A.B.C.D <1-65535> while keeping the old command 'local-tcp-port <1-65535>'. Both the old and the new command immediately change the SMPP listening address and port. Add a LOGL_NOTICE log when the SMPP listening address and/or port change. However, to be useful, this patch has to go somewhat further: refactor the initialization procedure, because it was impossible to run the VTY commands without an already established connection. The SMPP initialization procedure was weird. It would first open a connection on the default port, and a subsequent VTY port reconfiguration while reading the config file would try to re-establish a connection on a different port. If that failed, smpp would switch back to the default port instead of failing the program launch as the user would expect. If anything else ran on port 2775, SMPP would thus refuse to launch despite the config file having a different port: the first bind would always happen on 0.0.0.0:2775. Change that. In the VTY commands, merely store address and port if no fd is established yet. Introduce several SMPP initialization stages: * allocate struct and initialize pointers, * then read config file without immediately starting to listen, * and once the main program is ready, start listening. After that, the VTY command behaves as before: try to re-establish the old connection if the newly supplied address and port don't work out. I'm not actually sure why this switch-back behavior is needed, but fair enough. In detail, replace the function smpp_smsc_init() with the various steps smpp_smsc_alloc_init() -- prepare struct for VTY commands smpp_smsc_conf() -- set addr an port only, for reading the config file smpp_smsc_start() -- establish a first connection, for main() smpp_smsc_restart() -- switch running connection, for telnet VTY smpp_smsc_stop() -- tear down connection, used by _start() twice And replace smpp_openbsc_init() smpp_openbsc_set_net() with smpp_openbsc_alloc_init() smpp_openbsc_start() I'd have picked function names like "_bind"/"_unbind", but in the SMPP protocol there is also a bind/unbind process, so instead I chose the names "_start", "_restart" and "_stop". The smsc struct used to be talloc'd outside of smpp_smsc_init(). Since the smsc code internally uses talloc anyway and employs the smsc struct as talloc context, I decided to enforce talloc allocation within smpp_smsc_alloc_init(). Be stricter about osmo_signal_register_handler() return codes.
2016-02-24 18:15:39 +00:00
DEFUN(cfg_smpp_port, cfg_smpp_port_cmd,
"local-tcp-port <1-65535>",
"Set the local TCP port on which we listen for SMPP\n"
"TCP port number")
{
struct smsc *smsc = smsc_from_vty(vty);
uint16_t port = atoi(argv[0]);
return smpp_local_tcp(vty, smsc->bind_addr, port);
}
DEFUN(cfg_smpp_addr_port, cfg_smpp_addr_port_cmd,
"local-tcp-ip A.B.C.D <1-65535>",
"Set the local IP address and TCP port on which we listen for SMPP\n"
"Local IP address\n"
"TCP port number")
{
const char *bind_addr = argv[0];
uint16_t port = atoi(argv[1]);
return smpp_local_tcp(vty, bind_addr, port);
}
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
DEFUN(cfg_smpp_sys_id, cfg_smpp_sys_id_cmd,
SMPP: complete the VTY help/documentation As discovered by osmotestconfig.py, a number of SMPP related VTY commands were missing their help/documentation text.
2013-07-21 08:00:28 +00:00
"system-id ID",
"Set the System ID of this SMSC\n"
"Alphanumeric SMSC System ID\n")
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
{
struct smsc *smsc = smsc_from_vty(vty);
if (strlen(argv[0])+1 > sizeof(smsc->system_id))
return CMD_WARNING;
strcpy(smsc->system_id, argv[0]);
return CMD_SUCCESS;
}
DEFUN(cfg_smpp_policy, cfg_smpp_policy_cmd,
"policy (accept-all|closed)",
"Set the authentication policy of this SMSC\n"
Cosmetic: Fix spelling in smpp vty Change-Id: Id3fa3f26c333bf445590fd75ad7a08be68fed3e2
2019-01-17 00:08:33 +00:00
"Accept all SMPP connections independent of system ID / password\n"
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
"Accept only SMPP connections from ESMEs explicitly configured")
{
struct smsc *smsc = smsc_from_vty(vty);
if (!strcmp(argv[0], "accept-all"))
smsc->accept_all = 1;
else
smsc->accept_all = 0;
return CMD_SUCCESS;
}
static int config_write_smpp(struct vty *vty)
{
struct smsc *smsc = smsc_from_vty(vty);
vty_out(vty, "smpp%s", VTY_NEWLINE);
smpp: refactor initialization, add bind address Make the SMPP bind address configurable (used to be harcoded as "0.0.0.0"). Add VTY command smpp local-tcp A.B.C.D <1-65535> while keeping the old command 'local-tcp-port <1-65535>'. Both the old and the new command immediately change the SMPP listening address and port. Add a LOGL_NOTICE log when the SMPP listening address and/or port change. However, to be useful, this patch has to go somewhat further: refactor the initialization procedure, because it was impossible to run the VTY commands without an already established connection. The SMPP initialization procedure was weird. It would first open a connection on the default port, and a subsequent VTY port reconfiguration while reading the config file would try to re-establish a connection on a different port. If that failed, smpp would switch back to the default port instead of failing the program launch as the user would expect. If anything else ran on port 2775, SMPP would thus refuse to launch despite the config file having a different port: the first bind would always happen on 0.0.0.0:2775. Change that. In the VTY commands, merely store address and port if no fd is established yet. Introduce several SMPP initialization stages: * allocate struct and initialize pointers, * then read config file without immediately starting to listen, * and once the main program is ready, start listening. After that, the VTY command behaves as before: try to re-establish the old connection if the newly supplied address and port don't work out. I'm not actually sure why this switch-back behavior is needed, but fair enough. In detail, replace the function smpp_smsc_init() with the various steps smpp_smsc_alloc_init() -- prepare struct for VTY commands smpp_smsc_conf() -- set addr an port only, for reading the config file smpp_smsc_start() -- establish a first connection, for main() smpp_smsc_restart() -- switch running connection, for telnet VTY smpp_smsc_stop() -- tear down connection, used by _start() twice And replace smpp_openbsc_init() smpp_openbsc_set_net() with smpp_openbsc_alloc_init() smpp_openbsc_start() I'd have picked function names like "_bind"/"_unbind", but in the SMPP protocol there is also a bind/unbind process, so instead I chose the names "_start", "_restart" and "_stop". The smsc struct used to be talloc'd outside of smpp_smsc_init(). Since the smsc code internally uses talloc anyway and employs the smsc struct as talloc context, I decided to enforce talloc allocation within smpp_smsc_alloc_init(). Be stricter about osmo_signal_register_handler() return codes.
2016-02-24 18:15:39 +00:00
if (smsc->bind_addr)
vty_out(vty, " local-tcp-ip %s %u%s", smsc->bind_addr,
smsc->listen_port, VTY_NEWLINE);
else
vty_out(vty, " local-tcp-port %u%s", smsc->listen_port,
VTY_NEWLINE);
smpp: Checking an array for NULL will always be false The if (submit->short_message) and if (smsc->system_id) will always be true. Fixes: Coverity CID 1042371, CID 1042372
2013-07-14 06:50:57 +00:00
if (strlen(smsc->system_id) > 0)
smpp_vty: Ensure to not print 'system-id' in openbsc.cfg if its empty ... as an empty system-id would render the openbsc.cfg unparseable on next openbsc start.
2013-01-24 08:54:04 +00:00
vty_out(vty, " system-id %s%s", smsc->system_id, VTY_NEWLINE);
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
vty_out(vty, " policy %s%s",
smsc->accept_all ? "accept-all" : "closed", VTY_NEWLINE);
sms: Add a way to always route SMS through SMPP systems default-route would only be looked at after there has been no subscriber in the local database. Depending on the setup this is not what one wants. This has been discussed at the OsmoDevCon and there have been hacks in some branches. Let's introduce a VTY command to select if SMPP should be consulted first and then fallback to the current behavior.
2015-07-06 14:41:30 +00:00
vty_out(vty, " %ssmpp-first%s",
smsc->smpp_first ? "" : "no ", VTY_NEWLINE);
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
return CMD_SUCCESS;
}
DEFUN(cfg_esme, cfg_esme_cmd,
SMPP: complete the VTY help/documentation As discovered by osmotestconfig.py, a number of SMPP related VTY commands were missing their help/documentation text.
2013-07-21 08:00:28 +00:00
"esme NAME",
"Configure a particular ESME\n"
"Alphanumeric System ID of the ESME to be configured\n")
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
{
struct smsc *smsc = smsc_from_vty(vty);
struct osmo_smpp_acl *acl;
const char *id = argv[0];
if (strlen(id) > 16) {
vty_out(vty, "%% System ID cannot be more than 16 "
"characters long%s", VTY_NEWLINE);
return CMD_WARNING;
}
acl = smpp_acl_by_system_id(smsc, id);
if (!acl) {
acl = smpp_acl_alloc(smsc, id);
if (!acl)
return CMD_WARNING;
}
vty->index = acl;
vty->index_sub = &acl->description;
vty->node = SMPP_ESME_NODE;
return CMD_SUCCESS;
}
DEFUN(cfg_no_esme, cfg_no_esme_cmd,
SMPP: complete the VTY help/documentation As discovered by osmotestconfig.py, a number of SMPP related VTY commands were missing their help/documentation text.
2013-07-21 08:00:28 +00:00
"no esme NAME",
NO_STR "Remove ESME configuration\n"
"Alphanumeric System ID of the ESME to be removed\n")
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
{
struct smsc *smsc = smsc_from_vty(vty);
struct osmo_smpp_acl *acl;
const char *id = argv[0];
acl = smpp_acl_by_system_id(smsc, id);
if (!acl) {
vty_out(vty, "%% ESME with system id '%s' unknown%s",
id, VTY_NEWLINE);
return CMD_WARNING;
}
/* FIXME: close the connection, free data structure, etc. */
smpp_acl_delete(acl);
return CMD_SUCCESS;
}
DEFUN(cfg_esme_passwd, cfg_esme_passwd_cmd,
SMPP: complete the VTY help/documentation As discovered by osmotestconfig.py, a number of SMPP related VTY commands were missing their help/documentation text.
2013-07-21 08:00:28 +00:00
"password PASSWORD",
"Set the password for this ESME\n"
"Alphanumeric password string\n")
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
{
struct osmo_smpp_acl *acl = vty->index;
if (strlen(argv[0])+1 > sizeof(acl->passwd))
return CMD_WARNING;
strcpy(acl->passwd, argv[0]);
return CMD_SUCCESS;
}
DEFUN(cfg_esme_no_passwd, cfg_esme_no_passwd_cmd,
SMPP: complete the VTY help/documentation As discovered by osmotestconfig.py, a number of SMPP related VTY commands were missing their help/documentation text.
2013-07-21 08:00:28 +00:00
"no password",
NO_STR "Remove the password for this ESME\n")
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
{
struct osmo_smpp_acl *acl = vty->index;
memset(acl->passwd, 0, sizeof(acl->passwd));
return CMD_SUCCESS;
}
SMPP: Implement support for MO SMS Each ESME can have a number of prefix-matching routes, or it can be a 'default route' to whcih all otherwise unknown SMS destinations are routed.
2012-11-23 18:02:37 +00:00
static int osmo_is_digits(const char *str)
{
int i;
for (i = 0; i < strlen(str); i++) {
if (!isdigit(str[i]))
return 0;
}
return 1;
}
static const struct value_string route_errstr[] = {
{ -EEXIST, "Route already exists" },
{ -ENODEV, "Route does not exist" },
{ -ENOMEM, "No memory" },
{ -EINVAL, "Invalid" },
{ 0, NULL }
};
static const struct value_string smpp_ton_str_short[] = {
{ TON_Unknown, "unknown" },
{ TON_International, "international" },
{ TON_National, "national" },
{ TON_Network_Specific, "network" },
{ TON_Subscriber_Number,"subscriber" },
{ TON_Alphanumeric, "alpha" },
{ TON_Abbreviated, "abbrev" },
{ 0, NULL }
};
static const struct value_string smpp_npi_str_short[] = {
{ NPI_Unknown, "unknown" },
{ NPI_ISDN_E163_E164, "isdn" },
{ NPI_Data_X121, "x121" },
{ NPI_Telex_F69, "f69" },
{ NPI_Land_Mobile_E212, "e212" },
{ NPI_National, "national" },
{ NPI_Private, "private" },
{ NPI_ERMES, "ermes" },
{ NPI_Internet_IP, "ip" },
{ NPI_WAP_Client_Id, "wap" },
{ 0, NULL }
};
#define SMPP_ROUTE_STR "Configure a route for MO-SMS to be sent to this ESME\n"
SMPP: complete the VTY help/documentation As discovered by osmotestconfig.py, a number of SMPP related VTY commands were missing their help/documentation text.
2013-07-21 08:00:28 +00:00
#define SMPP_ROUTE_P_STR SMPP_ROUTE_STR "Prefix-match route\n"
SMPP: Implement support for MO SMS Each ESME can have a number of prefix-matching routes, or it can be a 'default route' to whcih all otherwise unknown SMS destinations are routed.
2012-11-23 18:02:37 +00:00
#define SMPP_PREFIX_STR "Destination number prefix\n"
#define TON_CMD "(unknown|international|national|network|subscriber|alpha|abbrev)"
#define NPI_CMD "(unknown|isdn|x121|f69|e212|national|private|ermes|ip|wap)"
SMPP: complete the VTY help/documentation As discovered by osmotestconfig.py, a number of SMPP related VTY commands were missing their help/documentation text.
2013-07-21 08:00:28 +00:00
#define TON_STR "Unknown type-of-number\n" \
"International type-of-number\n" \
"National type-of-number\n" \
"Network specific type-of-number\n" \
"Subscriber type-of-number\n" \
"Alphanumeric type-of-number\n" \
"Abbreviated type-of-number\n"
#define NPI_STR "Unknown numbering plan\n" \
"ISDN (E.164) numbering plan\n" \
"X.121 numbering plan\n" \
"F.69 numbering plan\n" \
"E.212 numbering plan\n" \
"National numbering plan\n" \
"Private numbering plan\n" \
"ERMES numbering plan\n" \
"IP numbering plan\n" \
"WAP numbeing plan\n"
SMPP: Implement support for MO SMS Each ESME can have a number of prefix-matching routes, or it can be a 'default route' to whcih all otherwise unknown SMS destinations are routed.
2012-11-23 18:02:37 +00:00
DEFUN(cfg_esme_route_pfx, cfg_esme_route_pfx_cmd,
"route prefix " TON_CMD " " NPI_CMD " PREFIX",
SMPP_ROUTE_P_STR TON_STR NPI_STR SMPP_PREFIX_STR)
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
{
struct osmo_smpp_acl *acl = vty->index;
SMPP: Implement support for MO SMS Each ESME can have a number of prefix-matching routes, or it can be a 'default route' to whcih all otherwise unknown SMS destinations are routed.
2012-11-23 18:02:37 +00:00
struct osmo_smpp_addr pfx;
int rc;
/* check if DESTINATION is all-digits */
if (!osmo_is_digits(argv[2])) {
vty_out(vty, "%% PREFIX has to be numeric%s", VTY_NEWLINE);
return CMD_WARNING;
}
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
SMPP: Implement support for MO SMS Each ESME can have a number of prefix-matching routes, or it can be a 'default route' to whcih all otherwise unknown SMS destinations are routed.
2012-11-23 18:02:37 +00:00
pfx.ton = get_string_value(smpp_ton_str_short, argv[0]);
pfx.npi = get_string_value(smpp_npi_str_short, argv[1]);
snprintf(pfx.addr, sizeof(pfx.addr), "%s", argv[2]);
rc = smpp_route_pfx_add(acl, &pfx);
if (rc < 0) {
vty_out(vty, "%% error adding prefix route: %s%s",
get_value_string(route_errstr, rc), VTY_NEWLINE);
return CMD_WARNING;
}
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
return CMD_SUCCESS;
}
SMPP: Implement support for MO SMS Each ESME can have a number of prefix-matching routes, or it can be a 'default route' to whcih all otherwise unknown SMS destinations are routed.
2012-11-23 18:02:37 +00:00
DEFUN(cfg_esme_no_route_pfx, cfg_esme_no_route_pfx_cmd,
"no route prefix " TON_CMD " " NPI_CMD " PREFIX",
NO_STR SMPP_ROUTE_P_STR TON_STR NPI_STR SMPP_PREFIX_STR)
{
struct osmo_smpp_acl *acl = vty->index;
struct osmo_smpp_addr pfx;
int rc;
/* check if DESTINATION is all-digits */
if (!osmo_is_digits(argv[2])) {
vty_out(vty, "%% PREFIX has to be numeric%s", VTY_NEWLINE);
return CMD_WARNING;
}
pfx.ton = get_string_value(smpp_ton_str_short, argv[0]);
pfx.npi = get_string_value(smpp_npi_str_short, argv[1]);
snprintf(pfx.addr, sizeof(pfx.addr), "%s", argv[2]);
rc = smpp_route_pfx_del(acl, &pfx);
if (rc < 0) {
vty_out(vty, "%% error removing prefix route: %s%s",
get_value_string(route_errstr, rc), VTY_NEWLINE);
return CMD_WARNING;
}
return CMD_SUCCESS;
}
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
DEFUN(cfg_esme_defaultroute, cfg_esme_defaultroute_cmd,
"default-route",
"Set this ESME as default-route for all SMS to unknown destinations")
{
struct osmo_smpp_acl *acl = vty->index;
acl->default_route = 1;
SMPP: Implement support for MO SMS Each ESME can have a number of prefix-matching routes, or it can be a 'default route' to whcih all otherwise unknown SMS destinations are routed.
2012-11-23 18:02:37 +00:00
if (!acl->smsc->def_route)
acl->smsc->def_route = acl;
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
return CMD_SUCCESS;
}
DEFUN(cfg_no_esme_defaultroute, cfg_esme_no_defaultroute_cmd,
"no default-route", NO_STR
SMPP: complete the VTY help/documentation As discovered by osmotestconfig.py, a number of SMPP related VTY commands were missing their help/documentation text.
2013-07-21 08:00:28 +00:00
"Remove this ESME as default-route for all SMS to unknown destinations")
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
{
struct osmo_smpp_acl *acl = vty->index;
acl->default_route = 0;
/* remove currently active default route, if it was created by
* this ACL */
SMPP: Implement support for MO SMS Each ESME can have a number of prefix-matching routes, or it can be a 'default route' to whcih all otherwise unknown SMS destinations are routed.
2012-11-23 18:02:37 +00:00
if (acl->smsc->def_route && acl->smsc->def_route == acl)
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
acl->smsc->def_route = NULL;
return CMD_SUCCESS;
}
SMPP: add missing VTY parameter 'deliver-src-imsi' for ESME the parameter was already used in the code and saved from VTY code, but somehow the functions for parsing it didn't make it into master.
2013-09-02 14:41:00 +00:00
DEFUN(cfg_esme_del_src_imsi, cfg_esme_del_src_imsi_cmd,
"deliver-src-imsi",
Fix some typos in stdout output Change-Id: I0dbb438f3bfbaf9744717cbeec31ceefdd679ee9 Related: OS#1694
2016-12-20 16:38:31 +00:00
"Enable the use of IMSI as source address in DELIVER")
SMPP: add missing VTY parameter 'deliver-src-imsi' for ESME the parameter was already used in the code and saved from VTY code, but somehow the functions for parsing it didn't make it into master.
2013-09-02 14:41:00 +00:00
{
struct osmo_smpp_acl *acl = vty->index;
acl->deliver_src_imsi = 1;
return CMD_SUCCESS;
}
DEFUN(cfg_esme_no_del_src_imsi, cfg_esme_no_del_src_imsi_cmd,
"no deliver-src-imsi", NO_STR
Fix some typos in stdout output Change-Id: I0dbb438f3bfbaf9744717cbeec31ceefdd679ee9 Related: OS#1694
2016-12-20 16:38:31 +00:00
"Disable the use of IMSI as source address in DELIVER")
SMPP: add missing VTY parameter 'deliver-src-imsi' for ESME the parameter was already used in the code and saved from VTY code, but somehow the functions for parsing it didn't make it into master.
2013-09-02 14:41:00 +00:00
{
struct osmo_smpp_acl *acl = vty->index;
acl->deliver_src_imsi = 0;
return CMD_SUCCESS;
}
SMPP: Implement SMPP Osmocom Estensions on MO-SMS An ESME can now be configured in the VTY to enable osmocom-extensions, which will add vendor-specific SMPP TLVs for RxLev/RxQual/ARFCN/IMEI and transmit power to the SMPP DELIVER-SM message type.
2013-03-13 14:29:27 +00:00
DEFUN(cfg_esme_osmo_ext, cfg_esme_osmo_ext_cmd,
"osmocom-extensions",
"Enable the use of Osmocom SMPP Extensions for this ESME")
{
struct osmo_smpp_acl *acl = vty->index;
acl->osmocom_ext = 1;
return CMD_SUCCESS;
}
DEFUN(cfg_esme_no_osmo_ext, cfg_esme_no_osmo_ext_cmd,
"no osmocom-extensions", NO_STR
"Disable the use of Osmocom SMPP Extensions for this ESME")
{
struct osmo_smpp_acl *acl = vty->index;
acl->osmocom_ext = 0;
return CMD_SUCCESS;
}
SMPP: Add new 'dcs_transparent' ESME setting If an ESME has the dcs_transparent config flag, then the TP-DCS of MO-SMS is transparently passed to SMPP and not converted to SMPP specific data_coding values. This is needed in cases where ESMEs actually care about the exact TP-DCS, as the conversion from TP-DCS to SMPP data_coding is not bijective.
2013-05-28 18:58:02 +00:00
DEFUN(cfg_esme_dcs_transp, cfg_esme_dcs_transp_cmd,
"dcs-transparent",
"Enable the transparent pass-through of TP-DCS to SMPP DataCoding")
{
struct osmo_smpp_acl *acl = vty->index;
acl->dcs_transparent = 1;
return CMD_SUCCESS;
}
DEFUN(cfg_esme_no_dcs_transp, cfg_esme_no_dcs_transp_cmd,
"no dcs-transparent", NO_STR
"Disable the transparent pass-through of TP-DCS to SMPP DataCoding")
{
struct osmo_smpp_acl *acl = vty->index;
acl->dcs_transparent = 0;
return CMD_SUCCESS;
}
Make alert notifications vty configurable per ESME Adds (no) alert-notifications as a per-esme vty command, in order to allow some ESMEs to be excluded from alerts. The default is still to send alert notifications to all esme, so no changes are required to the config file to maintain identical operation after this patch. Change-Id: I57f4d268ca6fe6a233f2caaffce62e4aade01274
2019-01-17 00:01:59 +00:00
DEFUN(cfg_esme_alert_notif, cfg_esme_alert_notif_cmd,
"alert-notifications",
smpp: Fix help string in vty for "alert-notifications" Without the 'no' prefix, this command is about enabling, not disabling Change-Id: I3019a0d9271e73030b9d7cd555761e17358ec812
2021-09-25 16:42:23 +00:00
"Enable sending of SMPP Alert Notifications for this ESME")
Make alert notifications vty configurable per ESME Adds (no) alert-notifications as a per-esme vty command, in order to allow some ESMEs to be excluded from alerts. The default is still to send alert notifications to all esme, so no changes are required to the config file to maintain identical operation after this patch. Change-Id: I57f4d268ca6fe6a233f2caaffce62e4aade01274
2019-01-17 00:01:59 +00:00
{
struct osmo_smpp_acl *acl = vty->index;
acl->alert_notifications = 1;
return CMD_SUCCESS;
}
DEFUN(cfg_esme_no_alert_notif, cfg_esme_no_alert_notif_cmd,
"no alert-notifications", NO_STR
"Disable sending of SMPP Alert Notifications for this ESME")
{
struct osmo_smpp_acl *acl = vty->index;
acl->alert_notifications = 0;
return CMD_SUCCESS;
}
SMPP: Add new 'dcs_transparent' ESME setting If an ESME has the dcs_transparent config flag, then the TP-DCS of MO-SMS is transparently passed to SMPP and not converted to SMPP specific data_coding values. This is needed in cases where ESMEs actually care about the exact TP-DCS, as the conversion from TP-DCS to SMPP data_coding is not bijective.
2013-05-28 18:58:02 +00:00
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
static void dump_one_esme(struct vty *vty, struct osmo_esme *esme)
{
vty_out(vty, "ESME System ID: %s, Password: %s, SMPP Version %02x%s",
SMPP: Implement support for MO SMS Each ESME can have a number of prefix-matching routes, or it can be a 'default route' to whcih all otherwise unknown SMS destinations are routed.
2012-11-23 18:02:37 +00:00
esme->system_id, esme->acl ? esme->acl->passwd : "",
esme->smpp_version, VTY_NEWLINE);
ESME: use osmo_sock_get_name() for logging This allows us to drop single-use parameters from osmo_esme to facilitate further code changes. Related: OS#5568 Change-Id: I34bd4c145b0f6287a323e2350808feb59f1d3187
2022-07-27 13:41:00 +00:00
vty_out(vty, " Connection %s%s", osmo_sock_get_name(tall_vty_ctx, esme->wqueue.bfd.fd), VTY_NEWLINE);
SMPP: Implement support for MO SMS Each ESME can have a number of prefix-matching routes, or it can be a 'default route' to whcih all otherwise unknown SMS destinations are routed.
2012-11-23 18:02:37 +00:00
if (esme->smsc->def_route == esme->acl)
vty_out(vty, " Is current default route%s", VTY_NEWLINE);
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
}
DEFUN(show_esme, show_esme_cmd,
"show smpp esme",
Cosmetic: Fix spelling in smpp vty Change-Id: Id3fa3f26c333bf445590fd75ad7a08be68fed3e2
2019-01-17 00:08:33 +00:00
SHOW_STR "SMPP Interface\n" "SMPP External SMS Entity\n")
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
{
struct smsc *smsc = smsc_from_vty(vty);
struct osmo_esme *esme;
llist_for_each_entry(esme, &smsc->esme_list, list)
dump_one_esme(vty, esme);
return CMD_SUCCESS;
}
SMPP: Implement support for MO SMS Each ESME can have a number of prefix-matching routes, or it can be a 'default route' to whcih all otherwise unknown SMS destinations are routed.
2012-11-23 18:02:37 +00:00
static void write_esme_route_single(struct vty *vty, struct osmo_smpp_route *r)
{
switch (r->type) {
case SMPP_ROUTE_PREFIX:
vty_out(vty, " route prefix %s ",
get_value_string(smpp_ton_str_short, r->u.prefix.ton));
vty_out(vty, "%s %s%s",
get_value_string(smpp_npi_str_short, r->u.prefix.npi),
r->u.prefix.addr, VTY_NEWLINE);
break;
case SMPP_ROUTE_NONE:
break;
}
}
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
static void config_write_esme_single(struct vty *vty, struct osmo_smpp_acl *acl)
{
SMPP: Implement support for MO SMS Each ESME can have a number of prefix-matching routes, or it can be a 'default route' to whcih all otherwise unknown SMS destinations are routed.
2012-11-23 18:02:37 +00:00
struct osmo_smpp_route *r;
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
vty_out(vty, " esme %s%s", acl->system_id, VTY_NEWLINE);
if (strlen(acl->passwd))
vty_out(vty, " password %s%s", acl->passwd, VTY_NEWLINE);
if (acl->default_route)
vty_out(vty, " default-route%s", VTY_NEWLINE);
SMPP: Implement support for MO SMS Each ESME can have a number of prefix-matching routes, or it can be a 'default route' to whcih all otherwise unknown SMS destinations are routed.
2012-11-23 18:02:37 +00:00
if (acl->deliver_src_imsi)
vty_out(vty, " deliver-src-imsi%s", VTY_NEWLINE);
SMPP: Implement SMPP Osmocom Estensions on MO-SMS An ESME can now be configured in the VTY to enable osmocom-extensions, which will add vendor-specific SMPP TLVs for RxLev/RxQual/ARFCN/IMEI and transmit power to the SMPP DELIVER-SM message type.
2013-03-13 14:29:27 +00:00
if (acl->osmocom_ext)
vty_out(vty, " osmocom-extensions%s", VTY_NEWLINE);
SMPP: Add new 'dcs_transparent' ESME setting If an ESME has the dcs_transparent config flag, then the TP-DCS of MO-SMS is transparently passed to SMPP and not converted to SMPP specific data_coding values. This is needed in cases where ESMEs actually care about the exact TP-DCS, as the conversion from TP-DCS to SMPP data_coding is not bijective.
2013-05-28 18:58:02 +00:00
if (acl->dcs_transparent)
vty_out(vty, " dcs-transparent%s", VTY_NEWLINE);
Write configuration correctly from vty (alert notifications) The default is [yes] alert-notifications, therefore write "no alert-notifications" in the case that this has been set, in order to preserve configuration after write is called from vty. Change-Id: I079aea96ee83fbf04f782dcab344d41a4ef04657
2019-03-19 14:14:19 +00:00
if (!acl->alert_notifications)
vty_out(vty, " no alert-notifications%s", VTY_NEWLINE);
SMPP: Implement support for MO SMS Each ESME can have a number of prefix-matching routes, or it can be a 'default route' to whcih all otherwise unknown SMS destinations are routed.
2012-11-23 18:02:37 +00:00
llist_for_each_entry(r, &acl->route_list, list)
write_esme_route_single(vty, r);
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
}
static int config_write_esme(struct vty *v)
{
struct smsc *smsc = smsc_from_vty(v);
struct osmo_smpp_acl *acl;
llist_for_each_entry(acl, &smsc->acl_list, list)
config_write_esme_single(v, acl);
return CMD_SUCCESS;
}
int smpp_vty_init(void)
{
install_node(&smpp_node, config_write_smpp);
install_element(CONFIG_NODE, &cfg_smpp_cmd);
sms: Add a way to always route SMS through SMPP systems default-route would only be looked at after there has been no subscriber in the local database. Depending on the setup this is not what one wants. This has been discussed at the OsmoDevCon and there have been hacks in some branches. Let's introduce a VTY command to select if SMPP should be consulted first and then fallback to the current behavior.
2015-07-06 14:41:30 +00:00
install_element(SMPP_NODE, &cfg_smpp_first_cmd);
install_element(SMPP_NODE, &cfg_no_smpp_first_cmd);
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
install_element(SMPP_NODE, &cfg_smpp_port_cmd);
smpp: refactor initialization, add bind address Make the SMPP bind address configurable (used to be harcoded as "0.0.0.0"). Add VTY command smpp local-tcp A.B.C.D <1-65535> while keeping the old command 'local-tcp-port <1-65535>'. Both the old and the new command immediately change the SMPP listening address and port. Add a LOGL_NOTICE log when the SMPP listening address and/or port change. However, to be useful, this patch has to go somewhat further: refactor the initialization procedure, because it was impossible to run the VTY commands without an already established connection. The SMPP initialization procedure was weird. It would first open a connection on the default port, and a subsequent VTY port reconfiguration while reading the config file would try to re-establish a connection on a different port. If that failed, smpp would switch back to the default port instead of failing the program launch as the user would expect. If anything else ran on port 2775, SMPP would thus refuse to launch despite the config file having a different port: the first bind would always happen on 0.0.0.0:2775. Change that. In the VTY commands, merely store address and port if no fd is established yet. Introduce several SMPP initialization stages: * allocate struct and initialize pointers, * then read config file without immediately starting to listen, * and once the main program is ready, start listening. After that, the VTY command behaves as before: try to re-establish the old connection if the newly supplied address and port don't work out. I'm not actually sure why this switch-back behavior is needed, but fair enough. In detail, replace the function smpp_smsc_init() with the various steps smpp_smsc_alloc_init() -- prepare struct for VTY commands smpp_smsc_conf() -- set addr an port only, for reading the config file smpp_smsc_start() -- establish a first connection, for main() smpp_smsc_restart() -- switch running connection, for telnet VTY smpp_smsc_stop() -- tear down connection, used by _start() twice And replace smpp_openbsc_init() smpp_openbsc_set_net() with smpp_openbsc_alloc_init() smpp_openbsc_start() I'd have picked function names like "_bind"/"_unbind", but in the SMPP protocol there is also a bind/unbind process, so instead I chose the names "_start", "_restart" and "_stop". The smsc struct used to be talloc'd outside of smpp_smsc_init(). Since the smsc code internally uses talloc anyway and employs the smsc struct as talloc context, I decided to enforce talloc allocation within smpp_smsc_alloc_init(). Be stricter about osmo_signal_register_handler() return codes.
2016-02-24 18:15:39 +00:00
install_element(SMPP_NODE, &cfg_smpp_addr_port_cmd);
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
install_element(SMPP_NODE, &cfg_smpp_sys_id_cmd);
install_element(SMPP_NODE, &cfg_smpp_policy_cmd);
install_element(SMPP_NODE, &cfg_esme_cmd);
install_element(SMPP_NODE, &cfg_no_esme_cmd);
install_node(&esme_node, config_write_esme);
install_element(SMPP_ESME_NODE, &cfg_esme_passwd_cmd);
install_element(SMPP_ESME_NODE, &cfg_esme_no_passwd_cmd);
SMPP: Implement support for MO SMS Each ESME can have a number of prefix-matching routes, or it can be a 'default route' to whcih all otherwise unknown SMS destinations are routed.
2012-11-23 18:02:37 +00:00
install_element(SMPP_ESME_NODE, &cfg_esme_route_pfx_cmd);
install_element(SMPP_ESME_NODE, &cfg_esme_no_route_pfx_cmd);
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
install_element(SMPP_ESME_NODE, &cfg_esme_defaultroute_cmd);
install_element(SMPP_ESME_NODE, &cfg_esme_no_defaultroute_cmd);
SMPP: add missing VTY parameter 'deliver-src-imsi' for ESME the parameter was already used in the code and saved from VTY code, but somehow the functions for parsing it didn't make it into master.
2013-09-02 14:41:00 +00:00
install_element(SMPP_ESME_NODE, &cfg_esme_del_src_imsi_cmd);
install_element(SMPP_ESME_NODE, &cfg_esme_no_del_src_imsi_cmd);
SMPP: Implement SMPP Osmocom Estensions on MO-SMS An ESME can now be configured in the VTY to enable osmocom-extensions, which will add vendor-specific SMPP TLVs for RxLev/RxQual/ARFCN/IMEI and transmit power to the SMPP DELIVER-SM message type.
2013-03-13 14:29:27 +00:00
install_element(SMPP_ESME_NODE, &cfg_esme_osmo_ext_cmd);
install_element(SMPP_ESME_NODE, &cfg_esme_no_osmo_ext_cmd);
SMPP: Add new 'dcs_transparent' ESME setting If an ESME has the dcs_transparent config flag, then the TP-DCS of MO-SMS is transparently passed to SMPP and not converted to SMPP specific data_coding values. This is needed in cases where ESMEs actually care about the exact TP-DCS, as the conversion from TP-DCS to SMPP data_coding is not bijective.
2013-05-28 18:58:02 +00:00
install_element(SMPP_ESME_NODE, &cfg_esme_dcs_transp_cmd);
install_element(SMPP_ESME_NODE, &cfg_esme_no_dcs_transp_cmd);
Make alert notifications vty configurable per ESME Adds (no) alert-notifications as a per-esme vty command, in order to allow some ESMEs to be excluded from alerts. The default is still to send alert notifications to all esme, so no changes are required to the config file to maintain identical operation after this patch. Change-Id: I57f4d268ca6fe6a233f2caaffce62e4aade01274
2019-01-17 00:01:59 +00:00
install_element(SMPP_ESME_NODE, &cfg_esme_alert_notif_cmd);
install_element(SMPP_ESME_NODE, &cfg_esme_no_alert_notif_cmd);
SMPP: VTY configuration of SMPP code, authentication support
2012-11-20 21:22:04 +00:00
install_element_ve(&show_esme_cmd);
return 0;
}