These are the osmo-iuh changes corresponding to the libosmo-netif
branch 'destroy_conn_with_cb_flag'.
Change-Id: I62e6d4fe4da75f1a56abf4c46a2426d17840025f
Add commands to get number of connected HNBs and identity string of
connected HNB based on Cell ID.
Change-Id: I3a2d6fa3d6d0829ccee4ecc0998d9299c97820e9
We used to have hardcoded 2323 from early development, use the proper
libosmocore definition instead.
Depends: Ife52a968a41cb286f640006587877971ff66c1a4 (libosmocore)
Change-Id: Id67d89695ebdc6288f507338c15ad773b8adf6e4
It's not necessary to set a local IP to connect to OsmoSTP with, 'any' is as
good as any.
Related: OS#2663
Change-Id: If5d0a1500de5e2c4b80acf025761d0264a8a51a0
Since I8ac15fa2fd25bedb26297177e416976a5389b573 in July 2017 we are
not using sctp_*() functions directly anymore but go via
libosmo-sigtran. However, some dead code remained in hnbgw.c, which
means that linkage will fail if compiled without any optimization,
i.e. without -O present.
Change-Id: Ifbcb21d43e17bf512bc7b219e590410e06c434ca
In the vty config, use the SCCP address book to configure the local and remote
SCCP addresses. Add VTY commands to set the remote SCCP addresses by name,
derive the ss7 instance from these addresses:
cs7 instance 1
point-code 0.23.0
sccp-address msc
point-code 0.0.1
sccp-address sgsn
point-code 0.0.2
hnbgw
iucs
remote-addr msc
iups
remote-addr sgsn
Enforce that both IuCS and IuPS use the same ss7 instance. In the future, we
may add the feature to use two separate instances.
Depends: libosmo-sccp I75c67d289693f1c2a049ac61cf2b2097d6e5687d,
Ie1aedd7894acd69ddc887cd65a8a0df4b888838c,
I85b46269dbe7909e52873ace3f720f6292a4516c
Change-Id: I33a7ba11eb7c2d9a5dc74d10fb0cf04bf664477b
libosmo-sigtran now has a "proper" SCCP/M3UA stack, so we can make our hnb-gw
3GPP compliant by switching from the old SUA code to the new universal SCCP
user API with support for (currently) M3UA and SUA.
Main changes:
Use one cn_link to STP: We will connect to the core network using an (Osmo)STP
instance that routes to MSC and SGSN, so we want one SCCP link instead of two.
The only difference between IuCS and IuPS is a different remote osmo_sccp_addr.
This has various effects through the messaging code; the patch is a bit larger
than I would like, but it is hard to separate out truly independent smaller
changes.
CS or PS domain was previously flagged in the separate cn_link, as ctx pointer
for two separate sccp_sap_up()s. Now there's just one such ctx, so determine
is_ps from the RANAP Domain Indicator, or from the conn's hnbgw_context_map:
- Add is_ps to context_map_alloc_by_hnb().
- To find a matching context, the RUA ID alone is no longer sufficient, also
match is_ps (possible optimization todo: separate lists).
We would send separate CS or PS Reset messages based on the cn_link, instead
send both CS and PS Reset at the same time for the single cn_link. This could
be adjusted to detect presence of MSC or SGSN instead.
Pending: adjust the VTY config to reflect that there is only one remote
address. Place a TODO comment for that.
Smaller changes:
rua_to_scu(): populate called and calling addresses for N_CONNECT and
N_UNITDATA.
Remove DSUA.
Don't build dummy_cn, which is still implemented on SUA. Mark todo to maybe
re-include it based on M3UA later.
In hnbgw_cnlink, place sccp related items in a separate sub-struct.
Do not keep an llist of cn_links, just have the one. Remove iteration and list
management.
Change jenkins script to build libosmo-sccp master.
Patch-by: hwelte, nhofmeyr
Change-Id: I8ac15fa2fd25bedb26297177e416976a5389b573
Basically copy-paste the Iuh local-ip and local-port code to provide
parameterization of the IuCS and IuPS remote addresses.
Add IUCS and IUPS nodes, enhance go_parent_cb and config writing accordingly.
Change-Id: I2c28977011009df4e1fa472290bbbc359e406971
A second level of depth will be added to the hnbgw node soon, which will need
explicit go-parent logic.
Change-Id: I8d1c18a396c215e8425ae49872b5c73316087d7d
Use the g_hnb_gw->config.iuh_local_ip directly, drop hnbgw_get_iuh_local_ip().
Change-Id: Ie91aea82ae5d128ad735a0857ea814b440c3232c
Suggested-by: hwelte
Prepare for parameterization of IuCS and IuPS addresses:
Conform internal variable naming to local-ip, local-port, remote-ip,
remote-port (instead of bind-ip).
Rename HNBGW_IUH_LOCAL_IP_DEFAULT to HNGGW_LOCAL_IP_DEFAULT to be more general
and move it to the top.
Move a function doc comment to the .c file.
Change-Id: Ice85941c978498e3ddf41d151248507e7f56cb5d
Properly initialize msgb talloc context in hnbgw and all tests, using the new
msgb_talloc_ctx_init().
test-ranap.c: since msgb talloc ctx is now in test_common_init(), remove msgb
talloc init here.
Change-Id: I807c799aff1239184728551ed77fdafa73bd683f
The standard osmo VTY terminology is 'remote-ip', 'remote-port', 'local-ip',
'local-port'. Conform to that. osmo-hnbgw is so far not rolled out widely, so
it makes sense to do this now.
Change-Id: Ifda2653bf58044552a5f1477cd7008dec3fb9100
To prepare for an upcoming commit that accepts TMSI identification upon UE
Register Requests:
Add tmsi arg to ue_context_alloc().
Add ue_context_by_tmsi().
This is aimed at the ip.access nano3G femto cell, as it apparently feeds
whichever identification the UE sends through to HNBAP (TMSI+LAI, pTMSI+RAI),
instead of an IMSI as expected.
See the upcoming commit that enables accepting TMSI identities for further
detail.
Change-Id: I138458443319cc4cbea5ee7906cf5dd72d582130
After libosmocore 55dc2edc89c1a85187ef8aafc09f7d922383231f which outputs
'telnet at <ip> <port>' from telnet_init_dynif(), there's no need to log the
telnet VTY bind here anymore.
Change-Id: Icd9e670c1d30c156f7bd5d0d34892150aeba95e9
This came up while fixing 'make distcheck'; this is certainly not the easiest
way but it makes sense to have the headers in include/, like we do in openbsc.
The easy alternative might be to add -I$(top_srcdir)/src to src/Makefile.am.
Remove -I$(top_srcdir)/src from src/tests/Makefile.am, no longer needed.
Change-Id: I5a82e029dcdc4df0a60a31271a4883393fe59234
Add config node hnbgw/iuh/bind, taking an IPv4 address.
Use this address to bind the Iuh server.
This is particularly useful for the ip.access nano3G, which is very sensitive
with SCTP addresses that don't respond to SCTP heartbeats. If the hnbgw listens
on 0.0.0.0, there will be SCTP heartbeats for all local interfaces on the
machine that the hnbgw runs on; the nano3G will interpret the "missing", or
rather, redundant heartbeat acks for the interfaces that aren't really related
to the Iuh server and assume a broken Iuh link, leading to an Iuh shutdown and
reconnection, looping every minute or so. By binding the hnbgw to only one
local interface, the SCTP addresses can be reduced and "missing" heartbeat acks
can be avoided.
Change-Id: Ie2749c152b878e17aa65dfb806826357d5c494f1
Now that a config file gets parsed after the command line options, e.g. the
'logging timestamp 0' config item is stronger than a -T commandline option. So
rather store the cmdline options to take effect after config file parsing.
This adds a stupid 'log_disable_color = true' reverse boolean logic, which is
unavoidable if we want to use the same default cmdline options as osmo-nitb /
osmo-cscn.
Change-Id: I16ad55b173a443c36b71dc6b70f58695f6665312
Default options taken from osmo-nitb:
-h --help This text.
-d option --debug=DHNBAP:DSUA:DRUA:DRANAP:DMAIN Enable debugging.
-D --daemonize Fork the process into a background daemon.
-s --disable-color
-T --timestamp Prefix every log line with a timestamp.
-V --version Print the version of OsmoHNBGW.
-e --log-level number Set a global loglevel.
Change-Id: I931cee01c605c1b507c16041ada226cf963ea433
See libosmo-sccp.git 1a3875092f93df3c3054d26eac52bb0ea9bd09c3
Note: at time of commit, osmo-iuh still depends on the libosmo-sccp sysmocom/iu
branch to build.
The same rename has been committed to both sysmocom/iu and master on
libosmo-sccp. Above commit hash is on sysmocom/iu. The master commit is
03ad002c28073b347b92bcde16d5af80a06389e4.
Change-Id: Id9c0065d7398a6205ff24477d47c9663caac669c
We now have the RUA and SUA parts interconnected by the
context ID mapper, and should be able to pass messages back and forward
between both sides.
Unfortunately this touches a bit of everything, but the structures are
all still very much in flux. Hopefully they will start to stabilize at
some point soon...
This socket doesn't do much yet except to connect to localhost:14001
The host/port needs to be made configurable, and the RUA<->SUA
interfacing needs to be implemented.
Also, we'll need two SUA sockets, one for MSC and one for SGSN.