In order for osmo-hlr to be able to 100% guarantee distinct INDs for CS and PS,
set CN-Domain = CS in all SendAuthInfo Requests.
In Milenage auth, it is highly desirable that osmo-hlr guarantees use of
distinct INDs for CS and PS domains. If an MSC and SGSN attached at the same
time use the same IND bucket to generate Milenage SQN, that collision would
rapidly waste SQNs and load osmo-hlr with requesting new auth tuples on each
CS/PS Complete-Layer3.
So far, osmo-msc did not indicate the CN domain in the GSUP SendAuthInfo
Request, which was neither required nor evaluated. The CN-Domain is only sent
for the UpdateLocation Request that usually follows later.
Related: OS#4318
Change-Id: I22f44068268e62801cadbf6542efaf153423cd65
Add a char buffer of 1024 characters length as space for SDP to pass to /
receive from MNCC.
Actually support receiving MNCC without such an SDP tail. The main reason for
this is to avoid the need to adjust the ttcn3 implementation of MNCC: it would
stop working for older osmo-msc.
Older or non-SIP MNCC peers could operate the previous MNCC protocol unchanged
(save the protocol number bump) without having to implement SDP.
The SDP part in the MNCC protocol will be used in upcoming patch
I8c3b2de53ffae4ec3a66b9dabf308c290a2c999f.
This patch must be merged at the same time as osmo-sip-connector patch
Iaca9ed6611fc5ca8ca749bbbefc31f54bea5e925, so that both sides have a matching
MNCC protocol version number.
Change-Id: Ie16f0804c4d99760cd4a0c544d0889b6313eebb7
Rationale: in order to add full SDP to the MNCC protocol (upcoming patch
I8c3b2de53ffae4ec3a66b9dabf308c290a2c999f), we need to parse and compose SDP
messages. Obviously, libosmo-mgcp-client already contains similar code, but
that is unfortunately heavily glued to the actual MGCP implementation. The
simplest solution is to create this separate implementation, copy-pasting from
the existing libosmo-mgcp-client code as is convenient.
This API is added here to probe whether it works well. When it does, the
intention is to "move it up" to osmo-mgw and overhaul the SDP parsing in our
MGCP client and MGCP server APIs using this same API.
Change-Id: If3ce23cd5bab15e2ab4c52ef3e4c75979dffe931
Do not free the CC transaction when an MT subscriber is already being Paged.
Instead, invoke another paging request, which paging.c will correctly add to
the list of pending paging response callbacks to run.
A ttcn3 test is linked in the related patch (s.b.).
Related: OS#4240
Related: Ieeae6322d4e80893ea3408c6b74bf8e32bea8e46
Change-Id: Idd4537b5f4817d17e5c87d9a93775a32aee0e7be
When the CRCX OK returns an invalid RTP address, abort the call; fixes
MSC_Tests.TC_invalid_mgcp_crash.
The original crash happened when adding this error handling without this commit
I08c03946605aa12e0a5ce8b3c773704ef5327a7a ("fsm: use deferred deallocation" for
osmo-mgw I7df2e9202b04e7ca7366bb0a8ec53cf3bb14faf3 "fix use-after-free: require
new fsm deferred dealloc, check for term"). With this error handling added,
even though avoiding a crash, the test does not pass yet, because instead of
rejecting the call, it currently composes an Assignment Command without a
Transport Layer Address. Fix that.
Change-Id: I00c3b5ff74c05bcc2b7c39375c33419916a57193
Actually decode the Codec List (BSS Supported) in BSSMAP, in both the Complete
Layer 3 Information and the Assignment Complete messages.
An upcoming patch improves codec negotiation and requires the BSS supported
codecs, which are so far ignored (which is/was a pity as osmo-bsc goes at great
lengths to compose those IEs).
Change-Id: I66c735c79e982388f06b5de783aa584c9d13569e
Use of this flag was dropped when adding inter-BSC and inter-MSC Handover
support, I forgot to remove it.
Change-Id: I5ec78e30eb36fbe78a3f7c46bfa44af5a4eb7bf2
Fix three 'FIXME: ERROR HANDLING' occurences in the code that reacts upon the
MGW providing (or failing to provide) an RTP port for the RAN side. From an
earlier stage of the code, the cleanup for this situation was extremely
complex, and hence the choice was to simply wait for the call to time out and
fail. But since we have implemented safe deallocation of nested FSMs in
libosmocore, the situation has become rather trivial: simply free the CC
transactions, and all the rest will immediately release, and terminate
correctly without crashing.
A ttcn3 test for this is MSC_Tests:TC_invalid_mgcp_crash, which actually also
needs the change to osmo_sockaddr_str_is_nonzero() in preceding patch
I53ddb19a70fda3deb906464e1b89c12d9b4c7cbd, so that a seemingly valid MGCP
message ends up causing a failure in the on_success() branch of
mgcp_client_endpoint_fsm.c.
Change-Id: I8313bed1d782100bebeac7d8fc040557c4cb653e
Also regard an RTP port as invalid if the IP address is 0.0.0.0.
Achieve this by using osmo_sockaddr_str_is_nonzero() instead of
osmo_sockaddr_str_is_set().
Depends: I73cbcab90cffcdc9a5f8d5281c57c1f87b2c3550 (libosmocore)
Change-Id: I53ddb19a70fda3deb906464e1b89c12d9b4c7cbd
libosmo-mgcp-client recently introduced osmo_mgcpc_ep_cancel_notify() to cancel
notification if a notify target FSM deallocates. Use it for sanity in
rtp_stream FSM cleanup, the notify target for endpoint FSMs.
Depends: I41687d7f3a808587ab7f7520f46dcc3c29cff92d (osmo-mgw)
I14f7a46031327fb2b2047b998eae6ad0bb7324ad (osmo-mgw)
Change-Id: I351bb8e8fbc46eb629bcd599f6453e2c84c15015
Since osmo-bsc uses the MGCP client FSMs, it is required to enable this new
feature to guarantee safe operation. The issue is described in detail in commit
logs linked below.
Notably, osmo-msc currently chooses to omit error handling during MGCP events
(marked "FIXME"). An upcoming patch implements this error handling, and would
make osmo-msc vulnerable to crash from unexpected MGCP messages without this.
Deferred FSM deallocation is a more general, simpler approach to
osmo_fsm_term_safely(), so we can switch that off now.
Depends: Ief4dba9ea587c9b4aea69993e965fbb20fb80e78 (libosmocore),
I0adc13a1a998e953b6c850efa2761350dd07e03a (libosmocore)
Related: I7df2e9202b04e7ca7366bb0a8ec53cf3bb14faf3 (osmo-mgw)
Change-Id: I08c03946605aa12e0a5ce8b3c773704ef5327a7a
Before:
RAN decode: BSSMAP: Rx BSSMAP DT1 COMPLETE LAYER 3
After:
RAN decode: BSSMAP: COMPLETE LAYER 3
This caught my attention while I was writing up a script to parse osmo-msc
logging to produce ladder diagrams.
Change-Id: I387dde8f2eb3edb35d22ce52dc0ed580978dea36
If an incoming MNCC_SETUP_REQ ends up in Paging (as usually it does), the early
return so far skipped logging of that MNCC message. Add this logging.
Change-Id: I1495dd562a06cf6c1e9453a1fe111bdf8f4be081
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
For all CC type transaction logging, log the current trans->cc.state string for
all LOG_TRANS*() logging.
Change-Id: I67be12c74c679ce684f8c0b9b4e0d96299849dc6
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
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
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
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
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
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
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
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
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
Distinguish the enclosed DTAP RR Ciphering Mode Complete message from the outer
BSSMAP Cipher Mode Complete message in the DEBUG log.
Change-Id: I80c69b491e2ddb932bc4295a01caaf6a903b1fe4
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
failure.
Change-Id: Ia3d4f67b53fcc2654ff048fbc338e92cb763a095
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.
Crash:
#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
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
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
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
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
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
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
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
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
GSM 04.08 10.5.4.11
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
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
osmo_counter will be soon deprecated. Use the newer and more flexible
osmo_stat_item instead.
Depends on: Id2462c4866bd22bc2338c9c8f69b775f88ae7511 (libosmocore)
Change-Id: I6a20123b263f4f808153794ee8a735092deb399e
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
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
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
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
When periodic Location Update is disabled (T3212 = 0), it was noticed
that OsmoMSC does expire subscribers quite soon - after 60 seconds
(VLR_SUBSCRIBER_LU_EXPIRATION_INTERVAL) since the last LU.
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
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
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
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
This check was copy-pasted from the CC handling code during the
initial development of "SS/USSD over GSUP" feature. It probably
makes sense for MT calls, but definitely not for SS/USSD.
Change-Id: I2899a23ee49fd7917443943629603700a5025cf4
This check was copy-pasted either from CC, or from SMS handling
code during the initial development of "SS/USSD over GSUP". Now
this is the only one survived after the recent refactoring.
I doubt this is exactly the right way to check whether subscriber
is attached or not. Moreover, this check should rather be done in
a single place, rather then in each CC/SS/SMS handler separately.
Change-Id: I7bd48860e923cb1f1a5bccc4b0f497ec1a7bcf84
In case of network-originated SS/USSD session establishment, we
need to verify the received GSUP PROC_SS_REQ message and make
sure that all mandatory IEs are present.
There is no sensible need to allocate a new transaction before
doing all the checks, other than the ability to use LOG_TRANS().
This complicates the code, so let's avoid the early allocation.
Change-Id: I4e027b19e8065a39324a1647957cef4066b82ce7
reported by _dev_zero in #osmocom
Change-Id: Ib5679ab5d06b6ef735725b4a68eeb1e9cbcc11ba
Depends-On: libosmocore I52b9f6b5f3e96d85a390ba2af21d7814df8aaeec
During the recent refactoring, some code parts has been moved out
of 'gsm_04_08.c', but the related header files were forgotten.
Change-Id: I61e728069a1e79bf72c01ef9d9fc5fb171d3892e
It is expected that establish_nc_ss_trans() returns an allocated
transaction in successful case, or NULL in case of error. The
function assumes two scenarios:
- the subscriber already has an active RAN connection,
- RAN connection needs to be established (Paging).
In the first case, a pointer to the transaction is returned as
expected, but in case of Paging, NULL has always been returned,
even if there were no errors. Let's fix this.
Change-Id: I9dcee64dd0b435ef29630c223132b81724701f93
The SM-RP-MR (Message Reference for SM Service) value in the response
(no matter result or error) shall match the value from the request.
Change-Id: Ifb6e749928548e6febfe7768aefe9a2a3ecf4de0
Found using the new TC_mt_ussd_for_unknown_subscr test case.
Change-Id: Id00a99b713a6b97c455b8e6ae49abea163e8281f
Related: (TTCN-3) Id35cd3ec15d1bab15260312d7bbb41e2d10349fe
Related: OS#2931
For SS/USSD, it's important to have both session state and ID IEs.
Found using the new TC_mt_ussd_for_unknown_subscr test case.
Change-Id: I57317a7b8036d1ffd36e2021efc146db4633da84
Related: (TTCN-3) Id35cd3ec15d1bab15260312d7bbb41e2d10349fe
Related: OS#2931
I am not a big fan of using such syntax sugar for initializing
structures, and this is one of the reasons: it's much easier
to shoot yourself in the foot.
IMSI was copied to the new GSUP message, but then overridden.
Found using the new TC_mt_ussd_for_unknown_subscr test case.
Change-Id: If81c3fa56951185339f33a523ab6364594101be1
Related: (TTCN-3) Id35cd3ec15d1bab15260312d7bbb41e2d10349fe
Related: OS#2931
The initial idea of the SMS expiry threshold was to avoid storing
SMS messages with too long validity time (e.g. 63 weeks).
Unfortunately, neither this feature was properly documented, nor
the expiry threshold is configurable. Moreover, it has been
implemented in a wrong way, so instead of deleting the oldest
expired message, it would delete the youngest one or nothing:
SELECT ... FROM SMS ORDER BY created LIMIT 1;
while it should be sorted by 'valid_until' in ascending order:
SELECT .. FROM SMS ORDER BY valid_until LIMIT 1;
Thus, if the oldest message is expired, it gets deleted. If the
oldest message is not expired yet, there is nothing to delete.
Change-Id: I0ce6b1ab50986dc69a2be4ea62b6a24c7f3f8f0a
In general, neither TP-User-Data nor decoded text should be
truncated. If the SMSC's database for some reason does contain
such weird messages, let's at least let the user know about it.
Change-Id: I75e852ebe44ba4784572cbffa029e13f0d3c430c
The following functions:
- sms_from_result(),
- sms_from_result_v3(),
- sms_from_result_v4(),
do retrieve the TP-UD, TP-UDL and text in the same way.
A consequence of such duplication is [1], which fixed potential
NULL-pointer dereference for sms_from_result(), but not for two
other functions: sms_from_result_v3() and sms_from_result_v4().
[1] I545967464c406348b8505d1729213cfb4afcd3e2
Change-Id: If67dfb9f7d2a55fa3d45dc4689a2acff9909faf6
The value of 'sms->user_data_len' is fetched from the database:
sms->user_data_len = dbi_result_get_field_length(result, "user_data");
and this is where the problem is. As per the libdbi's documentation
(see 3.5.3), dbi_result_get_field_length() returns the length in
bytes of the value stored in the specified field:
unsigned int dbi_result_get_field_length(dbi_result Result,
const char *fieldname)
so 'unsigned int' is assigned to 'uint8_t', what could lead to an
integer overflow if the value is grather than 0xff. As a result,
if the database for some reason does contain such odd TP-UD,
the truncation of 'user_data' would be done incorrectly.
Let's avoid such direct assignment, and use a separate variable.
Also, let's warn user if TP-UDL value is grether than 140, as
per 3GPP TS 03.40.
Change-Id: Ibbd588545e1a4817504c806a3d02cf59d5938ee2
Related: OS#3684
Catched by ASan on db_sms_test unit test:
DDB NOTICE test_db_sms_get('Empty TP-UD'): osmo-msc/src/libmsc/db.c:796:2: runtime error: null pointer passed as argument 2, which is declared to never be null
That happens on empty PDU because dbi_result_get_binary returns NULL,
and sms->user_data_len is 0, so it's harmless but we can avoid calling
mempcy and make ASan happy.
Change-Id: I545967464c406348b8505d1729213cfb4afcd3e2
Thanks to db_sms_test, it was discovered that storing an SMS with
empty TP-User-Data (TP-UDL=1) causes buffer overruns in libdbi
and it's SQLite3 driver (libdbdsqlite3):
DDB NOTICE test_db_sms_store('Empty TP-UD'): ==7791== Invalid write of size 2
==7791== at 0x857DC60: dbd_quote_binary (in /usr/lib/x86_64-linux-gnu/dbd/libdbdsqlite3.so)
==7791== by 0x5B2B321: dbi_conn_quote_binary_copy (in /usr/lib/x86_64-linux-gnu/libdbi.so.1.1.0)
==7791== by 0x4073B1: db_sms_store (db.c:701)
==7791== by 0x405BB5: test_db_sms_store (db_sms_test.c:310)
==7791== by 0x405BB5: main (db_sms_test.c:546)
==7791== Address 0x7ed1cf0 is 0 bytes after a block of size 0 alloc'd
==7791== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7791== by 0x857DC4B: dbd_quote_binary (in /usr/lib/x86_64-linux-gnu/dbd/libdbdsqlite3.so)
==7791== by 0x5B2B321: dbi_conn_quote_binary_copy (in /usr/lib/x86_64-linux-gnu/libdbi.so.1.1.0)
==7791== by 0x4073B1: db_sms_store (db.c:701)
==7791== by 0x405BB5: test_db_sms_store (db_sms_test.c:310)
==7791== by 0x405BB5: main (db_sms_test.c:546)
...
DDB NOTICE test_db_sms_get('Empty TP-UD'): ==8051== Invalid read of size 1
==8051== at 0x5B30510: _dbd_decode_binary (in /usr/lib/x86_64-linux-gnu/libdbi.so.1.1.0)
==8051== by 0x857D957: dbd_fetch_row (in /usr/lib/x86_64-linux-gnu/dbd/libdbdsqlite3.so)
==8051== by 0x5B2C86E: dbi_result_seek_row (in /usr/lib/x86_64-linux-gnu/libdbi.so.1.1.0)
==8051== by 0x40828F: next_row (db.c:188)
==8051== by 0x40828F: db_sms_get (db.c:805)
==8051== by 0x406C29: test_db_sms_get (db_sms_test.c:390)
==8051== by 0x405C14: main (db_sms_test.c:547)
==8051== Address 0x8f74641 is 0 bytes after a block of size 1 alloc'd
==8051== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8051== by 0x5DBEB49: strdup (strdup.c:42)
==8051== by 0x857D93C: dbd_fetch_row (in /usr/lib/x86_64-linux-gnu/dbd/libdbdsqlite3.so)
==8051== by 0x5B2C86E: dbi_result_seek_row (in /usr/lib/x86_64-linux-gnu/libdbi.so.1.1.0)
==8051== by 0x40828F: next_row (db.c:188)
==8051== by 0x40828F: db_sms_get (db.c:805)
==8051== by 0x406C29: test_db_sms_get (db_sms_test.c:390)
==8051== by 0x405C14: main (db_sms_test.c:547)
==8051==
success, as expected
DDB NOTICE verify_sms('Empty TP-UD'): user_data_len mismatch: E0 vs A3
Apparently, dbi_conn_quote_binary_copy() doesn't properly handle
zero-length input. Let's guard against this.
Observed with:
- libdbi-dev 0.9.0-1
- libdbd-sqlite3:amd64 0.9.0-2ubuntu2
Change-Id: If0b2bb557118c5f0e520a2e6c2816336f6028661
Since OsmoMSC has built-in SMSC, it needs to store the messages
somewhere. Currently we use libdbi and SQLite3 back-end for that.
For a long time, the db_sms_* API remained uncovered by unit tests.
This change aims to fix that, and does cover the following calls:
- db_sms_store(),
- db_sms_get(),
- db_sms_get_next_unsent(),
- db_sms_mark_delivered(),
- db_sms_delete_sent_message_by_id(),
- db_sms_delete_by_msisdn(),
- db_sms_delete_oldest_expired_message().
Due to performance reasons, the test database is initialized in
RAM using the magic filename ':memory:'. This is a feature of
SQLite3 (and not libdbi), see:
https://www.sqlite.org/inmemorydb.html
Of course, this unit test helped to discover some problems:
1) Storing an SMS with empty TP-User-Data (TP-UDL=0) causes
buffer overruns in both db_sms_store() and db_sms_get().
2) TP-User-Data-Length is always being interpreted in octets,
regardless of DCS (Data Coding Scheme). This results in
storing garbage in the database if the default 7-bit
encoding is used. Fortunately, the 'user_data' buffer
in structure 'gsm_sms' is large emough, so we don't
experience buffer overruns.
3) db_sms_delete_oldest_expired_message() doesn't work
as expected. Instead of removing the *oldest* expired
message, it tries to remove the *newest* one.
The current test expectations do reflect these problems.
All of them will be fixed in the follow-up patches.
Change-Id: Id94ad35b6f78f839137db2e17010fbf9b40111a3
Neels Hofmeyr
Harald Welte
Martin Hauke
Philipp Maier
Pau Espin
Keith Whyte
Oliver Smith
Eric Wild