| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Missing (unset) type of to be encoded message is not a memory
allocation failure (-ENOMEM), this is definitely a mistake.
Change-Id: Ibbac18e2b68b765c17c2bc959c4c085037953a7f
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
* 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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Change-Id: Ieee6213dc5aad082a2d439c7418b51f281b80b1a
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
The wrong expectation caused OsmoHLR to fail on Auth Sync.
Change-Id: I277fb3d407396dffa5c07a9c5454d87a415d393f
|
|
|
|
| |
Change-Id: Ic29b588b72893821d73fe90ecc16c6bf78d5a360
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
We're starting to use GSUP for circuit-switched (CS) plane, so we need
to differentiate the two planes somehow from each other.
|
|
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.
|