Allowing a whole line of characters as address book name would be a lot,
allowing 512 characters is completely ridiculous. That's more than this entire
commit log message! 32 is plenty.
All linking programs should automatically get the limitation in their VTY
parsing without any changes.
Configs with sccp-addr names > 31 chars will no longer work after this.
Change-Id: I3ecf83d620e46f7bf9857fc60a93d4e240ee3b8a
When entering an 'cs7' / 'asp' node, and invoking 'do show cs7 i 0 asp', the
ASP's FSM instance is not yet allocated. Hence attempting to print its status
will result in a segfault.
Spotted this while writing VTY tests that will follow shortly in another patch
(I6a28684fa24d6e7de568623444297028eba2ab8c).
Change-Id: I3ebf498492c6ba69a5dd1c9f36acdabfd6fbdfe1
In osmo-stp, cmd "local-ip" inside node "listen m3ua 2905" was actually
not being applied, because the server was created + bound at "listen" command
time using NULL as IP, and at "local-ip" time the IP was changed but the
server was not re-bound using the new IP, so it kept listening at
0.0.0.0.
With this patch, we defer binding the socket to "local-ip" cmd time,
after the IP has been applied.
As a result, if no "local-ip" command is provided, then the bind never
happens, which means it is now mandatory that users of osmo_ss7_xua_server_create
API not using osmo_ss7_xua_server_set_local_host call new provided API
osmo_ss7_xua_server_bind. Another new API osmo_ss7_bind_all_instances is
provided to easily make sure all servers are bound after configuration
process. This is specially important for servers which doesn't contain
the "local-ip" parameter.
Users of osmo_sccp_simple_server API are not affected by this change,
and they not requrie to call any new API.
Furthermore, using osmo_ss7_xua_server_bind in VTY code ensures the xUA
server is automatically bound to the new address if the operator changes
the "local-ip" cmd at runtime.
Related: OS#2647
Change-Id: I79738963d633bec70705ff159c5b2127cd498aa2
So far, the config would log an error upon config parsing, and then continue to
use defaults, which is super easy to miss. On errors, return CMD_ERR_INCOMPLETE
to abort the program in a config parsing error.
Be fatal for re-using an already defined addressbook entry in another cs7
instance, and for having a too long addressbook entry name.
Though it is mixing in cosmetic changes, add "Error:" to the output and arrange
the erratic name to the end of the message, as is customary for error messages.
Related: osmo-bsc Ia4e58902a2d3757b266cf35ac89f256cfb8f0eec
Change-Id: I2f71b9c4dd30f919d2054da81283dd7035f44f60
vty_install_default() and install_default() will soon be deprecated.
Depends: I5021c64a787b63314e0f2f1cba0b8fc7bff4f09b
Change-Id: I185aa3a11cb63c893ed80f326f852bde95217321
We can set the ASP's remote IP (i.e. where to reach osmo-stp), but so far the
only way to specify the local IP address to bind to can only be set from C code
(e.g. the simple client). Allow setting the local address via VTY.
For example, this is desired for the osmo-gsm-tester, to not use arbitrary IP
addresses.
Change-Id: I3f71897dfacafcf3126e51894d6ca756b02dcd7d
The VTY definition for this command is flawed and breaks osmo-msc VTY tests.
The small problem is a stray '}' in the definition, the bigger problem is that
square brackets indicating optional arguments must not enclose more than one
argument.
Split up the command in several separate definitions with si arg, with ssn arg,
with both, and with neither.
If si and/or ssn are not passed, set them to zero.
See https://lists.osmocom.org/pipermail/openbsc/2017-August/011026.html
"optional vty items are stricter than expected"
Change-Id: Idc68bfae5457960a9eae5d9648586d6ce719ad68
A doc element is missing, which fails the VTY tests in osmo-msc at Change-Id
I5ae4e05ee7c57cad341ea5e86af37c1f6b0ffa77.
Change-Id: I16aa74244ed5332bdc1fddd538e17b86f62ec3b2
The asp->cfg.remote.host is allowed to be NULL in cases where the
localhost is used.
Check if asp->cfg.remote.host is NULL when writing the config file
and omit it when it is set to NULL.
Change-Id: I18f79cc4d4f1db8f2858e8e95098c5821d50594f
The SG (signal gateway) requires an extra set of VTY commands in
order to be fully configurable. These VTY commands do not make
sense in a situation where libosmo-sccp is used to implement an
ASP (application server process).
Detect in which role libosmo-sccp is used by which of the VTY
initalization functions are called:
osmo_ss7_vty_init_asp() ==> ASP
osmo_ss7_vty_init_sg() ==> SG
Prevent writing back of SG specific configuration when in
running as ASP. Only write back the full parameter set when
running as SG.
Change-Id: I707bcd790f4c6d0f618e41163b51d2179ea3aeaf
Allows to automatically set an RI in future change
I75c67d289693f1c2a049ac61cf2b2097d6e5687d
"sccp-addr vty: set RI to SSN_PC when setting a point-code"
Change-Id: I6e2f31b023b08cba2f2ee8234e6108efcaca41c0
Initialize osmo_ss7_instance.cfg.primary_pc = OSMO_SS7_PC_INVALID.
Adjust all code paths using primary_pc to ensure it is indeed valid.
Rationale:
It looks like we are going to use the primary point-code of an SS7 instance to
derive a local SCCP address, e.g. for osmo-bsc and osmo-hnbgw.
cs7-instance 1
point-code 1.2.3 ! sets osmo_ss7_instance.primary_pc = 1.2.3
sccp-address msc
point-code 0.0.1
routing-indicator PC
hnb
iucs
remote-addr msc ! derives cs7 instance 1 and local pc 1.2.3
If 'point-code 1.2.3' is omitted, this becomes '0.0.0' without the user
noticing, and this happens for each client that omits it. I would like to barf
when no local PC is set.
Change-Id: I7f0f0c89b7335d9da24161bfac8234be214ca00c
Drop the separate osmo_ss7_set_vty_alloc_ctx() because we are likely to forget
calling it. Instead, incorporate into osmo_ss7_vty_init_*() with a new ctx arg,
and set the static context var in vty_init_shared().
Change-Id: Id4e7f47979001f7856b0b3665c9e94982e75e490
It is possible to add two (or more) different
sccp-addresses under the same name, when the
addresses are defined in different cs7 instances.
Add a check to make sure an address name is not
used multiple times
Change-Id: I63227cd87bc24f7d9ac995430b869f0393818335
The sccp-addressbook only allows defining addresses for a specific
ss7 instance. It is not possible to use an sscp-address, that is
defined in the one ss7 instance in another ss7 instance.
Add a second global list where all sscp-addresses are added,
regardless on which instance they are defined.
Fixup the search functions so that they always search the global
list.
Change the API, so that the address data is written to a
destination pointer. This protects the stored address from
unintentional changes. Also return the ss7 instance, where the
address is associated with.
Change-Id: I5acc1e5abc3b3081149a9f476038e4e53d23b763
The installation of the vty commands for the sccp addressbook is
currently located in osmo_ss7_vty_init_sg(), which is normally
only used in signalling gateway applications. An ASP would lack
the addressbook functionality.
Make SCCP addressbook available for both SG and ASP
Change-Id: Ib49ab623055e9ada7f95e0163ba7e33c5f6f99cb
The result of osmo_ss7_pointcode_parse() is currently not
checked. This means that -EINVAL could end up as value
in the pointcode configuration.
Check the return code of osmo_ss7_pointcode_parse() and
exit the VTY command with CMD_WARNING if the returned
pointcode is < 0
Change-Id: Iae6d92b1d135063dfd0a26bc23a89802cb3b1a78
SCCP addresses are defined through a number of compoinents, not
just an IP-Address, there is also point code, ssn and more. To
simplify and unify the handling of such objects, this patch
introduces an addressbook functionality. The user can set up
multiple addresses per ss7 instance and give them names. Later
that name can be used to reference the address at a later point
in the config. This means that the usage of sccp-addresses from
the programmers point of view boils down to a VTY function that
reads the string name of a previously defined address. The
programmer can then use the API to get a pointer to the SCCP
address struct and use it normally.
For this feature, two additional VTY nodes are necessary,
this commit depends libosmocore change:
Change-Id I42aa29c0cccc97f284b85801c5329b015b189640
Change-Id: I068ed7f7d113dab88424a9d47bab7fc703bb7942
As an IPA SCCPlite message arrives without any MTP routing label, we
simply construct one artificially for all inbound IPA/SCCPlite packets:
* we set the SPC to the point-code of the routing key of the AS
(as this is the PC we route to this IPA/SCCPlite client anyway)
* we set the DPC to a point-code from a new vty config command
"point-code override dpc"
Change-Id: Id556398e1ded3e613cfde7ea8b71aff7a414ff90
This tries as good as possible to fit the IPA/SCCPlite stacking into the
existing SIGTRAN/SS7 code architecture/model. To the user, the IPA
protocol looks like yet another protocol on the same level as the choice
between SUA and M3AU. On the inside, things are obviously quite
different.
We need to handle TCP with IPA framing instead of SCTP for both server
and client. We also implement an alternative "ASP FSM" for IPA, which
takes care of the CCM handshake (ID_REQ/ID_RESP/ID_ACK/ID_ACK2) for both
client and server mode.
In server mode, we use the 'unit name' as identifier to look up the AS,
similar to how we use a routing context to look up the AS in the xUA
case.
We also have to bypass activating the default layer manager in the
simple client to make sure we don't run into even more complexity.
What's missing right now is some way to manually override/set the point
codes. As IPA/SCCPlite is missing any routing label, we currently
simply generate one with SPC=0/DPC=0, which will obviously not work in
most configurations.
Change-Id: I9098574cddeba10fcf8f1b6c196a7069a6805c56
By moving this variable into the SS7 instance, we avoid one more global
variable, and we also fix a bug where the xua servers would be saved
multiple times (once per instance).
Change-Id: Icbab59d773f23cc8514cbeb6e21e25ca35dd337f
If we add more xUA variants/protocols, we want to avoid having to touch
too many parts of the code with copy+pasted strings.
Change-Id: I085b884d98fb4c45ac15910a8ebf82b91e861fd4
If RKM has dynamically generated some AS definitions on the fly, or if
we accepted auto-creation of ASPs on SCTP connect time, then we don't
wnat to save such objects during vty config file store.
Change-Id: I9d0b0b61737a30b9d6e76cecbe42ec071bcddeeb
Using this command one can specify if ASP connections should be refused
if there's no matching configuration, or whether ASPs should simply be
create on-demand.
Change-Id: Ic93b99047fb566cdb25a2f4139ebef54849dece9
This way it is systematic and doesn't clash with other optional
arguments we may introduce sooner or later at the end of the commands
Change-Id: I5c1050b0564791b5684619d3737d1cb6c4539d63
Now that the VTY has no static dependencies like a global ss7_instance
anymore, we can move it back to libosmo-sigtran and make use of it in
other programs outside osmo-stp.
This requires Change-Id I184a7e3187b48c15c71bf773f86e188fe1daad15 in
libosmocore
Change-Id: I2e549f1eadbfb28dde79f620b130cbf022312c42
osmo-stp is able to define multiple M3UA and/or SUA application servers
(AS) as well as application server processes (ASPs). Clients can then
connect via M3UA or SUA, perform the respective ASPSM / ASPTM state
changes and finally exchange MTP signaling such as ISUP or SCCP on top
of it. Routing is currently only based on point codes (PC). Routing table
is fully configurable with Destination PC and mask.
Shortcomings:
* xUA: only "override" traffic mode supported, no load-balance or broadcast
* xUA: no SNM supported, i.e. DAVA/DUNA/... messages are neither parsed
nor generated
* SCCP: no Global Title based Routing (GTR) yet
* SCCP: no Global Title Translation (GTT) yet
* no M2PA / M2UA sigtran dialects
* no classic CS7 based signaling links(E1/T1 TDM)
Change-Id: If32227b8d3127c6178e4ee45527ce65f69bc7b1e
This is what aims to be a rather complete/proper implementation of the
SIGTRAN + SS7 protocol suite. It has proper abstraction between the
layers with primitives, finite state machines for things like the AS and
ASP state machines, support for point code routing, etc.
What's not implemented at this point:
* re-integration of pre-existing SUA (pending)
* actual MTP2 and physical E1/T1 link support
* different trafic modes like broadcast/fail-over/load-balance
Change-Id: I375eb80f01acc013094851d91d1d3333ebc12bc7
Neels Hofmeyr
Pau Espin
Harald Welte
Neels Hofmeyr
Philipp Maier