Commit Graph

87 Commits

Author SHA1 Message Date
Pau Espin 3caa7f6d97 Iu: Drop timer X3314
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
2021-04-14 12:14:52 +02:00
Pau Espin 223754fde5 mm_state_iu_fsm: T3314 expiry must lead to PMM IDLE, not PMM DETACHED
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
2021-04-13 20:36:06 +02:00
Pau Espin f025e582bb gprs_gmm.c: State proper GMM prefix logging rx/tx of GMM messages
Change-Id: I58af41acdc4a04870b4cf2ea34a272d46d896254
2021-04-13 11:58:59 +02:00
Pau Espin e8cd6856a5 mm_iu: Expect E_PMM_PS_ATTACH when in ST_PMM_IDLE
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
2021-03-25 17:58:07 +01:00
Pau Espin c67c90b47e mm_iu: Send event E_PMM_PS_CONN_ESTABLISH upon rx GMM SERVICE REQUEST
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
2021-03-25 17:58:03 +01:00
Pau Espin c26072a77f gmm_fsm: Expect E_GMM_COMMON_PROC_INIT_REQ when in ST_GMM_COMMON_PROC_INIT
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
2021-03-25 16:57:24 +01:00
Pau Espin ce0a0e9beb gmm: Expect E_VLR_ANSWERED when in ST_IU_SECURITY_CMD
GSUP message is sent immediately before moving onto state
ST_IU_SECURITY_CMD, so it's expected to receive a response for it, which
will trigger event E_VLR_ANSWERED being sent.
See following log showing the scenario:

"""
GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x8137b88]{Authenticate}: Received Event E_AUTH_RESP_RECV_SUCCESS
MM(001010123456789/f8bab3dc) Requesting authorization
MM(001010123456789/f8bab3dc) Missing information, requesting subscriber data
MM(001010123456789/f8bab3dc) Requesting subscriber data update
SUBSCR(001010123456789) subscriber data is not available
SUBSCR(001010123456789) Sending GSUP, will send: 04 01 08 00 01 01 21 43 65 60 f3 28 01 01
GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x8137b88]{Authenticate}: state_chg to IuSecurityCommand
SUBSCR(001010123456789) Received GSUP message OSMO_GSUP_MSGT_INSERT_DATA_REQUEST
SUBSCR(001010123456789) Will set PDP info, context id = 1, APN = 01 2a
SUBSCR(001010123456789) Updating subscriber data
MM(001010123456789/f8bab3dc) Subscriber data update
MM(001010123456789/f8bab3dc) Updating authorization (authenticate -> accepted)
MM(001010123456789/f8bab3dc) Got authorization update: state authenticate -> accepted
MM(001010123456789/f8bab3dc) Authorized, continuing procedure, IMSI=001010123456789
GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x8137b88]{IuSecurityCommand}: Received Event E_VLR_ANSWERED
GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x8137b88]{IuSecurityCommand}: Event E_VLR_ANSWERED not permitted
SUBSCR(001010123456789) Sending GSUP, will send: 12 01 08 00 01 01 21 43 65 60 f3 28 01 01
SUBSCR(001010123456789) Received GSUP message OSMO_GSUP_MSGT_UPDATE_LOCATION_RESULT
SUBSCR(001010123456789) Updating subscriber data
MM(001010123456789/f8bab3dc) Subscriber data update
MM(001010123456789/f8bab3dc) Updating authorization (accepted -> accepted)
sccp_sap_up(N-DATA.indication)
N-DATA.ind(2, 20 06 00 08 00 00 01 00 06 00 01 00 )
handle_co(dir=2, proc=6)
Transmitting RANAP CommonID (SCCP conn_id 2)
GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x8137b88]{IuSecurityCommand}: Received Event E_IU_SECURITY_CMD_COMPLETE
GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x8137b88]{IuSecurityCommand}: state_chg to WaitAttachComplete
"""

Related: SYS#5389
Change-Id: If348ff32faa4a709b59ee1b9b043883a7d46cf93
2021-03-25 16:35:07 +01:00
Pau Espin c8ace5a03c gmm: log GMM msg type name instead of number
Change-Id: I2dc6eb5bfb0f44caf2687e582d660f71fdd647a2
2021-03-25 16:03:05 +01:00
Pau Espin 183e6c3367 ranap: log ranap iu event type name instead of number
Change-Id: If66e9d5989b46abe01855a5c1183d567d358abeb
2021-03-25 15:54:45 +01:00
Vadim Yanitskiy 8de4be261d main: resurrect removed 'ns' logging category as deprecated
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
2021-03-14 20:59:08 +01:00
Harald Welte adcf97d095 Remove bogus DNS log category
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
2021-03-10 12:30:05 +00:00
Harald Welte ebd39830cb main: change initialization order
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
2021-02-23 16:43:37 +01:00
Harald Welte 999a776b70 main: add --vty-ref-mode, use vty_dump_xml_ref_mode()
Change-Id: I893fc869d5900eff8395bfded0c2fa3883c5a1e7
Depends: Ie2022a7f9e167e5ceacf15350c037dd43768ff40
Related: SYS#5359
2021-02-23 15:52:54 +01:00
Pau Espin 11ccc4305d Fix nsei+bvci not updated on rx UL SNDCP data
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
2021-02-16 13:59:07 +01:00
Pau Espin 4be5ab3707 sndcp: Fix struct bit fields on big endian
Change-Id: I30014bf84e7a69fa3d85d542d03e41d56506beb7
2021-02-04 12:49:40 +01:00
Philipp Maier 2ce050ba46 sgsn_rim: Add routing for (GERAN) BSSGP RIM messages
The SGSN currently does not forward BSSGP RIM messages.

Related: SYS#5103
Depends: libosmocore Icd667f41d5735de56cd9fb257670337c679dd258
Change-Id: I6fde8ab8955660b48000ca1b650cfc7c7b2e24ba
2021-01-28 23:20:31 +01:00
Alexander Couzens 43e5f8a2c6 follow libosmocore/gprs_ns2 API changes (gprs_ns2_dynamic_create_nse)
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
2021-01-28 21:19:59 +00:00
Alexander Couzens caf73b803c sgsn: migrate to the new gprs_ns2_vty configuration
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
2021-01-28 21:19:59 +00:00
Alexander Couzens 21afdf9a32 follow libosmocore/gprs_ns2 API changes of GPRS enums
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
2021-01-27 21:07:01 +01:00
Alexander Couzens f23e2db752 sgsn: Use the new NS2 api
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
2021-01-04 16:06:13 +00:00
Alexander Couzens 3326ba7d4c sgsn: check for NULL of gprs_subscr_get_or_create()
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
2020-12-15 11:57:16 +01:00
Daniel Willmann 7c86a1efce mm_state_gb_fsm: Handle implicit detach from mm_standby
Change-Id: I63d04a2dcdc17b4df6616c515641c435d919c787
Related: OS#2737
2020-12-10 15:25:51 +00:00
Harald Welte 453a51d1a1 migrate to DLBSSGP as log sub-system for BSSGP
Change-Id: I69ee10b6fad1da2053cf6f3ae99d3ecf62a144ce
Depends: libosmocore.git Change-Id I506190aae9217c0956e4b5764d1a0c0772268e93
2020-12-10 15:42:15 +01:00
Pau Espin 83142beca2 gmm: Introduce comment to ease addition of Network feature support IE later
Change-Id: I131cba3de3c80c61d5549e7c31b4eacaaeddb040
2020-12-01 11:47:58 +00:00
Pau Espin 8c3d7fd263 gmm: fix build without define PTMSI_ALLOC
Change-Id: Idcac01c4634af81ef884dc2b1b20dec3f8d12236
2020-12-01 11:47:58 +00:00
Pau Espin bcd7709452 sgsn: generate coredump and exit upon SIGABRT received
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
2020-11-25 18:28:55 +01:00
Daniel Willmann 62fa6198ae Let libosmocore handle VTY parent node tracking
* 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
2020-11-06 22:21:21 +01:00
Pau Espin 08395b3369 process_ms_ctx_status: Fix crash deleting PDP Ctx if GTP side was already released
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
2020-10-23 13:25:13 +02:00
Pau Espin 25998ddcc5 process_ms_ctx_status: refactor to avoid code duplication
Change-Id: I1d1a1284c1563b3a5598e79d8ffd544288de4d62
2020-10-23 13:23:18 +02:00
Pau Espin 60581ae7c9 sgsn_delete_pdp_ctx: Add documentation and assert assumptions
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
2020-10-23 13:04:48 +02:00
Keith Whyte c70e8388c7 VTY: Add gtp state-dir command
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
2020-10-20 13:21:37 +00:00
Pau Espin 5ce54ba1e6 Fix crash rx DeactPdpReq while waiting for DeactPdpAck after gtp side is freed
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
2020-10-19 15:06:55 +00:00
Pau Espin ff5b59a821 Log error if pdp ctx is freed while holding an active timer
Change-Id: Iae520be36377b27a12441defa722fd41a3cdba0a
2020-10-19 15:06:55 +00:00
Harald Welte be2330fde4 Use osmo_fd_setup() whenever applicable
Change-Id: I68d14b1c19dd8f1764fdf65afe1a957278255e40
2020-10-19 10:50:45 +00:00
Philipp Maier ef6205ba00 gprs_sndcp: fix use after free
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
2020-10-02 17:38:12 +02:00
Keith Whyte 6d92f148aa Fix Radio Priority in MM Attach and PDP Context Activation
3GPP TS 24.008 Section 10.5.7.2 Radio Priority states that the Radio Priority IE is
3 bits as follows:

--------------------------------------------
0 0 1   priority level 1 (highest)
0 1 0   priority level 2
0 1 1   priority level 3
1 0 0   priority level 4 (lowest)

All other values are interpreted as priority
 level 4 by this version of the protocol.
--------------------------------------------

However at least the MediaTek MT6753 and MT6592 have been
observed to interpret a value of 0 0 0 in an undetermined way
resulting in lack of access to RACH in the cell.

Fixes: OS#4506
Change-Id: I810cd541eb5764ee3f2c238bcd3a10836228d0b5
2020-09-21 00:18:48 +02:00
Alexander Couzens 27a0bf70e7 gmm: on invalid RA id reject the MS with an implicit detach
As long the SGSN doesn't support PS handover treat unknown RA as invalid
and do an implicit detach.

Fixes ttcn3 crash when an RAU happen within an Attach Request

Change-Id: I6a0b335d51f58c26349f7e0a62b2107d7d351d07
2020-09-20 09:52:24 +00:00
Alexander Couzens d3c3ddeb51 gprs_llc: _bssgp_tx_dl_ud: ensure the LLME is valid before using it
In rare cases the LLME is NULL even when the mmctx is valid.
Ensure not accessing a NULL pointer.

Change-Id: Id9fdfb0d88264671546f8dfc4655032ff27bf43e
2020-09-18 18:32:04 +02:00
Pau Espin e6c5b4a970 Change default SCTP conn NULL->127.0.0.1 to localhost->localhost
"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
2020-08-21 18:07:11 +02:00
Pau Espin aae7daff81 Support setting rt-prio and cpu-affinity mask through VTY
Change-Id: I1af1b154d14de6d6d6fba08f15f167f4b2ed9aa2
Depends: libosmocore.git Change-Id If76a4bd2cc7b3c7adf5d84790a944d78be70e10a
Depends: osmo-gsm-masnuals.git Change-Id Icd75769ef630c3fa985fc5e2154d5521689cdd3c
Related: SYS#4986
2020-08-18 13:50:00 +02:00
Harald Welte 9d16b14345 Send a BVC-RESET to all persistent Gb interfaces at start-up
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
2020-07-27 14:43:36 +00:00
Pau Espin b3e10aa8eb sgsn_libgtp: Avoid ps-paging MS on GMM Suspended state
The MS notifies movement to GMM SUSPEND state because it is for instance
handling a call and cannot use PDCH anymore. Once it releases the TCH it
will ASAP move to either dedicated mode or trigger RAU, which means it
will get out of SUSPEND state. So it doesn't make sense to try paging
the MS when in that state.

This change makes test TC_suspend_nopaging pass.

Related: OS#4616
Change-Id: Ia245899eb9f16c7f839785def4ceb721a1c3a11b
2020-06-26 12:20:57 +02:00
Pau Espin 36ecddb705 gprs_gmm_fsm.c: Add missing license header
The file was created by myself on September 2019,
31c4657c97.

Change-Id: I94299b9ccf760ad13429e149067f06ed60d37de3
2020-06-26 12:07:12 +02:00
Pau Espin cfd307b4e8 sgsn_libgtp: Improve ps-paging logging
Change-Id: I0c3d48d54295824c3ba5b0fa9e3c035983556326
2020-06-18 11:39:13 +00:00
Neels Hofmeyr b26a5a82db use new osmo_mobile_identity API everywhere
Depends: If4f7be606e54cfa1c59084cf169785b1cbda5cf5 (libosmocore)
Change-Id: I4cacb10bac419633ca0c14f244f9903f7f517b49
2020-06-18 11:23:35 +00:00
Harald Welte 5e1a486a72 Treat RAU as implicit RESUME if GMM is suspended
We so far only resumed from suspend upon receiving an explicit BSSGP
RESUME message from the BSS.  The latter is only possible in
BSC-colocated PCU, where the BSC can trigger the message when releasing
the dedicated channel.  In BTS-colocated PCUs, this is not possible,
and we have to rely on the MS resuming by RAU.

See 3GPP TS 23.060 section 16.2.1.1.1 clause 6:

The MS shall resume GPRS services by sending a Routeing Area Update Request message to the SGSN:
* if the BSS did not successfully request the SGSN to resume GPRS services,
* if the RR Channel Release message was not received before the MS left dedicated mode,
* if the MS locally determines that the conditions for the GPRS suspension have disappeared

Without this patch, the GMM state would forever be stuck in SUSPEND,
which in turn causes the SGSN to page the MS all the time.

Change-Id: I3c09187a27483d95fa0070bbb467f94a2ea3978f
Related: OS4616
2020-06-17 21:09:03 +00:00
Harald Welte 627e285fd0 Fix memory leak when SNDCP de-fragmentation is used
As msgb ownership is not passed along, we need to free the message
buffer memory we allocate in defrag_segments() after calling
sgsn_rx_sndcp_ud_ind().

Change-Id: I1185b1aa99bb167d616eb469e5445e4ed5ad949d
Closes: OS#4603
2020-06-08 20:46:53 +02:00
Neels Hofmeyr b63e19d7d2 gsup: send RAT type on LU
At 36c3, osmo-hlr was run with a patch that records the RAN type of attached
subscribers. Even though this is not in osmo-hlr master, it is nice information
to send along.

Change-Id: I5dbe610738aed7ea1edf6b33543b1c03818cc274
2020-05-12 13:52:24 +02:00
Neels Hofmeyr c6548bbaab fix nullpointer: in gsm48_rx_gmm_ra_upd_req()
This caused frequent crashes at 36c3. The "proper" fix is probably elsewhere
(lynxis mentions an unfinished patch), but at least this prevented some crashes
during active operation.

Once this is merged, we can (re)enable SGSN_Tests_Iu.TC_geran_attach_iu_rau,
which tests exactly for this scenario:  A Subscriber / MM context that is so
far attached via GERAN, but now receives a RAU via UTRAN/Iu.

Closes: OS#4339
Change-Id: Ifde15dc4151d84748f0e67b32c9c260cb2d9d8fc
2020-05-10 22:33:27 +00:00
Pau Espin b2ebc59f30 Use OSMO_FD_* instead of deprecated BSC_FD_*
New define is available since libosmocore 1.1.0, and we already require
1.2.0, so no need to update dependenices.
Let's change it to avoid people re-using old BSC_FD_* symbols when
copy-pasting somewhere else.

Change-Id: Iaebd049e383b02204a12f39cc6c932a53d25fd72
2020-05-09 19:21:15 +02:00