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
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
Extend the test to illustrate the bug described in the related issue,
which will be fixed with the next patch.
Related: OS#5215
Change-Id: I1d26867ac1b837bea6a9754a3203e53c147e7a5f
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
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
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
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
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
When the MTU changes for any fr device, all
NSE will recalculate their MTU. If any NSE is alive,
libosmocore will crash.
Related: OS#5192
Change-Id: I31ba5cefea7bbb0b74060d6664b42c58815ee2a1
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
Alexander Couzens
Pau Espin
Philipp Maier
Oliver Smith
Daniel Willmann