| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
Change-Id: Icaec95a9c6105fd17bc1151fdc77394f4efd3b70
|
|
|
|
|
|
|
|
| |
This way it's easier by osmo_verify_transcript_vty.py to skip and avoid
breaking existent test in osmo-hlr.
Fixes: d0b3b9edac978c91bf84aa2537aa24426685b1fb
Change-Id: Iab9423661e4f4eefca2e3d02b60a43f913ed92a3
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The intention of osmo_tdef_get()'s val_if_not_present argument was to return a
default timeout, or to optionally abort the program for missing timer
definitions if the default timeout is < 0. This was the case in the original
implementation of this API in osmo-bsc, but in the migration to libosmocore,
the argument was by accident changed to an unsigned type. In consequence, the
assertion in the implementation that was intended to abort the program seemed
bogus to coverity, and was fixed by removal in
I7a544d2d43b83135def296674f777e48fe5fd80a -- the wrong direction, as is obvious
from the API doc for osmo_tdef_get().
Note that osmo-bsc master passes -1 in various places and expects the
program-abort behavior that was missing from the libosmocore implementation.
Change the val_if_not_present argument to a signed type, and revert removal of
the assertion, so that passing -1 has the effect described in the API doc:
program abort on missing timer definition.
This bug was not detected because it is hard to write tests that expect a
program abort to happen, hence no tests for this API feature exist.
Related: OS#4152
Change-Id: Ie61c3c85069916336e6dbd91a2c16f7634816417
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When reading SUT logs resulting from TTCN3 runs, it can be hard to figure out
which log section corresponds to which test code. Add a 'logp' command on VIEW
and ENABLE nodes that simply echos an arbitrary message on log output, useful
to set markers / explanations from the TTCN3 code, which then appear in all log
outputs and can make it trivial to figure out which log section is interesting.
logging_vty_test# logp lglobal notice This is the log message
DLGLOBAL NOTICE This is the log message
From TTCN3, could be used like this, e.g. in BSC_Tests.ttcn:
private function f_logp(charstring log_msg) runs on MSC_ConnHdlr
{
// log on TTCN3 log output
log(log_msg);
// log in stderr log
f_vty_transceive(BSCVTY, "logp lglobal notice " & log_msg);
}
...
f_logp("f_probe_for_handover(" & log_label & "): Ending the test: Handover Failure stops the procedure.");
Change-Id: Ife5dc8999174c74e0d133729284fe526d6eaf8d9
|
|
|
|
| |
Change-Id: I64c6d3dc08ff87b673ba6225f98546e86f91bcfd
|
|
|
|
|
|
|
| |
openbsc's directory structure is a bit different (has most stuff inside
an extra subdir). Let's account for that.
Change-Id: I407cf47d8339d99c74a976460ea84fffe679dfd8
|
|
|
|
| |
Change-Id: I614080361f3cc5bfb89994a8e8e36981529cd439
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and debian/control
Sample output for current osmo-msc master:
Releasing 1.3.1.191-7ea0d -> 1.4.0...
ERROR: configure.ac <libosmocore, 1.0.0> does NOT match debian/control <libosmocore, 0.10.0>!
ERROR: configure.ac <libosmo-netif, 0.4.0> does NOT match debian/control <libosmo-netif, 0.1.0>!
ERROR: configure.ac <libosmo-sigtran, 1.0.0> does NOT match debian/control <libosmo-sigtran, 0.8.0>!
ERROR: configure.ac <libosmo-mgcp-client, 1.5.0> does NOT match debian/control <libosmo-mgcp-client, 1.1.0>!
ERROR: configure.ac <libosmo-gsup-client, 1.0.0> does NOT match debian/control <libosmo-gsup-client, 0.2.1>!
ERROR: configure.ac <libsmpp34, 1.13.0> does NOT match debian/control <libsmpp34, 1.12>!
ERROR: configure.ac <libasn1c, 0.9.30> does NOT match debian/control <libasn1c, 0.9.28>!
ERROR: configure.ac <libosmo-ranap, 0.3.0> does NOT match debian/control <libosmo-ranap, 0.2.0>!
ERROR: exiting due to previous errors
make: *** [osmo-release.mk:9: release] Error 1
Change-Id: I702a82c1b0e21dbe71a334a6f8bc62efe07859a6
|
|
|
|
| |
Change-Id: Ib929bfac3689f35aaa58d7d079a46fff188b7e8e
|
|
|
|
|
|
|
|
|
|
| |
This option allows testing if everything is in place before attempting
release related actions such as commiting, applying tag, etc.
It's also useful during development of the osmo-release.sh release
itself, sine it makes test iterations faster (no need to undo actions
done).
Change-Id: Ie5c320b7c92f92fcc37287bb9801368265a986b3
|
|
|
|
| |
Change-Id: I05dd1f2725e05f856f1d27c9201a0005de101b8f
|
|
|
|
|
|
|
|
|
|
| |
As a result whitespace ended up in some variables and then command
"expr" was not happy about it.
It was spotted because src/coding/Makefile.am had some whitespacing.
Since it's the only one, let's drop the whitespace there too to have
similar line in all Makefile.am files.
Change-Id: I33afef5e4ef9eb36de81274533f46598ba9a0edb
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some toolchains (such as sysmobts 201705 one) containing the TLS bug on
old ARM gcc versions (<7.3.0) also crash if the initial workaround found
is aplied (CFLAGS="-mtls-dialect=gnu2"). In that scenario, let's provide
a way to disable the workaround (to avoid "ld" crashing) and warn the
user about requirement to build with -O0 to avoid runtime crashes.
Related: OS#4062
Related: SYS#4628
Change-Id: I04ff8c702eabcf4f6e7b59e11aece2744267cefe
|
|
|
|
|
|
|
|
|
|
|
|
| |
Check if compiler being used contains the bug. GCC 7.3.0 is the oldest
version containing the fix, and version 6.3.0 is known to contain the
bug. Bug is only known to appear so far only on ARM32. If the bug is
present, gcc will generate a wrong binary which wil lend up segfaulting
when accessing TLS (__thread) variables under certain conditions.
Related: OS#4062
Related: SYS#4628
Change-Id: I8acc2cf41b73da0c3290f1cefd79f2bc68b0e77d
|
|
|
|
|
|
|
|
|
|
|
| |
Since March 15th 2017, libosmocore API logging_vty_add_cmds() had its
parameter removed (c65c5b4ea075ef6cef11fff9442ae0b15c1d6af7). However,
definition in C file doesn't contain "(void)", which means number of
parameters is undefined and thus compiler doesn't complain. Let's remove
parameters from all callers before enforcing "(void)" on it.
Related: OS#4138
Change-Id: Iaea795521361a8e5b3b45eaeb35e6eda69163af3
|
|
|
|
|
|
|
|
|
|
|
| |
There's no real good reason for using that function (static buffer)
instead of osmo_str_tolower_buf(local buffer), so let's use the later.
In any case, we get rid of TLS variables in those places, which is a
performance improvement.
It will also allow later shrinking of those buffers if we decide to
define maximum logging category and level name length.
Change-Id: I2e99de1142020e4d80ef0a094e4e751f7903f5f9
|
|
|
|
|
|
|
|
|
|
|
| |
This way we get rid of extra 128 bytes in memory per thread created.
It makes sense to share the buffer since it's same size and it doesn't
make much sense to be using both osmo_str_tolower and osmo_strtoupper at
the same time (usually you either want to move everything to uppercase
or everything to lowerase). In required scenarios, one can still use the
_buf versions.
Change-Id: I032803faa0e27c2efdff1ff276acabab95a8319a
|
|
|
|
|
|
|
|
| |
The pseudotalloc layer doesn't yet support talloc_named() API
which will be used by the upcoming "context" change. Let's add
this function to pseudotalloc.c for our arm-non-eabi builds.
Change-Id: I4d91ebd73a3357a17ef9143a1b41b90186d4c128
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when using gcc 8.3.0 on Debian unstable and doing an embedded build,
I'm getting the following error:
> fsm.c:621:40: error: format '%ld' expects argument of type
> 'long int', but argument 6 has type 'time_t {aka long long int}'
> [-Werror=format=]
Let's avoid that...
Change-Id: I92fb9b08def8475739f0dc6316de43b166f48ac3
|
|
|
|
| |
Change-Id: Ic6d7d68e9a559a6fb5bd6eaf6eccceae51e7ed39
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After reading data from the socket, assigned to a given VTY, we
need to '\0'-terminate the received string. Otherwise, further
access to that string, stored in a heap buffer vty->buf, would
lead to a heap overrun.
== How to reproduce?
$ python -c "print 'A' * 512" | telnet $HOST $PORT
==21264==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x6190000211e0 at pc 0x000000435d2f
bp 0x7ffc06c7add0 sp 0x7ffc06c7a578
READ of size 1025 at 0x6190000211e0 thread T0
#0 0x435d2e in __interceptor_strlen (/usr/local/bin/osmo-msc+0x435d2e)
#1 0x7fb95bfa5624 in talloc_strdup (/usr/lib/x86_64-linux-gnu/libtalloc.so.2+0x6624)
#2 0x7fb95c1be2bc in vty_hist_add /opt/osmocom/libosmocore/src/vty/vty.c:578
#3 0x7fb95c1be2bc in vty_execute /opt/osmocom/libosmocore/src/vty/vty.c:703
#4 0x7fb95c1be2bc in vty_read /opt/osmocom/libosmocore/src/vty/vty.c:1425
#5 0x7fb95c1bfd78 in client_data /opt/osmocom/libosmocore/src/vty/telnet_interface.c:157
#6 0x7fb95b90bd33 in osmo_fd_disp_fds /opt/osmocom/libosmocore/src/select.c:223
#7 0x7fb95b90bd33 in osmo_select_main /opt/osmocom/libosmocore/src/select.c:263
#8 0x5006cc in main /opt/osmocom/osmo-msc/src/osmo-msc/msc_main.c:723:3
#9 0x7fb959935f44 in __libc_start_main /build/eglibc-xkFqqE/eglibc-2.19/csu/libc-start.c:287
#10 0x4226fb in _start (/usr/local/bin/osmo-msc+0x4226fb)
== Why exactly 512?
Because the initial size of the heap buffer is 512 (see VTY_BUFSIZ).
Later on it can be realloc()ated, so X > 512 should also work.
Found using AddressSanitizer and Radamsa [1] fuzzer.
[1] https://gitlab.com/akihe/radamsa
Change-Id: I82f774ad18d0e555eb8f3590a519946d9c583c78
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unfortunately, osmo_sock_get_name_buf() fails in telnet_close_client():
DLGLOBAL INFO telnet_interface.c:130 Closing telnet connection <error-in-getsockname>
because getsockname(), getpeername(), and even close() fail with:
"Bad file descriptor".
This looks like a bug of the existing code.
Change-Id: I77b31abfa159d2f269deaa5a08d94b7bbba7d23c
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After recent system upgrade, gcc 9.1.0, I started getting gsm0808_test
failing locally:
Assert failed memcmp(&enc_ct, &dec_ct, sizeof(enc_ct)) == 0 libosmocore/tests/gsm0808/gsm0808_test.c:992
During investigation with gdb, fields of both structures seem to contain
same values. However, closer lookup gives some hints on why it fails:
(gdb) print memcmp(&enc_ct, &dec_ct, sizeof(enc_ct))
$1 = 85
(gdb) print memcmp(&enc_ct, &dec_ct, 12)
$14 = 85
(gdb) print ((uint8_t*)&enc_ct)[11]
$15 = 85 'U'
(gdb) print ((uint8_t*)&dec_ct)[11]
$16 = 0 '\000'
So the 12th byte in struct gsm0808_channel_type is basically an
alignment padding byte added by the compiler (to align perm_spch_len to
4-byte alignment). Since both compared structs are initialized without
memset(0) but using compiler's designated initializers, it seems the compiler
decided it's no longer needed to zero the padding byte, making memcp fail in
this case.
In order to avoid the failure, let's properly check every field instead
of using memcp here.
Change-Id: I17fe7a0a5dc650f050bba1f47d071be749550729
|
|
|
|
| |
Change-Id: I33837f0fac1afe83596fa600916abc05ecb8c356
|
|
|
|
|
|
|
|
| |
Unconditional initialization follows the structure definition,
so there is no need to do it twice. This prevents compiler
from warning about potential errors.
Change-Id: If9fd2826f132dfa203dda62940d93dbdfcfd92ac
|
|
|
|
| |
Change-Id: I1564f4714a33d36792e4982deb8f19d1b740dc0c
|
|
|
|
| |
Change-Id: I5eb17edadf89ac47b4ca86c9e822037f7c0e518e
|
|
|
|
| |
Change-Id: Ib444383d2074ddb89b3fe5bbf198bcbfabd7057f
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ubsan will report undefined behavior due to the SUN_LEN macros interaction with a null pointer,
so let's tell ubsan to ignore this function. After carefully reviewing the final publically
availlable drafts of the C99,C11 and C18 standards I can confirm that dereferencing null pointers
is still undefined behavior, as such ubsan will always warn with absolutely every existing compiler
version. Since the sanitizers are periodically synced between llvm and gcc I'm also fairly confident
that rebuilding everything with compiler_rt to use the integrated sanitizers would result in the same message.
I sincerly hope that this explanation provides to be sufficient, If not I'd be willing to show up at
the next llvm dev meeting to provide quotes from actual sanitizer developers to back up these claims.
Change-Id: I0ff445072f1b46390c9f70b21d61c789e39358d5
|
|
|
|
| |
Change-Id: Id38272ff93fae6d2fdf39df4ffc74856d6c9a898
|
|
|
|
| |
Change-Id: Ie18c291d0cfe3b246d09ac6cfd9591951a2984c8
|
|
|
|
|
| |
Change-Id: I34e465dead179487f7d4508e0e6ecf0e838c6eb7
Closes: CID#177910
|
|
|
|
|
| |
Change-Id: I7a544d2d43b83135def296674f777e48fe5fd80a
Closes: CID#190866
|
|
|
|
|
| |
Change-Id: I0888fbad0f9094ec1b31e2cceecfc9cd372399bd
Closes: CID#202057
|
|
|
|
| |
Change-Id: I1e2c62cb9047648907c91b99f764f6caba8f4493
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than having the encoder/decoder library print some log
messages in case of encoding/decoding errors, let's provide something
akin to 'errno', but with a string instead of a numeric error code.
The 'osmo_cbsp_errstr' global variable (if set) contains a
human-readable string describing the most recent encoding/decoding error.
It exists separately for each thread and hence can be used safely in
multi-threaded environments.
Change-Id: Id9a5a595a76ba278647aee9470ded213d8464103
|
|
|
|
|
|
|
|
|
|
| |
This introduces definitions as well as a parser+encoder for the
Cell Broadcast Service Protocol (CBSP) as specified in 3GPP TS 48.049.
CBSP is used on the interface between CBC and BSC.
Related: OS#3537
Change-Id: I5b7ae08f67e415967b60ac4b824db9e22ca00935
|
|
|
|
| |
Change-Id: I9d6f6b66c99c43107d1ad3e80af332e967bb19e8
|
|
|
|
| |
Change-Id: I57a330e16cc2910597672e1b27cf971499cea5bc
|
|
|
|
| |
Change-Id: I56cce5cda0621f5e9f1c28aaad4646e9e267d17d
|
|
|
|
|
| |
Related: OS#3047
Change-Id: Ic147678e7906a8b9ad7fac8367602b656f4172e6
|
|
|
|
|
|
|
|
|
|
|
|
| |
The link quality, defined by C/I (Carrier-to-Interference) ratio,
can be computed from the training sequence of each burst, where we
can compare the "ideal" training sequence with the actual training
sequence and then express that in cB (centiBels, dB * 10).
By analogy with both RSSI and ToA, it can be used to filter out
false-positive detections and ghost Access Bursts.
Change-Id: Ie2a66ebd040b61d6daf49e04bf8a84d3d64764ee
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 4e284b637943980a405a8c44f2712b749ded428f.
Unfortunately, some projects such as OsmoMSC, OsmoBTS and OpenBSC
do contain OSMO_ASSERT statements without a semi colon. Thus,
this change causes compilation errors when building them.
Please note that only the OSMO_ASSERT's definition is reverted,
while changes to other files (adding missing semicolons) are kept.
Change-Id: I6da4d7397d993f6c1af658cb5ae1e49c92a1b350
|
|
|
|
|
|
|
|
|
| |
When using `OSMO_ASSERT(exp);` clang will warn about
an empty expression because the semi colon was superflous.
Use do {} while (0) to enfore the need of a semi colon.
This might break other test.
Change-Id: I2272d29a81496164bebd1696a694383a28a86434
|
|
|
|
|
|
|
|
|
| |
Do not remove the entire doc/vty/ dir during the doxygen generation,
because it contains versioned files.
Fixes: 2fe50ac9511469a587426b80501b2b5da770e3a0 ("doxygen: enable cross referencing everywhere")
Related: OS#3986
Change-Id: I884398c5e834ae2fac0af8c9b52d65bb3ceacb2d
|
|
|
|
|
|
|
| |
Ignore files created during the two-pass doxygen generation that was
introduced in Ib03d0b70d536c8f1386def666c89106a840f7363.
Change-Id: I719bbc968420c462426d2c0ce703c7f3b2c1139e
|
|
|
|
| |
Change-Id: I7df6858bb98abffc1d5bf420f991ae5854b24638
|
|
|
|
|
|
|
|
| |
The timeout is calculated dynamically in t200_by_lchan() based on FN
advance value estimated by bts_get_avg_fn_advance(), so it's informative
to have the final value printed out.
Change-Id: Ib50a9c23de881c66c9218833703cc41101e06bfd
|
|
|
|
| |
Change-Id: Ifb3115c7488fbcf082cc9b92abc25cf7c46064e0
|
|
|
|
|
|
| |
The function allocates x bytes not bits for the vector.
Change-Id: I60fbe9fe9acd11c5d3232207f1bb677e8a98625f
|