AgeCommit message (Collapse)AuthorFilesLines
2019-01-22Bump version: 1.3.0 → Welte1-0/+7
Change-Id: I624144d6f8919d1dd237cdffc9122f685a8e4d6b
2019-01-22fix build: apply msgb_wrap_with_TL() renameNeels Hofmeyr1-1/+1
After libosmocore commit If1e851ac605c8d2fde3da565b0bd674ea6350c2e b27e6feb699712345373e87a48187dc622e4fa92 the osmo-msc master build is broken. Apply the msgb_wrap_with_TL() rename to msgb_push_tl() to unbreak the build. Change-Id: I1d4675e0c907b2f92f2ec79b02356391a6d72aa8
2019-01-21Bump version: → Welte2-10/+240
Change-Id: I59d032ad953438f12439ac3d6275ee78d0ebbb40
2019-01-17vty: make 'sh connect/transact' readable againMax1-9/+24
After recent changes to vlr_subscr_name() result became variable-length which messes up old vty code. Fix this by moving it to the very end and adjusting headers as necessary. While at it, make sure we don't print headers if we have nothing else to show. Change-Id: Id06b4277ff790d95457d0cc2f94ef6bf5366bb21
2019-01-17Cosmetic: Fix spelling in smpp vtyKeith1-2/+2
Change-Id: Id3fa3f26c333bf445590fd75ad7a08be68fed3e2
2019-01-17Make alert notifications vty configurable per ESMEKeith4-2/+35
Adds (no) alert-notifications as a per-esme vty command, in order to allow some ESMEs to be excluded from alerts. The default is still to send alert notifications to all esme, so no changes are required to the config file to maintain identical operation after this patch. Change-Id: I57f4d268ca6fe6a233f2caaffce62e4aade01274
2019-01-17SMS: remove code duplication in transaction initMax1-24/+27
Move code which allocates transaction for SMS and initializes corresponding FSM into separate function (shared by MT and MO code paths) to avoid code duplication and simplify further modifications. Change-Id: I3563e11bebb58e656592df2ff7db96f41deaf735
2019-01-16MNCC: use explicit struct type in gsm_callMax1-1/+1
There's no need to use 'void *' because we have forward declaration for 'struct gsm_network' in the very same header. Change-Id: I5078ffcf2706adaca1b5df107f8b6a44062ca28c
2019-01-16Enable SMS-related log in VLR testsMax8-3/+590
The likely reason why it was disabled is due to paging_cb_mmsms_est_req() logging pointers which results in unstable log output. Fixing this allows us to track SMS-related regressions properly. Change-Id: I44ae817d9edb73d182ff33ff5a2fd942e224e344
2019-01-16VLR: send CHECK-IMEI to EIR/HLROliver Smith10-57/+918
When check-imei-req is enabled in the VTY config, do not accept IMEIs sent by the ME directly anymore. Send the IMEI to the EIR/HLR and wait for its ACK or NACK. OsmoHLR also accepts all IMEIs at this point, but this allows to optionally store the IMEI in the HLR DB. Depends: Ib240474b0c3c603ba840cf26babb38a44dfc9364 (osmo-hlr) Related: OS#3733 Change-Id: Ife868ed71c36cdd02638072abebf61fc949080a7
2019-01-14Fix trans_has_conn() doxygen descriptionMax1-1/+1
Change-Id: Ica5e498e03d0a157a661e428dfd68739f572d073
2019-01-12gsm_04_08: Fix nullpointer derefPhilipp Maier1-2/+5
The pointers conn, conn->vsub and conn->vsub->last_tuple are checked, but before the check those pointers are already dereferenced during assignment. This defeats the purpose of the check. Lets dereference those pointers after the check. Fixes: CID#190404 Change-Id: Ice4992606f3799eac13154ec0b9f53e46d2e178e
2019-01-12gsm_04_08_cc.c: drop non-sensible error messagegsmevent admin1-2/+0
Change-Id: Icbf099e418281eb908e7916503f178ab7ea26ffe
2019-01-12msc_vlr_tests: tweak logging in verbose modeNeels Hofmeyr1-2/+7
Change-Id: Ia06245f3adc6cf4c483d9c12c387cd5169582353
2019-01-12err log: fully log MS supported A5 algos on mismatchNeels Hofmeyr1-2/+38
Change-Id: Icb18e0f0bb420de066e7eb8fc683f192ba2a7368
2019-01-12tweak fsm_msc_mgcp FSM and FI nameNeels Hofmeyr1-6/+4
Instead of MGW(MGW_99) use a name of msc-mgcp(MSISDN:2331_GERAN_A:00000017_trans99) 1. The FSM is communication towards an MGW, not the MGW itself. When reading combined logging (gsmtap_log), it is confusing to read 'MGW' in a log coming from the MSC. The API is also called msc_mgcp_*. 2. Calling the FSM instance 'MGW_' again doesn't make sense. 3. Indicate 'trans' before the trans_id (trans_id was already shown, but not indicated what it was). 4. Also indicate the actual subscriber's identification. 5. Also indicate the RAN connection and conn_id. This comes up while trying to understand a call coming in on an already established call: parsing the log with a human brain is near torture without this info, taking extremely long to get grips on. Change-Id: Ie5fc1ffb7eba0209fee4666a075655cd24d27473
2019-01-12mm_rx_id_resp(): use osmo_mi_name()Neels Hofmeyr5-20/+18
Change-Id: I6bb053def223ed698351ad9f52c1e36293df5d59
2019-01-12refactor log ctx for vlr_subscr and ran_connNeels Hofmeyr18-11406/+11763
ran_conn_get_conn_id(): instead of a talloc allocated string, return a static buffer in ran_conn_get_conn_id(). So far this function had no callers. Refactor ran_conn_update_id() API: during early L3-Complete, when no subscriber is associated yet, update the FSM Id by the MI type seen in the L3 Complete message: ran_conn_update_id_from_mi(). Later on set the vsub and re-update. Call vlr.ops->subscr_update when the TMSI is updated, so that log context includes the TMSI from then on. Enrich context for vlr_subscr_name and ran_conn fi name. Include all available information in vlr_subscr_name(); instead of either IMSI or MSISDN or TMSI, print all of them when present. Instead of a short log, rather have more valuable context. A context info would now look like: Process_Access_Request_VLR(IMSI-901700000014706:MSISDN-2023:TMSI-0x08BDE4EC:GERAN-A-3:PAGING_RESP) It does get quite long, but ensures easy correlation of any BSSAP / IuCS messages with log output, especially if multiple subscribers are busy at the same time. Print TMSI and TMSInew in uppercase hexadecimal, which is the typical representation in the telecom world. When showing the RAN conn id GERAN_A-00000017 becomes GERAN-A-23 - We usually write the conn_id in decimal. - Leading zeros are clutter and might suggest hexadecimal format. - 'GERAN-A' and 'UTRAN-Iu' are the strings defined by osmo_rat_type_name(). Depends: I7798c3ef983c2e333b2b9cbffef6f366f370bd81 (libosmocore) Depends: Ica25919758ef6cba8348da199b0ae7e0ba628798 (libosmocore) Change-Id: I66a68ce2eb8957a35855a3743d91a86299900834
2019-01-12rx CM Service Req: reject double use soonerNeels Hofmeyr2-9/+9
When a CM Service Req is being rejected, we should do so before changing the state of the current conn. Concerning multiple CM Service Requests: in fact we should store multiple requests, but first fix the status quo of rejecting multiple requests. Change-Id: I39209ee6662694aa054a2fc0d21eae76fb33e2f1
2019-01-12add LOG_RAN_CONN() to use the conn->fi->id for contextNeels Hofmeyr19-262/+295
For each conn, set a default logging category, to distinguish categories for BSSMAP and RANAP based conns. LOG_RAN_CONN(): log with the conn's default category, LOG_RAN_CONN_CAT(): log with a manually set category (mostly for keeping previous DMM logging on the same category). In some places, replace LOGP() using manual context with LOG_RAN_CONN(), and remove the manual context info, now provided by the conn->fi->id. This is loosely related to inter-BSC and inter-MSC handover: to speed up refactoring, I want to avoid the need for manual logging context and just use this LOG_RAN_CONN(). Change-Id: I0a7809840428b1e028df6eb683bc5ffcc8df474a
2019-01-12use osmo_lu_type_name() from libosmocoreNeels Hofmeyr10-72/+63
Change-Id: Ib562bb5fb272c0c3ae0849f32b28faa2c26f9bb7
2019-01-11libmsc/gsm_04_11.c: accept MT SMS messages over GSUPVadim Yanitskiy5-4/+164
Change-Id: I57357982ca0e51f6722c24a4aa1d0fb3e6caef88 Depends-on: (core) Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71 Depends-on: (OsmoHLR) I0589ff27933e9bca2bcf93b8259004935778db8f Related Change-Id: (TTCN) I63a25c8366cce0852df6b628365151661a22a25f Related: OS#3587
2019-01-10Use explicit protocol discriminator for NC SS/USSD sessionMax1-6/+5
In gsm0911_rcv_nc_ss() we sometimes use pdisc parsed from msgb and sometimes constant. This function is only called when protocol discriminator is GSM48_PDISC_NC_SS so there's no point in parsing it again from msgb. Let's make it consistent and always use constant. Change-Id: Iae40bf9906fe676ff817c709120015fca4c9e042
2019-01-09VLR: vlr_subscr_{,msisdn_or_}name: const vsub argOliver Smith2-4/+4
Make the vsub argument of both vlr_subscr_msisdn_or_name() and vlr_subscr_name() a const. The LOGVSUBP() macro uses vlr_subscr_name() and will not generate a warning anymore when used with a const vsub. Change-Id: If609269191f4df6186d823a2eee14012846328e2
2019-01-09vlr_core.h: remove duplicate declarationsOliver Smith1-2/+0
Remove vlr_subscr_name() and vlr_subscr_alloc() declarations from vlr_core.h, as they are already defined in osmocom/msc/vlr.h and vlr.h gets included on top of vlr_core.h. Change-Id: I5c029be490577b513395dc3f2c2698f365157e73
2019-01-09msc_vty.c: make check-imei-rqd configurableOliver Smith2-0/+17
Related: OS#3189 Change-Id: Iee516b9cd7877b21207ce9a6d954109f19558163
2019-01-09Cosmetic: msc_vty: remove redundant "0 =", "1 ="Oliver Smith1-2/+2
Remove "0 =", "1 =" in-front of the boolean descriptions of auth-tuple-reuse-on-error. The online VTY doc and the pdf manual prepend the value automatically. Change-Id: Ifd14c2fb3f58701eaf66570d729a660233fb83ed
2019-01-05use mgcp-client configured endpoint domain nameneels/mgw_domainNeels Hofmeyr1-7/+6
Rationale: reading pcaps becomes so much easier when each of osmo-bsc and osmo-msc address their MGW with differing domain names. Otherwise, both will have a '0@mgw' endpoint and it gets really confusing. After this, with according configuration, there can be a '0@bsc' and a '0@msc' endpoint. osmo-mgw-for-msc.cfg: mgcp domain msc osmo-msc.cfg: msc mgw endpoint-domain msc Depends: Ia662016f29dd8727d9c4626d726729641e21e1f8 (osmo-mgw) Change-Id: I87ac11847d1a6d165ee9a2b5d8a4978e7ac73433
2019-01-04use osmo_rat_type from libosmocoreNeels Hofmeyr36-847/+831
Replace locally defined enum ran_type with libosmocore's new enum osmo_rat_type, and value_string ran_type_names with osmo_rat_type_names. The string representations change, which has cosmetic effects on the test suite expectations. Depends: I659687aef7a4d67ca372a39fef31dee07aed7631 (libosmocore) Change-Id: I2c78c265dc99df581e1b00e563d6912c7ffdb36b
2019-01-04vty cfg: move 'ipa-name' from 'msc' to 'hlr' sectionNeels Hofmeyr2-23/+22
during code review, I completely overlooked this: We've added the 'ipa-name', which identifies the MSC on the GSUP link to the HLR, under the 'msc' section, while all other GSUP/HLR related config is under the 'hlr' section. Before we roll that out in a release, move it over to 'hlr'. Related: OS#3355 Change-Id: I1a572865aa90c5fa43c6f57282a6e2b06776e425
2019-01-04vlr: auth_fsm: make sure vsub->auth_fsm = NULL when it terminatesNeels Hofmeyr1-3/+7
Probably fixes this segfault: at ../../../../src/osmo-msc/src/libvlr/vlr_lu_fsm.c:957 file=file@entry=0x5611d8f10c28 "../../../../src/osmo-msc/src/libvlr/vlr_lu_fsm.c", line=line@entry=1467) at ../../../src/libosmocore/src/fsm.c:580 parent_event_failure=parent_event_failure@entry=6, parent_event_data=parent_event_data@entry=0x0, vlr=0x5611d98862b0, msc_conn_ref=msc_conn_ref@entry=0x5611d9aa8150, type=VLR_LU_TYPE_REGULAR, tmsi=4294967295, imsi=0x7ffd756c1cf0 "262423403004874", old_lai=0x7ffd756c1ce0, new_lai=0x7ffd756c1ce8, authentication_required=true, ciphering_required=true, is_r99=false, is_utran=false, assign_tmsi=true) at ../../../../src/osmo-msc/src/libvlr/vlr_lu_fsm.c:1467 at ../../../../src/osmo-msc/src/libmsc/gsm_04_08.c:443 The segfault is indirectly caused by 1fbf45c291f7e1f09ef2e862abfeca6a23efdc03, 'enrich context for vlr_subscr_name and ran_conn fi name', which sets auth_fsm context, on a non-NULL auth_fsm that has been deallocated. Change-Id: I3c528eed295be2ee673ea295804372f388a0dccd
2019-01-04abort assignment on Assignment FailureNeels Hofmeyr3-1/+24
If Assignment fails in the BSC, trigger an EV_TEARDOWN_ERROR in the mgcp_ctx FSM instance, so that the call gets torn down immediately. Before this, the non-call would idle around without anything happening. Related: OS#3236 Depends: I11b182a03f5ecb6df7cd8f260757d3626c8e945d (libosmocore) Change-Id: I358cfbaf0f44f25148e8b9bafcb9257b1952b35a
2019-01-04fix: incoming call during ongoing callNeels Hofmeyr1-0/+31
If a call is already busy and another call is coming in, do not try to immediately assign an lchan (before this patch, it fails because there already is an mgcp_ctx for the conn). Leave the second CC transaction waiting. When a call is hung up, as soon as the old mgcp_ctx is discarded, look for other CC transactions that are waiting. If there is one, trigger assignment, so a new mgcp_ctx is set up for the new call. This fixes the following scenario: - from A, call B. - from C, call B; B rings during ongoing call. - in B, pick up the call, choose to drop the old call. After this patch, and with osmo-bsc patch with change-id I0c00ec2c120e5008281755adcd4944a3ce4d8355 we are now able to talk to the new caller. I currently haven't tested yet what happens if there is *three* peers trying to talk to the same number, running out of lab phones (not really, just not bothering now). Possibly we should be taking over the particular call indicated by the CC TI; instead, the current patch version takes on whichever waiting call it finds first. This is fine if *one* additional call comes in on an ongoing call, and this is already a huge improvement to what we had before. Related: OS#3735 Change-Id: I0ba216b737909e92080a722db26e3577726c63cb
2019-01-04move trans->assignment_done to cc.assignment_startedNeels Hofmeyr2-6/+4
The flag is set to true when an assignment has been started, and it is only relevant for a CC transaction. So fix naming and place in cc struct. Cosmetic preparation for I1f8746e7babfcd3028a4d2c0ba260c608c686c76 and I0ba216b737909e92080a722db26e3577726c63cb/ Change-Id: I8dacf46141ba0b664e85b0867ade330c97d8495f
2019-01-04remove code dup: add msc_mgcp_try_call_assignment()Neels Hofmeyr5-27/+24
Various places in the code check a flag whether assignment was started and launch it. To fix incoming-call-during-ongoing-call, I will tweak that logic. To be able to do that only in one place, remove code dup. Cosmetic preparation for I1f8746e7babfcd3028a4d2c0ba260c608c686c76 and I0ba216b737909e92080a722db26e3577726c63cb/ Depends: I11b182a03f5ecb6df7cd8f260757d3626c8e945d (libosmocore: LOGPFSMSL) Change-Id: I11c0b7dc3f1a747028629b48e522bb3b864884ba
2019-01-04Constify transaction helpers parametersMax2-10/+10
Change-Id: If002a1ff6ba4218cc16592946798340fcb1852ae
2019-01-04fix vlr ops.subscr_assoc re-associationNeels Hofmeyr4-10/+26
In rare cases, a conn is already associated with a subscriber. So far, we abort()ed on that, bringing the entire osmo-msc down. Rather log an error and keep the service running. In vlr.ops.subscr_assoc, add success/failure return value, and abort the LU/PARQ on error. I haven't figured out in detail yet why/how a subscriber would re-launch a LU/PARQ on a conn that is already associated, so far it is merely clear that we do not want to crash the MSC if that happens. A log is in OS#3742. Related: OS#3742, OS#3743 Change-Id: Ic0d54644bc735700220b1ef3a4384c217d57d20f
2019-01-03release RTP stream only for matching CC transactionNeels Hofmeyr1-0/+6
Do not break the currently ongoing call when rejecting a second incoming caller. There may be multiple (up to seven) simultaneous CC transactions, and there is one mgcp_ctx for the currently active RTP stream. Release the MGCP context only when the active CC transaction is releasing. Before this patch, any CC transaction release would destroy the single MGCP context, possibly breaking the currently ongoing call (another CC trans). This also fixes a possible use-after-free if there were pending MGCP message responses for the MGCP context; they are canceled properly for a released transaction, but since one transaction would free the other transaction's MGCP state, the clean up did not take place and possibly caused an mgcp client response handling to access a freed mgcp_ctx. Related: OS#3735 Change-Id: I1f8746e7babfcd3028a4d2c0ba260c608c686c76
2019-01-03cosmetics in msc_mgcp_call_release()Neels Hofmeyr1-8/+8
Use local variables instead of writing trans->conn-> all the time. Cosmetic preparation for I1f8746e7babfcd3028a4d2c0ba260c608c686c76 and I0ba216b737909e92080a722db26e3577726c63cb/ Change-Id: I99717b3b72a9d7cbc95455ea25b2018ec1755308
2018-12-30libmsc/gsm_04_11.c: forward MO SMS messages over GSUPVadim Yanitskiy7-2/+249
Change-Id: I7d651fde3d608d02f275a74043dc42262aabb1b8 Depends-on: (core) Ic37f3b2114b8095cfce22977e67133b9103942e3 Depends-on: (core) Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71 Depends-on: (OsmoHLR) I0589ff27933e9bca2bcf93b8259004935778db8f Related Change-Id: (TTCN) I7abc95b8e416f7308d54e11be11c08586d18e6c5 Related Change-Id: (TTCN) Id14bbd8bd51558cdacefea0fe042769cd69ed5c8 Related: OS#3587
2018-12-30libmsc/VTY: introduce kill-switch for routing SMS over GSUPVadim Yanitskiy3-0/+33
As a rudiment of OsmoNiTB, OsmoMSC is still involved in SMS processing, storage (in SQLite DB), and routing (via SMPP). In real networks this is done by the external entity called SMSC (SMS Centre), while the MSC is doing re-encapsulation of GSM 04.11 SM-TL (Transport Layer) payload (i.e. TPDU) between SM-RL (Relay Layer) and MAP. Since OsmoMSC itself is not a 'Network in The Box' anymore, it makes sense to replicate the 'traditional' behaviour of MSC. The problem is that this behaviour cannot co-exist with the current implementation, so the key idea is to rip out the local SMS storage and routing from OsmoMSC, and (re)implement it in a separate process (OsmoSMSC?). As a temporary solution, this change introduces a 'kill-switch' VTY option that enables routing of SMS messages over GSUP towards ESME (through VLR and HLR), but breaks the local storage and routing. This is why it's disabled by default. As soon as we move the SMS processing and storage away from OsmoMSC, this behaviour would be enabled by default, and the VTY option would be hidden and deprecated. At the moment, this option basically does nothing, and will take an effect in the follow-up changes. Change-Id: Ie57685ed2ce1e4c978e775b68fdffe58de44882b Related: OS#3587
2018-12-23MNCC: use log wrapper for call processingMax1-13/+12
Add log/debug wrappers to conveniently print local and remote call references. Change-Id: I5c44d7bb28f1ff895dd4f839d75840495503c916
2018-12-21use vty->type instead of local variableStefan Sperling3-7/+1
We can check if we're parsing the config file by checking whether vty->type equals VTY_FILE. This avoids the use of an extra local variable to track the parsing state. Change-Id: I85161575e025f7c389832427a434bd8e2d6ecc75 Fixes: 1051c4208834c22d344dd92d25addfd8e5d95993 Related: OS#3355
2018-12-20fix test_nodes.vty after libosmo-mgcp-client vty changesNeels Hofmeyr1-2/+0
osmo-mgw I98a9f1f17a1c4ab20cea3b08c7d21663592134d6 broke the build here. Fix that. Change-Id: I20e37c5228928b67e67f16aef0eb2930d21ef60a
2018-12-19mgcp log tweak: say RAN, not BTS, like surrounding loggingNeels Hofmeyr1-1/+1
Change-Id: Ibb40155189a7f05ba2da4fcf9cf03fda5ffc3683
2018-12-19fix msc_mgcp_fsm_evt_names: two missing eventsNeels Hofmeyr1-0/+2
Change-Id: I66ebaf0a55de1a46bccbc86652ffa9b73c951ebf
2018-12-19msc_vty: also show IMEI and IMEISVPhilipp Maier1-0/+4
When the VLR subscriber information is shown on the VTY it shows IMSI and TMSI, but not IMEI and IMEISV. Since in some cases this information might be helpful, lets display it as well. Change-Id: Iedd75dbb9850388ec1fedb984ed0b8bf4c62e780
2018-12-19Remove redundancy in LAC processingMax8-11/+9
Always use LAC which is part of Cell Global ID otherwise we might end up in a situation where separately stored LAC differs. Both are described in 3GPP TS 23.008 $2.4 as temporary subscriber data to be stored in VLR. Both are defined in 3GPP TS 23.003. The LAC is part of LAI which is part of CGI so there should be no case when those values differ for a given subscriber. Change-Id: I993ebc3e14f25e83124b6d3f8461a4b18f971f8e
2018-12-19msc_vty: display current RAN typePhilipp Maier1-0/+2
When a subscriber is displayed the RAN type is not included in the overview. Meanwhile the MSC supports multiple different ran types it becomes important to see in which RAN the subscriber is currently active. Change-Id: I000cafd5e41b9951d51b6bd6672ee68a224b8212 Related: OS#3615
2018-12-19msc_vty: display subscriber flagsPhilipp Maier1-0/+19
When a VLR subscriber is displayed on the VTY we get a lot of meta information, but there are also some flags to handle the internal subscriber status e.g. conf_by_radio_contact_ind. Lets display those flags as well as this information can be very helpful when debugging problems in the VLR Change-Id: I59a9145a4daad50d68de3fd5c3291f027256917f