Add vty 'encryption uea 0 1 2', defaults to 'encryption uea 0' to yield
previous behavior.
If any UEA above 0 is enabled, include the UEA key in the Iu Security
Mode Command.
I noticed that only the code bit in st_iu_security_cmd_on_enter()
affects the test. The same code in gsm48_gmm_authorize() seems to be
dead code? But applying the patch there as well just to be safe.
We cannot yet verify the chosen UEA to match a configured UEA level,
because the iu_client.c does not send us message details with the
RANAP_IU_EVENT_SECURITY_MODE_COMPLETE.
Also we cannot yet send the set of configured UEA to the hNodeB, since,
again, iu_client.c does not provide the proper API for it.
The proper solution here is to completely dissolve iu_client.c and do
all Iu handling in osmo-sgsn itself -- see OS#5487.
Related: SYS#5516
Related: I1a7c3b156830058c43f15f55883ea301d2d01d5f (osmo-ttcn3-hacks)
Change-Id: I27e8e0078c45426bf227bb44aac82a4875d18d0f
will add uea_encryption_mask, and find that the name
'cipher_support_mask' is not concise enough.
Related: SYS#5516
Change-Id: Ie8d4a0534c5b751f698bce425427bb1d28ddea31
Remove the paragraph about writing to the Free Software Foundation's
mailing address. The FSF has changed addresses in the past, and may do
so again. In 2021 this is not useful, let's rather have a bit less
boilerplate at the start of source files.
Change-Id: I9bc57a7152015e0f37e3d1573921d6d5d3c0449b
Fix crash in vty_dump_sne when sndcp->lle has already been deallocated.
Context:
* sndcp->lle is set only once in gprs_sndcp_entity_alloc()
* sndcp->lle is a struct gprs_llc_lle, which gets allocated and
deallocated together with struct gprs_llc_llme. From gprs_llc.h:
struct gprs_llc_llme {
...
struct gprs_llc_lle lle[NUM_SAPIS];
Fixes: OS#4824
Change-Id: I707029f78222bc6335837241e5a08c54c5ae6eb3
We were not handling the case of PDP_TYPE_N_IETF_IPv4v6
in gprs_pdpaddr2str() and showed "invalid" for these addresses.
Depends: libosmocore Change-Id: I1f82f9d8fc13dcc4474760329bd74ae9685b9031
Change-Id: Id36b7520677e4a0af40d05dc503b26d1b0b74a26
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
The E_(P)MM_IMPLICIT_DETACH event was actually sent and handled when the
UE was considered to be detached, no matter the reason, be it due to
implicit detach, or Detach Request received, etc.
So, let's properly name the event to avoid confusions in the code.
Related: SYS#5389
Change-Id: I224ea9db80b4d96696934cea06349dab036f919b
This Iu timer is Osmocom specific, but is made to resemble T3314
timer from GERAN (also named READY timer).
The idea of this activity timer was to arm it whenever PMM state
transitions to CONNECTED, and then rearm it every time there's some
sort of activity, until there's none for some time, then we send a
Release Command to close the conn with the HNGBW/RNC. That's the
same principle as per spec-defined READY timer T3314.
However, there's still a fundamental problem with it: GTP-U in
GERAN passes through the SGSN, but in UTRAN, the GTP-U stream
goes directly from the HnodeB to the GGSN. Hence, there's no proper
way to re-arm this timer upon activity in UTRAN, basically because
the SGSN will never see (userplane data) activity. That explains why
the E_MM_PDU_RECEPTION event exists for mm_state_gb_fsm, but doesn't
exist for mm_state_iu_fsm.
As a result, the timer is currently never rearmed, which means it
will transition to IDLE always after 44 seconds (default value) once
it went into CONNECTED state.
In UTRAN, there is a SCCP connection for each subscriber between
RNC/hNB and SGSN. If the subscriber is no longer in the respective
state, the RNC/hNB should release that IuPS SCCP connection, whcih
in turn means the SGSN cleans up its state.
Furthermore, SCCP has a built-in IT (inactivity timer). So should
the RNC/hNB die, that timer would time out, and the SGSN-side local
SCCP stack (provider) wold send a RELEASE.ind for that connection
to the user (SGSN).
TLDR; this timer is not really needed and cannot be implemented
properly in UTRAN, so let's remove it.
Related: OS#5116
Change-Id: Ibc71829e417bf2dd0c27deb842369dd4f17010d6
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
msgid2mmctx() was already being called for signalling messages in
gsm0408_gprs_rcvmsg_gb() before calling gprs_gb_recv_pdu(), but it was
not called in sndcp_llunitdata_ind().
Let's move msgid2mmctx() inside gprs_gb_recv_pdu() since we want to
always update the nsei+bvci, regardless of message containing data or
control content.
This commit fixes the scenario where an MS changes to a new cell (PCU)
and then continues transmitting UL data. Prior to this patch, the SGSN
kept sending DL content to the old cell (PCU nsei+bvci) instead of the
new one even after the MS transmitted Ul content fro mthe new cell.
Related: SYS#4909
Change-Id: I2c14e1d65575f54212924f7c5f0a2f4c1b76ec81
The SGSN currently does not forward BSSGP RIM messages.
Related: SYS#5103
Depends: libosmocore Icd667f41d5735de56cd9fb257670337c679dd258
Change-Id: I6fde8ab8955660b48000ca1b650cfc7c7b2e24ba
DPCU is defined in debug.h, but never registered as log subsystem,
so we shall not use it. Also remove other similar "orphan" log
subsystems from debug.h
Change-Id: I8be54ee49e10d4004128352613923c4700063aa3
When SGSN pooling is enabled we need to route some responses based on
IMSI back to the correct SGSN, e.g. PAGING_PS_REJECT.
The IMSI cache keeps track of this IMSI <-> NSE(SGSN) mapping.
Change-Id: If0a8d6cc1d63f2fb2c395cc5d4373a915bc2cb87
Related: OS#4951, OS#4472
When routing a SUSPEND/RESUME we need to keep track of where it came
from so we can send the (N)ACK back to the correct BSS. Use the TLLI
which is present in both messages to cache and retrieve the correct BSS.
A timer runs every two seconds and expires entries that are older than
the timeout (hardcoded to 5 seconds for now).
Related: SYS#4865, OS#4472
Change-Id: I42adf70f560d2bb358a9e1c7614281e8d2967568
This is useful for logging and configuration to identify an SGSN by name
Change-Id: I2a3410dd9bebb242957e13a63ed70e447204203c
Related: SYS#5115, OS#4472
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
In order to support SGSN pooling we need to configure the various NRI
parameters such as the bitlen, NULL NRI, and which NRIs are assigned to
which SGSN.
Related: OS#4890, OS#4472
Change-Id: Id67592aa7712e5e04e7264b2fb8f26d57eb7e69e
When there are multiple SGSNs inside a pool, we need to decide
how much of the per-BVC capacity advertised by the BSS in its
BVC-FLOW-CONTROL we should announce to each of the pool members.
A conservative approach would be to advertise 1/num_sgsn, but
there may also be use case where over-provisioning (announcing more
than an equal share of the capacity) is useful.
Hence, let's introduce "pool bvc-flow-control-ratio <1-100>" in order
to allow the administrator to decide.
Related: OS#4891
Change-Id: Ibe5addf657e7237499ca0205bacfe999ecd1e771
Rewrite of a large part of osmo-gbproxy in order to prepare
for SGSN pool support. The amount of changes are of such fundamental
nature that it doesn't make sense to try to split this into hundreds
of individual changesets.
Related: OS#4472
Change-Id: Ie0746f17927a9509c3806cc80dc1a31d25df7937
Those features were introduced a long time ago for one specific use
case at one specific user, and they are not needed anymore. They
complicate the code base significantly and are hard to maintain with
all the upcoming modifications regarding SGSN pool supoprt.
Change-Id: Id9cc2e1c63486491ac5bb68876088a615075fde6
For the common lookup-by-bvci, this should reduce the computational
complexity significantly.
Depends: libosmocore.git I8ef73a62fe9846ce45058eb21cf999dd3eed5741
Change-Id: Ic8e9279fd61a3c514fc3203429f36a468f0e81d3
For the common lookup-by-nsei, this should reduce the computational
complexity significantly.
Depends: libosmocore.git I8ef73a62fe9846ce45058eb21cf999dd3eed5741
Change-Id: Idbb6a362332bb6e3ce22102e7409ae80d0980f44
We will soon also have a list of sgsn-side NSEs, and we need to
differentiate those.
Change-Id: If5accec0c70c01b88927ea07beba6f6488bd9d5a
Related: OS#4472
I cannot really read the code while it contains its historical weird
naming. A "peer" used to be a strange amalgamation of NSE + BVC,
while in reality we can have any number of BVC on top of each NSE.
We recently started to split the peer into a gbproxy_nse_peer + gbproxy_peer.
This takes it one step further and renames gbproxy_peer to gbproxy_bvc,
as that's really what it is.
Change-Id: Iae01067282a6401f6af4cab731202872d2cdb080
Since gbproxy doesn't use bssgp_rcvmsg from libosmocore we need to
implement our own filtering.
Change-Id: I4d1b57b89990945d307f27a58a7f630be0253d5b
Related: SYS#5232
We want this level of indirection to support multiple BVCs per NSE. The
current code assumes that an NSE only has one BVC which breaks messages
on the signalling BVC which should only be sent once to an NSE
regardless of the number of BVCs it contains.
Change-Id: I97cc6c8f8c0f1b91577ab8f679c4ae217cc88076
Related: SYS#5226
This will be needed to use the TLLI as link selector parameter
in osmo-gbproxy in an upcoming patch.
Depends: libosmocore.git I397b32a6e6ea3e9d218446138cceafa9b27685dd
Change-Id: Ia6d5300e63ad23987cbdca824db620305bd583d7
Since NS2 has a different abstraction we mock up the prim send/recv
functions and don't test NS like the old tests did.
Related: SYS#4998
Change-Id: Iecfd0408a35a11638d254c1db3c1d477b1a11524
The osmo_ prefix should be only used for official struct/apis of libosmocore.
This commit was done via `sed -i 's/osmo_sockaddr/sgsn_sockaddr/g'`.
In prepartion of introducing a different api of osmo_sockaddr to
libosmocore.
Change-Id: Ibb1ddce9ff1ffe7494de5cdb8ea1843c45fe4566
Since osmo-ggsn.git c94837c6a401bf0f80791b619a9b4cfbe9160afd, those
APIs are a no-op since timers are tracked internally through osmocom
APIs (and at the same time, new implementation fixes some timing related
bugs).
As a result, osmo-sgsn depends now on at least that libgtp commit. Since
it's not yet avaiable on latest libgtp release, let's track it down in
TODO-RELESE to not forget to update libgtp requirements during osmo-sgsn
release.
Related: OS#4178
Change-Id: Ia9a93d4a6ed63cd0c736f9a99d81d730b958d82e
The user inactivity timer is similiar to the Gb READY timer and reduces
the resources taken by an idle UE.
Change-Id: I66c2ac0350cb074aefd9a22c5121acf723f239d3
PMM Connected defines a Iu signaling connection. The 2 other
PMM states do not have an active Iu signaling connection.
Change-Id: Ie05d2bdf8dfb593b4c7e837107a3a06f22e90119
When receiving a PDU, the GMM fsm will change to state MM_READY
and will re-arm the T3314
Relates: OS#1941
Change-Id: I78f40762fb17bbd4a6f35608a793f8e5271e9b86
State machine inspired in the one from TS 24.008 4.1.3.3.1. Some state
transitions are inroduced in the code but are still commented out since
we lack some functionalitites or improvements in the code to handle
different scenarios.
Most of the logic is still outside of the FSM, but at least now the
states are handled in a sane way triggered by events.
Change-Id: Idecb43c10d66224d4f9ba9320825040ce6cf9a07