Do not attempt to change permissions/ownership if the package gets
upgraded from a version higher than the next release.
Do not fail if the user deleted the config file.
Be verbose when changing permissions.
Related: OS#4107
Change-Id: I2b01a7625cf66fbb7d203f939ddcc1cbab43cf33
* Explicitly chown /var/lib/osmocom to osmocom:osmocom, instead of
relying on systemd to do it when the service starts up. This does not
work with the systemd versions in debian 10 and almalinux 8.
* deb: Use "useradd" instead of the interactive "adduser" perl script
from Debian. This makes it consistent with how we do it in rpm, and
avoids the dependency on "adduser".
* deb: Consistently use tabs through the file, instead of mixing tabs
and spaces.
* deb: Remove support for the "dpkg-statoverride --list" logic. This
seems to be a rather obscure feature to override permissions for
certain files or directories, for which it does not seem to be a good
idea to make the postinst script less maintainable. Something similar
can be achieved by using your own Osmocom config file in a different
path with different permissions.
Related: OS#4107
Change-Id: I406ff0d625b02991d580c8382aa4be04dba45a00
Created osmocom user & group during package installation.
Fix the configuration dir/files permission to match.
Related: OS#4107
Tweaked-By: Oliver Smith <osmith@sysmocom.de>
Change-Id: I41d47c0884d09d4674ec806d77e43bc8f08d9b64
Fix a bug introduced in commit
implement CM Re-Establish for voice calls
ae98b97382
Neels Hofmeyr <neels@hofmeyr.de>
Thu Jul 29 22:40:59 2021 +0200
I6fa37d6ca9fcb1637742b40e37b68d67664c9b60
We should only succeed when conn_accepted == true!
Related: SYS#5130
Change-Id: I3679162143e8d7d8c0878de2102faa11eadfccfc
With 'no assign-tmsi', regard any TMSI as invalidated at the end of a
Location Updating procedure. Hence, avoid paging by TMSI.
When 'no assign-tmsi' is set, osmo-msc does not actively assign a new
TMSI at the end of the Location Updating. However, it stores any TMSI
identity that the MS sends in a Location Updating Request. So far, this
caused osmo-msc to use the TMSI that the MS had sent in subsequent
Paging, which goes unanswered by the MS.
(After the long standing evil twin problem regarding TMSI MI has been
fixed in recent Ifdabe0b65bffafbf7b8e5cc10e2d225d1ed1cecd, there is no
longer an evil twin risked by clearing out a TMSI.)
Related: SYS#6860 OS#4721
Change-Id: I583682d1a35a70b008d7bb2d89ba7c3109a60b21
When a subscriber first attaches by TMSI only, and later tells the IMSI
via ID Response, it may turn out that this IMSI already exists in the
VLR database. If this happens, the TMSI that the subscriber issued was
not known in the existing VLR entry, indicating that the subscriber has
in the meantime camped on a different core. Which means we can assume
that there cannot be any active connections, and the old subscriber can
be discarded, for the benefit of the new one.
(We could also discard the new one, but it is more complex to reparent
the ongoing FSMs for Compl L3 than to copy some dormant VLR state.)
In vlr_subscr_set_imsi(), check for an existing IMSI entry in the VLR.
If such exists, copy any pending Paging and auth tuple state to the new
subscriber, and discard the old one from the VLR.
In order to safely discard a vlr subscriber by force, add a new vlr_ops
function: subscr_inval(), to tell the MSC that a vlr_subscr is no longer
valid.
Upcoming patch I583682d1a35a70b008d7bb2d89ba7c3109a60b21 better clears
TMSI state from the VLR, making it more likely to hit the evil twin
situation this patch fixes; hence this is, sort of, preparation.
Related: SYS#6860 OS#4721
Change-Id: Ifdabe0b65bffafbf7b8e5cc10e2d225d1ed1cecd
We have an msc_conn_ref pointer from vlr_subscr to an active msc_a
instance. So far, we just keep it pointing at discarded memory. Instead,
make sure it goes back to NULL when the msc_a instance deallocates.
This way the VLR can reliably tell whether a given VLR entry still has
an active connection or is just inactively caching the subscriber.
Related: SYS#6860 OS#4721
Change-Id: Ic63d01d220b63453976fe06a7c6b606f97172c99
* 'sizeof(sms->user_data)' evaluates to 256
* 'ud_len' is of type 'uint8_t' and cannot be greater than 256
Change-Id: Ia71a0b6b9421911dc5113782d2f555a640fd90ed
This commit simply fixes a -Wenum-conversion thrown by clang.
No idea why are we using the SM (GPRS Session Management) cause values.
msc_a_release_mo() does not even use the given SM cause value.
Change-Id: Iade6bf97466ab2b3b39e9ea123fc90d06c0f6a9b
This was found thanks to clang (-Wenum-conversion):
warning: implicit conversion from enumeration type
'enum gsm48_gmm_cause' to different enumeration type
'enum gsm48_reject_value' [-Wenum-conversion]
Change-Id: I0b820bb2a8e561682a8158fc51bd9565f5912d56
I'm not sure why so many files (particularly written by Neels)
did contain a GPLv2+ header, instead of the AGPLv3+ which is the
actual overall project license. I consider it a mistake.
In any case, any copyrightable contribution to those files was done by
sysmocom employees, so I as managing directory can legally make a
license change, whther or not it was a mistake early on or not.
The only GPLv2-or-later file remaining is mncc_internal.c, as it has
more contributors and a longer history.
Change-Id: I8650697592b3160c4d0a7c61ae9c46d4aacb3bef
(Same as osmo-bsc I47c9011b5e0e2886d221e34e6aa281d1dd0495c7)
*.vty tests are picked up by the Makefile.am by means of a wildcard --
they are run when they are there. So when you forget to add it to
EXTRA_DIST, it will be run in your local build tree, but it will be
silently omitted from a distribution tar, and nothing will complain
about it gone missing.
Instead, also use a *.vty wildcard in EXTRA_DIST. So any *.vty test
added to the git source will both be run *and* included in distribution
tars implicitly.
So far, test_neighbor_ident.vty was missing from the distribution.
Change-Id: Id28e020fc59b83d1b4cd0e5b72314a46bea62259
Better match the pattern of sdp_audio_codecs_* instead of having
foreach_ in the front. Prepare for prepending osmo_ some day, because I
plan to move the SDP API to a separate library.
Change-Id: Ia96190e0bdb513886663be1c8c12be3b403b71c9
When we get the codec filter result logged, it is most interesting to
know the caller. So wrap a file-line macro around trans_cc_filter_run().
Change-Id: I243404487c1871e921b08098086ef2fc78a5561d
The comments indicating which two "members" are identical are
inaccurate. (One of them is a macro pointing at the other.)
Change-Id: Ifaa2f361db77cd0ed3ad39d6ca197195b9354ea1
Currently the CSD check is in the middle of figuring out the voice codec
for normal voice calls. Rather do the CSD check first, and then do voice
in one coherent section.
(prep for upcoming change in this code, to support AMR rate selection.)
Change-Id: Ibd21f0bb46c66a406904105564ce961a8760cbe7
Before the codec filter, it would have been the CN side codec, but now
it is only the codec that the RAN reports as assigned, fed into the
codecs filter.
(prep for upcoming change in this code, to support AMR rate selection.)
Change-Id: Ie7966099c5565013018734b0c2028484c24341a7
This also makes sure it doesn't compile against older libosmogsm gsup
versions which would break ABI.
Related: OS#6091
Depends: libosmocore.git Change-Id 70be3560659c58f24b8db529c4fc85da4bb0ec04
Change-Id: Ia002fd6e0334d56de34d352a0bf1a8604e2e9fd3
low/high layer compatibility are used for capability checking between
caller and called entitiy. The transcoding is performed by libosmogsm.
Related: OS#6152
Depends: libosmocore.git Ia6a2159ecf810a02f85b558026edf20b934567de
Change-Id: I760980a7e17e2fa81615adc69ef85797eb0c07f1
low/high layer compatibility are used for capability checking between
caller and called entitiy.
The information is added to the end of struct gsm_mncc increases, so
that the version number needs not to be incremented.
Related: OS#6152
Change-Id: I15f5afcf069ee6c1c4641108ceacc837bee311b5
We do include this IE in result and error messages, but somehow
not in the request messages. For the sake of consistency, let's
ensure that the Source Name IE is present in all SMS related PDUs.
This additionally brings osmo-msc in sync with ttcn3-msc-test, which
was modified to expect the Source Name IE in all receive templates,
and makes the following testcases pass [again]:
* MSC_Tests.TC_gsup_mo_sms
* MSC_Tests.TC_gsup_mo_smma
* MSC_Tests.TC_gsup_mo_mt_sms_rp_mr
Change-Id: I65f5e3b7a0688e258979bb2679598659881a4321
Related: osmo-ttcn3-hacks.git Ic24d3082fe3dce08e43e8f3ecb6d6132503c55c6
Related: OS#6135
... so that it's clear which MNCC handler is used by looking
at the output of `show running-config`.
Change-Id: Id1fe7aecc1c8445db48ff5fddcf6df0f05ba5e2e
Prior to this change, if there was no explicit ipa-name configuration
in OsmoMSC, OsmoHLR would see the GSUP connection as MSC-00-00-00-00-00-00.
However, this default is constructed somewhere deep in IPA libraries
and is not visible to the GSUP client application, in this case OsmoMSC.
This situation creates a problem for SMS-over-GSUP routing: when we get
MT-forwardSM.req from an SMSC, we have to send a GSUP response, and this
response needs to get back to the MT-sending SMSC. Because OsmoHLR
applies only passive routing for these responses, we have to set
source_name when generating MT-forwardSM.res in OsmoMSC - but we cannot
do so if don't know our own IPA name.
Change the default OsmoMSC ipa-name from MSC-00-00-00-00-00-00 to
unnamed-MSC, mirroring OsmoHLR default of unnamed-HLR, and set it
at our application level rather than deep in the libraries.
Related: OS#6135
Change-Id: I7bacd001b81326c32bc262c7d0c0491ded822fa8
Previously added codecs tests uses non-default PT number sent by MT and
adopted by MO. Also test the other direction, i.e. a non-standard PT
from MO is adopted by MT.
Related: OS#6258
Change-Id: I8fbabe242982441d676d09f4d0ed7557c8349f2c
In msc_vlr_test_call.c, allow to tell MO non-default payload type
numbers in the SDP, to verify that it adopts the other call leg's PT
numbers.
Actually apply the non-default payload type number (AMR=96 instead of
the default of 112 from codec_mapping.c) and see the effects in
msc_vlr_test_call.err.
The diff shows that, as intended, the change in payload type number
should result in modifying the MGW endpoint to change the earlier '112'
to the modified '96' used in this test.
Related: OS#6258
Change-Id: I25df2ed7ad792fbe66dfd0fbf08182c9cf6cfc5b
In msc_vlr_test_call.c, allow to tell MO non-default payload type
numbers in the SDP, to verify that it adopts the other call leg's PT
numbers.
This test differs only slightly from the first codecs test, so in this
patch add the test as a 1:1 copy of the first test. The next patch [2/2]
will then show only the difference the new test makes.
Related: OS#6258
Change-Id: I618e3cf1b412985589a0c63bd76b7a60202f17b9
In patch I8760feaa8598047369ef8c3ab2673013bac8ac8a, osmo-msc learns to
handle codec mismatches reported by MT. For simplicity, that patch cuts
short the msc_vlr codecs tests by validating only the first codec.
Now test the full list of codecs properly.
This also introduces testing the re-assignment that MO does to match
MT's codec limitations, and removes the "EXPECTED FAILURE" markers.
Related: OS#6258
Change-Id: Ib933554f826c1b4347dfa3f6c4f6fe086be8b133
It was true once, but not since "do CN CRCX first"
Ie433db1ba0c46d4b97538a969233c155cefac21c
Related: OS#6258
Change-Id: I94e430e4e5b5bf18dbb155258d82f599ada453e6
This is the last missing piece that allows osmo-msc to make good TFO
codecs choices.
Since the codec_filter, osmo-msc properly gathers codec options and
limitations. But the MO call leg still assigns a voice channel before
getting a response from the MT call leg, and is then stuck with that.
Add the capability to adjust the MO call leg's codec in case the MT side
needs a different codec for TFO.
This is only relevant for 2G; on 3G we always have AMR/IuUP.
For inter-MSC handover, keep the behavior unchanged: offer only the
currently assigned codec to the remote side. Codec-changing HO should be
equally trivial to implement, but that is for another day.
msc_vlr_test_call's codec tests are adjusted to test the new feature in
Ib933554f826c1b4347dfa3f6c4f6fe086be8b133. For now, avoid change in
these tests by validating the first codec in SDP lists only.
Related: OS#6258
Related: osmo-ttcn3-hacks I402ed0523a2a87b83f29c5577b2c828102005d53
Change-Id: I8760feaa8598047369ef8c3ab2673013bac8ac8a
Used by I8760feaa8598047369ef8c3ab2673013bac8ac8a to add just a single
codec to a speech codec list, instead of a list.
Change-Id: I6ac23c54bc26939e048ff2df06eb987421cfb1c5
To parse and handle SDP included in incoming MNCC, use rx_mncc_sdp()
everywhere. So now rx_mncc_sdp() is the single implementation for
parsing the SDP string and taking action for codecs if needed.
One current dup of this code has a fall-back to use legacy bearer cap --
absorb that into rx_mncc_sdp(), so that we now also do that fall-back
for all of the incoming MNCC that contains bcap.
This is a cosmetic preparation for implementing MO Re-Assignment to
match MT's codec limitations.
Change-Id: I94ae11654e1f88fbd64361b639a4c583836dc13e
We're checking the result of trans_alloc() 6 out of 7 times, so check
it in gsm_silent_call_start() too, for the sake of consistency.
Change-Id: Ie989cd8146d66d9531cf3f3d84f46a2c6fcc2e5c
Fixes: CID#322140
"[ESTABLISHED] transition to state ESTABLISHED not permitted"
i.e. don't complain when we already are in the established state.
Change-Id: I9b1fd63ed1ee7ed2877a4b2059386354598f4ea4
The cfg bits are for AMR-HR, not GSM-HR. The function
gsm0808_enc_speech_codec_list2() will return -EINVAL when it encounters
GSM-HR with non-zero cfg bits.
It appears this mapping was never used before, and my testing of call
re-assignment to match MT's codecs (it allows more than just the
assigned codec, because it can re-assign) has uncovered this bug
via MSC_Tests.TC_ho_inter_msc_out. I don't fully understand all the
details why we didn't see this before; anyway, the fix is obvious.
Change-Id: I19cff847a0f618ad000d12c1df54c55ef2f79699
The SGs interface is currently only casually mentioned in the chapter
running, even though the SGs interface is a prominent and often
requested feature. Let's give the SGs interface its own section so that
users can find the info about it quicker.
Related: OS#6008
Change-Id: Ic7c17511ee19cb7f6d5069b27beb661ecb4b0be8
When trying to modify the value of an SGs counter (eg. ns11), then the
setting is never stored. The reason for this is that OsmoMSC uses the
wrong string table to compare the user input.
Related: OS#6008
Change-Id: I0358c1ec0026c37fda6db1f3af3145393df25cfd
Only the originator may terminate the VGCS/VBS call. This will not
happen in real life, because the UI of the MS should not allow
termination of a recevied VGCS call.
Change-Id: Ibe289920fa3ea50dd3e7d5c1371456dca9b72604
Related: OS#4854
Certain calls (seen on very old Nokias) won't have the rate adaptation flag
set on "analog" CSD calls. The field for the intermediate rate (after RA) is
still filled correctly.
Workaround this by setting the RA to V.110 whenever the RA is unset but an
intermediate rate is specified.
Change-Id: I5b3e5649fe071636f1becddfbfee06f9175a5f17
Bearer capability 3k1_AUDIO and FAX_G3 are only important
for the interworking function, the MSC should handle
these calls the same as CSD calls with unrestricted digital
bearer capability.
Change-Id: I198aa867a8f236b8ddd05d3b2356f64b876fd4c1
For MO-forwardSM and MT-forwardSM request messages, OsmoHLR applies
routing based on the SMSC address for MO or based on the IMSI for MT.
However, reply messages following these requests are routed passively
based on the destination_name IE. This passive message routing path
requires the source_name IE to be set as well - implement this
source_name setting.
Related: OS#6135
Change-Id: I0b7f4760bdce8a38d43d3860086c6dfb7b390701
When OsmoMSC is used with OsmoHLR rather than a GSUP-to-MAP gateway,
MT-forwardSM.req GSUP messages delivering MT SMS will be coming from
a separate SMSC relayed via OsmoHLR, rather than from OsmoHLR itself.
When we reply to these messages, in order for these replies to reach
the MT-sending SMSC via OsmoHLR, we need to save source_name from
the request and regurgitate it into destination_name in our response
messages. Implement this logic.
Related: OS#6135
Change-Id: I436e333035b8f6e27f86a49fe293ea48ea07a013
If the GSUP request message to which we are replying is an MT SMS
delivery from an SMSC relayed via OsmoHLR, we must set destination_name
in our reply - otherwise our reply won't make it back to the SMSC.
Related: OS#6135
Change-Id: I892fe87a733a78ed9d5761a8ce238caa135dea1e
The intent of the guard timer is to clear hung or stuck states
during call setup or teardown. However, there are some MNCC
messages that will be exchanged between OsmoMSC (passing CC
messages to and from the MS) and the external MNCC agent during
the active call state, not related to setup or teardown: DTMF
start and stop, plus call hold and retrieve operations for call
waiting. Unpatched OsmoMSC restarts the guard timer on every
received MNCC message, even those that pass through to CC without
affecting any state, and the result is breakage for users.
Consider the case of an IVR where you have to press some DTMF keys
before you can be transferred to a human operator. You press the
needed keys, get the human operator, and start talking. Then
3 minutes into your conversion (default guard timer duration)
your call unceremoniously disconnects without any warning.
Fix: look at the MNCC message type, and skip the call to start
the guard timer for known-benign MNCC messages.
Change-Id: Ibe2dd53f8e9e06d175b64df67d2a2e3e2d4155aa
This is a fixup for the patch
'3G: decapsulate IuUP to AMR at the MGW; allow 3G<-AMR->2G'
I386a6a426c318040b019ab5541689c67e94672a1
After above patch, osmo-msc intelligently decides which codecs to run on
which legs of the RTP streams. In the meantime, it seems the necessary
matching changes to call_leg_local_bridge() had been lost somehow.
Testing 3G to 3G voice now, I noticed that call_leg_local_bridge()
overwrites the intelligent choices made earlier.
The history of an MGW endpoint that should convert from IUFP to plain
AMR, extracted from a pcap, looks like this:
<- CRCX None None
-> CRCX-OK audio 4050 RTP/AVP 112 None
<- MDCX audio 4056 RTP/AVP 112 AMR
-> MDCX-OK audio 4050 RTP/AVP 112 AMR
<- MDCX audio 4056 RTP/AVP 96 VND.3GPP.IUFP
-> MDCX-OK audio 4050 RTP/AVP 96 VND.3GPP.IUFP
So after call_leg_local_bridge(), there is an extra MDCX + MDCX-OK that
switches the codec from 112 AMR back to 96 IUFP.
That is because call_leg_local_bridge() copies the *RAN* side's codec to
both CN sides, which used to be ok when RAN and CN codecs were always
identical.
Instead, adjust only the CN sides of the MGW endpoints, and adjust them
so that both CN sides are identical. osmo-mgw should then be able to
trivially translate the codecs appropriately.
Change-Id: I130bcd77ec57e332370c487a11b0b973b6e1089d
Fail if MNCC tries to switch the Information Transfer Capability from
CSD to speech, so it is obvious that something is wrong here. I ran into
this while writing a test.
Related: OS#4394
Change-Id: Ibb76d08cad1ac3bc3320391c89766150a2e605c3
Reject any other codec than GSM0808_SCT_CSD in Assignment Complete from
RAN, if OsmoMSC is preparing a CSD call.
Related: OS#4394
Change-Id: I94de84df41bcd050d0e7b4e4fea1c6a6551ef7d3
Instead of asserting on an empty list of bearer services, return
-EINVAL. This makes the function more similar to
sdp_audio_codecs_to_gsm0808_channel_type which also doesn't assert if
an empty list of codecs is passed.
Related: OS#4394
Change-Id: I15a389e1f7a9d3d17b6531c9836d3d5f9d148267
The MS in general provides the Selected PLMN ID (IE) in the Complete
Layer 3 Information message. osmo-msc handles that message in
msc_a_ran_dec_from_msc_i() and stores the information of the PLMN in
msc_a->via_cell. If no PLMN information is provided in the message, then
at that same place the PLMN configured in the VTY is taken as an implicit
default.
This patch changes trans_lcls_compose() to use the PLMN stored in
msc_a->via_cell instead of the VTY configured one, meaning the PLMN
provided by the MS (through the RAN in use) is used if available
(otherwise the VTY-configure one is still used, as before).
With this patch the PLMN VTY config option use is relegated to a single
point of use in msc_a_ran_dec_from_msc_i() where the Complete Layer 3
Information is used. As a result, it becomes clear now that the VTY
config is only applied in the scenario where no PLMN is provided at that
time.
Related: SYS#6360
Change-Id: Ibad0005a1d7cef64dd8fefa3e554ba99a06c3666
The MS in general provides the Selected PLMN ID (IE) in the Complete
Layer 3 Information message. osmo-msc handles that message in
msc_a_ran_dec_from_msc_i() and stores the information of the PLMN in
msc_a->via_cell. If no PLMN information is provided in the message, then
at that same place the PLMN configured in the VTY is taken as an implicit
default.
The PLMN information stored in msc_a->via_cell is then finally stored
into vsub->cgi in evaluate_acceptance_outcome().
This patch changes gsm0408_loc_upd_acc() to avoid re-applying the PLMN
configured at the VTY again, and instead use whatever is already in
vsub->cgi. This is more correct since the PLMN provided by the MS takes
precedence over the implicitly configured one, meaning several PLMNs can
be handled. Otherwise, the code is always overwriting the PLMN announced
by the network on a specific RAN with the one in the MSC, which may end
up with unexpected results.
Related: SYS#6360
Change-Id: I421bd63a264db2bf6e1c4a4eea976f389e87b332
Currently this function fails to initialize all bcap fields properly,
so the resulting CC Setup message generated by osmo-msc has some
fields set to reserved/invalid values.
With these changes I am able to establish a data call on TCH/F9.6:
* cap->{mode,coding}: assign default values explicitly;
* cap->radio: value 0 is reserved, set GSM48_BCAP_RRQ_FR_ONLY;
* cap->data.sig_access: value 0 is reserved, set GSM48_BCAP_SA_I440_I450;
* cap->data.transp: this is not a bool, set GSM48_BCAP_TR_{TRANSP,RLP};
* cap->data.{nr_{data,stop}_bits,parity}: set 8N1 by default;
* cap->data.modem_type: explicitly assign default value;
* cap->data.interm_rate: value 0 is reserved, set GSM48_BCAP_IR_{8k,16k}.
The related libosmocore.git patch additionally fixes encoding of the
"Connection element (octet 6c)", so that bcap->data.transp is used.
Change-Id: If49c89e4f867bac92ad062c062b9f36bab2b4531
Related: libosmocore.git I7339908864e8a2aef6f2b48a108650167e413c7f
Related: OS#6110, OS#4394
Without the gsm0808_speech_codec functions:
* codec_mapping_by_gsm0808_speech_codec_type(), and
* codec_mapping_by_gsm0808_speech_codec()
fail to find the codec mapping for CLEARMODE.
Change-Id: I87b3aedaf7ff7bbbcb381e94158566dc765e3ae6
Related: OS#6110, OS#4394
As per 3GPP TS 48.008, section 3.2.2.103, the Codec Type is valid if
at least one of FI, PI or PT is set to '1'. Otherwise the Speech
Codec Element is considered invalid and shall be ignored.
Change-Id: Ibc452d37d4215c961a7946eef3ba2e7efdba078b
Related: OS#6110, OS#4394
Whenever we call build_tlv() we must
call destroy_tlv() after we are finished with it.
Similarly, smpp34_unpack() makes calls to smpp34_malloc()
and these need to be free'd by us later.
Change-Id: Ic2abcbe78cf7cf7b6ce36fe09aa9b4f8daee973f
Voice group call and voice broadcast call messages as well as assignment
result are forwarded to VGCS/VBS call control.
Change-Id: Ie68eedb8fcb064a55cd71b58630d7a8c8b5f29ad
Related: OS#4854
When sending or receiving BSSMAP reset msg, the ongoing VGCS/VBS SCCP
connections are cleared. E.g. this happens if the BSC is restarted and
there is an ongoing VGCS/VBS call at this BSC.
Change-Id: Ib0b309150b82148098d05cfb1fb18767283e654e
Related: OS#4854
When the calling phone releases the uplink before it has been assigned
to the group channel, it will send an UPLINK RELEASE message on the
dedicated channel.
This message is forwarded to VGCS state machine to handle the release
there.
Change-Id: Ie8f7338da18eaaefbb022c09b96f18a3d78f8a95
Related: OS#4854
Switching ASCI support is controled via VTY. This added in a later
patch. (Chg-Id: I5bd034a62fc8b483f550d29103c2f7587198f590)
Change-Id: Id68deb69f7395f0f8f50b3820e9d51052a34f753
Related: OS#4854
A voice group/broadcast call has no SCCP connection that is related 1:1
to a calling or called subscriber. Instead there are multiple connections
between MSC and BSS. Some of them control the uplink for each BSS and
some of them assign the channels for each BTS.
SCCP connections are maintained by the VGCS call control. Message from the
RAN are directly forwarded to the VGCS call control.
Change-Id: Ie4a2f19ba75140a6f2de02b709597239c01f02a2
Related: OS#4854
There is no GSM0808_DATA_RATE_TRANSP_300 (not in libosmocore and not in
3GPP TS 48.008 § 3.2.11 on which the enum is based). As I understand it,
we need to use GSM0808_DATA_RATE_TRANSP_600.
As pointed out in review, either TCH/H2.4 or TCH/F2.4 would work for
rates below 9600, so use GSM0808_DATA_FULL_PREF.
Use GSM0808_DATA_FULL_BM instead of GSM0808_SPEECH_FULL_BM. The value is
0x8 for both, but this is the correct name.
Related: OS#4394
Change-Id: I7297cc481fbe36355b5231ca800cf566a1ee93c0
VGCS/VBS messages from BSS are decoded and a receiver funktion for
the GCC/BCC (VGCS/VBS call control) is selected.
Change-Id: Ief6259ba3914eeaceb063b562a0bcbc48349ce60
Related: OS#4854
The (optional) call reference is required to assign a calling subscriber
to a voice group/bcast channel. The BSC can then determine to which
existing VGCS/VBS channel the MS is assigned to.
This IE is part of the GSM standard TS 48.008 (see §3.2.1.1)
Change-Id: I7955c6e0eebc930f85f360dda46be17cbd39e181
Related: OS#4854
This is a built-in data structure to store and handle voice group calls.
The GCR will be used by VGCS/VBS call control.
(Chg-Id: I9947403fde8212b66758104443c60aaacc8b1e7b)
The GCR will be used by VTY code.
(Chg-Id: I5bd034a62fc8b483f550d29103c2f7587198f590)
Change-Id: Ia74a4a865f943c5fb388cd28f9406005c92e663e
Related: OS#4854
Generally a transaction is linked with a subscriber (vsub).
A voice group call transaction may not have a subscriber associated. The
vsub field of the transaction will be NULL. If the group call is
initiated by a calling subscriber, the vsub field is set until the
calling subscriber is assigned to the voice group channel. If the group
call is initiated via VTY, vsub field is not set on creation of the
transaction.
Change-Id: I2b9afe95db4c106c141f4b7bd199ec74e197e523
Related: OS#4854
- TRANS_GCC is used for the voice group call.
- TRANS_BCC for the voice broadcast call.
This also includes the use counters for transaction and CM service
request usage:
- MSC_A_USE_GCC
- MSC_A_USE_BCC
- MSC_A_USE_CM_SERVICE_BCC
- MSC_A_USE_CM_SERVICE_GCC
Change-Id: Iddd11f813582ac2ac2bdee91cc3a525986deb514
Related: OS#4854
A transaction can be identified by the callref and the type. Because
transactions with different types may share the same callref value,
it is required to include the type in the trans_find_by_callref()
parameters.
E.g. a voice group call may have the same callref as a voice broadcast
call, but they are different calls. They also may not be confused with
other transaction types having eventually equal callref value, like
GSM 04.08 calls, SMS or supplementary services transactions.
By adding the transaction type to trans_find_by_callref(), we
essentially now use the (type, callref) tuple as unique ID for
transactions, instead of just callref.
Change-Id: Ic0b82033a1aa3c3508ad610c690a5f29073006c1
Related: OS#4854, OS#3294
Allow the caller of rtp_stream_alloc() to define what events will be
dispatched to the parent FSM. This allows other state machines to use
rtp_stream. It is required for using RTP stream process with VGCS FSM.
Drop the unused parent_call_leg member.
Change-Id: I0991927b6d00da08dfd455980645e68281a73a9e
Related: OS#4854
So far rtp_stream_commit() triggers an MGCP MDCX message only when
codecs or the RTP address changed.
Do the same for mode changes. ('sendrecv', 'recvonly', 'sendonly',...)
Change-Id: I7a5637d0a7f1df13133e522fc78ba75eeeb2873e
Related: OS#4854
The MGCP protocol features the 'C' (call-id) to identify which
connections belong to the same call. They may be used by MGW for
accounting or management procedures.
So far we sent the MNCC callref as call-id. Instead, add a separate
unique call_id number space. Assign a unique call_id to each
transaction.
Change-Id: I36c5f159fa0b54fb576ff8bd279928b895554793
Related: OS#4854
Use the MNCC bearer capabilities in CC setup for CSD, if available.
Note that in the MNCC_F_BEARER_CAP code path sdp_audio_codecs_set_csd()
also gets called by trans_cc_set_remote_from_bc().
Related: OS#4394
Change-Id: I56e49ebc41696912a81b8f4f63fbc36d0b605e9e
Check the return code before writing it to unsigned ct->data_rate, as
"ct->data_rate < 0" is never true.
Fixes: CID#321277
Fixes: 106321 ("Add initial CSD support with external MNCC")
Change-Id: I5d77da71b60748818ba631229126c1bf061a9c7d
Prepare to use trans->bearer_cap.transfer in trans_cc_filter_run() to
differentiate between speech and data (CSD).
Related: OS#4394
Change-Id: Id0476a4882bcb27413d033f2de2c5288954f0b95
Move remote out of codecs, as it will be used by CSD code as well.
Otherwise we would need to store it twice (in cc.codecs.remote and
cc.csd.remote).
Related: OS#4394
Change-Id: I5d2e078db3b3437cb6feae40d8955912d7a297e4
Remove the comment as trans->bearer_cap will be used in CSD code to
differentiate between speech and data.
Related: OS#4394
Change-Id: I0539632f464bc44945599bec52dc2a4df2f0115f
Remove the misleading "We must not pass bearer_cap to
codec_filter_init()" part of the comment. The function doesn't accept a
bearer_cap parameter, it cannot be passed to the function:
void codec_filter_init(struct codec_filter *codec_filter)
{
*codec_filter = (struct codec_filter){};
}
Related: OS#4394
Change-Id: I87a1e371e108d8da514b30f1726aad0f85ea4111
In all the places where codec_filter_ functions get called, for CSD we
will need to filter the bearer services. Add a new
transaction_cc.c file for functions that either combine the
codec_filter_ function with logic for CSD and voice calls or just call
the existing codec_filter function and a new csd_filter function.
Start with moving codec_filter_set_ms_from_bc to this new file, it will
be extended with a case for CSD in a future patch.
Related: OS#4394
Change-Id: If225f2a299ce6bc9ae35a17d6f591d889f49155e
cat-testlogs.sh does "exit 1", so no workspace.tar.xz is created.
Call this script after archiving the workspace.
Change-Id: Ibcb842f32418e66a186d6b21bb5861cf4a0b7c4a
Fixes: 799d972132 "contrib/jenkins: create workspace.tar.xz on error"
Related: OS#5665
In order to figure out why we sometimes get a coredump in the jenkins
master jobs, add a quick hack to get all relevant binaries on libraries
on error.
Related: OS#5665
Change-Id: If7b4eb050e2b3f763b5cfddf1a5b6a18bb41f46e
For all 3G calls, convert IuUP <-> plain AMR/RTP on the MSC's MGW hop
like this:
Before this patch:
hNodeB <--IuUP--> MGW@hnbgw <--IuUP--> MGW@msc <--IuUP--> other call leg
After this patch:
hNodeB <--IuUP--> MGW@hnbgw <--IuUP--> MGW@msc <--AMR--> other call leg
^
This allows, in principle, 2G to 3G calls without expensive transcoding,
like this:
hNodeB <--IuUP--> MGW@hnbgw <--IuUP--> MGW@msc <--AMR--> MGW@msc <--AMR--> MGW@bsc <--AMR--> 2G-BTS
^
(So far only proven to work with AMR-FR at 12k2.)
3G to 3G calls now look like this:
hNodeB <--IuUP--> MGW@hnbgw <--IuUP--> MGW@MSC <--AMR--> MGW@MSC <--IuUP--> MGW@hnbgw <--IuUP--> hNodeB
^
Implementatino: get rid of the shim that was put in place to still send
IuUP (VND.3GPP.IUFP) to the CN. So now, for all 3G voice, the IuUP gets
decapsulated to plain AMR/RTP at the MSC's MGW hop.
What is proven to work with this patch:
successful voice call between 2G and 3G with these conditions:
- a hNodeB that stubbornly accepts only 12k2 AMR;
- a 2G BTS configured to use only TCH/F and only FR3, with only 12k2 as
allowed AMR rate.
We have not yet seen a call working for TCH/H HR3 <-> 3G, because of the
lab hNodeB's limitation to 12k2.
Future work we probably need:
- properly request and negotiate AMR rates via SDP fmtp:mode-set.
- request more RFCIs in our RANAP RAB Assignment requests
(see I61e0e9e75e3239662846fd797532acdefa9f73dc).
- Convert IuUP to AMR already at the HNBGW's MGW?
Solving this is not part of this patch.
Related: SYS#5092
Change-Id: I386a6a426c318040b019ab5541689c67e94672a1
When the SMS sqlite db is opened and not closed properly, sqlite will
print a trace on the next OsmoMSC startup while restoring the database.
This happens when e.g. attempting to bind OsmoMSC on an IP that is not
available (yet) and then restarting OsmoMSC.
db.c:521 Init database connection to 'sms.db' using SQLite3 lib version 3.34.1
db.c:318 SQLITE3: (283) recovered 37 frames from WAL file /var/lib/osmocom/sms.db-wal
backtrace.c:42 backtrace() returned 22 addresses
backtrace.c:53 /lib/x86_64-linux-gnu/libsqlite3.so.0(+0x36a56) [0x7f1518c00a56]
backtrace.c:53 /lib/x86_64-linux-gnu/libsqlite3.so.0(sqlite3_log+0x9e) [0x7f1518c00b3e]
backtrace.c:53 /lib/x86_64-linux-gnu/libsqlite3.so.0(+0x5f4f4) [0x7f1518c294f4]
backtrace.c:53 /lib/x86_64-linux-gnu/libsqlite3.so.0(+0x5fbb3) [0x7f1518c29bb3]
backtrace.c:53 /lib/x86_64-linux-gnu/libsqlite3.so.0(+0x7ee02) [0x7f1518c48e02]
backtrace.c:53 /lib/x86_64-linux-gnu/libsqlite3.so.0(+0x7f908) [0x7f1518c49908]
backtrace.c:53 /lib/x86_64-linux-gnu/libsqlite3.so.0(+0xb9a5f) [0x7f1518c83a5f]
backtrace.c:53 /lib/x86_64-linux-gnu/libsqlite3.so.0(+0xcddac) [0x7f1518c97dac]
backtrace.c:53 /lib/x86_64-linux-gnu/libsqlite3.so.0(+0xcddef) [0x7f1518c97def]
backtrace.c:53 /lib/x86_64-linux-gnu/libsqlite3.so.0(+0xf537d) [0x7f1518cbf37d]
backtrace.c:53 /lib/x86_64-linux-gnu/libsqlite3.so.0(+0xb479e) [0x7f1518c7e79e]
backtrace.c:53 /lib/x86_64-linux-gnu/libsqlite3.so.0(+0xb79b6) [0x7f1518c819b6]
backtrace.c:53 /lib/x86_64-linux-gnu/libsqlite3.so.0(+0xb8116) [0x7f1518c82116]
backtrace.c:53 /lib/x86_64-linux-gnu/libsqlite3.so.0(+0xb853f) [0x7f1518c8253f]
backtrace.c:53 /lib/x86_64-linux-gnu/libsqlite3.so.0(sqlite3_prepare_v2+0x16) [0x7f1518c826a6]
backtrace.c:53 /lib/x86_64-linux-gnu/libsqlite3.so.0(sqlite3_exec+0xb4) [0x7f1518c8fce4]
backtrace.c:53 /usr/bin/osmo-msc(+0x1bf13) [0x564f81946f13]
backtrace.c:53 /usr/bin/osmo-msc(+0x524c0) [0x564f8197d4c0]
backtrace.c:53 /usr/bin/osmo-msc(+0x1324e) [0x564f8193e24e]
backtrace.c:53 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea) [0x7f1518991d0a]
backtrace.c:53 /usr/bin/osmo-msc(+0x13fea) [0x564f8193efea]
Related: SYS#6360
Change-Id: I9bb799048db5fcdb2a2520107bd75d5f7a865459
Don't fall back to the legacy config if the pool is configured but no
connection to any pool member can be established.
Depends: osmo-mgw I009483ac9dfd6627e414f14d43b89f40ea4644db
Related: OS#5993
Change-Id: I44e7b2723d801ceb03aaa2e5546802b4eb56b3c3
In msc_vlr_test_call, we fail to send the right MNCC struct for
MNCC_RTP_CREATE. We should pass a struct gsm_mncc_rtp. Fix that.
Change-Id: Ia0b3253f85c716e45f925da3f58f025af1f15ec9
In order to send the MSC's RTP endpoint IP address+port in the initial
SDP, move the MGCP CRCX up to an earlier point in the sequence of
establishing a voice call.
Update the voice call sequence chart to show the effects.
Though the semantic change is rather simple, the patch is rather huge --
things have to happen in a different order, and async waits have to
happen at different times.
The new codec filter helps to carry codec resolution information across
the newly arranged code paths.
Related: SYS#5066
Change-Id: Ie433db1ba0c46d4b97538a969233c155cefac21c
Upcoming patch 'do CN CRCX first' changes the ordering of MGCP. To
properly show the change in behavior in the msc_vlr_test_call, first
clarify which side is expected to do MGCP when.
Related: SYS#5066
Change-Id: I972e7426006e5b62f81ccfe4fa224ee9eed7a7ac
Transmit and receive full SDP information via MNCC, to accurately pass
codecs choices between the call legs.
In msc_vlr_test_call.c test_call_mt(), show that when receiving MNCC,
the codec information in SDP overrules the Bearer Cap codec information
-- we expect to still receive inaccurate Bearer Cap from e.g.
osmo-sip-connector, because we have chosen to add SDP to MNCC instead of
trying to fix the codecs represented in Bearer Cap.
For internal MNCC, the MT call leg now knows which codec the MO has
chosen and assigned.
For external MNCC, osmo-sip-connector receives SDP about our codecs
choices and sends it in SIP messages, and we also receive the full SDP
information from the remote SIP leg.
Update the SDP in codec_filter every time it is received, to always have
the latest SDP information from the remote leg.
CC MNCC
| ---ALERTING--> | add local side SDP to MNCC msg
| <--ALERTING--- | store remote side SDP
| <--SETUP-RESP- | store remote side SDP
| --SETUP-CNF--> | add local side SDP to MNCC msg
| -RTP-CREATE--> | use codec_filter, add local side SDP to MNCC msg
| <-RTP-CONNECT- | store remote side SDP
There still is one problem: when initiating MNCC, we do not yet know the
RTP address and port to be used for the CN side, because the CN CRCX
happens later. So far we send 0.0.0.0:0 as RTP endpoint in the SDP,
until the CN CRCX is done. A subsequent patch moves CN CRCX to an
earlier time, adding proper RTP information right from the start.
Related: SYS#5066
Change-Id: Ie0668c0e079ec69da1532b52d00621efe114fc2c
So far, patches have set up rtp_stream to allow setting multiple codecs,
and collected the codecs information into the codecs filter struct.
Now actually use the codecs filter result to choose a codec.
Setting up the call leg FSMs and codecs still looks rather confusing in
this patch, because this is an incremental step in a larger series. The
upcoming patch 'do CN CRCX first' clarifies this substantially.
The resulting codecs behavior is tested in upcoming patch
I879ec61f523ad4ffc69a0b02810591f7c0261ff9. (The test ideally should have
come before this patch, but my time to rework this branch is up.)
With the codecs filter in place, we are ready for sending and receiving
full SDP via MNCC, see upcoming Ie0668c0e079ec69da1532b52d00621efe114fc2c
and Ie433db1ba0c46d4b97538a969233c155cefac21c
Related: SYS#5066
Change-Id: I66e7c8c5e401f4f3a7d3d42b9525b2c6e99691d9
So far, we just forwarded the Bearer Capabilities received in MNCC from
the remote MO call leg, and omitted Bearer Cap if the remote call leg
did not provide any.
Instead, always include Bearer Cap, and compose it from the codecs
filter result. Hence the Bearer Cap is now an intersection of MS, BSS
and remote call leg, instead of just the remote call leg.
Related: SYS#5066
Change-Id: I9586221ef56352b7ce4b2604ae0dc04554145a78
Do not convert to enum mgcp_codecs, but directly pass the
gsm0808_speech_codec IE from the A interface to codecs handling.
For Iu:
- RAN side: use ran_infra.force_mgw_codecs_to_ran to keep the MGW
endpoint towards RAN on IUFP.
- CN side: introduce flag ran_msg.assignment_complete.codec_with_iuup,
so to decide whether to forward IUFP towards CN, we don't need to test
the RAN type, but use the flag from the ran_msg implementation.
In msc_vlr_tests, use the SDP codec string instead of enum
mgcp_codecs.
So far limit to intra-MSC related messaging, adjusting inter-MSC
handover follows in a separate patch.
Change-Id: Ia666cb697fbd140d7239089628faed93860ce671
Allow configuring MGW conns with multiple codecs. The new codecs filter
can have multiple results, and MGCP can configure multiple codecs. Get
rid of this bottleneck, that so far limits to a single codec to MGW.
On Assignment Complete, set codec_filter.assignment to the assigned
codec, and use that to set the resulting codec (possibly multiple codecs
in the future) to create the CN side MGW endpoint.
Related: SYS#5066
Change-Id: If9c67b298b30f893ec661f84c9fc622ad01b5ee5
Indicate in the ran_infra data structure whether a RAN needs specific
codecs to be set up on the RAN facing MGW endpoint.
This allows setting forced RAN codecs as first-class citizen in the
ran_infra data structure, instead of special cases in the code (for IuUP
on IuCS).
Will be used in subsequent commit
I37f65c36af2679ecba1040a11a9aa0eb9481d817, submitted separately for
easier readability.
Change-Id: I37f65c36af2679ecba1040a11a9aa0eb9481d817
Codec List (BSS Supported) is received once in Complete Layer 3 and
again in Assignment Complete messages. Use the most recent one, i.e. the
one from Assignment Complete, when it occurs.
Related: SYS#5066
Change-Id: I5e66ecc7987fa926f39d8be8eaf5799b931ab20a
I noticed by chance that the Assignment Complete message generated in
the test lacks a remote RTP address for the RAN side.
Make the test more realistic by adding a remote RTP address and port. It
doesn't have any bearing on the tests besides more accurately showing
RTP stream setup in the logs.
Change-Id: Ia428762a16dcc17f036d725a00e0b3767418289b
Collect either the SDP or the Bearer Capabilites in the incoming
MNCC in the new codecs filter.
So far just collect the info and do not change the behavior, using the
filter result will follow in a subsequent patch.
Related: SYS#5066
Change-Id: I84d9bbca3e4061da622b1b2fc0bde8868e7e3521
For MT call, initialize the codecs filter and apply the
Codec List (BSS Supported) from Compl L3.
Related: SYS#5066
Change-Id: I530409a64d11da48518a3dc60aa3a4e47c384663
The initial Compl L3 happens long before we establish a CC transaction.
Remember the Codec List (BSS Supported), so that we can feed the new
codecs filter with it. Subsequent patches implement feeding the filter.
Related: SYS#5066
Change-Id: I7cdc348218433141a43d2e42750af02591688240
Add the central codecs_filter for Call Control. The new member is not
used in this patch yet, subsequent patches will start to populate the
various stages of this codec filter, one by one.
Related: SYS#5066
Change-Id: Ib3fdeff8d1e1ea0760168d63ee6e1b1fb993aa5f
Add the infrastructure to store and filter all codec limitiations from
the different stages: MS, BSS, CN and remote call leg. Upcoming patches
will properly collect these and find an optimal codec.
No functional change, yet.
Related: SYS#5066
Change-Id: I4d90f7ca62f2307a7b93dd164aeecbf4bd98ff0a
Converting between different codec representations is confusing. This
codec mapping provides a consolidated overview of all our codec
representations, and how they match up.
In particular, it adds the SDP codec representation repertoire,
preparing the use of full SDP on the MNCC interface.
Related: SYS#5066
Change-Id: Iaa307be6a8487aa8d4ba7cd59d5c5ef04818a744
This option should be used for any executables which are used only
for testing, or for generating other files and are consequently never
installed. By specifying this option, we are telling Libtool that
the executable it links will only ever be executed from where it is
built in the build tree. Libtool is usually able to considerably
speed up the link process for such executables.
Also take a chance to add the missing $(COVERAGE_LDFLAGS).
Change-Id: I664a9d5abed2777deee302f9d3afd1bbfde7a844
Same as voice_call_external_mncc.msc, but run with internal MNCC. Shows
some curious differences like the MNCC_LCHAN_MODIFY that internal MNCC
sends, but external doesn't.
Change-Id: Ic003322dc4e3fce24a8413688cfe18198a4dc08a
Re-run the msc_log_to_ladder.py on an actual 2G-2G voice call log, to
see if anything changed in the meantime, to prepare for upcoming changes
to the sequencing of establishing voice calls.
Also shows recent improvements on picking up RTP ports from MGCP and
MNCC.
Change-Id: I9dcf980ad24d5921c291c9aada211b37f6f3db7f
(multiple changes in one patch because who cares about this script)
tweak regexes -- they worked ok, but some of the '[^:]' should really be
'[^:)]', and they also look happier that way.
don't skip RAN=NONE, so we also see messages before Complete Layer 3.
s/sip/mncc, to generally be valid for both internal and external MNCC.
pick up RTP port information from MGCP OK
pick up RTP port information from MNCC rx and tx
add --verbose flag, to be able to check whether the regex rules are
still working (getting any hits).
fix rule_imsi_detach: should return True to be counted in --verbose.
tweak comment 'Generated by...' to include the full git path.
Change-Id: If619182ba76c6b238a1fa105a3c3449d7f473dd1
Omit "in state FOO", because LOG_TRANS() already logs the state.
Most MNCC "rx" logging was duplicated. Log "rx" only once.
If there is RTP information passed with the MNCC message, log it:
- if there is SDP, log the SDP information.
- if there is no SDP, log the legacy MNCC RTP fields, if any.
One motivation to do this is to get RTP information in ladder diagrams
generated by msc_log_to_ladder.py without the need to add udtrace MNCC
logging to osmo-msc; and also to get RTP info for internal MNCC, where
udtrace doesn't apply, because no unix domain socket is involved in
internal MNCC operation.
Change-Id: I4b916cb482ed441b508c6295de211a21c49cd5c1
Both EXTRA_DIST and CLEANFILES had missing entries. It is easy to
forget to keep them up to date. Rather use wildcards to always pick up
all relevant files.
(Not adding *.dot because there are no .dot charts here, yet.)
Change-Id: I3a18e4608a310169d7c9cd9c1b8ac9015a990920
Since osmo-mgw now supports IuUP properly, and since we indicate IUFP in
the MGCP CRCX towars an IuCS RAN [1], we should no longer place the MGW
endpoint in loopback mode to hack up an IuUP Initialization.
This hack should have been removed along with [1].
[1] IUFP sent to MGW since this commit:
commit 3a02d29804
Refs: 1.8.0-13-g3a02d2980
Announce IuFP audio codec for UTRAN conns in CRCX towards MGW
I7aca671e00ed27ac03f0d106b5a6b665a9bed4c1
Change-Id: I6446c64421e3e13e2b829293d031c98b99cd39a7
A new VTY node was added in commit [1], but bsc_vty_go_parent() was
not updated. Because of that, commands following the MGW node may
crash osmo-msc. See related patch [2] for more details.
Change-Id: I2422fa9152ecc8c4be1f2487ee016c3fe737e653
Fixes: [1] b44cf2d575
Related: [2] osmo-bsc.git Id3050ff7e2402c33ee76c7bf0cc83603c0cc6dfc
According to 3gpp spec the Call Reference part of GCR is 5 octets,
3 octets Call ID followed by 2 octets BSS ID.
We are using our internal call reference (4 octets) and the
location area code, or optionally Cell ID as BSS ID
(2 octets). Obviously it does not fit.
Let's use only 3 octets from the call reference, dropping the MSB.
Includes code by Vadim Yanitskiy <vyanitskiy@sysmocom.de>
Change-Id: I9c33a89c819e8925d89ca833d7705ed5ced6b566
Now that the warnings in osmo-iuh have been fixed, we should be able to
build the IU version of OsmoMSC with --enable-werror too.
Related: OS#4462
Change-Id: Id54be9dd1aa66cc27eb5ee4010be9e495865b331
When the HLR fails to return auth info and authentication and ciphering
are configured to be optional, fall back to no-auth.
This patch concludes a series of preparatory patches and implements the
actual functional change.
Related: OS#4830
Change-Id: I5feda196fa481dd8a46b0e4721c64b7c6600f0d1
Add third outcome of auth_fsm: the no_auth_info_event, which should be
dispatched when auth failed because the HLR has no auth info for this
subscriber, i.e. not because an actual auth challenge failed.
No functional change: Handling no_auth_info_event separately follows in
another patch (to allow fallback to no-auth). Feed the same
_E_AUTH_FAILURE as no_auth_info_event to still behave unchanged.
Related: OS#4830
Change-Id: I5103b1f2727f1729a5517ae359df813d50436ed3
Previous patch added the AUTH_FAILURE event, which means that the
AUTH_RES event now only signals success. Reflect that in the name.
No functional change.
Related: OS#4830
Change-Id: I7124a3591fcf36cee06d7488eeb94f9b85af5dc2
Explicitly send distinct parent events on auth success and failure. So
far determining success depended only on the data pointer passed on with
the event. Distinct events clarify the logging and the FSM code.
This prepares for a third FSM outcome to be added in a subsequent patch,
to separately signal when the HLR has no auth data.
No functional change.
Related: OS#4830
Change-Id: I02776dfe6785983f2ebe398f57867f5ceb288ba0
These functions actually return whether these procedures should be
attempted, not whether they are absolutely required. Rename to avoid
confusion in upcoming patches.
Related: OS#4830
Change-Id: I0ea90476470109134411255ffd1f11d88236c91b
For establishing Layer 3, pass a flag from msc_a to VLR that indicates
to fail if encryption is not possible.
An earlier patch [1] renamed a previously existing flag
require_ciphering to is_ciphering_to_be_attempted, because the naming
was not accurate. This new flag now indicates what its name suggests.
This new flag is needed for upcoming patch [2] to distinguish between
optional and mandatory encryption.
[1] Ia55085e3b36feb275bcf92fc91a4be7d1c24a6b9
[2] I5feda196fa481dd8a46b0e4721c64b7c6600f0d1
Related: OS#4830
Change-Id: I52090c5f5db997030da7c2ed9beca9c51f55f4cf
Clarify the name to avoid confusion in upcoming patches.
This function actually returns whether any ciphering mode besides A5/0
is enabled, and does not imply that ciphering is mandatory. A5/0 may
well be allowed when this function returns true.
Related: OS#4830
Change-Id: Ia55085e3b36feb275bcf92fc91a4be7d1c24a6b9
This way we document the recently gained support for MGW pooling.
Related: SYS#5987
Depends: osmo-gsm-manuals.git Change-Id Ieda0d4bfe6fc90da6e19c791d8ec2da89427ba3b
Change-Id: I9d8116a74a63591599c4cbafa60f9a313e6ab19c
Since call_leg_fsm_releasing_onenter() calls immediatelly
osmo_fsm_inst_term(), it meant we couldn't receive any event in that
state because osmo_fsm disables event dispatching to FSMs being
terminated.
As a result, CALL_LEG_EV_MGW_ENDPOINT_GONE was never received and hence
call_leg_mgw_endpoint_gone() was never called, which means the
mgcp_client used in cl->mgw_endpoint was never put back to the pool.
By first freeing all the children (rtp_streams), we make sure
cl->mgw_endpoint ends up with no conns and sends us the GONE event
before we go ourselves into termination state.
Related: SYS#5987
Change-Id: I2126578c4e64c9f336e8a1f6ee98de970866b8dc
New VTY commands have been added recently to the "mgw" node which drop
the redundant "mgw" prefix on each fo them.
Change-Id: I8ac11388e9493416b644812638e1374251725584
Depends: osmo-mgw.git Change-Id: Id55af13d2ecde49d968b9dca6a2f8108a17ec484
Related: SYS#5987
Let's use the new API available in libosmo-mgcp-client to control more
consciously where the mgw pool config is printed.
Before this patch, the place where the node was printed was defined
based on implementation details on how the enum of nodes are defined and
installed.
Related: SYS#5987
Depends: osmo-mgw.git Change-Id I7a620cf47886d8ecab30ce369cf123d98ab842c5
Change-Id: Ic473fe05c55e8df3eddedf0260ec04b6fefc501f
Large RAN installations may benefit from distributing the RTP voice
stream load over multiple media gateways.
libosmo-mgcp-client supports MGW pooling since version 1.8.0 (more than
one year ago). OsmoBSC has already been making use of it since then (see
osmo-bsc.git 8d22e6870637ed6d392a8a77aeaebc51b23a8a50); lets use this
feature in osmo-msc too.
This commit is also part of a series of patches cleaning up
libosmo-mgcp-client and slowly getting rid of the old non-mgw-pooled VTY
configuration, in order to keep only 1 way to configure
libosmo-mgcp-client through VTY.
Related: SYS#5091
Related: SYS#5987
Change-Id: I7670ba56fe989706579224a364595fdd4b4708ff
Those commands are not controlled/implemented in this repository, so
it's a bad idea having them show up here, since they may change. be
modified, become deprecated, etc.
They are actually becoming deprecated now in libosmo-mgcp-client
(osmo-mgw.git Change-Id Id55af13d2ecde49d968b9dca6a2f8108a17ec484) and
hence they don't appear anymore when listing the node.
Change-Id: I5d908f9e3023f725d49ed039158bd3d09828f12c
The global g_smsc struct pointer is defined twice in the same file.
Let's keep the earlier definition.
Related: OS#5568
Change-Id: If96a44450563d45b707bdd4165cf3cf269db9906
The timer "mgw X2" (RTP stream establishing timeout)
is set by default to 30 seconds.
When an MT call is ringing and remains unanswered, it
is this timer that will expire, and the call is terminated.
Up to now this results in a CC_CAUSE of Resource Unavailable
and if osmo-sip-connector is in use, the SIP agent will
get 503 Service Unavailable.
While "resource unavailable" may be technically correct, in
that the MGW did not return an rtp stream in time, returning
"No User Responding" (resulting in SIP 480) is probably a
more accurate description of what actually happened,
allowing the switch to inform the caller.
Change-Id: I4a9cfc388ec9ecb743d154a114a6db638eac4701
Move it closer to the other MNCC_F_* entries, so that it's more
likely that it gets updated when new flags are added.
Change-Id: If1a12a696b87184c9eee14f475594c317927427b
Related: OS#5282
In c6921e5068, 0x4000 was added to the
possible MNCC field flags, but before this commit, using it would
result in an ERROR of "Unknown MNCC field mask 0x....."
Related: OS#5282
Change-Id: I9e7d224e7f2d6d2824b2466752b6e8c994ac5a3d
This helps to merge similar code from smpp_mirror and smpp_* in follow-up patches.
Related: OS#5568
Change-Id: I8f7ac2c00d16660925dd0b03aa1a0973edf9eb70
By default systemd will execute service with root directory (or home directory for user instance) which might result in
attempts to create files in unexpected place. Let's set it to 'osmocom' subdir of state directory (/var/lib for system instance) instead.
Fixes: OS#5661
Change-Id: I0f942545d9e920ba8a2d8645512ec3414ab27418
Parallel build has been fixed [1] and re-enabled [2] back in 2018.
Change-Id: I13d2d6f3b5ffae390cf429e41bf9035b8c551f66
Related: [1] I5a9d7dbd7b992d322ed0d852ebf8ca2252b51a12 libsmpp34.git
Related: [2] Id41fbcb5a96093eb6c3dc00bcacbd379111ada70 libsmpp34.git
As part of preparation for libosmo-netif migration let's move common SMPP code
into separate build-time library and use it for both smpp_mirror and OsmoMSC
renaming the files if necessary.
While at it we also fix id/password legth limits in smpp_mirror and drop unused
fields from ESME struct.
Related: OS#5568
Change-Id: I61910651bc7c188dc2fb67d96189a66a47e7e8fb
This allows us to drop single-use parameters from osmo_esme to facilitate further code changes.
Related: OS#5568
Change-Id: I34bd4c145b0f6287a323e2350808feb59f1d3187
Having smpp_smsc_stop() called from within smpp_smsc_start() instead of
explicitly inside smpp_smsc_restart() is confusing and could lead to
hard-to-trace bugs. Let's get this fixed first before going further.
Related: OS#5568
Change-Id: I353f5b82c9f5308d93e926538d4ef7e24d0b0339
Some functions act on a struct sdp_audio_codecs but begin with the name
sdp_audio_codec (singular). That's confusing.
Related: SYS#5066
Change-Id: Id87eb350c1f17f8dbf776909824bfa06634c1d04
A problem with SDP fmtp handling is visible in this patch: when cmp_fmtp
is true, we compare fmtp strings 1:1, which is not how things should be
done. The intention is to fix fmtp handling in a later patch.
At least there now is a flag to bypass fmtp comparison altogether.
Related: SYS#5066
Change-Id: I18d33e189674229501afec950aa1c732386455a2
libsqlite3 that ships with some distributions may have secure_delete
activated by default. This means all database records are overwritten
with zeros on DELETE. We don't needs this extra overhead.
Change-Id: I9da6499a38096c8df2025bb9d35ec789864b7c5e
The Binary format changed when libdbi was removed. If we let osmo-msc run on an
unconverted database, the results are unpredictable, certainly undesirable.
Change-Id: I887b6a4374b1c83684f4007e9791ae58bba4e8c1
README.md in-line with that of other osmocom CNI projects:
* markdown syntax
* link to manuals, issue tracker, gerrit contributions, etc.
Change-Id: I98e09e8900c359382e2a90b187f0c6f22a1cf81d
This is meant as a safeguard against users or user equipment which
doesn't set a reasonable validity period. Using this setting, the
SMSC administrator can set a minimum SMS validity period. Any SMS
submitted with lower validity period will be extended to that minimum.
Change-Id: I192528a6f9059d158fa12876a247d61bd7edaec8
Related: OS#5567
Before this patch, we always ignored any SMPP-provided validity period
and used '0' which is now, and means it expires immediately.
As SMPP allows for validity_period of NULL, use 7 days as SMSC default
in such situations.
Change-Id: Iad9f2697f045ed3bc0eb74c3a9730861f82e6c48
Closes: OS#5567
This introduces some VTY settings that determine if delivered
or expired messages should be removed from he SQL database or not.
Change-Id: Id6174875d5c01c40d987077651b27ae1acbcaa93
The pre-historic sms_queue code used to have very strange aspects,
such as having some parameters (max-failure, max-pending) which could
only be sent from the 'enable' node, but not from a config file.
Before adding more configuration parameters, let's clean this up by
introducing a proper VTY config node for the 'smsc'; move the existing
config commands there and add new ones for max-failure and max-pending.
As the sms_queue data structure is only allocated after the config file
parsing happens, we are introducing a new 'sms_queue_config' data
structure. This encapsulates the public readable/writable config
parameters.
Change-Id: Ie8e0ab1a9f979337ff06544b9ab3820954d9804a
As we're using WAL mode, it is not neccessary to use synchronous=FULL
but rely on synchronous=NORMAL mode while still guaranteeing database
consistency.
To do this, we can fix the typo in one of our two PRAGMA statements,
and remove the other.
See https://www.sqlite.org/pragma.html#pragma_synchronous for the
sqlite3 documentation on that topic.
Change-Id: Ie782f0fe90e7204c4d55cdb3948b728c348367d1
Closes: OS#5566
RelateD: OS#5564, OS#5563
The choice of libdbi was one of the biggest early mistakes in (back
then) OpenBSC development. A database abstraction library that
prevents you from using proper prepared statements. Let's finally
abandon it and use sqlite3 directly, just like we do in osmo-hlr.
I decided to remove the database migration code as it would be relatively
cumbersome to port all of it to direct sqlite3 with prepared statements,
and it is prone to introduction of all kinds of errors. Since we don't
have a body of older database files and comprehensive migration tests,
it is safer to not offer migration code of uncertain quality. The last
schema revision (5) was introduced 5 years ago in 2017 (osmo-msc
v1.1.0), so it is considered an exceptionally rare case. People can
install osmo-msc 1.1.0 through 1.8.0 to upgrade to v5 before using
this new 'direct sqlite3' version of osmo-msc.
Change-Id: Ia334904289f92d014e7bd16b02b3b5817c12c790
Related: OS#5559, OS#5563, OS#5564
ERROR: files left in build directory after distclean:
./sms.db-shm
./tests/sms.db-shm
./tests/sms.db-wal
./sms.db-wal
Change-Id: Iecd380f598edbd1635361e4c340d54d092739919
Both callers would immediately execute sms_pending_add() after
a successful sms_pending_from(); we can merge those two functions.
Change-Id: Iaf37234b3caafd568dd4fe17739be9ec842c2a8d
This avoids every caller from manually having to remember to
increment the count, the stat_item and llist_{add,del}.
Change-Id: Ice4c73727ef2d7e4118f0ef5fe24cae943c7528f
If the ESME has been disconnected (dead socket) but still is
in memory (other users hold a use count), we shouldn't enqueue
messages to the write queue.
This prevents messages like
DSMPP write_queue.c:112 wqueue(0x7f8bc392f6e0) is full. Rejecting msgb
Change-Id: I10a270f1d555782be272f4d78da43190618a9950
Closes: OS#3278
When the SMPP code free's an ESME it also free's the related write_queue
and the osmo_fd contained therein. So if this happens while we are
in esme_link_read_cb(), we must return -EBADF to make
osmo_wqueue_bfd_cb() of libosmocore avoid further accessing related
memory.
Change-Id: I441d3b05c2f2556c530783a7f66c73adf6d845a1
Closes: OS#5565
This should give us some more insight into what is happening inside
the MSC's VLR in terms of number of subcribers, rate of successful /
unsuccessful GSUP procedures, etc.
Related: OS#1974
Change-Id: I681bcfc1875363478190151f2931cad197323ee8
The function vlr_subscr_rx_imsi_detach() implies that an explicit IMSI
DETACH was received. However, that same function was called in other
situations such as timer expiration or GSUP CANCEL.
Let's clean this up by splitting the function into two parts.
No logical change is introduced to the VLR in this patch.
Change-Id: Iffc02f3062ad591ca372a3c6d866066cf63a8830
It makes the code much more readable if there's at least a one-liner
documenting each function (and struct member).
Change-Id: I6d239369cabdf1703eba7f3606b46b95cbbb1ea7
Looking at 'perf top' of osmo-msc under load shows that there's a
significant amount of time spent in terms of locking (mutex,...)
which is useless as osmo-msc is a single-threaded application.
Unfortunately libdbi doesn't provide a mechanism to perform
sqlite3_config(), so we have to do it directly here, introducing an
explicit build-time dependency (and linkage) to libsqlite3.
Related: OS#5559
Change-Id: I5bbea90d28b6d73b64b9e5124ff59304b90a8a75
The existing rate counters per-minute/hour/day values were never
computed as the related timer was never started...
Change-Id: I27282051a6da5d1e1a25981712fbe4c4a6378dea
With comments, clarify the code paths where a CM Service use count has
not yet been placed on the conn (just send CM Service Reject) and where
the use count is placed (decrement count on CM Service Reject).
Place the CM Service use count slightly earlier:
- it is then correctly present when checking the mobile identity in
cm_serv_reuse_conn(), avoiding the crash reported in OS#5532.
- there is only one place incrementing the use count instead of two.
Related: OS#5532
Change-Id: I6c735b79b67108bcaadada3f01c7046e262f939b
When using 'check_PROGRAMS', autoconf/automake generates smarter
Makefiles, so that the test programs are not being compiled during
the normal 'make all', but only during 'make check'.
Change-Id: I13b519e61ca0d9ce038e8c989ddac012de4a6c61
This happens if for instance an HNBGW drops the RAB-AssignmentRequest
and does nothing with it.
call_leg.c:348:15: runtime error: member access within null pointer of type 'struct rtp_stream'
Related: OS#5401
Change-Id: I67d2d5b2dd3b367c34f929d63c056306ec001431
We need to set the codec as present in order for
msc_a_up_call_assignment_complete() to configure properly the CN-side of
he leg with the IUFP codec, which should be the desired default in order
to avoid transcoding.
Change-Id: Ib8086462239e2df748cf47ea7b37a07f1f3b85a8
RAB Assignment Complete contains no codec info, hence
assignment_complete.codec is not set and
assignment_complete.codec_present is false.
As a result a wrong value is passed to rtp_stream_set_codec.
This fixes osmo-msc sending "a=rtpmap:112 AMR/8000/1" during MDCX in the
RAT-side connection of the call leg after having properly sent
VND.3GPP.IUFP/16000 in CRCX.
Change-Id: Ic028d35893d29f7d72f22f82ef89695229c9b01b
This way the MGW knows it has to handle IuUP in that connection (answer
IuUP Initialization, etc.).
Depends: osmo-mgw.git 1de5ed6f979bd4c1380789c9a82f8e396f05c5f8
Change-Id: I7aca671e00ed27ac03f0d106b5a6b665a9bed4c1
Remove the paragraph about writing to the Free Software Foundation's
mailing address. The FSF has changed addresses in the past, and may do
so again. In 2021 this is not useful, let's rather have a bit less
boilerplate at the start of source files.
Change-Id: I1b68e0aa26d81fbfe26abaa287d2bd5eec2cfd0f
On the protocol level, it's impossible to indicate UEA0 together
with the other algorithms. The encryption is either a) disabled,
so the Encryption Information IE is not present, or b) enabled,
so the Encryption Information IE indicates UEA1 and/or UEA2.
Because of that, the ranap_new_msg_sec_mod_cmd2() would fail to
generate the RANAP PDU if the given bitmask has the UEA0 bit set.
Fixes: 505a94a610 ("Make UTRAN encryption algorithms configurable")
Change-Id: I3271d27c09fc8d70a912bce998ceffbce64dd95e
Function msc_i_ran_enc() calls msc_role_ran_encode(), but unlike the
other callers of this function it does not free() the encoded message.
A simple solution would be to call msgb_free(), like it's done in
the other places. But a more elegant solution is to modify function
msc_role_ran_encode(), so that it attaches the msgb to OTC_SELECT.
This way there is no need to call msgb_free() here and there.
This change fixes a memleak observed while running ttcn3-msc-test.
Change-Id: I741e082badc32ba9a97c1495c894e1d22e122e3a
Related: OS#5340
Ciphering is optional in both GERAN and UTRAN, however for the later
it's *required* to enable integrity protection for the signalling.
Thus we must always send Security Mode Command in UTRAN, even in
case if ciphering is disabled (UEA0) in the configuration.
The actual decision whether to send CMC/SMC or not is taken in:
* vlr_access_req_fsm.c / _proc_arq_vlr_node2(), and
* vlr_lu_fsm.c / vlr_loc_upd_post_auth().
depending on the value returned by is_ciph_required(). Let's
rename this function to is_cmc_smc_required() and ensure that
it always returns true in UTRAN.
This change fixes the Iu test cases in ttcn3-msc-test.
Change-Id: I6205f13453eff7afbf25e013d72ae98a78fcd31b
Fixes: OS#5333
This function is never called when ciph_required is false, so
there is no need for an additional check in this function.
Change-Id: I900ddd5f1882f8cee234ab1074adcf25830a092c
If a MO SMS gets successfully routed through SMPP, we return early
in gsm340_rx_tpdu() and leak a chunk of type 'struct gsm_sms'.
Change-Id: I8a745d747f06baa7109418ffe600b27b3c0a5228
Fixes: [1] Ic34d398e0a850856e20380ae35e5c2ae5e3c539b
Fixes: OS#5334
RANAP Security Command can include an encryption IE. If it includes
it the RNC can still ignore it (e.g. unsupported encryption) and
return the Security Command Complete with an choosen encryption IE:
"no encryption".
Validate the encryption element and ensure the encryption is included in
the encryption mask.
Closes: OS#4144
Change-Id: Icfc135c8b8ae862defe7114db492af600c26407f
Allow the user fine-grained control over which UMTS encryption
algorithms are permitted, rather than always permitting UEA1 and UEA2
or neither.
This brings the handling of UEA in line with the handling of A5 for
GERAN.
Change-Id: I91f9e50f9c1439aa19528f887b83ae9de628fcfd
Closes: OS#4144
Depends: osmo-iuh.git I6d2d033b0427bdc84fee61e0f3cb7b29935214bf
The existing code allowed the user to configure UMTS encryption in the
vty, but we never actually passed this information down to RANAP. As a
result, the RAN had no chance of ever enabling encryption on the air
interface.
Change-Id: Ieaaa6b23b7337b7edb902fad8031e195e0c5e9d2
Related: OS#4144
Do not turn some compiler warnings into errors by default. This patch
was added before --enable-werror was available.
We build with --enable-werror during development and in CI. If the code
is built with a different compiler that throws additional warnings, it
should not stop the build.
This reverts commit 34f012639d.
Related: OS#5289
Change-Id: Ideff462157a034e053e5e7049605dd8d24440905
Using *unpacked* 'struct osmo_gcr_parsed' in the MNCC PDUs makes
the protocol even more complicated than it currently is, and
moreover complicates implementing MNCCv8 in the ttcn3-sip-test.
Replace 'struct osmo_gcr_parsed' in 'struct gsm_mncc' with a
fixed-length buffer, which is supposed to hold the Global Call
Reference encoded as per 3GPP TS 29.205.
Indicate presence of GCR using the MNCC_F_GCR flag.
Change-Id: I259b6d7e4cbe26159b9b496356fc7c1c27d54521
Fixes: I705c860e51637b4537cad65a330ecbaaca96dd5b
Related: OS#5164, OS#5282
This commit is largely based on work by
Max <msuraev@sysmocom.de>
Adds LCLS parameters for A-interface transactions
This commit also adds a vty option to facilitate globally
disabling LCLS for all calls on this MSC.
Add a global call reference (GCR) to MNCC and therefore
bump the MNCC version to version 8. (This commit has to be
merged at the same time as the corresponing commit in the
osmo-sip-connector for mncc-external use.)
Depends: osmo-sip-connector Id40d7e0fed9356f801b3627c118150055e7232b1
Change-Id: I705c860e51637b4537cad65a330ecbaaca96dd5b
If the remote ESME would send us 0xffffffff as length field, don't try
to allocte 4GB of memory, but bail out.
Change-Id: I561f75210811826de06ea1673eca1df24faaa210
Fixes: CID#240738
The log output of libosmo-mgcp-client has changed. This change causes
the unit tests to fail because the log output does not match anymore.
Lets disable the DLMGCP log output since it is of minor importance
for VLR testing anyway.
Change-Id: Id197e4ab9ba12e284299ef520edee9c362513bf1
Related: SYS#5091
During a recent pcap trace, it was spotted that subscriber coming from
SGs had a use count with 16 "SGs" items, and later it incremented to 17.
Further investigation shows that the related use_count item was never
decreased, meaning every time an SGs-LU was sent by the MME, the item
was incremented further and never decremented.
Let's rename the item to be referenced while in LU, and then decremented
when LU is done. At that time, either the LU was accepted and the
subscriber object has a use_count item "attached", or it was rejected
and we already sent the reject messages, so we are fine deleting it if
needed.
Related: SYS#5337
Change-Id: I22c386f02ffa57428f700b003cc2cf23133598d0
it was recently observed in a pcap trace with gsmtap_log that the
use_count contained a "vlr_sgs_imsi_detach" item despite no related
message was seen near by. Further investigation shows that there's an
unbalanced get+put code path, introduced by an early return added to fix
another issue.
related: SYS#5337
Fixes: 0803d88d9a
Change-Id: I91ae956e50fca2f4d0e1d145d60ccb0ebfb409e9
Set order of states in the same order as they appear in the specs (see
chapter 4.2.2 mentioned above the enum).
Furthermore, from FSM state transition point of view it also makes sense
to put them in this new order, since one should pass through
SGS_UE_ST_LA_UPD_PRES to get to SGS_UE_ST_ASSOCIATED.
Change-Id: Ia9216965e9f30caedffa3cb53d14da7f7fd37b4e
The manual seems to lack a section about how the MGW is set up. In the
osmo-bsc manual we have a "Configure MGCP to connect to an MGW" section
under the "Configure primary links" section. We should have the same
thing in the osmo-msc manual as well.
Change-Id: I5501739e63860c436ff606bc2758b495258cd2b9
Depends: osmo-mgw I47e7ff858d5067b46d52329be5f362ff61c0dff8
Will be used by I6fa37d6ca9fcb1637742b40e37b68d67664c9b60
"implement CM Re-Establish for voice calls"
Related: SYS#5130
Change-Id: I5291d098a02268bd1c2e30195ae61e4a13e8709c
As seen in a running osmo-msc:
"vlr_access_req_fsm.c:153
msc_a(IMSI-....:MSISDN-...:TMSI-0x...:GERAN-A-8:CM_SERVICE_REQ){MSC_A_ST_RELEASING}:
Event MSC_A_EV_CN_CLOSE not permitted"
Also seen in several unit tests, which need update.
The action event handler for that state is actually already
expecting/handling the event by ignoring it, so we should allow it.
Change-Id: I4d30cffab693529aab3ba736419dec116a4dd7ef
Forward the Kc128 key to the new BSS in BSSMAP Handover Request.
Depends: Ieb6e43eef9e57281d54d4b7c63664668df5aef3e (libosmocore)
Change-Id: Id5ce995a741c8e469a50a0c46e53c06a2378bb7e
Add A5/4 to the internal mask of allowed algorithms.
(Not actually working yet, A5/4 implementation follows in other
patches.)
Related: SYS#5324
Change-Id: I5b46aaa8579f8d069ca39caf996a8795ffe63dd7
Use new API in Cipher Mode Command to prepare for A5/4 support.
Depends: Ib3906085e0c6e5a496a9f755f0f786238a86ca34 (libosmocore)
Related: SYS#5324
Change-Id: Ib238d367b8d5d07b6ab4cb2e48fbf4ce22ca4476
Since recently, osmo-bsc behaves strictly as per specs, meaning it will
only send the "Cell selection indicator after release of all TCH and SDCCH IE"
in RR Channel Release iff:
* "Last Used E-UTRAN PLMN Id" was received in the CommonID sent MSC->BSC
* "Last Used E-UTRAN PLMN Id" was received insider "old BSS to new BSS Information"
in the HandoverRequest sent MSC->BSC.
On the other hand, CSFB_Indicator from ClearCommand MSC->BSC is nw
ignored and not taken into account.
Hence, let's update osmo-msc to also behave correctly by sending the
Last Used E-UTRAN PLMN ID at CommonID tx time to avoid regressions in
CSFB support when running against newer osmo-bsc.
Let's keep sending the CSFB Indicator in ClearCommand as we used too, in
order to keep compatibility with older BSCs (as per spec).
Related: SYS#5337
Change-Id: Ic5f175b179973d0a50d94f00e15f5a3e332605fc
Add the missing runtime dependency to the sqlite3 driver of libdbd.
The library does not provide a pkgconfig file, so using "pkgconfig(...)"
as done in the BuildRequires is not possible. Write both the OpenSUSE
and CentOS name with an if..else.
Fixes:
<0009> db.c:648 Failed to create database connection to sqlite3 db 'sms.db';
Is the sqlite3 database driver for libdbi installed on this system?
Change-Id: Ia972944c300aecbb6ec460b2362aabff459baefd
Let's disable category here since we don't care about its formatting here.
In any case, every test relying on logging output validation should
always explicitly state the config to avoid issues in the future if
default values change.
Change-Id: I089c0001fc75e81558c3e860827e4d434cf1eab3
Related: OS#5034
Calling gsm48_cc_tx_release() before mncc_release_ind() has a side
effect: the former may change CC state to GSM_CSTATE_RELEASE_REQ.
This makes the later send MNCC_REL_CNF instead of MNCC_REL_IND, so
if one of the call leg disconnects due to RF failure, the other one
will not be terminated correctly.
Makes both TC_{mo,mt}_call_clear_request TTCN-3 test cases pass.
Change-Id: I3ad4a99757878de3796027325627c87d9a4e93f1
Related: Id16969fe0de04445d1320a96d35cf1d48cc8cf09
Related: SYS#5340
The msc_vlr_tests verify whether any of the tests run contain msgb or
talloc memory leaks. So far they did so by fixating a specific number of
talloc blocks, which may break by library implementations changing.
Instead, verify that the test leaks no allocations by comparing talloc
blocks before and after each test.
When a leak is detected, print the full talloc report to stderr, which
makes the expected output mismatch the actual output and fails the test.
Related: OS#4311
Change-Id: I8537fa76d460c951302932a1bad4299f7fe398c9
Previous code relied on abort() switching sigaction to SIG_FDL +
retriggering SIGABRT in case the signal handler returns, which would
then generate the coredump + terminate the process.
However, if a SIGABRT is received from somewhere else (kill -SIGABRT),
then the process would print the talloc report and continue running,
which is not desired.
Change-Id: Iff66eea9ee70850a4d038ece1d8473457023e1ee
Fixes: OS#4865
osmo-msc is pretty useless without osmo-mgw these days. Let's not
make it a strong dependency, as the mgw could of course be running
on different machines.
Change-Id: I76c1bf30c733cf2fd596a8971ccb8bac4220be66
The function gsm48_rx_cm_reest_req() is the only one where the return
code of osmo_mobile_identity_decode_from_l3() is not checked, lets check
it here too.
Change-Id: I37981205870b094b3a40a20197461208daa62698
Fixes: CID#211037
We may never be able to deliver this SMS if it depends on the ESME, as we will
not resubmit the SMS to the ESME. Better to reject it at this time and have the MS
try again later.
Change-Id: I2c50904349dd4ed229b60b8468d776b817c0bd44
Related: OS#4740
The struct gsm_mncc which is created and populated in mncc_call_tx_setup_ind
casted to a union mncc_msg* pointer. This leads to a memory overrun
in mncc_call_tx because the union mncc_msg is larger then the gsm_mncc struct.
To fix this, lets just declare a union mncc_msg and populate the signal
member inside it. This can be handed over to mncc_call_tx. The data in
it will look the same, except that the memory will have the proper
lenght (longer).
Change-Id: Ifff28b3375d6bd5e4f837f25c46736952f7bfa9b
Fixes: CID 214330
Timer X1 is not defined in libosmo-mgcp-client, so this tdef had no effect.
Change this to X2427.
(libosmo-mgcp-client recently moved T2427001 to X2427.)
(X2 is still used in call_leg.c itself)
Related: OS#4539
Related: If097f52701fd81f29bcca1d252f4fb4fca8a04f7 (osmo-mgw)
Change-Id: I9804fdb2c24f49910f2386e3788bd1107b8ebc40
In this case we are fine with simply updating test result because anyway
ABI breakage in some libosmo-mgcp-client structs was needed, so new
versions of osmo-msc will require new versions of libosmo-mgcp-client.
Change-Id: I1fbdb95f71d3b9a2dc88e1ba79892ae16485aa99
So far, the cmdline argument was the only way to set a database file.
Add a similar config to VTY as 'msc' / 'sms-database'. The cmdline arg is stronger
than the 'database' cfg item. DB is not reloaded from VTY command.
Change-Id: I18d954c30fcceb0b36a620b927fd3a93dcc79f49
"127.0.0.1" is changed to "localhost" to let local NSS decide whether to
use IPv4 or IPv6. In newish systems, IPv6 ::1 will be selected since
IPv6 takes precedence over IPv4.
Similarly, the default source addr needs to be changed from NULL to "localhost"
since for some yet unknwon reason, getaddrinfo(AF_UNSPEC, NULL) returns
first IPv4 "0.0.0.0" and later "::", which is inconsistent with
getaddrinfo("localhost") result, resulting in src=IPv4(0.0.0.0) and
dst=IPv6(::1), which is incompatible and will fail. In any case, since
the default remote address is a local one and it's the client side,
there's no real logical change since the kernel would anyway should have
taken a local address anyway.
Change-Id: I05a5c792ab1d053c6f38ba36d4b9fa6db293fbd0
We're already sending the RANAP CommonID message to the RNC,
let's do the same using BSSMAP CommonId towards the BSC. This
way the BSC knows about the IMSI of the served subscriber, which
is very useful for logging/debugging.
Change-Id: I2552736477663adb250c55728093500e8ae83ebb
Closes: OS#2969
Depends: libosmocore.git I353adc1aa72377f7d4b3336d2ff47791fb73d62c
Otherwise, each time the 3GPP TS 44.014 MS test commands (TCH loop)
are invoked, both subscriber_mstest_{close,open} functions add +1
to the subscriber's reference count, but never revoke it.
Change-Id: I0cefa5b5a0cb712080ba2afd322db329f19608e3
This byte is redundant, and must not be allocated in this function.
A consequence of this error is that the MS alwats interprets the
"Sub-channel" IE as test loop A regardless of the specified type.
Here is an example of malformed Close TCH loop (type C) message:
0f 00 00 04
x. .. .. .. - Skip indicator (see 3GPP TS 24.007)
.x .. .. .. - Protocol discriminator (see 3GPP TS 24.007)
.. xx .. .. - Message type (CLOSE_TCH_LOOP_CMD)
.. .. !! .. - (!) Redundant byte from create_gsm0414_msg()
.. .. .. xx - (!) The actual "Sub-channel" IE (loop C, X=0)
Change-Id: Ia47225b884439dcd43be307e7351994e55fcd50d
So far, by failing to initialize the cause value, we always send a Clear
Command cause == 0, which actually means "Radio Interface Message Failure".
This is seen in all my logged network traces of osmo-msc lab testing.
"Call Control" seems to be the only cause value that remotely fits a normal
release procedure, even if it was not voice call related, see 3GPP TS 48.008
3.2.1.21.
Related: OS#4664
Change-Id: I1347ed72ae7d7ea73a557b866e764819c5ef8c42
Move 'doc' subdir further down to "make sure" the osmo-msc binary is built
before the docs.
Remove msc_vty_reference.xml from the source tree.
In manuals/Makefile.am use the new BUILT_REFERENCE_XML feature recently added
to osmo-gsm-manuals, and add a build target to generate the XML using the new
osmo-msc --vty-ref-xml cmdline switch.
Depends: I613d692328050a036d05b49a436ab495fc2087ba (osmo-gsm-manuals)
Change-Id: Ib872e7979c5b5a9da1347a3f326307844cf76536
new_id_ptr should be passed as NULL if encoding the TMSI failed, so initialize
it accordingly.
Also add some bloat to better handle the case of an encoding error, even though
from code analysis that should not be possible here: there is enough buffer,
the MI is a TMSI encoded from a uint32_t...
The problem was introduced by Idfc8e576e10756aeaacf5569f6178068313eb7ea, before
which new_id_len was always 0 when no TMSI was present.
Related: CID#210894
Change-Id: I800c5dca3fdbdedf70a64d9fd5a1bdfd1397f431
ran_peer.c is not the proper place to parse messages, because it should be RAN
agnostic. All parsing and encoding belongs in ran_msg_a.c and ran_msg_iu.c.
Move the Osmux TLV parsing into the is_reset_msg op: add supports_osmux
out-parameter (and add a logging fi pointer). To be able to modify msg->l3h,
also make the msgb arg non-const.
In ranap_is_reset_msg(), always return non-support for Osmux.
In bssmap_is_reset_msg(), return 0 if no TLVs were parsed, 1/-1 if an Osmux TLV
was present/not present.
Update the osmux support flag directly where the ConnectionLess message is
received, so that there is only one place responsible for that.
Related: OS#4595
Change-Id: I1ad4a3f9356216dd4bf8c48fba29fd23438810a7
Adopt the same way to run manual vty transcript tests as in
osmo-bsc/test/Makefile.am.
There are different ways to select a specific test to run in osmo-bsc and here
in osmo-msc. The osmo-bsc way is more convenient when building outside the src
tree, because it does not need the full absolute path of the test file.
Change-Id: If1e2abfa321a5e9fb60358d1f0e4e448b33184af
As soon as the subscriber is authenticated, update the VLR entry with the
MSC-A's full CGI, including the Cell Id received from the Complete Layer 3
Information.
Thus the Cell Id will be shown by vty 'show subscriber cache' and 'show
connection'.
This is tested by osmo-ttcn3-hacks Ie410714a96353f74a52a104c56fa0a08683e0004.
Related: OS#4627
Change-Id: Iee1781985fb25b21ce27526c6a3768bf70d4dc9a
For 'show subscriber cache', we print vsub->cgi. For 'show connection', it
makes more sense to print msc_a->via_cell.
This is tested by osmo-ttcn3-hacks Ie410714a96353f74a52a104c56fa0a08683e0004.
Related: OS#4627
Change-Id: I194271af2acb37b4f8cc2d106ab2fd2b0d443589
Add only a long option to not clutter the cmdline namespace.
To add a long option without a short letter is slightly complex: use the 'flag'
and 'val' mechanism as in 'man 3 getopt' to write an option index to
long_option.
Make sure that all VTY commands have been added before parsing cmdline options:
move various VTY init further above. For msc_vty_init(), the global msc_network
already needs to be allocated, so also move that.
Depends: Ic74bbdb6dc5ea05f03c791cc70184861e39cd492 (libosmocore)
Change-Id: I9146d5a44427509265420f52ae6540ad93eb14fc
When msc_ho_send_handover_request() generates the HANDOVER REQUEST
message, it does not populate the call_id struct member.
In ran_msg_a.c the struct member call_id is used, but the
call_id_present flag is not set, which also prevents the call_id being
added to the message
Change-Id: I6b1b55b3f5a3092d9557dc2512020c766a9ff744
Related: OS#4582
The BSSMAP message ASSIGNMENT REQUEST may contain an optional CALL
IDENTIFIER IE. While this IE is optional some BSC implementions may
require it.
Change-Id: I4288f47e4a6d61ec672f431723f6e72c7c6b0799
Related: OS#4582
This patch served for a manual testing counterpart for osmo-bsc to implement
MSC pooling.
This enables a basic MSC pooling setup, but for a production setup, osmo-msc
would still lack various features related to unloading subscribers to another
MSC as explained in 3GPP TS 23.236.
Change-Id: Iafe0878a0a2c8669080d757b34a398ea75fced36
when the VTY write the config file ist prints the configuration line
for emergency-call in network and in msc, however the presence of the
configuration line in network leads to a parsing error on msc startup.
The vty command probably got moved to node msc and it was forgotten
to remove the printing from network.
Change-Id: I4f3dac27723e7852f8f049fcfca5cccdc027734d
Related: OS#4548
There is an invalid Mobile Identity in the msc_vlr_test_gsm_ciph test data.
This became apparent when applying the new osmo_mobile_identity API (in a
following patch). Current Mobile Identity API ignores the error.
Change-Id: Ib1d54c59acc8b716de471ca275f54f9d22da3574
The SPEC file already included a build dependency to libsmpp34, but
then the compilation of osmo-msc didn't actually pass --enable-smpp
along, resulting in binaries without SMPP support - unlike the Debian
binaries, which do contain that part.
Change-Id: I223be7a735e97b32f7c0ff246cf826f109b0f686
The Mobile Identity type is received on the wire, we asserting on its type
constitutes a DoS vector.
Change-Id: I2b2e25ef8e878e91a165018ba49f1609cfb5cbd0
Remove OpenSUSE bug report link, set version to @VERSION@, make it build
with CentOS 8 etc.
Related: OS#4550
Change-Id: If5499e11d872e629a018fc77d5adf5d0cb863d48
From ASAn on gcc 10.1.0:
+=================================================================
+==269368==ERROR: AddressSanitizer: odr-violation (0x559114a5b880):
+ [1] size=4 'asn1_xer_print' /git/osmo-msc/src/libmsc/ran_msg_iu.c:50:5
+ [2] size=4 'asn1_xer_print' /git/osmo-iuh/src/iu_client.c:85:5
+These globals were registered at these points:
+ [1]:
+ #0 0x7f6208d3869a in __asan_register_globals /build/gcc/src/gcc/libsanitizer/asan/asan_globals.cpp:341
+ #1 0x55911456d221 in _sub_I_00099_1 (/build/new/tmpdir/osmo-msc/tests/msc_vlr/msc_vlr_test_hlr_timeout+0x48d221)
+ #2 0x5591145e8e9c in __libc_csu_init (/build/new/tmpdir/osmo-msc/tests/msc_vlr/msc_vlr_test_hlr_timeout+0x508e9c)
+
+ [2]:
+ #0 0x7f6208d3869a in __asan_register_globals /build/gcc/src/gcc/libsanitizer/asan/asan_globals.cpp:341
+ #1 0x7f6207d8db91 in _sub_I_00099_1 (/build/new/out/lib/libosmo-ranap.so.3+0x47db91)
+ #2 0x7f62096eb0f1 in call_init.part.0 (/lib64/ld-linux-x86-64.so.2+0x110f1)
+
+==269368==HINT: if you don't care about these errors you may set ASAN_OPTIONS=detect_odr_violation=0
+SUMMARY: AddressSanitizer: odr-violation: global 'asn1_xer_print' at /git/osmo-msc/src/libmsc/ran_msg_iu.c:50:5
+==269368==ABORTING
Related: OS#4556
Change-Id: I702e9748eaaf2279c3764ba67f80f00ae9f2526f
New define is available since libosmocore 1.1.0, and we already require
1.3.0, so no need to update dependenices.
Let's change it to avoid people re-using old BSC_FD_* symbols when
copy-pasting somewhere else.
Change-Id: Ifc89fffac0443d94f3e49555684975b293ef90fb
The example configs suggest to use a random ip-address as MGW address.
Lets use a loopback address here. This will suit the usual case where
MGW and MSC run together on the same machine.
Change-Id: Ie2b2094fdcfed45353d9ba22cb07eed626fd143c
As pointed out at https://github.com/libexpat/libexpat/issues/312
libtool does not play nice with clang sanitizer builds at all.
For those builds LD shoud be set to clang too (and LDFLAGS needs the
sanitizer flags as well), because the clang compiler driver knows how
linking to the sanitizer libs works, but then at a later stage libtool
fails to actually produce the shared libraries and the build fails. This
is fixed by this patch.
Addtionally LD_LIBRARY_PATH has no effect on conftest runs during
configure time, so the rpath needs to be set to the asan library path to
ensure the configure run does not fail due to a missing asan library,
i.e.:
SANS='-fsanitize=memory -fsanitize-recover=all -shared-libsan'
export CC=clang-10
ASANPATH=$(dirname `$CC -print-file-name=libclang_rt.asan-x86_64.so`)
export LDFLAGS="-Wl,-rpath,$ASANPATH $SANS $LDFLAGS"
Change-Id: I17d95c416e26dae6ca8bec57df01d3e7b7061058
Do not crash when a Paging Response could not be associated with a VLR
subscriber.
Related: OS#4449
Change-Id: Ie117949dd6da86afaa1a0a6ac57bf2111f6cff43
The problem is that osmo_rat_type_name() calls get_value_string(),
so we first cast -1 to 'const enum osmo_rat_type' and then to
'uint32_t'. Let's rather use OSMO_RAT_UNKNOWN.
Found by GCC with -Wextra in CFLAGS:
warning: operand of ?: changes signedness from ‘int’ to
‘const enum osmo_rat_type’ due to unsignedness
of other operand [-Wsign-compare]
Change-Id: I63ba355102d3cc035ba90121e06aba7cf1776aa0
We unconditionally use logging level of the parent FSM anyway.
All callers of auth_fsm_start() always pass fi->log_level.
Change-Id: If2fdf2564eb56d3d94ec3800bdcb0aabcad4e48d
Since the split of OsmoNiTB, OsmoMSC does not deal with the radio
access network directly. Therefore the only purpose of T3212 is to
control subscriber expiration in the local VLR. The timeout value
indicated in System Information Type 3 needs to be configured
separately in the BSC/RNC.
This means that we don't need to store it in deci-hours anymore.
Let's move T3212 to the group of VLR specific timers, so it can
be configured and introspected using the generic 'timer' command,
and deprecate the old '[no] periodic location update' command.
It should be also noted that in the old code subscriber expiration
timeout was actually set to twice the T3212 value plus one minute.
After this change, we apply the configured value 'as-is', but
keep the old behaviour for 'periodic location update' command.
Change-Id: I9b12066599a7c834a53a93acf5902d91273bc74f
These timers so far were implemented as a list of unsigned integers,
which has never been initialized to any reasonable defaults. Since
they are used as state timeouts in several FSMs, we might end up
staying in some state forever.
Let's migrate to generic osmo_tdef API and use default values from
table 11.2 of 3GPP TS 24.008. This way the user can introspect and
change their values from the VTY / configuration file.
Change-Id: Ia8cf98da0aea0e626c5ff088a833d7359c43847f
Related: OS#4368
This change introduces several new VTY commands letting the user
a possibility to introspect and reconfigure some of the existing
timers implemented using libosmocore's osmo_tdef API.
At the moment this covers the following timers:
- MGW specific timers:
- X1 - MGCP response timeout,
- X2 - RTP stream establishing timeout,
- RAN specific timers (same names for GERAN and UTRAN):
- X1 - Authentication and Ciphering timeout,
- X2 - RAN connection release sanity timeout,
- X3 - Handover procedure timeout.
The following commands are introduced:
- 'enable' node:
- show timer [(mgw|mncc|sccp|geran|utran|sgs)] [TNNNN]
- 'config-msc' node:
- timer [(mgw|mncc|sccp|geran|utran|sgs)] [TNNNN] [(<0-2147483647>|default)]
Both MNCC and SCCP related timer definitions are empty at the
moment. Achieved by using osmo_tdef_group API of libosmovty.
Change-Id: I6024c104b6101666c8aa1108a043910eb75db9a5
Related: OS#4368
There was one libmsc commit to openbsc that was
thus far missing in osmo-msc.
This commit completes the work on delayed response
from an ESME. Without this patch, the SMR sends
an RP-ACK to the mobile station, and subsequently a
DELIVER_SM_REPONSE from the ESME provokes either a second
RP-ACK, or an RP-ERROR; both of which result in
"unhandled at this state (IDLE)" from the SMR
After this patch, we have two things corrected:
1) RP-ERROR respects Deliver-SM error cause.
2) No more "unhandled as this state" error from the SMR
Extract from original commit message:
--------
libmsc: annotate esme route in the sms object from deliver_to_esme()
Annotate this esme route, so we can use it to return -EINPROGRESS to
skip sending premature RP-ACK to the mobile station, in case we're
handling sms routes through SMPP.
--------
Fixes: #OS4351
Change-Id: Ic34d398e0a850856e20380ae35e5c2ae5e3c539b
This commit also, (for what it is worth) removes a
difference to the same file in openbsc, which I found
while looking for changes that affected SMPP delivery.
This is essentially a "forward-port" of [1]
[1] https://gerrit.osmocom.org/#/c/openbsc/+/3899/
Change-Id: I350c19f5bb70b2656171c096334c2ee83f49df7e
d34ed5768c introduced
comparison of GSM411_RP_CAUSE_MO_NUM_UNASSIGNED with
GSM48_CC_CAUSE_UNASSIGNED_NR
For consistency lets use the GSM411_RP constants
in SMS related code.
Change-Id: Ie54966560f66d2dcde905feb2eb19ef90406acd1
During the last congress, we have noticed that OsmoMSC crashes
on receipt of malformed MM Identity Response messages:
BSSAP
Message Type: Direct Transfer (0x01)
Data Link Connection Identifier
00.. .... = Control Channel: not further specified (0x0)
..00 0... = Spare: 0x0
.... .000 = SAPI: RR/MM/CC (0x0)
Length: 11
GSM A-I/F DTAP - Identity Response
Protocol Discriminator: Mobility Management messages (5)
.... 0101 = Protocol discriminator: Mobility Management messages (0x5)
0000 .... = Skip Indicator: No indication of selected PLMN (0)
01.. .... = Sequence number: 1
..01 1001 = DTAP Mobility Management Message Type: Identity Response (0x19)
Mobile Identity - Format Unknown
Length: 8
.... 1... = Odd/even indication: Odd number of identity digits
.... .111 = Mobile Identity Type: Unknown (7) <-- This makes OsmoMSC crash
[Expert Info (Warning/Protocol): Unknown format 7]
[Unknown format 7]
[Severity level: Warning]
[Group: Protocol]
The value '111'B is not a valid Mobile Identity type, and shall be
considered as reserved according to 3GPP TS 24.008, section 10.5.1.4.
Later on it was discovered that '000'B also crashes OsmoMSC in the same way.
The crash itself is provoked by OSMO_ASSERT(0) in vlr_subscr_rx_id_resp().
Let's keep that assert in there, and make sure that:
- on receipt of MM Identity Response, Mobile Identity type
matches the one in MM Identity Request;
- on receipt of RR Ciphering Mode Complete, Mobile Identity
contains IMEI(SV) if present.
Change-Id: Ica4c90b8eb4d90325313c6eb400fa4a6bc5df825
TTCN-3 test case: I62f23355eb91df2edf9dc837c928cb86b530b743
Fixes: OS#4340
We shall not include additional BCD length octet into the value part
of SM-RP-OA (Originating Address) IE. Instead, there should be
ToA/NPI header (1 octet).
Since we do not get ToN/NPI fields from the VLR/HLR, let's assume
the following default values:
1... .... = Extension: No extension
.001 .... = Type of number: International (1)
.... 0001 = Numbering plan: ISDN/telephone (E.164/E.163) (1)
Change-Id: I0f32e2af0ed2d2fea6addf45efbdfee120c2425d
TTCN-3 test case: Ib467eeca6439bc6cce72293fbb5bb48f6d233db9
Related: OS#4324
Make build and external tests work with python3, so we can drop
the python2 dependency.
This should be merged shortly after osmo-python-tests was migrated to
python3, and the jenkins build slaves were (automatically) updated to
have the new osmo-python-tests installed.
Related: OS#2819
Depends: osmo-python-tests I3ffc3519bf6c22536a49dad7a966188ddad351a7
Change-Id: I53ccde96dd3785098df0f7d693c504c8b8302e90
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
Please note that counter "sms:delivered" assumes "Delivered MT SMS",
but actually counts total number MT SMS delivery attempts. This
change describes its _actual_ (erroneous) behaviour.
Change-Id: I081cf962ce2658ceab02699f3cdee19658d00939
Related: OS#4273
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
Substantial parts of the CC / MNCC call establishment were so far completely
missing from the msc_vlr_test_call.c tests. With my new insights on CC and MNCC
procedures, complete the tests.
Root reason: since I am going to re-order the sequence of events to enable
codec negotiation via SDP in MNCC, I want to have comprehensive tests of the CC
procedures to see the effect as diffs in the test output.
Change-Id: Ie995e264eb1e3dd9558a1753ff6f9b55c1d084e1
Use of this flag was dropped when adding inter-BSC and inter-MSC Handover
support, I forgot to remove it.
Change-Id: I5ec78e30eb36fbe78a3f7c46bfa44af5a4eb7bf2
Add voice_call_full.msc, generated from a real 2G<->3G voice call log fed to
msc_log_to_ladder.py.
The idea is to document how the voice call sequence of events changes in
upcoming patches.
Change-Id: I8a907d6a4ece1f3ad78da75a8c3e3e76afd5418d
Add script that reads in an osmo-msc log output and extracts the interesting
information for displaying a sequence chart of voice call log, in mscgen
format.
I want to visualize how the sequence of messages changes across patches. It is
error prone to do it manually, and re-doing the sequence chart for every patch
(and patch rework) would be prohibitively time consuming.
Change-Id: I2e4d8778f7b83dee558517a9b23450b817ee325d
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
Fix vty tests that are failing since libosmocore change
Ic225232fbfca49ba868427eaf898e1f6e34e1ca8. If OsmoMSC is built without
IU support, it fails with "cs7-instance-iu" in the config.
Change-Id: Ie56da9167badfd2399b566af91a345103f46c2a1
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
To not break the msc_vlr tests by new GSUP IEs added to some of the GSUP
messages, make msc_vlr_tests only match the start of the GSUP message and not
care about extra IEs. The extra IEs are anyway seen in the expected logs.
The reason to drop the msgb_eq_data_print() is because it is useless for
mismatching lengths. It will always print only the length mismatch, instead we
need to be able to compare with what was expected.
Change-Id: I38d51eeafab04ece83e4bb87bfaa967506f97b11
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
mncc_fsm.[hc] were renamed to mncc_call.[hc] during patch review, which failed
to carry through to this sequence chart.
Also fix the MNCC_ST_* to MNCC_CALL_ST_* and MNCC_EV_* to MNCC_CALL_EV_*.
Change-Id: I03ee1b43ab95dca3c43fdb9e92dc158aad5a4203
- add SIP messages, taken from OS#1683
- change some wording and clarify some message ordering
- have a separate sipcon1 and sipcon2 for the MO and MT sides
Change-Id: I6782e416dbd8ee88d093cbef722b0c5084f3865c
Following I04ecd7a3b1cc603b2e3feb630e8c7c93fc36ccd7, have tests for UMTS
authentication both for cases with and without encryption.
- Rename test_umts_authen_utran to test_umts_auth_ciph_utran() (uses
encryption).
- Again add test_umts_authen_utran() not using encryption.
- Likewise with test_umts_authen_resync_utran().
Some permutations are still missing, like UMTS AKA on GERAN with encryption
enabled; not bothering at the moment.
Related: OS#2783
Change-Id: I54227f1f08c38c0bf69b9c48924669c4829b04b9
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
There is unfortunately no way to suppres this witha pragma,
and gcc 9 uncovers quite a few new instaces with enabled LTO that can't/won't be fixed
Related: OS#4123
Change-Id: I615bb5be3671022c6b821575a61f945b50e8f2a5
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
The function name implies OSMO_RAT_GERAN_A, and it has nothing
to do with other OSMO_RAT_* types. Found using clang:
warning: too many arguments in call to 'expect_bssap_clear'
expect_bssap_clear(OSMO_RAT_GERAN_A);
^^^^^^^^^^^^^^^^
Change-Id: Id3a3af33fcc5da4ca4c48a2f589a69f3568d2586
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
Newer versions of libdbi print to stderr unconditionally when trying to
load drivers from /usr/lib/dbd. This makes test output to change
depending on host/distro set up (installed modules).
Let's get those messages out to make it easier for people having tests
pass.
We swap stderr/stdout instead of mixing to avoud future possible race
conditions if both get content writen into them.
Change-Id: Iec78826d28435f464be22e81b3776a6ae8326d59
The libdbd-sqlite3 provides SQLite3 driver for libdbi. We use it
by default for the built-in SMS Centre. Since [1], we have unit
test coverage for the db_sms_* API, thus we need libdbd-sqlite3
to be installed at build-time.
[1] Id94ad35b6f78f839137db2e17010fbf9b40111a3
Change-Id: Ice9fb11f5b8a39abecee426d2fadcf62b7ee47c4
man memcp doesn't define exact values for returned integer, it only
specifices a meaning for the sign of it.
So it happens that different versions/implementations actually return
different values when this test is run, making it fail.
Let's simply drop that info from logs since anyways it's not useful.
Change-Id: I771fb8f4fc56f337b16561d005ff1803a386d1c6
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
We also need stubs for the upcoming db_sms tests.
Due to a known bug of automake [1], we cannot use 'subdir-objects',
so as a side effect this change introduces some autoreconf warnings.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752993
Change-Id: I8846c940f2695fd33e1007fecac83e73f508bb34
In the most cases we need to check whether particular char buffer
is empty or not. Using strlen() for that involves more CPU power,
so let's just check the first character against '\0'.
Change-Id: I8728876b80c870e82247e6e56f719e10ed322a95
The current way of printing subscriber, connection, and transaction
info is ugly (sorry) and has several problems:
- the terminal width should be large enough to fit quite long lines,
otherwise the output is unreadable and looks misaligned;
- some fields (such as subscriber name) can be larger than it's
expected, so either they're getting truncated, or again, the
output is misaligned and unreadable;
- adding new info fields would require one to think about the
alignment and would make the output even more cumbersome.
Here is an example output of 'show connection' command:
_Subscriber_______________________________________ _LAC_ _RAN___________________ _MSC-A_state_________ _MSC-A_use_
IMSI-123456789012345:MSISDN-12345:TMSI-0x12345678 1 GERAN-A-4294967295:A5-3 WAIT_CLASSMARK_UPDATE 2=cm_service,trans_cc
IMSI-123456789012356:MSISDN-234567:TMSI-0x123ABC78 65535 UTRAN-Iu-4294967295 COMMUNICATING 2=cm_service,trans_sms
IMSI-262073993158656:MSISDN-123456:TMSI-0x493026BA 1 GERAN-A-1 MSC_A_ST_COMMUNICATING 1=1 (silent_call)
Another 'show subscriber' command mixes the information about
subscriber, its connections and transactions without any alignment,
what also decreases the readability.
This change introduces a hierarchical approach, based on the old
'field per line' formatting. First of all, the VTY commands were
extended with optional flags:
show connection [trans]
show subscriber cache [(conn|trans|conn+trans)]
show subscriber TYPE ID [(conn|trans|conn+trans)]
so it can be decided, whether to print child connections and/or
transaction, or not. For example:
show connection trans
would print all connections and their child transactions with
hierarchical alignment:
Connection #00:
Subscriber: IMSI-262073993158656:MSISDN-123456:TMSI-0x76760B75
RAN connection: GERAN-A-1
RAN connection state: MSC_A_ST_COMMUNICATING
LAC / cell ID: 1 / 0
Use count total: 1
Use count: 1 (silent_call)
Transaction #00:
Unique (global) identifier: 0x00000000
GSM 04.07 identifier (MT): 0
Type: silent-call
another example is:
show subscriber cache conn+trans
which would print all known subscribers,
their active connections and transactions:
Subscriber #00:
MSISDN: 123456
LAC / cell ID: 1 / 0
RAN type: GERAN-A
IMSI: 262073993158656
TMSI: 76760B75
...
Connection:
RAN connection: GERAN-A-1
RAN connection state: MSC_A_ST_COMMUNICATING
...
Transaction #00:
Unique (global) identifier: 0x00000000
GSM 04.07 identifier (MT): 0
Type: silent-call
Transaction #01:
Unique (global) identifier: 0x00000001
GSM 04.07 identifier (MO): 0
Type: SMS
Transaction #02:
Unique (global) identifier: 0x00000002
GSM 04.07 identifier (MT): 0
Type: SMS
Please note that we don't print redundant info in child nodes
(i.e. connection and transaction info), such as subscriber name
in connection info, nor connection name in transaction info - it
is clear from the hierarchical formatting.
Change-Id: I5e58b56204c3f3d019e8d4c3c96cefdbb4af4d47
The HLR (which is connected via the GSUP interface) may fail and
disconnect. On the next location update the VLR will try to talk to the
HLR and fail. This failure event is not communicated towards the SGs
related code and the SGs-association will remain in the LA-PRESENT state
forever. Lets add code to report the problem to the SGs code and trigger
a RESET an the SGs interface.
- Add a flag to report an HLR problem back to the SGs code
- Fix the FSM that controls the reset
- Make sure the all SGs associations are reset when the failure occurs.
Change-Id: Icc7df92879728bc98c85fc1d5d8b4c6246501b12
Related: OS#3859
According to 3GPP TS 29.002, section 7.6.8.7, MMS (More Messages to Send)
is an optional IE of MT-ForwardSM-Req message which is used by SMSC to
indicate that there are more (multi-part) MT SMS messages to be sent.
The MSC needs to use this indication in order to decide whether to
keep the RAN connection with a given subscriber open.
Related Change-Id: (TTCN) I6308586a70c4fb3254c519330a61a9667372149f
Change-Id: Ic46b04913b2e8cc5d11a39426dcc1bfe11f1d31e
Related: OS#3587
in osmo-msc/Makefile.am, osmo-msc was actually missing the LIBASN1C_LIBS even
though it included LIBASN1C_CFLAGS. Probably libasn1c is implicitly linked from
libranap.so, but doesn't hurt to name it.
When building without Iu support, the LIBOSMORANAP* and LIBASN1C* vars are
empty, so no need to explicitly switch on BUILD_IU, just name them.
Change-Id: I39ae5e3f0f7661ca9ee5c17a500be28c461d7ec7
DB counters has been used to save osmo_counters & osmo_rate_ctr to a local
sqlite databases every 60 seconds.
This is quite slow e.g. 1000 subscriber might slow the msc down.
Change-Id: Id64f1839a55b5326f74ec04b7a5dbed9d269b89c
Later on we want to do extra steps upon receiving a Rx Reset Ack
(checking for Osmux support from peer). Let's move handling of this
message into its own function to have handling implementation in one
place.
Change-Id: I516c4baf6071d26f6c530726d93677bed968efd1
When 'check-imei-rqd 1 early' is set in the config, send the IMEI to
the HLR before doing the location update with the HLR.
The OsmoHLR documentation referenced in the code will be added in
osmo-hlr.git's Change-Id I2dd4a56f7b8be8b5d0e6fc32e04459e5e278d0a9.
Related: OS#2542
Change-Id: I88283cad23793b475445d814ff49db534cb41244
Copy IMEISV to IMEI when IMEISV changes. The additional SV digits will
get cut off then. This is needed for the subscriber on demand use case,
since we can get the IMEISV early (see [1]), but need to send the IMEI
to the Check IMEI procedure.
While adjusting the tests, I have noticed that there are code paths
where we ask the MS for the IMEISV first, and later ask the MS for the
IMEI, although we already have the IMEISV. This could be improved in a
future patch.
[1] Change-Id I256224194c3b8caf2b58a88d11dccd32c569201f
Related: OS#2542
Change-Id: I02e7b66848bf7dddb31b105e2ae981432817ae1e
Set the length of vlr_subscr->imei to
GSM23003_IMEI_NUM_DIGITS_NO_CHK (14)
instead of
GSM23003_IMEISV_NUM_DIGITS (16).
Note that there is also GSM23003_IMEI_NUM_DIGITS (15), which includes
an additional checksum digit. This digit is not intended for digital
transmission, so we don't need to store it. Also by not storing it, we
can simply copy the IMEI-part from the IMEISV to the IMEI without
worrying about the checksum (will be done in a follow up patch).
A good overview of the IMEI/IMEISV structure is here:
https://en.wikipedia.org/wiki/International_Mobile_Equipment_Identity#Structure_of_the_IMEI_and_IMEISV_(IMEI_software_version)
Related: OS#2542
Change-Id: Iaf2569c099874b55acbd748b776394726cc5ce54
Prepare for Rhizomatica's subscriber on demand use case, in which the
network access is disabled by default for new subscribers, but the IMEI
is required in the HLR to find out which user has which IMSI. Due to the
network access being disabled, the location update request towards the
HLR fails and the MS gets rejected, so we need to get the IMEI early.
Related: OS#2542, OS#3755
Change-Id: I256224194c3b8caf2b58a88d11dccd32c569201f
Previous patch [1] removed NULL-safety from LOG_TRANS(). Fix that.
In case a trans is NULL, it is fine to log in the DMSC category, since the
context should still be general (erratic message or other initial problems).
[1] 7f85acea9b / I6dfe5b98fb9e884c2dde61d603832dafceb12123
"LOG_TRANS: store subsys in trans, unify USSD logging back to DMM"
Change-Id: I6e36c47bf828dd073b36c6301bbeabcc28e101e6
In state machine callback functions, instead of logging an error when
an invalid event arrives, do OSMO_ASSERT(0).
Change-Id: If5363ae37b414a0ac195e5f89664c75cbad0bb21
In ran_a_make_handover_request() we do prevent destination buffer
(r.encryption_information.key) overflow, but not source buffer
(n->geran.chosen_encryption->key) overrun if an incorrect key
length is received. Let's fix this.
Change-Id: I278bb72660634c2d535e1bd3d7fce5696da23575
Fixes: CID#198450 Out-of-bounds access
We basically need to make sure that one of two possible IEs
is not NULL, while another is NULL (eXclusive OR). This can
be done using at least two conditional branches.
Change-Id: Ie0f9b5c1bbbfb744e0615da07d76037d91b0abc8
Fixes: CID#198444 Logically dead code
For some reason, having ternary operator there makes Coverity think
that 'n->geran.chosen_encryption' is dereferenced before checking
against NULL. Let's make it happy, and move the assignment.
Change-Id: I95051d0f02e2fdd3ec8da3a506109e7b23e99b4b
Fixes: CID#198454 Dereference before null check
The librt is required for old glibc < 2.17 to get clock_gettime().
Since we do check the availability of this function libosmocore
and conditionally link it against librt, there is no need to do
such unconditional and redundant linkage here.
Change-Id: If587d16d2db677b97e3a0641027eb735af9c9c30
In gsm48_rx_mm_serv_req() we need to make sure that a given message
buffer is large enough to contain both 'gsm48_hdr' and
'gsm48_service_request' structures.
Comparing msg->data_len with size of pointer if wrong because:
- we actually need to compare with size of struct(s),
- we need msgb_l3len(), not length of the whole buffer.
Moreover, since we have to use the pointer arithmetics in order
to keep backwards compatibility with Phase1 phones, we also
need to check the length of both Classmark2 and MI IEs.
Change-Id: I6e7454d7a6f63fd5a0e12fb90d8c58688da0951e
Since in parse_umts_auth_resp() we are checking the length of
GSM48_IE_AUTH_RES_EXT TLV, we need to print its length, but
not the length of the whole L3.
Change-Id: I2bfebce6d017be834bfe7628ffa2b341eb82c11c
The MSC_A_EV_HANDOVER_END exists as parent term event for the msc_ho_fsm, but
it is not actually required as functional event, since all cleanup is handled
in msc_ho_fsm_cleanup().
That's why I never bothered to add the event to msc_a_fsm, but of course that
means we get an error message after each (successful and unsuccessful)
handover, that the MSC_A_EV_HANDOVER_END is not permitted.
Allow the event and ignore it to silence the error message.
Explain in a comment.
Change-Id: Ie8dc0c0a631b7da43111f329562007766a21b134
After neels/ho was merged, SMS over IuCS/RANAP was failing in both
MO and MT direction. The reason was that all mobile-terminated SMS-CP
layer messages were sent in RANAP with SAPI-0 instaed of SAPI-1.
Change-Id: I98e6eddb52d5c61c4e2d34bdfcd43cf460296ad7
Closes: OS#3993
The event is actually never dispatched and useless, because when an RTP stream
releases, the call_leg terminates directly anyway (which wasn't apparent when
starting to design the call_leg FSM yet).
Change-Id: I6b2fc1225c960fa2f7c46adf241520217a07821c
The SMPP 3.4 specification defines the password field as a
"Variable-length octet string with maximum length of 9", and according
to table 3-1 this means including the terminating NUL-byte.
However, OsmoMSC allows to configure longer passwords in the ESME
configuration. Those passwords will then never match, as libsmpp34
performs length validation and generates a parser error for anyone
trying to send a longer password via SMPP.
The same applies for system-id, where we have to permit only 15
characters with zero termination, but not 16 characters.
Change-Id: I81ef593e84bf1e15f6746386fc145495fae29354
Closes: OS#3166
Instead of calling trans_log_subsys() for each LOG_TRANS() log line, rather
store in trans->log_subsys once on trans_alloc() and use that.
Do not fall back to the RAN's own subsystem (DBSSAP / DIUCS), it makes little
sense and may cause logging to switch subsystems depending on the RAN state.
In trans_log_subsys(), add missing switch cases:
- Log silent call transactions also on CC.
- Log USSD on DMM.
About USSD: we currently have no dedicated USSD logging category. As a result,
after LOG_TRANS() was introduced [1], USSD logged on DBSSAP/DIUCS or DMSC,
depending on whether a RAN was associated with the trans or not. Before that
change, USSD always logged on DMM, so, until we have a separate logging
category for USSD, consistenly use DMM again.
[1] in I2e60964d7a3c06d051debd1c707051a0eb3101ba / ff7074a0c7
Related: coverity CID 198453
Change-Id: I6dfe5b98fb9e884c2dde61d603832dafceb12123
As per 3GPP TS 03.40, section 9.2.3.16 "TP-User-Data-Length (TP-UDL)",
if the TP-User-Data is coded using the GSM 7-bit default alphabet,
the TP-User-Data-Length field indicates the *number of septets*
within the TP-User-Data field to follow. Otherwise, i.e. in case
of 8-bit or UCS-2 encoded data, the *number of octets* is indicated.
Since we store the original TP-UDL value (as received), we might
need to convert septets to octets before passing it to memcpy().
Otherwise this would lead to a buffer overrun.
Also, as we receive TPDU from untrusted source (i.e. subscriber),
the TP-UDL value needs to be checked against the corresponding
maximum (160 septets or 140 octets) and truncated if needed.
Please note that buffer overrun is still possible, e.g. when an
indicated TP-UDL value is grather than the remaining TPDU length.
Preventing this would require adding an additional check.
Change-Id: I4b08db7665e854a045129e7695e2bdf296df1688
Depends-on: (core) I54f88d2908ac47228813fb8c049f4264e5145241
It was noticed that SCCP_RAN_MSG_RESET_ACK message is not freed after
sending. Since ran_peer_rx_reset() calls sccp_ran_down_l2_cl(), which
then calls osmo_sccp_user_sap_down_nofree(), which doesn't free the
message buffer (what's clear from its name).
OsmoMSC# show talloc-context application full filter msgb
full talloc report on 'osmo_msc' (total 20155 bytes in 88 blocks)
msgb contains 4640 bytes in 5 blocks (ref 0)
bssmap: reset ack contains 1160 bytes in 1 blocks (ref 0)
bssmap: reset ack contains 1160 bytes in 1 blocks (ref 0)
bssmap: reset ack contains 1160 bytes in 1 blocks (ref 0)
Let's free it after sending (or in case of error).
Change-Id: Ic174f6eecd6254af597dfbdc1c9e3d65716f0a76
The misnomed 'nas_decode' and 'nas_encode' APIs have been renamed to
'ran_decode' and 'ran_encode', which was forgotten in the large comment
explaining the message path in sccp_ran.h. Apply the rename there.
Change-Id: I742fb4844ac8a9ad76f59883ae9447eb8819b82d
This fixes the following compiler error:
msub.c: In function ‘msub_fsm_active’:
msub.c:85:35: error: ‘msc_role_a_c’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
|| (msc_role_a_c && msc_role_a_c->ran->type == OSMO_RAT_EUTRAN_SGS)))
~~~~~~~~~~~~^~~~~
msub.c:59:26: note: ‘msc_role_a_c’ was declared here
struct msc_role_common *msc_role_a_c;
^~~~~~~~~~~~
Change-Id: Id518dea77d01ed0518ca7cba6b1b363f1c8e6543
While developing the inter-MSC handover refactoring, I was annoyed by the fact
that mncc_tx_to_cc() receives an MNCC message struct containing a msg_type, as
well as a separate msg_type argument, which may deviate from each other. So, as
a first step I wanted to make sure that all callers send identical values for
both by inserting an OSMO_ASSERT(msg_type == msg->msg_type). Later I was going
to remove the separate msg_type argument.
I then forgot to
- carry on to remove the argument and
- to actually test with internal MNCC (it so happens that all of our ttcn3
tests also use external MNCC).
As a result, the "large refactoring" patch for inter-MSC Handover breaks
internal MNCC operation.
Fix that: remove the separate msg_type argument and make sure that all callers
of mncc_tx_to_cc() indeed pass the desired msg_type in msg->msg_type, and hence
also remove the odd duality of arguments.
Various functions in mncc_builtin.c also exhibit this separate msg_type
argument, which are all unused and make absolutely no sense. Remove those as
well.
Related: OS#3989
Change-Id: I966ce764796982709ea3312e76988a95257acb8d
We are just introducing smpp34_set_memory_functions() in libsmpp34
to allow applications like OsmoMSC to provide their own heap allocator
callback functions. Let's used this to integrate with talloc and
hence allow talloc tracking/debugging for libsmpp34 internal
allocations.
Depends: libsmpp34 Change-Id I3656117115e89638c093bfbcbc4369ce302f7a94
Change-Id: Ie2725ffab6a225813e65768735f01678e2022128
Related: OS#3913
Get rid of the legacy name bscconfig.h from osmo-nitb times.
Remove the #include from some of the files that aren't actually using it.
Instead of '#include "../../config.h"', use plain '#include "config.h"'
because we're anyway passing $top_srcdir as -I during compilation.
Change-Id: Id4f683be1f36f0630c83da54e02868aae847aeec
Before, I was testing with osmo-hlr patch
I01a45900e14d41bcd338f50ad85d9fabf2c61405 applied, but that patch is currently
in an abandoned state.
This is the counterpart implemented in osmo-msc: always include the terminating
nul char in the "blob" that is the MSC IPA name.
The dualities in the formats of routing between MSCs is whether to handle it as
a char*, or as a uint8_t* with explicit len (a blob).
In the VTY config to indicate target MSCs for inter-MSC handover, we have
strings. We currently even completely lack a way of configuring any blob-like
data as a VTY config item.
In osmo-hlr, the IPA names used for routing are currently received as a char*
which *includes* the terminating nul char. So in osmo-msc, if we also always
include the nul char, it works.
Instead, we could just send the char* part without the nul char, and apply
above mentioned osmo-hlr patch. That patch would magically match a name that
lacks a nul with a name that includes one. I think it is better to agree on one
format on the GSUP wire now, instead of making assumptions in osmo-hlr on the
format of the source/target names for routing. This format, from the way GSUP
so far transmits the IPA SERNO tag when a client attaches to osmo-hlr, happens
to include the terminating nul char.
Change-Id: I9ca8c9eef104519ed1ea46e2fef46dcdc0d554eb
3GPP TS 49.008 '4.3 Roles of MSC-A, MSC-I and MSC-T' defines distinct roles:
- MSC-A is responsible for managing subscribers,
- MSC-I is the gateway to the RAN.
- MSC-T is a second transitory gateway to another RAN during Handover.
After inter-MSC Handover, the MSC-I is handled by a remote MSC instance, while
the original MSC-A retains the responsibility of subscriber management.
MSC-T exists in this patch but is not yet used, since Handover is only prepared
for, not yet implemented.
Facilitate Inter-MSC and inter-BSC Handover by the same internal split of MSC
roles.
Compared to inter-MSC Handover, mere inter-BSC has the obvious simplifications:
- all of MSC-A, MSC-I and MSC-T roles will be served by the same osmo-msc
instance,
- messages between MSC-A and MSC-{I,T} don't need to be routed via E-interface
(GSUP),
- no call routing between MSC-A and -I via MNCC necessary.
This is the largest code bomb I have submitted, ever. Out of principle, I
apologize to everyone trying to read this as a whole. Unfortunately, I see no
sense in trying to split this patch into smaller bits. It would be a huge
amount of work to introduce these changes in separate chunks, especially if
each should in turn be useful and pass all test suites. So, unfortunately, we
are stuck with this code bomb.
The following are some details and rationale for this rather huge refactoring:
* separate MSC subscriber management from ran_conn
struct ran_conn is reduced from the pivotal subscriber management entity it has
been so far to a mere storage for an SCCP connection ID and an MSC subscriber
reference.
The new pivotal subscriber management entity is struct msc_a -- struct msub
lists the msc_a, msc_i, msc_t roles, the vast majority of code paths however
use msc_a, since MSC-A is where all the interesting stuff happens.
Before handover, msc_i is an FSM implementation that encodes to the local
ran_conn. After inter-MSC Handover, msc_i is a compatible but different FSM
implementation that instead forwards via/from GSUP. Same goes for the msc_a
struct: if osmo-msc is the MSC-I "RAN proxy" for a remote MSC-A role, the
msc_a->fi is an FSM implementation that merely forwards via/from GSUP.
* New SCCP implementation for RAN access
To be able to forward BSSAP and RANAP messages via the GSUP interface, the
individual message layers need to be cleanly separated. The IuCS implementation
used until now (iu_client from libosmo-ranap) did not provide this level of
separation, and needed a complete rewrite. It was trivial to implement this in
such a way that both BSSAP and RANAP can be handled by the same SCCP code,
hence the new SCCP-RAN layer also replaces BSSAP handling.
sccp_ran.h: struct sccp_ran_inst provides an abstract handler for incoming RAN
connections. A set of callback functions provides implementation specific
details.
* RAN Abstraction (BSSAP vs. RANAP)
The common SCCP implementation did set the theme for the remaining refactoring:
make all other MSC code paths entirely RAN-implementation-agnostic.
ran_infra.c provides data structures that list RAN implementation specifics,
from logging to RAN de-/encoding to SCCP callbacks and timers. A ran_infra
pointer hence allows complete abstraction of RAN implementations:
- managing connected RAN peers (BSC, RNC) in ran_peer.c,
- classifying and de-/encoding RAN PDUs,
- recording connected LACs and cell IDs and sending out Paging requests to
matching RAN peers.
* RAN RESET now also for RANAP
ran_peer.c absorbs the reset_fsm from a_reset.c; in consequence, RANAP also
supports proper RESET semantics now. Hence osmo-hnbgw now also needs to provide
proper RESET handling, which it so far duly ignores. (TODO)
* RAN de-/encoding abstraction
The RAN abstraction mentioned above serves not only to separate RANAP and BSSAP
implementations transparently, but also to be able to optionally handle RAN on
distinct levels. Before Handover, all RAN messages are handled by the MSC-A
role. However, after an inter-MSC Handover, a standalone MSC-I will need to
decode RAN PDUs, at least in order to manage Assignment of RTP streams between
BSS/RNC and MNCC call forwarding.
ran_msg.h provides a common API with abstraction for:
- receiving events from RAN, i.e. passing RAN decode from the BSC/RNC and
MS/UE: struct ran_dec_msg represents RAN messages decoded from either BSSMAP
or RANAP;
- sending RAN events: ran_enc_msg is the counterpart to compose RAN messages
that should be encoded to either BSSMAP or RANAP and passed down to the
BSC/RNC and MS/UE.
The RAN-specific implementations are completely contained by ran_msg_a.c and
ran_msg_iu.c.
In particular, Assignment and Ciphering have so far been distinct code paths
for BSSAP and RANAP, with switch(via_ran){...} statements all over the place.
Using RAN_DEC_* and RAN_ENC_* abstractions, these are now completely unified.
Note that SGs does not qualify for RAN abstraction: the SGs interface always
remains with the MSC-A role, and SGs messages follow quite distinct semantics
from the fairly similar GERAN and UTRAN.
* MGW and RTP stream management
So far, managing MGW endpoints via MGCP was tightly glued in-between
GSM-04.08-CC on the one and MNCC on the other side. Prepare for switching RTP
streams between different RAN peers by moving to object-oriented
implementations: implement struct call_leg and struct rtp_stream with distinct
FSMs each. For MGW communication, use the osmo_mgcpc_ep API that has originated
from osmo-bsc and recently moved to libosmo-mgcp-client for this purpose.
Instead of implementing a sequence of events with code duplication for the RAN
and CN sides, the idea is to manage each RTP stream separately by firing and
receiving events as soon as codecs and RTP ports are negotiated, and letting
the individual FSMs take care of the MGW management "asynchronously". The
caller provides event IDs and an FSM instance that should be notified of RTP
stream setup progress. Hence it becomes possible to reconnect RTP streams from
one GSM-04.08-CC to another (inter-BSC Handover) or between CC and MNCC RTP
peers (inter-MSC Handover) without duplicating the MGCP code for each
transition.
The number of FSM implementations used for MGCP handling may seem a bit of an
overkill. But in fact, the number of perspectives on RTP forwarding are far
from trivial:
- an MGW endpoint is an entity with N connections, and MGCP "sessions" for
configuring them by talking to the MGW;
- an RTP stream is a remote peer connected to one of the endpoint's
connections, which is asynchronously notified of codec and RTP port choices;
- a call leg is the higher level view on either an MT or MO side of a voice
call, a combination of two RTP streams to forward between two remote peers.
BSC MGW PBX
CI CI
[MGW-endpoint]
[--rtp_stream--] [--rtp_stream--]
[----------------call_leg----------------]
* Use counts
Introduce using the new osmo_use_count API added to libosmocore for this
purpose. Each use token has a distinct name in the logging, which can be a
globally constant name or ad-hoc, like the local __func__ string constant. Use
in the new struct msc_a, as well as change vlr_subscr to the new osmo_use_count
API.
* FSM Timeouts
Introduce using the new osmo_tdef API, which provides a common VTY
implementation for all timer numbers, and FSM state transitions with the
correct timeout. Originated in osmo-bsc, recently moved to libosmocore.
Depends: Ife31e6798b4e728a23913179e346552a7dd338c0 (libosmocore)
Ib9af67b100c4583342a2103669732dab2e577b04 (libosmocore)
Id617265337f09dfb6ddfe111ef5e578cd3dc9f63 (libosmocore)
Ie9e2add7bbfae651c04e230d62e37cebeb91b0f5 (libosmo-sccp)
I26be5c4b06a680f25f19797407ab56a5a4880ddc (osmo-mgw)
Ida0e59f9a1f2dd18efea0a51680a67b69f141efa (osmo-mgw)
I9a3effd38e72841529df6c135c077116981dea36 (osmo-mgw)
Change-Id: I27e4988e0371808b512c757d2b52ada1615067bd
Avoid deprecation warning: use gsm48_decode_bcd_number2() instead of
gsm48_decode_bcd_number().
Validate the return value and add error handling.
Change-Id: Ibef71c46d72d2d43123e68f73e5ed554a69243d8
When the LU is accepted and the subscriber (vsub) is not claimed as "in
use" in the ref counting system.
- Make sure vlr_subscr_get() is called when the LU is accepted.
Change-Id: Iba90be095569cc5212c61ab8e8a9bfd4ae51fd44
Related OS#3934
This looks like a rudiment from OpenBSC, where we have:
#define BSC_API __attribute__((visibility("default")))
However, we don't use this attribute in OsmoMSC.
Change-Id: Ie2f18e9b47eca478f6e4702606068814546e34ce
In smpp_openbsc.c submit_to_sms(), "get" the appropriate use count upon
assigning sms->receiver, fixing a -1 use count upon sms_free().
Also, avoid a "put" of a NULL subscriber in the same function.
Related: OS#3930
Change-Id: Idaf01cd3cfa08088ce0d543d0576db957dc94262
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'
below.
Related: I7dce12942a65eaaf97f78ca69401c7f93faacb9e (osmo-ttcn3-hacks)
Change-Id: I24bf9f1c1167efe1080ae4cf47ed2ef0bd981e49
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
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
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
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
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
started.
Change-Id: If95c63706dc1c5a537f7cd1b6481252427cbf234
Related: OS#3614
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
database.
Change-Id: I575cf6036ad39468f590b2d57a06cd3512a4c31c
Related: OS#3614
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
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
smsq_take_next_sms().
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
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
It was observed that the SGs server is started before
the actual VTY configuration is parsed. For example:
sgs
local-port 9999
local-ip 127.0.0.1
vlr-name vlr.example.net
produces the following debug output:
<0011> sgs_server.c:185 SGs socket bound to r=NULL<->l=0.0.0.0:29118
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=0.0.0.0:9999
DSGS NOTICE <0011> sgs_server.c:185 SGs socket bound to r=NULL<->l=127.0.0.1:9999
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
We now have a nicer way to compose strings in a buffer than this.
(Cosmetic preparation for inter-MSC handover patch.)
Change-Id: I7813068032475deb3850af05f7ba5a6f652e7fa2
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
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
AUTH REQUEST/RESPONSE cycle.
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 <tnt@246tNt.com>
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
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
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
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
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
violation.
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
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
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)
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)
The SGS_STATE_TS11 is not for counters, it's for timers!
Change-Id: Ifbb1a37e644ae8bf8e7959f6f6cd6403ac1f2f1b
Fixes: CID#190872 Out-of-bounds read (OVERRUN)
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
system?
Tested by building the Debian package and looking at its depends.
Related: OS#3771
Change-Id: I7c099212a6ad7d87978c3dce63ce7385d8076bd1
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:
msc
...
! 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
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
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
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
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
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
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
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
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
builds.
Change-Id: I092e95ea970763c4008d3c7ff1b7028042574a64
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
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
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
Previously, SM-RP Message Reference was assigned to MT transactions
only, but not to MO transactions. As a result, this could lead to
having a few transactions with duplicate SM-RP-MR value, because
in case of MO SMS, trans->sms.sm_rp_mr would remain 0x00.
Let's parse SM-RP-MR from MO SMS messages in gsm0411_rcv_sms(),
and assign it to the new transaction after allocation.
Change-Id: I4d07354175444f9764fb0dd6ea188a64494d79fe
The need to pass a pointer to RAN connection in order to find
a transaction limits possible use cases of trans_find_by_sm_rp_mr(),
e.g. when we need to find a transaction, but RAN connection is not
established yet.
Moreover, the pointer to RAN connection was only used to obtain
pointers to gsm_network and vlr_subscr, so we can just
pass them directly.
Change-Id: I093f36d63e671e50e54fc6236e97a777cc6da77b
Log transaction allocation errors as such. While at it, use proper
subsystem to log missing VLR subscriber.
Change-Id: I617be8793b9416ccd49022c72f7d93df7f4fb4d9
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-22 01:58:55 +01:00
254 changed files with 65387 additions and 30225 deletions
This repository contains a C-language implementation of a GSM **Mobile Switching
Centre (MSC)** for 2G (GSM) and 3G (UMTS). It is part of the
[Osmocom](https://osmocom.org/) Open Source Mobile Communications
project.
OsmoMSC exposes
* *A over IP* towards BSCs (e.g. [osmo-bsc](https://osmocom.org/projects/osmobsc/wiki): 3GPP AoIP or SCCPlite
* *IuCS over IP* towards RNCs / HNBGW (e.g. [osmo-hnbgw](https://osmocom.org/projects/osmohnbgw/wiki))
* *MGCP* towards a co-located [osmo-mgw](https://osmocom.org/projects/osmo-mgw/wiki) for the RTP streams
* *[GSUP](https://osmocom.org/projects/cellular-infrastructure/wiki/GSUP)* (instead of 3GPP MAP) towards [osmo-hlr](https://osmocom.org/projects/osmo-hlr/wiki)
* *SMPP* towards any external SMS sending/receiving applications
* *[MNCC](https://osmocom.org/projects/osmomsc/wiki/MNCC)* as external call-control interface towards e.g.
Oliver Smith
Max
Neels Hofmeyr
Harald Welte
Vadim Yanitskiy
Pau Espin
Philipp Maier
Manawyrm
Keith Whyte
Eric Wild
Martin Hauke
Daniel Willmann
Sylvain Munaut