AgeCommit message (Collapse)AuthorFilesLines
2019-12-03add utils/osmo-gsm-sharkneels/gsm-sharkNeels Hofmeyr3-0/+2176
Change-Id: Ifdfd261f776d9bf2bbfb0a584deac3e9a11bfe47
2019-12-01gprs_ns_instantiate(): propagate errors from gprs_sns_init() to callerHarald Welte1-2/+7
Change-Id: I71f347a2f0376716e5f83d33a7931eb8a99aad77
2019-12-01Check for osmo_fsm_register() error return valueHarald Welte4-4/+4
Change-Id: Idbc1557739b2a253b73914e6f1f18a6d169d882e
2019-11-30libosmovty: simplify condition checking vty->fd in vty_close()Vadim Yanitskiy1-2/+2
On POSIX systems, standard I/O streams - stdin, stdout, and stderr, always have default file descriptors 0, 1, and 2 respectively. Change-Id: Ied35d142af0ba0f5ad78975b8f22c35b32d6ff71
2019-11-30libosmovty: properly initialize vty->fd in vty_new()Vadim Yanitskiy1-0/+1
Since we're using talloc_zero(), vty->fd is initialized with 0, which corresponds to stdin. Let's set an invalid value to prevent potential bugs like the one fixed by the recent change [1]. [1] Icdeaea67a06da3a2f07b252e455629559ecc1829 Change-Id: Iec15649781317a23e13d2c2840a8f672050f76c1
2019-11-3004.80: Deprecate gsm0480_create_ussd_resp()Harald Welte1-0/+1
In July 2018 in commit Ide240279240322f643e142229eb7829f538c6314 we introduced the successor gsm0480_gen_ussd_resp_7bit(), which is also what both libosmogsm-internal code as well as osmo-hlr have been ported to. For some reason it wasn't marked deprecated back then. Change-Id: Iff4c91b5b98a73d9a30aa42f6b2a1ebcc8a45343
2019-11-30Add code coverage supportVasil Velichkov6-0/+330
The coverage report shows what code is covered by tests and what is not and the ratio could be tracked over time. These reports will allow us to identify code that is not being tested and improve the test suites. To enable the reports configure with --enable-code-coverage and execute "make check-code-coverage". The HTML report will be generated in a subdirectory with name libosmocore-$(PACKAGE_VERSION)-coverage/index.html The report is generated using gcov, lcov and lcov_cobertura tools and the OSMO_AC_CODE_COVERAGE macro. The osmo_ax_code_coverage.m4 is a copy of ax_code_coverage.m4 taken from autoconf-archive v2018.03.13. It was copied to avoid the additional external dependency and renamed to avoid overwriting it in case autoconf-archive is already installed as we are going to install it in $(datadir)/aclocal in order to be reused in other osmocom's projects. Closes: OS#1987 Change-Id: I6f4ffb91bd7f3dd070aa09dd16d5ad1faf130a4c
2019-11-28add all missing OSMO_GSUP_TO_MSGT_*() macrosNeels Hofmeyr1-0/+3
OSMO_GSUP_TO_MSGT_RESULT() is needed by osmo-hlr for osmo_gsup_req. The others are added for completeness' sake. Related: I3a8dff3d4a1cbe10d6ab08257a0138d6b2a082d9 Change-Id: I6e38a3bb8447f8f212f8d6f5b10a5d0df59323d7
2019-11-27Introduce fields related to DTAP DLCIPau Espin Pedrol3-1/+36
Change-Id: Iec448af02d28e6c5c573e68a0b4a86067ec7e561
2019-11-24add osmo_escape_cstr and osmo_quote_cstrNeels Hofmeyr4-21/+301
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_app_info.is_config_node: add OSMO_DEPRECATEDNeels Hofmeyr1-1/+4
Although this OSMO_DEPRECATED doesn't seem to generate a warning when compiling code that sets .is_config_node = foo, it seems a good idea to add the deprecation tag. It is deprecated since commit "vty: track parent nodes also for telnet sessions" I2b32b4fe20732728db6e9cdac7e484d96ab86dc5 Change-Id: I800507b27cb0d536c1a4c203d7f7b90eec05a69c
2019-11-24vty: track parent nodes also for telnet sessionsNeels Hofmeyr3-48/+31
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 Hofmeyr5-36/+60
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 Hofmeyr4-0/+65
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 Hofmeyr3-0/+82
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-24msgb_put: more elaborate logging of head/tailroom failureNeels Hofmeyr1-3/+12
Change-Id: I55b68098e1037c74ebe5faa86e34bd4494f5b726
2019-11-24fsm.h: add missing include of logging.hNeels Hofmeyr1-0/+1
Change-Id: I783bf0eb40b674fb6a77f7673563fdf156975f5a
2019-11-24GSUP: rename E_ROUTING_ERROR to ROUTING_ERRORNeels Hofmeyr2-2/+4
GSUP routing was introduced when adding the E interface. Hence that was the first realm where routing errors could occur. I did notice back then that this message type was special: it does not convey a response to a particular message kind -- it does not make sense, for example, to return an Updating Location Error cause, and do that for all conceivable message types. Instead, this tells the sender that a deeper error exists, i.e. that the desired peer is completely gone and unreachable. I did not foresee though that for D-GSM, there would also be arbitrary GSUP proxy routing, and that this error is not limited to E interface semantics. From today's point of view, adding the "_E_" in the name was a mistake. Remove that "_E_" to yield OSMO_GSUP_MSGT_ROUTING_ERROR (with unchanged message type discriminator), but provide a #define linking the old name OSMO_GSUP_MSGT_E_ROUTING_ERROR to the new one. The only visible change should be that osmo_gsup_message_type_names[] now returns the new name without "_E_". I am not aware of any regression test fallout from that. Change-Id: Ic8e8bd11522d6c51ac7aaf946516cbce26bc6e1e
2019-11-23fix osmo_escape_str_c() and osmo_quote_str_c()Neels Hofmeyr1-30/+48
The osmo_escape_str_c() and osmo_quote_str_c() functions return truncated results when characters need escaping. For example: osmo_quote_str_c(NULL, "foo"); --> "foo" osmo_quote_str_c(NULL, "foo\n"); --> "foo\n osmo_quote_str_c(NULL, "foo\tbar\t\n"); --> "foo\tbar\t Implement these _c variants using OSMO_NAME_C_IMPL() to always allocate sufficient memory. However, current osmo_escape_str_buf2() and osmo_quote_str_buf2() fail to return the required buffer size (even though that information is readily avaiable), so these don't qualify for accurate use of OSMO_NAME_C_IMPL(). Hence, move the implementations of osmo_escape_str and osmo_quote_str to an internal static function that returns the characters needed, so that all dynamically allocating implementations can return un-truncated results. Of course, external callers would also benefit from escape/quote API that accurately returns the amount of characters needed, but I am not changing public API in this patch, on purpose, ... yet. Change-Id: I16c08eced41bf1b7acf6e95f658068ace99ca4c8
2019-11-23utils.h: add OSMO_NAME_C_IMPL() macroNeels Hofmeyr3-0/+154
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 Hofmeyr3-54/+58
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-23cosmetic: logging.h: fix comment s/levels/subsystemsNeels Hofmeyr1-1/+1
Change-Id: I242a4a44649bc4dac055985ba8fd63b2f784ee6d
2019-11-23fix DLSMS logging category color: '[1:38m' isn't actually definedNeels Hofmeyr1-1/+1
Instead it apparently renders as bright white, so just use that constant instead. Change-Id: Ic775b6e37ccf61dc71a540b41d6a16a8a9291dc2
2019-11-23logging.h: define ansi color constantsNeels Hofmeyr4-14/+33
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-22libosmogsm: add support for XOR authenticationDaniel Willmann2-1/+188
Change-Id: I1afaf0a9e2dce43aec87964bacefb21ed4d3d565 Related: OS#2475
2019-11-21utils.c: fix various inaccurate API doc about return valuesNeels Hofmeyr1-4/+3
Change-Id: I9ee6416decd23f8d5d634197620a63ae408cead3
2019-11-21add osmo_sockaddr_str_cmp()Neels Hofmeyr5-0/+678
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: do not close stderr in vty_close()Vadim Yanitskiy1-1/+1
Since Icdeaea67a06da3a2f07b252e455629559ecc1829, we use stderr for printing warnings while parsing the VTY configuration files. Make sure we do not close() stderr. Otherwise stderr logging gets broken. Change-Id: I6ecc85555d102f5911d50ed5ac54933c766fa84d Fixes: Icdeaea67a06da3a2f07b252e455629559ecc1829
2019-11-21logging/vty: fix vty_read_file(): do not write warnings to stdinVadim Yanitskiy2-5/+6
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 Yanitskiy6-2/+15
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-21logging/vty: use LOG_LEVEL_ARGS in logging_vty_add_deprecated_subsys()Vadim Yanitskiy1-2/+1
Change-Id: I862c3cce0147ee8cf4013501132584ea09c58b53
2019-11-20logging/vty: do not print deprecated logging commands to stdoutVadim Yanitskiy1-1/+0
Yes, we don't really need to poison stdout, as some osmo-* binaries (like osmo-gapk) may want to use it for non-logging purposes. This printf() call looks like a debugging leftover. Change-Id: Ida35865b1c0bb3d3567918f8e89c6551c6b34103
2019-11-11fix OSMO_SOCKADDR_STR_FMT for IPv6Neels Hofmeyr2-13/+17
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: 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-09GPRS/BSSGP: introduce bssgp_bvc_ctx_free()Vadim Yanitskiy4-0/+13
So far we had a function to allocate a new bssgp_bvc_ctx, but not the opposite one. Let's finally introduce it, so it will be used at least in OsmoPCU. Please note that the new symbol has 'bssgp_' prefix, not 'btsctx_'. Change-Id: Ia78979379dbdccd6e4628c16f00d0c06d9212172
2019-11-07select: Make file descriptor lists per-threadHarald Welte2-3/+18
In a multi-threaded environemnt, it's likely that each thread will have its own, distinct set of file descriptors that it wants to watch. Hence, let's make the osmo_fd_* functions configure not one global list of file descriptors, but a thread-local list of file descriptors. Change-Id: I5082ed3e500ad1a7516e1785bc57e008da2fac9a
2019-11-04gsm: gsm_04_08.h: Allow accessing classmark2 as struct instead of uint32_tPau Espin Pedrol1-5/+28
New fields are put inside a union to keep backward compatibility with potential older users of the struct. Change-Id: I235635800c0de47b1e2b9ec9c7191418f6003554
2019-11-04gsm: gsm_utils: Fix return type of API ms_class_gmsk_dbm() and add unit testsPau Espin Pedrol3-4/+23
Only known user of API is in osmocom-bb and it compiles fine after the change. Related: OS#4244 Change-Id: Ia10345008b3aca50b30482ef3b852b03eca71995
2019-11-04gsm: Fix compilation error under some compilersPau Espin Pedrol2-2/+2
Some compilers don't like declaration of enums in header files like we do sometimes for structs: enum gsm_band; void foobar(enum gsm_band band); triggers: error: use of enum 'gsm_band' without previous declaration Fixes: b99f4ca2d8517d99cdf8aa183dbfda7b233bb781 Related: OS#4244 Change-Id: I6c2102c763f565bbe3c8dd7e5b4e04c4a45fff67
2019-11-03gsm_04_08.h: Introduce API osmo_gsm48_rfpowercap2powerclass()Pau Espin Pedrol5-1/+49
Related: OS#4244 Change-Id: I32e9cc1c2397b44f0d48db2acdf782a821365b63
2019-11-01add osmo_sockaddr_str_is_nonzero()Neels Hofmeyr4-0/+87
Often, an IP address of 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 ( or ::0), or - the IP address cannot be parsed. A practical use example: osmo-msc so far accepts an RTP IP address of 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-11-01cosmetic: gsm_04_08.h: Fix trailing whitespacePau Espin Pedrol1-3/+3
Change-Id: I4b34dbd5f0176d1d8aa8cc96f642ed35d4214b7e
2019-10-29fsm: refuse state chg and events after termNeels Hofmeyr2-1996/+307
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 Hofmeyr4-26/+3508
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-29gprs_ns_vty: return success for disabled FR/GREOliver Smith1-4/+0
Do not return a warning and therefore fail parsing the config when the "encapsulation framerelay-gre local-ip" command is used and FR/GRE is disabled. Having this in the config does no harm and allows keeping the same config if it is enabled later. This fixes the currently failing vty tests for osmo-sgsn. Fixes: a0c8195ad37292ab800a6c777fc28383995b4b64 ("vty: Return error if cmd returns CMD_WARNING while reading cfg file") Change-Id: Ic225232fbfca49ba868427eaf898e1f6e34e1ca8
2019-10-28gsm0508: add functions to calculate beginning of a blockPhilipp Maier7-0/+611
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 Pedrol5-2/+29
Otherwise bad configurations can easily sneak in and produce unexpected behavior. Change-Id: Ic9c1b566ec4a459f03e6319cf369691903cf9d00
2019-10-24configure: Introduce --disable-libsctp and error by default if libsctp not foundPau Espin Pedrol2-11/+18
This way libosmocore build fails during configuring phase if expected default behavior (building with libsctp support enabled and providing osmo_sock_init2_multiaddr() API) fails. User is still provided with --disable-libsctp option in case he doesn't need those features or his environment doesn't provide required libsctp APIs. Change-Id: I710c9cb1c6da0e5fc94b792df8bf60194a72208f
2019-10-24socket.c: build multiaddr socket API helpers only if used by public APIsPau Espin Pedrol1-0/+4
Those two functions are only used by osmo_sock_init2_multiaddr(), which is only built if HAVE_LIBSCTP is defined. Avoid compiler warning about unusued function helpers if osmo_sock_init2_multiaddr() is not being built. Change-Id: I52769d6b8f70af1a8bda23d60b3230a932e71fab
2019-10-22libosmocore.pc.in: Append -lsctp to Libs.privatePau Espin Pedrol1-1/+1
It will be used by the linker when linking statically against libosmocore. Change-Id: I797b970b22053432b243e4ef9f6b0458727fc608