When using 'check_PROGRAMS', autoconf/automake generates smarter
Makefiles, so that the test programs are not being compiled during
the normal 'make all', but only during 'make check'.
Change-Id: I8118ee3d3da9bdcd0c691471ef91b95dba21004a
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
Do not turn some compiler warnings into errors by default. This patch
was added before --enable-werror was available.
We build with --enable-werror during development and in CI. If the code
is built with a different compiler that throws additional warnings, it
should not stop the build.
This reverts commit 34f012639d.
Related: OS#5289
Change-Id: I24e0a0d7f93f196dc642e37b03f68464024c09d4
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
Use list_first_entry_or_null instead of llist_first, which has been
present in libosmocore since the 0.10.0 release.
Use llist_last_entry instead of llist_last (also present since
libosmocore 0.10.0). This macro does not have a check for an empty
list, however the only user is already checking for an empty list
before using the macro.
This solves a build error, as llist_last was defined in libosmocore
Icf455bf6ba9d60bd311af17c9e80febaa42cacc9 (should probably be reverted
for backwards compatibility with previous osmo-sgsn versions?):
gtphub.c:68:0: error: "llist_last" redefined [-Werror]
#define llist_last(head, type, entry) \
In file included from /build/deps/install/stow/libosmocore/include/osmocom/core/timer.h:46:0,
from /build/deps/install/stow/osmo-ggsn/include/gtp.h:17,
from gtphub.c:32:
/build/deps/install/stow/libosmocore/include/osmocom/core/linuxlist.h:245:0: note: this is the location of the previous definition
#define llist_last(head) (head)->prev
Change-Id: Ia0496c24386cd13b1e9e604aa2d425d3fa28d352
The old command is deprecated since [1] has been merged.
Change-Id: Iac985f373de98206fdfb3196295ebec160189780
Related: [1] Ie6700c4e9d2df1eb5fde1b971e287b62668cc2de
Related: SYS#5324
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
Move 'doc' subdir further down to "make sure" the osmo-bsc binary is built
before the docs
Rremove sgsn_vty_reference from the source tree.
In manuals//Makefile.am use the new BUILT_REFERENCE_XML feature recently added
to osmo-gsm-manuals, and add a build target to generate the XML using the new
osmo-sgsn --vty-ref-xml cmdline switch.
Change-Id: Ied75fdd13283aa592350994fb4febce06c213d3a
Depends: I613d692328050a036d05b49a436ab495fc2087ba
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
The gprs_ns2_vty2 has been renamed to gprs_ns2_vty. The old
vty has been complete dropped.
API change which must be synchronized with libosmocore.
Depends-on: I8c3f2afecc74b78f7f914f7dce166cbcb63444eb (libosmocore)
Change-Id: If5bd6b86e130772e6c93d640b0c637985416136d
Harald Welte
Vadim Yanitskiy
Neels Hofmeyr
Pau Espin
Oliver Smith
Keith Whyte
Eric Wild
Daniel Willmann
Philipp Maier
Alexander Couzens