To ease linking C tests, introduce a libhnbgw.la that contains all of
osmo-hnbgw except the main() and friends.
(I wrote a test that I was going to add, but it turned out to be
obsolete -- now at least we may keep this preparation to add C tests
more easily.)
Change-Id: Id2a706a30fb459005c676bb29c196cf3a582fa01
Conform to recent osmocom practice by having an osmo_hnbgw_main.c file
for main() and its immediate infrastructure.
Prepares for adding a non-installed libhnbgw.la -- which must not
contain a main() function -- so that linking regression tests is easy.
Separating to a new file seems appropriate because hnbgw.c has gathered
a bunch of stuff that is not strictly main() related / might be useful
to access in a C test.
Change-Id: I5f26a6b68f0d380617d73371f40f3b9055cac362
So far we jump through hoops everywhere to pass around osmo-hnbgw's
global singleton state to all code paths. Some files choose to spawn a
static "global" pointer. And we also have the talloc root tall_hnb_ctx.
Simplify:
- Have a single global g_hnbgw pointer. Drop all function args and
backpointers to the global state.
- Use that global g_hnbgw as talloc root context, instead of passing a
separate tall_hnb_ctx around.
(Cosmetic preparation for separate osmo_hnbgw_main.c file)
Change-Id: I3d54a5bb30c16a990c6def2a0ed207f60a95ef5d
It's really just a bloated llist_count() wrapper.
(Cosmetic preparation for separate osmo_hnbgw_main.c file)
Change-Id: Icd4100ddeb98f4dc2e2ec6de2d44a4b861a66078
This fix is really weird: by *removing* a FREE() call, fix a leak of the
replaced transportLayerAddress. (An in-code comment says some more.)
Also remove the other FREE() call that turns out to not be necessary.
This has been verified with a ttcn3 test that is not yet submitted,
which ensures an empty talloc_asn1_ctx at the end of every test
(osmo-ttcn3-hacks I2948ee6f167369a2252f85b493e9653b93c7e4e9 ).
Change-Id: I315d04a07b7dfd4dce26e5b5f871318e27e2bdf6
Include talloc_asn1_context in 'show talloc-context application'. It
belongs there IMO.
Related: SYS#6297
Change-Id: Iffc320c64713b225b57211da4fb95a868bf1f369
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
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
This option should be used for any executables which are used only
for testing, or for generating other files and are consequently never
installed. By specifying this option, we are telling Libtool that
the executable it links will only ever be executed from where it is
built in the build tree. Libtool is usually able to considerably
speed up the link process for such executables.
Change-Id: Id5f88c331cf1dfd3f38120b4ef59ced9a563d4f0
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
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
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
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
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
Add braces around context part.
In the HNBGW_Tests.ttcn output, I see this:
DRUA DEBUG TTCN3 HNodeB transmitting RUA DirectTransfer
which reads like the hNodeB would transmit a RUA to us. Instead, this is
us sending RUA to the hNodeB, which is much clearer like this:
DRUA DEBUG (TTCN3 HNodeB) transmitting RUA DirectTransfer
This matches the way we typically show context info in osmo logging.
Change-Id: If6f0c3ae81c737b7488fa93c435179dcf27a5c94
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
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
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
Planning new connection-oriented RUA and SCCP FSMs to
- conquer confusion about hnbgw_context_map release behavior, and
- eradicate SCCP connection leaks.
Related: SYS#6297
Change-Id: I661bf65d79972a732c52732934095e8bfcd99694
Change the order in the struct definition so that the items for RUA and
for SCCP are grouped together. Tweak comments.
Change-Id: I84424617996d8e1a6814aa122e63454c0666b724
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
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
Oliver Smith
Neels Hofmeyr
Vadim Yanitskiy
Philipp Maier