path: root/src
AgeCommit message (Collapse)AuthorFilesLines
2019-05-28rest_octets: Remove SI2ter + SI2bis encoders that don't do anythingHarald Welte2-33/+0
The library should either provide functions that implement encoding of those rest octets, or it shouldn't. Providing a function that doesn't do anything but pad the buffer is useless. Change-Id: Ie10684de6a6b2663e2a871fcdb2b275b6ad7a1e7
2019-05-28rest_octets: Implement actual SI6 rest octets encodingHarald Welte1-11/+35
There's very little sense behind introducing a function into libosmogsm which doesn't implement 90% of the spec. Let's allow the caller to provide the various optional bits of information to the encoder, rather than generating mostly static SI6 rest octets. Change-Id: Id75005a0c4a02ce7f809692d58b3bd226bc582b2
2019-05-28rest_octets: Add function to parse SI3 rest octetsHarald Welte2-0/+79
Change-Id: I690cf308311f910005a325d50f5d5d825678d2b2 Related: OS#3075 Related: OS#4023
2019-05-28rest_octets: Suffix encoder functiosn with _encodeHarald Welte2-18/+20
... otherwise it's not really clear what they do. Change-Id: I08e0ca9a8d13c7aa40b9d90f34f0e13adb87d4e0
2019-05-28rest_octets: Fix export of osmo_gsm48_rest_octetsHarald Welte1-8/+8
the symbols had an omso_ prefix, while the entry in the .map file didn't. As a result, all related symbols were never exported and hence not usable by any users of the dynamic library. Change-Id: I8b1ee2405f6338507e9dfb5f1f437c4c2db2e330
2019-05-28rest_octets: Actually include gsm48_rest_octets.c in Makefile.amHarald Welte1-1/+1
The gsm48_rest_octets.c file was added in Change-Id I47888965ab11bba1186c21987f1365c9270abeab, but it never actually ended up being compiled as it wasn't listed in the makefile :/ Change-Id: I0355115c2645f236c9e32cf7a563cf51a857e8a3 Relsted: OS#3075
2019-05-28rest_octets: Use correct symbols names for range encoderHarald Welte1-4/+4
As gsm48_rest_octets.c is not listed in the Makefile.am, it's never actually compiled and we never noticed that it's calling functions by symbol names that don't exist :/ Change-Id: I7b1e436f70e0c60979261db87606f38271ec47d3 Related: OS#3075
2019-05-28gsm48_rest_octets: Fix license: GPLv2+ instead of AGPLv3+Harald Welte1-4/+6
libosmo{core,gsm,vty} code is GPLv2+. The rest octet code originated in osmo-bsc.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. Original copyright is mine. For contributions by sysmocom, I as the managing director can approve the license change. This means only Holger needs to ACK this. Change-Id: Ief3009dc28dd83e1e26a7101af2eed2341684a87
2019-05-28gsm48_decode_bcd_number2(): return -EINVAL if LV has too big lengthVadim Yanitskiy1-2/+2
Change-Id: Ie07b2e8bc2f9628904e88448b4ee63b359655123
2019-05-28gsm48_decode_bcd_number2(): fix: return -ENOSPC on truncationVadim Yanitskiy1-3/+13
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-27tdef: Fix license: GPLv2+ instead of AGPLv3+Harald Welte2-8/+9
libosmo{core,gsm,vty} code is GPLv2+. The tdef 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: Ie483ff6f6ea0a56c477649677b4b163c49df11d7
2019-05-27oap_client: Fix license: GPLv2+ instead of AGPLv3+Harald Welte1-4/+6
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-27rsl: Add osmocom-specific extensions to RSL channel numbers for CBCHHarald Welte1-0/+10
We don't really *need* it in libosmocore as such, but the lack of having all osmocom extensions listed here lead to using overlapping definitions: 0x18 was used for dynamic PDCH on the Abis side, but also for CBCH on the L1SAP side. Let's list them all here to increase visibility in case anyone wants to extend this further... Related: OS#4027 Change-Id: I93e557358cf1c1b622f77f906959df7ca6d5cb12
2019-05-19lapdm_rslms_recvmsg: Fix memory leak in error pathHarald Welte1-1/+3
The caller of lapdm_rslms_recvmsg() (e.g. osmo-bts/src/common/rsl.c) assumes the message ownership is transferred. However, in one of the two error paths, msgb_free() was not called and hence we had a memory leak. Also clarify the msgb ownership transfer in a comment. Related: OS#3750 Change-Id: Id60cb45e50bfc89224d97df6c68fcd2949751895
2019-05-19TLV: Add one-shot TLV encoderHarald Welte2-0/+100
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-18pseudotalloc: turn talloc_steal() into #defineHarald Welte2-2/+3
Any non-anciant version of talloc implements talloc_steal() as a #define using the _talloc_steal_loc() symbol. Let's be more compatible. This fix is relevant to using osmo_fsm inside the osmo-ccid-firmware builds for Cortex-M4. In this situation, for some strange reason, libosmcoore is compiled using src/pseudotalloc/talloc.h, but later then linked against the real libtalloc. Change-Id: I1ee7f5e9b1002cff37bb8341ad870e1da5f1f9ff
2019-05-15codec/ecu: Add a bit of precision about the actual frame format usedSylvain Munaut1-2/+7
Change-Id: I9620088e449c31e966ecb9ec5ddf283b949c5a4a Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
2019-05-15gsm_23_003: add GSM23003_MSISDN_{MIN,MAX}_DIGITSOliver Smith1-1/+1
Add the constant, so it can be used in create-subscriber-on-demand related patches. ITU-T Rec. E.164 6.1 states that maximum international number length should be 15. I did not find a source for a minimum length, but I've added the constant and set it to 1 for consistency (based on the existing osmo_msisdn_str_valid() function). Related: OS#2542 Change-Id: Idc74f4d94ad44b9fc1b6d43178f5f33d551ebfb1
2019-05-13gsm0808: Introduce Osmocom extensions to announce Osmux supportPau Espin Pedrol3-0/+24
IE GSM0808_IE_OSMO_OSMUX_SUPPORT (T, 1 byte) is sent in AoIP appended to BSSMAP RESET in order to announce the peer that its MGW supports handling Osmux streams upon call set up. IE GSM0808_IE_OSMO_OSMUX_CID (TV, T 1 byte & V 1 byte) is sent in AoIP during call set up: * MSC->BSC Assignment Request * BSC->MSC Assignemnt Complete The 1 byte value contains the local Osmux CID, aka the recvCID aka CID where the peer sending the Assign Req/Compl will look for Osmux frames on that call. Hence, the peer receiving this CID value must use it to send Osmux frames for that call. As a result, a given call leg BSC<->MSC can have one different Osmux CID per direction. For example: * MS => MGW_BSC ==CID 0==> MGW_MSC * MS <= MGW_BSC <=CID 1=== MGW_MSC This allows for setups with 256 call legs per BSC on scenarios where NAT is not a problem, where MSC can have a pool of 256 CID per MGW_BSC (or remote peer). Related: OS#2551 Change-Id: I28f83e2e32b9533c99e65ccc1562900ac2aec74e
2019-05-10NS: log address:port on errorMax1-2/+2
Change-Id: If2dc533a6dc150254f5d44b672f04bb728e7e927
2019-05-10osmo_sock_get_name_*: Ensure string is returned in error caseHarald Welte1-1/+3
osmo_sock_get_name_buf(): In case the getsockname() call is failing for some weird reason, we shouldn't return an uninitialized, non-zero-terminated string buffer to the caller, as most callers will be too lazy to test the return value. This holds even more true for users of the internal osmo_sock_get_name2() and osmo_sock_get_name2_c() functions which indeed very much ignore the return value of osmo_sock_get_name_buf(). Change-Id: I2d56327e96b7a6783cca38b828c5ee74aed776ae
2019-05-10Revert "Print error message if application fails to call rate_ctr_init()"Harald Welte1-5/+2
This reverts commit 9685a48c7bc83b1f5ee9b51e29419164b387ade2 which has caused massive fall-out among (particularly) unit tests in osmo-{msc,bts,pcu}. Change-Id: Iede72e86451d94cf678045992cb71f6b1bf16896
2019-05-10gsm0808_utils: Introduce gsm0808_msgb_put_cell_id_u()Harald Welte2-41/+43
This function is doing the bulk work of encoding a given Cell ID List item. gsm0808_enc_cell_id_list2() is modified to be a wrapper / loop around the new function. The purpose of this is to expose Cell ID List Entry encoding so that the upcoming CBSP protocol encoder can re-use this code. Related: OS#3537 Change-Id: I6cc567798e20365e6587e6b2988e834306d8c80c
2019-05-10Print error message if application fails to call rate_ctr_init()Harald Welte1-2/+5
Change-Id: Ie8093b66b7e27cf863d2558fe21b2c6e0f3fcdfd Closes: OS#3580
2019-05-10Fix osmo_quote_str_c() for strings larger than 32 bytesHarald Welte1-2/+13
As Neels pointed out, we shouldn't pass a constant value of 32 to osmo_quote_str_buf2(). Change-Id: Id9bde14166d6674ce4dda36fa9f4ae9217ce5cc2
2019-05-10Add MO-FALLBACK-VALUE SGsAP IEOmar Ramadan1-0/+2
In testing against a particular EPC, the SGsAP-SERVICE-REQUEST can contain a MO fallback value TLV with T 0xF1 Change-Id: Ia2460af9673818d375e28c67f1631b5f7eacdaeb
2019-05-09fix typo in FSM descriptionKévin Redon1-4/+4
Change-Id: I3559e9c0769b708cee0d1b221b60960c62f15bd4
2019-05-08deal with rate_ctr_group_alloc() returning NULLHarald Welte2-0/+8
Change-Id: I47d6623b9eca704e3c2537cfb5799a4c0749a7bc Related: #3701
2019-05-07Bump version: → Espin Pedrol5-5/+5
Change-Id: I351411ca5913c8b40f23287ec7c9ebfe11bd2bb0
2019-05-07add osmo_stat_item_inc/osmo_stat_item_dec to set it relativeAlexander Couzens1-0/+24
Change-Id: Id2462c4866bd22bc2338c9c8f69b775f88ae7511
2019-05-05add gsm0808_create_handover_request_ack2 to add AoIP RTP addrNeels Hofmeyr2-9/+37
osmo-bsc so far omits the AoIP Transport Layer Address from its Handover Request Acknowledge message, which breaks inter-BSC Handover for AoIP. Allow fixing that. One quirk I really don't like about this: I would prefer to directly use struct sockaddr_storage as a member of the struct gsm0808_handover_request_ack. Even though struct sockaddr_storage appears in various function signatures, the gsm0808.c actually also gets built on embedded systems that lack arpa/inet.h (for me indicated by the ARM build job on jenkins). Compiling gsm0808.c works only because the actual coding of struct sockaddr_storage is implemented in gsm0808_util.c, which (apparently) does not get built on embedded and hence, even though there are undefined references to e.g. gsm0808_enc_aoip_trasp_addr() it works. Related: I4a5acdb2d4a0b947cc0c62067a67be88a3d467ff (osmo-bsc) Change-Id: Ia71542ea37d4fd2c9fb9b40357db7aeb111ec576
2019-05-05osmo_gsup_decode(): properly check IMSI, avoid deprecationNeels Hofmeyr1-3/+5
In osmo_gsup_decode(), call gsm48_decode_bcd_number2() to avoid deprecation warning, and also actually check the return value to detect invalid IMSI IEs. Change-Id: Iaded84d91baad5386c8f353c283b6b9e40a43b05
2019-05-05gsm48_decode_bcd_number2(): allow avoiding deprecationNeels Hofmeyr1-23/+25
gsm48_decode_bcd_number() is marked as deprecated, so gsm48_decode_bcd_number2() will cause deprecation warnings as long as it calls gsm48_decode_bcd_number(). Hence move the code to gsm48_decode_bcd_number2(). Change-Id: I81925e9afb3451de9b8a268d482f79ee20ca14d6
2019-05-05gsm48_decode_bcd_number2(): fix input len checkNeels Hofmeyr1-2/+3
The input_len argument for gsm48_decode_bcd_number2() includes the BCD length *and* the length byte itself, so add the missing +1. Also clarify the API doc for the input_len argument. Change-Id: I87599641325c04aae2be224ec350b1a145039528
2019-05-03add vty_is_active()Neels Hofmeyr1-0/+10
For async callbacks it is useful to determine whether a given VTY pointer is still valid. For example, in osmo-msc, a silent call can be triggered by VTY, which causes a Paging. The paging_cb then writes to the VTY console that the silent call has succeeded. Unless the telnet vty session has already ended, in which case osmo-msc crashes; e.g. from an osmo_interact_vty.py command invocation. With this function, osmo-msc can ask whether the vty pointer passed to the paging callback is still active, and skip vty_out() if not. Change-Id: I42cf2af47283dd42c101faae0fac293c3a68d599
2019-05-03add gsm48_decode_bcd_number2() from osmo-mscNeels Hofmeyr2-1/+28
gsm48_decode_bcd_number() is unable to provide proper bounds validation of input and output data, hence osmo-msc's vlr.c introduced a static decode_bcd_number_safe() a long time ago. Move to libosmocore. I need to use the same function to decode an MSISDN during inter-MSC Handover, instead of making it public in osmo-msc, rather deprecate the unsafe function and provide a safer version for all callers. Mark the old one deprecated. Change-Id: Idb6ae6e2f3bea11ad420dae14d021ac36d99e921
2019-05-03BSSMAP: add messages for inter-BSC and inter-MSC HandoverNeels Hofmeyr2-0/+175
Change-Id: I9dac375331f6bea744769e973725d58e35f87226
2019-04-26BSSMAP: tweaksNeels Hofmeyr1-2/+2
Change two instances of Speech Version values to enum gsm0808_permitted_speech. It is often not trivial to find the right values for a uint8_t member, giving the enum name makes it a lot easier/safer to use. In gsm0808_create_handover_required(), use msgb_tv_put() so that the enum's storage size doesn't matter. (Already used for handover_performed) Fix typo in doc of gsm0808_create_handover_required(). Change-Id: I6387836bab76e1fa42daa0f42ab94fc14b70b112
2019-04-26GSUP: add inter-MSC handover related msgs and IEsOliver Smith1-0/+127
Based on a draft created by Neels, which is the result of reading a MAP trace of two MSCs negotiating inter-MSC handovers, and of reading the TS 29.002, TS 29.010 and related specs: https://lists.osmocom.org/pipermail/openbsc/2019-January/012653.html I figured out that the "Handover Number" mentioned in the specifications is the same as the MSISDN IE that we already have, so we can use that instead of creating a new IE (example usage in tests/gsup/gsup_test.c). Create a new OSMO_GSUP_MSGT_E_ROUTING_ERROR message type, which the GSUP server uses to tell a client that its message could not be forwarded to the destination (see [1]). MAP has no related message. [1]: Change-Id: Ia4f345abc877baaf0a8f73b8988e6514d9589bf5 (osmo-hlr.git) Related: OS#3774 Change-Id: Ic00b0601eacff6d72927cea51767801142ee75db
2019-04-25bitcomp.c: fix missing Doxygen group closing tagVadim Yanitskiy1-1/+1
Change-Id: I01f837ac4c8644c0851c77c3f42eb44353cef0d7
2019-04-25application.c: drop wrong \references of osmo_init_ignore_signals()Vadim Yanitskiy1-1/+1
Change-Id: Ib08e15dd5d811662de46a1dfdb676b9a5b66b529
2019-04-13GSUP: add Message Class IENeels Hofmeyr2-0/+19
osmo-msc and osmo-hlr have distinct subsystems handling incoming GSUP messages. So far we decide entirely by message type which code path should handle a GSUP message. Thus no GSUP message type may be re-used across subsystems. If we add a GSUP message to indicate a routing error, it would have to be a distinct message type for subscriber management, another one for SMS, another one for USSD... To allow introducing common message types, introduce a GSUP Message Class IE. In the presence of this IE, GSUP handlers can trivially direct a received message to the right code path. If it is missing, handlers can fall back to the previous switch(message_type) method. Change-Id: Ic397a9f2c4a7224e47cab944c72e75ca5592efef
2019-04-12gsm/gsm_utils.c: indicate intentional fall-throughVadim Yanitskiy1-0/+1
Change-Id: Ica7d2d1884b745fe30234d6c50d93828c4930680 Fixes: CID#57700
2019-04-12gb/gprs_ns_sns.c: fix incorrect sizeof() calculationVadim Yanitskiy1-1/+1
Calling sizeof() on a pointer would result in getting size of the pointer (usually 4 or 8 bytes) itself, but not the size of the memory it points to. Change-Id: I83f55a9638b75d9097d37992f7c84707791f10f6 Fixes: CID#194266
2019-04-12Fix incorrect buffer size calculationVadim Yanitskiy3-11/+16
Calling sizeof() on a pointer to dynamically allocated memory would result in getting size of the pointer (usually 4 or 8 bytes) itself, but not the size of allocated memory. Change-Id: I8ffda4dea2b7f9b4b76dfeecad1fab6384c5a62c Fixes: CID#197629, CID#197628, CID#197627 Fixes: CID#197626, CID#197625, CID#197624
2019-04-12add identifier sanitation for setting FSM instance idsNeels Hofmeyr2-2/+51
We often compose FSM instance IDs from context information, for example placing an MSISDN string or IP:port information in the FSM instance id, using osmo_fsm_inst_update_id_f(). This fails if any characters are contained that don't pass osmo_identifier_valid(). Hence it is the task of the caller to make sure only characters allowed in an FSM id are applied. Provide API to trivially allow this by replacing illegal chars: - osmo_identifier_sanitize_buf(), with access to the same set of illegal characters defined in utils.c, - osmo_fsm_inst_update_id_f_sanitize() implicitly replaces non-identifier chars. This makes it easy to add strings like '' or '+4987654321' to an FSM instance id, without adding string mangling to each place that sets an id; e.g. replacing with '-' to yield '192-168-0-1:2342' or '-4987654321'. Change-Id: Ia40a6f3b2243c95fe428a080b938e11d8ab771a7
2019-04-12add osmo_{escape,quote}_str_buf2() for standard args orderingNeels Hofmeyr1-39/+95
To be able to append an escaped or quoted string using OSMO_STRBUF_APPEND_NOLEN(), the function signature must have the buf and len as first args, like most other *_buf() functions. Add osmo_escape_str_buf2() and osmo_quote_str_buf2() to match this signature. A recent patch [1] has changed the return value of osmo_escape_str_buf() to char*, removing the const. However, the functions may return const strings, hence re-add the const. The new signatures always return the non-const buffer. To avoid code duplication, implement osmo_quote_str_buf() and osmo_escape_str_buf() by calling the new functions. I decided to allow slight changes to the behavior for current osmo_escape_str() and osmo_escape_str_buf(), because impact on callers is minimal: (1) The new implementation uses OSMO_STRBUF_*, and in consequence osmo_quote_str() no longer prints an ending double quote after truncated strings; Before, a truncated output was, sic: "this string is trunca" and now this becomes, sic: "this string is truncat I decided to not keep the old behavior because it is questionable to begin with. It looks like the string actually ended at the truncation boundary instead of the reason being not enough space in the output buffer. (2) The new osmo_escape_str_buf2() function obviously cannot pass-thru an unchanged char* if no escaping was needed. Sacrifice this tiny optimization feature to avoid code duplication: - it is an unnoticeable optimization, - the caller anyway always passes a string buffer, - the feature caused handling strings and buffers differently depending on their content (i.e. code that usually writes out strings in full length "suddenly" truncates because a non-printable character is contained, etc.) I considered adding a skip_if_unescaped flag to the osmo_quote_str_buf2() function signature, but in the end decided that the API clutter is not worth having for all the above reasons. Adjust tests to accomodate above changes. [1] 4a62eda225ab7f3c9556990c81a6fc5e19b5eec8 Ibf85f79e93244f53b2684ff6f1095c5b41203e05 Change-Id: Id748b906b0083b1f1887f2be7a53cae705a8a9ae
2019-04-11add osmo_str_startswith()Neels Hofmeyr2-11/+15
Move from a static implementation in tdef_vty.c to utils.c, I also want to use this in osmo-msc. The point is that the telnet VTY allows unambiguous partly matches of keyword args. For example, if I have a command definition of: compare (apples|oranges) then it is perfectly legal as for the vty parser to write only compare app One could expect the VTY to then pass the unambiguous match of "apples" to the parsing function, but that is not the case. Hence a VTY function implementation is faced with parsing a keyword of "app" instead of the expected "apples". This is actually a very widespread bug in our VTY implementations, which assume that exactly one full keyword will always be found. I am now writing new commands in a way that are able to manage only the starts of keywords. Arguably, strstr(a, b) == a does the same thing, but it searches the entire string unnecessarily. Change-Id: Ib2ffb0e9a870dd52e081c7e66d8818057d159513
2019-04-11make osmo_sockaddr_str_is_set() NULL-safeNeels Hofmeyr1-1/+2
Obviously a NULL pointer should return false instead of segfaulting. Change-Id: Iac025cf4d556cbed99f3924cd9ca05a05881cd9a