Commit Graph

31 Commits

Author SHA1 Message Date
Harald Welte a3c639ff5f sms: Introduce VTY-configurable minimum SMS validity period
This is meant as a safeguard against users or user equipment which
doesn't set a reasonable validity period.  Using this setting, the
SMSC administrator can set a minimum SMS validity period. Any SMS
submitted with lower validity period will be extended to that minimum.

Change-Id: I192528a6f9059d158fa12876a247d61bd7edaec8
Related: OS#5567
2022-05-19 19:34:41 +00:00
Harald Welte 2765a18450 sms: Make default SMS validity period configurable via VTY
Change-Id: Ie2c81c1d5795dd9aaf07b9766013f20b01abc762
2022-05-19 19:34:41 +00:00
Harald Welte 53e2e5fe70 sms_queue: Make deletion of messages from DB VTY-configurable
This introduces some VTY settings that determine if delivered
or expired messages should be removed from he SQL database or not.

Change-Id: Id6174875d5c01c40d987077651b27ae1acbcaa93
2022-05-19 19:34:41 +00:00
Harald Welte 1a62db20e7 sms: Give smsc its own VTY config node
The pre-historic sms_queue code used to have very strange aspects,
such as having some parameters (max-failure, max-pending) which could
only be sent from the 'enable' node, but not from a config file.

Before adding more configuration parameters, let's clean this up by
introducing a proper VTY config node for the 'smsc'; move the existing
config commands there and add new ones for max-failure and max-pending.

As the sms_queue data structure is only allocated after the config file
parsing happens, we are introducing a new 'sms_queue_config' data
structure.  This encapsulates the public readable/writable config
parameters.

Change-Id: Ie8e0ab1a9f979337ff06544b9ab3820954d9804a
2022-05-19 19:34:41 +00:00
Harald Welte 505a94a610 Make UTRAN encryption algorithms configurable
Allow the user fine-grained control over which UMTS encryption
algorithms are permitted, rather than always permitting UEA1 and UEA2
or neither.

This brings the handling of UEA in line with the handling of A5 for
GERAN.

Change-Id: I91f9e50f9c1439aa19528f887b83ae9de628fcfd
Closes: OS#4144
Depends: osmo-iuh.git I6d2d033b0427bdc84fee61e0f3cb7b29935214bf
2021-11-05 01:29:05 +01:00
Keith Whyte a1a70be593 Add support for LCLS to the MSC
This commit is largely based on work by
Max <msuraev@sysmocom.de>

Adds LCLS parameters for A-interface transactions
This commit also adds a vty option to facilitate globally
disabling LCLS for all calls on this MSC.

Add a global call reference (GCR) to MNCC and therefore
bump the MNCC version to version 8. (This commit has to be
merged at the same time as the corresponing commit in the
osmo-sip-connector for mncc-external use.)

Depends: osmo-sip-connector Id40d7e0fed9356f801b3627c118150055e7232b1
Change-Id: I705c860e51637b4537cad65a330ecbaaca96dd5b
2021-10-25 10:07:48 +00:00
Eric Wild a7f8020bfa vty: allow A5/4 encryption in config
Add A5/4 to the internal mask of allowed algorithms.

(Not actually working yet, A5/4 implementation follows in other
patches.)

Related: SYS#5324
Change-Id: I5b46aaa8579f8d069ca39caf996a8795ffe63dd7
2021-06-24 01:27:47 +02:00
Alexander Couzens ae167fcc9a Convert paging response timer into an osmocom own X4 timer
All timeout values should use tdef.

Change-Id: Ic050eb49ba0c5811b43d8d8b44145a1115fd8546
2020-09-26 21:45:09 +02:00
Pau Espin 047c5d9dc8 tests: Fix VTY results after switch to newer libosmo-mgcp-client
In this case we are fine with simply updating test result because anyway
ABI breakage in some libosmo-mgcp-client structs was needed, so new
versions of osmo-msc will require new versions of libosmo-mgcp-client.

Change-Id: I1fbdb95f71d3b9a2dc88e1ba79892ae16485aa99
2020-09-09 13:18:40 +02:00
Keith Whyte 1587ffbc7b vty: allow configuring db path from cfg file
So far, the cmdline argument was the only way to set a database file.
Add a similar config to VTY as 'msc' / 'sms-database'. The cmdline arg is stronger
than the 'database' cfg item. DB is not reloaded from VTY command.

Change-Id: I18d954c30fcceb0b36a620b927fd3a93dcc79f49
2020-08-28 16:25:14 +02:00
Neels Hofmeyr 9aac5c2d21 add rudimentary NRI support for MSC pooling
This patch served for a manual testing counterpart for osmo-bsc to implement
MSC pooling.

This enables a basic MSC pooling setup, but for a production setup, osmo-msc
would still lack various features related to unloading subscribers to another
MSC as explained in 3GPP TS 23.236.

Change-Id: Iafe0878a0a2c8669080d757b34a398ea75fced36
2020-06-19 03:58:13 +02:00
Philipp Maier 72b8c38287 doc: do not use random ip-address for MGW
The example configs suggest to use a random ip-address as MGW address.
Lets use a loopback address here. This will suit the usual case where
MGW and MSC run together on the same machine.

Change-Id: Ie2b2094fdcfed45353d9ba22cb07eed626fd143c
2020-04-14 13:14:35 +00:00
Vadim Yanitskiy fc2b019cd8 libmsc: move subscriber expiration timer T3212 to libvlr
Since the split of OsmoNiTB, OsmoMSC does not deal with the radio
access network directly. Therefore the only purpose of T3212 is to
control subscriber expiration in the local VLR. The timeout value
indicated in System Information Type 3 needs to be configured
separately in the BSC/RNC.

This means that we don't need to store it in deci-hours anymore.
Let's move T3212 to the group of VLR specific timers, so it can
be configured and introspected using the generic 'timer' command,
and deprecate the old '[no] periodic location update' command.

It should be also noted that in the old code subscriber expiration
timeout was actually set to twice the T3212 value plus one minute.
After this change, we apply the configured value 'as-is', but
keep the old behaviour for 'periodic location update' command.

Change-Id: I9b12066599a7c834a53a93acf5902d91273bc74f
2020-01-25 12:49:42 +07:00
Vadim Yanitskiy baf71a72ec libvlr: use generic osmo_tdef API for T3250, T3260, and T3270
These timers so far were implemented as a list of unsigned integers,
which has never been initialized to any reasonable defaults. Since
they are used as state timeouts in several FSMs, we might end up
staying in some state forever.

Let's migrate to generic osmo_tdef API and use default values from
table 11.2 of 3GPP TS 24.008. This way the user can introspect and
change their values from the VTY / configuration file.

Change-Id: Ia8cf98da0aea0e626c5ff088a833d7359c43847f
Related: OS#4368
2020-01-25 10:52:26 +07:00
Vadim Yanitskiy ffc7f39f01 VTY: add osmo_tdef introspection and configuration commands
This change introduces several new VTY commands letting the user
a possibility to introspect and reconfigure some of the existing
timers implemented using libosmocore's osmo_tdef API.

At the moment this covers the following timers:

  - MGW specific timers:
    - X1 - MGCP response timeout,
    - X2 - RTP stream establishing timeout,

  - RAN specific timers (same names for GERAN and UTRAN):
    - X1 - Authentication and Ciphering timeout,
    - X2 - RAN connection release sanity timeout,
    - X3 - Handover procedure timeout.

The following commands are introduced:

  - 'enable' node:
    - show timer [(mgw|mncc|sccp|geran|utran|sgs)] [TNNNN]

  - 'config-msc' node:
    - timer [(mgw|mncc|sccp|geran|utran|sgs)] [TNNNN] [(<0-2147483647>|default)]

Both MNCC and SCCP related timer definitions are empty at the
moment. Achieved by using osmo_tdef_group API of libosmovty.

Change-Id: I6024c104b6101666c8aa1108a043910eb75db9a5
Related: OS#4368
2020-01-25 10:24:14 +07:00
Keith Whyte 991bb422d4 Implement a global switch on the network to disable call waiting.
Add a network -> callwaiting VTY command as boolean.

When this is enabled (default) there is no change to
operation previous to this commit.

When this switch is disabled with "no call-waiting" in vty
then when a call arrives, we will check if we have an active
call transaction for this subscriber, no matter if it is
establishing, established, or alerting, in any of these cases we
will return USER BUSY to the calling party.

Change-Id: I3eb6f23f7103e3002874fb5d3a30c9de952202ae
2019-09-03 11:47:13 +00:00
Neels Hofmeyr 4dfb2babf2 add 'encryption uea 1 2' cfg / fix ttcn3 iu tests
Recently, the ability to run UTRAN without encryption was added, but the config
for it was tied to the A5 GERAN encryption configuration. This affected
osmo-msc's default behavior of Iu, breaking osmo-msc ttcn3 Iu tests: the ttcn3
test suite sets A5 to 0 (no encryption) but still expects Iu to enable air
encryption. Fix this "regression".

Add a separate vty config option for UEA encryption, even if it does not
provide full granularity to select individual UEA algorithms yet.

As a result, Iu default behavior remains to enable encryption regardless of the
A5 config. UTRAN encryption can be disabled by the new cfg option
"encryption uea 0" alone.

Even though the new vty command already allows passing various combinations of
the UEA algorithm numbers, only '0' and '1 2' are accepted as valid
combinations, to reflect current osmo-msc capabilities.

Revert most changes to the msc_vlr test suite in commit "do not force
encryption on UTRAN" (I04ecd7a3b1cc603b2e3feb630e8c7c93fc36ccd7): use new
net->iu_encryption instead of net->a5_encryption_mask.

Adjust/add to test_nodes.vty transcript tests.

Related: OS#4144
Change-Id: Ie138f2fcb105533f7bc06a6d2e6deccf6faccc5b
2019-08-13 23:52:31 +02:00
Pau Espin 4faff9ef86 vty: Add option to enable osmux towards BSCs
Change-Id: I6de1be0322ddbdc115074ebb6be2598ebf6c95db
2019-05-19 07:28:02 +00:00
Oliver Smith 03ded913ad vty: make retrieve-imeisv-early configurable
Prepare for Rhizomatica's subscriber on demand use case, in which the
network access is disabled by default for new subscribers, but the IMEI
is required in the HLR to find out which user has which IMSI. Due to the
network access being disabled, the location update request towards the
HLR fails and the MS gets rejected, so we need to get the IMEI early.

Related: OS#2542, OS#3755
Change-Id: I256224194c3b8caf2b58a88d11dccd32c569201f
2019-05-15 08:43:39 +00:00
Neels Hofmeyr c4628a3ad4 large refactoring: support inter-BSC and inter-MSC Handover
3GPP TS 49.008 '4.3 Roles of MSC-A, MSC-I and MSC-T' defines distinct roles:
- MSC-A is responsible for managing subscribers,
- MSC-I is the gateway to the RAN.
- MSC-T is a second transitory gateway to another RAN during Handover.

After inter-MSC Handover, the MSC-I is handled by a remote MSC instance, while
the original MSC-A retains the responsibility of subscriber management.

MSC-T exists in this patch but is not yet used, since Handover is only prepared
for, not yet implemented.

Facilitate Inter-MSC and inter-BSC Handover by the same internal split of MSC
roles.

Compared to inter-MSC Handover, mere inter-BSC has the obvious simplifications:
- all of MSC-A, MSC-I and MSC-T roles will be served by the same osmo-msc
  instance,
- messages between MSC-A and MSC-{I,T} don't need to be routed via E-interface
  (GSUP),
- no call routing between MSC-A and -I via MNCC necessary.

This is the largest code bomb I have submitted, ever. Out of principle, I
apologize to everyone trying to read this as a whole. Unfortunately, I see no
sense in trying to split this patch into smaller bits. It would be a huge
amount of work to introduce these changes in separate chunks, especially if
each should in turn be useful and pass all test suites. So, unfortunately, we
are stuck with this code bomb.

The following are some details and rationale for this rather huge refactoring:

* separate MSC subscriber management from ran_conn

struct ran_conn is reduced from the pivotal subscriber management entity it has
been so far to a mere storage for an SCCP connection ID and an MSC subscriber
reference.

The new pivotal subscriber management entity is struct msc_a -- struct msub
lists the msc_a, msc_i, msc_t roles, the vast majority of code paths however
use msc_a, since MSC-A is where all the interesting stuff happens.

Before handover, msc_i is an FSM implementation that encodes to the local
ran_conn. After inter-MSC Handover, msc_i is a compatible but different FSM
implementation that instead forwards via/from GSUP. Same goes for the msc_a
struct: if osmo-msc is the MSC-I "RAN proxy" for a remote MSC-A role, the
msc_a->fi is an FSM implementation that merely forwards via/from GSUP.

* New SCCP implementation for RAN access

To be able to forward BSSAP and RANAP messages via the GSUP interface, the
individual message layers need to be cleanly separated. The IuCS implementation
used until now (iu_client from libosmo-ranap) did not provide this level of
separation, and needed a complete rewrite. It was trivial to implement this in
such a way that both BSSAP and RANAP can be handled by the same SCCP code,
hence the new SCCP-RAN layer also replaces BSSAP handling.

sccp_ran.h: struct sccp_ran_inst provides an abstract handler for incoming RAN
connections. A set of callback functions provides implementation specific
details.

* RAN Abstraction (BSSAP vs. RANAP)

The common SCCP implementation did set the theme for the remaining refactoring:
make all other MSC code paths entirely RAN-implementation-agnostic.

ran_infra.c provides data structures that list RAN implementation specifics,
from logging to RAN de-/encoding to SCCP callbacks and timers. A ran_infra
pointer hence allows complete abstraction of RAN implementations:

- managing connected RAN peers (BSC, RNC) in ran_peer.c,
- classifying and de-/encoding RAN PDUs,
- recording connected LACs and cell IDs and sending out Paging requests to
  matching RAN peers.

* RAN RESET now also for RANAP

ran_peer.c absorbs the reset_fsm from a_reset.c; in consequence, RANAP also
supports proper RESET semantics now. Hence osmo-hnbgw now also needs to provide
proper RESET handling, which it so far duly ignores. (TODO)

* RAN de-/encoding abstraction

The RAN abstraction mentioned above serves not only to separate RANAP and BSSAP
implementations transparently, but also to be able to optionally handle RAN on
distinct levels. Before Handover, all RAN messages are handled by the MSC-A
role.  However, after an inter-MSC Handover, a standalone MSC-I will need to
decode RAN PDUs, at least in order to manage Assignment of RTP streams between
BSS/RNC and MNCC call forwarding.

ran_msg.h provides a common API with abstraction for:

- receiving events from RAN, i.e. passing RAN decode from the BSC/RNC and
  MS/UE: struct ran_dec_msg represents RAN messages decoded from either BSSMAP
  or RANAP;
- sending RAN events: ran_enc_msg is the counterpart to compose RAN messages
  that should be encoded to either BSSMAP or RANAP and passed down to the
  BSC/RNC and MS/UE.

The RAN-specific implementations are completely contained by ran_msg_a.c and
ran_msg_iu.c.

In particular, Assignment and Ciphering have so far been distinct code paths
for BSSAP and RANAP, with switch(via_ran){...} statements all over the place.
Using RAN_DEC_* and RAN_ENC_* abstractions, these are now completely unified.

Note that SGs does not qualify for RAN abstraction: the SGs interface always
remains with the MSC-A role, and SGs messages follow quite distinct semantics
from the fairly similar GERAN and UTRAN.

* MGW and RTP stream management

So far, managing MGW endpoints via MGCP was tightly glued in-between
GSM-04.08-CC on the one and MNCC on the other side. Prepare for switching RTP
streams between different RAN peers by moving to object-oriented
implementations: implement struct call_leg and struct rtp_stream with distinct
FSMs each. For MGW communication, use the osmo_mgcpc_ep API that has originated
from osmo-bsc and recently moved to libosmo-mgcp-client for this purpose.
Instead of implementing a sequence of events with code duplication for the RAN
and CN sides, the idea is to manage each RTP stream separately by firing and
receiving events as soon as codecs and RTP ports are negotiated, and letting
the individual FSMs take care of the MGW management "asynchronously". The
caller provides event IDs and an FSM instance that should be notified of RTP
stream setup progress. Hence it becomes possible to reconnect RTP streams from
one GSM-04.08-CC to another (inter-BSC Handover) or between CC and MNCC RTP
peers (inter-MSC Handover) without duplicating the MGCP code for each
transition.

The number of FSM implementations used for MGCP handling may seem a bit of an
overkill. But in fact, the number of perspectives on RTP forwarding are far
from trivial:
- an MGW endpoint is an entity with N connections, and MGCP "sessions" for
  configuring them by talking to the MGW;
- an RTP stream is a remote peer connected to one of the endpoint's
  connections, which is asynchronously notified of codec and RTP port choices;
- a call leg is the higher level view on either an MT or MO side of a voice
  call, a combination of two RTP streams to forward between two remote peers.

  BSC                 MGW                PBX
                CI          CI
                [MGW-endpoint]
  [--rtp_stream--]          [--rtp_stream--]
  [----------------call_leg----------------]

* Use counts

Introduce using the new osmo_use_count API added to libosmocore for this
purpose. Each use token has a distinct name in the logging, which can be a
globally constant name or ad-hoc, like the local __func__ string constant.  Use
in the new struct msc_a, as well as change vlr_subscr to the new osmo_use_count
API.

* FSM Timeouts

Introduce using the new osmo_tdef API, which provides a common VTY
implementation for all timer numbers, and FSM state transitions with the
correct timeout. Originated in osmo-bsc, recently moved to libosmocore.

Depends: Ife31e6798b4e728a23913179e346552a7dd338c0 (libosmocore)
         Ib9af67b100c4583342a2103669732dab2e577b04 (libosmocore)
	 Id617265337f09dfb6ddfe111ef5e578cd3dc9f63 (libosmocore)
	 Ie9e2add7bbfae651c04e230d62e37cebeb91b0f5 (libosmo-sccp)
	 I26be5c4b06a680f25f19797407ab56a5a4880ddc (osmo-mgw)
	 Ida0e59f9a1f2dd18efea0a51680a67b69f141efa (osmo-mgw)
	 I9a3effd38e72841529df6c135c077116981dea36 (osmo-mgw)
Change-Id: I27e4988e0371808b512c757d2b52ada1615067bd
2019-05-08 17:02:32 +02:00
Vadim Yanitskiy 4d75877e61 libmsc/sgs_vty.c: always write server address and VLR name
Comparing an array to null is not useful, because the expression
will always evaluate as true. Let's just always write SGs server
address and VLR name, no mater whether default values are used
or not, same as we do for the HLR address and port.

Change-Id: If045e42fca0315b0777eb86c44bf934ce58b340b
Fixes: CID#190871 Array compared against 0 (NO_EFFECT)
2019-02-28 00:14:15 +07:00
Vadim Yanitskiy 64623e1848 libmsc/gsm_09_11.c: implement guard timer for NCSS sessions
It may happen that either the MS or an EUSE would become
unresponsive during a call independent SS session, e.g.
due to a bug, or a dropped message. In such cases, the
corresponding transaction would remain unfreed forever.

This change introduces a guard timer, that prevents keeping
'stalled' NCSS sessions forever. As soon as it expires, both
sides (i.e. MS and EUSE) are getting notified, and the
transaction is being released.

By default, the timer expires after 30 seconds. As soon as
either the MS, or an EUSE initiates any activity,
the watchdog timer is rescheduled.

The timeout value can be configured from the VTY:

  msc
   ...
   ! Use 0 to disable this timer
   ncss guard-timeout 30

Please note that changing the timeout value at run-time
doesn't affect the existing NCSS sessions, excepting the
case when the timer is disabled at run-time.

This change makes TC_lu_and_ss_session_timeout pass.

Change-Id: Icf4d87c45e90324764073e8230e0fb9cb96dd9cb
Related Change-Id: (TTCN) I3e1791773d56617172ae27a46889a1ae4d400e2f
Related: OS#3655
2019-02-20 03:22:38 +07:00
Harald Welte 0df904dea9 Add SGs Interface
Add an SGs interface (3GPP TS 29.118) to osmo-msc in order to support
SMS tunneling and Circuit Switched Fallback (CSFB)

Change-Id: I73359925fc1ca72b33a1466e6ac41307f2f0b11d
Related: OS#3615
2019-02-04 13:36:26 +01:00
Oliver Smith 0fec28a506 msc_vty.c: make check-imei-rqd configurable
Related: OS#3189
Change-Id: Iee516b9cd7877b21207ce9a6d954109f19558163
2019-01-09 14:33:35 +00:00
Neels Hofmeyr 3a3ed9b704 vty cfg: move 'ipa-name' from 'msc' to 'hlr' section
during code review, I completely overlooked this:

We've added the 'ipa-name', which identifies the MSC on the GSUP link to the
HLR, under the 'msc' section, while all other GSUP/HLR related config is under
the 'hlr' section.

Before we roll that out in a release, move it over to 'hlr'.

Related: OS#3355
Change-Id: I1a572865aa90c5fa43c6f57282a6e2b06776e425
2019-01-04 16:32:21 +00:00
Vadim Yanitskiy f40e46fdf4 libmsc/VTY: introduce kill-switch for routing SMS over GSUP
As a rudiment of OsmoNiTB, OsmoMSC is still involved in SMS
processing, storage (in SQLite DB), and routing (via SMPP).
In real networks this is done by the external entity called
SMSC (SMS Centre), while the MSC is doing re-encapsulation
of GSM 04.11 SM-TL (Transport Layer) payload (i.e. TPDU)
between SM-RL (Relay Layer) and MAP.

Since OsmoMSC itself is not a 'Network in The Box' anymore, it
makes sense to replicate the 'traditional' behaviour of MSC.
The problem is that this behaviour cannot co-exist with the
current implementation, so the key idea is to rip out the
local SMS storage and routing from OsmoMSC, and (re)implement
it in a separate process (OsmoSMSC?).

As a temporary solution, this change introduces a 'kill-switch'
VTY option that enables routing of SMS messages over GSUP
towards ESME (through VLR and HLR), but breaks the local
storage and routing. This is why it's disabled by default.

As soon as we move the SMS processing and storage away from
OsmoMSC, this behaviour would be enabled by default, and
the VTY option would be hidden and deprecated. At the moment,
this option basically does nothing, and will take an effect
in the follow-up changes.

Change-Id: Ie57685ed2ce1e4c978e775b68fdffe58de44882b
Related: OS#3587
2018-12-30 11:48:22 +01:00
Neels Hofmeyr b12b6cb006 fix test_nodes.vty after libosmo-mgcp-client vty changes
osmo-mgw I98a9f1f17a1c4ab20cea3b08c7d21663592134d6 broke the build here. Fix
that.

Change-Id: I20e37c5228928b67e67f16aef0eb2930d21ef60a
2018-12-20 04:42:10 +01:00
Stefan Sperling afa030d6f9 make gsup ipa name configurable in osmo-msc.cfg
Add a 'ipa-name' VTY command which overrides the default IPA name
used by the MSC. This is a prerequisite for inter-MSC handover.

Related: OS#3355
Change-Id: I317d6c59f77e92fbb2b875a83dc0ec2fa5cb6006
2018-12-11 13:08:00 +00:00
Neels Hofmeyr 80447ebe6c add VTY commands: mncc internal / external (== -M)
So far the only way to use external MNCC is to pass the -M cmdline arg:

  osmo-msc -M /path/to/socket

However, the osmo-msc.service file for systemd is installed by 'make install',
and hence it is quite impractical to depend on such a config item to be
required in the service file:

- It defies any scheme an operator may have in place to compose the
  osmo-msc.cfg file -- this option doesn't go in the .cfg file but needs
  separate action to add to the installed service file.

- After a make install or package upgrades / re-installations, this option will
  be plain overwritten silently, or lead to the need for resolving file
  conflicts.

The initial spark for this came from configuring the 35c3 GSM from cfg
templates.

Change-Id: I2ec59d5eba407f83295528b51b93678d446b9cee
2018-12-05 19:35:11 +00:00
Neels Hofmeyr 05c5680ba1 vty: mncc cfg: separate the 'mncc' from 'mncc-guard-timeout'
I want to add 'mncc internal' and 'mncc external' commands, and IMHO makes most
sense to have a common 'mncc' keyword to start MNCC config commands with. To
put it in terms of VTY online help:

  OsmoMSC(config-msc)# mncc ?
    internal       Use internal MNCC handler
    external       Use internal MNCC handler
    guard-timeout  Set global guard timeout

So far only the 'guard-timeout' exists, I want to add 'internal' and 'external'
in a subsequent commit.

Keep the old command 'mncc-guard-timeout' as deprecated alias. That means it
still works from old config files, but online documentation will omit it.

On 'write', write back the new format instead.

Rationale: see I2ec59d5eba407f83295528b51b93678d446b9cee

Change-Id: I52d69af48e1ddc87b3fb54bf66a01b1b8cbf5abe
2018-12-05 19:35:11 +00:00
Neels Hofmeyr 18333fa5a5 add test_nodes.vty transcript test
It needs to work whether SMPP,Iu are enable or disabled, hence a bit more
wildcarding than one might expect.

Change-Id: I3a8c50d8d555b6b948d97d6412e17594ee439de0
2018-12-05 19:35:11 +00:00