summaryrefslogtreecommitdiffstats
path: root/src/gsm
Commit message (Collapse)AuthorAgeFilesLines
* gsm48_encode_bcd_number(): clarify optional LHV header initializationVadim Yanitskiy2019-05-291-1/+7
| | | | Change-Id: Iafd911dd55691b3715391e3899cd6971245c8d7f
* rest_octets: Remove SI2ter + SI2bis encoders that don't do anythingHarald Welte2019-05-282-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
* rest_octets: Implement actual SI6 rest octets encodingHarald Welte2019-05-281-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
* rest_octets: Add function to parse SI3 rest octetsHarald Welte2019-05-282-0/+79
| | | | | | Change-Id: I690cf308311f910005a325d50f5d5d825678d2b2 Related: OS#3075 Related: OS#4023
* rest_octets: Suffix encoder functiosn with _encodeHarald Welte2019-05-282-18/+20
| | | | | | ... otherwise it's not really clear what they do. Change-Id: I08e0ca9a8d13c7aa40b9d90f34f0e13adb87d4e0
* rest_octets: Fix export of osmo_gsm48_rest_octetsHarald Welte2019-05-281-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
* rest_octets: Actually include gsm48_rest_octets.c in Makefile.amHarald Welte2019-05-281-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
* rest_octets: Use correct symbols names for range encoderHarald Welte2019-05-281-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
* gsm48_rest_octets: Fix license: GPLv2+ instead of AGPLv3+Harald Welte2019-05-281-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
* gsm48_decode_bcd_number2(): return -EINVAL if LV has too big lengthVadim Yanitskiy2019-05-281-2/+2
| | | | Change-Id: Ie07b2e8bc2f9628904e88448b4ee63b359655123
* gsm48_decode_bcd_number2(): fix: return -ENOSPC on truncationVadim Yanitskiy2019-05-281-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
* gsm48_decode_bcd_number2(): fix output truncationVadim Yanitskiy2019-05-281-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
* oap_client: Fix license: GPLv2+ instead of AGPLv3+Harald Welte2019-05-271-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
* rsl: Add osmocom-specific extensions to RSL channel numbers for CBCHHarald Welte2019-05-271-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
* lapdm_rslms_recvmsg: Fix memory leak in error pathHarald Welte2019-05-191-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
* TLV: Add one-shot TLV encoderHarald Welte2019-05-192-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
* gsm_23_003: add GSM23003_MSISDN_{MIN,MAX}_DIGITSOliver Smith2019-05-151-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
* gsm0808: Introduce Osmocom extensions to announce Osmux supportPau Espin Pedrol2019-05-133-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
* gsm0808_utils: Introduce gsm0808_msgb_put_cell_id_u()Harald Welte2019-05-102-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
* Add MO-FALLBACK-VALUE SGsAP IEOmar Ramadan2019-05-101-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
* Bump version: 1.0.1.143-cc72c → 1.1.0Pau Espin Pedrol2019-05-071-1/+1
| | | | Change-Id: I351411ca5913c8b40f23287ec7c9ebfe11bd2bb0
* add gsm0808_create_handover_request_ack2 to add AoIP RTP addrNeels Hofmeyr2019-05-052-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
* osmo_gsup_decode(): properly check IMSI, avoid deprecationNeels Hofmeyr2019-05-051-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
* gsm48_decode_bcd_number2(): allow avoiding deprecationNeels Hofmeyr2019-05-051-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
* gsm48_decode_bcd_number2(): fix input len checkNeels Hofmeyr2019-05-051-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
* add gsm48_decode_bcd_number2() from osmo-mscNeels Hofmeyr2019-05-032-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
* BSSMAP: add messages for inter-BSC and inter-MSC HandoverNeels Hofmeyr2019-05-032-0/+175
| | | | Change-Id: I9dac375331f6bea744769e973725d58e35f87226
* BSSMAP: tweaksNeels Hofmeyr2019-04-261-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
* GSUP: add inter-MSC handover related msgs and IEsOliver Smith2019-04-261-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
* GSUP: add Message Class IENeels Hofmeyr2019-04-132-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
* gsm/gsm_utils.c: indicate intentional fall-throughVadim Yanitskiy2019-04-121-0/+1
| | | | | Change-Id: Ica7d2d1884b745fe30234d6c50d93828c4930680 Fixes: CID#57700
* gsm_utils.c: fix Doxygen description for gsm_get_octet_len()Vadim Yanitskiy2019-04-111-4/+4
| | | | Change-Id: Id6fd2cd33be1cb7cd7ff6a43bfcfb1f368304522
* Add _c versions of functions that otherwise return static buffersHarald Welte2019-04-108-4/+238
| | | | | | | | | | | | | | We have a habit of returning static buffers from some functions, particularly when generating some kind of string values. This is convenient in terms of memory management, but it comes at the expense of not being thread-safe, and not allowing for two calls of the related function within one printf() statement. Let's introduce _c suffix versions of those functions where the caller passes in a talloc context from which the output buffer shall be allocated. Change-Id: I8481c19b68ff67cfa22abb93c405ebcfcb0ab19b
* gsm_utils: fix use buf_len instead of sizeof in osmo_dump_gsmtime_bufPhilipp Maier2019-04-081-1/+1
| | | | | | | | | | The function osmo_dump_gsmtime_buf gets a pointer *buf and a parameter buf_len. The pointer *buf is a string buffer and the function places an \0 at the end of the buffer before it exists. However it uses sizeof(buf) as part of the index calculation, which is incorrect. Lets correct this by using buf_len instead. Change-Id: Id24263aa7c9a53544f1639b6ceb09ce5615d5114
* Add _buf() functions to bypass static string buffersHarald Welte2019-04-038-77/+267
| | | | | | | | | | | | | | | We have a number of static buffers in use in libosmo*. This means the related functions are not usable in a thread-safe way. While we so far don't have many multi-threaded programs in the osmocom universe, the static buffers also prevent us from calling the same e.g. string-ify function twice within a single printf() call. Let's make sure there's an alternative function in all those cases, where the user can pass in a caller-allocated buffer + size, and make the 'classic' function with the static buffer a wrapper around that _buf() variant. Change-Id: Ibf85f79e93244f53b2684ff6f1095c5b41203e05
* ipa: Fix ipa_ccm_id_resp_parse on big endian systemsPau Espin Pedrol2019-03-281-2/+2
| | | | Change-Id: Iedc46ab53a4f76bbd98741c065fad3d9042a34a4
* ipa: Document ipa_ccm_idtag_parse_off and fix ipa_ccm_idtag_parsePau Espin Pedrol2019-03-281-1/+11
| | | | | | | | | | | | | | | | | | | | | ipa_ccm_idtag_parse_off is broken, and can only be used with len_offset=1 on ID Request messages, otherwise won't work correctly. Modify ipa_ccm_idtag_parse to at least parse those correctly, and document the limitations. Those two functions are already deprecated and only used in openbsc by 3 callers: * ipa_ccm_idtag_parse in ussd_read_cb(): Broken, that function can only work for Requests and it's used to parse a Response. * ipa_ccm_idtag_parse_off in forward_sccp_to_msc (NAT): Broken, it can only be used to parse Requests and it's used to parse a Response. Furthermore, len_offset=2 is passed which makes no sense and most probably it fails always, or can even make the program crash. * ipa_ccm_idtag_parse_off in (answer_challenge): This one is fine and could actually be replaced with ipa_ccm_id_get_parse after this commit is merged. Change-Id: I6efc852dfc041192f554e41a58290a0f63298021
* Revert "ipa_ccm_idtag_parse*: Fix reported length value"Oliver Smith2019-03-251-1/+1
| | | | | | | | | | | | This reverts commit 1261db15058cfa94615f26c1083bb8a38d09218b. The patch broke openbsc's external tests, and currently it is unclear whether it is just an error in the test or if openbsc makes wrong assumptions about the length value. Let's revert the patch to unblock the master-openbsc jenkins job. Related: OS#3851 Change-Id: I9adea35ff6de36c1611c7f85dde1b15bc1c0e786
* ipa_ccm_idtag_parse*: Fix reported length valueHarald Welte2019-03-191-1/+1
| | | | | | | | | | | | | | | IPA CCM is using a somewhat weird TLV encoding scheme: * 16bit length (of tag and value) * 8bit tag * value Our existing code mapping the CCM to 'struct tlv_parse' used the plain length value without accounting for the one-byte tag. This patch ensures we only report the length of the "value" part, excluding the tag. Change-Id: I435aaa33605bd48635715a2c81aa2d231c1abf51
* osmo_gsm48_classmark_a5_name(): fix 'no-cm3' labelNeels Hofmeyr2019-03-141-1/+1
| | | | Change-Id: Id84021858dfb2f7d6a7cf81ae73bd94cd47f6776
* Fix build on non-glibc systemsKarl Koscher2019-03-111-3/+8
| | | | Change-Id: Id5d577522a4889e152158f7e93ee1c99d3a21003
* gsm0808_utils: fix gsm48 multirate to S-bit converterPhilipp Maier2019-03-111-0/+10
| | | | | | | | | | | | The function gsm0808_sc_cfg_from_gsm48_mr_cfg() is used to convert a gsm48 multirate struct into a set of S-bits (S0 to S15). However, the conversion function currently does not take into account that bit S1 actually stands for four rates at once (Config-NB-Code = 1). Lets make sure that S1 is only set when the multirate configuration permits all four required rates. Change-Id: I6ad531d4e70c2252e32e2bbaca8e14a7ec6d9840 Related: SYS#4470
* gsm0808_utils: fix gsm48 multirate configuration generatorPhilipp Maier2019-03-111-21/+73
| | | | | | | | | | | | | | | | | The function gsm0808_sc_cfg_from_gsm48_mr_cfg() takes an S15 to S0 bitmask and converts that bitmask into an AMR multirate configuration struct. Unfortunately the current implementation implements 3GPP TS 28.062, Table 7.11.3.1.3-2 wrongly in some aspects. Lets fix this. - Fix wrong interpretation of the bitpatterns - 5,15K is invalid and must never be selected - Make sure that no more than 4 rates are selected in the active set - Extend unit-test Change-Id: I6fd7f4073b84093742c322752f2fd878d1071e15 Related: SYS#4470
* add gsm0808_cell_id_from_cgi(), gsm0808_cell_id_to_cgi()Neels Hofmeyr2019-03-082-0/+89
| | | | | | | | | | | | | | | | CGI to Cell ID: for example, for Paging, osmo-msc has a CGI for a subscriber and needs to send out a Cell Identifier IE. Makes sense to add this conversion here. Cell ID to CGI: for a Layer 3 Complete, a subscriber sends the current cell in the form of a Cell Identifier, which we store as a CGI, if necessary enriched with the local PLMN. Add enum with bitmask values to identify parts of a CGI, for the return value of gsm0808_cell_id_to_cgi(). Can't use enum CELL_IDENT for that, because it doesn't have a value for just a PLMN (and is not a bitmask). Change-Id: Ib9af67b100c4583342a2103669732dab2e577b04
* api doc: tweak gsm0808_cell_id_matches_list() docNeels Hofmeyr2019-03-051-1/+2
| | | | Change-Id: Ide94558d1c31356483252b83e04b061b4ee4d3bf
* fix api doc typo for osmo_plmn_name2()Neels Hofmeyr2019-02-261-1/+1
| | | | Change-Id: Ic2652c7e4ffe1e707022168ac6c0da7c88ae7f45
* LCLS: add string dump helpersMax2019-02-263-0/+45
| | | | | | | | | Add functions to dump LCLS (without GCR) and GCR. Dumping entire struct results in inconveniently long string hence the separate functions. Both use talloc functions so they expect caller to take care of providing proper allocation context and freeing memory. Change-Id: Ic3609224c8f3282d667e75f68bc20327e36eb9e6
* rsl: Support PDCH in rsl_chan_nr_strPau Espin Pedrol2019-02-181-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
* gsm0808: comment about difference of gsm0808_create_clear_command()Harald Welte2019-02-181-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
* Fix BSSMAP length generated by gsm0808_create_clear_command2()Harald Welte2019-02-181-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
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-30 12:08:31 +0000