Implement only the VTY configuration part, applying NRI to select CN
links follows in I66fba27cfbe6e2b27ee3443718846ecfbbd8a974.
Use the osmo_nri_ranges API to manage each cnlink's NRI ranges by VTY
configuration.
Analogous to osmo-bsc
MSC pooling: make NRI mappings VTY configurable
4099f1db504c401e3d7211d9761b034d62d15f7c
I6c251f2744d7be26fc4ad74adefc96a6a3fe08b0
plus
vty: fix doc: default value for 'nri bitlen'
f15d236e3eee8e7cbdc184d401f33b062d1b1aac
I8af840a4589f47eaca6bf10e37e0859f9ae53dfa
Related: SYS#6412
Change-Id: Ifb87e01e5971962e5cfe5e127871af4a67806de1
After recent introduction of multiple 'msc' and 'sgsn' nodes in the
VTY config, switch cfg files to the new syntax:
- in doc/examples
- for 'make config-tests'
- have one test in old config syntax to test backwards compat:
'legacy', an exact copy of 'one_cs7_with_addrs'.
Related: SYS#6412
Change-Id: If999b71a8a8237699f6ccfcaa31d1885e66c0518
Allow configuring multiple MSCs and SGSNs. Show this in new transcript
test cnpool.vty and in sccp.dot chart.
Still use only the first CN link; actual CN link selection from the pool
follows in I66fba27cfbe6e2b27ee3443718846ecfbbd8a974.
Config examples and VTY tests cfg files will be adjusted to the new cfg
syntax in patch If999b71a8a8237699f6ccfcaa31d1885e66c0518. Only the VTY
write() changes are visible here, to pass all transcript tests.
Related: SYS#6412
Change-Id: I5479eded786ec26062d49403a8be12967f113cdb
To ease patch review, I decided to submit this separately from the
caller, which follows in subsequent patch
I5479eded786ec26062d49403a8be12967f113cdb
The new event will be dispatched when there are SCCP config changes
pending, and the human user types 'apply sccp' on the telnet VTY. The
aim is to disconnect all connections so we can create a new SCCP User.
Related: SYS#6412
Change-Id: Idff8e09b5328c904b175e4d4df7d4044a34f4a20
Have separate find, alloc, set_cnlink functions instead of all in one.
For CN pooling, I need these operations to be separate:
- we need to decode the RANAP and L3 PDU only if no existing context_map
was found (see I373d665c9684b607207f68094188eab63209db51 ).
- while decoding RANAP and L3 PDU, and while deciding which cnlink to
use, I already want to use the logging context of LOG_MAP(). So I want
to allocate a map first, and connect it to the selected cnlink later.
Related: SYS#6412
Change-Id: Ifc5242547260154eb5aecd3a9d9c2aac8419e8db
osmo_sccp_instance_next_conn_id() may return negative on error, so use
int instead of uint.
Fixup for recent 548d3d2f66
'use new osmo_sccp_instance_next_conn_id()'
Related: CID#316694
Change-Id: I2623c06c23691acb75f6ee6ff3a42ac7d10a4b1f
Prepare for CN pooling; allow using separate SS7 instances for IuCS and
IuPS.
New struct hnbgw_sccp_user describes a RANAP SCCP user, one per cs7.
Limit struct hnbgw_cnlink to describing a CN peer, using whichever SCCP
instance that is indicated by hnbgw_sccp_user.
Chart sccp.dot shows the changes made.
Related: SYS#6412
Change-Id: Iea1824f1c586723d989c80a909bae16bd2866e08
Show current use of SCCP and SS7 by osmo-hnbgw, which is about to
change (along with this chart).
Related: SYS#6422
Change-Id: I109948758de998326a5e9f0dcdc84d5f11dfba02
Get a handle on how osmo-hnbgw currently auto-configures itself, by
running vty tests with a couple of config files that have various levels
of omitted config items that are to be auto-configured.
These tests serve to ensure continuity and compatibility by upcoming
cnpool patches. They will show how the configuration changes / doesn't
change in all the right ways.
Uncover one bug in osmo-hnbgw: local point-code setting is discarded by
osmo-hnbgw startup when there are no SCCP address book entries in use.
The error is fixed as side effect of an upcoming patch:
Iea1824f1c586723d989c80a909bae16bd2866e08
Related: SYS#6412
Change-Id: Ic8bb30e1dd73753c2ff255566382e241918414f7
Instead of doc/examples/osmo-hnbgw.cfg, use a separate location
tests/osmo-hnbgw-vty-test.cfg for VTY transcript tests, and add a bunch
of SCCP address book entries that upcoming VTY tests will use.
Declaring address book entries within transcript tests is possible, but
cluttered with node 'exit' and VTY prompts -- these addresses are much
easier to read and maintain in form of a cfg file.
First user of these address book entries will be cnpool.vty in
I5479eded786ec26062d49403a8be12967f113cdb
Related: SYS#6412
Change-Id: Idcdf0e8660e8180fbe02282bc94e623ff89e848a
We have not a single example yet showing point code and SCCP address
configuration. Add this example, which will also show how the config
file syntax changes while introducing CN pooling in upcoming patches.
Related: SYS#6412
Change-Id: I42c3b434a7339cc3efb27b43c893cfb734de9ca4
The RUA side may disconnect
a) gracefully (RUA Disconnect with RANAP IU Release Complete) or
b) by detecting that the HNB is gone / has restarted
For a), the SCCP side waits for a RLSD from the CN that follows the IU
Release Complete.
For b), we so far also wait for a RLSD from CN, which will never come,
and only after a timeout send an SCCP RLSD to the CN.
Instead, for b), immediately send an SCCP RLSD.
To distinguish between the graceful release (a) and the disruptive
release (b), add new state MAP_RUA_ST_DISRUPTED on the RUA side,
and add new event MAP_SCCP_EV_RAN_LINK_LOST for the SCCP side.
Any non-graceful disconnect of RUA enters ST_DISRUPTED.
disrupted_onenter() dispatches EV_RAN_LINK_LOST to SCCP,
and SCCP directly sends RLSD to the CN without timeout.
These changes are also shown in doc/charts/hnbgw_context_map.msc.
Change-Id: I4e78617ad39bb73fe92097c8a1a8069da6a7f6a1
We do not need to restore the parent node on vty_go_parent() anymore,
only call the ss7 go-parent callback to trigger actions on vty node
exit.
Change-Id: Id3ecc53885436294d2217c52130910872dde550e
When I implemented it, I thought context_map_check_released() would help
clarify context map deallocation, but instead it just bloats. Simplify
and tweak related comment.
Change-Id: I535780de0d3b09893ba89d66804e5e36b26db049
When in map_rua_fsm_cleanup(), we are always already deallocating the
context map, i.e. neither RUA nor SCCP are active anymore. No need to
call context_map_check_released() again.
Change-Id: I4bf9a9de7861296ec38c3a37de0254ad9a41ef1b
This looks like working RANAP RESET handling, but is in fact dead code.
Instead of testing and completing this implementation, I will copy the
RESET handling FSM from osmo-bsc, which is proven to work well.
See Id3eefdea889a736fd5957b80280fa45b9547b792
"detect in/active CN links by RANAP RESET"
The future patch will start to use transmit_rst(). So instead of
dropping now and resurrecting later, let's keep the code -- but it has
to be '#if 0'-ed to avoid compiler complaints about the unused function.
Related: SYS#6412
Change-Id: I7cacaec631051cf5420202f2f0dd9665a5565b17
Prepend it to the cs7 config .adoc, so that it introduces some concepts
and specifies some limitations of current implementation, etc.
Change-Id: I9faef2dd15b62814e474299c675c2cb05b779c44
Make this deprecated command fatal when in a .cfg file:
hnbgw
sccp cr max-payload-len N
Because we now have:
cs7 instance N
sccp max-optional-data N
from libosmo-sigtran to replace it.
Context: The old command currently has no effect, because we had
implemented the specified fixed 130 byte data limit in libosmo-sigtran.
Recent libosmo-sigtran adds a variable limit configuration.
I considered implementing a shim to redirect the legacy command to the
new implementation, but that would be quite ugly: the old command is
under the 'hnbgw' node and would have to apply to all 'cs7' instances.
But we cannot assume that all 'cs7' are above or below the 'hnbgw' node
in the .cfg file. So I'd have to add global state to remember the legacy
config's value and apply that everywhere else. IMHO this is too much
complexity to support an obsoleted command that has a replacement.
To rule out all confusion that this situation may otherwise create,
abort osmo-hnbgw startup in presence of the legacy VTY command, logging
an error that hints at the new cfg item.
Related: SYS#6423
Change-Id: I71f82efe07af2c32f2aa01084bc8da6ce5c6cd1a
Fix the following compile error, seen on ubuntu 18.04 with GCC 7.5.0,
opensuse 15.4 and our OE builds:
hnbgw.c:549:15: error: initializer element is not constant
.copyright = hnbgw_copyright,
^~~~~~~~~~~~~~~
Fixes: 04844415 ("move main() to separate file")
Change-Id: I13b2569a369724e0298b064a0876b95d6dafd9d0
To ease linking C tests, introduce a libhnbgw.la that contains all of
osmo-hnbgw except the main() and friends.
(I wrote a test that I was going to add, but it turned out to be
obsolete -- now at least we may keep this preparation to add C tests
more easily.)
Change-Id: Id2a706a30fb459005c676bb29c196cf3a582fa01
Conform to recent osmocom practice by having an osmo_hnbgw_main.c file
for main() and its immediate infrastructure.
Prepares for adding a non-installed libhnbgw.la -- which must not
contain a main() function -- so that linking regression tests is easy.
Separating to a new file seems appropriate because hnbgw.c has gathered
a bunch of stuff that is not strictly main() related / might be useful
to access in a C test.
Change-Id: I5f26a6b68f0d380617d73371f40f3b9055cac362
So far we jump through hoops everywhere to pass around osmo-hnbgw's
global singleton state to all code paths. Some files choose to spawn a
static "global" pointer. And we also have the talloc root tall_hnb_ctx.
Simplify:
- Have a single global g_hnbgw pointer. Drop all function args and
backpointers to the global state.
- Use that global g_hnbgw as talloc root context, instead of passing a
separate tall_hnb_ctx around.
(Cosmetic preparation for separate osmo_hnbgw_main.c file)
Change-Id: I3d54a5bb30c16a990c6def2a0ed207f60a95ef5d
It's really just a bloated llist_count() wrapper.
(Cosmetic preparation for separate osmo_hnbgw_main.c file)
Change-Id: Icd4100ddeb98f4dc2e2ec6de2d44a4b861a66078
This fix is really weird: by *removing* a FREE() call, fix a leak of the
replaced transportLayerAddress. (An in-code comment says some more.)
Also remove the other FREE() call that turns out to not be necessary.
This has been verified with a ttcn3 test that is not yet submitted,
which ensures an empty talloc_asn1_ctx at the end of every test
(osmo-ttcn3-hacks I2948ee6f167369a2252f85b493e9653b93c7e4e9 ).
Change-Id: I315d04a07b7dfd4dce26e5b5f871318e27e2bdf6
Include talloc_asn1_context in 'show talloc-context application'. It
belongs there IMO.
Related: SYS#6297
Change-Id: Iffc320c64713b225b57211da4fb95a868bf1f369
Without "null tracking" enabled, the VTY 'show talloc-ctx all' shows
nothing at all.
Since the talloc_asn1_ctx is "created in NULL ctx", it was not visible
in any talloc reports before this patch.
This patch uncovers a slur of leaks, which accumulate in
talloc_asn1_ctx. Fixes follow.
Related: SYS#6297
Change-Id: I5cb4e9a3b393100877f03d68a09acf5817c5a878
Don't fall back to the legacy config if the pool is configured but no
connection to any pool member can be established.
Depends: osmo-mgw I009483ac9dfd6627e414f14d43b89f40ea4644db
Related: OS#5993
Change-Id: Icf3f3f0524c9d27f645c68851aaf9c6f33842927
Neels Hofmeyr
Oliver Smith
Pau Espin
Vadim Yanitskiy