This fixes bug in use of M3UA/SCCP after 2**24 connection IDs have been
allocated.
Related: SYS#6211
Change-Id: I03bad960f65fbff6e467def5bba60fefb328f962
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
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
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
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
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
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
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
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
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
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
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
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
* 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
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
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
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
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
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
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
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
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
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
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
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
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