summaryrefslogtreecommitdiffstats
path: root/tests/gsup
Commit message (Collapse)AuthorAgeFilesLines
* GSUP: add inter-MSC handover related msgs and IEsOliver Smith2019-04-263-4/+347
| | | | | | | | | | | | | | | | | | | | 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-5/+7
| | | | | | | | | | | | | | | | | | 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
* tests/gsup_test.c: drop session IEs from MO-ForwardSM ErrorVadim Yanitskiy2019-01-052-10/+4
| | | | | | | | Both session state and session ID IEs were left from the initial version of Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71. There is no need to use them (as we use SM-RP-MR), so let's clean up. Change-Id: I0d910b87f15ffbc0aeeca9cb4fcbef32bdf3ef88
* GSUP: add CHECK-IMEI messageOliver Smith2018-12-213-0/+54
| | | | | | | | | | | | | | 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: add end marker to enum osmo_gsup_ieiOliver Smith2018-12-211-5/+1
| | | | | | | | | | | | | Simplify gsup_test.c by defining an end marker in gsup.h. No need to manually update the last element every time anymore. The C standard guarantees, that the end marker will have the last value plus one: "Each subsequent enumerator with no = defines its enumeration constant as the value of the constant expression obtained by adding 1 to the value of the previous enumeration constant." (From C99: 6.7.2.2 Enumeration specifiers) Change-Id: I2aab7245e209f0ebd2f33a83d4d181dd3339cb17
* GSUP/SMS: introduce READY-FOR-SM messageVadim Yanitskiy2018-12-183-1/+19
| | | | | | | | | | | | | | | 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-183-13/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* GSUP: introduce new messages for SS/USSD payloadsVadim Yanitskiy2018-05-313-1/+60
| | | | | | | | | | | | | | | | | 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-313-1/+19
| | | | | | | | | | | | | | | | | | | | 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
* use osmo_init_logging2() with proper talloc ctxNeels Hofmeyr2018-04-061-1/+2
| | | | | | | | Ironically, when deprecating osmo_init_logging() in I216837780e9405fdaec8059c63d10699c695b360, I forgot to change the callers within libosmocore itself, i.e. in the various regression tests. Change-Id: Ia36c248f99353d5baaa2533f46a2f60a8579bdf8
* GSUP: change osmo_gsup_encode() return typeMax2018-02-051-1/+3
| | | | | | | | | | * 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
* GSUP: don't fail test on first errorMax2018-01-222-4/+30
| | | | | | | | | | Instead of forcing test failure via assert on first error encountered, let it run until completion and print detailed error log. This simplifies troubleshooting by letting user to see more errors from single run and more details on each of the errors. Update test output with explicit test results. Change-Id: I016a28fe04f7b194e22c15e936095004c5f079d1
* gsup: Add encoding/decoding for the pdp charging characteristicsHolger Hans Peter Freyther2017-07-072-5/+8
| | | | | | | | 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
* gsup_test: also check stderrNeels Hofmeyr2017-02-222-6/+85
| | | | | | | | | Configure logging to be deterministic and add stderr checking to testuite.at. However, exclude the thousands of message modification log lines from the log to not have a huge test expectation file. Change-Id: I0dd7112967a64a168556b62e5ec15107b7608ffb
* gsup test: add decoding test for UMTS IEsNeels Hofmeyr2017-02-222-1/+61
| | | | | | | | | | This would have caught the wrong expectation of AUTS' length fixed recently (3a5ca647c531b7761dc6c555e5e0cabc972bd3ac). Besides AUTS, add AUTN, RES, CK, IK which were also not tested yet. Change-Id: I6fddf8d7ce97137b0a585d365807bcaf90a319d0 Related: OS#1593
* fix: DLGSUP logging category "unusable"Neels Hofmeyr2016-12-111-5/+0
| | | | | | | | | | | | | | | | | | | All DL* categories are typically negative, but DLGSUP isn't, and it's also not in libosmocore's internal_cat array. See: 3b6fb0880c3ab1e23a3d7d738d073b00c2a794c2 This means that a program using DLGSUP has to include DLGSUP in its own logging cat array (typically not needed for DL* categories), which means for osmo-nitb that DLGSUP (11) replaces DMGCP (also 11), and DMGCP becomes unusable. Fix this: make DLGSUP -11 and include in internal_cat. In gsup_test.c, no longer add DLGSUP to the logging categories array. External follow-ups are otherwise needed only in osmo-hlr.git and some pending patches for openbsc (Id3938267fa062e1a997d3704cd678874306f86ee). Change-Id: Id974c7be158e4d60421a98110f5c807aefd31119
* import gprs_gsup_message.[ch] from openbsc as gsup.[ch]Harald Welte2016-05-062-0/+278
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.
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-17 21:15:09 +0000