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
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
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
The Mobile Identity type is received on the wire, we asserting on its type
constitutes a DoS vector.
Change-Id: I2b2e25ef8e878e91a165018ba49f1609cfb5cbd0
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
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
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