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
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
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
Do not crash when a Paging Response could not be associated with a VLR
subscriber.
Related: OS#4449
Change-Id: Ie117949dd6da86afaa1a0a6ac57bf2111f6cff43
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
Add a char buffer of 1024 characters length as space for SDP to pass to /
receive from MNCC.
Actually support receiving MNCC without such an SDP tail. The main reason for
this is to avoid the need to adjust the ttcn3 implementation of MNCC: it would
stop working for older osmo-msc.
Older or non-SIP MNCC peers could operate the previous MNCC protocol unchanged
(save the protocol number bump) without having to implement SDP.
The SDP part in the MNCC protocol will be used in upcoming patch
I8c3b2de53ffae4ec3a66b9dabf308c290a2c999f.
This patch must be merged at the same time as osmo-sip-connector patch
Iaca9ed6611fc5ca8ca749bbbefc31f54bea5e925, so that both sides have a matching
MNCC protocol version number.
Change-Id: Ie16f0804c4d99760cd4a0c544d0889b6313eebb7
Rationale: in order to add full SDP to the MNCC protocol (upcoming patch
I8c3b2de53ffae4ec3a66b9dabf308c290a2c999f), we need to parse and compose SDP
messages. Obviously, libosmo-mgcp-client already contains similar code, but
that is unfortunately heavily glued to the actual MGCP implementation. The
simplest solution is to create this separate implementation, copy-pasting from
the existing libosmo-mgcp-client code as is convenient.
This API is added here to probe whether it works well. When it does, the
intention is to "move it up" to osmo-mgw and overhaul the SDP parsing in our
MGCP client and MGCP server APIs using this same API.
Change-Id: If3ce23cd5bab15e2ab4c52ef3e4c75979dffe931
Do not free the CC transaction when an MT subscriber is already being Paged.
Instead, invoke another paging request, which paging.c will correctly add to
the list of pending paging response callbacks to run.
A ttcn3 test is linked in the related patch (s.b.).
Related: OS#4240
Related: Ieeae6322d4e80893ea3408c6b74bf8e32bea8e46
Change-Id: Idd4537b5f4817d17e5c87d9a93775a32aee0e7be
When the CRCX OK returns an invalid RTP address, abort the call; fixes
MSC_Tests.TC_invalid_mgcp_crash.
The original crash happened when adding this error handling without this commit
I08c03946605aa12e0a5ce8b3c773704ef5327a7a ("fsm: use deferred deallocation" for
osmo-mgw I7df2e9202b04e7ca7366bb0a8ec53cf3bb14faf3 "fix use-after-free: require
new fsm deferred dealloc, check for term"). With this error handling added,
even though avoiding a crash, the test does not pass yet, because instead of
rejecting the call, it currently composes an Assignment Command without a
Transport Layer Address. Fix that.
Change-Id: I00c3b5ff74c05bcc2b7c39375c33419916a57193
Actually decode the Codec List (BSS Supported) in BSSMAP, in both the Complete
Layer 3 Information and the Assignment Complete messages.
An upcoming patch improves codec negotiation and requires the BSS supported
codecs, which are so far ignored (which is/was a pity as osmo-bsc goes at great
lengths to compose those IEs).
Change-Id: I66c735c79e982388f06b5de783aa584c9d13569e
Use of this flag was dropped when adding inter-BSC and inter-MSC Handover
support, I forgot to remove it.
Change-Id: I5ec78e30eb36fbe78a3f7c46bfa44af5a4eb7bf2
Fix three 'FIXME: ERROR HANDLING' occurences in the code that reacts upon the
MGW providing (or failing to provide) an RTP port for the RAN side. From an
earlier stage of the code, the cleanup for this situation was extremely
complex, and hence the choice was to simply wait for the call to time out and
fail. But since we have implemented safe deallocation of nested FSMs in
libosmocore, the situation has become rather trivial: simply free the CC
transactions, and all the rest will immediately release, and terminate
correctly without crashing.
A ttcn3 test for this is MSC_Tests:TC_invalid_mgcp_crash, which actually also
needs the change to osmo_sockaddr_str_is_nonzero() in preceding patch
I53ddb19a70fda3deb906464e1b89c12d9b4c7cbd, so that a seemingly valid MGCP
message ends up causing a failure in the on_success() branch of
mgcp_client_endpoint_fsm.c.
Change-Id: I8313bed1d782100bebeac7d8fc040557c4cb653e
Also regard an RTP port as invalid if the IP address is 0.0.0.0.
Achieve this by using osmo_sockaddr_str_is_nonzero() instead of
osmo_sockaddr_str_is_set().
Depends: I73cbcab90cffcdc9a5f8d5281c57c1f87b2c3550 (libosmocore)
Change-Id: I53ddb19a70fda3deb906464e1b89c12d9b4c7cbd
libosmo-mgcp-client recently introduced osmo_mgcpc_ep_cancel_notify() to cancel
notification if a notify target FSM deallocates. Use it for sanity in
rtp_stream FSM cleanup, the notify target for endpoint FSMs.
Depends: I41687d7f3a808587ab7f7520f46dcc3c29cff92d (osmo-mgw)
I14f7a46031327fb2b2047b998eae6ad0bb7324ad (osmo-mgw)
Change-Id: I351bb8e8fbc46eb629bcd599f6453e2c84c15015
Before:
RAN decode: BSSMAP: Rx BSSMAP DT1 COMPLETE LAYER 3
After:
RAN decode: BSSMAP: COMPLETE LAYER 3
This caught my attention while I was writing up a script to parse osmo-msc
logging to produce ladder diagrams.
Change-Id: I387dde8f2eb3edb35d22ce52dc0ed580978dea36
If an incoming MNCC_SETUP_REQ ends up in Paging (as usually it does), the early
return so far skipped logging of that MNCC message. Add this logging.
Change-Id: I1495dd562a06cf6c1e9453a1fe111bdf8f4be081
So far, the logging said only "RAN encode: BSSMAP: DTAP", but not *which* DTAP
message, which is in fact a very interesting detail when reading osmo-msc logs.
Change-Id: I0cb8d1e3307737ffe53730c64bb984adacedb2da
For all CC type transaction logging, log the current trans->cc.state string for
all LOG_TRANS*() logging.
Change-Id: I67be12c74c679ce684f8c0b9b4e0d96299849dc6
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
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
Add a network -> callwaiting VTY command as boolean.
When this is enabled (default) there is no change to
operation previous to this commit.
When this switch is disabled with "no call-waiting" in vty
then when a call arrives, we will check if we have an active
call transaction for this subscriber, no matter if it is
establishing, established, or alerting, in any of these cases we
will return USER BUSY to the calling party.
Change-Id: I3eb6f23f7103e3002874fb5d3a30c9de952202ae
Distinguish the enclosed DTAP RR Ciphering Mode Complete message from the outer
BSSMAP Cipher Mode Complete message in the DEBUG log.
Change-Id: I80c69b491e2ddb932bc4295a01caaf6a903b1fe4
So far we sent CC cause "Unassigned Number"
But the MSC doesn't trivially know whether the HLR has the number assigned or
not: any handset that is currently switched off would cause "Unassigned number"
to be displayed on the caller's handset.
Rather send a temporary failure cause code.
Send this cause code for all cases, because claiming that an assigned number is
unassigned is worse than rejecting an unassigned number with a temporary
failure.
Change-Id: Ia3d4f67b53fcc2654ff048fbc338e92cb763a095
Apparently, if a conn disappears during an ongoing call, the CC code tried to
send a CC REL on a NULL msc_a during cleanup, which lead to a crash
(cccamp2019). Guard against that.
Crash:
#0 msc_a_tx_dtap_to_i (msc_a=0x0, dtap=0x55a4bf2fa0f0) at ../../../../src/osmo-msc/src/libmsc/msc_a.c:1565
#1 0x000055a4be1bb03c in trans_tx_gsm48 (trans=0x55a4bf2d52a0, trans=0x55a4bf2d52a0, trans=0x55a4bf2d52a0, msg=<optimized out>)
at ../../../../src/osmo-msc/src/libmsc/gsm_04_08_cc.c:82
#2 gsm48_cc_tx_release (trans=trans@entry=0x55a4bf2d52a0, arg=arg@entry=0x7ffdd731a0e0) at ../../../../src/osmo-msc/src/libmsc/gsm_04_08_cc.c:1101
#3 0x000055a4be1bee65 in _gsm48_cc_trans_free (trans=trans@entry=0x55a4bf2d52a0) at ../../../../src/osmo-msc/src/libmsc/gsm_04_08_cc.c:278
#4 0x000055a4be1ab654 in trans_free (trans=trans@entry=0x55a4bf2d52a0) at ../../../../src/osmo-msc/src/libmsc/transaction.c:170
#5 0x000055a4be1bd091 in mncc_tx_to_gsm_cc (net=<optimized out>, msg=msg@entry=0x55a4bf2d3b68)
at ../../../../src/osmo-msc/src/libmsc/gsm_04_08_cc.c:1971
#6 0x000055a4be1bf1e5 in mncc_tx_to_cc (net=<optimized out>, arg=arg@entry=0x55a4bf2d3b68)
at ../../../../src/osmo-msc/src/libmsc/gsm_04_08_cc.c:2049
#7 0x000055a4be18ed63 in mncc_sock_read (bfd=0x55a4bf2563b8, bfd=0x55a4bf2563b8) at ../../../../src/osmo-msc/src/libmsc/mncc_sock.c:121
#8 mncc_sock_cb (bfd=0x55a4bf2563b8, flags=1) at ../../../../src/osmo-msc/src/libmsc/mncc_sock.c:189
#9 0x00007fcfad607ce1 in osmo_fd_disp_fds (_eset=0x7ffdd731a9a0, _wset=0x7ffdd731a920, _rset=0x7ffdd731a8a0)
at ../../../src/libosmocore/src/select.c:223
#10 osmo_select_main (polling=<optimized out>) at ../../../src/libosmocore/src/select.c:263
#11 0x000055a4be17dd56 in main (argc=3, argv=<optimized out>) at ../../../../src/osmo-msc/src/osmo-msc/msc_main.c:723
Change-Id: Ia1bb0410ad0618c182a5f6da06af342b6d483eff
All other calls check acl before deref because in a setup
with no access policy, there won't be any acl structure
Change-Id: Ibe0256535b40351594d79baa05a0147a9f89dc26
When a CSFB call is over the MS changes back to LTE after the call is
cleared. However, at the moment the MSC does not change the
cs.attached_via_ran flag. This may cause problems with the next call. Lets
make sure that if there is an SGs association present, the ran type is
set back to SGs when the call is cleared.
Related: SYS#4624
Change-Id: I104adecb0645b81b90ee230c57bf8b463c9e7045
When the VLR/MSC receives an SGsAP-MO-CSFB-INDICATION message it sets
the RAN type back to SGs. This is wrong, the message
SGsAP-MO-CSFB-INDICATION has just an informative character. It informs
the VLR that the UE has initiated an MO CSFB call (service request).
Change-Id: I625574fc42fc915ba483db3bb406922ad6df370d
Related: SYS#4624
Recently, the ability to run UTRAN without encryption was added, but the config
for it was tied to the A5 GERAN encryption configuration. This affected
osmo-msc's default behavior of Iu, breaking osmo-msc ttcn3 Iu tests: the ttcn3
test suite sets A5 to 0 (no encryption) but still expects Iu to enable air
encryption. Fix this "regression".
Add a separate vty config option for UEA encryption, even if it does not
provide full granularity to select individual UEA algorithms yet.
As a result, Iu default behavior remains to enable encryption regardless of the
A5 config. UTRAN encryption can be disabled by the new cfg option
"encryption uea 0" alone.
Even though the new vty command already allows passing various combinations of
the UEA algorithm numbers, only '0' and '1 2' are accepted as valid
combinations, to reflect current osmo-msc capabilities.
Revert most changes to the msc_vlr test suite in commit "do not force
encryption on UTRAN" (I04ecd7a3b1cc603b2e3feb630e8c7c93fc36ccd7): use new
net->iu_encryption instead of net->a5_encryption_mask.
Adjust/add to test_nodes.vty transcript tests.
Related: OS#4144
Change-Id: Ie138f2fcb105533f7bc06a6d2e6deccf6faccc5b
The function mncc_tx_to_gsm_cc() is declared as non static but only used
from within gsm_04_08_cc.c. Lets declare it as static to increase
readability of the code
Change-Id: Icd02c669cfee6dd7e6b154e303cd0f4c148c83c4
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
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
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
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
Neels Hofmeyr
Philipp Maier
Harald Welte
Pau Espin
Keith Whyte
Martin Hauke