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