Commit Graph

247 Commits

Author SHA1 Message Date
Harald Welte a3c02651db context_map_{rua,sccp}: Re-order to always process KPIs
Prior to this patch we always decoded CS RANAP, but only decoded PS
RANAP in case PFCP support was enabled.  This meant that PS KPIs
were only counted when PFCP was enabled, too.

Let's move to a mode where we unconditionally decode RANAP and always
call the KPI module for updating the rate counters.

Change-Id: I6054b6efcc202ebd71cd6e135e49c279ba616a01
2024-03-27 18:22:10 +01:00
Neels Hofmeyr 5329c44e0e fix null deref on hnb_context_release
Usually, a hnb_context still has a hnb_persistent associated at release
time. But that is not guaranteed.

See also further below, where the function tests for ctx->persistent
correctly.

Change-Id: I77ddd627ebfe96c7674c6a197af8b2c4b1a4024c
2024-03-23 12:51:56 +01:00
Harald Welte 6917c9b2cd RAB activation/modification/release statistics
Add rate_ctr based statistics for RAB activation, deactivation and
failures.  This requires us to parse RANAP in both uplink and downlink
and to iterate deep into the setup/modify/release/failure lists.

Given the way how the protocol works, the only way to distinguish an
activation from a modification is because sender and recipient know
whether a given RAB is already active at the time of the message.  So we
also need to track the activation state of each RAB.

Depends: osmo-iuh.git Change-Id I328819c650fc6cefe735093a846277b4f03e6b29
Change-Id: I198fa37699e22380909764de6a0522ac79aa1d39
2024-03-18 13:50:36 +01:00
Harald Welte ffae71bc14 mgw_fsm: Add some OSMO_ASSERT() to ensure only CS maps passed
The mgw_fsm only supports CS RABs in the CS domain; let's add some
ASSERTs to make sure the impossible doesn't happen.

Change-Id: I264c4b3da17b6f59ebcdd02031318402a483041a
2024-03-13 12:11:01 +01:00
Harald Welte 5a2cf382ef cosmetic: align downlink RANAP unitdata function names with uplink
In uplink we use *ranap_rx_udt_ul*, so let's use the same naming
pattern for processing dowlink unit-data messages to make things more
consistent.  Also, make sure udt is always part of functions that only
handle unitdata - not to be confused with connection-oriented messages.

Change-Id: I1792e4c2cdce145ae906c181898163bcda36328d
2024-03-13 12:11:01 +01:00
Harald Welte ea15086584 stats: Add per-hnb paging:{cs,ps}:attempted counter
Adding counters for number of paging succeeded is much harder,
as we currently don't parse connection-oriented DL RANAP and/or any
L3 NAS in it.

Change-Id: I7648caa410dba8474d57121a8128579ba200b18f
2024-03-13 12:10:36 +01:00
Harald Welte 14c36591fc Introduce counter for per-hnb cumulative active CS RAB duration
This counter can be used to determine the traffic in Erlangs per HNB.

Change-Id: Iffb6a3f38239094551a12c872cd8474d02a5ad56
2024-03-13 12:04:20 +01:00
Harald Welte bceef626b5 vty: Print the uptime during 'show hnb' output
Change-Id: Ic414fe301b3fa5c357bd1cd8a7842b7d6333c709
2024-03-12 23:30:19 +00:00
Harald Welte 1cd9402663 don't forward paging requests to HNB's not yet registered
Change-Id: I22ddfea1c6e13e91acecaf731b446e2de0976892
2024-03-12 23:28:50 +00:00
Harald Welte cae5bf33e8 rename hnbgw_peek_l3 to hnbgw_peek_l3_ul as it's uplink only
Let's not make the functions appear more generic than they are: They
all explicitly only support uplink so far.

Change-Id: I7db0d933a8f17f8c410141f43dab12b8c19fc8ae
2024-03-12 23:28:50 +00:00
Harald Welte 51fb6b5578 cosmetic: Rename hnbgw_rx_ranap and friends to *_rx_ranap_udt_ul
Those functions have always been handling only unit-data in uplink
direction, so let's reflect that in the function name to prevent
anyone assuming they process connection-oriented RANAP and/or
the downlink direction.

Change-Id: I29e8176ac19b2e7390e5950b8d0944c8961e491f
2024-03-12 23:28:50 +00:00
Harald Welte 2b771919dc cosmetic: talk about cs_rab_ass_* when working in CS domain
There's RAB assignment for CS and PS, let's not name functions
too generic to avoid confusion.

Change-Id: Id49ef931e11958315d612d764bbc488ef43f4290
2024-03-12 20:47:59 +00:00
Harald Welte b43660685d cosmetic: Fix comment in mgw_fsm.c: One RAB per context_map, not hnb!
Change-Id: I0cecccd94ba9c1b14de083265a394a210b758b92
2024-03-12 20:47:55 +00:00
Harald Welte 31178cd2cb stats: Introduce basic counters for RANAP unit-data from CN links
Let's keep track of the various unit-data messages we receive from
CN-link peers: RESET, RESET-ACK, PAGING, UNKNOWN, UNSUPPORTED,
OVERLOAD_IND, ERROR_IND.

Change-Id: Ibe4c73b0288ea20ca3d54519b42bc7cb0e9e61b2
2024-03-12 20:47:50 +00:00
Harald Welte f43fbc9c40 stats: Introduce CNPOOL counter macro
Ever since the ancient days of OpenBSC, we've always had macros to
abbreviate the cumbersome 'rate_ctr_inc(rate_ctr_group_get_ctr(...))'
construct.  Somehow this was missed here.

Also, since 2018 (libosmocore.git 175a4ae93aaf1068b61041dca12962059d65ed55)
we have rate_ctr_inc2() to make it even simpler...

Change-Id: I5b9e6b2069eed533c472cea8483a370f7fcc8e74
2024-03-12 20:47:40 +00:00
Harald Welte e874946bfb stats: Introduce CNLINK counter macros
Ever since the ancient days of OpenBSC, we've always had macros to
abbreviate the cumbersome 'rate_ctr_inc(rate_ctr_group_get_ctr(...))'
construct.  Somehow this was missed here.

Also, since 2018 (libosmocore.git 175a4ae93aaf1068b61041dca12962059d65ed55)
we have rate_ctr_inc2() to make it even simpler...

Change-Id: I2754d7aa9d6c3e333bd729bc6e924c502b40cdad
2024-03-12 20:47:35 +00:00
Harald Welte 30691e7b90 Various new per-hnb RANAP and RUA counters
example output while running HNBGW_Tests.ttcn:

OsmoHNBGW# show rate-counters skip-zero
hNodeB 0 (001-01-L2-R3-S4-C1):
          iuh:established:         17 (0/s 4/m 0/h 0/d) Number of times Iuh link was established
        rua:ps:connect:ul:          3 (0/s 0/m 0/h 0/d) Received RUA Connect requests (PS Domain)
        rua:cs:connect:ul:          9 (0/s 4/m 0/h 0/d) Received RUA Connect requests (CS Domain)
     rua:cs:disconnect:ul:          1 (0/s 0/m 0/h 0/d) Received RUA Disconnect requests in uplink (CS Domain)
     rua:ps:disconnect:dl:          2 (0/s 0/m 0/h 0/d) Transmitted RUA Disconnect requests in downlink (PS Domain)
     rua:cs:disconnect:dl:          6 (0/s 3/m 0/h 0/d) Transmitted RUA Disconnect requests in downlink (CS Domain)
rua:ps:direct_transfer:ul:          1 (0/s 0/m 0/h 0/d) Received RUA DirectTransfer in uplink (PS Domain)
rua:cs:direct_transfer:ul:         10 (0/s 5/m 0/h 0/d) Received RUA DirectTransfer in uplink (CS Domain)
rua:ps:direct_transfer:dl:          2 (0/s 0/m 0/h 0/d) Transmitted RUA DirectTransfer in downlink (PS Domain)
rua:cs:direct_transfer:dl:         12 (0/s 6/m 0/h 0/d) Transmitted RUA DirectTransfer in downlink (CS Domain)

Related: SYS#6773
Change-Id: I61bd4f51ec88fd93d8640d39228ac85f5ac5b69b
2024-03-12 21:35:40 +01:00
Harald Welte e4d0951a86 New per-hnb rate_ctr and stat_item groups; track uptime
Let's add a per-hnb rate_ctr and stat_item group.  Only one initial
counter (number of Iuh establishments) and one initial stat_item
(uptime/downtime) is implemented.

Related: SYS#6773
Change-Id: I26d7c3657cdaf7c6ba5aa10a0677381ab099f8dd
2024-03-12 21:35:40 +01:00
Harald Welte 101a9c7e21 Set persistent->ctx pointer on HNB REGISTER REQ
The previous commit was missing the assignment of hnb_persistent->ctx
during successful HNB REGISTER REQ.

Related: SYS#6773
Fixes: Change-Id Ife89a7a206836bd89334d19d3cf8c92969dd74de
Change-Id: I18fe0e5aa968a1095c72e6bf32d08b031b342ac6
2024-03-12 21:35:39 +01:00
Harald Welte 7ec5cb7280 Introduce concept of per-HNB persistent data structure
This allows us to add a new "hnb-policy closed", which means we do not
accept any random HNB connection anymore, but only those whose identity
is pre-configured explicitly using administrative means.

Furthermore, this new data structure will allow us (in future patches)
to keep persistent data like uptime / downtime of each HNB.

Related: SYS#6773
Change-Id: Ife89a7a206836bd89334d19d3cf8c92969dd74de
2024-03-12 08:18:12 +00:00
Harald Welte fa4da8f980 Introduce umts_cell_id_from_str() as inverse of umts_cell_id_name()
We are about to introduce the stringified UMTS cell identifier to the
VTY, and for that we need to not only print but also parse the related
string.

Related: SYS#6773
Change-Id: I6da947d1f2316241e44e53bb6aaec4221cfaa2c0
2024-03-07 18:24:09 +01:00
Harald Welte 05605354ef osmo_hnbgw_main: Install our usual SIGUSR1/SIGUSR2/SIGABRT handlers
I just wanted to get a talloc report from osmo-hnbgw by sending SIGUSR1
and the process terminated.  Clearly not the desired behaviour...

Change-Id: I1209a2fadacf62afd5027480426285f527249788
2024-03-07 18:24:09 +01:00
Harald Welte 046ba3d27d umts_cell_id_name: Use 3-digit MCC and 2/3-digit MNC based on VTY config
Printing the PLMN 001-01 as "1-1" like the existing code is just weird,
and also doesn't differentiate between 2-digit and 3-digit MNC in the
output.

Change-Id: I015ad84a6f61b4420f6bfdaa60e8e1b53a71589c
2024-03-07 18:24:09 +01:00
Harald Welte e01a873cff [cosmetic] re-order hnbgw.c to group code in major blocks
Change-Id: Ia7ce60e6f80d10b7712de1aa6d8a30dd61690dcc
2024-03-07 18:24:08 +01:00
Harald Welte 1ee44400a4 Fix license headers: Should have been AGPLv3+, not GPLv2+
I'm not sure why so many files (particularly written by Philipp)
did contain a GPLv2+ header, instead of the AGPLv3+ which is the
actual overall project license.  I consider it a mistake.

In any case, any copyrightable contribution to those files was done by
sysmocom employees, so I as managing directory can legally make a
license change, whther or not it was a mistake early on or not.

Change-Id: I42ea544ae4e5c4d3bedad12ddb55cf3c26a30919
2024-02-17 10:28:41 +01:00
Neels Hofmeyr eba9cbf9d1 pfcp: implement sending Network Instance IEs
Allow configuring specific Network Instance names for the Core and
Access sides, to send to the UPF, to allow the UPF to pick the proper
network interface to create GTP tunnels on.

Add VTY cfg 'hnbgw' / 'pfcp' / 'netinst (access|core) NAME' to allow
configuring Network Interface values to send in PFCP. These are "dotted"
domain name strings, as in APN.

Add these Network Interface names to the PFCP messages' detection as
well as forwarding rules, each one indicating the side that it is
detecting on or forwarding to.

This helps lift osmo-hnbgw's PFCP support out of lab situations to a
proper production scenario, where the core and access networks are in
separate subnets, with osmo-hnbgw + UPF as the gateway.

For example, in osmo-hnbgw, configure

  hnbgw
   pfcp
    netinst access my-ran
    netinst core my-core

and in osmo-upf, configure

  netinst
   add my-ran 10.9.8.7
   add my-core 1.2.3.4

In effect, all GTP tunnel endpoints towards the Access side will be
bound on 10.9.8.7, and all GTP tunnel endpoints towards the Core side
will be bound on 1.2.3.4.

Related: SYS#5895
Change-Id: Ief53dbfacf1645c32a07847d590c4884d4c8ca56
2024-01-21 02:48:38 +01:00
Neels Hofmeyr 5fd2aa5dc4 pfcp: fix missing vty_write of pfcp local-port
Change-Id: I180e67b8abdd3c0d91b30f1e7668b02f1a323809
2024-01-21 02:29:45 +01:00
Neels Hofmeyr 4ec1c77f9c add tests/pfcp_cfg.vty.with_pfcp
So far, we had no pfcp.vty test, because PFCP support is built
conditionally, and the pfcp.vty test would always fail without PFCP
support.

Add a pfcp test for the VTY, conditionally: use suffix .vty.with_pfcp to
identify tests that need PFCP support, and run those only when
configured with --enable-pfcp.

Related: SYS#5895
Change-Id: Ibb1797bb43a18f26fc693e0c8920cfd1f5fb9ede
2024-01-21 02:29:31 +01:00
Neels Hofmeyr ec10455aed tweak vty doc: "UDP port"
Change-Id: I24e52143a8f3d0c9f92985f6bb0420b34926eb33
2024-01-20 08:34:54 +01:00
Neels Hofmeyr 6582c9a06c pfcp: fix modification of wrong FAR ID
Do not update the Core-facing Forwarding Action Rule with the Access
side's remote TEID, update the Access-facing FAR as we should.

This is a seemingly small but very grave bug in osmo-hnbgw's PFCP
implementation, and proof that no-one anywhere has tested osmo-hnbgw's
PFCP support properly yet.

Related: SYS#5895
Change-Id: I596f1785d280d7e53e0cef649d6bb5df01ebf648
2024-01-20 08:34:54 +01:00
Oliver Smith 1237ae48d1 debian: fix having no manuals in osmo-hnbgw-doc
Fixes: OS#6326
Change-Id: I8daeba6b267b2f7793a26a0e1fbc74ab17401cde
2024-01-19 14:40:49 +01:00
Oliver Smith 770d62f91b gitignore: add *.la, hnbgw_vty_reference.xml
Change-Id: I5c9ec6cf01d75b10a86098755064ad187de815c1
2024-01-19 14:40:42 +01:00
Harald Welte 67f9de4148 Display RANAP state during 'show cnlink'
This adds a line to the output showing DISCONNECTED or CONNNECTED
state for each cnlink during the 'show cnlink' VTY command.

Closes: SYS#6741
Change-Id: I6ab7d08fcd0631d31a12418f950c5901a93db43a
2024-01-15 13:56:38 +01:00
Neels Hofmeyr 406d95139b rua: move from ERROR to DEBUG log: stray RUA Disconnect
Related: SYS#6602
Change-Id: Ib55c254190f46f24981e4394d8d5cf017070118d
2024-01-05 05:12:03 +01:00
Neels Hofmeyr c17b2850b7 rua: validate correct RUA ctx state per RUA message type
It helps in a pretty complex situation seen in the field.
A third-party MSC releases SCCP in one fell swoop, not waiting for the
Iu Release Complete to come back from RAN as the specs would suggest.

The result is this odd sequence, where late rx of RUA Disconnect
actually causes a new SCCP connection to be established and torn down
again:

    RAN                 HNBGW                MSC
     |--active-RUA-ctx----|--active-sccp------|
     |                    |<--IU-Release-Cmd--|
     |<--IU-Release-Cmd---|                   |
     |                    |<--SCCP-RLSD-------| (too soon)
     |...<-RUA-Disconnect-|                   x (the consequence)
     |                    x
     |--RUA-Disconnect--->|                     (IU Release Complete)
     x              <create-new-ctx>
                          |-SCCP-CR---------->|
                          |-IU-Release-Compl->|
                          |<--CREF------------|
                          x                   x

This patch is a relatively simple practical improvement of above
situation that is logically obvious:

Validate the correct message type for creating a new RUA-to-SCCP
context: RUA Connect.

That means the IU Release Complete is ignored:

    RAN                 HNBGW                MSC
     |--active-RUA-ctx----|--active-sccp------|
     |                    |<--IU-Release-Cmd--|
     |<--IU-Release-Cmd---|                   |
     |                    |<--SCCP-RLSD-------| (too soon)
     |...<-RUA-Disconnect-|                   x (the consequence)
     |                    x
     |--RUA-Disconnect--->|                     (IU Release Complete)
     x                 <error>
                          x

Related: SYS#6602
Change-Id: Ie359fcada98fb19f56015cf462e6d8c039f5fce5
2023-12-12 02:02:08 +01:00
Pau Espin 5755268f9b mgw_fsm: Modify RAB on HNB if IuUP local IP addr at MGW changes during MDCX
Allow IP address renegotation between HNB and MGW:
* Upon MGCP MDCX ACK received from the RAN-side conn, if the IP address/port
  changes, then restart the RAB-Ass-Req+Resp procedure on Iuh.
* Upon RAB-Ass-Resp received from the HNB, if the IP address/port changes,
  then go through another MDCX + MDCX ACK prcoedure on MGCP.

An MDCX counter is introduced to avoid infinite loops where the HNB and
the MGW keep changing their IP address triggered by the change on the
other side, eg. due to incorrect network/routing setup.
The counter is also used to track count in order to make sure that
always at least 1 MDCX is transmitted, in order to change conn_mode to
SEND_RECV.

Related: OS#6127
Change-Id: I936a50fed38a201c4a8da99b40f07082049e5157
2023-12-04 13:13:49 +01:00
Pau Espin 656d1d2778 mgw_fsm: Assume IuUP HNB IP addr = Iuh during MGCP CRCX on RAN side
In general, the HNBs end up binding its IuUP/RTP streams to the same IP
address used for Iuh signalling.

When receiving a RAB-Ass-Req from CN, osmo-hnbgw creates an endpoint in
its co-located MGW and creates 2 MGCP conns on it, one facing the RAN
side and one facing the CN side. At that point, the remote CN IuUP IP address
is known (was include din the received RAB-Ass-Req), but the RAN one is
not yet known. Hence, the CRCX on the RAN-side conn contained no remote
IP address, which means MGW has to blindly guess a good local IP address
if "ip probing" is enabled.
As a result, when RAB-Ass-Resp comes back from the hNodeB containing the
allocated remote IuUP IP address and MGW is updated through MGCP MDCX,
it may happen that MGW rebinds to a better fitting local IP address and
returns it in MDCX. This has several downfalls:
1- We don't yet support updating the hNodeB about the changed IP address
(see mgw_fsm_mdcx_hnb). For that, we'd need to send a RAB-Modify-Req+Resp.
2- Even if we supported it, in the general case we'd be delaying call
establishment because an extra roundtrip is needed to update
RAB-Modify-Req+Resp.

In general, the HNBs end up binding its IuUP/RTP streams to the same IP
address used for the Iuh signalling. Hence, use this assumption to
announce the Iuh IP address as a remote IuUP IP address when
transmitting the MGCP CRCX at the RAN-side conn to the MGW. This way
the MGW can potentially select a proper local IuUP IP address from the
start, so no RAB-Modify-Req is required later on.

The logic to transmit RAB-Modify-Req is left unimplemented in this
commit and is left as a later improvement.

Related: SYS#6657
Change-Id: Icf43e3a1cde809d844f17ef2d0600efe64bc3dfe
2023-12-04 12:07:05 +00:00
Neels Hofmeyr 90928fb246 systemd,manual: set LimitNOFILE=65536
A typical OS imposed limit is 1024 open FD, which is too low when there
are thousands of HNB.

In systemd service file, set a super high limit of 65536.

In osmo-hnbgw's user manual, add section 'Configure limits' describing
this in detail.

Related: OS#6256
Related: osmo-bsc I26c4058484b11ff1d035a919bf88824c3af14e71
Change-Id: I5333765199cf9e3e5a570f85b85d2b7423d34a4d
2023-12-03 02:21:00 +00:00
Andreas Eversberg fadc67b8fb Use uniform log format for default config files
Related: OS#6272
Change-Id: I10bfc4150e10cac048f320641c040fa300f734c4
2023-12-01 11:53:41 +01:00
Pau Espin cd09569bc8 tests/ranap_rab_ass: Test RAB-Ass.req with X.213 IPv4 address len=7
It was found in the field that some peers sends an X.213 IP address
consisting of 7 bytes (1byte IDP/AFI, 2byte ICP, 4 byte IPv4 address) insetad
of 20 bytes. This was until recently failing in osmo-hnbgw due to
missing decoding functionalitit in osmo-iuh.git. Cover it here.

Related: SYS#6623
Depends: osmo-iuh.git I507fb1605d976bd8573162e4fa81721245330184
Change-Id: I71323018d79a4f5778dc6e49488d75ae7c2c4cdc
2023-11-27 14:51:13 +00:00
Neels Hofmeyr 3abd523faa allow (second) CS RAB Assignment Request without RTP info
In the field, we've encountered a so far unsupported scenario: after a
RAB Assignment Request and Response have successfully set up an RTP
stream, the CN sends *another* RAB Assignment Request to modify some SDU
parameters, omitting the transportLayerInformation IE (not modifying the
RTP address).

Directly forward all RAB Assignment Requests that have no RTP
information. This covers above use case, and also generally applies: no
RTP info means nothing to tell the MGW about.

Do not (yet?) support modifying the RTP address/port.

Related: osmo-ttcn3-hacks Iadaba0e5e82ad6d163ad509904ede213e2462d5c
Related: SYS#6624
Change-Id: I25bf19981cd75a87a7ceb3382dae1ec626ae475c
2023-11-07 04:34:35 +01:00
Neels Hofmeyr 81105a4d7a X31: fix vty doc
The actual scope is larger than just a stale release. Every RUA and SCCP
context map FSM state that has a timeout uses X31. (Seems I intended to
add more timers but forgot to follow up when I wrote it.)

Related: SYS#6602
Change-Id: I75a25f9065bc651e7ba8feda6db03c49a3b75c5e
2023-11-03 19:42:40 +00:00
Pau Espin 0e987d7f3c context_map_sccp: Fix assert hit due to missing ev handling
This was being triggered recently by
HNBGW_Tests.TC_ranap_cs_mo_disconnect in osmo-ttcn3-hacks.git.

Change-Id: Idaad11eaa3c2e56de792f80bab1f1d8435ef9b68
2023-11-02 12:09:06 +01:00
Pau Espin b64afa8631 Increase default X31 val from 5 to 15 seconds
It was spotted that in some deploys with satellite links and heavy load,
the roundtrip times for CR and CC can go slightly over 12 seconds, so
better increase the default value to 15 seconds to be on a safer place
and avoid operation problems with default configuration.

Related: SYS#6602, SYS#6616
Change-Id: I24225cfc0addf326c239ec658a27b93b83a3e751
2023-10-31 12:46:22 +01:00
Pau Espin 8514b73bff hnbgw_cn: Remove assert hit due to wrong assumption
The HNBGW in correctly assumes that no ss7->sccp instance is allocated
until the same function calls osmo_sccp_simple_client_on_ss7_id().
This assumption is wrong, since ss7 may create its own ss7->sccp
instance internally as a result of vty configuration, eg. when "sccp
max-optional-data 124" is placed in osmo-hnbgw.cfg file.

In this scenario, simply removing the assert is enough, since
osmo_sccp_simple_client_on_ss7_id() just calls osmo_ss7_ensure_sccp(),
the same that the libmoso-sccp code called to allocate the pointer.

Related: SYS#6566
Fixes: f3caea850b
Change-Id: I1221c165156e9625324cf0080836a8ed2bad4e9c
2023-09-19 12:36:38 +02:00
Pau Espin 92340d2131 Bump version: 1.4.0.109-89fe-dirty → 1.5.0
Change-Id: I7816b6554ce733207302c373d745b52146e0a995
2023-09-12 17:18:44 +02:00
Pau Espin 89fe80525b Tear down call if local IuUP MGW address changed during MDCX
Due to ip probing used at MGW and specific/complex routing in place
between RAN and CN, it may happen that, on the RAN-side endpoint connection,
the MGW first selects a local IP address.

Then, after the HNBGW signalling it to the HNB with the patched RabAssReq
and receiving the HNB local IP address through RabAssResp, then applying
it to MGW through MDCX, it can happen that the MDCX ACK contains a changed
local IP address at the MGW, due to IP probing after learning the remote
address.

This change is so far not announced to the HNB in anyway, ending up in the
HNB sending IuUP packets to the wrong IP/port, which is rejected with ICMP
due to osmo-mgw having no socket open there anymore.

We should at least, in osmo-hnbgw, if detecting the local MGW IP address
changed during MDCX, tear down the call setup. This patch does precisely
that.

Related: OS#6127
Change-Id: I32c4a7f838ceb5077bec7945e7976ce455d6b025
2023-08-01 19:21:38 +02:00
Philipp Maier 267a92a580 ranap_rab_ass: be sure to initialize memory with 0
When we use the ASN.1 decoder functions, we often reserve some memory on
the stack to store the results. (e.g. RANAP_RAB_xy_t _RANAP_RAB_xy;).
Then we assign the memory location to a pointer variable (e.g.
RANAP_RAB_xy = &_RANAP_RAB_xy). We do this for cosmetic reasons but we
may end up with an uninitialized buffer, which may cause trouble
lateron. Let's be consistent and make sure that those buffers are
initialized with zeros.

Change-Id: I7a8a951ccd8c9ae3923261468c0755192894a84b
2023-06-23 13:11:05 +00:00
Philipp Maier b77d944961 ranap_rab_ass: do not free never allocated FieldItems
When we check for an assignment failure in a RAB AssignmnetResponse, we
use decode_rab_flitms_from_resp_ies to search through the list of RAB
FailedItemsIEs for the RAB id we want to check. In case of failure, we
get a positive index back from this function. We then know that the RAB
that we checked for has failed bcause it was in the FailedItemsList.

In that case, we also must free the RAB FailedItemsIEs that
decode_rab_flitms_from_resp_ies has decoded. At the moment we also free
the RAB FailedItemsIEs also when decode_rab_flitms_from_resp_ies returns
with a negative return code, which may mean that the RAB was not found
or some other error occured. In this case we must not free since then
no valid RAB FailedItemsIEs are allocated.

Related: OS#6062
Change-Id: I755ba6599079810a048bf5b6d8947b5a9ffa622d
2023-06-23 13:11:05 +00:00
Neels Hofmeyr 067f1a0948 coverity: hnbgw_cn: avoid NULL deref in LOGP
Related: CID#321281
Change-Id: Icc2b45c8df8d92cfb42582615313d83389cf1621
2023-06-22 16:28:13 +02:00