Commit Graph

93 Commits

Author SHA1 Message Date
Neels Hofmeyr c62b45d589 on HNB Register, discard old HNB with same id, allow new connection
Change-Id: I6b04398296fdd9657a733984f28c2ef4188861ab
2023-02-11 03:12:50 +01:00
Pau Espin a3c7f750a2 Bump version: → 1.4.0
Change-Id: I0e45a9ba7437f800da6115da135cc80fb9e97bfe
2023-02-07 18:05:47 +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

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

 e62af4d46a is the first bad commit
 Author: Pau Espin Pedrol <>
    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:
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

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 0e03070789 doc: Include mgwpool.adoc from osmo-gsm-manuals
This way we document the recently gained support for MGW pooling.

Related: SYS#5987
Depends: osmo-gsm-manuals.git Change-Id Ieda0d4bfe6fc90da6e19c791d8ec2da89427ba3b
Change-Id: I3dc8a4b50f13ad50390ba82e64fe4ebe0b97d4e5
2022-10-20 17:15:16 +02: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 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
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

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
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.

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
Neels Hofmeyr 6bcd615d10 do not depend on libosmo-gtlv
Depending on libosmo-pfcp implies libosmo-gtlv, no need to explicitly
add this dependency.

Change-Id: I39eb59520231bcfed724060d3fda4ba919f2199d
2022-09-14 13:27:27 +02: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
Max 0c5878fa9d Set working directory in systemd service file
By default systemd will execute service with root directory (or home directory for user instance) which might result in
attempts to create files in unexpected place. Let's set it to 'osmocom' subdir of state directory (/var/lib for system instance) instead.

Related: OS#4821
Change-Id: I3133dc7a687550901841755461db6020ee96d6b1
2022-08-30 19:48:37 +07: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
Neels Hofmeyr b08b19c990 debian,RPM: package with PFCP support
- depend on libosmo-pfcp
- configure --enable-pfcp

Related: SYS#5895
Change-Id: I54dfe600d45541fecbb4c05bf75f147934c230f0
2022-08-27 16:02:51 +00:00
Harald Welte 791babf40e packate the new osmo-hnbgw-pfcp.cfg example config file
In I62c4935bcc7f684bfe850f88f1b80e8970e0e098 we added a new example
config file, but didn't actually package it in dpkg or rpm packages
yet.  This also lead to package build failures like:

[   39s] RPM build errors:
[   39s]     Installed (but unpackaged) file(s) found:
[   39s]    /usr/share/doc/osmo-hnbgw/examples/osmo-hnbgw/osmo-hnbgw-pfcp.cfg

Change-Id: I7c5c346f67f003b2cc5d74e812441c3704b133ef
2022-08-26 11:53:33 +00: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

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
Oliver Smith 0a5e2b3643 rpm spec: add osmo-hnbgw-pfcp.cfg
Fix for:
  Installed (but unpackaged) file(s) found:

Related: OS#5654
Change-Id: Ia05323a627719a7fff7c232aa3e5cc8766f9a8e1
2022-08-22 12:04:11 +02:00
Neels Hofmeyr 9f654da0aa example cfg: tweak logging
Change-Id: Idaf75d64d28264a29b67439c6bbcae8ad6981f7e
2022-08-18 16:17:53 +02:00
Neels Hofmeyr f7df74fc48 manual: explain the PFCP port
Change-Id: I383befb226caa49e4a2577657806aef1ee11faa3
2022-08-18 16:17:53 +02:00
Neels Hofmeyr a0d528ef31 manual: update IuCS/IuPS protocol stack chart
We use SCCP/M3UA now, not SUA.

Change-Id: I4496a6ffdda511875208bebbe68dbc9e69541fc0
2022-08-18 16:17:53 +02:00
Neels Hofmeyr d8de11b430 manual: update overview chart with PFCP
Change from ascii art to the dotty chart, taken from the
wiki. No need to keep a separate representation here.

Change-Id: Ifd8843aeb8ff28fec53323c8fb37b10d4d1f2f9b
2022-08-18 16:17:53 +02:00
Neels Hofmeyr 598ebb6943 manual: add missing bit on the MGCP port
Change-Id: Ic18180793f0c1497b020e5f4a8cd34d6b519b85f
2022-08-18 16:15:36 +02:00
Neels Hofmeyr 1ce5148996 add example osmo-hnbgw-pfcp.cfg
Change-Id: I62c4935bcc7f684bfe850f88f1b80e8970e0e098
2022-08-18 16:15:36 +02:00