Just like rate_ctr_group_free, osmo_stat_item_group_free should tolerate
it when the argument is NULL
Change-Id: I23323833e7268356a50c4fc6a19639c4ecd2a101
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
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
This kind of API will likely cause memory leaks in case the caller fails
to check the return value of the function and knows he must free the
message.
Change-Id: I7e61c19d32a75e28f08b74a8e3d9d63a2d8bf3d7
Related: OS#5329
In case osmo_wqueue_enqueue_quiet() fails, msgb ownership is not
transferred to the queue, but the caller is responsible for freeing
the message buffer that we just failed to enqueue.
Change-Id: I6306e34dc7289864c889e72adf31d74d4581a810
Closes: OS#5328
Related: OS#5329
The log message is very confusing if printed for PtP-BVCI as well. Move
it into the correct if branch.
Change-Id: I0359443ddc52108b492f741005c4699e06b40183
gcc complains because our char might or might not be signed depending on
arch and phase of the moon:
error: array subscript has type 'char' [-Werror=charsubscripts]
Change-Id: I7c76f9a2318c4f0e5eedeea00ec380824b86567e
The bitvec_read_field() is used in performance critical places,
such as the CSN.1 decoder in osmo-pcu. Thus the less conditional
statements we have in the parsing loop, the better.
The bitvec_get_bit_pos() alone is quite a complex function, which
does check the boundaries and even supports the L/H syntax. Even
if it gets inlined by the compiler, we don't really want to run
redundant checks and run bitval2mask() on each iteration.
Change-Id: I438fc82d33ab2edbabd4215ec7bc46afb07d50ab
While running a sanitized version of the bitvec_test I get:
bitvec.c:492:24: runtime error: shift exponent 64 is too large
for 64-bit type 'long unsigned int'
This error is triggered by the following line in the bitvec_test:
_bitvec_read_field(0, 8 * 8 + 1); /* too many bits */
which basically tries to parse more bits (65) than the test vector
actually has (64). The problem is that we don't check if the
given vector has enough data *before* entering the parsing loop,
so we end up doing weird bit-shifts and getting weird values:
bitvec_read_field(idx=0, len=65) => bd5b7ddffdd7b5db (error)
Unfortunately, this problem remained unnoticed so far because in
'tests/testsuite.at' we don't check if stderr is empty. This is
fixed in a follow up change [1].
Rather than checking for errors in every loop iteration, do this
once and return early if the overrun is possible with the given
offset and length arguments.
Change-Id: I4deeabba7ebb720cdbe7c85b37bc011d05bdfa65
Related: [1] Ia82b92eddb18dc596881abcef2f098dc7385538b
This function returns an *unsigned* integer (uint64_t), so returning
a negative value on error is a bad idea. A negative value turns into
a huge positive value, what was demonstrated in the bitvec_test:
bitvec_read_field(idx=512, len=16) => ffffffffffffffea
bitvec_read_field(idx=0, len=65) => ffffffffffffffea
bitvec_read_field(idx=64, len=16) => ffffffffffffffea
The 0xffffffffffffffea above is basically:
(uint64_t) -EINVAL, or
(uint64_t) -22 + 1, or
0xffffffffffffffff - 0x16 + 1.
Let's make use of the errno in order to indicate an error to the caller.
Change-Id: I2cc734caa3365d03c2ae2b3f2cd9544933c25e9e
Related: OS#4388
It's the usual naming for unit test binaries. Without the '_test' endig,
the tdef_vty_test_{config_root,config_subnode,dynamic} binaries do not
match the 'tests/*/*_test' pattern and appear as untracked files in git.
Change-Id: I828fa45132e11a41c527d4b25df850c19871cb75
There might be library code that has rate counters, and if the main
program calls rate_ctr_init() a second time, we can skip the second
initialization.
Change-Id: I6f5342a77518599eb5ac9a0f0605917a78fcc387
alive_timeout_handler() changes the state to RECOVERING which calls
ns2_st_alive_onenter()->ns2_nse_notify_unblocked(unblocked=false)->
ns2_sns_notify_alive(unblocked=false)
When all (signalling) NSVCs have failed and gss->role is SGSN and not
persistent sns_failed() calls gprs_ns2_free_nse() which talloc_free()s
the nse before returning.
The next line in ns2_nse_notify_unblocked() tries to read nse->alive which then causes the
use-after-free.
Change-Id: I0486a77fd3e21fd3904bd19e4e0225ffbf654935
Related: OS#5302
Recent commit introduced the "blocking-io" param to "log stderr" VTY
command, which calls log_target_file_switch_to_{stream,wqueue}.
The VTY command already locks the log_tgt_mutex mutex, since it has to
access the tgt list. However, the functions mention above also want to
lock the same mutex in order to log information. Let's drop the logging
to avoid the double lock, and update its documentation to mention it
must be called with the lock already held, as documented on other
similar functions.
The issue can be spotted when running osmo-trx-uhd:
"""
(gdb) bt
#0 0x00007ffff75d7600 in __lll_lock_wait () from /usr/lib/libpthread.so.0
#1 0x00007ffff75d0503 in pthread_mutex_lock () from /usr/lib/libpthread.so.0
#2 0x00007ffff66314fb in log_tgt_mutex_lock_impl () at /git/libosmocore/src/logging.c:130
#3 0x00007ffff6638e74 in log_check_level (subsys=8, subsys@entry=-1, level=level@entry=3) at /git/libosmocore/src/logging.c:1510
#4 0x00007ffff6639c91 in log_target_file_switch_to_wqueue (target=target@entry=0x611000000320) at /git/libosmocore/src/logging.c:1186
#5 0x00007ffff68565d3 in cfg_log_stderr (self=<optimized out>, vty=0x6140000018a0, argc=0, argv=<optimized out>) at /git/libosmocore/src/vty/logging_vty.c:859
#6 0x00007ffff683db3d in cmd_execute_command_strict (vline=0x60b0000dfe80, vty=vty@entry=0x6140000018a0, cmd=cmd@entry=0x0) at /git/libosmocore/src/vty/command.c:2768
7 0x00007ffff683e396 in config_from_file (vty=vty@entry=0x6140000018a0, fp=fp@entry=0x615000036400) at /git/libosmocore/src/vty/command.c:2880
8 0x00007ffff684cedb in vty_read_config_filep (confp=confp@entry=0x615000036400, priv=priv@entry=0x0) at /git/libosmocore/src/vty/vty.c:1529
9 0x00007ffff684ebfc in vty_read_config_file (file_name=0x7fffffffe7d8 "/build/new/conf/osmo-trx-uhd.cfg", priv=0x0) at /git/libosmocore/src/vty/vty.c:1920
10 0x0000555555565270 in main (argc=3, argv=0x7fffffffe3c8) at /git/osmo-trx/Transceiver52M/osmo-trx.cpp:652
"""
Debugged by rebuilding libosmocore with "LOG_MTX_DEBUG 1":
"""
/libosmocore/src/logging.c:1510 [log_check_level] lock
/libosmocore/src/logging.c:1522 [log_check_level] unlock
/libosmocore/src/vty/logging_vty.c:844 [cfg_log_stderr] lock
/libosmocore/src/logging.c:1510 [log_check_level] lock
"""
Fixes: b72867f0e6
Related: OS#4311
Change-Id: Idb4215fa2f364e28c0bb73fb9975b6c9f50a46f6
In the old days, we performed synchronous, blocking writes to the log
file or stderr. This was replaced by code that turned all log
file/stderr writes into non-blocking writes behind a write_queue.
This patch now introduces a further optimization: If we currently
don't have any log messages pending in the write queue, we are not
back-logged and assume we have a fair chance of writing the log message
right now, synchronously. So we try that first, and only enqueue
the log message if the write fails (no bytes or insufficient number
of bytes written).
This way we should get the best of both worlds: No delay/re-ordering
(and lower select syscall load) for the "normal" case (benefits of
the old synchronous writes) while at the same time never risking to
block on log output.
Related: OS#4311
Change-Id: I08469a7e4be9bc5bbd39140457bb582f4a0b1703
For file and stderr output, the existing code always generates
the log string on a stack buffer, and then (in case of non-blocking
write via write_queue) copies it over to a msgb.
Let's optimize this by turning _file_output() into a raw_output
callback which first allocates the msgb and then format-prints
directly to that msgb instaed of stack + memcpy.
This has the disadvantage that we don't know how long the buffer
has to be in order to print the entire string to it. As a result
we always have to allocate a 4k-sized buffer (plus msgb overhead).
The write_queue length for log file output has been decreased from
1024 entries to 156 entries in order to stay within the same
memory requirements for each log target memory pool (about 648 kBytes).
Related: OS#4311
Change-Id: I0d10b0199576d2e7ff6421a6dba19ae5ffafd946
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
Previous dark shiny blue one is really difficult to read on the
terminal. Let's change it for some purpleish color which is far easier
to read.
Change-Id: Ia5c0860dd8d756bb24eb8972f94590bfba5bc865
BLOCK PDU can be send over a different NSVC than the NSVC.
E.g. informing a NSVC got blocked in case of a lower-layer failure.
Change-Id: I483e3a1d3b8c43bbb0cc6185b7f7f772bcb264bf
When receiving an invalid RESET (e.g. wrong NSEI or NSVCI) do not
forward the PDU to the NSVC fsm. Answer it with correct NSEI & NSVCI,
log the PDU, then ignore it.
Fixes: OS#5258
Change-Id: I6e562def9c5a1e4534d42884215272b1e66d26c2
STATUS PDU can be send over a different NSVC than the NSVC which
generated the STATUS PDU. E.g. informing a NSVC got blocked in case of a lower-layer failure.
Change-Id: I5c9e9de10c669c1226da67bb9e2663c5cfe828a8
To answer correct on a BLOCK PDU with a different NSVCI, the
STATUS PDU needs also a NSVCI parameter.
Change-Id: I373eb48697097cdfa45748a091c11f7b3f0345fa
The BLOCK and BLOCK ACK PDUs can be send over a working NSVC to inform
the NSE that a NSVC is blocked.
Change-Id: I6189229fdc1f054e86811bc60cb7646e1f758a78
Even if not bound to a IF they just exist and work as expected, and make
distinguishing traffic for local setups easy.
Change-Id: I1043dfd8075f14481011f43db45c943e9320413c
The buffer is allocated dynamically on heap, so there is no such
limitation of 4096 bytes / 1365 characters.
Change-Id: I960dd6a53123fd4209ef6e61dcd0d22e4005e397
Replace some with atoi(), where the VTY has already validated correct
range of the argument.
Replace others with the new osmo_str_to_int() or osmo_str_to_int64()
functions, possibly covering more detection of invalid number strings.
Leave those strtol() callers that depend on endptr to provide the next
string token.
Related: SYS#5542
Change-Id: I0ebb06e751c28f7d1cdf328de29cd227a2449391
20 bytes is not enough for some VAMOS specific channel number values,
so the resulting string representation gets truncated by snprintf():
expected: "VAMOS TCH/H(0) on TS4\0"
actual: "VAMOS TCH/H(0) on T\0"
Let's enlarge the buffers to 32 bytes.
Change-Id: I68d839f4ab742cf56de34e7e22572a1163aec2da
Change the functionality of skipping unchanged values: instead of
looking up whether new values have been set on a stat item, rather
remember the last reported value and skip reporting identical values.
stats_test.c shows that previously, a stat item reported a value of 10
again, even though the previous report had already sent a value of 10.
That's just because the value 10 was explicitly set again, internally.
From a perspective of preserving all data points, it could make sense to
send consecutive identical values. But since we already collapse all
data points per reporting period into a max, that is pointless.
Related: SYS#5542
Change-Id: I8f4cf34dfed17e0879716fa2cbeee137c158978b
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
To show adminstrator the last state change of a nsvc add a timestamp and
show it on the vty
> show ns nsei 1234
NSEI 01234: UDP, DEAD since 0d 0h 1m 42s
[...]
4 NS-VC:
UNBLOCKED DYNAMIC sig_weight=1 data_weight=1 udp)[127.0.0.1]:22000<>[127.0.0.1]:23001 ALIVE since 0d 0h 0m 1s
UNBLOCKED DYNAMIC sig_weight=2 data_weight=2 udp)[127.0.0.1]:22000<>[127.0.0.1]:23000 ALIVE since 0d 0h 0m 1s
UNBLOCKED DYNAMIC sig_weight=2 data_weight=2 udp)[127.0.0.1]:22001<>[127.0.0.1]:23000 ALIVE since 0d 0h 0m 1s
UNBLOCKED DYNAMIC sig_weight=1 data_weight=1 udp)[127.0.0.1]:22001<>[127.0.0.1]:23001 ALIVE since 0d 0h 0m 1s
Related: OS#5028
Change-Id: Ie3a039a209869295afa5feda39297cee81fedf22
To show adminstrator the last state change of a nse add a timestamp and
show it on the vty
> show ns nse 1234
NSEI 01234: UDP, ALIVE since 0d 0h 0m 16s
FSM Instance Name: 'GPRS-NS2-SNS-SGSN(NSE01234-SNS)[0x6120000012a0]', ID: 'NSE01234-SNS'
Log-Level: 'DEBUG', State: 'CONFIGURED'
Timer: 4
Maximum number of remote NS-VCs: 8, IPv4 Endpoints: 2, IPv6 Endpoints: 0
[...]
Related: OS#5028
Change-Id: I8143080a3c5c9a55d37dfad44ba2ac6561daa216
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
Expose all stat items as RO variables of the form
stat_item.last.group_name.N.item_name
stat_item.last.group_name.by_name.idx_name.item_name
For (possibly contrived) example:
stat_item.last.trunk.0.endpoints:used
stat_item.last.trunk.by_name.virtual-0.endpoints:used
Include the 'last' token to ease future extension, like 'max'.
Put this token in the beginning, similarly to rate_ctr variables, which
begin with 'per_sec', 'per_hour', ...
Related: SYS#5542
Related: I178dcf4516606aa561d47b06061b8a416d3c40cf (osmo-ttcn3-hacks)
Related: Ic1b35b7406547f92818afe399a2383d154576409 (osmo-ttcn3-hacks)
Change-Id: Idace66b37492fe96b2f2e133a69cac7960ca279c
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
A STATUS PDU with cause code NSVC UNKNOWN/NSVC BLOCKED informs the other
side about a state mismatch between the side.
Change-Id: Ib6a2424f3027a30f14ef0a9fc2230e6aae9a2a04
The ns2_vc_force_unconfigured() needs to be protected otherwise it would free
gss->nsvc which will be used later. It further would run into another
SNS failure which is wrong too.
Change-Id: If14b9e3fcd5d139457b10d06517302168091d8d8
Previous the SNS NSVC (the NSVC used for all SNS traffic) was never changed except
when the choosen NSVC went dead or got freed.
When receiving a SNS SIZE PDU over a different NSVC than the current SNS
NSVC the answer would be transmitted to a different port.
Change-Id: I36cd9488b8bca5cb99dae5cf50a55ee282e0557b
When no remaining signalling NSVCs are available the SNS must be
restarted (BSS) or go into unconfigured state (SGSN).
Change-Id: I95e6bbb7a418d647a8426804879571597ae06ff8
When cleaning up the SGSN side (e.g. receiving a SNS SIZE PDU) the
clean up will result in a use-after-free bug when the SGSN side is still
alive.
Change-Id: I0f57dd0577d1fc7bd270f58e15f6f22eb130ef59
When removing a bind the remote side needs to be
informed via the SNS DELETE procedure.
Related: OS#5036
Change-Id: I53cd54dfd262c70c425c3f13dad3b29526daa523
When adding a bind, the remote side needs to be
informed via the SNS ADD procedure.
Related: OS#5036
Change-Id: I71c33200bd1f0307ceb943ee958db5ebe3623d36
When changing the bind ip-sns weight, initiate a
SNS CHANGE WEIGHT procedure to inform the other side.
Related: OS#5036
Change-Id: Icec4dabb46bc198f68f91bfe09ba279fbe68d454
The problem are recursive execution because a free generates an event which could
allow the use to free a nsvcs while the llist_for_each() is still running.
Change-Id: I902557fb6e56e6588728a46e43a9cbe3215d5c68
When removing NSVCs before removing the bind from the SNS list, the removing NSVCs could
trigger a creation of a new NSVC on the same bind ending in a
while(true) loop.
Change-Id: I6f497348f75fb479427d8a4c23313e33fbc62036
Otherwise there could be recursive loop when free'ing NSVCs which
in the end create an event which the SNS want to free the NSVCs a
second time
Change-Id: Ie99ba5fe8a84519fe8a8c0abdf875606715ab7f6
Move the cleanup into it's own state. Also changing the
SGSN unconfigured state which won't be triggered when a
SIZE is received.
Change-Id: I2639345fdf3cd300a934238d676c543065ceaa8b
When other parts of ns2 requires to emit an event to the SNS fsm it would
need a proxy function because the events are private to the
SNS file. To circumvent creating multiple proxy function make the events
available via a header file.
Change-Id: I8e3fae4367c112b5a71bffb33c302d903855cddc
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
The encoder function gsm0503_tch_ahs_encode uses gsm0503_afs_ic_ubit
when encoding the CMR or FT (depends on the frame number). This is not
correct. It should use gsm0503_ahs_ic_ubit instead.
Change-Id: Id250b2102ac79ff222bd3ad9d1abc4b60abdd12b
Related: SYS#5549
Exempt all stat_item statistics from 'stats reset'. Only reset rate_ctr
statistics to zero.
The rate_ctr statistics have an implicit time scale, counting occurences
per time unit. For them it makes sense to reset all ratings and start
from zero, for example in a test suite (e.g. our TTCN3 BSC_Tests).
In contrast, stat_item statistics count number of objects or nr of
specific object stati at any given time, and they do not deteriorate
over time. Many stat items depend on increment/decrement to be sane.
For example, in osmo-bsc, if the nr of connected BTS is 3, that does not
make sense to be reset to zero. There are still 3 BTS connected, only
the stat_item would suddenly reflect zero. From then on, it'd be wrong.
All stat_items are by definition wrong after a 'stats reset'.
- Those that depend on increment/decrement will be wrong until the
program exits, and
- those that are set to absolute values will be wrong up until the next
value is set. That could be seconds or hours later, depending.
Related: SYS#5542
Change-Id: If2134768b1076e7af189276c45f2a09a4944303e
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
When free'ing a NSE/NSVC/BIND ensure there can't be a double
free by using a free anchor in the struct.
Recursive free's can happen when the NS user reacts on an event
(e.g. GPRS_NS2_AFF_CAUSE_VC_FAILURE) and calls the free().
Or when the user free's a NSVC when the NSE uses SNS as configuration,
the fsm tries to free it again.
Change-Id: If9823aadaa936e136aa43e88cee925ddd5974841
The SGSN fsm should be freed when becoming invalid instead of going
into the unconfigured state. The unconfigured states should be only used
when creating the NSE (on the SGSN side).
Change-Id: Ife889091ecba4180a90743deb786767008fe863d
The SNS code will always create NSVC on it's own. The only case
when the SNS dialect allows dynamic NSE/NSVC is on the SGSN side when accepting
dynamic NSE and receiving the first SNS SIZE. In this case the NSVC FSM must not be started yet.
Prevents sending NS_ALIVE before the SNS configuration has been
finished.
Change-Id: I86275c99432262b3c19c1ded9a77090b74303bc8
Use ANSI escape characters to clear the screen with ^L, like it works
in typical Linux shells. I always found it slightly inconvenient that
this didn't work in the VTY.
Change-Id: Ie2356cd92f39b4dc28b5c20bbe4557fb0d972747
Some tests under osmo-pcu (TbfTest) were caught accessning NULL pointer
bssgp_nsi in bssgp_tx_llc_discarded triggered by timeout while stepping
slowly with the debugger.
It seems that test is not properly using neither the old nor the new
API. Let's catch such cases easily.
Change-Id: I3ea42755c4bfd29e4a01ad57f186f28d58ab466a
After my system's gcc was upgraded, I get false positivies in a couple
places. Let's initialize those to make gcc happy.
"""
/git/libosmocore/src/socket.c: In function ‘osmo_sock_init’:
/git/libosmocore/src/socket.c:958:25: error: ‘sfd’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
958 | close(sfd);
| ^~~~~~~~~~
/git/libosmocore/src/gsm/gsm48.c: In function ‘osmo_mobile_identity_decode’:
/git/libosmocore/src/gsm/gsm48.c:690:20: error: ‘str_size’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
690 | if (rc < 1 || rc >= str_size) {
| ~~~~~~~^~~~~~~~~~~~~~~~~
/git/libosmocore/src/gsm/gsm48.c:679:22: error: ‘str’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
679 | rc = osmo_bcd2str(str, str_size, mi_data, 1, 1 + nibbles_len, allow_hex);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"""
Change-Id: I8aacfbc21e23f63a65e8baee3fd536a1fe1bdd8a
Kill programs with SIGTERM with the new vty command, as it would happen
with "systemctl stop".
I've considered running the select shutdown logic too in order to ensure
that pending OSMO_FD_WRITE requests are serviced. But as noted in
review, it's better to ensure that the regular SIGTERM code path works
as expected and call that instead of introducing an alternative code
path.
Closes: OS#4609
Change-Id: I3596a35b0f4a24e49484ec3f24a98e4d4f583e1e
The FR code is using force unconfigured to change the state of the NSVC
when the FR link goes down. The force unconfigured state didn't
notified the NSE when changing into this state.
Related: SYS#5533
Change-Id: I4d7bbbbce26f7cde99eebe96995c50b1e812e5bd
The implementation cleary replaces sep_chars instead of keeping them.
Adjust the doc to clarify that.
It seems to me that the intention was to *allow* sep_chars instead of
replacing them, especially when looking at sep_chars of
osmo_separated_identifiers_valid(). But we're stuck with that now.
Change-Id: Ia842a7eeb46b49ee364be55c1194e463ebcaf392
If the NSVCI is valid, there is no signalling or data weight defined (internally this is 1).
For NSVC with NSVCI don't print the signalling or data weight.
For NSVC without NSVCI, don't print NSVCI at all.
Related: OS#5180
Change-Id: Iaadc806a9136436468e2b02eb0bc1f4570a10ecc
gprs_ns2_free_bind() takes care of all required steps to clean up a bind.
The driver->free_bind() operation only cleans up the driver internal state
but not NSVCs and other generic things.
Fixes a crash when free'ing a bind from the vty which has active NSVCs.
Related: OS#5195
Change-Id: I0a2ad22905bcacb929b9b5f5b034af0da3081826
The log line should describe what's reported towards the NS user
and not the NSE MTU itself
Related: OS#5192
Change-Id: I3f5445a1ba8c89c4023ff48be15a80569a128528