Age | Commit message (Collapse) | Author | Files | Lines |
|
Change-Id: I18dfd08ea0857f2751164a295dd9de20a2024ac3
Fixes: CID#190874
|
|
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
|
|
Change-Id: I8a15c9baae2071569e2ecc4635ddaf5a0001f959
|
|
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
|
|
Change-Id: I52787120d5ec59897329d28eab28e0fda3d0f44f
|
|
Change-Id: I80238d89e95b6fd791961c48de80aac69ff5b0e9
|
|
Change-Id: I2d3a6334f49989bedbb1430d26ffad8b61dfd873
|
|
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.
Change-Id: Id2321e4cb3800929cea56785e5c5bd7480408806
|
|
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
|
|
Change-Id: I09515aea9da8e2b5836c5c6409f094fae05633d4
|
|
Change-Id: Ia28ba52b0ea4771843a2a1faa346f7357604b8aa
|
|
Log transaction allocation errors as such. While at it, use proper
subsystem to log missing VLR subscriber.
Change-Id: I617be8793b9416ccd49022c72f7d93df7f4fb4d9
|
|
Change-Id: Ibf5f9cad1f70aee56d5bca8fe09a24ca417e7a63
Related: OS#2487
|
|
Change-Id: I624144d6f8919d1dd237cdffc9122f685a8e4d6b
|
|
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
|
|
Change-Id: I59d032ad953438f12439ac3d6275ee78d0ebbb40
|
|
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
|
|
Change-Id: Id3fa3f26c333bf445590fd75ad7a08be68fed3e2
|
|
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
|
|
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
|
|
There's no need to use 'void *' because we have forward declaration for
'struct gsm_network' in the very same header.
Change-Id: I5078ffcf2706adaca1b5df107f8b6a44062ca28c
|
|
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
|
|
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
|
|
Change-Id: Ica5e498e03d0a157a661e428dfd68739f572d073
|
|
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
|
|
Change-Id: Icbf099e418281eb908e7916503f178ab7ea26ffe
|
|
Change-Id: Ia06245f3adc6cf4c483d9c12c387cd5169582353
|
|
Change-Id: Icb18e0f0bb420de066e7eb8fc683f192ba2a7368
|
|
Instead of
MGW(MGW_99)
use a name of
msc-mgcp(MSISDN:2331_GERAN_A:00000017_trans99)
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
|
|
Change-Id: I6bb053def223ed698351ad9f52c1e36293df5d59
|
|
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:
Process_Access_Request_VLR(IMSI-901700000014706:MSISDN-2023:TMSI-0x08BDE4EC:GERAN-A-3:PAGING_RESP)
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
GERAN_A-00000017
becomes
GERAN-A-23
- 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
|
|
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
|
|
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
|
|
Change-Id: Ib562bb5fb272c0c3ae0849f32b28faa2c26f9bb7
|
|
Change-Id: I57357982ca0e51f6722c24a4aa1d0fb3e6caef88
Depends-on: (core) Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71
Depends-on: (OsmoHLR) I0589ff27933e9bca2bcf93b8259004935778db8f
Related Change-Id: (TTCN) I63a25c8366cce0852df6b628365151661a22a25f
Related: OS#3587
|
|
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
|
|
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
|
|
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
|