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
So far, we used blocking, buffered fwrite() to write to stderr
and file targets. This causes problems if there are [slow] consumers
causing delays, such as gnome-terminal (when the program is started
interactively) or systemd/journald (where we observe 64..128ms blocks on
stderr).
This patch introduces stderr/file based logging via write_queue
and osmo_select_main(), i.e. switch from glibc-buffered, blocking
to internally buffered, non-blocking writes.
* when osmo_stderr_target is created via application.c, we create it
in blocking stream mode for backwards compatibility, particularly
for [smaller] programs that don't use osmo_select_main()
* when the VTY code encounters 'log stderr' or 'log file FILENAME',
we switch that respective target to non-blocking write-queue mode,
as this means the application is in fact using osmo_select_main()
* The config file can now state 'log stderr blocking-io' or
'log file FILENAME blocking-io' to explicitly enforce using blocking
stream based I/O
* The application can at any time use API functions to switch either way
Closes: OS#4311
Change-Id: Ia58fd78535c41b3da3aeb7733aadc785ace610da
The library specific sub-systems are kind of special, because their
position in the 'osmo_log_info' may vary depending on the number of
application specific sub-systems. This is why their associated
constant values (like DLGLOBAL) are negative, and this is what
the LOGP() macro expects as the first argument.
Before this change, invoking 'logp' command with any library
specific logging sub-system would result in getting messages
printed with the fall-back DLGLOBAL sub-systems.
Change-Id: If86563e169fe1243adfa7b09c9d65d9f88c8a99e
Introduce 2 new logging sub systems for signal and unit data.
Unify log messages so all log messages look similiar.
Log also Rx PDUs. Ensure dropped Tx packets (BLOCK/RESET on SNS)
contain *Tx*.
Change-Id: I34b8fde2955ecc010d1dcd9512e1bba9211e2c0d
Let's use log_set_print_filename2() API instead, which has less ackward
behavior implications like changing the print status of category-hex.
Related: OS#5034
Change-Id: Ifc78e1dcba5baf0b41f6ccbbbd1e3f06552d73da
This will alow easily changing default values for print_category vs
print_category_hex later.
In any case, every test relying on logging output validation should
always explicitly state the config to avoid issues in the future if
default values change.
Related: OS#5034
Change-Id: If29b40557d5c2bcda04b964f344070bad58d8f28
Historically, BSSGP uses a non-constant, user-configurable integer
varieable for the logging sub-system. Let's replace this with a
statically-allocated library logging constant.
This is required if we want to use the subsystem number in e.g.
static initialized for osmo_fsm.log_subsys.
Change-Id: I506190aae9217c0956e4b5764d1a0c0772268e93
It's hard to figure out what color logging categories have with those ANSI
color code strings. Instead, define these OSMO_LOGCOLOR_* constants.
Naming: commonly, the logging.h header has the "LOG" prefix in the name, but it
seems saner to include the OSMO_ prefix: it seems too likely that some
libosmocore user somewhere already has defined "LOGCOLOR_RED" somewhere.
Change-Id: I03b6b1f73ae7ee61d37ff921e071a3d0881d3e9a
log_enable_multithread() enables use of locks inside the
implementation. Lock use is disabled by default, this way only
multi-thread processes need to enable it and suffer related
complexity/performance penalties.
Locks are required around osmo_log_target_list and items inside it,
since targets can be used, modified and deleted by different threads
concurrently (for instance, user writing "logging disable" in VTY while
another thread is willing to write into that target).
Multithread apps and libraries aiming at being used in multithread apps
should update their code to use the locks introduced here when
containing code iterating over osmo_log_target_list explictly or
implicitly by obtaining a log_target (eg. osmo_log_vty2tgt()).
Related: OS#4088
Change-Id: Id7711893b34263baacac6caf4d489467053131bb
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
Since March 15th 2017, libosmocore API logging_vty_add_cmds() had its
parameter removed (c65c5b4ea0). 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
It's defined in logging.h for quite some time but is not actually
enabled alongside with other internal logging categories.
Change-Id: I0e7a2add6293a072752900608c8ba34cc3850f31
We must explicitly check the return value of osmo_log_vty2tgt(), or may run
into a segfault. I wasn't aware of this and introduced numerous such cases in
I36f17c131cc70ce5a1aef62fd9693097de230cd4.
Reproduce: on the VTY, do not issue 'logging enable', invoke 'logging level
force-all LEVEL' first.
Show in logging_vty_test.vty that this situation is now again amended by
telling the user that logging was not enabled.
Related: OS#3611
Change-Id: Id11702d1801d6654ca5e5a51b597a0d802e2e8dd
We want to have well-formed config files that print exactly one space
per VTY/config node level, and not two.
Change-Id: Ia75c7067284ea225cffe13ca71bad05a7747ae66
Add new command to once-off set each and every category to the given log level,
as discussed at length on the openbsc@ mailing list.
Show that it works in logging_vty_test.vty.
Change-Id: I4c3e4f786476cb813fdc0a7c64f30ee04758309d
Add 'logging level force-all <level>' and 'no logging level force-all' as new
names for 'logging level all <level>' and 'logging level all everything'.
Resurrect the functionality of 'logging level all everything' -- even if it is
still deprecated because the name is confusing, it is now just an alias for
'no logging level force-all'.
Show in logging_vty_test.vty that we can now again lift the global logging
clamp, both with the new commands as well as with the deprecated ones.
Also show that 'force-all' is written back properly, if set.
Change-Id: I36f17c131cc70ce5a1aef62fd9693097de230cd4
The 'logging level all everything' has not had an effect for some time now. The
plan is to bring back its old functionality, but to keep it deprecated and
rather define a less confusing name.
* Deprecate 'everything'.
* Do not write 'everything' during 'write file' or 'show running-config', which
we curiously still do until now.
BTW, the reason why we need to compose a complete list of categories for the
deprecated 'everything' command is explained in detail in the commit log for
I3b083f27e3d751ccec258880ae7676e9af959a63
Change-Id: Ib75fedb0572570a61bb34ee729a2af86cf5f16da
I am setting out to refactor various details about logging. To show the effect,
I am first adding this new test to illustrate the exact effects on the various
osmo programs.
Add logging_vty_test.c as a standalone program that simply defines a few
logging categories and opens a telnet vty to play with.
Add logging_vty_test.vty, as an osmo_verify_transcript_vty.py test script.
Add --enable-external-tests to configure.ac, to enable running
logging_vty_test.vty during 'make check'.
Also allow running 'make vty-test' without the need to first configure with
--enable-external-tests (a flexibility I've missed many times over in the other
osmo source trees).
Add a Makefile.am stub for external CTRL tests, basically a copy-paste from
osmo-msc.git. I doubt that libosmocore will get python driven CTRL interface
testing any time soon, but if so we will know to not run it concurrently.
Change-Id: I948e832a33131f8eab98651d6010ceb0ccbc9a9c
This was always intended to be GPL and not AGPL. "kat" did the
development as part of an internship paid by me and we agreed
to shared copyright.
Change-Id: Ied2041ba20c5737bd967dfaa3017edf72a95b31c
In log_set_category_filter(), passing a negative index lead to memory
corruption. Particularly dangerous since the internal logging categories have
negative values.
Fix: apply map_subsys() to interpret negative values as internal logging
categories.
As a side effect, out-of-bounds logging categories will be mapped to DLGLOBAL
instead of being dropped.
Fix the expectations in logging_test to match the fixed bug.
While at it also guard against a NULL logging target.
Change-Id: Ib0725b22bc39498c6b3970a61eb3339cf56d19f1
Add a check to logging_test.c to show a bug: passing an internal DL* category
constant to log_set_category_filter() results in a negative array index and
undefined behavior. A sanitize build should catch this.
The bug is confirmed by the fact that logging_test.err stays the same
(hopefully) although a logging output should appear from this patch. The test
could as well segfault or anything else, it's a bit of a gamble.
This bug will be fixed along with the expectation in a subsequent patch.
Change-Id: Ie2da77c642a84cafc0f528985930697ec167183b
To check category bounds, rather use num_cat_user, to redirect all semantically
unknown categories to DLGLOBAL.
Adjust logging_test expectations accordingly: "(d)" is now also shown.
Note: subsys is and needs to be signed, while num_cat* are unsigned. Thus for a
negative subsys, 'subsys >= num_cat_user' practically always yields true. Pay
close attention to signedness and check upper bound only for positive values.
Change-Id: I4a952b759f30d90fbfb81fedcfc56a8092ea18c1
In the background osmo_log_info array, the user's logging categories are
enhanced by the library internal ones. So far logging category range checking
only checked for the larger array bounds, although passing a logging category
>= num_cat_user is already semantically unknown and should redirect to
DLGLOBAL.
Add a check to logging_test.c to show that this isn't happening. Instead of
DLGLOBAL, a logging category that happens to be at that index is queried.
The bug is confirmed by logging_test.err only showing "(e)" and not "(d)":
"(e)" is shown because the first category after the user ones happens to be
DLGLOBAL. "(d)" is omitted since it hits a category that's not on debug level.
This bug will be fixed along with the expectation in a subsequent patch.
Change-Id: I397278714018ee9a0ae5101515f31ddddf79c2ec
In map_subsys(), fix the '>' condition to '>=' for array bounds checking.
Also make the bounds checking more strict: after both invocations of
subsys_lib2index(), re-check validity of the array index. If the final index is
still wrong, which should never happen, exit by assertion.
Change-Id: I7ca1a1d47724e40350f1c4dfebe90bad01c965f9
Add a check to logging_test.c to show a bug: when a logging category value that
is the first out-of-bounds value is passed to the logging system, the internal
map_subsys() fails to redirect to DLGLOBAL due to a flawed conditional. This
results in a too large array index and undefined behavior. A sanitize build
should catch this.
The bug is confirmed by the fact that logging_test.err stays the same
(hopefully) although a logging output should appear from this patch. The test
could as well segfault or anything else, it's a bit of a gamble.
This bug will be fixed along with the expectation in a subsequent patch.
Change-Id: I12bf38b6c1f85e2d7bf5a15f942dfe0beed41eba
For out-of-bounds logging categories, redirect to the proper DLGLOBAL array
index instead of returning -1.
Adjust test expectation which shows that the bugs tested for are fixed.
Note: there are separate bounds checking problems, left for another patch.
Change-Id: I6ea9a59e005a22e0305454291714fdb9531c346b
Add a check to logging_test.c to show a bug: when a logging category value that
is out-of-bounds is passed to the logging system, the internal map_subsys()
function should remap that to DLGLOBAL. But in fact DLGLOBAL is -1 and the
function fails to map this to a proper positive array index, directly returning
-1 instead. This results in a negative array index and undefined behavior. A
sanitize build should catch this.
The bug is confirmed by the fact that logging_test.err stays the same
(hopefully) although a logging output should appear from this patch. The test
could as well segfault or anything else, it's a bit of a gamble.
This bug will be fixed along with the expectation in a subsequent patch.
Note: osmo_log_info->num_cat + 0 is also out-of-bounds, but there is a separate
bug there, so leaving this for another patch.
Change-Id: I161b6550fa204a872bad1abefee1a6155393fafd
Prepares for upcoming modifications of the logging test to show and fix bugs in
the logging system.
Change-Id: I9461b987adf85d87469a6af55de5f1aa478f6ebb
There doesn't seem to be a reason not to check the filter. Update
and extend the test. Currently the filter function will be called
once for the log check and once for the output of it.
This commit adds OSMO_ASSERTs for mandatory conditions related to
log_check_level, and fprintfs for optional conditions, since it is
always safe for log_check_level to return != 0.
Sponsored-by: On-Waves ehf
The filter_fn has not been copied into the new structure breaking
the imsi and other filters in OpenBSC. Looking at the code we should
also introduce a callback for the reset of the context so we could
use subscr_get/subscr_put on the subscriber structure.
Vadim Yanitskiy
Neels Hofmeyr
Harald Welte
Oliver Smith
Alexander Couzens
Pau Espin