summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* doxygen: allow manual 'make apidoc' even if --disable-doxygenNeels Hofmeyr2019-02-041-8/+17
| | | | | | | | | | | | Even if ./configure --disable-doxygen was passed and doxygen builds are by default skipped, provide a manual 'make apidoc' target that nevertheless generates the API doc on the premise that a 'doxygen' program is available. Especially since we do a two-pass doxygen build whenever any source file changes, my guess is --disable-doxygen could be a common choice. It is then cumbersome to have to ./configure just to get one doxygen build started. Change-Id: If8d8dfb8365c8f28612b8ce2b8ddf88f74df9a90
* doxygen: add source files as dependenciesNeels Hofmeyr2019-02-041-7/+25
| | | | | | | | | | | | | | | | | So far, when modifying a source file, the doxygen docs were not regenerated automatically. It required a manual 'rm -rf docs/core' or similar. Make it rebuild automatically: Add each library's source files to the list of dependencies for the first-pass doxygen build. Attention, since all libraries depend on the .map files of each other library, and each library depends on its own source files, that means that a single touch on one .c file anywhere will result in rebuilding the entire doxygen docs. It is correct to do so, since any file may introduce \ref targets used anywhere else. If you don't want that, --disable-doxygen. Change-Id: I15ea96be6e7abe91264b91f0b06963a0f2d63b0b
* doxygen: enable cross referencing everywhereNeels Hofmeyr2019-02-048-28/+130
| | | | | | | | | | | | | | | | | | | | | | | | doxygen \ref cross-references to groups or files from other libraries only work when the .map file was present when the HTML was generated, and when that .map file was listed in TAGFILES in the Doxyfile. - Makefile.am: introduce a two-pass build for doxygen API docs. - First build pass makes sure the .tag files are present. - Second build pass picks up all the references, hence generates hyperlinks properly. - Add all libraries to TAGFILES of all other libraries, so we can from now on freely criss-cross reference from everywhere to everywhere. - Add all libraries' tag files as dependencies for all others. Example: in upcoming tdef.h, I would like to cross reference to tdef_vty.h, and vice versa, even though they are in libosmocore and libosmovty, respectively. This is now possible. We may still need to fix some problems with naming collisions, see for example stats.h, which exists twice with identical doxygen handle (different source dirs seems to not suffice for doxygen). Change-Id: Ib03d0b70d536c8f1386def666c89106a840f7363
* vty api: add vty_out_va()Neels Hofmeyr2019-02-042-12/+20
| | | | | | | | | Provide a va_list type vty_out() variant, to be able to pass on variable arguments from other function signatures to vty_out(). This will be used by Ibd6b1ed7f1bd6e1f2e0fde53352055a4468f23e5 for osmo_tdef. Change-Id: Ie6e6f11a6b794f3cb686350c1ed678e4d5bbbb75
* vty telnet: consistently never change nodes upon CTRL-CNeels Hofmeyr2019-02-041-18/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove any special node exiting from the VTY CTRL-C handling. From a curious VTY transcript test glitch, I noticed weird behavior by the VTY telnet shell: usually, when the user hits CTRL-C, that means to cancel the current command line and present a fresh, clean prompt. However, only on the CONFIG_NODE and CFG_LOG_NODE, a CTRL-C also exits the current node and moves up by one level. This behavior is unexplainable and makes zero sense. No other nodes exit on CTRL-C: - on the ENABLE node, a CTRL-C stays on the ENABLE_NODE and doesn't exit to the VIEW_NODE. - any sub-nodes of the CONFIG_NODE stay unchanged, e.g. 'network' or 'bts' / 'trx', etc. There is no apparent special meaning of CTRL-C on CONFIG_NODE nor CFG_LOG_NODE to justify this odd choice. Particularly, the vty transcript tests using osmo_verify_transcript_vty.py rely on sending CTRL-C to clear the command prompt, so that we can properly test sending '?' to the VTY during transcripts. In a live session, a '?' prints available options and then updates the prompt with identical command arguments. In a transcript test, that doesn't make sense, because each time the transcript writes out a new command to run. Consider e.g. a transcript test like: tdef_vty_test(config)# timer ? tea Tea time test Test timers software Typical software development cycle tdef_vty_test(config)# timer tea ? [TNNNN] T-number, optionally preceded by 't' or 'T'. To be able to issue a fresh command after '?', osmo_verify_transcript_vty.py explicitly sends a CTRL-C to clear the command buffer. Hence there we rely on predictable behavior of CTRL-C. More particularly, the upcoming osmo_tdef_vty transcript tests are apparently the first that want to test '?' behavior on the CONFIG_NODE's root level and fall on their face, because of the implicit exit that happens only there. Change-Id: I4f339ba61f1c273fa7da85caf77ba116ae2697b1
* vty: enable tab-completion for optional-multi-choice argsNeels Hofmeyr2019-02-041-1/+10
| | | | | | | | | | | | | | In cmd_complete_command_real(), detect and strip square braces from multi-choice arguments, to enable tab-completion for commands like > list cmd [(alpha|beta)] > cmd <TAB> alpha beta > cmd be<TAB> > cmd beta Change-Id: I8c304300b3633bb6e9b3457fcfa42121c8272ac0
* vty: enable optional-multi-choice syntax: [(one|two)]Neels Hofmeyr2019-02-043-3/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | Since very recently we sensibly handle commands like cmd ([one]|[two]|[three]) as optional multi-choice arguments. In addition, support the more obvious syntax of cmd [(one|two|three)] Internally, the tokens are mangled to [one] [two] and [three], which is how the rest of the code detects optional args, and makes sense in terms of UI: > cmd ? [one] [two] [three] (i.e. optional arguments are always shown in braces in '?' listings) Before this patch, commands defined with a syntax like [(one|two)], would lead to an assertion (shows as "multiple") during program startup. Change-Id: I952b3c00f97e2447f2308b0ec6f5f1714692b5b2
* vty: enable optional-multi-choice syntax: ([one]|[two])Neels Hofmeyr2019-02-042-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add basic optional multi-choice argument support. The VTY detects optional arguments by square braces. > cmd ? [optional-arg] > cmd optional-arg ok > cmd ok However, within multi-choice args, these braces were so far not treated as optional: > list cmd2 ([one]|[two]|[three]) > cmd2 % Command incomplete In preparation for I952b3c00f97e2447f2308b0ec6f5f1714692b5b2 which will enable the more obvious syntax of cmd [(one|two)] for reasons of internal implementation, first support a syntax of cmd ([one]|[two]) The internal vty implementation always needs square braces around each option. There is currently no good way to prevent developers from defining braces inside multi-arguments, so it is easiest to allow and handle them: > list cmd2 ([one]|[two]|[three]) > cmd2 ok The VTY doesn't guard against a mix like cmd (one|[two]) With this patch, a multi-choice command is treated as optional iff the first element is in square brackets. The remaining elements' square brackets have no effect besides confusing the user. This is not explicitly checked against. In general, I would prefer to check all of these details, but the current VTY code with its endless code duplication and obscure string mangling just doesn't provide that luxury. There are numerous worse errors hidden in there. Change-Id: I9a8474bd89ddc2155c58bfca7bd038d586aaa60a
* add generic vty_transcript_test.c, vty_transcript_test.vtyNeels Hofmeyr2019-02-043-2/+301
| | | | | | | | I want to tweak general VTY features and need to cover with a transcript test to show the differences. Start by showing the current situation of optional and multi-choice arguments. Change-Id: I5a79c83fabd02aba6406b6e0d620969c4bd0cc1d
* socket.h: add missing includeMax2019-02-041-2/+7
| | | | | | | | | | socket.h uses INET6_ADDRSTRLEN without including arpa/inet.h where it's defined which might break external users of socket.h Fix this by adding missing include. The error was introduced in 64b51eb68bd272b6b1f2cefa2b33e9dd74024d0c Change-Id: I2883addcb81cec038577e401e356e8f07a947d4c
* GSUP: deprecate osmo_gsup_get_err_msg_type()Oliver Smith2019-02-042-30/+17
| | | | | | | | | | | | | | Replace osmo_gsup_get_err_msg_type() with a wrapper to OSMO_GSUP_TO_MSGT_ERROR(). This macro assumes, that all error messages are (request message | 0x000001). Add a big comment header for osmo_gsup_message_type, describing this already implicitly followed rule and therefore making it explicit. With this change, we don't need to maintain the request -> error message mapping in osmo_gsup_get_err_msg_type() anymore. Related: Iec1b4ce4b7d8eb157406f006e1c4241e8fba2cd6 (osmo-gsm-manuals) Change-Id: I46d9f2327791978710e2f90b4d28a3761d723d8f
* osmo_fsm_inst_state_chg(): clamp timeout_secs to <= ~68 yearsNeels Hofmeyr2019-01-311-1/+13
| | | | | | | | | | | | | | | | | | | | During testing of the upcoming tdef API, it became apparent that passing very large timeout values to osmo_fsm_inst_state_chg() wraps back in the number range, and might actually result in effectively very short timeouts instead. Since time_t's range is not well defined across platforms, use a reasonable maximum value of signed 32 bit integer. Hence this will be safe at least on systems with an int32_t for struct timeval.tv_sec and larger. Clamp the osmo_fsm_inst_state_chg() timeout_secs argument to a maximum of 0x7fffffff, which amounts to just above 68 years: float(0x7fffffff) / (60. * 60 * 24 * 365.25) = 68.04965038532715 (In upcoming patch Ibd6b1ed7f1bd6e1f2e0fde53352055a4468f23e5, this can be verified to work by invoking tdef_test manually with a cmdline argument passed to enable the range check.) Change-Id: I35ec4654467b1d6040c8aa215049766089e5e64a
* osmo_fsm_inst_state_chg(): set T also for zero timeoutNeels Hofmeyr2019-01-294-7/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this patch, if timeout_secs == 0 was passed to osmo_fsm_inst_state_chg(), the previous T value remained set in the osmo_fsm_inst->T. For example: osmo_fsm_inst_state_chg(fi, ST_X, 23, 42); // timer == 23 seconds; fi->T == 42 osmo_fsm_inst_state_chg(fi, ST_Y, 0, 0); // no timer; fi->T == 42! Instead, always set to the T value passed to osmo_fsm_inst_state_chg(). Adjust osmo_fsm_inst_state_chg() API doc; need to rephrase to accurately describe the otherwise unchanged behaviour independently from T. Verify in fsm_test.c. Rationale: it is confusing to have a T number remaining from some past state, especially since the user explicitly passed a T number to osmo_fsm_inst_state_chg(). (Usually we are passing timeout_secs=0, T=0). I first thought this behavior was introduced with osmo_fsm_inst_state_chg_keep_timer(), but in fact osmo_fsm_inst_state_chg() behaved this way from the start. This shows up in the C test for the upcoming tdef API, where the test result printout was showing some past T value sticking around after FSM state transitions. After this patch, there will be no such confusion. Change-Id: I65c7c262674a1bc5f37faeca6aa0320ab0174f3c
* jenkins distcheck: enable external testsNeels Hofmeyr2019-01-291-1/+2
| | | | | | | | | It was recently discovered that logging_vty_test.vty was missing from EXTRA_DIST. To make sure we don't forget similar files in the future, add python tests to 'make distcheck', by means of DISTCHECK_CONFIGURE_FLAGS. Related: I1bcedf3097f02b2adc679560d1cbceb27dbc345e Change-Id: Id569b2a932c1428cabb4d7ff17822cff8eee02af
* build: add missing logging_vty_test.vty to EXTRA_DISTNeels Hofmeyr2019-01-291-0/+1
| | | | | | | | | | It was introduced and forgotten to add to EXTRA_DIST in: "logging vty: add VTY transcript test" commit 3a9ff11e574fa7ee19b1062b2c90151dbf7f0e27 change-Id I948e832a33131f8eab98651d6010ceb0ccbc9a9c Change-Id: I1bcedf3097f02b2adc679560d1cbceb27dbc345e
* osmo_fsm_state_name: make robust against NULL fiNeels Hofmeyr2019-01-291-1/+1
| | | | Change-Id: I61d4f7dfada2763948f330745ac886405d889a12
* add osmo_classmark_* APINeels Hofmeyr2019-01-293-0/+149
| | | | | | | | | osmo-bsc and osmo-msc implement identical Classmark structures. It makes sense to define once near the gsm48 protocol definitions. Also move along some generic Classmark API from osmo-msc. Change-Id: Ifd27bab0380f7ad0c44c719aa6c8bd62cf7b034c
* add osmo_hexdump_buf() and testNeels Hofmeyr2019-01-284-11/+163
| | | | | | | | | | | | | | | | | | Add osmo_hexdump_buf() as an all-purpose hexdump function, which all other osmo_hexdump_*() implementations now call. It absorbs the static _osmo_hexdump(). Add tests for osmo_hexdump_buf(). Rationale: recently during patch review, a situation came up where two hexdumps in a single printf would have been useful. Now I've faced a similar situation again, in ongoing development. So I decided it is time to provide this API. The traditional osmo_hexdump() API returns a non-const char*, which should probably have been a const instead. Particularly this new function may return a string constant "" if the buf is NULL or empty, so return const char*. That is why the older implementations calling osmo_hexdump_buf() separately return the buffer instead of the const return value directly. Change-Id: I590595567b218b24e53c9eb1fd8736c0324d371d
* gsm0808: add BSSMAP Cell Identifier matching APINeels Hofmeyr2019-01-287-0/+645
| | | | | | | | | | | | | | | | | | | | | | | | | Add * osmo_lai_cmp() (to use in gsm0808_cell_id_u_matches()) * osmo_cgi_cmp() (to use in gsm0808_cell_id_u_matches()) * gsm0808_cell_id_u_match() (to re-use for single IDs and lists) * gsm0808_cell_ids_match() * gsm0808_cell_id_matches_list() * Unit tests in gsm0808_test.c Rationale: For inter-BSC handover, it is interesting to find matches between *differing* Cell Identity kinds. For example, if a cell as CGI 23-42-3-5, and a HO for LAC-CI 3-5 should be handled, we need to see the match. This is most interesting for osmo-msc, i.e. to direct the BSSMAP Handover Request towards the correct BSC or MSC. It is also interesting for osmo-bsc's VTY interface, to be able to manage cells' neighbors and to trigger manual handovers by various Cell Identity handles, as the user would expect them. Change-Id: I5535f0d149c2173294538df75764dd181b023312
* Work around bogus gcc-8.2 array-bounds warning/errorHarald Welte2019-01-222-1/+21
| | | | | | | | | | | | | | | | | | | | | | gcc-8.2 is printing the following warning, which is an error when used -Werror like our --enable-werror: In file included from gprs_bssgp.c:34: In function ‘tl16v_put’, inlined from ‘tvlv_put.part.3’ at ../../include/osmocom/gsm/tlv.h:156:9, inlined from ‘tvlv_put’ at ../../include/osmocom/gsm/tlv.h:147:24, inlined from ‘msgb_tvlv_push’ at ../../include/osmocom/gsm/tlv.h:386:2, inlined from ‘bssgp_tx_dl_ud’ at gprs_bssgp.c:1162:4: ../../include/osmocom/gsm/tlv.h:131:2: error: ‘memcpy’ forming offset [12, 130] is out of the bounds [0, 11] of object ‘mi’ with type ‘uint8_t[11]’ {aka ‘unsigned char[11]’} [-Werror=array-bounds] memcpy(buf, val, len); Where "130" seems to be the maximum value of uint8_t, shifted right one + 2. But even as we use strnlen() with "16" as maximum upper bound, gcc still believes there's a way that the return value of gsm48_generate_mid_from_imsi() could be 130. In fact, even the newly-added OSMO_ASSERT() inside gsm48_generate_mid() doesn't help and gcc still insists there is a problem :( Change-Id: I0a06daa19b7b5b5badbb8b3d81a54c45b88a60ec
* constrain gsm48_generate_mid() output array boundsHarald Welte2019-01-224-7/+12
| | | | | | | | | | | The longest BCd-digit type identity is the IMEISV with 16, so there's no point in trying to parse up to 255 decimal digits, which will do nothing but to overflow the caller-provided output buffer. Let's also clearly define the required minimum size of the output buffer and add a reltead #define for it. Change-Id: Ic8488bc7f77dc9182e372741b88f0f06100dddc9
* gsm0408_test: Fix IMEI-SV related tests to use no more than 16 digitsHarald Welte2019-01-222-16/+16
| | | | | | | | The IMEI-SV is speified as a 16 digit number: 14 digits of IMEI plus two digits of software version. Let's not try to feed 18 digit long numbers into our functions, as the resulting behavior is unspecified. Change-Id: I6fb85a0516dc387902ad9de4fe8c1ba82d68cae6
* Merge tag '1.0.1'Harald Welte2019-01-210-0/+0
|\ | | | | | | | | | | Release v1.0.1 on 2019-01-21. Change-Id: I2b92a7cfcdc7ed9d6f835bd17c6b5d2ec939b568
| * Bump version: 1.0.0 → 1.0.1Harald Welte2019-01-212-1/+8
| | | | | | | | Change-Id: I51696a3ace219ab69c294b0e3637371c5460291f
* | Bump version: 1.0.0 → 1.0.1Harald Welte2019-01-212-1/+8
| | | | | | | | Change-Id: I51696a3ace219ab69c294b0e3637371c5460291f
* | gsm_23_003.h: add GSM23003_IMEI_NUM_DIGITS_NO_CHKOliver Smith2019-01-211-0/+3
|/ | | | | | | Add new define for the 14 digit IMEI without the Luhn checksum, as it is used in OsmoHLR. Change-Id: I02b54cf01a674a1911c5c897fbec02240f88b521
* Rename msgb_wrap_with_TL()Max2019-01-212-10/+10
| | | | | | | | | | | | | | | This resolves an issue introduced in 84fb5bb6a09a6a358f98c654c84c3b99a0f24eef when msgb_wrap_with_TL() was introduced as an inline function with *exactly the same name* as in osmo-msc.git and openbsc.git. We *NEVER* do something like this. Functions moved from applications to library *MUST* always be renamed. This has been the case for almost a decade now. With this subsequent change we make sure the libosmocore function has a different name and doesn't clash. After this commit, old openbsc.git and osmo-bsc.git should again build fine. Change-Id: If1e851ac605c8d2fde3da565b0bd674ea6350c2e
* Bump version: 0.12.0.128-8dfde → 1.0.0Harald Welte2019-01-199-24/+247
| | | | Change-Id: I1bd973754b1ebc42283f6a07defa60f58523f5a3
* Prevent GCR encoder/decoder functions from being used directlyMax2019-01-191-2/+2
| | | | | | | | They only make sense in the context of LCLS so far - let's make sure they're not used by external projects directly instead of gsm0808_*() counterparts. Change-Id: I4ae5a3472a20492d5f76170b722e4e2274a5c433
* LCLS: make GCR into static member of osmo_lclsMax2019-01-193-24/+28
| | | | | | | | | Most of the time we'll have GCR filled anyway so it make sense to have it as static parameter instead of a pointer to separately allocated structure. Update tests to cover both static and dynamic osmo_lcls allocation variants. Change-Id: I905c36d8455911c68c30bc429379b7313dd46aea
* LCLS: add status parameter to Assignment Completed messageMax2019-01-194-11/+43
| | | | | | | | | | * add gsm0808_create_ass_compl2() with additional gsm0808_lcls_status parameter and make gsm0808_create_ass_compl() into trivial wrapper around it * update tests accordingly Change-Id: I547c6b8707123aa8c1ef636db88908df112d90a4 Related: OS#2487
* gsm29118: fix coverity issuesPhilipp Maier2019-01-181-1/+6
| | | | | | | | | | | | | The function msgb_sgsap_name_put() assignes the return code of osmo_apn_from_str() directly to len. Len is an uint8_t and the return code an int. If osmo_apn_from_str() returns -1. Len would become 0xFF causing a buffer overrun with msgb_tlv_put. Lets use the proper type to catch the return code and check it before using it as length. Change-Id: Ic0bc5114eee47bdcf2300a6e4b0df473d3d1903a Fixes: CID#190405 Fixes: CID#190401 Related: OS#3615
* socket: add define for socket name lengthPhilipp Maier2019-01-172-4/+4
| | | | | | | | | | | The function osmo_sock_get_name_buf() can be used to write a string representation to a user provided memory. Unfortunately the proper length for the user provided memory is not obvious. To make using osmo_sock_get_name_buf() more practical, add a define constant that defines the length of the required memory. Also use this define in socket.c. Change-Id: If8be8c2c0d4935da17ab13b2c2127b719ceefbcc
* LCLS: add GCR comparison helperMax2019-01-144-19/+27
| | | | Change-Id: I9e3b5560a058b976638d03cb819415d237ae9984
* LCLS: expand enc/dec testsMax2019-01-141-0/+12
| | | | Change-Id: I8ed87f26216104d34c7bd11c1527b203843760a2
* comments: update/fix three 3GPP spec referencesNeels Hofmeyr2019-01-143-3/+3
| | | | Change-Id: I3ab94f362866d752099000afe62922288b3dd118
* change GSM48_CMSERV_* to enum type, add namesNeels Hofmeyr2019-01-143-7/+26
| | | | | | | Prepare handling multiple CM Service Requests in osmo-msc: an enum is more clear than an int and #defines for passing around and count CM Service types. Change-Id: I9c2a7adc45ab7a1a7519168e965e7d805e1481ff
* gsm23003: add osmo_imei_str_valid()Oliver Smith2019-01-147-0/+107
| | | | | | | | | | | Verify 14 digit and 15 digit IMEI strings. OsmoHLR will use the 14 digit version to check IMEIs before writing them to the DB. Place the Luhn checksum code in a dedicated osmo_luhn() function, so it can be used elsewhere. Related: OS#2541 Change-Id: Id2d2a3a93b033bafc74c62e15297034bf4aafe61
* port rest octets encoding code from osmo-bscStefan Sperling2019-01-125-0/+1084
| | | | | | | | | | | | | | | | | | | | | | | | | | As part of fixing issue OS#3075, we want to migrate support for encoding system information from osmo-bsc to libosmocore. This change ports osmo-bsc code for encoding SI rest octets. The conversion was a bit tricky in some places because some functions receive a 'struct gsm_bts' parameter in osmo-bsc. In this libosmocore version, such functions expect parameters which correspond to the individual fields of 'struct gsm_bts' which are used by these functions. Several structs from osmo-bsc's system_information.h are now also declared in libosmocore headers, with an added osmo_ prefix to avoid collisions with existing definitions in osmo-bsc. Some helpers were ported from osmo-bsc's system_information.c to libosmocore's gsm48_rest_octets.c. Contrary to osmo-bsc's implementation they are now only visible within this file. Unfortunately, this code ported from osmo-bsc lacks unit tests. Change-Id: I47888965ab11bba1186c21987f1365c9270abeab Related: OS#3075
* port arfcn range encode support from osmo-bscStefan Sperling2019-01-127-1/+760
| | | | | | | | | | | | | | As part of fixing issue OS#3075, we want to migrate support for encoding system information from osmo-bsc to libosmocore. This change ports one of the prerequisites for doing so: osmo-bsc code for range-encoding ARFCNs, including tests. An osmo_gsm48_ prefix has been prepended to public symbols in order to avoid clashes with existing symbols in osmo-bsc code. Change-Id: Ia220764fba451be5e975ae7c5eefb1a25ac2bf2c Related: OS#3075
* LCLS: use proper types for value_string wrappersMax2019-01-091-3/+3
| | | | Change-Id: I0f47a610e06ac99bd60a5aad6f50f3658480165e
* Cosmetic: GSUP: note "on wire" for imei_resultOliver Smith2019-01-091-2/+2
| | | | | | | | | | | | | | Note that OSMO_GSUP_IMEI_RESULT_ACK is 0 on the wire, although the enum value is 1. Same with NACK (1 on wire, enum 2). I had implemented enum osmo_gsup_imei_result after enum osmo_gsup_cancel_type above, where this comment exists as well, and I incorrectly assumed that enum osmo_gsup_cn_domain in the middle was also implemented this way and therefore adding the comments to each enum would be redundant. But for cn_domain, the values on the wire are the same as the enum values. Change-Id: If97c34f117bfaab2232bbb625e9d118c8f390e58
* msgb: fix debug printMax2019-01-091-1/+1
| | | | | | | | Since osmo_hexdump() use static buffers we can't re-use pointers to it after subsequent osmo_hexdump() calls. Let's print data used for comparison directly instead. Change-Id: I24dc3fad6f64ef788da9b7d790f9d5f689190c42
* add osmo_lu_type_names[], osmo_lu_type_name()Neels Hofmeyr2019-01-083-0/+13
| | | | | | Move lupd_names[] from osmo-msc to libosmo-gsm. Change-Id: Ica25919758ef6cba8348da199b0ae7e0ba628798
* add osmo_mi_name(), for MI-to-string like "IMSI-123456"Neels Hofmeyr2019-01-085-0/+82
| | | | | | | | We have gsm48_mi_to_string() and osmo_bcd2str(), but still lack a function that conveniently prints both MI type and value in one function call. Related: http://people.osmocom.org/neels/mi_mi_mi.jpg Change-Id: I7798c3ef983c2e333b2b9cbffef6f366f370bd81
*