Commit Graph

196 Commits

Author SHA1 Message Date
Neels Hofmeyr 3f92103c62 fix asn1 leak in hnbgw_rua_rx()
Related: SYS#6297
Change-Id: I7392e0bb07c2cb02c1a12f8e19acb142cd101f77
2023-04-27 16:39:06 +00:00
Neels Hofmeyr 0d2251ef7d fix asn1 leaks in ps_rab_ass_resp_send_if_ready()
Related: SYS#6297
Change-Id: Icdb6eef0d1fde849c0b9121cc96d8221e72d45c8
2023-04-27 16:39:06 +00:00
Neels Hofmeyr 5437aeaca4 fix asn1 leak in error path of hnbgw_tx_ue_register_acc_tmsi()
Related: SYS#6297
Change-Id: Iad1519aea36d8b6fef51fedb22a861ad1bc462fc
2023-04-27 16:39:06 +00:00
Neels Hofmeyr e33d7321df fix asn1 leak in error path of hnbgw_tx_ue_register_acc()
Related: SYS#6297
Change-Id: Iaaf7a393ef1fcad619687e2eb2dcc31f0aec0e96
2023-04-27 16:39:06 +00:00
Neels Hofmeyr 7f219856c9 fix asn1 leak in handle_cn_ranap()
Related: SYS#6297
Change-Id: I307f65ae083aba16f75510bcd0a7d1f124e62be4
2023-04-27 16:39:06 +00:00
Neels Hofmeyr 0188391a19 place asn1 context under hnb_ctx for better visibility
Include talloc_asn1_context in 'show talloc-context application'. It
belongs there IMO.

Related: SYS#6297
Change-Id: Iffc320c64713b225b57211da4fb95a868bf1f369
2023-04-27 16:39:06 +00:00
Neels Hofmeyr 4a4a675fec fix vty: show talloc-context all
Without "null tracking" enabled, the VTY 'show talloc-ctx all' shows
nothing at all.

Since the talloc_asn1_ctx is "created in NULL ctx", it was not visible
in any talloc reports before this patch.

This patch uncovers a slur of leaks, which accumulate in
talloc_asn1_ctx. Fixes follow.

Related: SYS#6297
Change-Id: I5cb4e9a3b393100877f03d68a09acf5817c5a878
2023-04-27 16:39:06 +00:00
Oliver Smith 8fd4159ea9 hnbgw_mgw_setup: use mgcp_client_pool_empty()
Don't fall back to the legacy config if the pool is configured but no
connection to any pool member can be established.

Depends: osmo-mgw I009483ac9dfd6627e414f14d43b89f40ea4644db
Related: OS#5993
Change-Id: Icf3f3f0524c9d27f645c68851aaf9c6f33842927
2023-04-04 16:32:37 +02:00
Neels Hofmeyr 0b10b5799f vty: 'show ue': show which HNB the UE is registered on
Change-Id: Ife54a105a5a011678d6a03d0032c7622c3079a28
2023-03-24 04:14:59 +01:00
Neels Hofmeyr bc92608e60 log: in new RUA,SCCP FSM IDs, indicate CS/PS
During tests without an SGSN, I noticed SCCP connections failing, and I
also noticed that I couldn't tell if they were CS or PS related. Add a
"CS"/"PS" indicator to FSM instance IDs for RUA and SCCP.

Change-Id: I5b8242196af3b08eaf64ca5ac1c257a97a5d02cb
2023-03-24 04:14:59 +01:00
Neels Hofmeyr be7df7c1a7 release UE Contexts on SCTP_RESTART
When receiving SCTP_RESTART for a given HNB, directly clear the UE
Contexts.

(The HNB typically connects via HNBAP shortly after this causing a UE
Context clearing too, but UE state should always be cleared on
SCTP_RESTART, no matter what.)

Change-Id: I583922193ba73e17ab85152005535188c2762b85
2023-03-24 04:14:59 +01:00
Neels Hofmeyr 01389592b2 release UE Contexts on HNB (Re-)Register
Whenever a HNB reconnects, we want to discard all previous UE state and
any active connections.

In one HNB reconnect scenario, we receive SCTP_RESTART. This sets
hnb_registered == false, which in turn skipped the UE cleanup step in
hnbgw_rx_hnb_register_req(), leaking UE Contexts.

Remove all weird conditions like that, and simply clear out all UE state
whenever a HNB registers, period.

Change-Id: I370966d2d76fd263714e727918fcc1ea2f2315fa
2023-03-24 04:14:59 +01:00
Neels Hofmeyr 9425640d7f map_sccp: on timeout during WAIT_CC, send N-DISCONNECT to SCCP-SCOC
When waiting for CC expires, we should tell the SCCP-SCOC that we've
stopped waiting: send N-DISCONNECT, instead of nothing.

Change-Id: Ie94fcee4e2507a55449050aab96307199aed99a2
2023-03-24 04:14:56 +01:00
Philipp Maier c6cef24546 mgw_fsm: refactor helper function handle_rab_release()
the function handle_rab_release() is difficult to read and it is not
immediately clear what happens and why. Lets split this up and add some
comments to improve this.

Related: OS#5916
Change-Id: I3595502b98ea5febbde7f2fab3999e2533766b48
2023-03-21 09:46:33 +01:00
Philipp Maier 065a719294 mgw_fsm: use __func__ to mention function name in log line
Change-Id: I23050fc5f644340dfbd0323eef6309cff6fc4515
2023-03-21 09:46:33 +01:00
Philipp Maier cc7d2b1313 mgw_fsm: fix log line
The function name mentioned in the log line does not match the actual
function name.

Change-Id: Iefc005f10e3c8f165c5686781747460a10ada1e0
2023-03-21 09:43:36 +01:00
Philipp Maier 1c4b05d026 mgw_fsm: fix typo
Change-Id: I16ee37bbfda01b541ad7a6f5269689c4b9e92c8c
2023-03-20 16:43:42 +01:00
Neels Hofmeyr 9e051548d6 debug log: log received RANAP message types on DCN, DHNB
Change-Id: Ib295e49f2c53164c5787002797145b3e6de5546b
2023-03-09 03:24:30 +01:00
Neels Hofmeyr b5dfba79ca fix regression: unbreak PFCP: PS RAB via UPF proxying
Fix PS RAB Assignment operation:
- add #include "config.h"
- fix uncompilable code in ENABLE_PFCP sections.

A series of oversights made me completely break PFCP / UPF operation for
PS RAB Assignments in this commit:
 'context map: introduce RUA and SCCP FSMs to fix leaks'
 ed424d5be4
 I6ff7e36532ff57c6f2d3e7e419dd22ef27dafd19

- In my HNBGW_Tests.ttcn, I used osmo-hnbgw-with-pfcp.cfg, but failed to
  set mp_enable_pfcp_tests := true in HNBGW_Tests.cfg.

- Hence I was under the impression that I was testing PFCP via UPF when
  really I wasn't. So I did not notice that:

- in the new files context_map_rua.c and context_map_sccp.c, the
  ENABLE_PFCP macro was always unset because I forgot to
  #include "config.h".

- Hence I did not notice that the moved PFCP RAB code was never once
  compiled or run.

My bad, that was really dumb.

Related: SYS#6297
Change-Id: I5df5073f0092ecdfd73d5d08207ca4042154eab1
2023-03-09 03:24:30 +01:00
Neels Hofmeyr 0fdb5c3f09 sccp_sap_up(): ignore PCSTATE.ind
Silence the error log about "unknown" PCSTATE prim.

Todo / coming up: instead of ignoring, detect a Destination Unavailable
from prim->u.pcstate and disconnect all conns with that particular CN
link.

Depends: libosmo-sccp If381f537ab91af1feef7f0e51921217f27e18e6a
Change-Id: I547387a5cc14ccb506be04ac785e6807fc4e6a96
2023-02-24 15:19:24 +01:00
Neels Hofmeyr 311bfb5983 log osmo_fsm timeouts
set osmo_fsm_log_timeouts(true);

Change-Id: Ic1ca03f06fbdef5a3fbe503e4414a780eb3e0fcc
2023-02-24 15:19:24 +01:00
Neels Hofmeyr ed424d5be4 context map: introduce RUA and SCCP FSMs to fix leaks
Refactor the entire RUA <-> SCCP connection-oriented message forwarding:
- conquer confusion about hnbgw_context_map release behavior, and
- eradicate SCCP connection leaks.

Finer points:

== Context map state ==
So far, we had a single context map state and some flags to keep track
of both the RUA and the SCCP connections. It was easy to miss connection
cleanup steps, especially on the SCCP side.
Instead, the two FSMs clearly define the RUA and SCCP conn states
separately, and each side takes care of its own release needs for all
possible scenarios.
- When both RUA and SCCP are released, the context map is discarded.
- A context map can stay around to wait for proper SCCP release, even if
  the RUA side has lost the HNB connection.
- Completely drop the async "context mapper garbage collection", because
  the FSMs clarify the release and free steps, synchronously.
- We still keep a (simplified) enum for global context map state, but
  this is only used so that VTY reporting remains mostly unchanged.

== Context map cleanup confusion ==
The function context_map_hnb_released() was the general cleanup function
for a context map. Instead, add separate context_map_free().

== Free context maps separately from HNB ==
When a HNB releases, talloc_steal() the context maps out of the HNB
specific hnb_ctx, so that they are not freed along with the HNB state,
possibly leaving SCCP connections afloat.
(It is still nice to normally keep context maps as talloc children of
their respective hnb_ctx, so talloc reports show which belongs to
which.)

So far, context map handling found the global hnb_gw pointer via
map->hnb_ctx->gw. But in fact, a HNB may disappear at any point in time.
Instead, use a separate hnb_gw pointer in map->gw.

== RUA procedure codes vs. SCCP prims ==
So far, the RUA rx side composed SCCP prims to pass on:

 RUA rx ---SCCP-prim--> RANAP handling ---SCCP-prim--> SCCP tx

That is a source of confusion: a RUA procedure code should not translate
1:1 to SCCP prims, especially for RUA id-Disconnect (see release charts
below).
Instead, move SCCP prim composition over to the SCCP side, using FSM
events to forward:

 RUA rx --event--> RUA FSM --event--> SCCP FSM --SCCP-prim--> SCCP tx
         +RANAP             +RANAP              +RANAP

 RUA tx <--RUA---- RUA FSM <--event-- SCCP FSM <--event-- SCCP rx
          +RANAP             +RANAP              +RANAP

Hence choose the correct prim according to the SCCP FSM state.
- in hnbgw_rua.c, use RUA procedure codes, not prim types.
- via the new FSM events' data args, pass msgb containing RANAP PDUs.

== Fix SCCP Release behavior ==
So far, the normal conn release behavior was

 HNB                 HNBGW                   CN
  | --id-Disconnect--> | ---SCCP-Released--> |  Iu-ReleaseComplete
  |                    | <--SCCP-RLC-------- |  (no data)

Instead, the SCCP release is now in accordance with 3GPP TS 48.006 9.2
'Connection release':

 The MSC sends a SCCP released message. This message shall not contain
 any user data field.

i.e.:

 HNB                 HNBGW                    CN
  | --id-Disconnect--> | ---Data-Form-1(!)--> |  Iu-ReleaseComplete
  |                    | <--SCCP-Released---- |  (no data)
  |                    | ---SCCP-RLC--------> |  (no data)

(Side note, the final SCCP Release Confirm step is taken care of
implicitly by libosmo-sigtran's sccp_scoc.c FSM.)

If the CN fails to respond with SCCP-Released, on new X31 timeout,
osmo-hnbgw will send an SCCP Released to the CN as fallback.

== Memory model for message dispatch ==
So far, an osmo_scu_prim aka "oph" was passed between RUA and SCCP
handling code, and the final dispatch freed it. Every error path had to
take care not to leak any oph.
Instead, use a much easier and much more leakage proof memory model,
inspired by fixeria:
- on rx, dispatch RANAP msgb that live in OTC_SELECT.
- no code path needs to msgb_free() -- the msgb is discarded via
  OTC_SELECT when handling is done, error or no error.
- any code path may also choose to store the msgb for async dispatch,
  using talloc_steal(). The user plane mapping via MGW and UPF do that.
- if any code path does msgb_free(), that would be no problem either
  (but none do so now, for simplicity).

== Layer separation ==
Dispatch *all* connection-oriented RUA tx via the RUA FSM and SCCP tx
via the SCCP FSM, do not call rua_tx_dt() or osmo_sccp_user_sap_down()
directly.

== Memory model for decoded ranap_message IEs ==
Use a talloc destructor to make sure that the ranap_message IEs are
always implicitly freed upon talloc_free(), so that no code path can
possibly forget to do so.

== Implicit cleanup by talloc ==
Use talloc scoping to remove a bunch of explicit cleanup code. For
example, make a chached message a talloc child of its handler:
  talloc_steal(mgw_fsm_priv, message);
  mgw_fsm_priv->ranap_rab_ass_req_message = message;
and later implicitly free 'message' by only freeing the handler:
  talloc_free(mgw_fsm_priv)

Related: SYS#6297
Change-Id: I6ff7e36532ff57c6f2d3e7e419dd22ef27dafd19
2023-02-24 15:19:24 +01:00
Neels Hofmeyr 52b2a9e6b0 use RUA procedure code for rua_to_scu() arg
Instead of osmo_scu_prim_type, use RUA_ProcedureCode to tell
rua_to_scu() the RUA message type being handled.

Cosmetically prepare for upcoming patch that completely moves
osmo_scu_prim composition from rua_to_scu() to a new context map SCCP
FSM.

Related: I6ff7e36532ff57c6f2d3e7e419dd22ef27dafd19
Change-Id: I28735945844f732e7bd7f09db1f453c608415b84
2023-02-23 01:57:21 +01:00
Neels Hofmeyr 62d50a1fe8 rua_to_scu(): drop dead code for connection-less
From rua_to_scu(), drop dead code for connection-less messages. In fact,
rua_to_scu() is only used for connection-oriented messages. Clarify
that.

Change-Id: Id03c412cde066a6b2bbc26cb6b87053aa2408cba
2023-02-23 01:43:16 +01:00
Neels Hofmeyr 1e277db2cc fix deprecation: use ranap_cn_rx_co_decode2()
Change-Id: I867cbf174beab1eefddc682c1420737e49f9e50d
2023-02-23 01:17:11 +01:00
Neels Hofmeyr 60a52e4121 cosmetic: rename context_map_deactivate
Rename context_map_deactivate() to context_map_hnb_released().

This function is called only when the HNB is released / lost.

Change-Id: I6dcb26c94558fff28faf8f823e490967a9baf2ec
2023-02-23 01:15:54 +01:00
Neels Hofmeyr 95d5273967 log tweak
Change-Id: Ib6f8c46355d4748089e59c80fc1c8c736c887a26
2023-02-22 14:52:36 +01:00
Neels Hofmeyr 43cc12bac3 various comment tweaks
Change-Id: Ie40aa672948062282c566c90300f6e96963e05ec
2023-02-21 00:57:03 +01:00
Neels Hofmeyr f05d15e160 drop obsolete fixme comment
msgb will be freed by osmo_stream_srv_send(), called via hnbgw_rua_tx().

Change-Id: If35f4cedf6f37be797dcd48e816461d3b1d9db54
2023-02-21 00:57:03 +01:00
Neels Hofmeyr 3f4d645890 Deprecate 'sccp cr max-payload-len', remove SCCP CR limit code
The SCCP CR payload length limit is now implemented in libosmo-sigtran
v1.7.0. The limit no longer needs to be enforced in osmo-hnbgw.

This reverts commit 2c91bd66a1,
except for keeping the cfg option, marked deprecated, and not doing
anything.

Fixes: OS#5906
Related: SYS#5968
Related: OS#5579
Depends: I174b2ce06a31daa5a129c8a39099fe8962092df8 (osmo-ttcn3-hacks)
Change-Id: I18dece84b33bbefce8617fbb0b2d79a7e5adb263
2023-02-15 03:34:43 +01:00
Neels Hofmeyr 8eefcbee92 UE state leak: when HNB re-registers, discard previous UE state
User reports show leaked UE contexts over time, in a scenario where HNB
regularly disconnect and reconnect.

So far, when we receive a HNB REGISTER REQ, we log as "duplicated" and
continue to use the hnb_context unchanged. But it seems obvious that a
HNB that registers does not expect any UE state to remain. It will
obviously not tear down UE contexts (HNBAP or RUA) that have been
established before the HNB REGISTER REQUEST. These hence remain in
osmo-hnbgw indefinitely.

When receiving a HNB REGISTER REQUEST, release all its previous UE
state. Allow the HNB to register with a clean slate.

The aim is to alleviate the observed build-up of apparently orphaned UE
contexts, in order to avoid gradual memory exhaustion.

Related: SYS#6297
Change-Id: I7fa8a04cc3b2dfba263bda5b410961c77fbed332
2023-02-11 03:32:34 +01:00
Neels Hofmeyr d41112fbcc coverity: hnbgw_rua.c: remove redundant check
'map' is already guaranteed to be not NULL for that message type by the
preceding switch().

Related: CID#307434
Change-Id: Id30f459616391187aa2f8ad400c316e2144154c6
2023-02-01 16:40:40 +01:00
Neels Hofmeyr 87ecf69b55 fix SCCP conn leak on non-graceful HNB shutdown
Clean up SCCP connections when a HNB disconnects.

When a HNB disconnects, we clean up all RUA <-> SCCP connection state
for that HNB. In that cleanup, discarding the SCCP connection is so far
missing.

Add a flag indicating true between SCCP CC and DISCONNECT. Hence we can
tell during context_map_deactivate() whether the cleanup is graceful
(DISCONNECT already sent) or non-graceful (need to DISCONNECT).

Change-Id: Icc2db9f6c0b2d0a814ff1110ffbe5e8f7f629222
2023-01-20 20:30:03 +01:00
Neels Hofmeyr 07d01d50a5 fix possible leak of ue_context on UE REGISTER error
Deallocate a recently allocated UE context if the UE REGISTER procedure
fails internally, in two places.

The UE REGISTER error is rather unlikely to happen in practice: it only
occurs when encoding the HNBAP response fails, which only gets checked
input and thus is unlikely to fail.

The same code paths also possibly leak asn1c allocations -- leave those
for another patch.

Related: SYS#6297
Change-Id: Icf4b82f9a904d56332c567f7ccfb24231ee66270
2023-01-18 18:42:50 +01:00
Neels Hofmeyr a08b8a595a fix msgb leak for RANAP RAB Ass. Req.
Fix leaked msgb introduced by the MGW support recently added, and from
there copied to the UPF support added after that.

Fixes leaked "RANAP Tx" msgb, one per RAB Assignment that involves an
MGW or UPF proxying of user data.

Related: SYS#6297
Change-Id: Ie30e880301346ffca72f98f8c467e56d622fb03f
2023-01-17 23:40:00 +01:00
Neels Hofmeyr 28619961a9 fix segfault on MGCP timeout
bisect shows that the segfault was introduced by using the MGCP client
pool:

 e62af4d46a is the first bad commit
 Author: Pau Espin Pedrol <pespin@sysmocom.de>
    Introduce support for libosmo-mgcp-client MGW pooling
    Change-Id I371dc773b58788ee21037dc25d77f556c89c6b61

The segfault:

 20230117224550365 DLMGCP DEBUG MGCP_CONN(to-HNB)[0x612000003ca0]{ST_CRCX_RESP}: Timeout of T1 (fsm.c:317)
 [...]
 20230117224550366 DLMGCP DEBUG mgw-endp(mgw-fsm-14429752-0)[0x612000003b20]{WAIT_MGW_RESPONSE}: Deallocated (fsm.c:568)
 20230117224550366 DMGW DEBUG mgw(mgw-fsm-14429752-0)[0x612000003820]{MGW_ST_CRCX_HNB}: Received Event MGW_EV_MGCP_TERM (mgcp_client_endpoint_fsm.c:869)
 =================================================================
 ==255699==ERROR: AddressSanitizer: heap-use-after-free on address 0x62b000000260 at pc 0x7f282a6ee143 bp 0x7fff0d9bcae0 sp 0x7fff0d9bcad8
 READ of size 8 at 0x62b000000260 thread T0
     #0 0x7f282a6ee142 in osmo_mgcpc_ep_client ../../../../src/osmo-mgw/src/libosmo-mgcp-client/mgcp_client_endpoint_fsm.c:223
     #1 0x55e2a84f1889 in mgw_fsm_allstate_action ../../../../src/osmo-hnbgw/src/osmo-hnbgw/mgw_fsm.c:504
     #2 0x7f2829d50c56 in _osmo_fsm_inst_dispatch ../../../src/libosmocore/src/fsm.c:863
     #3 0x7f2829d55a08 in _osmo_fsm_inst_term ../../../src/libosmocore/src/fsm.c:962
     #4 0x7f282a72679a in osmo_mgcpc_ep_fsm_check_state_chg_after_response ../../../../src/osmo-mgw/src/libosmo-mgcp-client/mgcp_client_endpoint_fsm.c:869
     #5 0x7f282a6f1869 in on_failure ../../../../src/osmo-mgw/src/libosmo-mgcp-client/mgcp_client_endpoint_fsm.c:414
     #6 0x7f282a727ac6 in osmo_mgcpc_ep_fsm_handle_ci_events ../../../../src/osmo-mgw/src/libosmo-mgcp-client/mgcp_client_endpoint_fsm.c:935
 [...]

When a CRCX times out, MGCP_CONN fsm terminates (libosmo-mgcp-client).
In turn the parent mgw-endp fsm terminates (libosmo-mgcp-client).
This generates an MGW_EV_MGCP_TERM event to the mgw_fsm (osmo-ttcn3-hacks).
This attempts to retrieve a pointer from mgw_fsm state:
mgw_fsm_priv->mgcpc_ep->mgcp_client
where the middle one, mgcpc_ep, is the 'mgw-endp' that already deallocated above.

To fix, add to /osmo-hnbgw/mgw_fsm.c a separate pointer to the
mgcp_client, to call mgcp_client_pool_put() on it. Do not use mgcpc_ep
to get the mgcp_client, because mgcpc_ep deallocates independently.

Related: OS#5862
Change-Id: I460d7249f4fc7edcfd94f6084fc8f933b491520c
2023-01-17 23:39:46 +01:00
Neels Hofmeyr 9bc7649b95 drop bogus error log 'no MGW fsm'
Looking at a customer's log, these error logs got my attention. There
seems to be no point in logging this at all.

Change-Id: I89dd4fb6913bfb84b6667b159e09968734e2102a
2023-01-03 00:29:58 +01:00
Pau Espin a1c8653bf9 context_map: Lower loglevel to INFO when deallocating context IDs
Change-Id: Iefe13934d097d646db232127040feb02db37bc38
2022-12-23 15:23:00 +00:00
arehbein 76c4203552 osmo-hnbgw: Transition to use of 'telnet_init_default'
Related: OS#5809
Change-Id: Id3256d09f62e802cc62fa9ba8aaafd403ccbb53e
2022-12-23 11:13:46 +00:00
Max a7fcbe100c ctrl: take both address and port from vty config
Change-Id: If5b80364c28fb1ca2bc00f4ece851de64c8ce6b1
2022-12-17 21:24:13 +03:00
Pau Espin 61021881ac hnbgw: Avoid allocating SCCP conn id >0x00fffffe
This fixes bug in use of M3UA/SCCP after 2**24 connection IDs have been
allocated.

Related: SYS#6211
Change-Id: I03bad960f65fbff6e467def5bba60fefb328f962
2022-11-24 12:13:10 +01:00
Pau Espin 0589c3ecf1 vty: Fix timers not printed when dumping running-config
Change-Id: I129bf412cd4b74e9f515411ef8f812a8261e57b2
2022-11-02 20:12:54 +01:00
Pau Espin e62af4d46a Introduce support for libosmo-mgcp-client MGW pooling
Large RAN installations may benefit from distributing the RTP voice
stream load over multiple media gateways.

libosmo-mgcp-client supports MGW pooling since version 1.8.0 (more than
one year ago). OsmoBSC has already been making use of it since then (see
osmo-bsc.git 8d22e6870637ed6d392a8a77aeaebc51b23a8a50); lets use this
feature in osmo-hngw too.

This commit is also part of a series of patches cleaning up
libosmo-mgcp-client and slowly getting rid of the old non-mgw-pooled VTY
configuration, in order to keep only 1 way to configure
libosmo-mgcp-client through VTY.

Related: SYS#5091
Related: SYS#5987
Change-Id: I371dc773b58788ee21037dc25d77f556c89c6b61
2022-10-20 17:03:06 +02:00
Pau Espin bef2c345df Makefile.am: Drop duplicated LIBOSMOMGCPCLIENT_LIBS
Change-Id: Ie52f27bcacca60cc16b49142edb79a3e58dff131
2022-10-19 15:56:52 +02:00
Pau Espin b9be0ea93e Clear SCTP tx queue upon SCTP RESTART notification
Depends: libosmo-netif.git Change-Id Iecb0a4bc281647673d2930d1f1586a2df231af52
Related: SYS#6113
Change-Id: I60adf35e5b5713d38c4584615e059875dcb74bd7
2022-10-17 13:57:17 +02:00
Pau Espin bbad8dec36 hnb_read_cb(): -EBADF must be returned if conn is freed to avoid use-after-free
Otherwise the libosmo-netif stream API may continue accessing the conn
after returning if the socket has the WRITE flag active in the same main
loop iteration.

Change-Id: I628c59a88d94d299f432f405b37fbe602381d47e
2022-10-01 21:21:24 +02:00
Pau Espin c923d19b7b hnb_read_cb: use local var to reduce get_ofd() calls
Change-Id: Ic7058b5a05b0d34b80617006d4e929a523212221
2022-10-01 21:21:24 +02:00
Pau Espin 5f19597b02 Close conn when receiving SCTP_ASSOC_CHANGE notification
It was seen on a real pcap trace (sctp & gsmtap_log) that the kernel
stack may decide to kill the connection (sending an ABORT) if it fails
to transmit some data after a while:
ABORT Cause code: "Protocol violation (0x000d)",
      Cause Information: "Association exceeded its max_retrans count".
When this occurs, the kernel sends the
MSG_NOTIFICATION,SCTP_ASSOC_CHANGE,SCTP_COMM_LOST notification when
reading from the socket with sctp_recvmsg(). This basically signals that
the socket conn is dead, and subsequent writes to it will result in
send() failures (and receive SCTP_SEND_FAILED notification upon follow
up reads).
It's important to notice that after those events, there's no other sort
of different event like SHUTDOWN coming in, so that's the time at which
we must tell the user to close the socket.
Hence, let's signal the caller that the socket is dead by returning 0,
to comply with usual recv() API.

Related: SYS#6113
Change-Id: If35efd404405f926a4a6cc45862eeadd1b04e08c
2022-10-01 21:21:06 +02:00
Pau Espin 1906a30ca9 Fix handling of sctp SCTP_SHUTDOWN_EVENT notification
SCTP_SHUTDOWN_EVENT is a first class event, and not a subtype of
SCTP_ASSOC_CHANGE (such as SCTP_SHUTDOWN_COMP).

Related: SYS#6113
Change-Id: I7fa648142c07f63c55091d2a15b9d7312bcd4cec
2022-09-30 14:43:06 +02:00
Pau Espin 12bc4afab3 Workaround bug where old hnb_context from same remote addr+port is kept
Under some circumstancies not yet fully known, which seems to
involve bad link quality and high latencies and some specific hNodeB
which reuse its local IP addr+port, it is seen that a 2nd SCTP
connection is created from the same HNB while locally we still keep the
old SCTP connection and its related hnb_context. Hence, when the hNodeB
tries to register again with this new conn, it is rejected all the time
by the HNBGW.

Related: SYS#6113
Change-Id: I33ae901cc37646eca90bf06953e44fcc25f4d6c6
2022-09-29 17:18:56 +02:00
Pau Espin 25cd41f3b5 hnbap: Improve logging around HNBAP HNB Register Request
Change-Id: I279ef563b38fb0dd3e6a72162db91d8503f91af8
2022-09-27 14:57:05 +02:00
Pau Espin 55239c2cca hnbap: Accept duplicated HNB Register Request on same conn
As per what's indicated in 3GPP TS 25.469 8.2.4 Abnormal Conditions:
"""
If the HNB-GW receives a duplicate HNB REGISTER REQUEST (i.e. for an already registered HNB identified by the
unique HNB identity), then the new HNB REGISTER REQUEST shall override the existing registration and the
handling of the new HNB REGISTER REQUEST is according to section 8.2.
"""

Related: SYS#6113
Change-Id: I0250350a14a87498a2c68cd0c726ee2f1e72419d
2022-09-27 14:45:07 +02:00
Pau Espin 3bf5395102 hnbgw: Fix recent regression not closing conn upon rx of SCTP_SHUTDOWN_EVENT
Before handling of OSMO_STREAM_SCTP_MSG_FLAGS_NOTIFICATION in recent
commit (see Fixes: below), osmo_stream_srv_recv() and
internal _sctp_recvmsg_wrapper() in libosmo-netif would return either
-EAGAIN or 0 when an sctp notification was received from the kernel.

After adding handling of OSMO_STREAM_SCTP_MSG_FLAGS_NOTIFICATION, the
code paths for "rc == -EAGAIN" and "rc == 0" would not be executed
anymore since the first branch takes preference in the if-else
tree. For "rc == -EAGAIN" it's fine because the new branch superseeds
what's done on the "rc == -EAGAIN" branch. However, for the "rc == 0",
we forgot to actually destroy the connection. The "rc == 0" branch was
basically reached when SCTP_SHUTDOWN_EVENT was received because
osmo_stream_srv_recv() tried to resemble the interface of regular
recv(); let's hence check for that explicitly and destroy the conn
object (and the related hnb context in the process) when we receive
that event.

Fixes: 1de2091515
Related: SYS#6113
Change-Id: I11b6af51a58dc250975a696b98d0c0c9ff3df9e0
2022-09-22 16:39:51 +02:00
Pau Espin 1de2091515 hnbgw: Unregister HNB if SCTP link is restarted
Sometimes an hNodeB may reconnect (SCTP INIT) using same SCTP tuple without
closing the previous conn. This is handled by the SCTP stack by means of
pushing a RESET notification up the stack to the sctp_recvmsg() user.
Let's handle this by marking the HNB as unregistered, since most
probably a HNB Register Req comes next as the upper layer state is
considered lost.

Depends: libosmo-netif.git Change-Id I0ee94846a15a23950b9d70eaaef1251267296bdd
Related: SYS#6113
Change-Id: Ib22881b1a34b1c3dd350912b3de8904917cf34ef
2022-09-19 14:58:11 +02:00
Pau Espin d046306b63 Change log level about conn becoming closed to NOTICE
Change-Id: I8973990e2cc435422e62dd2a38192e7a6da4a716
2022-09-16 10:37:00 +00:00
Pau Espin f9825cbd4a Improve logging around hnb_context and sctp conn lifecycle
Change-Id: I44c79d86924ead84246b3d4937a6becae5d29185
2022-09-14 12:16:38 +02:00
Pau Espin 930ed702b6 hnb_context_release(): Make sure assigned conn is freed
Otherwise, some paths calling hnb_context_release() (like failing to
transmit HNB-REGISTER-REJECT) would end up with a conn object alive with
no assigned hnb_context, which is something not wanted.

This way an alive conn object always has an associated hnb_context, and
they are only disassociated during synchronous release path.

Related: OS#5676
Change-Id: I44fea7ec74f14e0458861c92da4acf685ff695c1
2022-09-14 12:16:18 +02:00
Harald Welte 96c712570a Don't permit anything but HNB (de)registration until HNB is registered
UE registration or other HNBAP procedures should only happen once the
HNB is registered.

Change-Id: Iaa62ce89f4ffbff868309bfb8b1df7ebcca5c44a
2022-09-13 13:00:01 +02:00
Harald Welte fe7c34737d Don't process RUA messages if HNB is not registered
Related: OS#5676
Change-Id: I85442e8adfefadc3bf3ed795eaef7677eb0b36e9
2022-09-13 13:00:01 +02:00
Harald Welte d3382ae952 hnbgw_rx_hnb_deregister: Don't call hnb_context_release()
Don't release the HNB context as there's plenty of code that
assumes there's always a HNB context associated with a SCTP connection.

Instead, simply unset the hnb_registered flag in the context when
processing a HNB_DE-REGISTER.

Related: OS#5676

Change-Id: Id5c4f5c900ea049f54afbf58edb84b4dc00b1dcb
2022-09-13 12:59:57 +02:00
Harald Welte c971c657c5 Abort if processing SCTP connection without HNB context
It was observed that under some circumstances (after HNBAP
HNB-De-Register) we end up crashing because a connection has no HNB
assigned to it. Let's explicitly assert if that happens, in order
clarify and avoid same sort of thing happening without clear view on
what's going on.
The issue will be fixed in a follow-up patch.

Closes: OS#5676
Change-Id: I1eedab6f3ac974e942b02eaae41556f87dd8b6ba
2022-09-13 11:31:46 +02:00
Pau Espin eadf523393 hnbgw: Log new SCTP HNB connections
Change-Id: I07b98ff4c3199eeab11a8c1cfd9ce44ab99bca85
2022-09-13 11:31:46 +02:00
Pau Espin 419e832473 cosmetic: Fix typo in log and whitespace
Change-Id: Ie2be6937bb0f44ea66397c905c5d380caa2d4cef
2022-09-13 11:31:40 +02:00
Harald Welte d28771a1b5 cosmetic: Fix typos
it's "successful", not" "successfull".

Change-Id: Ic421ed6835a9ffca6af34779f0ea648bb12e2fe1
2022-09-12 08:15:58 +02:00
Neels Hofmeyr 9ea431123d fix regression: in RUA, do PFCP only when enabled
Tested in ttcn3, by test cases not ready for submission (would require
enabling/disabling PFCP while osmo-hnbgw is running).
ttcn3 tests in I511e758807e0512c18f3f9e0a8c4699b9a3f5992

Related: SYS#6093
Change-Id: I39b9632f8524a9f3455c1a2d7611bfe8ba07c2fd
2022-08-29 16:57:28 +02:00
Daniel Willmann d129e0c86e hnbgw_hnbap: Fix memory leaks in HNBAP handling
* Use osmo_stream closed_cb to call hnb_context_release() in all cases
* Also call hnbap_free_hnbregisterrequesties() when sending hnb register
  reject

Related: OS#5656
Change-Id: I3ba02b0939413c67bc8088ea1a8f2252fc2bda31
2022-08-23 18:15:02 +02:00
Daniel Willmann 2dfeb1e218 Install show talloc-context VTY commands
Related: OS#5656
Change-Id: Ia4b0023028405ce065f618f536c92ea2bcd0ce15
2022-08-23 17:51:51 +02:00
Neels Hofmeyr 941008e785 ps_rab_fsm: check use cb success
Related: CID#275413 CID#275410 CID#275409
Related: SYS#5895
Change-Id: Idcb3d6796326b059280b0e552eb36067ba15b3ac
2022-08-17 14:33:33 +00:00
Neels Hofmeyr ca2c5b9067 optimize: decode PS msgs only when PFCP is enabled
For the benefit of skipping decoding of all PS RANAP and RUA messages,
introduce code dup: decode CS and PS separately.

Related: SYS#5895
Change-Id: Ifb57bad6a0d5ff263e4c6c3facc51620e110e7d2
2022-08-17 14:33:33 +00:00
Neels Hofmeyr e6201765cf build: add --enable-pfcp, make PFCP dep optional
Related: SYS#5895
Change-Id: I6d50c60bccda767910217243bdfb4a6fad1e39c1
2022-08-09 17:57:43 +02:00
Neels Hofmeyr 44f5a336a8 reduce code dup in handle_cn_data_ind()
Change-Id: I4bca25d1643693cf3a9d3c49f35b29ff1dce0859
2022-08-08 20:20:34 +00:00
Neels Hofmeyr 1496498713 add ps_rab_ass FSM to map GTP via UPF
Related: SYS#5895
Depends: If80c35c6a942bf9593781b5a6bc28ba37323ce5e (libosmo-pfcp)
Change-Id: Ic9bc30f322c4c6c6e82462d1da50cb15b336c63a
2022-08-08 20:20:34 +00:00
Neels Hofmeyr 223aeda282 ranap_rab_ass_req_encode(): return msgb
ranap_rab_ass_req_encode() forms a msgb, then copies the data to a
buffer provided by the caller. Instead, just return the msgb. This
removes one unnecessary memcpy() and simplifies some code.

In ranap_rab_ass_test.c, actually ensure the correct size of the
returned data. See also the fix of expected test data in patch
Ifb98a52e56db1227a834c0d7b7a260314d9f547e

Related: SYS#5895
Change-Id: I85e715326e1d8f4f301f82f78da109f1a7a92f30
2022-07-27 15:45:18 +02:00
Neels Hofmeyr 05aaccc42d mgw_fsm: move MGCP timeout to mgw_fsm_T_defs
For the tdefs used by libosmo-mgcp-client, passed via
osmo_mgcpc_ep_alloc(), do not use the separate mgw_tdefs. Instead, move
X2427 to mgw_fsm_T_defs. This makes X2427 VTY configurable.

Related: SYS#5895
Change-Id: I2aa67121c20dc3da5fd937a02b6747468622f317
2022-07-27 15:44:51 +02:00
Pau Espin 7eb89ec9fe hnbgw_cn.c: Guard against null ss7 ptr during init
Fixes: Coverity CID#272989
Change-Id: Ic787d52a3c2e73ac272735a33b20bb94e29fad95
2022-06-29 18:50:30 +02:00
Pau Espin 62fb1dea61 mgw_fsm: Simplify cleanup paths
Let's have a unified way of freeing the FSM instance once it was
allocated, otherwise it's far more difficult to understand and maintain.

Change-Id: I8883e737fa112cff57834abae7ef272388a54edb
2022-06-15 11:55:21 +02:00
Pau Espin 304f7646c9 mgw_fsm: Fix error path accessing uninitialized fsm ptr
The error handling of the error path was wrong. Let's remove the "fi"
variable to avoid more of such errors. Furthermore, add an assert to
clarify for the reader that the map->mgw_fi will be freed before
allocating a new FSM instance below.

Change-Id: I9d3bca552bfa77f5e18f75bedad8d422f74df1f8
2022-06-14 18:41:48 +02:00
Pau Espin 87e03208af mgw_fsm: Change macro to not use local variables implicitly
This is misleading for readers since it may access variables which may
be uninitialized or in a wrong state. Furthermore, we want to pass some
other variable name in a follow up patch.

This effectively allows the compiler to warn about uninitialized used of
a fi var in line 661.

Change-Id: Id694f51bb2918fd27da87b3f4a905727cd7f5de6
2022-06-14 18:40:11 +02:00
Pau Espin de8b170d1a cosmetic: mgw_fsm: Fix typo in log
Change-Id: I80aa61a288ab37c51510af67c784498f5949fc50
2022-06-14 18:07:52 +02:00
Pau Espin 1d1839a34b mgw_fsm: Improve logging
Change-Id: I14785b6bc798c3bae8c552bccb55ca4fa9f2f416
2022-06-14 18:07:32 +02:00
Pau Espin 8c7aae87b0 mgw_fsm: Mark structs as static const
Change-Id: Ie62f28587c08296429c0dabda7b6add67ffa010c
2022-06-14 17:46:56 +02:00
Neels Hofmeyr ff2fbdf998 fix segfault in error handling for mgw_fi == NULL
In mgw_fsm_handle_rab_ass_resp(), a NULL mgw_fi is handled as error,
but the error handling fails to return. The function continues to
dereference mgw_fi. Add missing return.

Related: SYS#5995
Change-Id: I3e98dc3a00145ec1f71c678bbf45debfd4276237
2022-06-10 11:40:33 +02:00
Neels Hofmeyr 2c91bd66a1 add option to send SCCP CR without payload
It is reported that a third-party SGSN is rejecting SCCP CR when the
SCCP message part exceeds a certain length. The solution is to first
send an SCCP CR without payload, and send the payload in a DT later.

Add config option

  hnbgw
   sccp cr max-payload-len <0-999999>

If the RANAP payload surpasses the given length, osmo-hnbgw will first
send an SCCP CR without payload, cache the RANAP payload, and put that
in an SCCP DT once the SCCP CC is received.

The original idea was to limit the size of the entire SCCP part of the
message, but I'm currently not sure how to determine that without
copying much of the osmo_sccp code. I figured using a limit on the RANAP
payload is sufficient. To avoid the error with above third-party SGSN,
the easy solution is to set max-payload-len to 0, so that we always get
a separate SCCP CR without payload.

Related: SYS#5968
Related: I827e081eaacfb8e76684ed1560603e6c8f896c38 (osmo-ttcn3-hacks)
Change-Id: If0c5c0a76e5230bf22871f527dcb2dbdf34d7328
2022-06-07 22:51:26 +02:00
Neels Hofmeyr afbcae6366 tweak comments in rua_to_scu()
Change-Id: I227a5e6b869da453fa72ff0eebaa1e95aa9625e6
2022-06-07 22:51:25 +02:00
Neels Hofmeyr da9d08c94e allow calling rua_to_scu() without data
There can be SCCP primitives without payload data, e.g. an "empty" SCCP
Connection Request.

Patch 'mgw_fsm: add MGW support to osmo-hnbgw' added RANAP message
decoding that lacks a guard against NULL data. Fix that: do not try to
decode NULL data.

Related: SYS#5968
Change-Id: Id755e769e82ace7203460ea1b3c847c2c90d41bf
2022-06-07 22:50:37 +02:00
Neels Hofmeyr 0ca9567fb2 use osmo_select_main_ctx(), tweak log in handle_cn_conn_conf()
Upcoming patch adds to this function. Let me first combine those four
LOGP() to a single one, use proper osmo_sccp_addr_to_str_c(OTC_SELECT).

To be able to use OTC_SELECT, switch hnbgw.c to osmo_select_main_ctx().

Related: SYS#5968
Change-Id: I1e0ea0a883e8cf65e6cfb45ed9b6f3d8fb7c59eb
2022-06-07 18:09:19 +02:00
Philipp Maier be9ed71631 ranap_rab_ass: check for more than one RAB assignment req
The spec permits RAB AssignmentRequests with multiple RABs at a time.
Even though one voice call is assigned only one RAB in practice. Since
the current FSM implementation only supports a 1:1 scenario, lets check
if the MSC really assigns only one RAB and block RAB Assignments that do
not fit in this scheme.

Change-Id: I0f1d868fd0b4dc413533d6fcc5482862825181be
Related: OS#5152
2022-02-28 10:22:16 +01:00
Philipp Maier d1f4b9b9a1 mgw_fsm: release call when FSM is not created
While the FSM is created the RAB Assignment Requests is checked and
parsed. In case of failure the context is freed, but the CN is not
informed about the problem. The RAB AssignmentRequest will then most
likely time out. However, lets make sure the call is released by re
requesting an IU Release.

Change-Id: I1904f7e95d86bbcecee14f8721bd4075d0e33ab4
Related: OS#5152
2022-02-25 15:12:18 +01:00
Philipp Maier 81f1751896 mgw_fsm: add MGW support to osmo-hnbgw
osmo-hnbgw lacks support for an co-located media gateway. This makes it
virtually impossible to isolate the HNB from the core network properly.

Lets add MGCP support to osmo-hnbgw so that it can control a co-located
media gateway to relay the RTP streams between HNB and core network.

Change-Id: Ib9b62e0145184b91c56ce5d8870760bfa49cc5a4
Related: OS#5152
2022-02-24 10:51:30 +01:00
Philipp Maier f5742a3bed ranap_rab_ass: add function to check if RAB is in ReleaseList
A RANAP RAB-AssignmentRelease may contain a ReleaseList. In order to
detect that a RAB is about to be released we need to be able to check if
the RAB we are dealing with is contained in such a ReleaseList.

Change-Id: I5b67cc2d35d11de7a09e66c181a1fdd5a58c75bb
Related: OS#5152
2022-02-23 15:50:43 +01:00
Philipp Maier efe4850e75 ranap_rab_ass: add function to check if RAB is in FailureList
A RANAP RAB-AssignmentResponse may contain a FailedList. In order to
detect that a RAB Assignment failed at the HNB we need to be able to
check if the RAB we are dealing with is contained an such a FailedList.

Change-Id: I4319f7caa45ea758ccd792cc8570521df075cf45
Related: OS#5152
2022-02-23 15:38:17 +01:00
Philipp Maier 0c465b0f68 ranap_rab_ass: ensure specific rab_id
The parser functions currently ignore the rab_id. An exception is
ranap_rab_ass_req_ies_extract_inet_addr, which extracts the rab_id
of the first RAB. To make the handling of the RAB assignment parsing
more robust lets add a rab_id parameter to the other functions. This
parameter can then be used to ensure thet the correct RAB is handled.

Change-Id: I2259ffce9f4b508c555d60618c5983ac6294e0ae
Related: OS#5152
2022-02-11 11:00:35 +01:00
Philipp Maier 7daa502a2d ranap_rab_ass: add decoder and rewrite functions for RAB-AssignmentRequest/Response
The RANAP RAB AssignmentRequest and AssignmentResponse contains the
IP-Address and the IP-Port for the RTP voice stream. In the comming MGCP
implementation we will have to extract and replace this information.
Lets add functions that do that in a convinient way.

Change-Id: I58b542bf23ff5e1db2ccf6833fec91d9ba332837
Related: OS#5152
2022-02-02 10:51:38 +01:00
Philipp Maier dddafa60ea hbgw_hnbap: use osmo_plmn_from_bcd instead of gsm48_mcc_mnc_from_bcd
The function gsm48_mcc_mnc_from_bcd is deprecated. Lets use
osmo_plmn_from_bcd instead.

Change-Id: I01406a4cf86d4f3ed162c9df55880941e54d654e
2022-01-14 17:31:25 +01:00
Philipp Maier 60008b1457 hnbgw_cn.c: fix sourcecode formatting
Change-Id: I50ec3a4a5c2f65c85adc177f83123991f949e9cf
2022-01-12 16:59:45 +01:00
Pau Espin dce3870429 Initial structure + import code from osmo-iuh.git
Imported from osmo-iuh.git 9b4de3f401c890fc2c0dfae9e827daaaadd80db0.

Change-Id: I569d221aeb83d352c1621c44c013a0e4c82fc8a8
2022-01-04 19:48:52 +01:00