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
Without this header, both OSMO_IS_{BIG,LITTLE}_ENDIAN macros are
not defined, and thus the 'struct gsm_sacch_l1_hdr' is empty.
Change-Id: I2c14a1b898fdb743191dab0e6be157ce916e8161
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
This change adds new [bit-]fields in order to allow:
* selectively enabling SACCH and/or FACCH,
* setting the RxQual (BER) threshold.
Change-Id: Ia28293a12de0af71f55e701fb65c46e905dae217
Related: SYS#5319
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
vty_out_uptime() calculates the time difference to a given timespec
and print it in a human readable format (days, hours,
minutes, seconds) to the vty.
Related: OS#5028
Change-Id: I264a3f49096b96646e0a1f5366623ac20d860793
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
It was so far sufficient to wait for the buffers to drain at some
random point in time, but this is not always the case, sometimes it is
important that the output is flushed immediately.
Change-Id: If984b9ad2eba9f400bc29a7aa8825e241fd1d2a9
This commit adds new Osmocom specific IEs required to pass C/I related
Power Control Parameters osmo-bsc => osmo-bts to be used by the MS Power
Control Loop being implemented.
Related: SYS#4917
Change-Id: Iffef0611430ad6c90606149c398d80158633bbca
To indicate to the BSC that a BTS supports temporary overpower of
SACCH/FACCH channels a new feature BTS_FEAT_ACCH_TOP is added.
Change-Id: I62fbfc30acd5d67b20727b75a8f256e6b5d31e06
Related: SYS#5319
To transfer the temporary overpower value from the BSC to the BTS, a new
RSL IE (RSL_IE_OSMO_TOP_ACCH_CAP) is added.
Change-Id: I31c5be4bceb9140d63ab8e2f197f0acc68699426
Related: SYS#5319
We have value strings for osmo_amr_type, but we do not have a function
that returns us the strings.
Change-Id: I694f56b032537440db6264df5e6a6aa3a2992175
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
Add one more tab between the define and the port number, to prepare for
longer defines in the next patch.
Related: OS#5203
Change-Id: I46655e33651814f41a1fea93406a83334d2fc529
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
This feature signals support to configure Osmocom Dynamic Timeslot type
as SDCCH8, on top of historically supported TCH/H and TCH/F.
The idea is that when unneeded, the TS is configured as PDCH, and as
soon as there's need for an SDCCH and there's none available, the TS is
dynamically reconfigured to SDCCH8. Once all logical channels in the
dynamic TS are released and hence becomes free, the BSC will reconfigure
it to PDCH.
Related: SYS#5309
Change-Id: Ifc0ca8916bd3e93e5a60a7dd7391d2588fdb5532
They will gain support to be activated as SDCCH/8 soon too. Since new
name would start to be too large, use a more generic naming for it.
Related: OS#5309
Change-Id: I56dcfe4d17899630b17f80145c3ced72f1e91e68
Prepare for A5/4 support in osmo-msc.
Add new function gsm0808_create_cipher2() which takes a struct as
argument instead of individual fields. This is akin to e.g.
gsm0808_create_handover_request() below in the file, and allows
backwards compatibly extending the argument list without needing a new
function signature every time.
Add struct gsm0808_cipher_mode_command, as argument list for
gsm0808_create_cipher2(), with kc128 included.
Encode the Kc128 IE in gsm0808_create_cipher2().
Implement gsm0808_create_cipher() by calling gsm0808_create_cipher2().
Change-Id: Ib3906085e0c6e5a496a9f755f0f786238a86ca34
Certain control interface commands also may require to verfy a range in
their verify function. cmd_range_match() from the VTY does exactly that
and the range can be specified as string, the same way as we would
specify it in the VTY.
Change-Id: I53fc207677f52b1dc748b01d58424839cdba807c
related: SYS#5369
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 feature provides the BSC with information on whether the BTS talks
the IPAC_PROTO_EXT_PCU osmocom extension over the underlying IPA
multiplex of the OML link.
Related: SYS#5303
Change-Id: Id62421f7f5540875ac877a187757f2cf0556bd02
Oliver Smith
Eric Wild
Harald Welte
Neels Hofmeyr
Alexander Couzens
Vadim Yanitskiy
Pau Espin
Keith Whyte
Philipp Maier