libbsc and libmsc have conflicting definitions of gsm_subscriber_connection
and do no longer belong together anyway.
Create libxsc, meaning 'lib[bm]sc', to hold all code used by both libmsc
and libbsc, and make sure gsm_subscriber_connection isn't used there.
In various binaries and tests, do not link libbsc and libmsc.
(Note: this commit was reshaped out of a large wip chunk, it may not
compile properly without the subsequent commits)
After rebasing onto 1b0e5540db, some changes need to be applied to
cscn_main.c, originally a copy of bsc_hack.c before the rebase. On master,
configurable MNCC socket path and Control interface bind address were added.
As described in a comment, for MSCSPLIT the tz data has been moved to network
level. To allow compiling osmo-bsc on the sysmocom-iu branch, move tz up to
network level in osmo-bsc as well.
This could be done better for osmo-bsc, rather easily too, still allowing
per-BTS timezone settings. But I'm trying to focus on IuCS and would like to
come back to this later.
To make the IuCS build work, disable the BSC-land access from MSC's SMPP code.
Some way shall be found to make the Osmocom vendor-specific SMPP TLVs work over
the A-interface (after the MSCSPLIT), but we're concentrating on IuCS for now.
There should be no need to silence this warning, the ranap_free_*
functions are declared in libranap headers. In any case this will only
obscure any real issue. Maybe osmo-iuh was not rebuilt completely
(including generation of the c files from the python script).
This reverts commit 05ae5b1245f95bf765b42e49af7b2596e013f0a0.
The sgsn uses other data structs so don't require them inside libiu.
Instead keep a private list of ue contexts and iterate through that.
This commit reverts the libui changes of commit
d03faa4bacd4d2a8b9155faf5219a948b73f481c
In the IU case the RNC and ggsn communicate directly on the user plane.
Since the IP address of the RNC is not known in our case (it sits behind
the hnbgw) we need to update the PDP context with the new IP address
after receiving the RAB assignment response (which includes the IP
address).
The RAB assignment response includes the gtp teid that we sent along in
the assignment request. Retrieve the correct pdp context from there and
activate it.