The weird formatting not only makes it hard to read but caused linter to fail in the follow-up patch.
Change-Id: Ie4e56b4796c1b8f270a692453faccf102c963db5
gsm0808_create_lcls_conn_ctrl() was adding the LCLS-Configuration IE twice.
Correct is LCLS-Configuration followed by LCLS-Connection-Status-Control
(TS 48.008 3.2.1.91)
Change-Id: I455ac7695ad33ef9073bea7d1711508717732607
This is similar to what we already do between BSC<->MSC to pass Osmux
CID (GSM0808_IE_OSMO_OSMUX_CID).
We now want to support Osmux between BSC and Osmocom BTS, hence add an
extension IE which will be used in ipaccess CRCX messages to tell the
BTS to use Osmux.
Change-Id: I580fe99c01bc0a844d877994ec6cd954310e265d
This feature is used by the BTS to signal to the BSC that it supports
using Osmux instead of RTP on the BTS<->BSC(MGW) data plane.
Related: SYS#5987
Change-Id: Ie79bfb6d0a7a8fe2842d2596b3244e7b74a0d5b6
The decoding pointer was not increased correctly, ending up in reading
by 1 byte offset for each item in the list.
Change-Id: I16ed9bd65109a7ce32ff43c5789b4544479838e7
The testcase in gsm0408_test is still failing because the encoder
produces a different result (with octet 3a present). There is no
way to tell the encoder to use the implicit coding, and in general
this is not that critical, so we can live with that.
Change-Id: I722c168f01bffa915cb155eac234a796549d3762
That code path should not happen since this function is only called for
data frames coming with IUUP_FSM_EVT_IUUP_DATA_IND.
Control frames should come with specific events like
IUUP_FSM_EVT_IUUP_CONFIG_REQ.
Hence, let's add an assert to make sure we early exit if that ever
happens (it shouldn't), instead of carrying on reading uninitialized var
"dt".
Fixes: Coverity CID#272996
Change-Id: Iaeba59bc9ebfe817dbb7528572dc669c010ef14d
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
Those events are not realy used there and they are not even present in
the FSM definition. Let's drop them.
Change-Id: I4beec96ac4bdf047ebf144a8b009b297b47cacdc
The event is expected since the user of the IuUP stack can send a
CONFIGURE.req to transition to state null. The handling was already
there in the function, but the bit was missing in the FSM definition.
Change-Id: I830835a5b8b98f8b91b866f5280f508098c9ae7e
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
It was recently found that several IEs which were added in the header
file were not actually added to the tlv_definition, and hence the tlv
parser failed to decode them. Let's make sure we don't foget to add new
IEs in the future.
Related: SYS#5915
Change-Id: Id8a679ca43eb0fcc4882780e9a95ec21c7f51972
Those are available in 3GPP TS 48.008 version 16.0.0 Release 16, section
3.2.2.17 Cell Identifier. It can be seen that we have a collision
between the osmocom non-standard format and the SAI standard one.
This is because CGI-PS is not really a TS 48.008 Cell Identifier, but only
specified in TS 48.018 and has no ID number assigned. The CGI-PS was
added there because the whole osmo-bsc neighbour configuration works
with CellIds to manage neighbours, so it felt natural to extend the APIs
to also provide means to use CGI-PS format (TS 48.018 even refers 48.008
existance and mentions there's no explicit ID).
At the time this Cell Identifier was added, the firstly available number
(11) was taken, which was of course a really bad idea since newer
versions of the spec can at some point use it, which is the case if one
checks for instance TS 48.008 Release 16 SAI Cell Id.
There no perfect way to fix this bad decision at the time, but the
CGI-PS is only used in osmo-bsc and only for RIM related purposes, so by
changing the ID of CELL_IDENT_WHOLE_GLOBAL_PS, we only break RIM under
some specific CIs being used, and when an osmo-bsc is built against
older libosmocore and then used at runtime against a newer libosmocore
(which should be rare).
Hence, the downside is acceptable, and by moving the new ID number to be
ouside of the spec proto TS 48.008 range (4 bits), we make sure we don't
have the same problem again in the future.
Related: SYS#5838
Fixes: ca33a71ca8
Change-Id: Id25e563febdb7640174540136225f399515a0089
In general, it's safe not to use talloc API here because those are
internal allocations, and there are no 'return' statements between
calloc() and free(). However, we don't really need to initialize
the heap memory with 0, so let's use the 'normal' malloc().
Change-Id: I6956cbd83b2999dbcf8e2d210134b0a166c33efb
The event names contain '.', and there are spaces ' ' in the state
names. This is a problem since states and events can also be monitored
via the CTRL interface. Unfortunately the CTRL interface does not allow
certain reserved characters. So lets rename the states and event names
to make them compatible with the CTRL interface.
Change-Id: Id19973b56f9d7b1e3d0b0d7c7d0be7beba5428fc
Related OS#4149
Change-Id: I5ebc9ab5b1456fee29aa4e254fae862dc053f0aa
The parameters described in the docstrings for osmo_plmn_from_bcd() do not match the actual parameter list.
Change-Id: Ic0999dbe096a98418db7482bd110e20497d8e4a5
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
The use of an unsinged integer as for loop counter variable doesn't
work when counting down and comparing with >= 0. The existing code
would be an infinite loop if it wasn't for the (data dependent) break
condition:
>>> CID 243259: Control flow issues (NO_EFFECT)
>>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "i >= 0U".
572 for (i = 15; i >= 0; i--) {
573 if (match_mask & (1<<i)) {
574 iui->mode_version = i;
575 break;
576 }
Change-Id: I019d0f0d8f2b167575a2883a13cca692c96961cf
Closes: CID#243259
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
Remove the paragraph about writing to the Free Software Foundation's
mailing address. The FSF has changed addresses in the past, and may do
so again. In 2021 this is not useful, let's rather have a bit less
boilerplate at the start of source files.
Change-Id: I5050285e75cf120407a1d883e99b3c4bcae8ffd7
Replace some with atoi(), where the VTY has already validated correct
range of the argument.
Replace others with the new osmo_str_to_int() or osmo_str_to_int64()
functions, possibly covering more detection of invalid number strings.
Leave those strtol() callers that depend on endptr to provide the next
string token.
Related: SYS#5542
Change-Id: I0ebb06e751c28f7d1cdf328de29cd227a2449391
20 bytes is not enough for some VAMOS specific channel number values,
so the resulting string representation gets truncated by snprintf():
expected: "VAMOS TCH/H(0) on TS4\0"
actual: "VAMOS TCH/H(0) on T\0"
Let's enlarge the buffers to 32 bytes.
Change-Id: I68d839f4ab742cf56de34e7e22572a1163aec2da
This commit adds new Osmocom specific IEs required to pass C/I related
Power Control Parameters osmo-bsc => osmo-bts to be used by the MS Power
Control Loop being implemented.
Related: SYS#4917
Change-Id: Iffef0611430ad6c90606149c398d80158633bbca
To indicate to the BSC that a BTS supports temporary overpower of
SACCH/FACCH channels a new feature BTS_FEAT_ACCH_TOP is added.
Change-Id: I62fbfc30acd5d67b20727b75a8f256e6b5d31e06
Related: SYS#5319
To transfer the temporary overpower value from the BSC to the BTS, a new
RSL IE (RSL_IE_OSMO_TOP_ACCH_CAP) is added.
Change-Id: I31c5be4bceb9140d63ab8e2f197f0acc68699426
Related: SYS#5319
After my system's gcc was upgraded, I get false positivies in a couple
places. Let's initialize those to make gcc happy.
"""
/git/libosmocore/src/socket.c: In function ‘osmo_sock_init’:
/git/libosmocore/src/socket.c:958:25: error: ‘sfd’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
958 | close(sfd);
| ^~~~~~~~~~
/git/libosmocore/src/gsm/gsm48.c: In function ‘osmo_mobile_identity_decode’:
/git/libosmocore/src/gsm/gsm48.c:690:20: error: ‘str_size’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
690 | if (rc < 1 || rc >= str_size) {
| ~~~~~~~^~~~~~~~~~~~~~~~~
/git/libosmocore/src/gsm/gsm48.c:679:22: error: ‘str’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
679 | rc = osmo_bcd2str(str, str_size, mi_data, 1, 1 + nibbles_len, allow_hex);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"""
Change-Id: I8aacfbc21e23f63a65e8baee3fd536a1fe1bdd8a
Vadim Yanitskiy
Max
Keith Whyte
Pau Espin
Oliver Smith
Neels Hofmeyr
Philipp Maier
Harald Welte