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
While at it, drop 8-1 in favour of 7. I don't think it is really more
understandable for readers to see some subtraction there...
Change-Id: I8b21eba9b9aa952f86abe7a6d4cdb1d1a61d9deb
This reverts commit a4063efa7d.
Reason for revert: It is not possible to guess the IP address
family from uninitialized memory. This function simply glorifies
random noise into an IPv6 address. It makes no sense to have it.
Change-Id: Ifadd614604cf9d0c2ed1a405493c1c3fcb37ae23
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
Sometimes we receive generic "struct sockaddr" with unspecified (AF_UNSPEC)
address family. It's handy to try to guess
the proper address (there're just 2 variants ATM in most practical applications).
Use the added function to relax input checks in osmo_sockaddr_str_from_in*()
Related: OS#5581
Change-Id: I1c90c56ce832f53b65e0d18d3cea94621c02a69a
Whenever iterating over a list and removing entries,
llist_for_each_entry_safe must be used instead of llist_for_each_entry.
The comment with "non-consecutive(!)" entries sounds like this is not
needed as long as one is iterating over the list consecutively. I guess
that might have worked with prefetch logic, however the prefetch
function is just a stub in linuxlist.h. (Also prefetch has been removed
from list.h in linux.git e66eed651fd18a961f11cda62f3b5286c8cc4f9f.)
Change-Id: I217e6871afe121edba26e4c6fd1a461e397c9e72
Theoretically, this should improve performance of the code where
we frequently invoke OSMO_ASSERT(), like osmo-msc and osmo-bsc.
Change-Id: I29b32a2477ec92762f8f0ce5e5c5a30810f6abbe
Using do-while is a common practice for complex macros. This allows
invoking OSMO_ASSERT in simple if-else statements without braces.
Change-Id: I42d9c315c9c30bce828564a63c496ee62e5c1431
These macros are built on top of the __builtin_expect() function [1],
which provides the compiler with branch prediction information.
Similar macros exist in the Linux kernel: likely() / unlikely().
[1] https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
Change-Id: I0b029654ba050f079eed4a0574a3fa8019677067
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
Max
Vadim Yanitskiy
Pau Espin
Neels Hofmeyr
Harald Welte
Oliver Smith
Philipp Maier
Sylvain Munaut
Eric Wild