Allow dumping the VTY XML reference (for generating manuals) to a normal FILE*
stream instead of a vty output buffer.
We currently generate the VTY reference by starting the client program,
connecting to the VTY telnet and dumping the reference. That is weirdly
convoluted, especially since there has to be a valid config file that
successfully starts up a minimal set of external links before the reference can
be generated. IMO we should have dumped the XML reference to stdout from the
start, and never to a VTY session.
With this patch, it is trivial to generate the XML VTY reference by a
commandline switch. The client program will set up the entire VTY, and
immediately after parsing the cmdline options but before parsing a config file,
just dumps the reference and doesn't even start establishing local ports. That
would allow generating the XML reference on the fly during the build process of
the manuals, without the need of a docker container or somesuch.
A first implementation of such a commandline switch is `osmo-bsc -X`, added in
This patch jumps through a bit of a hoop to still allow dumping to a VTY buffer
without code dup, to still allow dumping the XML reference through telnet VTY,
until all our programs have implemented an -X switch (TM).
This implementation is taken from OsmocomBB, in particular from:
Change return type to uint16_t, because neither ARFCN, nor MAI
can be negative. Add prefix 'gsm0502_' to the function's name.
gsm48_pag_resp and gsm48_service_request: omit comments in big endian part.
dtap_header: better segment the substruct.
gsm23041_msg_param_gsm: match up whitespace / comments.
Rationale: the script is a good way to avoid bugs from manually composing the
big endian parts (for example, it detected the missing endian.h include, fixed
in I593cc5e8272469b570559206bb02b6e79797340b). However, it becomes cumbersome
if it creates numerous edits in the source tree, which cause more time spent
for whoever wanted to rather save time with it. So let's keep the code tree
matching that struct's output.
Cause class is in bits 5-7 of the cause value.
For the cause value 0x52 old version returned 0xa instead of
a correct 0x5.
See section 188.8.131.52 Cause of TS 08.08 for the details.
Function gsm0808_get_cipher_reject_cause() was previously available
in private gsm0808_utils.h. In practice, the exact same code is useful
to extract Cause IE value from any of the many other BSSMAP messages
which use it.
So let's rename it to gsm0808_get_cause() and make it avilable
to everyone to use.
calling log_init() multiple times would lead into memory leaks. The
function should only be called once on startup of the process. Lets make
sure that it does not get called multiple times by accident.
when the API user of libosmocores logging infrastructure does not set a
pre-defined logging level in struct log_info_cat, the result would be an
invalid logging level. In order to avoid problems with that and to spare
all the additional .loglevel = LOGL_NOTICE (API users are advised to use
LOGL_NOTICE as default) lines in the user code lets check the logging
level on startup and set LOGL_NOTICE if there is no logging level set.
- struct gsm48_range_1024
- struct gsm48_range_512
- struct gsm48_range_256
- struct gsm48_range_128
In commit , the automatic little-to-big-endian compatibility by
struct_endianness.py introduced doubled little/big endian struct listings by
accident, resulting in a wrong big endian structure (due to double reversal in
the original big endian part). Remove the old conditionals around the new
automatic ones to fix the structs for big endian.
The pointer *pw is only populated when the the parameter *user is given,
otherwise it remains uninitalized while it is used later when the
previleges are being dropped.
This function offers the highest level of API among all libosmousb
helper functions. It is intended as a one-stop shop for everything
related to grabbing an interface.
See TS 08.08 section 184.108.40.206 SAPI "n" REJECT:
1) DLCI is a TV element, not V.
2) Cause is a TLV element and we have a special function to encode it.
while skipping `0` might be visually pleasant for non-repeating groups, e.g.:
it makes metrics parsing very awkward for repeating groups, e.g.:
and since nobody's going to look at raw statsd stream anyway,
we can live with some extra zeroes
Reliable monitoring requires regular flush of all stat values, even
if they have not changed. Otherwise (1) the monitoring app has to
maintain state and (2) can go out of sync if it's restarted while
the app is still running.
cfg_stats_interval_cmd() function was (probably mistakenly)
inserted between cfg_stats_reporter_statsd_cmd() and
cfg_no_stats_reporter_statsd_cmd() function which makes no sense.
Move it below the cfg_no_stats_reporter_log_cmd() to follow the order
of the osmo_stats_vty_add_cmds() function calls.
So far we only looked at SW definitions of the card profile. However,
if we have a currently selected application, we also must check
that application for SW definitions.
This breaks ABI and API all over the place, but as there are no
known users beyond osmo-sim-test, this is acceptable.
this causes problems when compiling user applications
/usr/bin/ld: ../../src/libvlr/libvlr.a(vlr_lu_fsm.o):/usr/local/include/osmocom/gsm/protocol/gsm_29_118.h:184: multiple definition of `sgsap_ie_tlvdef'; msc_main.o:/usr/local/include/osmocom/gsm/protocol/gsm_29_118.h:184: first defined here
AC_SEARCH_LIBS was finding the function correctly, but later on
AC_CHECK_FUNCS was not including the found LIBRARY_RT so the function
was not found, and hence HAVE_CLOCK_GETTIME ended up undefined (which in
turns disables support for osmo_clock_gettime() API).
This happened in systems like the soekris where the clock_gettime sybmol
is available in external lib -lrt.
Let's avoid double-checking for the function twice, and simply define
HAVE_CLOCK_GETTIME when AC_SEARCH_LIBS succeeds (the success action is
guaranteed to be called even if there's no extra lib required).
Each struct already contains different definition based on endianess, so
there's no reason to re-define all of them again based on endianess.
Probably at some point somebody run the script
./contrib/struct_endianess.py on those structures but forgot to remove
the old way of supporting differnet endianess.
/usr/bin/ld: .libs/gsm0503_coding.o:/home/laforge/projects/git/libosmocore/src/coding/../../include/osmocom/coding/gsm0503_parity.h:16: multiple definition of `gsm0503_mcs_crc12'; .libs/gsm0503_parity.o:/home/laforge/projects/git/libosmocore/src/coding/../../include/osmocom/coding/gsm0503_parity.h:16: first defined here
The signalfd(2) mechanism of Linux allows signals to be delivered
and processed via normal file descriptor I/O. This avoids any of the
usual problems about re-entrancy of signal processing, as signals can
be processed from the osmocom select() loop abstraction just like any
For a process running as root, it may be desirable to drop privileges
down to a normal user before executing an external command. Let's
add a new API function for that.
When switching the l2 structures passes to test_pdtch() to be constant,
it was noted that output of the test changes. This happens because same
array is tested several times with different length, incrementing each
time. Since the test was modifying the input array directly, it means
each new run of test_pdtch() the array was further modified.
Upon constifying the structures, we copy the array and hence only modify
the required bits each time.
gsm0503_coding contains AMR decoder functions for HR and FR. Those can
only decode AMR payload frames but not amr DTX frames. Lets add
functionality to detect DTX frames. Also lets add decoding for SID_UPDATE
frames as well as error checking for the SID frame recognition patterns.
As pointed out at https://github.com/libexpat/libexpat/issues/312
libtool does not play nice with clang sanitizer builds at all.
For those builds LD shoud be set to clang too (and LDFLAGS needs the
sanitizer flags as well), because the clang compiler driver knows how
linking to the sanitizer libs works, but then at a later stage libtool
fails to actually produce the shared libraries and the build fails. This
is fixed by this patch.
Addtionally LD_LIBRARY_PATH has no effect on conftest runs during
configure time, so the rpath needs to be set to the asan library path to
ensure the configure run does not fail due to a missing asan library,
SANS='-fsanitize=memory -fsanitize-recover=all -shared-libsan'
ASANPATH=$(dirname `$CC -print-file-name=libclang_rt.asan-x86_64.so`)
export LDFLAGS="-Wl,-rpath,$ASANPATH $SANS $LDFLAGS"
osmo-gsm-tester raised an ASan warning in osmo-bts-trx during execution
of a test with EGPRS enabled and a modem connecting to it (see OS#4483
for full trace):
==12388==ERROR: AddressSanitizer: global-buffer-overflow on address 0x7fa20b9ab8d0 at pc 0x7fa20b982894 bp 0x7ffdfea8b9c0 sp 0x7ffdfea8b9b8
READ of size 1 at 0x7fa20b9ab8d0 thread T0
#0 0x7fa20b982893 in gsm0503_mcs1_dl_interleave /home/osmocom-build/jenkins/workspace/osmo-gsm-tester_build-osmo-bts/libosmocore/src/coding/gsm0503_interleaving.c:165
Function gsm0503_mcs1_dl_interleave() was being passed the 6-bit USF
encoding while clrearly expecting a 12 element array. TS 05.03 220.127.116.11.2
"USF precoding" also clearly states that 12bit encoding is to be used