Commit Graph

6617 Commits

Author SHA1 Message Date
Harald Welte ca292dd607 debian: depend on libsctp-dev
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

Change-Id: I092e95ea970763c4008d3c7ff1b7028042574a64
2019-02-06 17:56:01 +00:00
Max 34d306be95 VLR tests: use msgb_eq_data_print() for comparison
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
2019-02-05 16:25:03 +00:00
Harald Welte 0df904dea9 Add SGs Interface
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
2019-02-04 13:36:26 +01:00
Vadim Yanitskiy c7de62cc53 libmsc/gsm_04_11.c: introduce and use gsm411_assign_sm_rp_mr()
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
2019-02-01 18:55:54 +00:00
Vadim Yanitskiy cfd058dbf1 libmsc/gsm_04_11.c: also assign SM-RP-MR to MO transactions
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
2019-02-01 18:55:54 +00:00
Vadim Yanitskiy 36c44b2100 transaction: change arguments of trans_find_by_sm_rp_mr()
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
2019-02-01 18:55:54 +00:00
Vadim Yanitskiy ce9e1f664e libmsc/ran_conn.c: cosmetic: use tabs instead of N * 8 spaces
Change-Id: I09515aea9da8e2b5836c5c6409f094fae05633d4
2019-01-26 11:36:14 +07:00
Vadim Yanitskiy e4574f09d0 transaction.c: cosmetic: use 'default' branch in trans_free()
Change-Id: Ia28ba52b0ea4771843a2a1faa346f7357604b8aa
2019-01-26 11:36:08 +07:00
Max 3614fd6d11 Various logging fixes
Log transaction allocation errors as such. While at it, use proper
subsystem to log missing VLR subscriber.

Change-Id: I617be8793b9416ccd49022c72f7d93df7f4fb4d9
2019-01-24 19:08:07 +00:00
Max 80d8ffda8c Handle LCLS-NOTIFICATION message from BSS
Change-Id: Ibf5f9cad1f70aee56d5bca8fe09a24ca417e7a63
Related: OS#2487
2019-01-24 17:37:08 +00:00
Harald Welte 41e7cf115d Bump version: 1.3.0 → 1.3.1
Change-Id: I624144d6f8919d1dd237cdffc9122f685a8e4d6b
2019-01-22 16:02:11 +01:00
Neels Hofmeyr a92025e8fd fix build: apply msgb_wrap_with_TL() rename
After libosmocore commit
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
Harald Welte 811f6806a4 Bump version: → 1.3.0
Change-Id: I59d032ad953438f12439ac3d6275ee78d0ebbb40
2019-01-21 00:16:27 +01:00
Max 45df98bd85 vty: make 'sh connect/transact' readable again
After recent changes to vlr_subscr_name() result became variable-length
which messes up old vty code. Fix this by moving it to the very end and
adjusting headers as necessary. While at it, make sure we don't print
headers if we have nothing else to show.

Change-Id: Id06b4277ff790d95457d0cc2f94ef6bf5366bb21
2019-01-17 19:27:05 +01:00
Keith Whyte 72520f8d4f Cosmetic: Fix spelling in smpp vty
Change-Id: Id3fa3f26c333bf445590fd75ad7a08be68fed3e2
2019-01-17 14:04:07 +00:00
Keith Whyte c6d219cd83 Make alert notifications vty configurable per ESME
Adds (no) alert-notifications as a per-esme vty command,
in order to allow some ESMEs to be excluded from alerts.

The default is still to send alert notifications to all esme,
so no changes are required to the config file to maintain
identical operation after this patch.

Change-Id: I57f4d268ca6fe6a233f2caaffce62e4aade01274
2019-01-17 14:03:27 +00:00
Max 0e8dfadc7a SMS: remove code duplication in transaction init
Move code which allocates transaction for SMS and initializes
corresponding FSM into separate function (shared by MT and MO code
paths) to avoid code duplication and simplify further modifications.

Change-Id: I3563e11bebb58e656592df2ff7db96f41deaf735
2019-01-17 12:17:52 +00:00
Max 6b3cef08d2 MNCC: use explicit struct type in gsm_call
There's no need to use 'void *' because we have forward declaration for
'struct gsm_network' in the very same header.

Change-Id: I5078ffcf2706adaca1b5df107f8b6a44062ca28c
2019-01-16 12:56:59 +00:00
Max 4813152691 Enable SMS-related log in VLR tests
The likely reason why it was disabled is due to
paging_cb_mmsms_est_req() logging pointers which results in unstable log
output. Fixing this allows us to track SMS-related regressions properly.

Change-Id: I44ae817d9edb73d182ff33ff5a2fd942e224e344
2019-01-16 12:56:30 +00:00
Oliver Smith 7d05309e3a VLR: send CHECK-IMEI to EIR/HLR
When check-imei-req is enabled in the VTY config, do not accept IMEIs
sent by the ME directly anymore. Send the IMEI to the EIR/HLR and wait
for its ACK or NACK.

OsmoHLR also accepts all IMEIs at this point, but this allows to
optionally store the IMEI in the HLR DB.

Depends: Ib240474b0c3c603ba840cf26babb38a44dfc9364 (osmo-hlr)
Related: OS#3733
Change-Id: Ife868ed71c36cdd02638072abebf61fc949080a7
2019-01-16 10:42:56 +00:00
Max c065ca3171 Fix trans_has_conn() doxygen description
Change-Id: Ica5e498e03d0a157a661e428dfd68739f572d073
2019-01-14 15:30:26 +01:00
Philipp Maier ec5901c8f2 gsm_04_08: Fix nullpointer deref
The pointers conn, conn->vsub and conn->vsub->last_tuple are checked,
but before the check those pointers are already dereferenced during
assignment. This defeats the purpose of the check. Lets dereference
those pointers after the check.

Fixes: CID#190404
Change-Id: Ice4992606f3799eac13154ec0b9f53e46d2e178e
2019-01-12 10:26:00 +00:00
gsmevent admin 9b9e76fe01 gsm_04_08_cc.c: drop non-sensible error message
Change-Id: Icbf099e418281eb908e7916503f178ab7ea26ffe
2019-01-12 09:51:22 +00:00
Neels Hofmeyr 39cb0dd303 msc_vlr_tests: tweak logging in verbose mode
Change-Id: Ia06245f3adc6cf4c483d9c12c387cd5169582353
2019-01-12 09:51:22 +00:00
Neels Hofmeyr 5769d36b44 err log: fully log MS supported A5 algos on mismatch
Change-Id: Icb18e0f0bb420de066e7eb8fc683f192ba2a7368
2019-01-12 09:51:22 +00:00
Neels Hofmeyr a725970d85 tweak fsm_msc_mgcp FSM and FI name
Instead of


use a name of


1. The FSM is communication towards an MGW, not the MGW itself. When reading
combined logging (gsmtap_log), it is confusing to read 'MGW' in a log coming
from the MSC. The API is also called msc_mgcp_*.

2. Calling the FSM instance 'MGW_' again doesn't make sense.

3. Indicate 'trans' before the trans_id (trans_id was already shown, but not
indicated what it was).

4. Also indicate the actual subscriber's identification.

5. Also indicate the RAN connection and conn_id.

This comes up while trying to understand a call coming in on an already
established call: parsing the log with a human brain is near torture without
this info, taking extremely long to get grips on.

Change-Id: Ie5fc1ffb7eba0209fee4666a075655cd24d27473
2019-01-12 09:51:22 +00:00
Neels Hofmeyr b62289aa27 mm_rx_id_resp(): use osmo_mi_name()
Change-Id: I6bb053def223ed698351ad9f52c1e36293df5d59
2019-01-12 09:51:22 +00:00
Neels Hofmeyr 361e571815 refactor log ctx for vlr_subscr and ran_conn
ran_conn_get_conn_id(): instead of a talloc allocated string, return a static
buffer in ran_conn_get_conn_id(). So far this function had no callers.

Refactor ran_conn_update_id() API: during early L3-Complete, when no subscriber
is associated yet, update the FSM Id by the MI type seen in the L3 Complete
message: ran_conn_update_id_from_mi(). Later on set the vsub and re-update.

Call vlr.ops->subscr_update when the TMSI is updated, so that log context
includes the TMSI from then on.

Enrich context for vlr_subscr_name and ran_conn fi name.

Include all available information in vlr_subscr_name(); instead of either IMSI
or MSISDN or TMSI, print all of them when present. Instead of a short log,
rather have more valuable context.

A context info would now look like:


It does get quite long, but ensures easy correlation of any BSSAP / IuCS
messages with log output, especially if multiple subscribers are busy at the
same time.

Print TMSI and TMSInew in uppercase hexadecimal, which is the typical
representation in the telecom world.

When showing the RAN conn id
- We usually write the conn_id in decimal.
- Leading zeros are clutter and might suggest hexadecimal format.
- 'GERAN-A' and 'UTRAN-Iu' are the strings defined by osmo_rat_type_name().

Depends: I7798c3ef983c2e333b2b9cbffef6f366f370bd81 (libosmocore)
Depends: Ica25919758ef6cba8348da199b0ae7e0ba628798 (libosmocore)
Change-Id: I66a68ce2eb8957a35855a3743d91a86299900834
2019-01-12 09:51:22 +00:00
Neels Hofmeyr 7ce21dc589 rx CM Service Req: reject double use sooner
When a CM Service Req is being rejected, we should do so before changing the
state of the current conn.

Concerning multiple CM Service Requests: in fact we should store multiple
requests, but first fix the status quo of rejecting multiple requests.

Change-Id: I39209ee6662694aa054a2fc0d21eae76fb33e2f1
2019-01-12 09:51:22 +00:00
Neels Hofmeyr 46c06e28c1 add LOG_RAN_CONN() to use the conn->fi->id for context
For each conn, set a default logging category, to distinguish categories for
BSSMAP and RANAP based conns.

LOG_RAN_CONN(): log with the conn's default category,

LOG_RAN_CONN_CAT(): log with a manually set category (mostly for keeping
previous DMM logging on the same category).

In some places, replace LOGP() using manual context with LOG_RAN_CONN(), and
remove the manual context info, now provided by the conn->fi->id.

This is loosely related to inter-BSC and inter-MSC handover: to speed up
refactoring, I want to avoid the need for manual logging context and just use
this LOG_RAN_CONN().

Change-Id: I0a7809840428b1e028df6eb683bc5ffcc8df474a
2019-01-12 09:51:22 +00:00
Neels Hofmeyr 55d22d9e5e use osmo_lu_type_name() from libosmocore
Change-Id: Ib562bb5fb272c0c3ae0849f32b28faa2c26f9bb7
2019-01-12 09:51:22 +00:00
Vadim Yanitskiy 82cc8a5cfa libmsc/gsm_04_11.c: accept MT SMS messages over GSUP
Change-Id: I57357982ca0e51f6722c24a4aa1d0fb3e6caef88
Depends-on: (core) Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71
Depends-on: (OsmoHLR) I0589ff27933e9bca2bcf93b8259004935778db8f
Related Change-Id: (TTCN) I63a25c8366cce0852df6b628365151661a22a25f
Related: OS#3587
2019-01-11 21:42:43 +00:00
Max 4a5cfa559a Use explicit protocol discriminator for NC SS/USSD session
In gsm0911_rcv_nc_ss() we sometimes use pdisc parsed from msgb and
sometimes constant. This function is only called when protocol
discriminator is GSM48_PDISC_NC_SS so there's no point in parsing it
again from msgb.

Let's make it consistent and always use constant.

Change-Id: Iae40bf9906fe676ff817c709120015fca4c9e042
2019-01-10 17:41:05 +01:00
Oliver Smith 5598aaef23 VLR: vlr_subscr_{,msisdn_or_}name: const vsub arg
Make the vsub argument of both vlr_subscr_msisdn_or_name()
and vlr_subscr_name() a const.

The LOGVSUBP() macro uses vlr_subscr_name() and will not generate a
warning anymore when used with a const vsub.

Change-Id: If609269191f4df6186d823a2eee14012846328e2
2019-01-09 14:34:34 +00:00
Oliver Smith 361fa46444 vlr_core.h: remove duplicate declarations
Remove vlr_subscr_name() and vlr_subscr_alloc() declarations from
vlr_core.h, as they are already defined in osmocom/msc/vlr.h and vlr.h
gets included on top of vlr_core.h.

Change-Id: I5c029be490577b513395dc3f2c2698f365157e73
2019-01-09 14:34:14 +00:00
Oliver Smith 0fec28a506 msc_vty.c: make check-imei-rqd configurable
Related: OS#3189
Change-Id: Iee516b9cd7877b21207ce9a6d954109f19558163
2019-01-09 14:33:35 +00:00
Oliver Smith d6e24fd155 Cosmetic: msc_vty: remove redundant "0 =", "1 ="
Remove "0 =", "1 =" in-front of the boolean descriptions of
auth-tuple-reuse-on-error. The online VTY doc and the pdf manual
prepend the value automatically.

Change-Id: Ifd14c2fb3f58701eaf66570d729a660233fb83ed
2019-01-09 14:32:34 +00:00
Neels Hofmeyr 2c268697e9 use mgcp-client configured endpoint domain name
Rationale: reading pcaps becomes so much easier when each of osmo-bsc and
osmo-msc address their MGW with differing domain names. Otherwise, both will
have a '0@mgw' endpoint and it gets really confusing.

After this, with according configuration, there can be a '0@bsc' and a '0@msc'

  domain msc

  mgw endpoint-domain msc

Depends: Ia662016f29dd8727d9c4626d726729641e21e1f8 (osmo-mgw)
Change-Id: I87ac11847d1a6d165ee9a2b5d8a4978e7ac73433
2019-01-05 04:37:56 +01:00
Neels Hofmeyr 7814a83298 use osmo_rat_type from libosmocore
Replace locally defined enum ran_type with libosmocore's new enum
osmo_rat_type, and value_string ran_type_names with osmo_rat_type_names.

The string representations change, which has cosmetic effects on the test suite

Depends: I659687aef7a4d67ca372a39fef31dee07aed7631 (libosmocore)
Change-Id: I2c78c265dc99df581e1b00e563d6912c7ffdb36b
2019-01-04 17:26:14 +00:00
Neels Hofmeyr 3a3ed9b704 vty cfg: move 'ipa-name' from 'msc' to 'hlr' section
during code review, I completely overlooked this:

We've added the 'ipa-name', which identifies the MSC on the GSUP link to the
HLR, under the 'msc' section, while all other GSUP/HLR related config is under
the 'hlr' section.

Before we roll that out in a release, move it over to 'hlr'.

Related: OS#3355
Change-Id: I1a572865aa90c5fa43c6f57282a6e2b06776e425
2019-01-04 16:32:21 +00:00
Neels Hofmeyr 868f505d86 vlr: auth_fsm: make sure vsub->auth_fsm = NULL when it terminates
Probably fixes this segfault:

    at ../../../../src/osmo-msc/src/libvlr/vlr_lu_fsm.c:957
    file=file@entry=0x5611d8f10c28 "../../../../src/osmo-msc/src/libvlr/vlr_lu_fsm.c", line=line@entry=1467)
    at ../../../src/libosmocore/src/fsm.c:580
    parent_event_failure=parent_event_failure@entry=6, parent_event_data=parent_event_data@entry=0x0, vlr=0x5611d98862b0,
    msc_conn_ref=msc_conn_ref@entry=0x5611d9aa8150, type=VLR_LU_TYPE_REGULAR, tmsi=4294967295, imsi=0x7ffd756c1cf0 "262423403004874",
    old_lai=0x7ffd756c1ce0, new_lai=0x7ffd756c1ce8, authentication_required=true, ciphering_required=true, is_r99=false, is_utran=false,
    assign_tmsi=true) at ../../../../src/osmo-msc/src/libvlr/vlr_lu_fsm.c:1467
    at ../../../../src/osmo-msc/src/libmsc/gsm_04_08.c:443

The segfault is indirectly caused by 1fbf45c291,
'enrich context for vlr_subscr_name and ran_conn fi name', which sets auth_fsm
context, on a non-NULL auth_fsm that has been deallocated.

Change-Id: I3c528eed295be2ee673ea295804372f388a0dccd
2019-01-04 16:24:59 +00:00
Neels Hofmeyr f383d411e6 abort assignment on Assignment Failure
If Assignment fails in the BSC, trigger an EV_TEARDOWN_ERROR in the mgcp_ctx
FSM instance, so that the call gets torn down immediately. Before this, the
non-call would idle around without anything happening.

Related: OS#3236
Depends: I11b182a03f5ecb6df7cd8f260757d3626c8e945d (libosmocore)
Change-Id: I358cfbaf0f44f25148e8b9bafcb9257b1952b35a
2019-01-04 16:24:59 +00:00
Neels Hofmeyr fcf49d3f4e fix: incoming call during ongoing call
If a call is already busy and another call is coming in, do not try to
immediately assign an lchan (before this patch, it fails because there already
is an mgcp_ctx for the conn). Leave the second CC transaction waiting.

When a call is hung up, as soon as the old mgcp_ctx is discarded, look for
other CC transactions that are waiting. If there is one, trigger assignment, so
a new mgcp_ctx is set up for the new call.

This fixes the following scenario:

- from A, call B.
- from C, call B; B rings during ongoing call.
- in B, pick up the call, choose to drop the old call.

After this patch, and with osmo-bsc patch with change-id
we are now able to talk to the new caller.

I currently haven't tested yet what happens if there is *three* peers trying to
talk to the same number, running out of lab phones (not really, just not
bothering now). Possibly we should be taking over the particular call indicated
by the CC TI; instead, the current patch version takes on whichever waiting
call it finds first. This is fine if *one* additional call comes in on an
ongoing call, and this is already a huge improvement to what we had before.

Related: OS#3735
Change-Id: I0ba216b737909e92080a722db26e3577726c63cb
2019-01-04 16:24:59 +00:00
Neels Hofmeyr a35712d576 move trans->assignment_done to cc.assignment_started
The flag is set to true when an assignment has been started, and it is only
relevant for a CC transaction. So fix naming and place in cc struct.

Cosmetic preparation for I1f8746e7babfcd3028a4d2c0ba260c608c686c76 and

Change-Id: I8dacf46141ba0b664e85b0867ade330c97d8495f
2019-01-04 16:24:59 +00:00
Neels Hofmeyr b16259f9ad remove code dup: add msc_mgcp_try_call_assignment()
Various places in the code check a flag whether assignment was started and
launch it. To fix incoming-call-during-ongoing-call, I will tweak that logic.
To be able to do that only in one place, remove code dup.

Cosmetic preparation for I1f8746e7babfcd3028a4d2c0ba260c608c686c76 and

Depends: I11b182a03f5ecb6df7cd8f260757d3626c8e945d (libosmocore: LOGPFSMSL)
Change-Id: I11c0b7dc3f1a747028629b48e522bb3b864884ba
2019-01-04 16:24:59 +00:00
Max 7916ca1c2d Constify transaction helpers parameters
Change-Id: If002a1ff6ba4218cc16592946798340fcb1852ae
2019-01-04 09:38:07 +00:00
Neels Hofmeyr 1035d90c17 fix vlr ops.subscr_assoc re-association
In rare cases, a conn is already associated with a subscriber. So far, we
abort()ed on that, bringing the entire osmo-msc down. Rather log an error and
keep the service running.

In vlr.ops.subscr_assoc, add success/failure return value, and abort the
LU/PARQ on error.

I haven't figured out in detail yet why/how a subscriber would re-launch a
LU/PARQ on a conn that is already associated, so far it is merely clear that we
do not want to crash the MSC if that happens. A log is in OS#3742.

Related: OS#3742, OS#3743
Change-Id: Ic0d54644bc735700220b1ef3a4384c217d57d20f
2019-01-04 01:46:46 +00:00
Neels Hofmeyr 3350bf9f78 release RTP stream only for matching CC transaction
Do not break the currently ongoing call when rejecting a second incoming

There may be multiple (up to seven) simultaneous CC transactions, and there is
one mgcp_ctx for the currently active RTP stream.

Release the MGCP context only when the active CC transaction is releasing.
Before this patch, any CC transaction release would destroy the single MGCP
context, possibly breaking the currently ongoing call (another CC trans).

This also fixes a possible use-after-free if there were pending MGCP message
responses for the MGCP context; they are canceled properly for a released
transaction, but since one transaction would free the other transaction's MGCP
state, the clean up did not take place and possibly caused an mgcp client
response handling to access a freed mgcp_ctx.

Related: OS#3735
Change-Id: I1f8746e7babfcd3028a4d2c0ba260c608c686c76
2019-01-03 00:34:53 +00:00
Neels Hofmeyr c43b966d32 cosmetics in msc_mgcp_call_release()
Use local variables instead of writing trans->conn-> all the time.

Cosmetic preparation for I1f8746e7babfcd3028a4d2c0ba260c608c686c76 and

Change-Id: I99717b3b72a9d7cbc95455ea25b2018ec1755308
2019-01-03 00:34:53 +00:00
Vadim Yanitskiy 76ef72dda8 libmsc/gsm_04_11.c: forward MO SMS messages over GSUP
Change-Id: I7d651fde3d608d02f275a74043dc42262aabb1b8
Depends-on: (core) Ic37f3b2114b8095cfce22977e67133b9103942e3
Depends-on: (core) Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71
Depends-on: (OsmoHLR) I0589ff27933e9bca2bcf93b8259004935778db8f
Related Change-Id: (TTCN) I7abc95b8e416f7308d54e11be11c08586d18e6c5
Related Change-Id: (TTCN) Id14bbd8bd51558cdacefea0fe042769cd69ed5c8
Related: OS#3587
2018-12-30 11:48:22 +01:00