Shorthand for the INET/INET6 switch() to get/put the addr part, useful
for encoding and decoding message buffers.
Related: OS#5599
Change-Id: Ie9e33bfac525c59c30714663d2bfcc62ec9eeb81
There already are osmo_quote_str_buf() and osmo_quote_str_buf2(), same
for _escape_, but none of them return the snprintf() like string length.
A private function does, publish this in the API.
The returned chars_needed is required to accurately allocate sufficient
size in string functions that call osmo_quote_str/osmo_escape_str. I am
adding such in osmo-upf.git.
Related: SYS#5599
Change-Id: I05d75a40599e3133da099a11e8babaaad0e9493a
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
When the logging framework is not initialized we get an error:
"ERROR: osmo_log_info == NULL! You must call log_init() before
using logging in ..."
There are sometimes situations where some code tries to log before
logging was initialied. This is a problem because the actual log
line with the debug info we need is covered up by the error message
from the logging framework.
Lets introduce a fallback logging function that is called when the
the logging framework is not available. This function can just use
fprintf to output to stderr.
Change-Id: I9b1b0988e02322e3e44fd4ceea3e1bc2d4df3c45
The configuration defaults for the socket statistics are currently set
to a batch size of 1. This means that only one socket per timer
expiration is scanned. This rate is probably a bit low. To speed things
up a bit we should set the default to 5. Scanning 5 sockets at a time is
still in the affordable range.
Change-Id: I87abc74c00377191f7940c5b8f19d932618fc019
Related: SYS#5701
When picking the end state, looking only at the path metric
is highly suboptimal because in a tail biting code, we _know_ that
whatever treillis path is correct, it must start and end at the same
state. So we only consider path meeting that condition. We know any
path that doesn't isn't the right one. We only fallback to only
path metric if no path met that condition.
Fixes OS#4508
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I87e51d3880c0fe7bf3d6cd08fd46517a424a230c
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 macro introduced in d02090bba5 was not
enough: the actual logging macros are being used, i.e. by the fsm, so
wrap those as well, and provide a flag to disable this at build time.
Change-Id: Ia4c78abe5f198139f96ffa289998855be2477585
This was previously unconditionally defined, so embedded targets were
unable to get rid of the log macros and functions.
Change-Id: I589f93d98a6bc5cf6221c56e2fe3f27bfdd200e8
gsmtap_sendmsg() places the burden of freeing the msgb in case of
erroneous return codes on the caller. A review of existing users
shows that this is overly optimistic and many calls get it wrong,
opening up memory leaks.
Let's add a new function gsmtap_sendmsg_free() which behaves like
gsmtap_sendmsg() but always takes ownership: Either it is sent + freed,
or it is just freed.
Change-Id: I106b09f2a49bf24ce0e8d11fd4d4ee93e9cafdf5
Related: OS#5329
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
Some deprecated functions are still used in libosmocore .c code. Use
OSMO_DEPRECATED_OUTSIDE() to get rid of those "resident warnings".
Change-Id: I6e79acc87be37ac1aaec900e737e41450b46826a
Intead of attempting to store all distinct values of a reporting period,
just store min, max, last as well as a sum and N of each reporting
period.
This gets rid of error messages like
DLSTATS ERROR stat_item.c:285 num_bts:oml_connected: 44 stats values skipped
while at the same time more accurately reporting the max value for each
reporting period. (So far stats_item only reports the max value; keep
that part unchanged, as shown in stats_test.c.)
With the other so far unused values (min, sum), we are ready to also
report the minimum value as well as an average value per reporting
period in the future, if/when our stats reporter allows for it.
Store the complete record of the previous reporting period. So far we
only compare the 'max' value, but like this we are ready to also see
changes in min, last and average value between reporting periods.
This patch breaks API by removing:
- struct members osmo_stats_item.stats_next_id, .last_offs and .values[]
- struct osmo_stats_item_value
- osmo_stat_item_get_next()
- osmo_stat_item_discard()
- osmo_stat_item_discard_all()
and by making struct osmo_stats_item opaque.
In libosmocore, we do have a policy of never breaking API. But since the
above should never be accessed by users of the osmo_stats_item API -- or
if they are, would no longer yield useful results, we decided to make an
exception in this case. The alternative would be to introduce a new
osmo_stats_item2 API and maintaining an unused legacy osmo_stats_item
forever, but we decided that the effort is not worth it. There are no
known users of the removed items.
Related: SYS#5542
Change-Id: I137992a5479fc39bbceb6c6c2af9c227bd33b39b
Using mbedtls commit f9c599cd8ac9d00c484d4f5b027e18c6af4f9fdf before
they re-licensed to Apache 2.0, so we have a GPL-v2-or-later bsae64
implementation and avoid having code under a different license in the
tree.
This code is the unmodified import, so we can record any local changes
compared to the original version.
Change-Id: I39a9d3ab98257d21b9439b00528c744efa372c14
There also is an osmo_stat_item_desc, so the name 'desc' makes it hard
to read the code / the upcoming refactoring patches. It is an
osmo_stat_item_group_desc, so call it group_desc.
Related: SYS#5542
Change-Id: I07bc011450549a44ebf043e7d8a70718ddfd900e
Add "missing" API for looking up a stat_item_group by its index-name.
A subsequent patch, which adds stat_items to the CTRL interface, will
use this to look up stat item groups by object name.
In stat item groups, there are group names, having a number of indexes
denoting different objects. An object can have, besides the index, also
a name that is equivalent to the index.
Apologies for the weird function name, it's still the best one I
could come up with: "group_by_name" refers to the group name, and
"idxname" refers to the name that the object index is associated with.
We already have osmo_stat_item_get_group_by_name_idx().
Other contestants for name of this new function were:
- osmo_stat_item_get_group_by_name_name()
because there is a "name" instead of "idx", but I find it confusing.
- osmo_stat_item_get_group_by_name_idx_name()
but I find that the last "name" should be closer to the "idx".
Related: SYS#5542
Change-Id: Ia1a77a1e4657ba624dd4f4bf7ad274e7751d0141
Properly converting a string to an integer while validating against all
possible errors is not trivial. It is a recurring theme in code review,
and there are places in osmo code that do it wrong.
End this by providing a simple API, if for nothing else then as an
example of how to use strol() / strtoul() / strtoll() / strtoull()
in an airtight way.
A subsequent patch, adding stat items to the CTRL interface, uses this
to properly validate indexes in CTRL variables and convert them to int.
Related: SYS#5542
Change-Id: I4dac826aab00bc1780a5258b6b55d34ce7d50c60
Background:
* Individual values can be added to osmo_stat_item.values at any time.
* Stats are reported at a fixed interval (see vty 'stats interval'),
e.g. every 10 seconds.
* In order to report a new stat value, we use the maximum of all
osmo_stat_item.values added since the last report.
* By default, we do not send new stat values if they did not change
(see vty 'config-stats' -> 'flush-period' default of 0).
Fix the following bug:
* If 'flush-period' is 0, and no new osmo_stat_item.values are coming
in, the last value that gets reported is not necessarily the last
entry in osmo_stat_item.values.
* For attached reporters (statsd), it could then be that the given stat
stays at the wrong value for a long stretch of time (think of several
hours/days/forever).
Explanation of how the test shows that it is fixed:
* stats get reported (value is irrelevant)
* osmo_stat_item gets a new value: 20
* osmo_stat_item gets a new value: 10
* stats get reported (value: 20, the maximum of both new values)
* osmo_stat_item gets no new values
* stats get reported (value: 10, this is new because of the bug fix,
the real last value in osmo_stat_item, different from the 20 sent
earlier, without the fix it would not send anything here and the last
sent value would be 20)
* osmo_stat_item gets no new values
* stats get reported (nothing gets sent, since the real last value was
already sent and 'flush-period' is 0)
Fixes: OS#5215
Change-Id: Ibeefd0e3d1dbe4be454ff05a21df4848b2abfabe
It's really a false positive since _sb_l is compared and granted to be
psotivie by the time we compare, so we don't really care, but c++ is not
happy about it.
"""
/osmocom/core/utils.h:227:40: error: comparison of integer expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long unsigned int’} [-Werror=sign-compare]
227 | if (_sb_l < 0 || _sb_l > _sb_remain) \
| ~~~~~~^~~~~~~~~~~~
"""
Change-Id: I90e7374aa959468670f1c0ea65a427398d423ddb
It is not be obvious on the first look that ->prev actually points to the last
element of a list, lets add a macro for that to make the API easier to use
Change-Id: Icf455bf6ba9d60bd311af17c9e80febaa42cacc9
Related: SYS#4971
Allow telling osmo_select_main* to only service pending writes (shutdown
mode). Introduce API fuctions to indicate a shutdown request, and find
out whether shutdown is complete.
Some osmo programs have a curious sleep of few seconds upon receiving
SIGTERM. The idea presumably was to finish off pending writes before
halting the program. But a sleep() on program exit is annoying,
especially when there usually are no pending writes, and when osmo-bsc
is launched numerous times for tests.
Change-Id: Ib94d4316924103459577087c2214188679db2227
Underlaying APIs (msgb_alloc) use a uint16_t as a type, which means
until now passing a value > 2^16 would succeed providing a msgb with
less space than requested.
Since those are static inline, there's no symbols used by apps, so we
should be safe enough changing the type to be uint16_t, since change
would only be applied at re-compile time.
Change-Id: I83c8222484e4856c68134a1a9d8cf96eb91af1b8
This patch adds a new field "name" to the rate_ctr and osmo_stat_item_group
structs, together with an API to set it. This new field allows for easy
identification of specific group instances when several of them exists,
rather than using a sometimes random/increasing index value.
If set, this name (string) is used instead of the index by the stats
reporter.
The name, if set, is also printed during "show stats" VTY commands.
It's up to the user or application to set up unique or meaningful names
to fullfill one's needs.
WARNING: this commit breaks ABI and possibly creates unexpected behavior
when run with non-rebuilt apps which use the modified structs directly
to get the coutners, or if use the static inline API rate_ctr_inc2().
Existing users of these structs should migrate to use new APIs
introduced in follow-up commits instead of accessing the field directly.
Related: SYS#5456
Change-Id: I0dc510783dd9ae8436dae8005a7b3330e80d36f3
Having this API and forcing apps to use it will allow easily adding new
members to the group structure without having so much impact in users of
this struct.
Related: SYS#5456
Change-Id: Iebbf401f11e36645f8964d389460918eb9e0910e
The api doc indicates the possibility to pass -1, and calling
osmo_tdef_get() actually casts the arg to a signed long. To end the
confusion, change default_timeout from unsigned long to long.
Change-Id: I51b9172603984839448346c9836e43c8c802fcf8
Every socket function that can be passed a 'flags' argument now
supports the following two additional macros that can be or-ed in
with the flags:
* OSMO_SOCK_F_DSCP(x) -- specify the IP DSCP of the socket
* OSMO_SOCK_F_PRIO(x) -- specify the priority of the socket
The existing osmo_sock_set_{dscp,priority}() functions are useful,
but you cannot call them in between the socket creation and the
connect() operation when using our socket helpers. This means that
the first packet sent will have the default DSCP/priority, and only
later packets would have the desired values.
When using the functionality introduced by this patch, we can ensure
that even the very first packet of e.g. a TCP or SCTP connect()
will have the correct DSCP/priority applied.
Change-Id: If22988735fe05e51226c6b091a5348dcf1208cdf
Related: SYS#5427
In some situations we want to set the SO_PRIORITY socket option
to determine the in-kernel priority of packets generated by this
socket.
Change-Id: I89abffcd125e6d073338a5c6437b9433220e1823
Related: SYS#5427
At least on Linux, sockets have a IP_TOS socket option that can be
configured to set the TOS. However, TOS (of RFC791) was replaced
by the DSCP (of RFC2474) in 1998.
As the DCSP bits are only the upper 6 bits of the TOS bits, let's
introduce a helper to get, mask and set the DSCP values in the TOS
bits.
Related: OS#5136, SYS#5427
Change-Id: Ia4ba389a5b7e3e9d5f17a742a900d6fd68c08e40
Fix counting of values missed because of FIFO overflow in
osmo_stat_item_get_next(), by assigning a new item value id effectively
as item->value[n + 1].id = item->value[n].id + 1, instead of increasing
a global_value_id that is shared between all items and groups. With
global_value_id, the count of values missed was wrong for one item, as
soon as a new value was added to another item.
This partially reverts b27b352e ("stats: Use a global index for stat
item values") from 2015, right after stats was added to libosmocore. It
was supposed to make multiple readers (reporters) possible, which could
read independently from stat_item (and later added comments explain it
like that). But this remained unused, stats has implemented multiple
reporters by reading all stat_items once and sending the same data to
all enabled reporters. The patch caused last_value_index in struct
osmo_stat_item to always remain at -1.
Replace this unused last_value_index with stats_next_id, so stats can
store the item-specific next_id in the struct again. It appears that
stats is the only direct user of osmo_stat_item, but if there are
others, they can bring their own item-specific next_id: functions in
stat_item.c still accept a next_id argument.
Related: OS#5088
Change-Id: Ie65dcdf52c8fc3d916e20d7f0455f6223be6b64f
Let osmo_stat_item_get_next, osmo_stat_item_discard,
osmo_stat_item_discard_all consistently refer to their next_id arg as
such (and not idx or next_idx). It refers to an ID (item->values[i].id),
not an index (item->values[i]), and it is always the next one, never the
current one.
Do the same change for _index/_idx variables in stats.c, which are used
as arguments to these functions. Replace rd_ with next_id_ in
stats_test.c, too.
Related: OS#5088
Change-Id: I5dd566b08dff7174d1790f49abd2d6ac020e120e
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 flag the API as deprecated so that people start using
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: If9b6b322989536a12094e6105c3aabc84d8be24a
This API wraps conventional gettid() linux-specific API, which even in
Linux itself is sometimes not properly supported/announced.
This API also allows future porting to other platforms if needed, and so
far falls back to getpid() if no gettid(9 can be found.
Code ported from osmo-trx.git, see commit 7a07de1efd4eb7cc11c33d3ad25cb2df70aa1ef1.
Related: OS#5027
Change-Id: Id7534beeb22fcd50813dab76dd68818e2ff87ec2
This adds an inter-thread queue "it_q" to libosmocore. With it_q,
one can perform thread-safe enqueing of messages to another thread,
who will receive the related messages triggered via an eventfd
handled in the usual libosmocore select loop abstraction.
Change-Id: Ie7d0c5fec715a2a577fae014b0b8a0e9c38418ef
In 'struct gsmtap_hdr' field 'snr_db' is defined as a signed integer,
however all functions that fill this structure accept an unsigned
integer. This is wrong, because SNR can be negative.
Let's use 'int8_t' instead of 'uint8_t'. Changing from unsigned
to signed should be relatively safe compared to the opposite.
Most of the callers I am aware of always do pass 0 anyway.
Change-Id: I9f432be5c346d563bf518111c14ff04d4a63f592
Related: SYS#5073
This function is called automatically on the main thread, but needs to
ba called explicitly in order to run the select loop on another thread.
Make it available for applications through talloc.h
Change-Id: Ie710ca9ad01d3fadb9f4ff344a55d6c01004727b
Neels Hofmeyr
Philipp Maier
Harald Welte
Sylvain Munaut
Vadim Yanitskiy
Oliver Smith
Eric Wild
Pau Espin
Neels Hofmeyr