summaryrefslogtreecommitdiffstats
path: root/src/gsm/gsm0480.c
Commit message (Collapse)AuthorAgeFilesLines
* gsm0480: drop messages with incorrect data lengthVadim Yanitskiy2018-04-041-9/+12
| | | | | | | | | | If either an INVOKE, either a RETURN_RESULT component has the data with incorrect length (see Annex A, 3GPP TS 04.80), the whole message is probably incorrect. Let's drop such messages instead of silent truncation. Change-Id: I2a169b0b84aa26ea2521edd55ff005c27ae6d808
* gsm0480: copy the raw USSD data, its DCS and lengthVadim Yanitskiy2018-04-041-9/+17
| | | | | | | | | | | | | | | | | | As it was already documented before, the 'ss_request' struct has a rudiment of deprecated 'ussd_request' struct - the 'ussd_text' field. It represents the data either of an INVOKE component, either of a RETURN_RESULT component, encoded as ASCII in case if DCS is 0x0f (i.e. decoded by the code itself), otherwise raw bytes 'as is'. Previously, there was no possibility to distinguish between ASCII and raw bytes with different DCS. Moreover, the payload decoding is not desired in some cases. Let's introduce the new fields, which will carry the raw unmodified payload, its length and DCS (Data Coding Scheme). Change-Id: Ia193d175021e145bb3b131290231f307dbefc64a
* gsm0480: parse optional IEs for RELEASE COMPLETE messageVadim Yanitskiy2018-01-171-1/+5
| | | | | | | | According to GSM 04.80 section 2.5 "Release complete", a message of the mentioned type may contain optional IEs, such as Cause and Facility. Let's parse them. Change-Id: Ib8fc1f6bae472b0b264b6158f372b6cce255b222
* gsm0480: parse all SS info elements in a messageVadim Yanitskiy2018-01-171-1/+10
| | | | | | | Some SS messages (e.g. RELEASE COMPLETE) may contai multiple IEs (Information Elements). Let's parse them all. Change-Id: I20cc59c25fdbda176bcf76437174cda829518d60
* gsm0480: correct parse_ss_info_elements() declarationVadim Yanitskiy2018-01-171-1/+1
| | | | Change-Id: I64df293188908c7eb10a61941db76656340d3a8e
* gsm0480: refactor gsm0480_decode_ss_requestVadim Yanitskiy2018-01-171-7/+14
| | | | Change-Id: Iba734db97ab516f8fce816c4e4225b97b93619f1
* gsm0480: move SS request length check to parse_ss()Vadim Yanitskiy2018-01-171-12/+11
| | | | Change-Id: I8e7ce5bd97f3a8731924264c92afb9a7183937dc
* gsm0480: pass exact GSM 04.80 payload length to parse_ss()Vadim Yanitskiy2018-01-171-4/+4
| | | | Change-Id: I9608d4ad16d7581320615c140beaac36628c31a4
* gsm0480: add specification reference to SS message typeVadim Yanitskiy2018-01-171-0/+1
| | | | Change-Id: Iff0210e995053e270939a774db33f55b22545204
* gsm0480: handle GSM0480_OP_CODE_PROCESS_USS_DATAVadim Yanitskiy2018-01-171-0/+5
| | | | Change-Id: I470290c2b544555e53cedd849b1d6a961db7b5a4
* gsm0480: handle USS_NOTIFY and USS_REQUEST with PROCESS_USS_REQVadim Yanitskiy2018-01-171-0/+2
| | | | Change-Id: If7cc6a966dfc17d37e22338ecc1f239f908a9f2e
* gsm0480: handle GSM0480_CTYPE_RETURN_RESULTVadim Yanitskiy2018-01-171-0/+82
| | | | Change-Id: I8fb2856acbbf4c53e7d53200a37bc8f79e763bcf
* gsm0480: parse GSM0480_MTYPE_FACILITY separatelyVadim Yanitskiy2018-01-171-1/+17
| | | | Change-Id: I6e029c436a50fa8c2823ea39c5d123ee701becfa
* gsm0480: handle UnstructuredSS Request with DSC != 0x0FVadim Yanitskiy2018-01-171-0/+20
| | | | | | | | | | | According to GSM 04.08, 4.4.2 "ASN.1 data types": the USSD-DataCodingScheme shall indicate use of the default alphabet using the 0x0F value. Previously, the UnstructuredSS Request messages with not default alphabet were not being handled. Let's fix this. Change-Id: I73d602f6f20b0afe7600d16bbd432069ae7be788
* gsm0480: clean up the parse_process_uss_req() codeVadim Yanitskiy2018-01-171-19/+20
| | | | | | This change reduces the degree of code nesting... Change-Id: I467f75794c5ac9df75c001245b18bbdfcfaadd88
* gsm0480: fix USSD OCTET STRING length confusionVadim Yanitskiy2018-01-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | According to the GSM 04.80 (version 5.0.0) specification Annex A "Expanded ASN.1 Module "SS-Protocol", the maximum size of a USSD OCTET STRING is 160 bytes. Thus according to ETSI TS 123 038 (version 10.0.0) specification 6.1.2.3 "USSD packing of 7 bit characters", in 160 octets, it's possible to pack (160 * 8) / 7 = 182.8, that is 182 characters. The remaining 6 bits are set to zero. This change defines both mentioned values: - GSM0480_USSD_OCTET_STRING_LEN 160 - GSM0480_USSD_7BIT_STRING_LEN 182 keeping the old MAX_LEN_USSD_STRING 'as is' due to compatibility reasons. Now the new value is used for ss_request structure, while old one is still used for deprecated ussd_request structure. Change-Id: I6dead74f9ecea079752ff2400cdaf7c30187784e
* gsm0480: skip length check for 'RELEASE COMPLETE' messageSergey Kostanbaev2018-01-171-3/+10
| | | | | | | | According to GSM 04.80 Section 2.5 'Release complete' Table 2.5, the 'RELEASE COMPLETE' message payload is optional, so let's drop the length check in gsm0480_decode_ss_request() for this type. Change-Id: I63b7f8ce403169a9dbdbdb031db16693de2196d6
* Fix/Update copyright notices; Add SPDX annotationHarald Welte2017-11-131-0/+2
| | | | | | | | 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
* 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
* gsm0480: add gsm0480_create_ussd_notify() and *_release_complete()Neels Hofmeyr2016-12-011-0/+29
| | | | | | | | | | | Add two functions to create USSD messages. Moves and generalizes code from openbsc. Pending: use the new functions in openbsc. It looks like _release_complete() should also set trans_id and direction flag; but since this is moving code from openbsc that is apparently working, just place a fixme comment and don't change the functionality. Change-Id: Ia80e32c7105359915bfad3cc5621a1c09caf20f0
* gsm0480: code dup: introduce and use gsm0480_l3hdr_push()Neels Hofmeyr2016-12-011-6/+14
| | | | | | | | Add function gsm0480_l3hdr_push() to push a struct gsm48_hdr to the start of a msgb. Use in gsm0480.c and gsm0411_utils.c. Further callers of the new function will follow in openbsc as well as another libosmocore patch for ussd. Change-Id: I54fce6053ab8362015686fe22dbcd38bf1366700
* fix USSD: SS message type mask should be 0x3f, not 0xbfNeels Hofmeyr2016-10-121-1/+1
| | | | | | | | | | | | | | See 04.80[1], section 3.4: the highest two bits are used as counter or ignored and do not contribute to the SS "Miscellaneous message group". Previous mask of 0xbf included the highest bit, fix to 0x3f. Observed a value of 0xbb that should mean 0x3b="Register" during testing of 3G USSD requests, which seem to be the first to send a nonzero highest bit to our code. The erratic mask of 0xbf lead to an unhandled message type of 0xbb. [1] 3GPP TS 24.080 version 7.2.0 Release 7 / ETSI TS 124 080 V7.2.0 (2006-09) Change-Id: I299001a9e36c16f55622a0acd5d4a55ca49d0055
* 04.08: add inline funcs for pdisc + msg type bitmasksNeels Hofmeyr2016-03-151-2/+2
| | | | | | | | | | | | | | | | Add inline functions for both release <= 98 and release >= 99 as well as a default define. Use the release 98 by default since the current code base uses the r98 bitmasks. These inline functions relieve callers of the decision on masking bits of the protocol discriminator and message type octets. Also add a define for the protocol discriminator extension to one octet length (GSM48_PDISC_EXTEND). Apply new pdisc function in gsm0480.c. [hfreyther: Make the hdr param const]
* Supplementary Services (de)activation, interrogation addedTobias Engel2015-01-011-25/+101
| | | | | | | | | | | | | These patches enhance the Supplementary Service (SS) processing from only being able to handle USSD to other SS, specifically activation, deactivation and interrogation of those SS. Registration is not yet implemented. include/osmocom/gsm/protocol/gsm_09_02.h has been added with needed values for SS. Modified by Harald Welte to keep the old ussd-only functiosn for API/ABI stability.
* ussd: Fix text of RELEASE COMPLETEAlexander Huemer2013-10-151-1/+1
| | | | | | Before the assigned value (0xFF) was truncated, reg->text[0] is of type char. A corresponding test for the same value in openbsc could only fail.
* sms: Added result buffer size parameter to 7bit conv funsJacob Erlbeck2013-08-121-7/+4
| | | | | | | | | | | | | The 7bit<->8bit encoding/decoding functions didn't check whether there is still enough space in the destination buffer. Therefore a buffer size parameter has been added to each of the functions which is used to truncate the output if the buffer is too small. In addition, the return value of the decoding functions has been changed to number of characters written (excluding \0), so this value is always equal to strlen(decoded). The old functions are still available as wrapper functions.
* Add special 7-bit encoding and decoding functions for USSD codingAndreas Eversberg2013-08-081-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | Handling 7-bit coding is a little different for USSD, as TS 03.38 states: To avoid the situation where the receiving entity confuses 7 binary zero pad bits as the @ character, the carriage return or <CR> character shall be used for padding in this situation [...]. If <CR> is intended to be the last character and the message (including the wanted <CR>) ends on an octet boundary, then another <CR> must be added together with a padding bit 0. The receiving entity will perform the carriage return function twice, but this will not result in misoperation as the definition of <CR> [...] is identical to the definition of <CR><CR>. The receiving entity shall remove the final <CR> character where the message ends on an octet boundary with <CR> as the last character. Jacob has verified the fix with fakeBTS and the wireshark dissector. Fixes: OW#947 Reviewed-by: Jacob Erlbeck <jerlbeck@sysmocom.de>
* gsm: Revert the gsm_7bit_encode changes as they are wrongHolger Hans Peter Freyther2013-07-071-24/+9
| | | | | | | | | | | | | | | This reverts commit f996b05dbddccb8e8788dd69777a4fedfa2373eb and 2b0cac4ef83137ee0bdd583aee877eac467abeab. A detailed explanation can be found here: http://lists.osmocom.org/pipermail/openbsc/2013-July/004737.html The short description is that: 1.) The API should return (as out parameter) the number of octets used. 2.) The handling for the <CR> encoding only applies to USSD and it is incomplete. On top of that it broke the SMS test.
* Fix: Handle returned length by gsm_7bit_encode correctlyAndreas Eversberg2013-07-061-9/+24
|
* include: reorganize headers file to include/osmocom/[gsm|core]Pablo Neira Ayuso2011-03-231-5/+5
| | | | | | | | | | | | This patch moves all GSM-specific definitions to include/osmocom/gsm. Moreover, the headers in include/osmocore/ have been moved to include/osmocom/core. This has been proposed by Harald Welte and Sylvain Munaunt. Tested with `make distcheck'. Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
* This patch moves the GSM-specific functions to the new libraryPablo Neira Ayuso2011-03-231-0/+461
libosmogsm which is provided by libosmocore. I have also moved generate_backtrace() to backtrace.c instead of gsm_utils.c, otherwise the timer and msgfile tests depend on libosmogsm. Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-19 13:16:07 +0000