aboutsummaryrefslogtreecommitdiffstats
path: root/src/libmsc
AgeCommit message (Collapse)AuthorFilesLines
2018-11-30libmsc/gsm_04_11.c: fix: always use SAPI 3 for MT SMSVadim Yanitskiy1-2/+3
In I4a07ece80d8dd40b23da6bb1ffc9d3d745b54092 I've introduced a regression. According to GSM TS 04.11, section 2.3, SAPI 3 shall be used for both MO/MT SMS transmissions. Due to a mistake, caused by misunderstanding of the meaning of trans->dlci, SAPI 3 was not assigned to SM transactions if there is already an active RAN connection with subscriber. Let's fix this. Let's also drop this misleading comment: /* FIXME: specify SACCH in case we already have active TCH */ because it's a task of the BSC/BTS to decide which lchan to use. Change-Id: I08d0801a89d377441e95fb8e3dd27c8d587f89e9 Related: OS#3716
2018-11-30drop unused gsm_network->handover.activeNeels Hofmeyr1-17/+2
gsm_network contains an int handover.active which is always zero. Drop it. There is real handover code coming up soon, one part of this is to avoid confusion. The internal MNCC code queried it to decide whether to MNCC_BRIDGE or proxy RTP (MNCC_FRAME_RECV). Since RTP is being handled by osmo-mgw since forever, drop that entire condition from mncc_builtin. Change-Id: Ie16e718266882588b38297121364ca0b7fdfe948
2018-11-30drop unused gsm_subscr_conn->mncc_rtp_bridgeNeels Hofmeyr1-2/+0
Change-Id: I322dc18cfe2cc573744261df837e719b5cf224ba
2018-11-29libmsc/gsm_04_11.c: refactor MT SMS message handlingVadim Yanitskiy4-167/+204
According to GSM TS 04.11, the SMC (Short Message Control) state machine is a part of CM-sublayer of L3, that is responsible for connection management (establisment and releasing), and SM-RP (Relay Protocol) message delivery. For some reason, the connection establisment request from SMC (GSM411_MMSMS_EST_REQ) was not handled properly - it was always assumed that connection is already established. This is why the code initiating a MT (Mobile Terminated) SMS transfer had to establish a radio connection with subscriber manually. Let's benefit from having the SMC state machine, and offload connection establishment to it. This change makes the local implementation closer to GSM TS 04.11, and facilitates the further integration of GSUP transport. NOTE: the expected unit test output is changed, because now we always allocate a transaction first, and then establish a connection, not vice versa. Change-Id: I4a07ece80d8dd40b23da6bb1ffc9d3d745b54092
2018-11-29libmsc/transaction: introduce trans_find_by_sm_rp_mr()Ivan Kluchnikov1-0/+22
According to GSM TS 04.11, section 8.2.3, the RP Message Reference is a mandatory field for all messages on the SM-RL (SM Relay Layer), that is used to link an RP-ACK or RP-ERROR message to the associated (preceding) RP-DATA or RP-SMMA message transfer attempt. This change extends the transaction state structure with SM-RP-MR, and introduces a new function for matching transactions within a given connection by this reference. Change-Id: Ice47c37ecef4416e65ecee8931d946c915316791
2018-11-28libmsc/gsm_09_11.c: drop redundant assertion of stored msgbVadim Yanitskiy1-2/+0
It's already asserted at the beginning of handle_paging_event(). Change-Id: Ia558e11c6bde7bff130e4b76a4402ecc8068f1ed
2018-11-27libmsc/transaction.c: cosmetic: fix typoVadim Yanitskiy1-1/+1
Change-Id: I6d72b856e40ba81ee2f1e60693055705b5993b09
2018-11-25libmsc/gsm_04_11.c: refactor RP-DATA header validationVadim Yanitskiy1-20/+18
It's much better to have both RP-DATA header parsing and validation code in a single function. There is no need to pass all the header fields (DA, OA, UI) to gsm411_rx_rp_ud() because they are not used there. Change-Id: Iaf295949148e2a613c5403d1f7a926fcd6849c15
2018-11-25libmsc/gsm_04_11.c: don't pass msgb to gsm411_rx_rp_{ack|error}Vadim Yanitskiy1-4/+4
Passing a message buffer containing the whole encoded message, and a pointer to the RP header (struct gsm411_rp_hdr) is redundant. Change-Id: I0eb5c7c485ab7d109966431bd875fa74e00936d7
2018-11-23osmo_msc: remove unused parameter from msc_dtap()Philipp Maier3-3/+3
The parameter link_id in the function msc_dtap() is unused. Lets remove it. Change-Id: I7ba67b0cb514c91bc87a7b396ed3962b7a68e7da
2018-11-21msc/gsm_04_11.h: use forward-declaration for _gsm411_sms_trans_free()Vadim Yanitskiy1-0/+1
Change-Id: I87f96abd2b2d446751d8f95c9164c5eb6a58e66c
2018-11-21libmsc/db.c: cosmetic: mark missing breaks in switch as intendedVadim Yanitskiy1-0/+2
Change-Id: I3f4f34ecd0c5bb2d1a675ad5c4669fcffb87f292 Closes: Coverity CID#148209
2018-11-20Use libosmocore to function to parse cipher mode reject causeMax1-6/+7
This allow us to handle both regular and extended cause transparently. Change-Id: I7742ac41dd0642a5a40ce79d23250f8d9e6ae556 Related: OS#3187
2018-11-20Use BSSAP-specific TLV parser from libosmocoreMax1-1/+1
Change-Id: Iae1a3ffcebf1b0b95e61cd5dffe7ef734796fcfc
2018-11-19msc: vty: Fix integer printf formattingPau Espin Pedrol1-9/+9
| ../../../git/src/libmsc/msc_vty.c:1202:44: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'uint64_t {aka long long unsigned int}' [-Wformat=] | vty_out(vty, "Location Update : %lu attach, %lu normal, %lu periodic%s", | ^ Change-Id: Iae1c0b20a519ce71a21f72cea3c63694ef10adb4
2018-11-19Fix build with latest libosmocoreMax1-9/+0
Remove locally defined function which conflicts with the one in libosmocore. Change-Id: I464c16034b76e4599ac42857f60442c3fd000c75
2018-11-19libmsc: Don't send SMS STATUS REPORT locally if the ESME accepted it.Keith Whyte1-1/+1
When using smpp-first, after the ESME accepts our STATUS REPORT, we were sending it locally into gsm340_rx_sms_submit() anyway. In the case of the ESME mirroring the report back to us, this would result in two copies of the status report in the SMS database, which were also both then delivered to the MS. This causes no visible error to the user but is a waste of radio resources. With this patch, we check if it is the sms_report that has had receiver set in sms_route_mt_sms() and not the original SMS we are reporting on, which of course already has receiver set. Change-Id: I3529b89535800eaa1127721d613fa7bbcb8b23be
2018-11-13vty: add command to show all known BSCMax1-0/+17
Change-Id: I247fdce00f43072b0a2a0122b80bd40cdd9e0128
2018-11-08cosmetic: remove forgotten debug printfPhilipp Maier1-1/+0
the control interface command subscriber-list-active-v1 contains a stray debug printf, lets remove it. Change-Id: I085cf7b4a45708ccb883f70f71f4fbcfda58d332
2018-11-02Add counters for BSSMAP cipher mode messagesMax1-0/+6
Count COMPLETE and REJECT messages. Besides general troubleshooting that's also useful for TTCN-3 tests to check that OsmoMSC processed those messages as expected. Change-Id: I5822b2b38b64f1a691b26c926a8e2bece21dc624 Related: OS#3187
2018-11-02Properly parse cause in cipher mode rejectMax1-5/+6
Use appropriate TLV routines to get and log the value of rejection cause. Change-Id: I26b3eb0deff6dbd217b23d284bbc6e6a9eebc8e6 Fixes: OS#3187
2018-10-24gsm_04_08_cc: Add global guard timer for MNCCPhilipp Maier3-0/+62
The external MNCC handler may hang indefinitely in cases where the remote end of the MNCC ceases to work properly. Add a global guard timer to make sure the call reaches ACTIVE state. Change-Id: I7375d1e17cd746aac4eadfe1e587e82cf1630d3d Related: OS#3599
2018-10-21gsm0407_is_duplicate(): Handle error ret of gsm0407_pdisc_ctr_bin()Harald Welte1-1/+2
Change-Id: If9525694bcbc5c6c0e622e899dd634dc11ed61c4 Fixes: Coverity CID#182702
2018-10-08msc_mgcp: move mncc struct initalization to where its actually neededPhilipp Maier1-9/+11
The function _handle_error() initalizes a struct gsm_mncc variable on startup. The initalization accesses mgcp_ctx->trans->callref. All this is done before the assertion on mgcp_ctx. Later in the code one finds an if which tests on mgcp_ctx->free_ctx. This is the only part of the code that accesses the mncc struct variable. We should move the initalization there as well. - Move initalization of struct gsm_mncc mncc into the if body that uses it. Change-Id: I86983eabd999c4275dcc0e4a169ef2aa1e33c747 Related: OS#3635
2018-09-28fix a use-after-free in msc_mgcp.c:_handle_error()Stefan Sperling1-10/+10
Move code which needs to test the mgcp_ctx->free_ctx flag upwards such that it runs before we're calling functions which will potentially free mgcp_ctx. The code being moved up takes effect only in case mgcp_ctx won't be freed, so there should be no functional difference. Change-Id: I5df17c19e2a68c019f7eaf582b14585caa54b32a Related: OS#2885
2018-09-28mncc: fix byte ordering of IP-Address in mnccPhilipp Maier1-1/+1
At the moment osmo-msc populates the member ip in struct gsm_mncc_rtp with the wrong byte ordering. This causes LCR or osmo-sip-connector to receive the IP address in the wrong order, which eventually leads into a reversed IP address in the SDP part of the SIP messages. Change-Id: I86148179b549b511528e4c65213eb6c204cc609e Related: OS#3431
2018-09-18fix Classmark Update without VLR subscriberNeels Hofmeyr2-1/+27
This recent patch moves Classmark storage to the VLR subscriber, and introduced a segfault when a Classmark Update is received during IMSI detach: commit 986fe7ed18580775bed91399a1f02eae60bda251 change-id I27081bf6e9e017923b2d02607f7ea06beddad82a Mon Sep 17 01:12:13 2018 +0200 "store classmark in vlr_subscr, not conn" It assumed that we would never accept any Classmark Update messages unless we also have a valid subscriber for it. Well, that is proven wrong by the ttcn3-msc-test TC_imsi_detach_by_imsi(), which brings osmo-msc to its knees. Fix: in case of no valid vlr_subscr being present, store Classmark in the conn temporarily, and copy any received Classmark to VLR subscriber as soon as it gets associated with the conn (if at all). Change-Id: Ib2a2ae6bf86e8f29fc6751a8b5cdb7187cd70290
2018-09-17A5/n Ciph: request Classmark Update if missingNeels Hofmeyr4-47/+175
When the VLR requests a Ciphering Mode with vlr_ops.set_ciph_mode(), and if we need a ciph algo flag from a Classmark information that is not yet known (usually CM 2 during LU), send a BSSMAP Classmark Request to get it. To manage the intermission of the Classmark Request, add - msc_classmark_request_then_cipher_mode_cmd(), - state SUBSCR_CONN_S_WAIT_CLASSMARK_UPDATE, - event SUBSCR_CONN_E_CLASSMARK_UPDATE. From state AUTH_CIPH, switch to state WAIT_CLASSMARK_UPDATE. Once the BSSMAP Classmark Response, is received, switch back to SUBSCR_CONN_S_AUTH_CIPH and re-initiate Ciphering Mode. To be able to re-enter the Ciphering Mode algo decision, factor it out into msc_geran_set_cipher_mode(). Rationale: In the following commit, essentially we stopped supporting A5/3 ciphering: commit 71330720b6efdda2fcfd3e9c0cb45f89e32e5670 "MSC: Intersect configured A5 algorithms with MS-supported ones" Change-Id: Id124923ee52a357cb7d3e04d33f585214774f3a3 A5/3 was no longer supported because from that commit on, we strictly checked the MS-supported ciphers, but we did not have Classmark 2 available during Location Updating. This patch changes that: when Classmark 2 is missing, actively request it by a BSSMAP Classmark Request; continue Ciphering only after the Response. Always request missing Classmark, even if a lesser cipher were configured available. If the Classmark Update response fails to come in, cause an attach failure. Instead, we could attempt to use a lesser cipher that is also enabled. That is left as a future feature, should that become relevant. I think it's unlikely. Technically, we could now end up requesting a Classmark Updating both during LU (vlr_lu_fsm) and CM Service/Paging Response (proc_arq_fsm), but in practice the only time we lack a Classmark is: during Location Updating with A5/3 enabled. A5/1 support is indicated in CM1 which is always available, and A5/3 support is indicated in CM2, which is always available during CM Service Request as well as Paging Response. So this patch has practical relevance only for Location Updating. For networks that permit only A5/3, this patch fixes Location Updating. For networks that support A5/3 and A5/1, so far we always used A5/1 during LU, and after this patch we request CM2 and likely use A5/3 instead. In msc_vlr_test_gsm_ciph, verify that requesting Classmark 2 for A5/3 works during LU. Also verify that the lack of a Classmark Response results in attach failure. In msc_vlr_test_gsm_ciph, a hacky unit test fakes a situation where a CM2 is missing during proc_arq_fsm and proves that that code path works, even though the practical relevance is currently zero. It would only become interesting if ciphering algorithms A5/4 and higher became relevant, because support of those would be indicated in Classmark 3, which would always require a Classmark Request. Related: OS#3043 Depends: I4a2e1d3923e33912579c4180aa1ff8e8f5abb7e7 (libosmocore) Change-Id: I73c7cb6a86624695bd9c0f59abb72e2fdc655131
2018-09-17store classmark in vlr_subscr, not connNeels Hofmeyr2-59/+72
Store all Classmark information in the VLR. So, we now always know the Classmark 1 (mandatory IE for LU). This is visible in the msc_vlr_tests -- they no longer indicate "assuming A5/1 is supported" because classmark 1 is missing, because we now know the Classmark 1. Rationale: During Location Updating, we receive Classmark 1; during CM Service Request and Paging Response, we receive Classmark 2. So far we stored these only for the duration of the conn, so as soon as a LU is complete, we would forget CM1. In other words, for anything else than a LU Request, we had no Classmark 1 available at all. During Ciphering Mode Command, we rely on Classmark 1 to determine whether A5/1 is supported. That is moot if we don't even have a Classmark 1 for any CM Service Request or Paging Response initiated connections. The only reason that A5/1 worked is that we assume A5/1 to work if Classmark 1 is missing. To add to the confusion, if a phone indicated that it did *not* support A5/1 in the Classmark 1, according to spec we're supposed to not service it at all. A code comment however says that we instead want to heed the flag -- which so far was only present in a Location Updating initiated connection. Now we can make this decision without assuming things. This got my attention while hacking on sending a BSSMAP Classmark Request from the MSC if it finds missing Classmark information, and was surprised to see it it lacking CM1 to decide about A5/1. Change-Id: I27081bf6e9e017923b2d02607f7ea06beddad82a
2018-08-23cosmetic: mute "COMPLETE_LAYER_3 not permitted"Neels Hofmeyr1-1/+8
For networks without Authentication, the conn is already accepted when SUBSCR_CONN_E_COMPLETE_LAYER_3 is emitted. Mute that misleading error message. All is actually fine. Adjust expected test logs. Change-Id: I2d19d0a7cf3226ee1456f75a68e007ba98232402
2018-08-10libmsc/mncc_sock.c: Add lchan_type_offset in queue_hello()Keith1-0/+1
lchan_type was removed from gsm_mncc and the hello message on initial import from legacy OpenBSC in Change-Id: Id3705236350d5f69e447046b0a764bbabc3d493c This patch follows on from Change-Id: Ia02373a36df7605507ee3de49173a9fd6547b726 which reintroduced lchan_type to the gsm_mncc struct. This patch restores the lchan_type_offset to the hello protocol message Without this patch, LCR will issue an error and disconnect from the MNCC socket. Change-Id: I65312082fa5dc0721170f923840e992ef9481a63 Closes: OS#3461
2018-08-07mgcp: use codec information returned with ASSIGNMENT COMPL.Philipp Maier3-14/+73
When the assignment completes a choosen codec is returned. At the moment we do not use this information. - add struct members for codec info (both, RAN and CN) - parse codec info in BSSMAP ASSIGNMENT COMPLETE - use codec info on mgcp Since the MNCC API is not complete yet, we currently only use the codec info only on the internal MNCC yet. Change-Id: I9d5b1cd016d9a058b22a367d0e5e9f2ef447931a Related: OS#2728
2018-08-05RRLP: print log when sending a position requestVadim Yanitskiy1-0/+4
Change-Id: Ia2446e05f63ac219f630ab9db1ea9bf305f0a4b9
2018-08-05RRLP: migrate and share mode definitions from msc_vty.cVadim Yanitskiy2-20/+23
Change-Id: I9560e6eab0ad1b5d57ca732741fc0b6f61f1a4a2
2018-08-05RRLP: properly name the init functionVadim Yanitskiy1-1/+1
We don't actually deal with DSO loading here... Change-Id: I24d0c9ad52f07f08176ad129878b48a591a3af6c
2018-08-05Remove local libgsupclient; Use libosmo-gsup-client from osmo-hlrHarald Welte2-3/+4
osmo-hlr has recently (as of Change-Id Iad227bb477d64da30dd6bfbbe1bd0c0a55be9474) a working shared library implementation of libosmo-gsup-client. We can remove the local implementation in osmo-msc and use the system-installed shared library instead. Change-Id: I6f542945403cf2e3ddac419186b09ec0e2d43b69
2018-08-05libmsc/gsm_09_11.c: clean up the local GSM 04.80 APIVadim Yanitskiy2-139/+11
Since we don't process SS/USSD requests in OsmoMSC anymore, there are some useless GSM 04.80 functions remained from the past. In particular, this change does the following: - removes both gsm0480_send_{ussd_response|return_error} functions because they are not used anymore; - changes symbol prefix from 'gsm0480_' to 'msc_', in order to avoid possible conflicts with the libosmogsm's GSM 04.80 API; - cleans up useless includes; Change-Id: I2990d8627bce0ce6afb1dcf6b11bb194292380d3
2018-08-04libmsc/rrlp.c: add missing includeVadim Yanitskiy1-1/+1
Change-Id: Id33c9e5c04d61d08110ae80209f73ed14a5ef59c
2018-07-30libmsc/gsm_09_11.c: introduce counter for active sessionsVadim Yanitskiy2-0/+10
Change-Id: Ia17e7c747fffb5267d3ca5bc4193c1be4a57ef3a
2018-07-30libmsc/gsm_09_11.c: introduce rate counters for NC_SS sessionsVadim Yanitskiy2-0/+30
This change introduces some new rate counters for call-independent SS/USSD connections. As OsmoMSC doesn't handle the messages itself, and only responsible for dispatching messages between both A and GSUP interfaces, the following is taken into account: - MS-initiated and network-initiated requests to establish a NC SS/USSD session (transaction) - "nc_ss:m{o|t}_requests"; - successfully established MS-initiated and network-initiated SS/USSD sessions (transactions) - "nc_ss:m{o|t}_established". Change-Id: I23c9475abc9951d82f3342fdc5aaa367836f7741
2018-07-30libmsc/gsm_09_11.c: properly handle MS-initiated releaseVadim Yanitskiy1-2/+5
According to GSM TS 02.90, section 4.3, release of the connection used for SS/USSD is normally the responsibility of the network. But the user may also initiate connection release, e.g. by pressing the 'red button'. TTCN-3 test case: I7936ed5072ed2ae02f039dc90a1fece1e7f70a70 Change-Id: I76fc277bf9db614a97824b1541cd5bb75aa3e29d
2018-07-30libmsc/gsm_09_11.c: implement network-initiated sessionsVadim Yanitskiy2-4/+170
This change introduces a possibility to establish network-initiated SS/USSD transactions with a subscriber in either IDLE, or DEDICATED state. In the first case, a new transaction is established using Paging procedure. If a subscriber already has an active connection, a separate new transaction is established. TTCN-3 test case: I073893c6e11be27e9e36f98f11c1491d0c173985 Change-Id: Ief14f8914ef013bd6efd7be842f81fbf053f02e2
2018-07-30libmsc/gsm_09_11.c: forward SS/USSD messages to HLR over GSUPVadim Yanitskiy2-54/+199
In order to be able to support external SS/USSD gateway, we should not terminate the GSM 04.80 messages at OsmoMSC. Instead, we need to follow the GSM TS 09.11 specification, and forward all messages unhandled by OsmoMSC to OsmoHLR over GSUP protocol. This change implements forwarding of MO SS/USSD messages. The forwarding assumes transcoding between GSM 04.80 messages and GSUP messages. The payload of Facility IE is carried 'as is'. As a side-effect, this will disable the osmo-msc internal handler implementing the "*#100#" for obtaining the subscribers own phone number. In order to re-gain this functionality, you will need a modern osmo-hlr (Change-Id I1d09fab810a6bb9ab02904de72dbc9e8a414f9f9) and the following line in your osmo-hlr.cfg: hlr ussd route prefix *#100# internal own-msisdn TTCN-3 test case: I01de73aced6057328a121577a5a83bc2615fb2d4 Change-Id: Ide5f7e350b537db80cd8326fc59c8bf2e01cb68c
2018-07-29libvlr/vlr.c: forward unhandled GSUP messages towards MSCVadim Yanitskiy1-0/+13
Some internal sub-systems, such as SS/USSD or SMS implementation, may also need to use GSUP connection with HLR. Previously, it was only available within the libvlr code, and nowhere else. Let's introduce the generic GSUP message router, which will receive messages unhandled by VLR itself, and route them to a handler depending on the message type. Change-Id: Ib8146ce5788c8f249dcaa39d61bd0388574bf892
2018-07-26cosmetic: typos in log and commentNeels Hofmeyr1-6/+6
Change-Id: I2416d9a45e88f4317aa8e6644f5581a6f4f119c8
2018-07-26Iu MGCP: no need to loopback on the cn sideNeels Hofmeyr1-8/+0
Change-Id: I501a7846c76dd703beb3991362b1ccbd62dfd155
2018-07-25libmsc: move L3 call-control to separate C file (gsm_04_08_cc.c)Harald Welte3-2066/+2141
The CC sub-layer is fairly self-contained, so let's move it to a separate C source file. The old gsm_04_08.c file now only contains the 04.07 / DTAP core and MM sub-layer handling. I did this initially as an experiment to see how self-contained our CC implementation really is. Given this rather straight-forward patch builds fine, CC really is self-contained (yay!). Change-Id: Idb8dd7a8d9d8b4a28c492f12da3cc3305b695cca
2018-06-12libmsc/gsm_04_80.c: make the API abstract from ss_request structVadim Yanitskiy2-23/+72
There is no need to pass a pointer to a ss_request struct when calling the gsm0480_send_ussd_* functions, because they only use both transaction ID and InvokeID from there, which may be passed directly. This change allows one to use this API without parsing the whole GSM 04.80 message, or when parsing is failed. Moreover, if InvokeID is not available, one can pass any incorrect, (e.g. negative) value, so the universal NULL tag will be used. Finally, setting a TI flag is also up to the caller. Change-Id: I13d5abbfdcf8238ebaf0566c420f09cd9255b648
2018-06-12libmsc/gsm_09_11.c: properly indicate transaction errorsVadim Yanitskiy1-5/+6
Previously it was intended that we are always parsing the whole GSM 04.80 message, including the Invoke ID. But there is no need to do that, since we are going to forward the Facility IE payload to HLR in near future. Moreover, there was a mistake (my bad) - transaction is being established before parsing of the message, so the req structure remains uninitialized until that. Let's just send RELEASE COMPLETE message without any Cause or Facility IEs. We could indicate a problem using the first one, but according to GSM TS 04.80, the Cause IE only makes sense when "its functional handling is specified in the service description or GSM TS 09.11". Change-Id: Iecba2dccada9bbcdeb3a9dfd868719aeedc07022
2018-06-12libmsc/gsm_04_08.c: expose gsm48_tx_simple()Vadim Yanitskiy1-4/+8
This function could be also used by other parts of code, e.g. by gsm_04_11.c or by gsm_09_11.c, during initialization of a new transaction. No need to hide it. Change-Id: I9a9d17fca4901163dae10d76455aa4cf54497156
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-28 08:01:21 +0000