aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2019-02-26use osmo_static_string() instead of numerous static buffersneels/static_stringsNeels Hofmeyr15-96/+122
Change-Id: Id0eab72fa71630c8eb9edafaa370a41ca16329aa
2019-02-26add osmo_string_ringbuffer and osmo_static_string() APINeels Hofmeyr4-0/+639
Change-Id: I48f8951de4d209d4cd3ca1aa9ce6137918913125
2019-02-26fix api doc typo for osmo_plmn_name2()Neels Hofmeyr1-1/+1
Change-Id: Ic2652c7e4ffe1e707022168ac6c0da7c88ae7f45
2019-02-22Add multipatch capability to osmo-config-mergeMax1-21/+45
That's pretty straightforward and convenient extention: handle all extra positional arguments as patch file names. This makes it similar to 'cp' and other coreutils basic tools. For example: osmo-config-merge base.cfg patch1.cfg patch2.cfg patch3.cfg will apply 3 patches to the base config file. Change-Id: I212cbdc3bf6f251c1a3175737ac74242fb004c6d
2019-02-21select: Call log_reset_context() before calling file descriptor callbacksHarald Welte1-0/+6
Make sure to clear any log context before processing the next incoming message as part of some file descriptor callback. This effectively prevents "context leaking" from processing of one message into processing of the next message as part of one iteration through the list of file descriptors here. Change-Id: I3644c7bc1a9cec5858eb0faf94efc8c3ba7f5d8d Closes: OS#3813
2019-02-19gprs_ns: Add missing NSVCI IE to NS-BLOCK-ACK messageHarald Welte1-1/+29
According to Section 9.2.4 of 3GPP TS 48.016, the NS-BLOCK-ACK PDU has a mandatory NSVCI IE which we so far were missing. Change-Id: Ie7205e99d57f1e42d941f1be2460d8c9f46aadfe Closes: OS#3808
2019-02-19gprs_ns: Declare gprs_ns_tx_alive*() in header fileHarald Welte1-0/+2
The symbols for those functions were always exported, but we somehow didn't declare them in gprs_ns.h Change-Id: Ib073e9c93fcdf408b63000182e90aabce37f687e
2019-02-19gprs_ns.c: cosmetic whitespace fixesHarald Welte1-2/+2
Change-Id: Ic19f65bdc5527ad5a69d0a92320ce5f672bf4d2b
2019-02-19gprs_ns: Use gprs_ns_tx_alive() instead of gprs_ns_tx_simple()Harald Welte1-2/+2
If we use gprs_ns_tx_alive() we will get logging for free. Change-Id: I53d410d13540d389096c40425e1fa2eb7460b16b
2019-02-19bssgp_tx_bvc_unblock(): Fix log messageHarald Welte1-1/+1
We're transmitting a BVC-UNBLOCK but the log states the opposite: BVC-BLOCK. Let's fix that. Change-Id: I70fa7336402d193513f89fcf3068b0b21925702d
2019-02-18rsl: Support PDCH in rsl_chan_nr_strPau Espin Pedrol1-0/+2
During log review lack of support for PDCH was spotted: scheduler.c:593 Configuring multiframe with PDCH trx=0 ts=4 rsl.c:1159 (bts=0,trx=0,ts=4,ss=0): chan_nr=UNKNOWN on TS4 type=0x00 mode=SIGNALLING rsl.c:741 (bts=0,trx=0,ts=4,pchan=TCH/F_TCH/H_PDCH as PDCH) (ss=0) PDTCH Tx CHAN ACT ACK Wireshark shows: 1100 0... = C-bits: PDCH (24) .... .100 = Time slot number (TN): 4 Change-Id: If6ed96c9eb0431eb24e2135634def61e0ea506ea
2019-02-18gsm0808: Add unit tests for test_create_clear_command2()Harald Welte2-0/+26
Change-Id: Ie3f34b78edc91a013152742bebbd839586a787fe Related: OS#3805
2019-02-18gsm0808: comment about difference of gsm0808_create_clear_command()Harald Welte1-1/+4
This single function has a quite different behavior than the other gsm0808_ functions in terms of how the resulting msgb l3h pointers are set. Let's document that to avoid more confusion. Change-Id: I0367760a588fc968c5a2dea46001ef1ee7965c8c
2019-02-18Fix BSSMAP length generated by gsm0808_create_clear_command2()Harald Welte1-1/+7
In Change-Id Id8a75e1da2d5f520064666e4ee413d1c91da6ae3 we recently introduced adding the "CSFB INDICATOR" IE to the CLEAR COMMAND, but we did so with a wrong length value. Change-Id: I4d07d25fb03ca0f89fd7b94226c54309c77a010a Closes: OS#3805 Related: OS#2778
2019-02-17add OSMO_STRBUF_PRINTF()Neels Hofmeyr3-0/+188
We are using macros like this or different workarounds in libmsc. In the course of implementing inter-MSC handover, I am encountering yet another such situation of appending multiple strings to a limited char buffer. Standardize. Add a unit test to utils_test.c. Change-Id: I2497514e26c5e7a5d88985fc7e58343be1a027b2
2019-02-17gsm_08_08.h: Add constants for Channel Type in signalling modeSylvain Munaut1-0/+14
This is from TS 08.08 3.2.2.11 directly. The choices for Data mode and Speech mode were already present, but not for Signalling mode Change-Id: I9e24841ea877a9a78dc4d2bd14cbf60c4bea79a6 Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
2019-02-15fix osmo_gsm48_classmark* libosmogsm.map entriesNeels Hofmeyr1-6/+6
When the initial patch was tweaked from osmo_classmark_* to osmo_gsm48_classmark_* naming, the libosmogsm.map entries were forgotten to be changed as well. Change-Id: I53a41b5e965a529d3c146ee85102f7f1725c6014
2019-02-15get_value_string(): guard against NULLNeels Hofmeyr1-0/+3
get_value_string() conveniently prints the value number to a static buffer if it is unknown in a value_string array. Do the same if the value_string array pointer itself is NULL. If a value string array is user supplied and might be NULL, one could add a separate NULL check around it; but by making get_value_string() itself guard against NULL, another static char buffer to print the value number is avoided. Change-Id: Ie640e9258a959da8f4f9089478de993509853997
2019-02-14Enable remote SIM protocol log levelMax2-1/+6
It's defined in logging.h for quite some time but is not actually enabled alongside with other internal logging categories. Change-Id: I0e7a2add6293a072752900608c8ba34cc3850f31
2019-02-08gsm/gsm0480: introduce gsm0480_create_release_complete()Vadim Yanitskiy3-1/+26
In OsmoMSC, it's required to be able to specify a particular GSM 04.07 transaction ID for GSM 04.80 Release complete message instead of the hard-coded value, that is used gsm0480_create_ussd_release_complete(). Let's finally deprecate gsm0480_create_ussd_release_complete(), and introduce a new function without USSD prefix, as this message is also used in other "structured" supplementary services. Change-Id: Ie3ac85fcef90a5e532334ba3482804d5305c88d7
2019-02-07protocol/gsm_04_14: Fix the OPEN LOOP message typeSylvain Munaut1-1/+1
Change-Id: Id4350dee4353ebf9de0450dd5dab6e4f2ee7c3a6 Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
2019-02-06platform independence fix: tdef range testsNeels Hofmeyr8-133/+490
Run INT_MAX and ULONG_MAX related tests only manually, remove from automatic testing. This will hopefully fix recent build failures on various platforms. Add a 64 bit output example for expected results when invoking `./tdef_test range'. This is not checked automatically and merely serves for manual reference. For vty tests, use 32bit max values instead of INT_MAX and ULONG_MAX. Change-Id: I6242243bde1d7ddebb858512a1f0b07f4ec3e5c2
2019-02-05gsm0808: Add CSFB indication IE to BSSMAP CLEAR COMMANDPhilipp Maier3-0/+18
When a call that was established in a CSFB context ends the CLEAR COMMAND that is send from the BSC to the MSC should contain a CSFB indication IE, which consists of just the IE byte itsslef. This additional IE tells the BSC to include other CSFB related IEs into the RR Release message. Change-Id: Id8a75e1da2d5f520064666e4ee413d1c91da6ae3 Related: OS#3778
2019-02-05bitvec: Add bitvec_tailroom_bits() functionHarald Welte2-0/+25
This is similar to msgb_tailroom(): It returns the amount of space left at the end of the bit vector (compared to the current cursor). The function returns the number of bits left in the bitvec. Change-Id: I8980a6b6d1973b67a2d9ad411c878d956fb428d1
2019-02-05bitvec: Add bitvec_bytes_used() functionHarald Welte3-0/+37
This new bitvec API function returns the number of bytes used in a given bit-vector. Change-Id: Id4bd7f7543f5b0f4f6f876e283bd065039c37646
2019-02-05gsm_08_08.h: Add IEI definitions from Release 15Harald Welte1-0/+5
Change-Id: If3649606ba7c25121e30ed02939ca08c94665be5
2019-02-05Extend gsm_04_08.h with CSFB related definitiosn form 44.018 Rel 15Harald Welte1-0/+2
These are some IEI definitions that we'll need for CSFB Fast Return Change-Id: I0e101af316438b56d63d43fc2cb16d7caf563d07
2019-02-04add osmo_tdef API, originally adopted from osmo-bsc T_defNeels Hofmeyr18-2/+2998
Move T_def from osmo-bsc to libosmocore as osmo_tdef. Adjust naming to be more consistent. Upgrade to first class API: - add timer grouping - add generic vty support - add mising API doc - add C test - add VTY transcript tests, also as examples for using the API From osmo_fsm_inst_state_chg() API doc, cross reference to osmo_tdef API. The root reason for moving to libosmocore is that I want to use the mgw_endpoint_fsm in osmo-msc for inter-MSC handover, and hence want to move the FSM to libosmo-mgcp-client. This FSM uses the T_def from osmo-bsc. Though the mgw_endpoint_fsm's use of T_def is minimal, I intend to use the osmo_tdef API in osmo-msc (and probably elsewhere) as well. libosmocore is the most sensible place for this. osmo_tdef provides: - a list of Tnnnn (GSM) timers with description, unit and default value. - vty UI to allow users to configure non-default timeouts. - API to tie T timers to osmo_fsm states and set them on state transitions. - a few standard units (minute, second, millisecond) as well as a custom unit (which relies on the timer's human readable description to indicate the meaning of the value). - conversion for standard units: for example, some GSM timers are defined in minutes, while our FSM definitions need timeouts in seconds. Conversion is for convenience only and can be easily avoided via the custom unit. By keeping separate osmo_tdef arrays, several groups of timers can be kept separately. The VTY tests in tests/tdef/ showcase different schemes: - tests/vty/tdef_vty_test_config_root.c: Keep several timer definitions in separately named groups: showcase the osmo_tdef_vty_groups*() API. Each timer group exists exactly once. - tests/vty/tdef_vty_test_config_subnode.c: Keep a single list of timers without separate grouping. Put this list on a specific subnode below the CONFIG_NODE. There could be several separate subnodes with timers like this, i.e. continuing from this example, sets timers could be separated by placing timers in specific config subnodes instead of using the global group name. - tests/vty/tdef_vty_test_dynamic.c: Dynamically allocate timer definitions per each new created object. Thus there can be an arbitrary number of independent timer definitions, one per allocated object. T_def was introduced during the recent osmo-bsc refactoring for inter-BSC handover, and has proven useful: - without osmo_tdef, each invocation of osmo_fsm_inst_state_chg() needs to be programmed with the right timeout value, for all code paths that invoke this state change. It is a likely source of errors to get one of them wrong. By defining a T timer exactly for an FSM state, the caller can merely invoke the state change and trust on the original state definition to apply the correct timeout. - it is helpful to have a standardized config file UI to provide user configurable timeouts, instead of inventing new VTY commands for each separate application of T timer numbers. Change-Id: Ibd6b1ed7f1bd6e1f2e0fde53352055a4468f23e5
2019-02-04doxygen: allow manual 'make apidoc' even if --disable-doxygenNeels Hofmeyr1-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
2019-02-04doxygen: add source files as dependenciesNeels Hofmeyr1-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
2019-02-04doxygen: enable cross referencing everywhereNeels Hofmeyr8-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
2019-02-04vty api: add vty_out_va()Neels Hofmeyr2-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
2019-02-04vty telnet: consistently never change nodes upon CTRL-CNeels Hofmeyr1-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
2019-02-04vty: enable tab-completion for optional-multi-choice argsNeels Hofmeyr1-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
2019-02-04vty: enable optional-multi-choice syntax: [(one|two)]Neels Hofmeyr3-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
2019-02-04vty: enable optional-multi-choice syntax: ([one]|[two])Neels Hofmeyr2-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
2019-02-04add generic vty_transcript_test.c, vty_transcript_test.vtyNeels Hofmeyr3-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
2019-02-04socket.h: add missing includeMax1-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
2019-02-04GSUP: deprecate osmo_gsup_get_err_msg_type()Oliver Smith2-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
2019-01-31osmo_fsm_inst_state_chg(): clamp timeout_secs to <= ~68 yearsNeels Hofmeyr1-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
2019-01-29osmo_fsm_inst_state_chg(): set T also for zero timeoutNeels Hofmeyr4-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
2019-01-29jenkins distcheck: enable external testsNeels Hofmeyr1-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
2019-01-29build: add missing logging_vty_test.vty to EXTRA_DISTNeels Hofmeyr1-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
2019-01-29osmo_fsm_state_name: make robust against NULL fiNeels Hofmeyr1-1/+1
Change-Id: I61d4f7dfada2763948f330745ac886405d889a12
2019-01-29add osmo_classmark_* APINeels Hofmeyr3-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
2019-01-28add osmo_hexdump_buf() and testNeels Hofmeyr4-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
2019-01-28gsm0808: add BSSMAP Cell Identifier matching APINeels Hofmeyr7-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
2019-01-22Work around bogus gcc-8.2 array-bounds warning/errorHarald Welte2-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
2019-01-22constrain gsm48_generate_mid() output array boundsHarald Welte4-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
2019-01-22gsm0408_test: Fix IMEI-SV related tests to use no more than 16 digitsHarald Welte2-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