Rework initialization and destruction of several sgsn subsystems to be
allocated & released together with the struct sgsn_instance.
This makes it easier to destroy and recreate the entire context and
allows us to start moving global variables scattered around to be under
struct sgsn_instance.
Change-Id: Idf60519b8e475b94d38bbb69e737132a5afaefab
It will be used to store all stuff relatd to libgtp use and GTP
protocol, similar to what we already do for other protocols.
Change-Id: I4aae35cd0ea401856cd822cb507d668350d07a89
All remaining code in that file is NS protocol related, hence let's
rename it so that we end up with one file per protocol in the Gb stack.
Change-Id: I8312c8a70d60cab48764950c5b57ca02964e9db2
Right now there's no much code there since the related code is totally
entangled with the LLC one.
This will eventually change in the future when we switch to use
libosmo-gprs.
Hence, this commit is a preparation to have already some place to put
new BSSGP specific code in the future.
Change-Id: I816396ab5ccb86032bbc21b41a959934a7768780
MMEs connect over Gn interface using GTPCv1 towards the SGSN in order to
exchange RIM PDUs by using "RAN Information Relay" GTPCv1 message type.
For more info, see 3GPP TS 29.060 sec 7.5.14.1 "RAN Information Relay"
In order to support it, this commit does the following:
* Uses new libgtp APIs to rx and tx RAN Information Relay messages. The
same "gsn" object is reused, ie. the local GTPCv1 socket address used
for exchanging messages against GGSN is reused.
* Adds a new "sgsn_mme_ctx" struct holding information about MMEs
allowed by the SGSN, each one containing information about the GTP
address it uses, the in/out routing based on TAI requests, etc. The
set of MMEs and their config can be set up using new VTY node introduced
in this commit.
* The RIM related code in SGSN is refactored to allow forwarding from
and to several types of addresses/interfaces.
Depends: osmo-ggsn.git Change-Id Iea3eb032ccd4aed5187baca7f7719349d76039d4
Depends: libosmocore.git Change-Id I534db7d8bc5ceb19a2a6866f07d5f5c70e456c5c
Related: SYS#5314
Change-Id: I396450b8d8b66595dab8ff7bf41cbf964bb40d93
This logging category has been removed completely in [1], and now
osmo-sgsn fails to start with old configuration files:
There is no such command.
Error occurred during reading the below line:
logging level ns info
Let's accept it and print a deprecation warning.
Change-Id: I2036170af41db89484c299e18e0b703c97427dc1
Fixes: [1] Ia4723ab344ad6a1927029a2d5d0dda020266b39d
When we switched to the libosmogb NS2 implementation, we should have
removed the DNS category, as NS2 uses DLNS internally and hence DNS
is unused.
Change-Id: Ia4723ab344ad6a1927029a2d5d0dda020266b39d
Closes: OS#5058
We must have initialized e.g. the NS protocol stack before calling
handle_options(), as that might want to dumpy the VTY XML, and it
can obviously only dump those nodes that are registered at that
point.
Change-Id: Icd1b8fb3f466cdace67ff0d4f7c85183d8266c41
The SGSN currently does not forward BSSGP RIM messages.
Related: SYS#5103
Depends: libosmocore Icd667f41d5735de56cd9fb257670337c679dd258
Change-Id: I6fde8ab8955660b48000ca1b650cfc7c7b2e24ba
The call gprs_ns2_dynamic_create_nse has been removed because it
was a workaround for the old/dropped vty api.
Depends-on: Ie924ead6da17657f3da334068c8ada82c8845495 (libosmocore)
Change-Id: Ie636cfd18d6d43da0e42f2c2de68dfa5c571d55c
Change the whole vty configuration for NS to be more flexible
and support more setups. Old configurations are invalid.
API change which must be synchronized with libosmocore
For further information see:
https://osmocom.org/projects/libosmocore/wiki/Network_service_(NS)
Depends-on: I8c3f2afecc74b78f7f914f7dce166cbcb63444eb (libosmocore)
Change-Id: Ie9306ab4d4738c2c57a69987086e22771b30657e
The new NS2 api supports NSE with multiple NS-VC and contains a NS-VC
fsm. FR/GRE support is not working.
The configuration is compatible except for FR/GRE.
Relates: OS#4629
Depends-on: Iaad7b53d44338e5dd81dc2202f23bdcb715af804 (libosmocore)
Depends-on: I6cef42749555e577d5573f2ed8b8bce4cf842a98 (libosmocore)
Change-Id: I92a3bcaf166b091a22d74c7c1586964d33d7cc9d
Previous code relied on abort() switching sigaction to SIG_FDL +
retriggering SIGABRT in case the signal handler returns, which would
then generate the coredump + terminate the process.
However, if a SIGABRT is received from somewhere else (kill -SIGABRT),
then the process would print the talloc report and continue running,
which is not desired.
Change-Id: I65f70a53b6982bff9ea4bd6ff786d8a2f8181eac
Fixes: OS#4865
* is_config_node is deprecated, so don't set it
* go_parent_cb is only used if we want to do special stuff upon exiting
a node, in osmo-sgsn and gtphub only osmo_ss7_vty_go_parent() needs to
be called
Change-Id: I2008dd9026922d29ee703c59e70d3fecced0ee18
"127.0.0.1" is changed to "localhost" to let local NSS decide whether to
use IPv4 or IPv6. In newish systems, IPv6 ::1 will be selected since
IPv6 takes precedence over IPv4.
Similarly, the default source addr needs to be changed from NULL to "localhost"
since for some yet unknwon reason, getaddrinfo(AF_UNSPEC, NULL) returns
first IPv4 "0.0.0.0" and later "::", which is inconsistent with
getaddrinfo("localhost") result, resulting in src=IPv4(0.0.0.0) and
dst=IPv6(::1), which is incompatible and will fail. In any case, since
the default remote address is a local one and it's the client side,
there's no real logical change since the kernel would anyway should have
taken a local address anyway.
Change-Id: I2f599e1aa449d44136ef20ba5f516ca9b61f3223
3GPP TS 48.018 Section 8.4:
> After any failure affecting the NSE, the party (BSS or SGSN) where
> the failure resided shall reset the signalling BVC. After sending or
> receiving a BVC-RESET PDU for the signalling BVC, the BSS shall stop all
> traffic and initiate the BVC-RESET procedure for all BVCs corresponding
> to PTP functional entities of the underlying network service entity. The
> BSS must complete the BVC-RESET procedure for signalling BVC before
> starting PTP BVC-RESET procedures.
TODO: We should not just trigger a single outbound BVC-RESET message,
but we should re-transmit them until we get a response. This would
likely entail adding FSMs to libosmogb, which we will leave for a later
point - it's anticipated that the NS + BSSGP code is undergoing quite
some changes in the coming months anyway, so leave it for then.
Change-Id: I0b46035b40709c38bb9ab9493c11031a577e3ee0
Closes: OS#4629
Depends: libosmocore.git I353adc1aa72377f7d4b3336d2ff47791fb73d62c
Pau Espin
Max
Vadim Yanitskiy
Harald Welte
Philipp Maier
Daniel Willmann