aboutsummaryrefslogtreecommitdiffstats
path: root/tests
AgeCommit message (Collapse)AuthorFilesLines
10 daystests/testsuite.at: ensure empty stderr for the bitvec_testVadim Yanitskiy1-1/+1
The address sanitizer may print errors and warnings to stderr, and this was actually the case for bitvec_test before [1]: bitvec.c:492:24: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int' Change-Id: Ia82b92eddb18dc596881abcef2f098dc7385538b Related: [1] I4deeabba7ebb720cdbe7c85b37bc011d05bdfa65
10 daysbitvec_read_field(): fix incorrect bit-shift issue found by UBSanVadim Yanitskiy1-1/+1
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
10 daysbitvec_read_field(): indicate errors using errnoVadim Yanitskiy2-17/+18
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
11 daystests/tdef: rename the binaries to end with '_test'Vadim Yanitskiy7-21/+21
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
11 daystests/vty: fix use of GNU 'missing =' extension in designatorVadim Yanitskiy1-3/+3
Change-Id: I66edb247898594b51cc9d7c1b3d0c60ba66fc637
13 daysadd osmo_time_cc, moved from osmo-bscNeels Hofmeyr4-0/+1109
Related: SYS#4878 Related: Ica9f908a1a30f334a24c59471affa11225117e12 (osmo-bsc) Change-Id: Iabb17a08e6e1a86f168cdb008fba05ecd4776bdd
2021-11-09stats: clarify error messages in cfg_no_stats_reporter_{statsd,log}Vadim Yanitskiy1-0/+5
Change-Id: I287130213c7de31a510f293bed0f3daddd53ce04 Related: SYS#5713
2021-11-09stats: don't mark reporter as 'disable' beforehandVadim Yanitskiy1-14/+4
Change-Id: I330a079807cca48b7cc43767abcd2b58830a05fc Related: SYS#5713
2021-11-09stats: cosmetic: print 'stats interval' before the reportersVadim Yanitskiy1-1/+1
It's better to have the common parameters printed first. Change-Id: Ifb401d4d363fb70e89960ca739baba5ee55eefe8 Related: SYS#5713
2021-11-09stats: allow configuring reporter's name in the VTYVadim Yanitskiy1-4/+70
This allows configuring more than one reporter of the given type. Change-Id: Ia815c24dc974648985539913012b3b074ea317a9 Related: SYS#5713
2021-11-09stats: use llist_add_tail() in osmo_stats_reporter_alloc()Vadim Yanitskiy1-34/+34
This allows printing reporters in the exact order as they were configired. Change-Id: I904cd0ed53510dbe26c15cd287ba2707ca04cd6e Related: SYS#5713
2021-11-09tests/stats: add VTY transcript testsVadim Yanitskiy3-0/+255
Change-Id: I85ac73f4c866617179e55821a292aad33b6edc99 Related: SYS#5713
2021-10-26logging: Change stderr + file target to use non-blocking writeHarald Welte1-0/+1
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
2021-10-08ns2: message: BLOCK/BLOCK ACK allow to use a given NSVCI instead of using ↵Alexander Couzens1-1/+1
the nsvc nsvci 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
2021-09-30refactor stat_item: report only changed valuesNeels Hofmeyr2-6/+4
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
2021-09-30refactor stat_item: get rid of FIFO and "skipped" errorNeels Hofmeyr3-106/+124
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
2021-09-23ns2: nsvc: add a uptime/downtime to track the last state changeAlexander Couzens1-8/+8
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
2021-09-23ns2: nse: add a uptime/downtime to track the last state changeAlexander Couzens1-2/+2
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
2021-09-21osmo-auc-gen: Print RFC3310 IMS HTTP-AKA style base64 nonce/resHarald Welte1-0/+30
This is useful when debugging IMS Authentication which uses RFC3310 representation of the nonce and expected result. Change-Id: Ibfa72410d8ff8e5b42063f1a12bff69ad2bebbb8
2021-09-21base64: reformat using Lindent to conform to our coding styleHarald Welte1-32/+30
Change-Id: I2286fa0d2cba7c11359bb48329135dfcd0d8a948
2021-09-21base64: Migrate over to osmocomHarald Welte4-0/+70
This containts the osmocom changes to the mbedtls base64 code merged in the previous commit. Change-Id: I82c1bf5f827c8def370dbcb80b146e9e4184c4a3
2021-09-20stats_test: assert counter and stat item val counts separatelyNeels Hofmeyr2-57/+51
Instead of just a send_count, keep one such count for the counter updates, and a separate one for the stat item updates. Print those numbers in the test output. An upcoming patch will tweak stat_item reporting so that only an actually changed value results in sending a new stat value. This patch allows illustrating that change clearly. Related: SYS#5542 Change-Id: I2da003ee6ec15f1c3959efe69e01b4ee24af82bb
2021-09-12utils: add osmo_str_to_int() and osmo_str_to_int64()Neels Hofmeyr2-3/+316
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
2021-09-04gprs_ns2_sns: implement local change weight procedureAlexander Couzens1-1/+1
When changing the bind ip-sns weight, initiate a SNS CHANGE WEIGHT procedure to inform the other side. Related: OS#5036 Change-Id: Icec4dabb46bc198f68f91bfe09ba279fbe68d454
2021-08-20stats: send real last value if no new values comeOliver Smith2-1/+3
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
2021-08-20tests/stats: show how last item sent may be wrongOliver Smith2-0/+12
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
2021-08-19tests: add 'make update_exp' targetOliver Smith1-0/+179
Add convenience target to update the test output. Change-Id: I7247fffde82ab9195ae03b2ccb30d7aa47543113
2021-07-13gprs_ns2: ensure the NSE becomes dead when FR link went downAlexander Couzens2-0/+58
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
2021-07-06gprs_ns2_vty: dump_nsvc: change output depending on NSVCIAlexander Couzens1-8/+8
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
2021-07-06gprs_ns2: use gprs_ns2_free_bind() to clean up a bindAlexander Couzens1-0/+4
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
2021-07-02gprs_ns2: fix crash when changing the MTUAlexander Couzens1-2/+11
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
2021-06-25gprs_ns2: fix missing notify towards the NSE when NSVC become blockedAlexander Couzens2-0/+72
The NSE wasn't notified when a NSVC went into the BLOCKED state from an UNBLOCKED state. Related: OS#5182 Change-Id: I09634e414e9bb966e6b5809b7de1b59fbabd413d
2021-06-25gprs_ns2: use llist_add_tail to keep orderAlexander Couzens1-4/+4
When configuring multiple NSE/BINDs the order of the configuration should be keeped. Related: OS#5181 Change-Id: Ibbc03f0780b49543b5bd97ee059f11cfd6c2a126
2021-06-15ctrl: Pre-calculate required size before allocating msgbPau Espin Pedrol1-3/+6
This commit fixes crash when response is more than ~4096 chars. Furthermore, we now allocate only the required memory, not 4096 for all messages, which usually don't require it. Test needs to be adapted since it assumed there was more available space at the end of the msgb. Related: OS#5169 Change-Id: I0b8f370f7b08736207f9efed13a0663b5e482824
2021-06-04Use new stat item/ctr getter APIsPau Espin Pedrol2-46/+46
Generated with spatch: """ @@ expression E1, E2; @@ - &E2->ctr[E1] + rate_ctr_group_get_ctr(E2, E1) """ """ @@ expression E1, E2, E3; @@ - E2->items[E1] + osmo_stat_item_group_get_item(E2, E1) """ Change-Id: I41297a8df68e28dfc6016330ac82b0ed5dd0ebc1
2021-04-29ns2: Allow setting the socket priority for a UDP bindHarald Welte1-3/+3
Change-Id: Ifdfa086ce1c8d62b256abb3454b70cf53da9dcdb
2021-04-12vty/logging: logp: properly handle library specific sub-systemsVadim Yanitskiy1-0/+3
The library specific sub-systems are kind of special, because their position in the 'osmo_log_info' may vary depending on the number of application specific sub-systems. This is why their associated constant values (like DLGLOBAL) are negative, and this is what the LOGP() macro expects as the first argument. Before this change, invoking 'logp' command with any library specific logging sub-system would result in getting messages printed with the fall-back DLGLOBAL sub-systems. Change-Id: If86563e169fe1243adfa7b09c9d65d9f88c8a99e
2021-04-07stats: log error when missing stats values (v2)Oliver Smith2-0/+6
Related: SYS#4877 Change-Id: I5140d967c2f1d36dadf93b03e52b9bbd42e2a3a6
2021-04-07stats_test: restore stat_item_get_next assertsOliver Smith1-18/+18
This is a partial revert of b27b352e ("stats: Use a global index for stat item values"). Now that osmo_stat_item_get_next correctly returns how many values have been skipped, we can use the accurate asserts on its return value again. Fix the initial values of next_id_a,b (1 instead of 0), so we don't get a skipped value on the first read. This is needed, because b27b352e refactored osmo_stat_item_get_next to have the next id as parameter instead of the last read one, and the initial value was not adjusted in the tests. Related: OS#5088 Change-Id: I9d4cda2487a62f52361c24058363dfa90e502c63
2021-04-07stat_item: make value ids item specificOliver Smith1-15/+0
Fix counting of values missed because of FIFO overflow in osmo_stat_item_get_next(), by assigning a new item value id effectively as item->value[n + 1].id = item->value[n].id + 1, instead of increasing a global_value_id that is shared between all items and groups. With global_value_id, the count of values missed was wrong for one item, as soon as a new value was added to another item. This partially reverts b27b352e ("stats: Use a global index for stat item values") from 2015, right after stats was added to libosmocore. It was supposed to make multiple readers (reporters) possible, which could read independently from stat_item (and later added comments explain it like that). But this remained unused, stats has implemented multiple reporters by reading all stat_items once and sending the same data to all enabled reporters. The patch caused last_value_index in struct osmo_stat_item to always remain at -1. Replace this unused last_value_index with stats_next_id, so stats can store the item-specific next_id in the struct again. It appears that stats is the only direct user of osmo_stat_item, but if there are others, they can bring their own item-specific next_id: functions in stat_item.c still accept a next_id argument. Related: OS#5088 Change-Id: Ie65dcdf52c8fc3d916e20d7f0455f6223be6b64f
2021-04-07vty/logging: ensure consistent '%' prefix for warningsVadim Yanitskiy1-1/+1
Change-Id: I2b2bab61e46668c3b4b0ccad88d02b6d00a83544
2021-04-06stat_item: make next_id argument name consistentOliver Smith1-27/+27
Let osmo_stat_item_get_next, osmo_stat_item_discard, osmo_stat_item_discard_all consistently refer to their next_id arg as such (and not idx or next_idx). It refers to an ID (item->values[i].id), not an index (item->values[i]), and it is always the next one, never the current one. Do the same change for _index/_idx variables in stats.c, which are used as arguments to these functions. Replace rd_ with next_id_ in stats_test.c, too. Related: OS#5088 Change-Id: I5dd566b08dff7174d1790f49abd2d6ac020e120e
2021-03-31gprs_ns2: vty: remove a white space in `show binds`Alexander Couzens1-3/+3
Change-Id: Ia3579ec5599f5f5c58eebab03f1ed9e17f171177
2021-03-24gprs_ns2: dump_nsvc: correct indentionAlexander Couzens1-8/+8
As both `show ns entities` and `show ns binds` looking similiar correct the indention. Change-Id: I55794188bec7e62f0341188dbf23ac04006974fe
2021-03-24gprs_ns2_vty: make the `show ns entities` and `show ns binds` look similiarAlexander Couzens1-0/+2
`show ns binds` prints a count of NSVCs. Add the same line to `show ns entities`. Change-Id: I15c58a1c0fe94dda728afb29e7e5ca41e3fa8966
2021-03-24gprs_ns2: always use the same method to print NSVCsAlexander Couzens1-4/+4
The binds also print a list of associated NSVC when dumping the bind. However the binds using their own representation of printing the NSVC which is different to `show ns entities`. Use the same function to print NS-VC. Before: NSVCI 00000: udp)[127.0.0.1]:23000<>[127.0.0.1]:22000 After: NSVCI none: UNCONFIGURED DYNAMIC data_weight=1 sig_weight=1 udp)[127.0.0.1]:23000<>[127.0.0.1]:22000 Change-Id: If31ec6c1c07dc134ab1ddeb915bc89747c7be048
2021-03-24gprs_ns2: rework logging of Rx and Tx NS PDUAlexander Couzens1-28/+30
Introduce 2 new logging sub systems for signal and unit data. Unify log messages so all log messages look similiar. Log also Rx PDUs. Ensure dropped Tx packets (BLOCK/RESET on SNS) contain *Tx*. Change-Id: I34b8fde2955ecc010d1dcd9512e1bba9211e2c0d
2021-03-24gprs_ns2_vty: Allow creating NSE in sgsn-roleHarald Welte1-1/+1
Change-Id: I694fa6c80d04d13cb1afaae93a9ae43b6dfd2207 Related: OS#3373
2021-03-19Revert "stats: log error when missing stats values"Oliver Smith2-151/+0
This reverts commit d290439b4afe928e7e341540cb92f1abf36a82cb, which caused "stats values skipped" messages to appear even if they were not skipped. Revert for now, replace with a proper version in the future. Related: SYS#4877 Change-Id: Ib43bd53188a4d31d771feb921ea14abe1a3ec877
2021-03-18tlv: Fix length returned by t{l16,16l}v_putDaniel Willmann1-0/+32
Every other function returns a pointer to the first byte after the tlv that was just written. tl16v seems to be a copy and paste error from tlv16 above and t16lv seems to count the 16-bit tag twice. The new tests verify that the return value of *_put(buf, tag, len, val) points to buf + *_GROSS_LEN(len). Change-Id: I268a7e11fb5dce67ce1bd7974ab86c4d2bd002f7