Commit Graph

1131 Commits (467bb87f44bd67aa7421f5ae4c3021d9200bd3c8)

Author SHA1 Message Date
Neels Hofmeyr 467bb87f44 log: drop duplicate MNCC log
Change-Id: I46055a4f7a6ae517772c6794faad8c775454974a
2019-10-21 00:40:31 +02:00
Neels Hofmeyr c192c0bf71 log which DTAP messages are sent to RAN
So far, the logging said only "RAN encode: BSSMAP: DTAP", but not *which* DTAP
message, which is in fact a very interesting detail when reading osmo-msc logs.

Change-Id: I0cb8d1e3307737ffe53730c64bb984adacedb2da
2019-10-21 00:40:31 +02:00
Neels Hofmeyr f636e6cedd LOG_TRANS for CC: always log CC state
For all CC type transaction logging, log the current trans->cc.state string for
all LOG_TRANS*() logging.

Change-Id: I67be12c74c679ce684f8c0b9b4e0d96299849dc6
2019-10-21 00:40:31 +02:00
Alexander Couzens a09f4987c1 vlr_auth_fsm: on SAI use the GSUP provided GMM cause code
The HLR might respond with a specific GMM cause code. E.g. roaming not
allowed which needs to be passed down the layers.

Change-Id: I9af515dc52834b7c57c42fc3a76ee2c682734e2a
2019-10-17 08:02:07 +00:00
Alexander Couzens 7312b15830 make vlr_gmm_cause_to_mm_cause public
To be used by vlr_auth_fsm

Change-Id: I9e13e756f359a9b9e6a2056ab37adf0af14afec1
2019-10-17 08:01:42 +00:00
Neels Hofmeyr 1bfe0e1cd1 catch GSUP auth result without auth_fsm
When a vlr_subscr receives an Send Auth Info result, properly check whether the
subscriber has an auth_fsm.

Before, a missing auth_fsm would crash osmo-msc with:

    vlr.c:762 Trying to dispatch event 1 to non-existent FSM instance!

Related: OS#4191
Change-Id: I1995d8f68cfde1140968fb9a97bd054de950de2e
2019-09-26 23:05:51 +00:00
Philipp Maier 002fb01faa paging: Send SGsAP-SERVICE-ABORT-REQUEST on paging timeout
When pagig for a CS-Call via SGs times out, the MME expects to be
informed about this via an SGsAP-SERVICE-ABORT-REQUEST, make sure this
message is sent, but only for CS-Fallback calls.

Change-Id: I3f8f153afe24cf2efa245713509bdc8488902877
Depends: osmo-ttcn3-hacks I99950a17ccf26aaa0eebded5480f33be4c57586a
Related: OS#3614
2019-09-26 19:23:54 +00:00
Philipp Maier 6dcdfb036a sgs_iface: Accept messages with unknown TLV elements
3GPP TS 29.118, chapter 7.5 states that unknown TLV elements should be
ignored rather than that the whole message is discarded a STATUS message
is sent. Lets turn the returncode check of the tlv_parse() call into a
log message and continue normally.

Change-Id: Ic6714451ad970043d4765f8420d753daf5294a44
Related: OS#4214
2019-09-24 11:48:19 +02:00
Neels Hofmeyr e9a3911844 fix error on BSSMAP Cipher Mode Complete L3 msg IE
When an MS returns the IMEISV in the BSSMAP Cipher Mode Complete message in
the Layer 3 Message Contents IE, do not re-invoke the decode_cb() a second
time, but instead point to it from the ran_msg.cipher_mode_complete struct.

When the MSC-A decodes the Ciphering Mode Complete message, it always wants to
also decode the enclosed DTAP from the Layer 3 Message Contents IE. However,
when the MSC-I preliminarily decodes messages, it often just wants to identify
specific messages without fully acting on them, let alone dispatching RAN_UP_L2
events more than once. So leave it up to the supplied decode_cb passed to
ran_dec_l2() implementations to decide whether to decode the DTAP.

In msc_a.c hence evaluate the DTAP by passing a msgb to msc_a_up_l3(), which
will evaluate the RR Ciphering Mode Complete message found in the BSSMAP Cipher
Mode Complete's Layer 3 Message Contents IE.

Particularly, the previous choice of calling the decode_cb a second time for
the enclosed DTAP caused a header/length parsing error: the second decode_cb
call tried to mimick DTAP by overwriting the l3h pointer and truncating the
length of the msgb, but subsequently ran_a_decode_l2() would again derive the
l3h from the l2h, obliterating the intended re-interpretation as DTAP, and
hence the previous truncation caused error messages on each and every Cipher
Mode Complete message, like:

DBSSAP ERROR libmsc/ran_msg_a.c:764 msc_a(IMSI-26242340300XXXX:MSISDN-XXXX:TMSI-0xA73E055A:GERAN-A-77923:LU)[0x5563947521e0]{MSC_A_ST_AUTH_CIPH}: RAN decode: BSSMAP: BSSMAP data truncated, discarding message

This error was seen a lot at CCCamp2019.

Modifying the msgb was a bad idea to begin with, the approach taken in this
patch is much cleaner.

Note that apparently many phones include the IMEISV in the Cipher Mode Complete
message even though the BSSMAP Cipher Mode Command did not include the Cipher
Response Mode IE. So, even though we did not specifically ask for the Cipher
Mode Complete to include any identity, many MS default to including the IMEISV
of their own accord. Reproduce: attach to osmo-msc with ciphering enabled using
a Samsung Galaxy S4mini.

Related: OS#4168
Change-Id: Icd8dad18d6dda24d075dd8da72c3d6db1302090d
2019-09-18 15:31:13 +02:00
Alexander Couzens eb1b03a98a vlr: gmm_cause_to_fsm_and_mm_cause() drop fsm_cause_p argument
It's always set to OSMO_TERM_ERROR. Move the assignment to the caller.
In prepartion to use gmm_cause_to_fsm_and_mm_cause() in vlr_auth_fsm.

Change-Id: Ie4720ad40ef7bcfc528d8d63bfc606c9c0545fb2
2019-09-16 17:57:39 +00:00
Pau Espin b08a380420 vty: fix access to wrong argv in paging response-timer
Fixes: 2ff5bcdc38
Change-Id: I667cf4c8e3e7b6e77ea6ed8ae603727ad22a2ee2
2019-09-16 19:01:40 +02:00
Neels Hofmeyr 01653252b4 msc_a fsm: ignore state chg to same state
We sometimes see errors like

   libmsc/msc_a.c:361 msc_a(...){MSC_A_ST_RELEASING}: transition to state MSC_A_ST_RELEASING not permitted!

i.e. changing state to the state msc_a is already in.

Ignore re-entering the same state for most state changes. However, there is one
state change in msc_a where re-entering the MSC_A_ST_VALIDATE_L3 is necessary
to start the timeout.

Hence add msc_a_state_chg_always() and use that for re-entering
MSC_A_ST_VALIDATE_L3. Change msc_a_state_chg() to skip no-op state changes.

This should silence all no-op state change error messages for msc_a.

Related: OS#4169
Change-Id: I0c74c10b5fa7bbdd6ae3674926cc0393edf15a35
2019-09-03 13:59:05 +00:00
Neels Hofmeyr f092301a0f ran_dec logging: log message sizes on errors
Change-Id: Id08e4ee5a4dbf552dbb107d8f0519110664f6acb
2019-09-03 13:59:05 +00:00
Neels Hofmeyr 4b78b29b8c vlr: don't log about "gratuitous ID RESPONSE"
If an ID Response comes in during a non-LU L3 Complete (Paging or CM Service
Request), no event needs to be dispatched. So far vlr_subscr_rx_id_resp()
logged a NOTICE "gratuitous ID RESPONSE?!?" if no lu_fsm is present.

An ID Response can come in particularly as payload with a BSSMAP Cipher Mode
Complete message, even though osmo-msc didn't explicitly ask for it.

It is not an error to get a Cipher Mode Complete containing an ID Response
during Paging or CM Service Request, so remove the confusing log message.

Related: OS#4168 (only loosely related)
Change-Id: I8a5b8735eb41cd0976c7ab32cdd55440d3ef70ac
2019-09-03 13:59:05 +00:00
Keith Whyte 991bb422d4 Implement a global switch on the network to disable call waiting.
Add a network -> callwaiting VTY command as boolean.

When this is enabled (default) there is no change to
operation previous to this commit.

When this switch is disabled with "no call-waiting" in vty
then when a call arrives, we will check if we have an active
call transaction for this subscriber, no matter if it is
establishing, established, or alerting, in any of these cases we
will return USER BUSY to the calling party.

Change-Id: I3eb6f23f7103e3002874fb5d3a30c9de952202ae
2019-09-03 11:47:13 +00:00
Neels Hofmeyr b4ef5e7bd1 msc_a.c, CC trans: change a comment to a debug log
Change-Id: I5a3cc6219080910119b0c9ff11fc2b9eb96a06e5
2019-09-02 11:07:49 +02:00
Neels Hofmeyr 43e8d4d412 gsm48_tch_rtp_create(): check against NULL mgcp_info
osmo_mgcpc_ep_ci_get_rtp_info() might return a NULL mgcp_info, guard against

Fixes: CID#203651
Change-Id: I98fe5860c49751ade1af10d99487aba259504f23
2019-09-02 11:07:49 +02:00
Neels Hofmeyr 38816dab97 log, cosmetic: add "RR" to "Ciphering Mode Complete"
Distinguish the enclosed DTAP RR Ciphering Mode Complete message from the outer
BSSMAP Cipher Mode Complete message in the DEBUG log.

Change-Id: I80c69b491e2ddb932bc4295a01caaf6a903b1fe4
2019-09-02 11:06:05 +02:00
Neels Hofmeyr 43a349fd63 tweak CC cause for incoming call to unattached nr
So far we sent CC cause "Unassigned Number"

But the MSC doesn't trivially know whether the HLR has the number assigned or
not: any handset that is currently switched off would cause "Unassigned number"
to be displayed on the caller's handset.

Rather send a temporary failure cause code.

Send this cause code for all cases, because claiming that an assigned number is
unassigned is worse than rejecting an unassigned number with a temporary

Change-Id: Ia3d4f67b53fcc2654ff048fbc338e92cb763a095
2019-08-29 05:42:02 +00:00
Neels Hofmeyr 364f927ac4 vlr_lu_fsm: ignore ID_IMEISV during VLR_ULA_S_WAIT_HLR_UPD
Change-Id: I2ea4f46efa013671d93892cb07bf830393289150
2019-08-29 05:42:02 +00:00
Neels Hofmeyr 2e8f881f72 fix segfault: don't send CC REL on NULL msc_a
Apparently, if a conn disappears during an ongoing call, the CC code tried to
send a CC REL on a NULL msc_a during cleanup, which lead to a crash
(cccamp2019). Guard against that.


 #0  msc_a_tx_dtap_to_i (msc_a=0x0, dtap=0x55a4bf2fa0f0) at ../../../../src/osmo-msc/src/libmsc/msc_a.c:1565
 #1  0x000055a4be1bb03c in trans_tx_gsm48 (trans=0x55a4bf2d52a0, trans=0x55a4bf2d52a0, trans=0x55a4bf2d52a0, msg=<optimized out>)
     at ../../../../src/osmo-msc/src/libmsc/gsm_04_08_cc.c:82
 #2  gsm48_cc_tx_release (trans=trans@entry=0x55a4bf2d52a0, arg=arg@entry=0x7ffdd731a0e0) at ../../../../src/osmo-msc/src/libmsc/gsm_04_08_cc.c:1101
 #3  0x000055a4be1bee65 in _gsm48_cc_trans_free (trans=trans@entry=0x55a4bf2d52a0) at ../../../../src/osmo-msc/src/libmsc/gsm_04_08_cc.c:278
 #4  0x000055a4be1ab654 in trans_free (trans=trans@entry=0x55a4bf2d52a0) at ../../../../src/osmo-msc/src/libmsc/transaction.c:170
 #5  0x000055a4be1bd091 in mncc_tx_to_gsm_cc (net=<optimized out>, msg=msg@entry=0x55a4bf2d3b68)
     at ../../../../src/osmo-msc/src/libmsc/gsm_04_08_cc.c:1971
 #6  0x000055a4be1bf1e5 in mncc_tx_to_cc (net=<optimized out>, arg=arg@entry=0x55a4bf2d3b68)
     at ../../../../src/osmo-msc/src/libmsc/gsm_04_08_cc.c:2049
 #7  0x000055a4be18ed63 in mncc_sock_read (bfd=0x55a4bf2563b8, bfd=0x55a4bf2563b8) at ../../../../src/osmo-msc/src/libmsc/mncc_sock.c:121
 #8  mncc_sock_cb (bfd=0x55a4bf2563b8, flags=1) at ../../../../src/osmo-msc/src/libmsc/mncc_sock.c:189
 #9  0x00007fcfad607ce1 in osmo_fd_disp_fds (_eset=0x7ffdd731a9a0, _wset=0x7ffdd731a920, _rset=0x7ffdd731a8a0)
     at ../../../src/libosmocore/src/select.c:223
 #10 osmo_select_main (polling=<optimized out>) at ../../../src/libosmocore/src/select.c:263
 #11 0x000055a4be17dd56 in main (argc=3, argv=<optimized out>) at ../../../../src/osmo-msc/src/osmo-msc/msc_main.c:723

Change-Id: Ia1bb0410ad0618c182a5f6da06af342b6d483eff
2019-08-29 05:42:02 +00:00
Neels Hofmeyr 85031ee0aa cc trans: make sure bearer cap is empty
Change-Id: I147f10f9258fc8685f2f666878dd2a655b8e4583
2019-08-29 04:58:49 +02:00
Neels Hofmeyr 61ae18c956 memleak on cc setup errors
Change-Id: I3333b90064575b270627721ace7e07d085f4ad43
2019-08-29 04:58:49 +02:00
Neels Hofmeyr 5e19b9a0bf mncc: send payload type matching chosen codec
Change-Id: Id32f32d77d24b753adb96b5393c0363439e312c2
2019-08-28 21:22:45 +00:00
Alexander Couzens 4aeb4ec182 smpp_openbsc.c: check acl before deref it
All other calls check acl before deref because in a setup
with no access policy, there won't be any acl structure

Change-Id: Ibe0256535b40351594d79baa05a0147a9f89dc26
2019-08-23 23:48:51 +02:00
Philipp Maier 47cf84d8d7 msc_a: switch RAN type back to SGs when a CSFB-Call is cleared
When a CSFB call is over the MS changes back to LTE after the call is
cleared. However, at the moment the MSC does not change the
cs.attached_via_ran flag. This may cause problems with the next call. Lets
make sure that if there is an SGs association present, the ran type is
set back to SGs when the call is cleared.

Related: SYS#4624
Change-Id: I104adecb0645b81b90ee230c57bf8b463c9e7045
2019-08-19 09:00:24 +00:00
Vadim Yanitskiy ed73ae13a1 libvlr/vlr.c: cosmetic: move message_type assignment
Change-Id: Ice7f98597b54f03069375fac56fb162f2669e7f0
2019-08-18 11:11:44 +00:00
Philipp Maier 25e7ba5b77 sgs_iface: do not use SGsAP-MO-CSFB-INDICATION for CSFB return
When the VLR/MSC receives an SGsAP-MO-CSFB-INDICATION message it sets
the RAN type back to SGs. This is wrong, the message
SGsAP-MO-CSFB-INDICATION has just an informative character. It informs
the VLR that the UE has initiated an MO CSFB call (service request).

Change-Id: I625574fc42fc915ba483db3bb406922ad6df370d
Related: SYS#4624
2019-08-16 08:59:06 +00:00
Neels Hofmeyr 4dfb2babf2 add 'encryption uea 1 2' cfg / fix ttcn3 iu tests
Recently, the ability to run UTRAN without encryption was added, but the config
for it was tied to the A5 GERAN encryption configuration. This affected
osmo-msc's default behavior of Iu, breaking osmo-msc ttcn3 Iu tests: the ttcn3
test suite sets A5 to 0 (no encryption) but still expects Iu to enable air
encryption. Fix this "regression".

Add a separate vty config option for UEA encryption, even if it does not
provide full granularity to select individual UEA algorithms yet.

As a result, Iu default behavior remains to enable encryption regardless of the
A5 config. UTRAN encryption can be disabled by the new cfg option
"encryption uea 0" alone.

Even though the new vty command already allows passing various combinations of
the UEA algorithm numbers, only '0' and '1 2' are accepted as valid
combinations, to reflect current osmo-msc capabilities.

Revert most changes to the msc_vlr test suite in commit "do not force
encryption on UTRAN" (I04ecd7a3b1cc603b2e3feb630e8c7c93fc36ccd7): use new
net->iu_encryption instead of net->a5_encryption_mask.

Adjust/add to test_nodes.vty transcript tests.

Related: OS#4144
Change-Id: Ie138f2fcb105533f7bc06a6d2e6deccf6faccc5b
2019-08-13 23:52:31 +02:00
Philipp Maier cd64af7cd4 cosmetic: make function mncc_tx_to_gsm_cc static
The function mncc_tx_to_gsm_cc() is declared as non static but only used
from within gsm_04_08_cc.c. Lets declare it as static to increase
readability of the code

Change-Id: Icd02c669cfee6dd7e6b154e303cd0f4c148c83c4
2019-08-12 08:41:34 +00:00
Neels Hofmeyr 106ba523c8 vlr_lu_fsm: fix missing event for IMEISV
Event VLR_ULA_E_ID_IMEISV is listed as permitted in VLR_ULA_S_WAIT_LU_COMPL,
but is missing from the switch() on the incoming event. So, sending an IMEISV
identity during the WAIT_LU_COMPL state would crash osmo-msc.

When receiving an IMEISV, vlr_subscr_set_imeisv() in turn calls
vlr_subscr_set_imei(), so as far as the lu_fsm is concerned, receiving an
IMEISV is identical to receiving an IMEI, and it can continue to send a Check
IMEI request to the HLR. Thus simply add VLR_ULA_E_ID_IMEISV to the
VLR_ULA_E_ID_IMEI switch case.

Change-Id: I11106cb108a4b1406ff9a8b8ff5761440a274dad
2019-08-08 02:08:55 +02:00
Neels Hofmeyr a4d7a76816 do not force encryption on UTRAN
Remove the conditions that always enable encryption on UTRAN.

We so far lack an explicit configuration for UTRAN encryption, and this patch
does not add any either. Instead, whether UTRAN encryption is enabled is simply
triggered on whether GERAN has A5 encryption enabled (A5/n with n > 0). Though
GERAN and UTRAN encryption are not technically related at all, this makes UTRAN
behave like GERAN for now, until we implement a proper separate configuration
for UTRAN encryption.

Adjust the msc_vlr_test_* configuration by setting the net->a5_encryption_mask
such that the expected output remains unchanged. A subsequent patch
(I54227f1f08c38c0bf69b9c48924669c4829b04b9) will add more tests, particularly
cases of UTRAN without encryption.

Adjust manual and vty doc.

Related: OS#2783
Change-Id: I04ecd7a3b1cc603b2e3feb630e8c7c93fc36ccd7
2019-08-05 23:24:47 +02:00
Pau Espin 3e1e47679d Remove undefined param passed to logging_vty_add_cmds
Since March 15th 2017, libosmocore API logging_vty_add_cmds() had its
parameter removed (c65c5b4ea075ef6cef11fff9442ae0b15c1d6af7). However,
definition in C file doesn't contain "(void)", which means number of
parameters is undefined and thus compiler doesn't complain. Let's remove
parameters from all callers before enforcing "(void)" on it.

Change-Id: Ia2b24ffd7f9cbb271fcdb979b851f3a07b9d6d3e
Related: OS#4138
2019-08-05 16:07:08 +02:00
Keith Whyte ff17f8fd8a Set coding in mncc_set_cause()
GSM 04.08

The Release indication needs to have the Coding Standard set.

For phones that would display a message on screen, such as
"Number not in use", if the coding standard is not defined,
the display may show "Error in Connection"

Change-Id: Ib28b62a41d433e231cff5910d19455296b284df6
2019-08-02 08:08:33 +00:00
Neels Hofmeyr 4014e481d4 minor comments in msc_vty.c
Change-Id: I83d8c778190adb1e74debc8f8ddac6996de7c513
2019-07-29 18:39:50 +02:00
Oliver Smith c0a5e71d0e vlr_lu_fsm.c: don't send LU reject twice
Don't call tx_lu_rej() in the "vlr_lu_compl" FSM. It is always getting
called in the parent "lu" FSM and is therefore redundant:

_vlr_lu_compl_fsm_done(fi, VLR_FSM_RESULT_FAILURE, cause)
-> osmo_fsm_inst_state_chg(fi, LU_COMPL_VLR_S_DONE, 0, 0)
-> vlr_lu_compl_fsm_dispatch_result()
-> lu_fsm_wait_lu_compl()/lu_fsm_wait_lu_compl_standalone()
-> lu_fsm_failure()
-> lfp->vlr->ops.tx_lu_rej()

I have noticed the bug with the TTCN3 tests. This patch fixes
TC_lu_imsi_auth_tmsi_check_imei_{nack,err} after stricter checking
in [1] and also TC_iu_mo_crcx_ran_reject.

[1] I836f76242463789c4c003feec757714827f2a31b (osmo-ttcn3-hacks)
Change-Id: I127b27937613ea0ff29d67991c0414fca6d441d9
2019-07-24 09:08:22 +02:00
Alexander Couzens efa7b97133 replace osmo_counter with stat_items
osmo_counter will be soon deprecated. Use the newer and more flexible
osmo_stat_item instead.

Depends on: Id2462c4866bd22bc2338c9c8f69b775f88ae7511 (libosmocore)
Change-Id: I6a20123b263f4f808153794ee8a735092deb399e
2019-07-18 14:50:51 +00:00
Thorsten Alteholz 3a357de631 fix spelling detected by lintian
Change-Id: I01e54b5cf111677079a8ad57645d3ceb7834702a
2019-07-16 20:12:03 +00:00
Vadim Yanitskiy 09ce3dcbdf libmsc/msc_vty.c: print subscriber expiration time
Change-Id: I092691a8c443f4c5ed4d33de2e551fef592c1baf
2019-07-09 07:14:09 +00:00
Vadim Yanitskiy d14422a236 Fix: add missing semicolons to OSMO_ASSERT statements
Change-Id: I4fae5fbab5fdbcce35906601d4f1031d971f4931
2019-07-09 07:13:45 +00:00
Vadim Yanitskiy 1c50044efb libmsc/ran_msg_iu.c: fix: properly handle SAPI IE of RANAP_DirectTransfer
The RANAP DirectTransfer message may contain an optional SAPI IE.
Thanks to our TTCN-3 tests (and Wireshark!), it was discovered
that this IE is ignored, so even if the MO SMS related messages
arrive on SAPI 3 (as per GSM TS 04.11, section 2.3) OsmoMSC sends
MT messages on SAPI 0.

In ran_iu_decode_l3() we need to check if the SAPI IE is present,
and tag the NAS PDU message buffer with a proper DLCI value.

This change makes the failing SMS related test cases pass.

Change-Id: I728b55b04e87fc23be6d4f8735e8cad82b6f640e
2019-06-20 16:54:45 +00:00
Vadim Yanitskiy 7659482318 libmsc/gsm_04_11.c: do not abuse LOG_TRANS() in gsm411_alloc_mt_trans()
This change is similar to I6b68a0f0b32eb126e0f7e914a314130254d28467.
If we 100% sure that trans == NULL, it makes more sense to use
generic LOGP(DLSMS, LOGL_*, ...) call, so the logs can reflect
more information than such dummy prefix:

  trans(NULL NULL callref-0x0 tid-0) ...

Change-Id: I3c1e633aee5dd7cd0d367404a3def9cffe0b3baa
2019-06-20 16:54:45 +00:00
Vadim Yanitskiy 59e0c6b46a gsm_04_11_gsup.c: fix broken reference counting for vsub
This change is similar to I5540556b1c75f6873883e46b78656f31fc1ef186.
In gsm411_gsup_rx() we do call vlr_subscr_find_by_imsi(), which
increases subscriber's reference count by one using the function
name as the token. However, we never release this token, so the
reference count grows on every received GSUP FORWARD-SM message.

Change-Id: Ic729beb5f94cbbfbb251bc9ab66a5e7b799286c0
2019-06-20 16:54:45 +00:00
Pau Espin fe5b7046ea sms_queue.c: Improve misleading log line
Otherwise when read in a log file it seems it's really going to send 20
sms even if there's none to send.

Change-Id: Ieb9bb61a90f295d2ba5fb67a2abee2d30785876d
2019-06-20 10:45:37 +02:00
Vadim Yanitskiy 718f32fa88 libvlr/vlr.c: do not expire subscribers if periodic LU is disabled
When periodic Location Update is disabled (T3212 = 0), it was noticed
that OsmoMSC does expire subscribers quite soon - after 60 seconds

In order to avoid that, we need to check T3212 timer value in
vlr_subscr_expire_lu(), and if it's equal to 0, do not expire
anybody until the explicit IMSI Detach.

Change-Id: I2ead2241a3394dbdd5417f4554190df3fd698af2
2019-06-19 14:36:28 +07:00
Vadim Yanitskiy b3bdc768be libmsc/gsm_09_11.c: do not suppress rc of gsup_client_mux_tx()
Change-Id: Ide2440188fb6fe1c54681fef8ec4fed9e6da66e2
2019-06-17 22:23:09 +07:00
Vadim Yanitskiy 6632251572 libmsc/gsm_09_11.c: do not abuse LOG_TRANS() in gsm0911_rcv_nc_ss()
If we 100% sure that trans == NULL, it makes more sense to use
generic LOGP(DSS, LOGL_*, ...) call, so the logs can reflect
more information than such dummy prefix:

  trans(NULL NULL callref-0x0 tid-0) ...

Change-Id: I6b68a0f0b32eb126e0f7e914a314130254d28467
2019-06-17 22:13:03 +07:00
Vadim Yanitskiy e0da446e76 libmsc/gsm_09_11.c: fix broken reference counting for vsub
In gsm0911_gsup_rx() we do call vlr_subscr_find_by_imsi(), which
increases subscriber's reference count by one using the function
name as the token. However, we never release this token, so the
reference count grows on every received GSUP PROC-SS message.

Change-Id: I5540556b1c75f6873883e46b78656f31fc1ef186
2019-06-17 21:57:30 +07:00
Vadim Yanitskiy 944d6a2acb libmsc/gsm_09_11.c: avoid double zero-initialization of gsup_msg
Change-Id: Ib991b01534499401e7a0c3de49ceba770fdd9b48
2019-06-17 21:57:30 +07:00
Vadim Yanitskiy f177590488 libmsc/gsm_09_11.c: properly handle OSMO_GSUP_MSGT_PROC_SS_ERROR
This message can be used by the HLR/EUSE to indicate that something
went wrong, e.g. the connection with EUSE is lost, EUSE or the MS
did not respond in time, etc. OsmoMSC needs to release the SS/USSD
transaction, and send GSM 04.80 RELEASE COMPLETE message to the MS
if there is an active RAN connection.

Change-Id: I076d12ef24d7320eda1df1ee4588da7375ef3d9e
Related: (TTCN-3) I5586a88136c936441a842f49248824680603672e
Related: OS#2931
2019-06-17 21:08:14 +07:00