summaryrefslogtreecommitdiffstats
path: root/src/gsm/gsup.c
Commit message (Collapse)AuthorAgeFilesLines
* gsup: Introduce OSMO_GSUP_NUM_VECTORS_REQ_IEHarald Welte2019-12-091-4/+15
| | | | | | | | | | | | | | This is a bit of a hack, as we want to maintain binary compatibility without breaking existing users of libosmocore. To do so, we use the 'num_auth_vectors' field in two ways now: * In the existing use case as part of SEND_AUTH_INFO_RESPONSE, it indicates the number of vectors stored in the 'auth_vectors' field * In the new use case as part of SEND_AUTH_INFO_REQUEST, it indicates the number of vectors actually requested by the MSC/SGSN/MME. Change-Id: Iaecc47280f8ce54f3e3a888c1cfc160735483d0f
* GSUP: rename E_ROUTING_ERROR to ROUTING_ERRORNeels Hofmeyr2019-11-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | GSUP routing was introduced when adding the E interface. Hence that was the first realm where routing errors could occur. I did notice back then that this message type was special: it does not convey a response to a particular message kind -- it does not make sense, for example, to return an Updating Location Error cause, and do that for all conceivable message types. Instead, this tells the sender that a deeper error exists, i.e. that the desired peer is completely gone and unreachable. I did not foresee though that for D-GSM, there would also be arbitrary GSUP proxy routing, and that this error is not limited to E interface semantics. From today's point of view, adding the "_E_" in the name was a mistake. Remove that "_E_" to yield OSMO_GSUP_MSGT_ROUTING_ERROR (with unchanged message type discriminator), but provide a #define linking the old name OSMO_GSUP_MSGT_E_ROUTING_ERROR to the new one. The only visible change should be that osmo_gsup_message_type_names[] now returns the new name without "_E_". I am not aware of any regression test fallout from that. Change-Id: Ic8e8bd11522d6c51ac7aaf946516cbce26bc6e1e
* gsup: add OSMO_GSUP_SUPPORTED_RAT_TYPES_IE and OSMO_GSUP_CURRENT_RAT_TYPE_IENeels Hofmeyr2019-09-281-0/+35
| | | | | | | | | | | | | | OSMO_GSUP_SUPPORTED_RAT_TYPES_IE corresponds to the Supported RAT Types Indicator from 3GPP TS 29.002. See 8.1.2 MAP_UPDATE_LOCATION service, which indicates the capabilities of the MSC/VLR to the HLR. So far, have room for eight RAT types in the gsup_msg. That is an arbitrary random choice without any rationale. OSMO_GSUP_CURRENT_RAT_TYPE_IE is useful to communicate the currently used RAN / RAT type of the current subscriber during Location Updating Request. Change-Id: I93850710ab55a605bf61b95063a69682a2899bb1
* 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
* 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-131-0/+18
| | | | | | | | | | | | | | | | | | 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
* GSUP: deprecate osmo_gsup_get_err_msg_type()Oliver Smith2019-02-041-28/+3
| | | | | | | | | | | | | | 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
* GSUP: add CHECK-IMEI messageOliver Smith2018-12-211-0/+23
| | | | | | | | | | | | | | Implement necessary messages for Procedure Check_IMEI_VLR (TS 23.018 Chapter 7.1.2.9). This lets the VLR ask the EIR to check if an IMEI is valid. In the Osmocom stack, we don't have an EIR and this request will be handled by the HLR. We will be able to store the IMEI in the HLR as side-effect (OS#2541). This is roughly based on TS 29.002 8.7.1 MAP_CHECK_IMEI service, but only implements the bare minimum required IEs (imei and imei_result). Related: OS#3733 Change-Id: I085819df0ea7f3bfeb0cabebb5fd1942a23c6155
* GSUP: fix missing osmo_gsup_get_err_msg_type()sOliver Smith2018-12-211-0/+8
| | | | | | | | | | | Add missing mappings of request to error message types in osmo_gsup_get_error_msg_type(): * PROC_SS_REQUEST * MO_FORWARD_SM_REQUEST * MT_FORWARD_SM_REQUEST * READY_FOR_SM_REQUEST Change-Id: I801a0d6ffe09cfc75b77ab602bd25b3dc40f19c0
* GSUP/SMS: introduce READY-FOR-SM messageVadim Yanitskiy2018-12-181-0/+13
| | | | | | | | | | | | | | | According to 3GPP TS 29.002, section 12.4, MAP-READY-FOR-SM is used between the MSC and VLR as well as between the VLR and the HLR to indicate that a subscriber has memory available for SMS. This change replicates this service in GSUP as READY_FOR_SM_*. The only mandatory IE for this service (excluding Invoke ID) is 'Alert Reason' that is replicated by OSMO_GSUP_SM_ALERT_RSN_IE. Change-Id: Ic37f3b2114b8095cfce22977e67133b9103942e3 Related Change-Id: (docs) I549b6c8840a1e86caac09e77fb8bc5042d939e62 Related Change-Id: (TTCN) If2256607527ecfcb10285583332fb8b0515d7c78 Related: OS#3587
* GSUP/SMS: introduce MO-/MT-FORWARD-SM messagesVadim Yanitskiy2018-12-181-1/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to 3GPP TS 29.002, there are two services: - MAP-MO-FORWARD-SHORT-MESSAGE (see 12.2), - MAP-MT-FORWARD-SHORT-MESSAGE (see 12.9), which are used to forward MO/MT short messages. This change replicates both services as GSUP messages: - OSMO_GSUP_MSGT_MO_FORWARD_SM_*, - OSMO_GSUP_MSGT_MT_FORWARD_SM_*. Please note, that only the 'must-have' IEs are introduced by this change, in particular the following: - OSMO_GSUP_SM_RP_MR_IE (see note below), - OSMO_GSUP_SM_RP_DA_IE (see 7.6.8.1), - OSMO_GSUP_SM_RP_OA_IE (see 7.6.8.2), - OSMO_GSUP_SM_RP_UI_IE (see 7.6.8.4), - OSMO_GSUP_SM_RP_MMS_IE (see 7.6.8.7), - OSMO_GSUP_SM_RP_CAUSE_IE (see GSM TS 04.11, 8.2.5.4), where both SM_RP_DA and SM_RP_OA IEs basically contain a single nested TV of the following format: - T: identity type (see 'osmo_gsup_sms_sm_rp_oda_t'), - V: encoded identity itself (optional). According to GSM TS 04.11, every single message on the SM-RL has an unique message reference (see 8.2.3), that is used to link an RP-ACK or RP-ERROR message to the associated (preceding) RP-DATA or RP-SMMA message transfer attempt. In case of TCAP/MAP, this message reference is being mapped to the Invoke ID. But since GSUP has no 'Invoke ID' IE, and it is not required for other applications (other than SMS), this change introduces a special 'SM_RP_MR' IE that doesn't exist in MAP. Change-Id: Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71 Related Change-Id: (docs) Ie0150756c33c1352bc4eb49421824542c711175c Related Change-Id: (TTCN) Ibf49474a81235096c032ea21f217170f523bd94e Related: OS#3587
* libosmogsm/gsup.c: fix error code in osmo_gsup_encode()Vadim Yanitskiy2018-10-211-1/+1
| | | | | | | Missing (unset) type of to be encoded message is not a memory allocation failure (-ENOMEM), this is definitely a mistake. Change-Id: Ibbac18e2b68b765c17c2bc959c4c085037953a7f
* gsup: Add value_string for Session State IEHarald Welte2018-06-161-0/+8
| | | | | | | | In Change-Id I1cee271fed0284a134ffed103c0d4bebbcfde2a8 we added support for a new session state IE, but we didn't add any value_string array for string conversion of it. Let's fix this. Change-Id: I3d9f087786dc37c42498fa9a2be07483ec93ba7b
* gsup: Add osmo_gsup_get_err_msg_type() functionHarald Welte2018-06-111-0/+23
| | | | | | | | This function can be used to resolve the error message type for a given message type. Can be used by generic error handlers that work for any incoming message type. Change-Id: Ic637bec53dd7fe3ec83da99b49b4eae34d5602b2
* GSUP: introduce new messages for SS/USSD payloadsVadim Yanitskiy2018-05-311-0/+15
| | | | | | | | | | | | | | | | | In order to be able to transfer SS/USSD messages via GSUP, this change introduces the following new message types: - OSMO_GSUP_MSGT_PROC_SS_*, and the following new IE: - OSMO_GSUP_SS_INFO_IE which represents an ASN.1 encoded MAP payload coming to/from the mobile station 'as is', without any transcoding. Change-Id: Ie17a78043a35fffbdd59e80fd2b2da39cce5e532 Related: OS#1597
* GSUP: implement TCAP-like session managementVadim Yanitskiy2018-05-311-0/+16
| | | | | | | | | | | | | | | | | | | | Unlike TCAP/MAP, GSUP is just a transport layer without the dialogue/context. This prevents us from having session based communication, required e.g. for USSD. But we can emulate TCAP dialogue by adding additional IEs, which would allow to relate each message to a particular session. This change introduces the following IEs: - OSMO_GSUP_SESSION_ID_IE, - OSMO_GSUP_SESSION_STATE_IE, which optionally can be used to indicate that the message is related to a session with given ID, and to manage session state, i.e. initiate, continue, and finish. Change-Id: I1cee271fed0284a134ffed103c0d4bebbcfde2a8 Related: OS#1597
* GSUP: change osmo_gsup_encode() return typeMax2018-02-051-4/+9
| | | | | | | | | | * match return type of osmo_gsup_encode() with osmo_gsup_decode() to allow propagating error to caller * check return value of osmo_gsup_encode() in GSUP test * return errors instead of braking app with aseert Change-Id: Idaa1deecb6d9e15329bd51867b4f6a03357461f0 Related: OS#2864
* Fix/Update copyright notices; Add SPDX annotationHarald Welte2017-11-131-2/+3
| | | | | | | | Let's fix some erroneous/accidential references to wrong license, update copyright information where applicable and introduce a SPDX-License-Identifier to all files. Change-Id: I39af26c6aaaf5c926966391f6565fc5936be21af
* [doc] Define 'gsup' group with proper name, add intro textHarald Welte2017-10-171-2/+1
| | | | Change-Id: Ieee6213dc5aad082a2d439c7418b51f281b80b1a
* gsup: Add encoding/decoding for the pdp charging characteristicsHolger Hans Peter Freyther2017-07-071-0/+20
| | | | | | | | These fields can be in the ISD and the PDP Context inofmration. Store pointers to this IE in both cases. It needs to be used by the SGSN when opening a PDP context. Change-Id: Iedc7c02adcf77ca5c9545119e19c968dfbbb3e6b
* doxygen: unify use of \file across the boardNeels Hofmeyr2017-06-231-2/+2
| | | | | | | | | | | | | | | | | Considering the various styles and implications found in the sources, edit scores of files to follow the same API doc guidelines around the doxygen grouping and the \file tag. Many files now show a short description in the generated API doc that was so far only available as C comment. The guidelines and reasoning behind it is documented at https://osmocom.org/projects/cellular-infrastructure/wiki/Guidelines_for_API_documentation In some instances, remove file comments and add to the corresponding group instead, to be shared among several files (e.g. bitvec). Change-Id: Ifa70e77e90462b5eb2b0457c70fd25275910c72b
* doxygen: enable AUTOBRIEF, drop \briefNeels Hofmeyr2017-06-231-1/+1
| | | | | | | | | | Especially for short descriptions, it is annoying to have to type \brief for every single API doc. Drop all \brief and enable the AUTOBRIEF feature of doxygen, which always takes the first sentence of an API doc as the brief description. Change-Id: I11a8a821b065a128108641a2a63fb5a2b1916e87
* update/extend doxygen documentationHarald Welte2017-06-121-0/+7
| | | | | | | | | It's a pity that even with this patch we still are fare away from having the whole API documented. However, at least we have a more solid foundation. Updates not only extend the documentation, but also make sure it is rendered properly in the doxygen HTML. Change-Id: I1344bd1a6869fb00de7c1899a8db93bba9bafce3
* gsup decode: fix expectation of AUTS length, should be 14Neels Hofmeyr2017-02-211-2/+2
| | | | | | The wrong expectation caused OsmoHLR to fail on Auth Sync. Change-Id: I277fb3d407396dffa5c07a9c5454d87a415d393f
* gsup: add osmo_gsup_message_type_name()Neels Hofmeyr2017-02-151-0/+29
| | | | Change-Id: Ic29b588b72893821d73fe90ecc16c6bf78d5a360
* GSUP, OAP, osmo-gen-vec: fix AUTS length to 14, not 16Neels Hofmeyr2017-02-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | GSUP transmits AUTS for UMTS authentication procedures, and OAP uses the same procedures to authenticate. osmo-gen-vec is a utility program that passes AUTS to our osmo_auth_gen_vec_auts() API. According to 3GPP 33.102 6.3.3, AUTS = SQN^AK || MAC-S, which are 6 || 8 == 14 bytes. This is confirmed by 24.008 9.2.3a where the TLV has 16 bytes, TL = 2 and AUTS being the V = 14. It is not harmful for milenage_gen_vec_auts() to pass two more AUTS bytes. But writing 16 bytes to a GSUP struct is a potential problem when passing in a 14 byte long AUTS buffer to the GSUP API, which then reads past the AUTS buffer. The API implies the length, so far to be 16, so passing in a 14 byte buffer to GSUP would require copying to a larger buffer first. Fix this by using a length of 14 for AUTS everywhere instead. This constitues an ABI breakage, we may handle it as a "fix before an official release", otherwise we need a version bump. The OAP protocol document has also been updated, needs an update in the osmo-gsm-manuals as well. Change-Id: If25b173d9ec57ea4c504d860954912b7d82af455
* cosmetic: gsup comments: write 'Generic' for the G in GSUPNeels Hofmeyr2016-12-091-1/+1
| | | | | | | | The G used to mean GPRS, but the scope is larger now. To satisfy the curious reader, give the G a name in gsup files' header comments. BTW, logging.h and gsup_test.c already mentioned "Generic" before this. Change-Id: I6ac5cf94c215e156ceff6a58da3d9e520ca942d9
* license: gsup: libosmogsm requires GPL, not AGPL; say 'sysmocom'Neels Hofmeyr2016-12-091-5/+5
| | | | | | | | | The copyright in gsup.h differed from the one in gsup.c: gsup.c names the GNU Affero GPL, gsup.h only the GNU GPL. Change both to GPL-v2-or-later. In gsup.c/h's copyright notice, 'sysmocom' should be spelled lower case. Change-Id: Ia5748c275501889b9086aef7d20ccb5c9edb8031
* osmo_gsup_encode(): Make coverity happy by invariant checkingHarald Welte2016-11-261-0/+1
| | | | | | | | | gsm48_encode_bcd_number() can theoretically return a length in excess of the size of the bcd_buf, but only in case an overly-long IMSI is passed into the function (which would be illegal in the first place). Change-Id: If3dc68ee13ff784b487bbc686b777cec9057d537 Fixes: Coverity CID 135216
* fix compiler warning: gsup.c: missing bracesNeels Hofmeyr2016-07-171-1/+1
| | | | | | | osmo_auth_vector's first member is an array, so for a zero initializer, we should add a second set of array braces. Change-Id: Iace448caca8152e46244f26c3af250f2035c99eb
* gsup.c: Fix encoding of UMTS auth vectorsHarald Welte2016-06-161-6/+22
| | | | | | | | | | Encoding auth vectors worked fine for GSM authentication, but didn't yet include the new IEs for UMTS authentication yet. Change-Id: I7fa5ba1c950292bd0a9874b3102a27f221ce390d Reviewed-on: https://gerrit.osmocom.org/302 Reviewed-by: Harald Welte <laforge@gnumonks.org> Tested-by: Jenkins Builder
* GSUP: Add support for RAND in SendAuthInfo.reqHarald Welte2016-05-061-1/+12
| | | | | | In the autentication re-sync case, we need not only the AUTS from the MS/UE, but also the RAND that we sent as part of the failed authentication challenge.
* GSUP: Add OSMO_GSUP_CN_DOMAIN_IE to differentiate CS and PS planeHarald Welte2016-05-061-0/+9
| | | | | We're starting to use GSUP for circuit-switched (CS) plane, so we need to differentiate the two planes somehow from each other.
* import gprs_gsup_message.[ch] from openbsc as gsup.[ch]Harald Welte2016-05-061-0/+472
Move those routines from OpenBSC to libosmogsm, so they can be re-used from other programs. I think it was a mistake to add them only inside the openbsc repository in the first place. We need to pay more attention to this in the future.