We should not be doing the actual logic inside the assert statements.
Change-Id: I3bbf4e602c25c5aaced609e9834d6b053688194d
Fixes: CID#274664, CID#274679
Once the IuUP FSM moved away from Init state, it stopped handling
Initialization messages received from peers and simply ignored them
starting from that point. As a result, if the first IuUP Init ACK it
sent to the peer was lost, the peer would keep retrying with more IuUP
Init and getting no answer.
In any case, it seems possible and desirable that a peer may send an
IuUP Init at a later point, as pointed out vaguely in 3GPP TS 25.415.
sec 6.5.2.1:
"""
Upon reception of a frame indicating that an Initialisation procedure is
active in the peer Iu UP entity, the Iu UP protocol layer forwards the whole
protocol information contained in the INITIALISATION control frame to the
upper layers. It also stores the RAB sub-Flow Combination set (and thus
replaces a possible previous set) in order to control during the transfer of
user data, that the Iu UP payload is correctly formatted (e.g. RFCI matches
the expected Iu UP frame payload total length). The peer Iu UP entity
receiving the INITIALISATION control frame shall choose a version that it
supports among the proposed versions indicated by the sender for which it
has enough initialisation information.
"""
sec B.2.2 "Initialisation State":
"""
After sending a positive acknowledgement of the last INITIALISATION control
frame, the Iu UP instance enters SMpSDU data transfer ready state. Note that
CN does not know if the initialisation ACK was correctly received by the RNC
(and Initialisation procedure successfully completed) until it receives RAB
assignment response, or use data from the RNC. The CN must therefore be able
to continue receiving INITIALISATION control frames by re-entering the
Initialisation state (from Support Mode Data Transfer Ready State), if the CN
has started to send user data before receiving the indication that
Initialisation was successfully completed
"""
sec B.2.3 "Support Mode Data Transfer Ready State":
"""
In case of handover or relocation, Initialisation procedures may have to be
performed and Iu UP instance may have to enter the initialisation state.
"""
Related: SYS#5995
Change-Id: I5cb740702805693cc7f0a550e2e093f9bfdd507c
This test shows a bug in IuUP stack which makes it only handle the first
Initialization IuUP message. After it moves to SMpSDU, it stops handling
Initialization messages.
A fix is provided in a follow up patch.
Related: SYS#5995
Change-Id: I72c2c2d88f158f3ef35724fcb73854a1827aaab4
The initially merged IuUP API and implementation assumed that RFCI with
ID was always in the position of its ID inside the list of RFCIs. This
was the case for messages sent by ip.access nano3g as well as our own
osmocom implementation. However it was noticed that other nodes from
other vendors actually use other order, as allowed by the IuUP message
format.
Hence, we need to break the assumption and provide explicit ID
information in the list.
NOTICE: This commit breaks API and ABI compatibility with older versions
of libosmogsm, but not with any previous release of libosmocore since
the API is only available in master so far (it was added in
9fe1f9fb0b).
Similary, it's only user (osmo-mgw) only uses the API in master, so
there's no API breakage with older releases.
Related: SYS#5969
Change-Id: Ib21cee2e30bf83dff4e167f79541796007af9845
This allows init-passive users to get the configured sizes for the RFCIs
and other similar information once engotiated with the peer.
Realted: OS#1937
Change-Id: I63ee780b4aa162ea097410b234e73984000c0965
Only support for SMpSDU mode is introduced in this commit.
Not supported explicit list:
- Transparent mode
- ATM/AAL2 based Transport layer
- GTP-U based Transport Layer
- Iu Rate Control procedure
- Time Alignment procedure
APIs are provided to allocate the primitives properly inside the related
msgb. This way primitives can be placed in the headroom, leaving the
data part of the msgb for the IuUP payload, hence allowing re-use of the
msgb and 0 copy of IuUP payload when forwarding data over RNL<->TNL.
Since RNL and TNL primitives relu struct osmo_prim_header, which is not
packed, they cannot be set to packed, and hence proper memory alignment
in the msgb must be done to avoid misaligned accesses (Asan errors about
it otherwise).
Related: SYS#5516
Change-Id: Ibe356fa7b1abaca0091e368db8478e79c09c6cb0
Vadim Yanitskiy
Pau Espin
Harald Welte