Commit Graph

6663 Commits (7c5346cd7005ad469702a2f74572b79de738fbbb)

Author SHA1 Message Date
Neels Hofmeyr 7c5346cd70 vlr_subscr: use osmo_use_count
Depends: Ife31e6798b4e728a23913179e346552a7dd338c0 (libosmocore)
Change-Id: Ib06d030e8464abe415ff597d462ed40eeddef475
2019-04-12 02:15:25 +02:00
Neels Hofmeyr d553c085e7 sms queue: avoid repeated Paging for a failed SMS
So far, sms_pending_failed() starts a new sms_queue_trigger() run. The
intention behind that might have been to fill up the queue when sending SMS has
failed, but the practical effect is actually bad:

As current ttcn3-msc-test runs show, a failed MT SMS gets triggered multiple
times in short succession, i.e. osmo-msc repeatedly sends Paging Requests for
the same subscriber.

This special case happens actually only when there are few SMS still in the DB
to be delivered. In the TTCN3 test, there is exactly one MT SMS for one
subscriber, and retriggering the queue brings up the same SMS every time.

See f_tc_lu_and_mt_sms_paging_and_nothing() and f_tc_sgsap_mt_sms_and_nothing()
which say:
"/* Expect the MSC to page exactly 10 times before giving up */"

This is bad because an MSC should send a Paging Request exactly once. Retrying
failed Paging is clearly the task of the BSC, not the MSC. The remaining code
around Paging correctly follows this paradigm, but this retrigger doesn't.

Do not immediately trigger the SMS queue on a failed MT SMS. Instead, leave it
up to the periodical SMS queue trigger to decide.

This patch will cause the MT SMS tests in ttcn3-msc-tests to fail, because the
test expectations are bogus. The patch fixing the test run is listed 'Related'

Related: I7dce12942a65eaaf97f78ca69401c7f93faacb9e (osmo-ttcn3-hacks)
Change-Id: I24bf9f1c1167efe1080ae4cf47ed2ef0bd981e49
2019-04-12 02:15:25 +02:00
Neels Hofmeyr e4f7e71204 enable osmo_fsm_term_safely(), apply logging changes
Start using osmo_fsm_term_safely(true), the recently added feature of
libosmocore's fsm.c. Deallocates in slightly changed order and with slightly
modified logging. Adjust test expectations.

Depends: I8eda67540a1cd444491beb7856b9fcd0a3143b18 (libosmocore)
Change-Id: I195a719d9ec1f6764ee5a361244f59f0144dc253
2019-04-12 02:15:25 +02:00
Philipp Maier 7231edb732 sgs_iface: fix nullpointer dereference
The function sgs_tx() is using the sgs connection pointer as context,
even though it has done a check for a nullpointer in the line before.
This is very prone to lead into a segfault when the SGs connection dies.

Change-Id: I88b95e3f8cd35241ad68f08d94c6ad7067b842e6
Related: OS#3859
2019-04-11 07:32:48 +00:00
Harald Welte 5dede769e7 smpp_smsc: Call destroy_tlv() when using build_tlv()
The libsmpp34 build_tlv() function is allocating dynamic memory
which we need to release again by calling destroy_tlv().

Change-Id: Iacc74c9948fb10fa79c0dd7b0cb72d4adbefdeed
Closes: OS#3912
2019-04-10 10:53:23 +00:00
Pau Espin f8af776fba sms_queue: Print dest msisdn instead of unknown subscriber
If subscriber is NULL, vlr_subscr_msisdn_or_name() returns string
"unknown", which is less informative than printing destination msisdn
expected for the queued sms.
This happens for instance if an sms was queued with Store&Forward and
destination subscriber is not currently registered

Change-Id: I4b8b54c9c41b17d4e1fa7ece63aa91a98036ef11
2019-04-09 19:45:03 +07:00
Vadim Yanitskiy 0f52319765 msc/gsm_data.h: drop unused SMS_HDR_SIZE macro
Change-Id: Iea32a26673ebb57b18dc7e86ad321d9ed48e0948
2019-04-08 07:34:20 +00:00
Philipp Maier 4826465708 vlr_sgs: start lu expiration timer on sgs eps detach
When the subscriber is detached from SGs services (but not from 2g
services). Then the subscriber essentially becomes a regular 2g
subscriber, which means thet the lu expiration timer needs to be

Change-Id: If95c63706dc1c5a537f7cd1b6481252427cbf234
Related: OS#3614
2019-04-07 18:57:39 +00:00
Philipp Maier 0803d88d9a vlr_sgs: fix SGs IMSI detech from non EPS services
When the subscriber is detached from non EPS services while the
SGs-association is not SGs-NULL, it needs to be removed from the VLR

Change-Id: I575cf6036ad39468f590b2d57a06cd3512a4c31c
Related: OS#3614
2019-04-07 18:57:31 +00:00
Vadim Yanitskiy 6c766c6464 tests/sms_queue: track the use of NULL talloc memory contexts
As we don't initialize all talloc contects of libmsc, let's make
sure that there is nothing left in the NULL context after the
unit test execution is finished.

Change-Id: I99fd82750aff376e4d90eaa2402ec41f4d59ef86
2019-04-01 12:02:57 +00:00
Vadim Yanitskiy 96262a7ca6 libmsc/sms_queue.c: fix memleak in smsq_take_next_sms()
A memleak has been noticed after executing some of TTCN-3 test
cases. For example, the following ones:

  - MSC_Tests.TC_lu_and_mo_sms,
  - MSC_Tests.TC_lu_and_mt_sms.

The key point is that MSC_Tests.TC_lu_and_mo_sms basically sends
a MO SMS to a non-attached subscriber with MSISDN 12345, so this
message is getting stored in the SMSC's database.

As soon as the SMSC's queue is triggered, sms_submit_pending() would
retrieve pending messages from the database by calling function
smsq_take_next_sms() in loop and attempt to deliver them.

This function in it's turn checks whether the subscriber is attached
or not. If not, the allocated 'gsm_sms' structure would not be
free()ed! Therefore, every time smsq_take_next_sms() is called,
one 'gsm_sms' structure for an unattached subscriber is leaked.

Furthermore, there is a unit test called 'sms_queue_test', that
actually does cover smsq_take_next_sms() and was designed to
catch some potential memory leaks, but...

In order to avoid emulating the low-level SQLite API, the unit
test by design overwrites some functions of libmsc, including
db_sms_get_next_unsent_rr_msisdn(), that is being called by

The problem is that the original function in libmsc does
allocate a 'gsm_sms' structure on heap (using talloc), while
the overwriting function did this statically, returning a
pointer to stack. This critical difference made it impossible
to spot the memleak in smsq_take_next_sms() during the
unit test execution.

Let's refactor 'sms_queue_test' to use dynamic memory allocation,
and finally fix the evil memleak in smsq_take_next_sms().

Change-Id: Iad5e4d84d8d410ea43d5907e9ddf6e5fdb55bc7a
Closes: OS#3860
2019-04-01 12:02:57 +00:00
Keith Whyte 18f1138a6d Write configuration correctly from vty (alert notifications)
The default is [yes] alert-notifications, therefore write
"no alert-notifications" in the case that this has
been set, in order to preserve configuration after
write is called from vty.

Change-Id: I079aea96ee83fbf04f782dcab344d41a4ef04657
2019-03-29 22:48:38 +00:00
Vadim Yanitskiy 81635d3400 libmsc: fix: properly initialize the SGs server
It was observed that the SGs server is started before
the actual VTY configuration is parsed. For example:

   local-port 9999

produces the following debug output:

  <0011> sgs_server.c:185 SGs socket bound to r=NULL<->l=
  DLSS7 NOTICE <001e> osmo_ss7.c:1284 0: ASP Restart for server not implemented yet!
  DSGS NOTICE <0011> sgs_server.c:185 SGs socket bound to r=NULL<->l=
  DSGS NOTICE <0011> sgs_server.c:185 SGs socket bound to r=NULL<->l=
  DMNCC DEBUG <0004> msc_main.c:604 Using internal MNCC handler.

The first startup is triggered by sgs_iface_init(), before reading
the VTY configuration, so the logging style is different. The next
two calls to sgs_server_open() are triggered during reading of the
VTY configuration by cfg_sgs_local_port() and cfg_sgs_local_ip().

Let's avoid starting the SGs server three times, and do it once,
after the VTY configuration is parsed. Also, keep the possibility
to change the binding parameters at run-time.

Change-Id: Ie0c31205ac48be7e50d0380a89833771b2708da4
2019-03-28 17:10:11 +07:00
Vadim Yanitskiy 1d802e2635 libmsc/sgs_vty.c: don't print SGs socket error twice
Because sgs_server_open() already does this.

Change-Id: Ifea308645c7829691dbcf53e4f59841090119006
2019-03-28 10:09:11 +00:00
Vadim Yanitskiy 4eaefc2222 libmsc/sgs_iface.c: register sgs_vlr_reset_fsm on DSO load
Change-Id: I80cd2e5645d6e391080376250c0853a3f3f821ef
2019-03-28 10:09:11 +00:00
Vadim Yanitskiy 118a0b890e libmsc/sgs_iface.c: fix copy-paste error
Change-Id: I57b773659302ad4c92b6e670c6156e90a50189ba
2019-03-28 10:09:11 +00:00
Pau Espin 0dad52d0b7 debian/control: Fix typo
Change-Id: I3392d8e184413203d27fc3d75371de4d66f205b9
2019-03-27 11:42:29 +00:00
Neels Hofmeyr 83e311fa3e vlr_subscr_name(): use OSMO_STRBUF
We now have a nicer way to compose strings in a buffer than this.
(Cosmetic preparation for inter-MSC handover patch.)

Change-Id: I7813068032475deb3850af05f7ba5a6f652e7fa2
2019-03-24 16:49:07 +00:00
Philipp Maier 8fa2dbe5b1 msc_vty: add missing header file
The symbol GSM0808_SPEECH_FULL_BM is used in msc_vty.c, but gsm_08_08.h,
where the symbol is declared is not included.

Change-Id: I31a8894031aa2321d7dbf2586d076bc303247278
2019-03-19 18:52:56 +01:00
Sylvain Munaut da9f37ed20 libvlr: Allow 2G auth tuples to be re-used without going through AUTH
If the key_seq we get in the first messages matches the last_tuple, then
both we and the MS already know the key to use and we don't need the

Security wise ... not so good, and so IMHO the 'auth required' option
in the MSC should always be set. But this allows to turn on ciphering on
a channel without doing any MM transaction, and so the MS doesn't turn
on the T3240 timer which allows to have a ciphered silent-call channel
that won't timeout.

Change-Id: Ief840a2ae7a0ffd2bf0bf726f209a79e3f787646
Signed-off-by: Sylvain Munaut <>
2019-03-19 15:24:01 +00:00
Harald Welte 31f4c1f927 a_iface: OSMO_ASSERT() if we ever want to send BSSAP with invalid length
Let's add a safeguard against sending BSSAP messages with invalid length
values.  This should never happen, and we'd rather see osmo-msc assert
during the development cycle than ever releasing a version which sends
invalid messages out on the wire.

Change-Id: I94327a0d276c65b528a8c7e33dde61ed53582284
Related: OS#3805
2019-03-19 13:39:14 +00:00
Philipp Maier 9286114f6f silent_call: use osmo_strlcpy() instead of strncpy()
If gsm_silent_call_start() is called with an over long string in
traffic_dst_ip, then the target string might be left unterminated. Lets
use osmo_strlcpy() so that we can be sure the result in scd->traffic_ip
is always terminated.

Fixes: CID#196068
Change-Id: Ic81842175e412ae7d97d023b612412f33411d60c
2019-03-15 09:51:15 +01:00
Sylvain Munaut 935583069d libmsc: Allow different channel types to be requested as silent calls
Change-Id: I82645708dd27864cf33ea9cc993ead0983415602
2019-03-14 12:39:31 +00:00
Neels Hofmeyr f90496f577 vty: add cmd subscriber ID sms delete-all
In ttcn3-msc-tests, so far we leave an intentionally failed MT SMS in the SMS
queue, which may cause it to re-appear in subsequent tests.

Allow removing all SMS for a given subscriber from the SMS database for good.

(I dimly remember a user report where the SMS queue spams failed SMS attempts,
and the only way to get rid of SMS for a given subscriber is to tamper with the
sms.db file directly. This should no longer be necessary with this command.)

Related: I7dce12942a65eaaf97f78ca69401c7f93faacb9e (osmo-ttcn3-hacks)
Change-Id: I637cbd7adc075a192f49752b38779391472ff06d
2019-03-08 04:51:18 +01:00
Neels Hofmeyr 34a36da3ef SMS queue: properly log failed attempts number
Change-Id: I16f2d29855eb715eccbdc5def225f43c110fab8e
2019-03-07 04:17:53 +01:00
Neels Hofmeyr 864d32c043 gsm_04_11_gsup.c: drop unused conn lookup
An earlier code state used the conn to lookup the transaction, but this is now
done by vsub. Hence the conn lookup is not used and not needed.

conn is no longer used since 36c44b2100,
change-Id I093f36d63e671e50e54fc6236e97a777cc6da77b,
"transaction: change arguments of trans_find_by_sm_rp_mr()"

Change-Id: Ia878d70138c883cb1a1d983516aff83efa6488ce
2019-03-07 04:17:47 +01:00
Neels Hofmeyr 8e2c6a31c1 use only accepted ran_conns for new transactions
In connection_for_subscriber(), do not return a ran_conn that is not yet
authenticated nor one that is already in release.

Using a ran_conn that is not yet authenticated may cause an auth/ciph

Using a ran_conn that is already in release may cause a use-after-free, see
OS#3842 for a description.

To be paranoid, upon releasing a conn, go through the transaction freeing
motions again by calling trans_conn_closed(), just in case some odd code path
added another transaction while the conn was already in release.

Related: OS#3842
Change-Id: Id957032e0ae1ff8ba055a75c3523447d3d06cbc3
2019-03-07 03:58:29 +01:00
Keith Whyte a3a8821167 Don't deliver alert notifications to ESME not yet bound.
We create a new ESME in smsc->esme_list on establishment
of a TCP connection, yet we do not know the system id 
or anything else, until the ESME identifies and authenticates.

So do not send alert notifications until
we know the bind status (and system_id)

Change-Id: Iec92d4c145ca050c2e212139572eeaae581b99df
2019-02-28 14:18:29 +00:00
Vadim Yanitskiy 477cbc6d93 libmsc/msc_vty.c: drop dead comparison against null
Since vsub->sgs.mme_name is allocated statically, comparing it
to null doesn't make sense - it's always != NULL.

Change-Id: Ib2933a20471ebff9dfe1d9fdddf39d177504c951
Fixes: CID#178166 Array compared against 0 (NO_EFFECT)
2019-02-28 00:14:21 +07:00
Vadim Yanitskiy 4d75877e61 libmsc/sgs_vty.c: always write server address and VLR name
Comparing an array to null is not useful, because the expression
will always evaluate as true. Let's just always write SGs server
address and VLR name, no mater whether default values are used
or not, same as we do for the HLR address and port.

Change-Id: If045e42fca0315b0777eb86c44bf934ce58b340b
Fixes: CID#190871 Array compared against 0 (NO_EFFECT)
2019-02-28 00:14:15 +07:00
Vadim Yanitskiy e9ef7c6b9a libmsc/sgs_iface.c: fix SGS_STATE_NS11 counter reference
The SGS_STATE_TS11 is not for counters, it's for timers!

Change-Id: Ifbb1a37e644ae8bf8e7959f6f6cd6403ac1f2f1b
Fixes: CID#190872 Out-of-bounds read (OVERRUN)
2019-02-26 23:16:45 +00:00
Vadim Yanitskiy 1396e1ca35 libmsc/ran_conn.c: add missing 'break' to OSMO_RAT_EUTRAN_SGS
Change-Id: I18dfd08ea0857f2751164a295dd9de20a2024ac3
Fixes: CID#190874
2019-02-26 23:16:10 +00:00
Oliver Smith 0dfa61e39e debian: depend on libdbd-sqlite3
Make sure that we don't fail at startup with:

<0009> db.c:621 Failed to create database connection to sqlite3 db
'sms.db'; Is the sqlite3 database driver for libdbi installed on this

Tested by building the Debian package and looking at its depends.

Related: OS#3771
Change-Id: I7c099212a6ad7d87978c3dce63ce7385d8076bd1
2019-02-25 14:59:03 +01:00
Vadim Yanitskiy 64623e1848 libmsc/gsm_09_11.c: implement guard timer for NCSS sessions
It may happen that either the MS or an EUSE would become
unresponsive during a call independent SS session, e.g.
due to a bug, or a dropped message. In such cases, the
corresponding transaction would remain unfreed forever.

This change introduces a guard timer, that prevents keeping
'stalled' NCSS sessions forever. As soon as it expires, both
sides (i.e. MS and EUSE) are getting notified, and the
transaction is being released.

By default, the timer expires after 30 seconds. As soon as
either the MS, or an EUSE initiates any activity,
the watchdog timer is rescheduled.

The timeout value can be configured from the VTY:

   ! Use 0 to disable this timer
   ncss guard-timeout 30

Please note that changing the timeout value at run-time
doesn't affect the existing NCSS sessions, excepting the
case when the timer is disabled at run-time.

This change makes TC_lu_and_ss_session_timeout pass.

Change-Id: Icf4d87c45e90324764073e8230e0fb9cb96dd9cb
Related Change-Id: (TTCN) I3e1791773d56617172ae27a46889a1ae4d400e2f
Related: OS#3655
2019-02-20 03:22:38 +07:00
Harald Welte 390d140b56 a_iface: Fix hexdumping of N-DATA.req
For some reason the existing code was using msgb_hexdump_l2() while the
L2 header is not used by the BSSAP transmit code.  Let's fix this.

Change-Id: I52a1eb3a867ece63fcfa4c2a720d035ebfb90a7b
2019-02-18 13:52:09 +01:00
Harald Welte fd96d45049 a_iface: use 'const' qualifier for ran_conn whenever possible
Change-Id: I8a15c9baae2071569e2ecc4635ddaf5a0001f959
2019-02-18 13:52:09 +01:00
Harald Welte 977b5486b1 a_iface: Centralize/wrap BSSAP / N-DATA transmission
We don't want multiple callers to osmo_sccp_tx_data_msg() each having
to hex-dump a log message about the to-be-transmitted message, with
half of the caller sitest missing that printing.  Let's centralize
all calls of osmo_sccp_tx_data_msg() in a wrapper function which
takes care of the related OSMO_ASSERT() and the related printing.

Change-Id: I6159ea72cc8e0650eda6c49544acd65e9c15e817
2019-02-18 13:52:05 +01:00
Vadim Yanitskiy 2eaee70ada transaction.h: use #pragma once as include guard
Change-Id: I52787120d5ec59897329d28eab28e0fda3d0f44f
2019-02-15 02:19:30 +07:00
Vadim Yanitskiy baeeb90907 transaction: fix description of trans_assign_trans_id()
Change-Id: I80238d89e95b6fd791961c48de80aac69ff5b0e9
2019-02-15 02:19:30 +07:00
Max d8daaae91e transaction: clarify magic 0xff transaction ID
Change-Id: I2d3a6334f49989bedbb1430d26ffad8b61dfd873
2019-02-15 02:19:30 +07:00
Max 30fb97aa43 transaction: drop meaningless ti_flag of trans_assign_trans_id()
According to GSM 04.07, the TI flag takes one bit and can be
either of the following:

  '0'B - transaction is allocated by sender of a message,
  '1'B - transaction is allocated by receiver of a message.

Since we store transaction ID in gsm_trans structure, we also store
TI flag (as a part of transaction ID), which in this context means:

  '0'B - transaction is allocated by us (OsmoMSC),
  '1'B - transaction is allocated by some MS.

In 100% cases, trans_assign_trans_id() is used to assign transaction IDs
to transactions allocated by us (i.e. OsmoMSC) for MT connections. And
there is no need to use it for MO transactions, because they basically
already do contain a valid transaction ID assigned by the MS.

Change-Id: Ie11999900b1789652ee078d34636dcda1e137eb0
2019-02-15 02:19:24 +07:00
Vadim Yanitskiy 114bad8c48 libmsc/osmo_msc.c: move connection ref-counting code to 'ran_conn.c'
The connection ref-counting implementation is specific to RAN
connections, and is not applicable for anything else. Moreover,
the API of this code is declared in 'ran_conn.h', so let's
move the code to a more logical place.

Change-Id: I593675d9bf56eaef12afdaf596ee1337b9a44259
2019-02-14 09:26:47 +00:00
Vadim Yanitskiy 3acfe68b8b libmsc/gsm_04_80.c: add msc_send_ussd_release_complete_cause()
According to GSM 04.80, section 2.5.1, Release complete message
may have an optional Cause IE. Let's add a new function, that
allows to specify cause location and value.

This function will be used by the upcoming changes.

Change-Id: I3b9e8e4f473d113d5b9e9e5d33f7914202077203
Depends Change-Id: (libosmocore) Ie3ac85fcef90a5e532334ba3482804d5305c88d7
2019-02-13 12:50:14 +00:00
Vadim Yanitskiy f20c6b7bd5 libmsc/gsm_04_80.c: use gsm0480_create_release_complete()
The previous implementation of msc_send_ussd_release_complete() was
based on gsm0480_create_ussd_release_complete(), that doesn't
allow to specify GSM 04.07 transaction identifier.

The ability to specify particular transaction identifier
is required for handling multiple SS/USSD transactions.

Change-Id: Id2975c3383f18e83124ba38927c03980d67ddadb
Depends Change-Id: (libosmocore) Ie3ac85fcef90a5e532334ba3482804d5305c88d7
2019-02-13 12:50:14 +00:00
Philipp Maier 896950ab82 a_iface: Include CSFB Indication into BSSMAP CLEAR COMMAND
When a call ends that has been established in an CSFB context, we should
add a CSFB Indication IE to the BSSMAP CLEAR COMMAND to instruct the BSC
to add further CSFB related IEs into the RR RELEASE.

- Check if an SGs association exists and add CSFB Indication IE

Change-Id: I6cfa4b3becdd0138d74e2e1eddd83a0b1568c1de
Related: OS#3778
2019-02-07 10:01:46 +01:00
Harald Welte 845285077d Check for libsctp
Since we merged the SGs interface, we include <netinet/sctp.h>, which
is provided by libsctp.

Change-Id: Id2321e4cb3800929cea56785e5c5bd7480408806
2019-02-06 18:08:59 +00:00
Harald Welte ca292dd607 debian: depend on libsctp-dev
Since we merged the SGs interface, we include <netinet/sctp.h>, which
is provided by libsctp-dev.  This means that the Debian package should
depend on this.

It is expected that this will un-break the network:osmocom:nightly

Change-Id: I092e95ea970763c4008d3c7ff1b7028042574a64
2019-02-06 17:56:01 +00:00
Max 34d306be95 VLR tests: use msgb_eq_data_print() for comparison
This simplifies tests refactoring by showing exact byte where mismatch
happened. It also makes code more readable.

No changes in expected test output are necessary because the additional
logging will be triggered iff the test fails so the result will be
visible only during debugging of unit test issues.

Change-Id: If9771c973f2bc55580f4c146bdbeeb1609d56786
2019-02-05 16:25:03 +00:00
Harald Welte 0df904dea9 Add SGs Interface
Add an SGs interface (3GPP TS 29.118) to osmo-msc in order to support
SMS tunneling and Circuit Switched Fallback (CSFB)

Change-Id: I73359925fc1ca72b33a1466e6ac41307f2f0b11d
Related: OS#3615
2019-02-04 13:36:26 +01:00
Vadim Yanitskiy c7de62cc53 libmsc/gsm_04_11.c: introduce and use gsm411_assign_sm_rp_mr()
Initially, it was assumed that if there is no active RAN connection,
we can just start counting from 0x00, as there are no other SMS
related transactions, and transaction itself is allocated using
talloc_zero(). Until now it was looking good, but...

As soon as we establish RAN connection with subscriber, we already
have a transaction with SM-RP-MR 0x00, but conn->next_rp_ref also
remains 0x00 - it isn't being increased!

It means that we can face a SM-RP-MR conflict (or collision) if
another MT SMS would arrive to the MSC (from SMSC over GSUP)
when this transaction is still active, i.e. the first SMS is
still being sent, because conn->next_rp_ref++ would
return 0x00 again.

Moreover, there might be already a MO SMS transaction, and using
the conn->next_rp_ref counter wouldn't prevent us from having
duplicate SM-RP-MR value.

Let's get rid of this per-connection counter, and introduce a
function instead, that would iterate over existing transactions
and look for an unused SM-RP-MR value.

This change makes the following test cases pass:

  - TC_gsup_mt_sms_rp_mr,
  - TC_gsup_mo_mt_sms_rp_mr.

Discovered by: Neels Hofmeyr
Related Change-Id: (TTCN) I3a52d44f4abde9b6b471b9108c1cee905884c9bc
Related Change-Id: (TTCN) I17cbbaa64d9bce770f985588e93cd3eecd732120
Change-Id: Ife6d954c46b7d8348a4221ab677d0355eb3ee7ac
2019-02-01 18:55:54 +00:00