aboutsummaryrefslogtreecommitdiffstats
path: root/tests
AgeCommit message (Collapse)AuthorFilesLines
18 hoursdebian, utils: switch to python 3HEADmasterOliver Smith1-1/+1
Make build and external tests work with python3, so we can drop the python2 dependency. This should be merged shortly after osmo-python-tests was migrated to python3, and the jenkins build slaves were (automatically) updated to have the new osmo-python-tests installed. Related: OS#2819 Depends: osmo-python-tests I3ffc3519bf6c22536a49dad7a966188ddad351a7 Change-Id: I84ef43f700e125c7a65f92347f12844e07e65655
4 daysgsup: Introduce OSMO_GSUP_NUM_VECTORS_REQ_IEHarald Welte3-0/+17
This is a bit of a hack, as we want to maintain binary compatibility without breaking existing users of libosmocore. To do so, we use the 'num_auth_vectors' field in two ways now: * In the existing use case as part of SEND_AUTH_INFO_RESPONSE, it indicates the number of vectors stored in the 'auth_vectors' field * In the new use case as part of SEND_AUTH_INFO_REQUEST, it indicates the number of vectors actually requested by the MSC/SGSN/MME. Change-Id: Iaecc47280f8ce54f3e3a888c1cfc160735483d0f
12 daysCheck for osmo_fsm_register() error return valueHarald Welte4-4/+4
Change-Id: Idbc1557739b2a253b73914e6f1f18a6d169d882e
2019-11-24add osmo_escape_cstr and osmo_quote_cstrNeels Hofmeyr2-4/+204
Provide string escaping that - returns the required buffer size, so it can be used with OSMO_STRBUF_APPEND(). - uses C compatible string constant escaping sequences. This is intended as a replacement for all previous osmo_escape_str* and osmo_quote_str* API. It pains me that I didn't get them right the first nor the second time: - The buffer functions do not return the chars needed, which is required for allocating sufficient memory in the *_c versions of the functions. - Because of that, these functions are accurately usable for OSMO_STRBUF_APPEND(), producing truncated strings, for example when dumping a GSUP message. - They do not use the C equivalent string constant escaping: for some reason I thought "\15" would be valid, but it should be "\x0f". If I could, I would completely drop those mislead implementations ... but backwards compat prohibits that. A previous patch already provided internal static functions that accurately return the required buffer size. Enhance these to also support C compatible string escaping, and use them as implementation of the new functions: osmo_escape_cstr_buf() osmo_escape_cstr_c() osmo_quote_cstr_buf() osmo_quote_cstr_c() In the tests for these, also test C string equivalence. Naming: from API versions, it would be kind of logical to call them osmo_escape_str_buf3() and osmo_escape_str_c2(). Since these anyway return a different escaping, it makes sense to me to have distinct names instead. Quasi missing are variants of the non-C-compatible weird legacy escaping that return the required buffer size, but I refrain from adding those, because we have enough API cruft as it is. Just always use these new cstr variants. Change-Id: I3dfb892036e01000033dd8e7e4a6a0c32a3caa9b
2019-11-24vty: track parent nodes also for telnet sessionsNeels Hofmeyr1-16/+0
Keep track of parent nodes and go back hierarchically, not only for .cfg file reading, but also for telnet VTY sessions. A long time ago cfg file parsing was made strictly hierarchical: node exits go back to parent nodes exactly as they were entered. However, live telnet VTY sessions still lacked this and depended on the go_parent_cb(). From this commit on, implementing a go_parent_cb() is completely optional. The go_parent_cb() no longer has the task to determine the correct parent node, neither for cfg files (as already the case before this patch) nor for telnet VTY sessions (added by this patch). Instead, a go_parent_cb() implementation can merely take actions it requires on node exits, for example applying some config when leaving a specific node. The node value that is returned by the go_parent_cb() and the vty->node and vty->index values that might be set are completely ignored; instead the implicit parent node tracking determines the parent and node object. As a side effect, the is_config_node() callback is no longer needed, since the VTY now always implicitly knows when to exit back to the CONFIG_NODE. For example, osmo_ss7_is_config_node() could now be dropped, and the osmo_ss7_vty_go_parent() could be shortened by five switch cases, does no longer need to set vty->node nor vty->index and could thus be shortened to: int osmo_ss7_vty_go_parent(struct vty *vty) { struct osmo_ss7_asp *asp; struct osmo_xua_server *oxs; switch (vty->node) { case L_CS7_ASP_NODE: asp = vty->index; /* If no local addr was set */ if (!asp->cfg.local.host_cnt) { asp->cfg.local.host[0] = NULL; asp->cfg.local.host_cnt = 1; } osmo_ss7_asp_restart(asp); break; case L_CS7_XUA_NODE: oxs = vty->index; /* If no local addr was set, or erased after _create(): */ if (!oxs->cfg.local.host_cnt) osmo_ss7_xua_server_set_local_host(oxs, NULL); if (osmo_ss7_xua_server_bind(oxs) < 0) vty_out(vty, "%% Unable to bind xUA server to IP(s)%s", VTY_NEWLINE); break; } return 0; } Before parent tracking, every program was required to write a go_parent_cb() which has to return every node's parent node, basically a switch() statement that manually traces the way back out of child nodes. If the go_parent_cb() has errors, we may wildly jump around the node tree: a common error is to jump right out to the top config node with one exit, even though we were N levels deep. This kind of error has been eliminated for cfg files long ago, but still exists for telnet VTY sessions, which this patch fixes. This came up when I was adding multi-level config nodes to osmo-hlr to support Distributed GSM / remote MS lookup: the config file worked fine, while vty node tests failed to exit to the correct nodes. Change-Id: I2b32b4fe20732728db6e9cdac7e484d96ab86dc5
2019-11-24osmo_sockaddr_str: deprecate osmo_sockaddr_str_*_32n()Neels Hofmeyr2-32/+32
Follow up for patch I3cf150cc0cc06dd36039fbde091bc71b01697322 osmo_sockaddr_str_{from,to}_32n actually use host byte order. Deprecate these and introduce a more accurately named version ending in h. Change-Id: Ic7fc279bf3c741811cfc002538e28e8f8560e338
2019-11-24utils: add osmo_strnchr()Neels Hofmeyr2-0/+42
When finding a char in a string, I want to be able to limit the search area by size, not only by nul terminator. Change-Id: I48f8ace9f51f8a06796648883afcabe3b4e8b537
2019-11-24utils_test: add osmo_print_n_test()Neels Hofmeyr2-0/+80
A couple of times recently I've needed to copy out a substring to a buffer with limited size. Use of strncpy() or osmo_strlcpy() are nontrivial here. I wanted to have a dedicated function. After I wrote that function with a test, I noticed that I had already implemented the same thing a while ago, as osmo_print_n() :P So here is just the test. Change-Id: Ia716abdc1f58af6065b84f4f567388a32a7b39fc
2019-11-23utils.h: add OSMO_NAME_C_IMPL() macroNeels Hofmeyr2-0/+98
Provide a common implementation for foo_name_c() functions that base on foo_name_buf() functions. char *foo_name_c(void *ctx, example_t arg) { OSMO_NAME_C_IMPL(ctx, 64, "ERROR", foo_name_buf, arg) } Rationale: the most efficient way of composing strings that have optional parts or require loops for composition is by writing to a ready char[], and this in turn is easiest done by using OSMO_STRBUF_* API. Using such a basic name string implementation which typically returns a length, I often want a more convenient version that returns a char*, which can just be inlined in a "%s" string format -- crucially: skipping string composition when inlined in a LOGP(). This common implementation allows saving code dup, only the function signature is needed. Why not include the function signature in the macro? The two sets of varargs (1: signature args, 2: function call args) are hard to do. Also, having an explicit signature is good for readability and code grepping / ctags. Upcoming uses: in libosmocore in the mslookup (D-GSM) implementation (osmo_mslookup_result_name_c()), and in osmo_msc's codec negotiation implementation (sdp_audio_codecs_name_c(), sdp_msg_name_c(), ...). I54b6c0810f181259da307078977d9ef3d90458c9 (libosmocore) If3ce23cd5bab15e2ab4c52ef3e4c75979dffe931 (osmo-msc) Change-Id: Ida5ba8d9640ea641aafef0236800f6d489d3d322
2019-11-23osmo_sockaddr_str: API doc: fix 32bit addr mixup of host/network byte orderNeels Hofmeyr2-48/+50
Of course both v4 and v6 addresses are kept in network byte order when represented in bytes, but when writing, I somehow must have assumed that inet_pton() returns host byte order. Fix that mixup in the API docs: osmo_sockaddr_str_from_32() and osmo_sockaddr_str_to_32() actually use network byte order. osmo_sockaddr_str_from_32n() and osmo_sockaddr_str_to_32n() actually use host byte order, though reflecting 'n' in their name. sockaddr_str_test: use hexdump instead of %x to show the osmo_sockaddr_str_to_32*() conversions so that the error becomes obvious. (Printing %x reverses the bytes again and made it look correct.) Change-Id: I3cf150cc0cc06dd36039fbde091bc71b01697322
2019-11-23logging.h: define ansi color constantsNeels Hofmeyr2-6/+6
It's hard to figure out what color logging categories have with those ANSI color code strings. Instead, define these OSMO_LOGCOLOR_* constants. Naming: commonly, the logging.h header has the "LOG" prefix in the name, but it seems saner to include the OSMO_ prefix: it seems too likely that some libosmocore user somewhere already has defined "LOGCOLOR_RED" somewhere. Change-Id: I03b6b1f73ae7ee61d37ff921e071a3d0881d3e9a
2019-11-21add osmo_sockaddr_str_cmp()Neels Hofmeyr2-0/+601
Currently planned user: for Distributed GSM in osmo-hlr: setting per-MSC service addresses in VTY: replace/remove existing entries. osmo_sockaddr_str_cmp() is useful to catch identical resulting IP addresses, regardless of differing strings (e.g. '0::' and '::' are equal but differ in strings). Change-Id: I0dbc1cf707098dcda75f8e07c1b936951f9f9501
2019-11-21logging/vty: fix vty_read_file(): do not write warnings to stdinVadim Yanitskiy1-4/+1
Setting vty->fd to 0 is a bad idea, which may cause the process to write() warnings to its own _stdin_ (yes, it's possible). For example, when a configuration file contains deprecated logging commands. Let's use stderr by default. Change-Id: Icdeaea67a06da3a2f07b252e455629559ecc1829
2019-11-21logging/vty: fix: actually ignore deprecated logging commandsVadim Yanitskiy5-1/+14
We shall not prevent programs from starting if their configuration files contain deprecated 'logging level ...' commands. Just print a warning and return CMD_SUCCESS instead of CMD_WARNING. While writing a unit test, another funny bug has been uncovered. Parsing of a deprecated command indeed triggers a deprecation warning, originated from libosmovty's log_deprecated_func(). This function simply calls vty_out(), but... Since the invocation of the vty_out() happens _before_ the VTY is initialized, the process is actually writing that warning to its own stdin! Most likely, because we use talloc_zero() to allocate a new instance of struct 'vty'. As a side effect, the evil warning magically appears in the output of 'make check', breaking the test statistics. Let's work around this bug for now by redirecting stdin to /dev/null. Change-Id: Ia934581410cd41594791d4e14ee74c16abe1009a Fixes: Ic9c1b566ec4a459f03e6319cf369691903cf9d00
2019-11-11fix OSMO_SOCKADDR_STR_FMT for IPv6Neels Hofmeyr1-11/+11
The format prints IP:port separated by a colon, which of course is confusing when the IPv6 address itself contains mostly colons. The new format adds square braces. cafe:face::1:42 -> [cafe:face::1]:42 The IPv4 format remains unchanged: 1.2.3.4:42 Change-Id: I161f8427729ae31be0eac719b7a4a9290715e37f
2019-11-11test: add OSMO_SOCKADDR_STR_FMT to sockaddr_str_test.cNeels Hofmeyr2-0/+24
This shows the weird format choice for showing IPv6 addresses' port, fixed in subsequent patch. Change-Id: I8e5ebfbbc3a2b88aed820e8f845d9f6ededb29de
2019-11-04gsm: gsm_utils: Fix return type of API ms_class_gmsk_dbm() and add unit testsPau Espin Pedrol1-0/+20
Only known user of API is in osmocom-bb and it compiles fine after the change. Related: OS#4244 Change-Id: Ia10345008b3aca50b30482ef3b852b03eca71995
2019-11-03gsm_04_08.h: Introduce API osmo_gsm48_rfpowercap2powerclass()Pau Espin Pedrol1-0/+24
Related: OS#4244 Change-Id: I32e9cc1c2397b44f0d48db2acdf782a821365b63
2019-11-01add osmo_sockaddr_str_is_nonzero()Neels Hofmeyr2-0/+57
Often, an IP address of 0.0.0.0 is considered an unset value (for clients requiring a server address; not for listening on "any"). osmo_sockaddr_str_is_set() does return false when the port is 0, but there is no simple way to tell whether the IP address is actually set to a server address. Add osmo_sockaddr_str_is_nonzero() to return false if: - the port is zero, or - the IP address is zero (0.0.0.0 or ::0), or - the IP address cannot be parsed. A practical use example: osmo-msc so far accepts an RTP IP address of 0.0.0.0 as valid. I noticed when trying to trigger error handling from a ttcn3 test. osmo-msc can use this function to reject invalid addresses from MGCP messages. Related: I53ddb19a70fda3deb906464e1b89c12d9b4c7cbd (osmo-msc) Change-Id: I73cbcab90cffcdc9a5f8d5281c57c1f87b2c3550
2019-10-29fsm: refuse state chg and events after termNeels Hofmeyr1-1996/+292
Refuse state changes and event dispatch for FSM instances that are already terminating. It is assumed that refusing state changes and events after FSM termination is seen as the sane expected behavior, hence this change in behavior is merged without being configurable. There is no fallout in current Osmocom code trees. fsm_dealloc_test needs a changed expected output, since it is explicitly creating complex FSM structures that terminate. Currently no other C test in Osmocom code needs adjusting. Rationale: Where multiple FSM instances are collaborating (like in osmo-bsc or osmo-msc), a terminating FSM instance often causes events to be dispatched back to itself, or causes state changes in FSM instances that are already terminating. That is hard to avoid, since each FSM instance could be a cause of failure, and wants to notify all the others of that, which in turn often choose to terminate. Another use case: any function that dispatches events or state changes to more than one FSM instance must be sure that after the first event dispatch, the second FSM instance is in fact still allocated. Furthermore, if the second FSM instance *has* terminated from the first dispatch, this often means that no more actions should be taken. That could be done by an explicit check for fsm->proc.terminating, but a more general solution is to do this check internally in fsm.c. In practice, I need this to avoid a crash in libosmo-mgcp-client, when an on_success() event dispatch causes the MGCP endpoint FSM to deallocate. The earlier dealloc-in-main-loop patch fixed part of it, but not all. Change-Id: Ia81a0892f710db86bd977462730b69f0dcc78f8c
2019-10-29add osmo_fsm_set_dealloc_ctx(), to help with use-after-freeNeels Hofmeyr2-17/+3460
This is a simpler and more general solution to the problem so far solved by osmo_fsm_term_safely(true). This extends use-after-free fixes to arbitrary functions, not only FSM instances during termination. The aim is to defer talloc_free() until back in the main loop. Rationale: I discovered an osmo-msc use-after-free crash from an invalid message, caused by this pattern: void event_action() { osmo_fsm_inst_dispatch(foo, FOO_EVENT, NULL); osmo_fsm_inst_dispatch(bar, BAR_EVENT, NULL); } Usually, FOO_EVENT takes successful action, and afterwards we also notify bar. However, in this particular case, FOO_EVENT caused failure, and the immediate error handling directly terminated and deallocated bar. In such a case, dispatching BAR_EVENT causes a use-after-free; this constituted a DoS vector just from sending messages that cause *any* failure during the first event dispatch. Instead, when this is enabled, we do not deallocate 'foo' until event_action() has returned back to the main loop. Test: duplicate fsm_dealloc_test.c using this, and print the number of items deallocated in each test loop, to ensure the feature works. We also verify that the deallocation safety works simply by fsm_dealloc_test.c not crashing. We should probably follow up by refusing event dispatch and state transitions for FSM instances that are terminating or already terminated: see I0adc13a1a998e953b6c850efa2761350dd07e03a. Change-Id: Ief4dba9ea587c9b4aea69993e965fbb20fb80e78
2019-10-28gsm0508: add functions to calculate beginning of a blockPhilipp Maier4-0/+441
The calculation of the beginning of a block for TCH/F, TCH/H and FACCH can be challenging since those channels are affected by the diagonal interleaving of the TCH channels. However, GSM 05.02 Section 7 Table 1 of 5 specifies how the blocks are distributed over the TDMA frame interval. Lets add a mapping function that is based on that table Related: OS#3803 Change-Id: I3d71c66f8c401f5afbad9b1c86c24580dab9e0ce
2019-10-28vty: Return error if cmd returns CMD_WARNING while reading cfg filePau Espin Pedrol4-0/+28
Otherwise bad configurations can easily sneak in and produce unexpected behavior. Change-Id: Ic9c1b566ec4a459f03e6319cf369691903cf9d00
2019-10-09logging: Introduce mutex API to manage log_target in multi-thread envsPau Espin Pedrol2-2/+3
log_enable_multithread() enables use of locks inside the implementation. Lock use is disabled by default, this way only multi-thread processes need to enable it and suffer related complexity/performance penalties. Locks are required around osmo_log_target_list and items inside it, since targets can be used, modified and deleted by different threads concurrently (for instance, user writing "logging disable" in VTY while another thread is willing to write into that target). Multithread apps and libraries aiming at being used in multithread apps should update their code to use the locks introduced here when containing code iterating over osmo_log_target_list explictly or implicitly by obtaining a log_target (eg. osmo_log_vty2tgt()). Related: OS#4088 Change-Id: Id7711893b34263baacac6caf4d489467053131bb
2019-10-07tdef_test: verify case where osmo_tdef_set returns -EEXISTPau Espin Pedrol2-0/+4
Change-Id: I436daa804aac11622fde24afe9ea35193d9e9beb
2019-10-07tdef: Introduce min_val and max_val fieldsPau Espin Pedrol4-3/+87
This is useful for timers expected to have a range of valid or expected values. Validation is done at runtime when timer values are set by the app or by the user through the VTY. Related: OS#4190 Change-Id: I4661ac41c29a009a1d5fc57d87aaee6041c7d1b2
2019-09-28gsup: add OSMO_GSUP_SUPPORTED_RAT_TYPES_IE and OSMO_GSUP_CURRENT_RAT_TYPE_IENeels Hofmeyr1-7/+7
OSMO_GSUP_SUPPORTED_RAT_TYPES_IE corresponds to the Supported RAT Types Indicator from 3GPP TS 29.002. See 8.1.2 MAP_UPDATE_LOCATION service, which indicates the capabilities of the MSC/VLR to the HLR. So far, have room for eight RAT types in the gsup_msg. That is an arbitrary random choice without any rationale. OSMO_GSUP_CURRENT_RAT_TYPE_IE is useful to communicate the currently used RAN / RAT type of the current subscriber during Location Updating Request. Change-Id: I93850710ab55a605bf61b95063a69682a2899bb1
2019-09-27gsm29205_test: fix error: missing braces around initializerVadim Yanitskiy1-1/+7
Since structure 'osmo_gcr_parsed' does contain arrays, GCC is not happy about the way we initialize it. Let's do it explicitly. Change-Id: Ia814b4a4ed5bec84ff1f69232f7f7d5ca0d19794
2019-09-26No fail if no /proc/cpuinfoRuben Undheim1-1/+1
Change-Id: I4b9e12e34f69d98fa87179c7ee390e31001ec943
2019-09-20ecu_fr: increase test coverage for FR ECU implementationPhilipp Maier2-0/+84
The ECU implementation for FR is currently tested by calling the related functions directly and by using the generic ECU abstraction layer. However, the test "test_fr_concealment" only tests directly. Lets add a version that uses the generic ECU abstraction layer as well. The generic ECU abstraction layer obsolets the public API functions osmo_ecu_fr_reset() and osmo_ecu_fr_conceal(), lets tag those functions as dprecated. Change-Id: Ib0c8a9b164f14ea4fa00688f760a76cdb4890af4
2019-09-02codec/ecu: Introduce new generic Error Concealment Unit abstractionHarald Welte2-0/+223
We don't want to expose the details of a given ECU implementation to the user (e.g. osmo-bts), but have a generic abstraction layer where an ECU implementation can simply register a few call-back functions with the generic core. As the developer and copyright holder of the related code, I hereby state that any ECU implementation using 'struct osmo_ecu_ops' and registering with the 'osmo_ecu_register()' function shall not be considered as a derivative work under any applicable copyright law; the copyleft terms of GPLv2 shall hence not apply to any such ECU implementation. The intent of the above exception is to allow anyone to combine third party Error Concealment Unit implementations with libosmocore, including but not limited to such published by ETSI. Change-Id: I4d33c9c7c2d4c7462ff38a49c178b65accae1915
2019-08-27context: Add support for [per-thread] global talloc contextsHarald Welte4-0/+99
Rather than having applications maintain their own talloc cotexts, let's offer some root talloc contexts in libosmocore. Let's also make them per thread right from the beginning. This will help some multi-threaded applications to use talloc in a thread-safe way. Change-Id: Iae39cd57274bf6753ecaf186f229e582b42662e3
2019-08-13add vty logp command to echo on all log targetsneels/logNeels Hofmeyr1-0/+53
When reading SUT logs resulting from TTCN3 runs, it can be hard to figure out which log section corresponds to which test code. Add a 'logp' command on VIEW and ENABLE nodes that simply echos an arbitrary message on log output, useful to set markers / explanations from the TTCN3 code, which then appear in all log outputs and can make it trivial to figure out which log section is interesting. logging_vty_test# logp lglobal notice This is the log message DLGLOBAL NOTICE This is the log message From TTCN3, could be used like this, e.g. in BSC_Tests.ttcn: private function f_logp(charstring log_msg) runs on MSC_ConnHdlr { // log on TTCN3 log output log(log_msg); // log in stderr log f_vty_transceive(BSCVTY, "logp lglobal notice " & log_msg); } ... f_logp("f_probe_for_handover(" & log_label & "): Ending the test: Handover Failure stops the procedure."); Change-Id: Ife5dc8999174c74e0d133729284fe526d6eaf8d9
2019-08-05tests: logging: Remove undefined param passed to logging_vty_add_cmdsPau Espin Pedrol1-1/+1
Since March 15th 2017, libosmocore API logging_vty_add_cmds() had its parameter removed (c65c5b4ea075ef6cef11fff9442ae0b15c1d6af7). However, definition in C file doesn't contain "(void)", which means number of parameters is undefined and thus compiler doesn't complain. Let's remove parameters from all callers before enforcing "(void)" on it. Related: OS#4138 Change-Id: Iaea795521361a8e5b3b45eaeb35e6eda69163af3
2019-07-30gsm0808_test: Fix wrong use of memcpPau Espin Pedrol1-1/+4
After recent system upgrade, gcc 9.1.0, I started getting gsm0808_test failing locally: Assert failed memcmp(&enc_ct, &dec_ct, sizeof(enc_ct)) == 0 libosmocore/tests/gsm0808/gsm0808_test.c:992 During investigation with gdb, fields of both structures seem to contain same values. However, closer lookup gives some hints on why it fails: (gdb) print memcmp(&enc_ct, &dec_ct, sizeof(enc_ct)) $1 = 85 (gdb) print memcmp(&enc_ct, &dec_ct, 12) $14 = 85 (gdb) print ((uint8_t*)&enc_ct)[11] $15 = 85 'U' (gdb) print ((uint8_t*)&dec_ct)[11] $16 = 0 '\000' So the 12th byte in struct gsm0808_channel_type is basically an alignment padding byte added by the compiler (to align perm_spch_len to 4-byte alignment). Since both compared structs are initialized without memset(0) but using compiler's designated initializers, it seems the compiler decided it's no longer needed to zero the padding byte, making memcp fail in this case. In order to avoid the failure, let's properly check every field instead of using memcp here. Change-Id: I17fe7a0a5dc650f050bba1f47d071be749550729
2019-07-08utils.h: require a semi colon after OSMO_ASSERTAlexander Couzens1-1/+1
When using `OSMO_ASSERT(exp);` clang will warn about an empty expression because the semi colon was superflous. Use do {} while (0) to enfore the need of a semi colon. This might break other test. Change-Id: I2272d29a81496164bebd1696a694383a28a86434
2019-06-14vty: command.c: Fix: single-choice optional args are no longer passed ↵Pau Espin Pedrol1-1/+1
incomplete to vty func For instance, take command "single0 [one]": If user executes "single0 on", VTY func will receive argv[0]="one" instead of argv[0]="on". Related: OS#4045 Change-Id: I5f4e2d16c62a2d22717989c6acc77450957168cb
2019-06-14vty: command.c: Fix: multi-choice args are no longer passed incomplete to ↵Pau Espin Pedrol2-11/+12
vty func For instance, take command "multi0 (one|two|three)": If user executes "multi0 tw", VTY func will receive argv[0]="two" instead of argv[0]="tw". Fixes: OS#4045 Change-Id: I91b6621ac3d87fda5412a9b415e7bfb4736c8a9a
2019-06-14vty: tests: Verify incomplete optional parameters are passed to vty funcsPau Espin Pedrol2-0/+18
The test shows that in the case were "single0 on" is executed, VTY function should return complete "single0 one" but it doesn't. Related: OS#4045 Change-Id: Ib5b9dc07e2b280dc95011b3926afb1d490cadd81
2019-06-11vty: command.c: Fix is_cmd_ambiguous() returning always 0Pau Espin Pedrol2-38/+9
inner block defined variable "enum match_type ret" was being masking outter block variable "int ret = 0". The ret variable was being given non zero values only inside the inner block, so that change was done on the inner variable and not the outer one, which is returned. Fixes: 5314c513f23688462d7f7937e5ae5e0d5cd4548e Change-Id: Iec87d7db49a096d07e38ff8a060b923a52bfd6ba
2019-06-07gsm48_decode_bcd_number2: fix ENOSPC edge caseOliver Smith2-0/+15
Return ENOSPC if the decoding buffer is one byte too small, instead of returning 0 and silently truncating the string. Add a new "truncated" variable to detect if the loop breaks in the final iteration. The string is not truncated if there is exactly one 0xf ('\0') higher nibble remaining. This is covered by the existing test case "long 15-digit (maximum) MSISDN, limited buffer". Related: OS#4049 Change-Id: Ie05900aca50cc7fe8a45d17844dbfcd905fd82fe
2019-06-06vty_transcript_test.vty: add choice auto-complete testsVadim Yanitskiy1-0/+9
This patch is a result of discussion we had in [1]. The key idea is that libosmovty should properly auto-complete the commands containing choice, such as the following one: multi0 (one|two|three) [1] If9b0c0d031477ca87786aab5c269d00748e896c8 Right now, sending the following command: (osmo-foo-bar)# multi0 th would basically match the following vector: multi0 three however the resulting argv would be: ["multi0", "th"] Moreover, sending the following command: (osmo-foo-bar)# multi0 t would basically match the following vectors: multi0 two multi0 three because both start from 't', so the resulting argv would be: ["multi0", "t"] which is ambiguous! The expected output is: (osmo-foo-bar)# multi0 th ok argc=1 three (osmo-foo-bar)# multi0 t % Ambiguous command. This is going to be fixed in the follow up patches. Change-Id: I83c3aef813173952641035862c534ef16384780e
2019-05-29gsm48_encode_bcd_number(): clarify optional LHV header initializationVadim Yanitskiy2-5/+9
Change-Id: Iafd911dd55691b3715391e3899cd6971245c8d7f
2019-05-28gsm48_decode_bcd_number2(): return -EINVAL if LV has too big lengthVadim Yanitskiy2-3/+3
Change-Id: Ie07b2e8bc2f9628904e88448b4ee63b359655123
2019-05-28gsm48_decode_bcd_number2(): fix: return -ENOSPC on truncationVadim Yanitskiy2-4/+4
The documentation of gsm48_decode_bcd_number2() clearly states that the output truncation is a erroneous case, so it should actually return negative in such cases. Let's return -ENOSPC. Change-Id: I75680f232001ba419a587fed4c24f32c70c3ad2b
2019-05-28gsm48_decode_bcd_number2(): fix output truncationVadim Yanitskiy1-2/+2
Thanks to the new unit test for BCD number encoding / decoding, it was discovered that gsm48_decode_bcd_number2() does not properly handle encoded LV if the output buffer size is equal to the original MSISDN length + 1 (\0-terminator): one digit is lost. For example, decoding of 15-digit long MSISDN to a buffer of size 16 (15 digits + 1 for \0) would give us only 14 digits. The problem was that 'output_len' was being decremented before checking the remaining buffer length and writing a digit to it. As a result, the maximum length was always one byte shorter. Change-Id: I61d49387fedbf7b238e21540a5eff22f6861e27a Fixes: OS#4025
2019-05-28gsm0408/gsm0408_test.c: introduce BCD number encoding / decoding testVadim Yanitskiy2-0/+224
So far, both gsm48_encode_bcd_number() and gsm48_decode_bcd_number2() did not have any unit test coverage. Let's fill this gap by testing the following scenarios: - encoding / decoding of a regular 9-digit MSISDN; - encoding / decoding of a MSISDN with optional LHV; - encoding / decoding of a long 15-digit MSISDN; - encoding / decoding of a MSISDN to a buffer: - with exactly matching size, - with lower size (truncation); - decoding LV buffer with incorrect length, - encoding / decoding an empty input buffer. As it turns out, gsm48_decode_bcd_number2() does not properly handle encoded LV if the output buffer size is equal to the original MSISDN length + 1 (\0-terminator): one digit is lost. For example, decoding of 15-digit long MSISDN to a buffer of size 16 (15 digits + 1 for \0) would give us only 14 digits. This is reflected in the unit test output: Decoding HEX (buffer limit=16) '0821436587092143f5'... Expected: (rc=0) '123456789012345' Actual: (rc=0) '12345678901234' Moreover, if the output buffer is shorter than decoded number, gsm48_decode_bcd_number2() silently truncates it and returns 0, while its description states, that the rc should reflect this. To be fixed in the follow-up patches. Change-Id: I4b2c330cf8ffe4427c0bee7d5f3b74be56ecd85d Related: OS#4025
2019-05-27oap_client: Fix license: GPLv2+ instead of AGPLv3+Harald Welte1-4/+5
libosmo{core,gsm,vty} code is GPLv2+. The OAP code originated in osmo-msc.git and was moved here without changing the license. That was a mistake, it always was meant to be under GPLv2-or-later after moving to libosmocore.git. Copyright is with sysmocom, so I as the managing director can approve the license change. Change-Id: I08311fa8214c15f8df8945b9894226608cf96f15
2019-05-19TLV: Add one-shot TLV encoderHarald Welte2-0/+49
So far, the TLV code contained two types of functions * tlp_parse() to parse all TLVs according to definition into tlvp_parsed * various helper functions to encode individual TLVs during message generation This patch implements the inverse of tlv_parse(): tlv_encode(), which takes a full 'struct tlv_pared' and encodes all IEs found in it. The order of IEs is in numerically ascending order of the tag. As many protocols have different IE/TLV ordering requirements, let's add a tlv_encode_ordered() function where the caller can specify the TLV ordering during the one-shot encode. Change-Id: I761a30bf20355a9f80a4a8e0c60b0b0f78515efe
2019-05-07add osmo_stat_item_inc/osmo_stat_item_dec to set it relativeAlexander Couzens1-0/+16
Change-Id: Id2462c4866bd22bc2338c9c8f69b775f88ae7511