It's similar to osmo_sock_get_name_buf() but supports multi-homed SCTP sockets
bound to several addresses.
Related: OS#5581
Change-Id: If76595ebd1cf26ba904887a36c4cc14a1b5c4521
The errno values are platform dependent. Printing them in the expected
output causes failure on some systems that don't match my development
system.
Still check for match with the expected errno value, but don't print the
actual value in gsm0408_test.ok.
Related: OS#4842
Change-Id: I87d125fb4e04b2130f653db1ed76691528e43411
This reverts commit e145e28a91.
Reason for revert:
The function osmo_sockaddr_strs_to_str() should not be part of the
osmo_sockaddr_str API. The implementation of this should live in
the function multiaddr_snprintf() added in patch
Icef53fe4b6e51563d97a1bc48001d67679b3b6e9
and should not use dynamic allocation.
Change-Id: I263dfd68313b896c5b474025fbca13c22ce41cdc
The decoding pointer was not increased correctly, ending up in reading
by 1 byte offset for each item in the list.
Change-Id: I16ed9bd65109a7ce32ff43c5789b4544479838e7
Some initial testing for that module was writen to apparently do some
manual tests (rand()) but were never added to testsuite.at.
Let's make sure they run during make check (make the test deterministic
by removing rand()).
Change-Id: Icd4feced06afb749de994195c6b338df006749ad
Coverity complains that we do check if osmo_tdef_get_entry() returns
NULL 39 out of 40 times. Check it in test_tdef_set_and_get() too.
Change-Id: I96041eab2786d850a49cb38a60a368cef2e476d3
Related: CID#274729
As was demonstrated in [1], osmo_fsm_inst_state_chg_ms() is broken.
The problem is in state_chg(): this function is passing *milli*seconds
to osmo_timer_schedule(), while it expects *micro*seconds.
Change-Id: Ib0b6c3bdb56e4279df9e5ba7db16841645c452aa
Related: [1] I5a35730a8448292b075aefafed897353678250f9
Fixes: I35b330e460e80bb67376c77e997e464439ac5397
Fixes: OS#5622
This change adds test_state_chg_Ts() and test_state_chg_Tms() checking
state timeout s/ms accuracy when using osmo_fsm_inst_state_chg() and
osmo_fsm_inst_state_chg_ms() calls, respectively.
test_state_chg_Tms() demonstrates that osmo_fsm_inst_state_chg_ms()
is not working as expected: the timeout fires earlier than expected.
Change-Id: I5a35730a8448292b075aefafed897353678250f9
Related: OS#5622
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
The new testcase contains a Bearer capability IE from Siemens S11E,
which does not use octet 3a (no extension bit set in octet 3).
gsm48_decode_bearer_cap() currently fails to parse it.
Change-Id: Ia19f3f6d80bc09ca3f8d39d35b148a0c0245141f
Currently, if one of the testcases fails, test_bearer_cap() would
abort and skip the remaining testcases. Also, a msgb would not
be free()ed making the LeakSanitizer unhappy.
Instead of returning early, jump to the end of loop to ensure that:
* the verdict ('passed' or 'failed') is always printed,
* all remaining testcases are still executed,
* the msgb is free()ed.
Change-Id: I39ac801e59ba56dfe3bcd4603b48f6fbf7cfb21c
osmo_bssap_le_dec() dereferences value of the given pointer and
checks it against NULL. The caller must always initialize it.
Change-Id: Id91dc73da1ca71827183564eb68b12c03ba332b3
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 new functions accept an additional mode_id poiner, which is
currently set for the following frames: AFS_ONSET, AHS_ONSET,
AHS_SID_FIRST_P2 with N * 16 - M bit pattern.
Also, the new API accepts soft-bits instead of hard-bits.
Converting bits from soft to hard is now performed internally.
Change-Id: Ibcac395f800bb64150c97fcdaca3523ecfc5fcee
Related: OS#5570
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
As was demonstrated in [1], there is a TCH/AHS specific problem in
libosmocoding causing unexpected BER ~50% in decoded AHS_SID_UPDATE
frames. The reason is that A[H]S_SID_UPDATE employs quite tricky
interleaving algorithm, which is different from the algorithm used
by normal TCH/AHS speech frames or A[F]S_SID_UPDATE frames.
An AHS_SID_UPDATE frame consists of two halves (228 bits each):
+---------+--------------------|---------+--------------------+
| in-band | SID marker | in-band | coded data |
+---------+--------------------|---------+--------------------+
| 16 bits | 212 bits | 16 bits | 212 bits |
The first half contains coded in-band signalling data (16 bits) and
the identification marker (212 bits), which allows to detect that
it's an AHS_SID_UPDATE. This half is carried by even bits of the
first two bursts and odd bits of the last two bursts.
The other half also contains the in-band data (16 bits), while the
remaining 212 bits contain encoded SID_UPDATE (212 bits). This
half is carried by even bits of the last two bursts and odd bits
of the first two bursts.
Current implementation does not use odd bits of the first two
bursts at all, so buffer cB[] in gsm0503_tch_ahs_decode_dtx()
contains only 114 out of 228 bits.
This patch changes the logic, so that gsm0503_tch_ahs_decode_dtx()
would not split AHS_SID_UPDATE onto two frames anymore like its
TCH/AFS equivalent does, but attempt to deinterleave the second
half and attempt to decode the payload immediately.
Change-Id: I8686d895e96fa0e606c1898b6574cc80a8f46983
Related: [1] I434157e2091a306c039123cea08d84bd8533c937
Related: SYS#5853
This patch adds a new test confirming that [1] actually fixes the bug.
Change-Id: I3d295a15d4446b3e440fbf4c90a1688d6c7275ae
Related: [1] I2e6f4b748c6445725211e264ab5f3f5a2712087a
Related: SYS#5853
This patch extends the existing unit test coverage for AMR's special
DTX frames. The new tests confirm that the problem with unexpected
BER in decoded AFS_SID_UPDATE frames has been actually fixed [1].
Additionally this patch demonstrates another TCH/AHS specific problem,
which negatively affects RxQual-SUB measurements in osmo-bts-trx: the
actual content of AHS_SID_UPDATE_CN is decoded with ~50% BER, because
the burst buffer contains only half of the burst bits.
Change-Id: I434157e2091a306c039123cea08d84bd8533c937
Related: [1] I813081a4c0865958eee2496fe251ae17235ac842
Related: SYS#5853
This unit tests shows how decoding of such message fails. Fix will be
provided in a follow up patch to make the test pass.
Related: SYS#5891
Change-Id: Ib4ff71d5e01d464febb062c5bfe3e06ee5a19ecd
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
We don't handle this correctly, as we decided to overload the
meaning of 0b1011 in a cell identifier list (defined by 3GPP
as used in SRVCC) with something osmocom proprietary.
Change-Id: I608220e8e5dd5a44f85c6bc5ea04622a2cad24ec
As was demonstrated in I54bf5e5c036efb1908232fe3d8e8e2989715fbb3,
when the logging is configured to print the filename *after* the
logging message, each logging line contains an artifact - '\0'.
The problem is that the 'len' variable is not updated. Fix this.
Change-Id: I5c920a0d5c1cf45bcdd327b39e33d63346b4f51c
Fixes: I393907b3c9e0cc1145e102328adad0a83ee13a9f
To easily log and print a sockaddr using OTC_SELECT, add
osmo_sockaddr_to_str_c().
Implement osmo_sockaddr_to_str_buf2() using osmo_strbuf, so that we can
return the chars_needed which osmo_sockaddr_to_str_c() uses.
From previous osmo_sockaddr_to_str_buf(), call
osmo_sockaddr_to_str_buf2() and return NULL if the buf_len was
insufficient, to mimick previous behavior. This makes it more
consistently returning NULL for insufficient buf_len, as shown in the
tweak that is needed in socket_test.c. Before osmo_sockaddr_to_str_buf()
would return a truncated port number, now it's all or NULL.
I will use osmo_sockaddr_to_str_c() in the new osmo-upf implementation.
Related: SYS#5599
Change-Id: I12771bf8a021e6785217b1faad03c09ec1cfef0e
This commit demonstrates a bug introduced in [1], which can be
observed when the logging is configured to print the filename
*after* the logging message (LOG_FILENAME_POS_HEADER_END):
logging print file 1 last
^^^^
In this mode, the code in _output_buf() overwrites the '\n' sybmol
contained in the logging message itself by shifting the 'offset'
backwards, and appends the nipped '\n' after the filename info.
The problem is that the 'len' variable is not updated in this case,
so the resulting length includes +1 character - '\0', which gets
printed at the end of every logging line.
Interestingly enough, this problem affects only the wqueue mode.
Change-Id: I54bf5e5c036efb1908232fe3d8e8e2989715fbb3
Related: [1] I393907b3c9e0cc1145e102328adad0a83ee13a9f
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
osmocom applications are deployed in a variety of different situations.
Dependung on the medium that interconnects the network components
unexpected behaviour may occur. To debug problems with the
interconnection between network components it might help to monitor the
health of the related TCP connections.
Change-Id: I1416f95aff2adcf13689646b7574845de169fa3d
Related: SYS#5701
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
The address sanitizer may print errors and warnings to stderr, and
this was actually the case for bitvec_test before [1]:
bitvec.c:492:24: runtime error: shift exponent 64 is too large
for 64-bit type 'long unsigned int'
Change-Id: Ia82b92eddb18dc596881abcef2f098dc7385538b
Related: [1] I4deeabba7ebb720cdbe7c85b37bc011d05bdfa65
While running a sanitized version of the bitvec_test I get:
bitvec.c:492:24: runtime error: shift exponent 64 is too large
for 64-bit type 'long unsigned int'
This error is triggered by the following line in the bitvec_test:
_bitvec_read_field(0, 8 * 8 + 1); /* too many bits */
which basically tries to parse more bits (65) than the test vector
actually has (64). The problem is that we don't check if the
given vector has enough data *before* entering the parsing loop,
so we end up doing weird bit-shifts and getting weird values:
bitvec_read_field(idx=0, len=65) => bd5b7ddffdd7b5db (error)
Unfortunately, this problem remained unnoticed so far because in
'tests/testsuite.at' we don't check if stderr is empty. This is
fixed in a follow up change [1].
Rather than checking for errors in every loop iteration, do this
once and return early if the overrun is possible with the given
offset and length arguments.
Change-Id: I4deeabba7ebb720cdbe7c85b37bc011d05bdfa65
Related: [1] Ia82b92eddb18dc596881abcef2f098dc7385538b
This function returns an *unsigned* integer (uint64_t), so returning
a negative value on error is a bad idea. A negative value turns into
a huge positive value, what was demonstrated in the bitvec_test:
bitvec_read_field(idx=512, len=16) => ffffffffffffffea
bitvec_read_field(idx=0, len=65) => ffffffffffffffea
bitvec_read_field(idx=64, len=16) => ffffffffffffffea
The 0xffffffffffffffea above is basically:
(uint64_t) -EINVAL, or
(uint64_t) -22 + 1, or
0xffffffffffffffff - 0x16 + 1.
Let's make use of the errno in order to indicate an error to the caller.
Change-Id: I2cc734caa3365d03c2ae2b3f2cd9544933c25e9e
Related: OS#4388
It's the usual naming for unit test binaries. Without the '_test' endig,
the tdef_vty_test_{config_root,config_subnode,dynamic} binaries do not
match the 'tests/*/*_test' pattern and appear as untracked files in git.
Change-Id: I828fa45132e11a41c527d4b25df850c19871cb75
Max
Neels Hofmeyr
Pau Espin
Oliver Smith
Vadim Yanitskiy
Harald Welte
Philipp Maier