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
This reverts commit 4bd931f96d.
The commit was wrong, and previous code is correct.
Relevant specs:
* TS 29.060 7.7.34 Quality of Service (QoS) Profile
* TS 24.008 10.5.6.5 Quality of service
As can be seen in TS 24.008 10.5.6.5, OSMO_IE_GSM_REQ_QOS never comes
with the the ARP byte prepended. This is actually always prepended when
sending the GTP message, as explained in TS 29.060 7.7.34.
As a result, the Qos Service sent in Create PDP Context Request sent to
the GGSN contained wrongly formatted Qos Profile IE, which was observed
checking wireshark with a real phone. This was found due to open5gs-smfd
being more strict about the possible lengths of the IE, since the
wrongly formatted IE send in GTP had length=14, which is incorrect due
to folllowing TS 24.008 10.5.6.5 wording:
"Octets 15-22 are optional. If octet 15 is included, then octet 16 shall also be included, and octets 17-22may be
included."
In this case, due to the wrong format it was seen as including octet 15
but not 16.
Change-Id: I4fc5ab823a27d27482858a7459337a2f8ae593c3
Related: SYS#5793
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
The vty is randomly including the pdp context when the vty
command 'show mm-context all' is issued without the pdp
parameter.
I do not know why, but I assume that relying on a true/false
test of argv[0] has unpredictable results.
Change-Id: Idcde4dd30a39625b24a1c3a38901349875e0949a
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
Let's always send the event to the FSM and keep logic of whether it's a
good event to sent or not inside the FSM, not in the caller.
The logic is kept the same: if the event is not expected (not handled),
keep forcing free of the IU connection.
In theory this should never happen since only a PMM in Connected state
should have a established connection (hence only a PMM in Connected
state can have it released). In any case let's keep the safety check,
but let the FSM receive the event and log an error about unexpected
event, which is more interesting from debug point of view.
While at it, clean up the related logging line: There's no need to print
the imsi explicitly, since LOGMMCTXP already does it. Furthermore, print
the exact low level event which triggered the code path.
Related: SYS#5389
Change-Id: I45017562ea7f27c2248b7de56f99ce7ca88e89b2
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
This Iu timer is Osmocom specific, but is made to resemble T3314 timer
from GERAN (also named READY timer). The READY timer mission is to make
the MM state transition from READY to STANDBY, which in PMM (UTRAN)
matches the transition from CONNECTED to IDLE.
Instead, the patch introducing the timer was making it transition to
DETACHED directly, but this was clearly not the intention:
* Detaching a UE after 44 seconds (default value for T3314) is overkill.
* The comment describing it says: "Iu User inactivity timer. On expiry
release Iu connection". The release of Iu connection happens during
the CONNECTED->IDLE transition (that's basically the difference between
both states).
The transition CONNECTED->IDLE is done by means of calling
sgsn_ranap_iu_release_free(), which will eventually answer with a event
RANAP_IU_EVENT_IU_RELEASE from lower layers when the Release Complete is
received. At that point, osmo-sgsn code frees the connection and
transitions to IDLE state. This way we maintain the state according to
the connection existance.
Related: SYS#5389
Related: osmo-iuh.git Change-Id Iac822c74e56750dc40e94573eae0e20853ff68c0
Fixes: 3bad31bcb4
Change-Id: I7279102ad51b0c39eb6d04c129986984112d15cc
It can happen that the MS tries to attach while SGSN's MM Iu state is
ST_PMM_IDLE (eg because UE was hard rebooted). Since Attach is a
specific case of getting a Connection Established, also allow it as a
trigger to transit to state ST_PMM_CONNECTED.
Related: SYS#5389
Change-Id: Ia74a062ddc3052faad569f1428f0ddd02e5b188d
Attach event should only be triggered by rx Attach Request, not other
messages. Furthermore, currently E_PMM_PS_CONN_ESTABLISH is defined and
expected in FSM but not sent by anyone.
Also, The opposite transition is done by E_PMM_PS_CONN_RELEASE:
"""
MM_STATE_Iu(0)[0x81379b0]{Connected}: Received Event E_PMM_PS_CONN_RELEASE
MM_STATE_Iu(0)[0x81379b0]{Connected}: state_chg to Idle
...
MM(001010123456063/c8b8bd08) -> GMM SERVICE REQUEST MI(3367550216) type="signalling"
MM_STATE_Iu(0)[0x81379b0]{Idle}: Received Event E_PMM_PS_ATTACH
MM_STATE_Iu(0)[0x81379b0]{Idle}: Event E_PMM_PS_ATTACH not permitted
"""
Related: SYS#5389
Change-Id: Ica00891f91834522f4dea2508b62af34e4c4eca7
Due to whatever errors, the MS may re-init the Common Procedure by
retransmitting a GPRS Attach Request while we are for instance aiting
for Identity to be resolved.
See this log:
MM(---/ffffffff) -> GMM ATTACH REQUEST MI(3903513414) type="GPRS attach"
GMM(gmm_fsm)[0x8136110]{Deregistered}: Allocated
GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x81383c0]{Init}: Allocated
MM_STATE_Gb[0x8138ac0]{Idle}: Allocated
MM_STATE_Iu[0x8138bb0]{Detached}: Allocated
GMM(gmm_fsm)[0x8136110]{Deregistered}: Received Event E_GMM_COMMON_PROC_INIT_REQ
GMM(gmm_fsm)[0x8136110]{Deregistered}: state_chg to CommonProcedureInitiated
GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x81383c0]{Init}: Received Event E_ATTACH_REQ_RECV
GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x81383c0]{Init}: state_chg to CheckIdentity
MM(/fba673a2) <- GPRS IDENTITY REQUEST: mi_type=IMEI
UE(0x2){001-01-10422-99} Received GSM 04.08 message type 0x16, but no MM context available
GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x81383c0]{CheckIdentity}: Timeout of T3370
MM(/fba673a2) <- GPRS IDENTITY REQUEST: mi_type=IMEI
[Failure to handle GSM48_MT_GMM_ID_RESP and subsequent retransmission of GPRS IDENTITY REQUEST happens a couple times here]
MM(---/ffffffff) -> GMM ATTACH REQUEST MI(3903513414) type="GPRS attach"
GMM(gmm_fsm)[0x8136110]{CommonProcedureInitiated}: Received Event E_GMM_COMMON_PROC_INIT_REQ
GMM(gmm_fsm)[0x8136110]{CommonProcedureInitiated}: Event E_GMM_COMMON_PROC_INIT_REQ not permitted
GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x81383c0]{CheckIdentity}: Received Event E_ATTACH_REQ_RECV
[Here IDENTITY REQUEST is sent again, and this time MS answers ID RESPONSE back and goes forward]
Related: SYS#5389
Change-Id: I93d7d6bc694c84223a11d075d24c234b82b73389
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
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
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
All gprs_ns2 enums have now GPRS_NS2 as prefix.
API change which must be synchronized with libosmocore
Depends-on: I548ff12f7277cbb7e1a630a3dc02b738ce89be72 (libosmocore)
Change-Id: I1af704cdd62ddaff4304479b837dc185b80d7dd6
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
gprs_subscr_get_or_create() can return NULL if no memory can
be allocated. Detected by the compiler on Ubuntu s390x.
Signed-off-by: Steve Langasek <steve.langasek@ubuntu.com>
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Change-Id: I86b3652d46bdd581fe6cbab16b52395a0daaa082
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
sgsn_delete_pdp_ctx() should never be called without checking if the GTP
side is available, since it may happen that it has already been released
by the time the mmctx tells us the pdp ctx is gone on the MS side.
Fixes: OS#4817
Change-Id: Ie618874545172ec98355174a2ee041fc4a8bec16
This function is only expected to be called if the GTP side of the PDP
ctx is still alive, since it will tear down the GTP side and then finish
the pending MS side if needed.
The asserts are added to ease debugging since it was noted that a few
callers were using this function without properly checking the status of
the pdp ctx.
Related: OS#4817
Change-Id: I4248e2e9846fec5ae2c8557384da2deb86668c50
The SGSN initialises GTP with gtp_statedir of "./" which may
not be the desired path for writing the gsn_restart file.
When starting from systemd for example, we might write
to the system root.
This patch allows override via the config file.
Closes: OS#4820
Change-Id: Ib3ffb7fd6ea1d9b0286111d8c2cba9da5394ca58
Scenario:
1- For an unknwon reason, sgsn sends DeletePdpCtxReq on GTP towards GGSN.
2- GGSN answers with Error Indication to that pdp ctx which calls
gtp_freepdp()
3- gtp_freepdp() calls libgtp callback cb_delete_context() before freeing the
pointer, in osmo-sgsn callback points to cb_delete_context(), which
removes pctx->ggsn and tries to drop the pdp on the NS side by sending a
DeactPdpReq.
4- While waiting for DeactPdpAck, the MS/PCU sends a DeactPdpReq, and
code was unconditionalyl trying to release the gtp side without checking
if it was alreay released, using pctx->ggsn==NULL and crashing.
This is basically the same logic already in place in regular path
gsm48_rx_gsm_deact_pdp_ack.
Related: OS#4817
Change-Id: I02587a3dc812823d893fc00b904142b75fd190b9
When compression is turned on, an extra buffer "expnd" is allocated in
the context of msg. This means that when msg is freed, expnd is freed as
well and there is no need for freein it explcicitly, which, when it is
done after freeng msg, causes talloc to abort.
Change-Id: I8959b75e241ffabf9fa34c4cf014721584372b26
Neels Hofmeyr
Pau Espin
Oliver Smith
Keith Whyte
Eric Wild
Vadim Yanitskiy
Harald Welte
Philipp Maier
Alexander Couzens
Daniel Willmann