Since commit 2483f1b050 the function
gsm48_tx_mm_info() was not called anymore. No MM info messages were
transmitted to phones even if MM info messages were enabled via VTY.
With this commit, we call gsm48_tx_mm_info() after successfully
processing an IMSI ATTACH location update.
Change-Id: Ice5963d84253eb8c803cd2dfa8b25a4db5382827
Related: OS#2850
struct gsm0808_cell_id_list in libosmocore is deprecated by
https://gerrit.osmocom.org/#/c/6509/
This updates the only API user I am aware of.
Change-Id: I67377270cf3b081ac5dc9cd7b4dc28f74143753a
Depends: Ib7e754f538df0c83298a3c958b4e15a32fcb8abb
Define the struct vlr_ciph_result member .imeisv not as a char* but a char[] of
appropriate length, to avoid the need to point to external memory.
Thus fix a use-after-free in msc_cipher_mode_compl(), which defined the
imeisv[] buffer in a sub-scope within that function, so that the .imeisv
pointer was already invalid when fed to vlr_subscr_rx_ciph_res().
Did you notice that the commit summary rhymes?
Closes: OS#3053
Change-Id: I90cfb952a7dec6d104200872164ebadb25d0260d
The code deciding on whether UMTS AKA is used was cascaded and convoluted. By
flattening the decisions, they become easier to read and possibly catch more
weird corner cases / log information more clearly.
- First decide what AKA the RES length reflects.
- Then decide whether all prerequisites for UMTS AKA are satisfied.
- Finally, on UTRAN, turn down the auth if we don't have UMTS AKA, and neatly
log all of the potential causes.
One corner case that should never occur is that the UMTS AKA RES length is
actually the same length as the GSM AKA SRES. If this nevertheless occurs, log
this as an error, though not turning down authentication because of it. (The
effect is that we would favor UMTS AKA when it has a res_len == sizeof(sres)
and would not succeed to GSM AKA. At least the log will tell us why, now.)
Adjust an expected test output, trivial logging difference.
Change-Id: I43f7f301ea85e518bac91f707391a53182e54fab
Do not interpret the SRES/RES length returned in the auth response as the R99
capability bit, instead determine it from the actual Classmark information
associated with the conn.
This fixes the is_r99 flag passed in to vlr_subscr_rx_auth_resp(), which ends
up in the struct vlr_auth_resp_par dispatched to the auth_fi and influences the
authentication acceptance.
Though the effect of a wrongly-set-to-false R99 flag is not harmful in this
code path, let's not get this confused.
Change-Id: Ib7f7d89a8b9455d2c022d53d74328fa7488577f4
Instead of just closing down the conn hard, actually feed invalid auth response
data to vlr_subscr_rc_auth_resp() in order to trigger all the actions we want
to see with a failed authentication:
- a GSUP signal that the auth failed,
- a LU reject.
Verify this in new test_wrong_sres_length() in msc_vlr_test_gsm_authen.c.
Note that in gsm48_rx_mm_auth_resp(), the is_r99 flag is falsely derived from
the RES length, which upcoming commit Ib7f7d89a8b9455d2c022d53d74328fa7488577f4
will fix.
Change-Id: I4179a290069ac61d0662de4ec7ca3edb76988899
Switch by vsub->sec_ctx to use the proper Kc for ciphering.
Even on an R99 capable MS with a UMTS AKA capable USIM, the MS may still choose
to only perform GSM AKA, as long as the bearer is GERAN. The VLR already stores
whether the MS replied with a GSM AKA SRES or a UMTS AKA RES in vsub->sec_ctx.
So far, though, we were always using the UMTS AKA Kc just because the USIM and
core net are capable of it, ignoring the choice the MS might have made in the
Authentication Response.
In msc_vlr_test_gsm_ciph, fix the test expectations to the correct GSM AKA Kc
keys, showing that all of LU, CM Service Request and Paging Response now
support MS choosing GSM AKA in a UMTS capable environment.
Related: OS#2793
Change-Id: I42ce51ae979f42d173a45ae69273071c426bf97c
In gsm_silent_call_{start,stop}(), return meaningful error codes and interpret
them on the VTY to clearly indicate the result.
Change-Id: Id5abb8f2ba901689e03040af8e51483b6c618e7f
Rationale: in the HLR, it is called 'msisdn' after the database column, so a
user going back and forth between osmo-hlr and osmo-msc would appreciate being
able to type 'msisdn' in the MSC's vty as well.
Change-Id: I7b46f9736421e8edd8a95ae89e025ebe486fde4c
Before this, it was for example possible to crash the MSC by the vty 'show
subscriber' command, which would dereference a potentially stale
vsub->msc_conn_ref pointer.
Related: OS#3050
Change-Id: Ia4105d9f135ba3216ad3c86157be7658b1d568fb
When osmo-msc restarts it looses all information about the BSC. The
BSC will not be aware of the reboot and on the next communication
attemt it will notice that something is wrong and start the reset
procedure on his side. osmo-msc will receive the reset messages
and send a reset.
The reset is received. Osmo-msc detects that no context information
is created yet. The context is created. Then it is checked if the
UNITTDATA message that came in is a reset. If it is one. Nothing
happens. The UNITTDATA is passed on and triggers the RESET-ACK
some layers above. Unfortunately by the current code this also
means that no reset FSM is created and therefore a_reset_conn_ready()
can never be true. Which means it will also drop any legitimate
reset from the BSC in the future.
- Ensure that the reset FSM is always created when a new BSC
context is created
- Make sure that reset related traffic always passes so that
the higher layers can handle the procedure properly
Change-Id: I3fdcec5dbeaa0e21fd6a92568a623faa368239be
The vlr_subscr_get() can return NULL if its argument is NULL
(which isn't checked for) so before dereferencing it's result
we should check for it.
Change-Id: I13632908d0b67323202effa9dd6f29732a12cc91
Actually call msc_vlr_set_ciph_mode() and wrap away a_iface_tx_cipher_mode()
and ranap_iu_tx_sec_mode_cmd(). Hence we'll see decisions and errors in
msc_vlr_set_ciph_mode() as well.
Change-Id: Id23bc245d4b5707edcd27c44db272fbb211bf9bd
Various functions in vlr_lu_fsm.c belong to one of the four FSMs defined in
that file. After the recent error was uncovered where the lu_fsm called
lu_compl_fsm()'s termination function, I want to make sure it's correct.
Introduce distinct inline functions to dereference the respective fi->priv
pointers, each asserting that the fi indeed belongs to the proper FSM. Use
those *everywhere* to dereference fi->priv.
From this patch on, we are sure beyond doubt that we are not inadvertently
passing an fi pointer to the wrong FSM's handling functions, though we will
only catch this at runtime -- but then will immediately know the reason.
vlr_lu_fsm.c is the only file defining more than one FSM, so the other FSM
definitions are already reasonably safe.
Change-Id: I7419a780ff2d8b02efc4195bb1702818e4df181c
From the vlr_loc_update() FSM, don't call the vlr_lu_compl_fsm_failure()
function. These are two distinct FSMs with distinct priv pointers, but they are
defined in the same .c file.
In vlr_loc_upd_post_auth(), change two erratic calls of
vlr_lu_compl_fsm_failure() to lu_fsm_failure(), so that the proper fi and priv
struct are used.
Fixes: OS#2947
Change-Id: I7fd2c6fa23254fffd0d526e53541f4068153929f
Add 3-digit flags and use the new RAI and LAI API from libosmocore throughout
the code base to be able to handle an MNC < 100 that has three digits (leading
zeros).
Depends: Id2240f7f518494c9df6c8bda52c0d5092f90f221 (libosmocore),
Ib7176b1d65a03b76f41f94bc9d3293a8a07d24c6 (libosmocore)
Change-Id: I82f0016d9512ee8722a3489a3cb4b6c704a271fc
All callers pass mcc=1, mnc=1, so just have it as default.
(Prepare for net->country_code etc to be replaced by net->plmn)
Change-Id: Ibcd1cc38f170895305ae176a5574384c74a33939
The FSM (fsm_msc_mgcp) lacks a proper definition of the FSM event
names. This causes problems when inspecting the FSM using the VTY.
- Add proper FSM Event names
Closes: OS#2924
Change-Id: I6823756a63b08a71e5518130e49751aa073dbcd2
The FSM lacks a proper definition of the FSM event names. This causes
problems when inspecting the FSM using the VTY.
- Add proper FSM Event names
Change-Id: I76d7d9e0accffd433a3f3b5e5f8ab17ecd4a348c
Related: OS#2924
Call osmo_fsm_vty_add_cmds() to make osmo_fsm VTY commands available
in osmo-msc's VTY interface.
Change-Id: Iaf970f6039c3f668f275dd8c21fb9071774a5d9e
Related: OS#2967
Change I0d57ac214e574e267fa9752daf76566197b9aa64 forgot to remove this
file along with meas_feed.c.
Note also the weirdness: that patch removes the proper
include/osmocom/msc/meas_feed.h, but there's also this other one.
This libmsc/meas_feed.h always existed from the start as an unused
orphan, see:
https://git.osmocom.org/osmo-bsc/diff/openbsc/src/libmsc/Makefile.am?id=b4771a6871efb3cf12b371aedc575912984ca528
No need to drop from Makefile.am, since it is already gone from there.
(meas_feed from the old osmo-nitb (openbsc.git) has / should have moved to
osmo-bsc. There are no measurement reports in the MSC. Refer to osmo-bsc.git
instead from now on.)
Change-Id: Ib2566013dd30b21ce2774cd4cc7dcba2408f938f
The ID will include the type of connection (GERAN_A, UTRAN_IU) followed
by the SCCP conn_id.
This can be used for the fsm instance ID before we know the IMSI.
Change-Id: I4b875772e3994ad3458ee60dbf880604486d9afd
This is another left-over VTY command from the OsmoNITB days.
If such functionality is desired, it must be implemented in OsmoHLR,
but not here.
Related: OS#2528
Change-Id: Icf0897c47388e49ba7886b55acc728a6f7d213fe
OsmoMSC is using whatever reject cause is apropriate in the given
situation. This user-configurable reject cause only had relevance
in OsmoNITB, and hence it is an unused parameter that can be removed
in OsmoMSC.
Related: OS#2528
Change-Id: Ie1f39e706477aaf42051877b52d4b3ae1c5f138e
This belongs into the BSC and has no relevance in the MSC, as the MSC
has no clue about dynamic timeslots.
Related: OS#2528
Change-Id: Iaa41d22db81120572d4cd2c0c4c75d258947a42f
When we receive bearer capabilities from MNCC and encode thme into
a CC message, we have to also update our "cache" inside 'struct
gsm_trans'. Only that way, the BSSMAP ASSIGNMENT code is aware of
the actual current/present bearer capabilities such as permitted speech
codecs.
This will in practise only work if the related CC/MNCC message with
berer_cap IE will happen before the MSC performs the BSSMAP ASSIGNMENT
procedure. Our logic still needs to change in a way that the CC/MNCC
code in gsm_04_08.c detects if trans->bearer_cap != new bearer_cap, and
in that case triggers a new follow-up BSSMAP ASSIGNMENT.
Change-Id: I6838dc0c8c4c2c6bba385da548c92f3fc91060c1
Closes: OS#2854
When we receive a MNCC_SETUP_REQ primitive from the external MNCC
handler, we must not only encode it into the TS 04.08 CC SETUP, but
also keep it around in the "trans" structure representing this voice
call, as it is needed e.g. at BSSMAP ASSIGNMENT time.
Change-Id: Ib6919d148ff6687112e8166dbde947be19e70a76
Related: OS#2322
Closes: OS#2929
There is no encoding of speech version / preference on Abis, only
on L3. L3 is carried on Um, Abis and A. Hence, referrin to Abis
in function names and comments is irritating.
Change-Id: Id226cd1414ca2a92356801bc71f43102d03ba37e
We cannot use conn->a.conn_id after conn has been free'd inside
msc_clear_request(). Let's store conn_id before that call to
ensure we avoid an use-after-free situation.
A more elegant (but more intrusive) solution would be to
move the SCCP connection clearing into the FSM itself.
Change-Id: Ibe41aa503e9f7cbeb05dce4b1a20b3eac85e619f
Closes: OS#2922
As in GSM/3GPP networks emergency calls carry no explicit destination
number/address, add a VTY commadn to patch in some destination handler
in the EMERGENCY SETUP before delivering to [internal or external] MNCC.
Change-Id: I7c9f43ba312fadda2b9a9483b3cf50e4abca9599
When we receive a msgb-wrapped primitive from the SCCP provider (stack),
it transfers msgb ownership to us (the SCCP user). The existing code
passed the msgb ownership down into all the various downstream
functions, which each then had to take care of msgb free'ing.
Not all of the paths did eventually free the msgb. And at least one
path used data from the primitive *after* the free
Let's restructure this in a way that no msgb ownership is transferred
down the call chain. Instead, there's one common msgb_free() in
sccp_sap_up(). We can do this as nobody is queueing or otherwise
keeping the msgb.
Change-Id: Ie65616ccb55ec58a0224bbe3c8e004e6029ef3e6
SUMMARY: AddressSanitizer: heap-use-after-free /home/laforge/projects/git/osmo-msc/src/libmsc/a_iface.c:538 in sccp_sap_up
Having all BSSAP related logs in the "DMSC" category is overly
generic, and dosn't provide useful granularity.
Change-Id: Id1e52dad03840dfd026fb23f3845a8771c8cc308
There's little point in resolving the gsm_subscriber_connection in each
and every function handling connection-oriented messages. We can
resolve it once and dispatch the already-resolved conn into the
function, instead of passing the raw sccp_user and a_conn_info.
Change-Id: Iea85527ea4d4cde7b36cc28a8027362c1570518f
Clean up the log statements in a_iface*.c, which was very inconsistent.
For example "BSC sending" is very confusing. We are receiving from the BSC,
and it did already send the message, it is no longer in the process of
sending it if we have already received it in the MSC.
Change-Id: Id50e964d86713ae506d4e7657159797e09501d99
During normal operation, regular messages occurring during processing
of a call / transaction should not be higher than LOGL_INFO.
Change-Id: Ibd04ade47b249406696c7d0b660474afc4f4adee
If the BSC is contacting us for the first time and sending a BSSMAP
RESET, then we should simply ACK that and transition into the
"connected" state, where connection-oriented and connectionless
procedures are permitted.
This patch is a bit large for such a seemingly simple behavioural
change, but the existing data model didn't permit a more
straight-forward implementation.
Change-Id: Ie67e7ed20a6c42afe99bafef96d85a4e083dd057
Closes: OS#2914
Using this argument we can create the state machine in the
"already connected" state, i.e. without starting an outbound
RESET procedure.
Change-Id: Ibf569d57300965cd47084fa0bff54aa67679e2a1
It is quite important to have some way of runtime state introspection
about the major objects inside osmo-msc. This patch adds some basic
capabilities to dump the most important information about
subscriber_connections and transactions (like calls/sms).
OsmoMSC> show connection
--ConnId ------------Subscriber RAN --LAC Use --Tokens CSA A5 State
00000001 IMSI:26242000000006 A 23 1 00000004 --- /0 SUBSCR_CONN_S_COMMUNICATING
Change-Id: I1c457c1eac20188f67b8379a36cfda3a085fcef4
The MGCP FSM implements a timeout when waiting for the RAN to complete
the call (assignment complete, alerting, connect...). This timeout
is currently set to 10sec. This means if the other end did not pick
up after 10sec, the MGCP connection will be lost while the phone keeps
ringing. When the other end finally picks up, the call gets
disconnected.
This behavior is odd and requires a proper fix. For now increasing the
timeout to 120sec. will decrese the probability that he problem occurs.
- Increas RAN timeout to 120sec (2 min).
Change-Id: I5a11d53f9701d9b11b18d7026ff2241c7c0b57f5
Check and handle gracefully any error which might appear in
osmo_gsup_encode() - mark corresponding functions with
warn_unused_result attribute to make sure this failure is always checked
against.
Change-Id: I4551212011fb0bd898c020a183756ed7a9afb9e5
Related: OS#2864
We don't usually put space before in-place increment or decrement. Let's
make code look similar to other Osmocom projects.
Change-Id: I5962431ad16c97e412939dc1b8949f6361a5c26e
in the current implementation we still use osmo-bsc_mgcp, which
has many problems and is also obsoleted by osmo-mgw.
integrate osmo-mgw and re-implement the current switching using
an osmo fsm.
Depends: osmo-mgw Iab6a6038e7610c62f34e642cd49c93d11151252c
Depends: osmo-iuh I3c1a0455c5f25cae41ee19229d6daf299e023062
Closes: OS#2605
Change-Id: Ieea9630358b3963261fa1993cf1f3b563ff23538
Using following semantic patch:
@@ expression A, B, C; @@
- osmo_strlcpy(A, B, sizeof(A));
+ OSMO_STRLCPY_ARRAY(A, B);
Which was applied using following command:
spatch --dir src -I src --sp-file strlcpy.spatch --in-place --recursive-includes
All the calls to osmo_strlcpy() which use destination buffer obtained
via sizeof() were replaced with the corresponding wrapper macro.
Change-Id: I67b482dedfa11237ac21894fc5930039e12434ab
Related: OS#2864
According to TS 24.007 Section 11.2.3.2.3, it is possible that uplink L3
messages are duplicated in some scenarios, particularly during
assignment/handover procedure.
To avoid L3 entities from seeing duplicated messages, there's a modulo-2
or modulo-4 message sequence counter, based on which the MSC can detect
and suppress such duplicate messages.
It appears that even our unit tests were wrong in that regard so far.
Rather than manually adjusting each and every message, let's make sure
that the sequence number generation always increments as expected, and
that during matching of incoming messages, sequence numbers are masked
out.
Note: the tests will only pass from libosmocore Change-Id
Iec875a77f5458322dfbef174f5abfc0e8c09d464 onwards, due to
gsm48_hdr_msg_type() being broken in earlier versions.
Change-Id: Id15e399ab7e1b05dcd426b292886fa19d36082b1
Closes: #2908
Make the submit_to_sms() funcion aware of the message mode. If the
message does not require real-time "transactional/forward mode" we
can store it in the SMS database even if subscriber B cannot be
found in the VLR at this point in time.
This should should make the esme_ms_sms_storeforward test in
osmo-gsm-tester pass (a tweak to this test's expectations will
be needed as well, because the test currently assumes that an
invalid phone number for subscriber B will fail immediately,
rather than cause the message to eventually expire).
Change-Id: Ic3d78919568ad9252b4d19c3ddab5068d1c52db2
Related: OS#2354
There's no point of ever asking a MS to perform ciphering using an
algorithm it advertises no support for. Let's hence use CLASSMARK
information to figure out the intersection between MSC policy (VTY
command) and MS-reported CLASSMARK.
Change-Id: Id124923ee52a357cb7d3e04d33f585214774f3a3
So far, the administrator had to pick one particular cipher which
would then be used throughout all subscribers/phones. This is a bit
impractical, as e.g. not all phones support A5/3. Extend the VTY
command syntax in a backwards-compatible way to permit for multiple
ciphers.
NOTE: Like the previous code, OsmoMSC does *not yet check* whether
the configured cipher is compatible with the MS capabilities as
reported in CLASSMARK! The network hence might choose an algorithm
not supported by the phone. Fixing this is subject to another patch.
Closes: OS#2460
Change-Id: I79a4e2892eb5fbecc3d84e11dceffb7149db264b
The VLR code seems to have the assumption that there is one particular
algorithm to be used, as opposed to one of a set of algorithms.
What's missing is basically to decide when/where to pick the best
algorithm within the capabilities of the phone (classmark) and the
network configuration (net->a5_encryption_mask). So far, libvlr has no
notion of classmark. Rather, libmsc has.
Why does the VLR care about the particular algorithm at all? The VLR
should probably simply decide if it should use encryption or not, and if
so, the MSC will figure which algorithm to use.
Change-Id: I5ed80ca2086560a5975a758ec568a034a9a8ab89
Delete expired SMS whenever we are done processing an SMS-related signal.
In order to minimize additional latency only one SMS is removed at a time.
Change-Id: I56cbe716e52b679c4b94f6cbb4a171306975be2e
Related: OS#2354
Accept any SMS and store it in the database, even if the receiver of
the message cannot be determined when the message arrives at the MSC.
This fixes https://osmocom.org/issues/2354 ("SMSC: Store&Forward not
working for subscribed but unregistered MS").
Change-Id: I833c3abd290d2bc5fceec7457e3933c9600e6c24
Depends: Icd6093b7b5d8db84b19a0aa47c68182566113ee2
Depends: I56cbe716e52b679c4b94f6cbb4a171306975be2e
Depends: Icf786f9b1efabfe7407fb6414ec0d326d8f7244a
Related: OS#2354
We already delete SMS which have been sent successfully. However, there
are plans to accept SMS for any subscriber in order to fix the problem
described in https://osmocom.org/issues/2354 ("SMSC: Store&Forward not
working for subscribed but unregistered MS").
This means we may end up storing SMS which never get sent, e.g. because
the B subscriber doesn't actually exist. This could lead to a higher
degree of SMS database growth over time, and therefore we need a way
to keep database size under control.
As a first step, introduce a DB function which removes an expired SMS,
and add a VTY command which removes all expired SMS from the DB.
Later commits will build upon this to remove expired SMS automatically.
The SMS expiry time period is currently hard-coded to 2 weeks.
We could make this configurable in the future if desired.
Change-Id: Icd6093b7b5d8db84b19a0aa47c68182566113ee2
Related: OS#2354
osmo-msc still had large amounts of dead code that came along from
openbsc.git. This commit removes a lot of it, mostly stuff relevant
only to the BSC side of things (or even GPRS).
Change-Id: I247def85da2dc3ec461389fb74414a0d964e7e3c
Related: OS#2528
We don't have BSC or GPRS related logging filters here.
This is a leftover from the NITB->MSC split
Change-Id: I05f991d1f5b7f89545521a73d79619bee4111094
According to TS 44.008 Section 3.2.1.31, the "Layer 3 Message Contents"
IE of the BSSMAP Cipher Mode Complete is optional. The BSC may hence
inlcude that IE or not include it.
Without this patch, OsmoMSC is crashing if that IE was missing:
<000a> a_iface_bssap.c:699 Rx BSC DT: 00 03 55 2c 02
<000a> a_iface_bssap.c:629 Rx MSC DT1 BSSMAP CIPHER MODE COMPLETE
<001f> a_iface_bssap.c:91 Found A subscriber for conn_id 1
<000a> a_iface_bssap.c:415 BSC sends cipher mode complete (conn_id=1)
==5611== Invalid read of size 8
==5611== at 0x128D0F: msc_cipher_mode_compl (osmo_msc.c:159)
==5611== by 0x114F62: bssmap_rx_ciph_compl.isra.8 (a_iface_bssap.c:432)
==5611== by 0x113267: sccp_sap_up (a_iface.c:520)
Change-Id: I722f9b468b157b3736918f090daaa9489a6028ee
Closes: OS#2871
Even if we're not implementing CM re-establishment, we should give
the MS a clear indication that we don't do and follow the related
procedures of TS 24.008 by sending CM SERVICE REJECT.
Closes: OS#2869
Change-Id: I1c0473647295456fd635b8df6079ee48695dcf2e
Measurement reporting (and the relate feed) are functions of the BSC,
not the MSC. This code should never have been inherited from OsmoNITB
to OsmoMSC in the first place, let's remove it.
Change-Id: I0d57ac214e574e267fa9752daf76566197b9aa64
When we receive a CM Service Request, OsmoMSC should eventually verify
what kind of service it is the phone requests, and whether we support
that service.
Change-Id: I499730d760dc9ac7f599e09959c6eac4452f2eab
Closes: OS#2668
OsmoMSC rejects an Emergency Call with IMEI as mobile identity with
"semantically incorrect message" which is clearly wrong. According to TS
24.008 4.5.1.5 we should reject with cause 5 "IMEI not accepted"
Found with TTCN-3 test case MSC_Tests.TC_emerg_call_imei
Change-Id: I2f7ab0e32b914a112c0b17c523d149ccd0299099
Closes: #2866
MNCC has a MNCC_F_EMERGENCY flag to indicate that the mncc.emergency
field is present. However, OsmoMSC never sets this flag.
Change-Id: I0ebd8f88e483172988f4a0cb0636b4160688d8ad
Closes: OS#2865
An emergency call should be logged different from a normal call,
and we also increase the log level from INFO to NOTICE in such a
situation.
Change-Id: I83f3b8bd0aeda70f03aa7b8d264a9008d10d5687
There appears to have been no input validation whatsoever on MNCC
messages. Hence it was very easy for an external MNCC handler to
crash OsmoMSC, such as in OS#2853
Change-Id: Idaf3b8e409c84564b1eb26d01a19c605f89b14f4
Closes: OS#2853
Quote the argument to sqlite's datetime(). Otherwise, the timestamp
stored in the database reads back as a negative value for some reason.
Before:
1032 validity_timestamp = dbi_result_get_datetime(result, "valid_until");
(gdb) p validity_timestamp
$2 = -1516814654
After:
1032 validity_timestamp = dbi_result_get_datetime(result, "valid_until");
(gdb) p validity_timestamp
$2 = 1516814654
Change-Id: Icf786f9b1efabfe7407fb6414ec0d326d8f7244a
As the include file gsm_data.h is generic (does not depend on osmo-iuh0s
iu_client.h), rab_assign_addr_enc is declared as "int" instead of "enum ranap_nsap_addr_enc".
osmo-msc/src/libmsc/msc_vty.c: In function ‘msc_vty_init’:
osmo-msc/src/libmsc/msc_vty.c:212:30: warning: passing argument 2 of ‘ranap_iu_vty_init’ from incompatible pointer type [-Wincompatible-pointer-types]
ranap_iu_vty_init(MSC_NODE, &msc_network->iu.rab_assign_addr_enc);
^
Change-Id: I1b63ee350911bdf772a2324fff55035275a455c4
Compute a validity timestamp based on SMS validity time.
Store the computed value in the database and recompute the validity
time when an SMS is read from the database.
Change-Id: Id27c250d3a64cd109416450e8ca155b18a8b9568
Currently the SMS database keeps accumulating entries for each SMS.
These entries are never deleted automatically. With this change, we
start deleting SMS which have successfully been sent to subscriber B.
Change-Id: I3749855fe25d9d4e37ec96b0c2bffbc692b66a78
If we cannot open a connection to the sqlite3 database, show the name of the
database we failed to access, and also hint at the fact that a likely reason
for the problem is a missing sqlite3 driver for libdbi.
Change-Id: If1c0026e882984b4358ce116ec4a7ad40340517c
There is no any significant reason to define static function
'send_own_number' after the code that calls it.
Change-Id: I7f76f278c09489dccd96921610e8d06efa679ff2
* move log helpers to generic header
* log subscriber update
It's handy for troubleshooting issues with subscriber update via GSUP
from HLR.
Change-Id: I1958aeeb3ea99831c7e2c5ee9a6b59834baf4520
The expire_lu is never used but is printed for every subscriber. Let's
remove it to avoid confusion.
Change-Id: I6f7ad1670836384d1e6a58f47a13464fdbbf8509
This avoids potential licensing incompatibility and makes integration of
Debian packaging patches easier.
Related: OS#1694
Change-Id: I71cd631704a4dc155c6c752fee2a42cd6e2fa336
It's not clear cut which code is responsible for canceling pending requests,
since the requests list is kept in vlr_subscr, but sending out Paging does
certainly not belong in the VLR. Place the requests cleanup in gsm_04_08.c.
Add to test_ms_timeout_paging() in msc_vlr_test_ms_timeout.c to verify that a
pending paging is canceled on IMSI Detach.
Change-Id: Ib8874a9d92f02b0826525b55518332f6899688fd
Currently, if there is no reply from the BSS / RNC, a subscriber will remain as
"already paged" forever, and is never going to be paged again. Even on IMSI
Detach, the pending request will keep a ref count on the vlr_subscr.
Add a paging timeout, as gsm_network->paging_timeout and in the VTY on the
'msc' node as 'paging timeout (default|<1-65535>'. (There is a 'network' /
'T3113' in OsmoBSC, but to not confuse the two, give this a different name.)
Add test_ms_timeout_paging() test to verify the timeout works.
I hit this while testing Paging across multiple hNodeB, when a UE lost
connection to the hNodeB. I noticed that no matter how long I wait, no Paging
is sent out anymore, and found this embarrassing issue. Good grief...
The choice of 10 seconds is taken from https://osmocom.org/issues/2756
Change-Id: I2db6f1e2ad341cf9c2cc7a21ec2fca0bae5b2db5
These rx functions are only used for the A interface, hence the names should
not suggest general SCCP rx (which Iu also has).
Change-Id: I6815c3d4dea4c2abfdff1cf0239ada6a9254f351
Add LOGPBSCCONN for struct bsc_conn.
Use LOGPCONN or LOGPBSCCONN whereever possible.
Tweak a few log messages and remove one redundant log.
Change-Id: If9cb0e7a5cef2ec37a1a7c548aecf11a11c22eec
The target buffer in libsmpp is 16 bytes long, and snprintf() may omit the
terminating zero. There seems to be no handling for unterminated strings, so
osmo_strlcpy() is the safer (and presumably more optimal) choice.
Change-Id: I5845666201f945ea9f83da62f2dd4bec52eb74cf
In case of UMTS AKA, the Kc for ciphering must be derived from the 3G auth
tokens. tuple->vec.kc was calculated from the GSM algorithm and is not
necessarily a match for the UMTS AKA tokens.
So far we were always sending the Kc retrieved from osmo-hlr. If the 2G auth
algo is set to milenage, the 2G Kc coincides with the one derived from 3G
tokens, but if 2G is set to a different algorithm, the Kc received from the
osmo-hlr is not usable for ciphering when UMTS AKA was used for authentication
(on R99 capable GERAN and MS).
Implementation: To decide whether to use UMTS AKA derived Kc or the Kc from the
auth vector, use the umts_aka flag added to set_ciph_mode() in a previous
patch. Use osmo_auth_c3() to derive the GSM AKA Kc from the UMTS AKA CK and KI.
Related: OS#2745
Requires: I85a1d6ae95ad9e5ce9524ef7fc06414848afc2aa (libosmocore)
Change-Id: If04e405426c55a81341747a9b450a69188525d5c
In case of UMTS AKA, the Kc for ciphering must be derived from the 3G auth
tokens. tuple->vec.kc was calculated from the GSM algorithm and is not
necessarily a match for the UMTS AKA tokens.
To decide (in an upcoming patch) whether to use UMTS AKA derived Kc or the Kc
from the auth vector, the set_ciph_mode() from vlr_ops needs to know whether
UMTS AKA is being used. This could possibly derived from the msc_conn_ref, but
all flags are already available in the vlr_lu_fsm and vlr_access_req_fsm. Hence
add a umts_aka flag to the set_ciph_mode() callback invocation. The VLR FSMs
thus decide whether UMTS AKA or GSM AKA is to be used during Ciphering Mode
Command, which makes more sense than re-implementing the same decision process
in the MSC.
I considered placing the Kc derivation in vlr_set_ciph_mode() and only tell the
MSC's set_ciph_mode() implementation the precise keys it should use, but the
RAN particulars, and whether a Kc is used at all, rather belong with the MSC.
Related: OS#2745
Prepares: If04e405426c55a81341747a9b450a69188525d5c
Change-Id: I983c48347faf4ee1b405d8174b4e006c904157cf
During Set Ciphering Mode on GERAN, it is required to know whether UMTS AKA is
used to decide which Kc to pick. Change static function is_umts_auth() into
public vlr_use_umts_aka(), so future patches can re-use it.
Prepares: If04e405426c55a81341747a9b450a69188525d5c
Change-Id: I85d784c62ecbabdb6186a3dae4dcd554e7921041
a_iface_tx_cipher_mode() is a bit too far away from the VLR to be handling its
ciphering enums. Instead, construct the gsm0808_encrypt_info in the
msc_vlr_set_ciph_mode() callback.
Greatly simplify the sanity checking code: a_iface_tx_cipher_mode() no longer
needs to re-verify the presence of the gsm0808_encrypt_info contents.
Change-Id: Id46f9a513b555d0a481f7124c9984c2b5b196b3e
The bit shifting is performed in gsm0808_enc_encrypt_info(), and must not be
done when populating the gsm0808_encrypt_info struct.
Provide vlr_ciph_to_gsm0808_alg_id() to translate the enum vlr_ciph to the
GSM0808_* constants we need to put in the gsm0808_encrypt_info struct instead.
Related: OS#2745
Change-Id: If75f95e8a5cc8b9979610ce6d746c1f0073ee39a
When the subscriber has no MSISDN, we might construct an invalid SQL statement
such as
... AND dest_addr= AND ...
Instead, don't even query for empty MSISDNs.
Related: OS#2706
Change-Id: I7d6169d774b2da04b3051957e364fe620feed51e
The commandline option -m has already been deprecated before the
split. Use the split as an opportunity to get rid of this option.
Change-Id: Ie23d492a839aae85470e39b0d0ad8f57b0d38f7e
The log output of the reset FSM duplicates lots of the built in
FSM log output.
Remove duplicate logging, use more expressive log messages where
needed.
Change-Id: Ie031d947a5b8097bd656c0271081af215605ba02
Adjust test expectations accordingly.
The error was:
==16084==ERROR: AddressSanitizer: heap-use-after-free on address 0x61500000f5f4 at pc 0x561be639ac2b bp 0x7ffc0aabbe40 sp 0x7ffc0aabbe38
READ of size 4 at 0x61500000f5f4 thread T0
#0 0x561be639ac2a in _msc_subscr_conn_put ../../../../src/osmo-msc/src/libmsc/osmo_msc.c:384
#1 0x561be636070b in rx_from_ms ../../../../src/osmo-msc/tests/msc_vlr/msc_vlr_tests.c:204
#2 0x561be6360b21 in ms_sends_msg ../../../../src/osmo-msc/tests/msc_vlr/msc_vlr_tests.c:217
#3 0x561be635b40a in test_call_mt ../../../../src/osmo-msc/tests/msc_vlr/msc_vlr_test_call.c:328
#4 0x561be6363bb7 in run_tests ../../../../src/osmo-msc/tests/msc_vlr/msc_vlr_tests.c:802
#5 0x561be63524ea in main ../../../../src/osmo-msc/tests/msc_vlr/msc_vlr_tests.c:849
#6 0x7f6eebb3e2b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#7 0x561be6352fb9 in _start (/n/s/osmo/make-3G/osmo-msc/tests/msc_vlr/msc_vlr_test_call+0xdafb9)
Related: OS#2672
Change-Id: If0659a878deb383ed0300217e2c41c8c79b2b6a5
If a conn is attempted to be used when in release, log an error, but don't skip
tracking.
No current code path apparently hits this, according to msc_vlr_tests. Just
making sure that we will prominently see such errors when we introduce any.
Change-Id: I8dd20ee56ce5ad7a90fcd03a06604c383e5eed54
When hunting a conn use count bug, it was very hard to figure out who's (not)
using the conn. To ease tracking down this bug and future bugs, explicitly name
what a conn is being reserved for, and track in a bit mask.
Show in the DREF logs what uses and un-uses a conn. See the test expectation
updates, which nicely show how that clarifies the state of the conn in the
logs.
On errors, log them, but don't fail hard: if one conn use/un-use fails, we
don't want to crash the entire MSC before we have to.
Change-Id: I259aa0eec41efebb4c8221275219433eafaa549b
We usually have both A and IuCS on 0.23.1, using differing SSNs.
0.23.2 was used only if there was a separate cs7 instance for Iu, which is not
practical, and even if used does not conflict with 0.23.1 (since it would be on
a different STP).
Just use 0.23.1 for all SCCP clients.
This needs adjustment of
https://osmocom.org/projects/cellular-infrastructure/wiki/Point_Codes
Change-Id: I3d5466eff5680cb5aa95a76a9e179fdf88ce8aa0
The BSC rate counters are a leftover from the nitb split.
Accessing them would result into a null-pointer exception,
because the struct isn't initialized.
Change-Id: I8c72ab8bf781d3f9a436eb1a27ac4d13df5e656b
Terminating one of the FSM instances may effect termination and deallocation of
the others, as well as the vlr_subscr itself. So, reserve the vlr_subscr
locally, and then dispatch events to exactly those FSM instances that exist.
The changes in expected output in the msc_vlr_tests shows that the subscriber
was deallocated from the first FSM termination, and now sticks around until
we've checked both FSMs are gone.
Change-Id: I56551ecc10f5295fe75944bdde4b583b1b621811
If dispatching a conn timeout, the conn fsm will already have been discarded,
and we cannot fire any more events to it.
The expected test output changes illustrate that we are now omitting event
dispatches that happen *after* the same FSM was already deallocated.
Change-Id: I25af3e5a1b04e3a5c9f41956cbcbbdd8439c6457
osmo_gsup_decode() doesn't actually decode everything, it does leave quite a
number of pointers into the original msgb. Hence we must not deallocate the
gsup msgb before dispatching GSUP events.
Move msgb_free() to the bottom of vlr_gsupc_read_cb() and use rc and gotos to
early-exit if needed.
Change-Id: I16fc92dcf84e29fcf34712a2e8b0464ef08425ad
When sub_pres_vlr_fsm_start() is called, it dispatches an event which may in
some cases already cause tear down and free of the parent FSM instance, after
which storing the returned instance pointer in that parent's metadata will use
freed memory. Instead, pass the target pointer to remember the instance at to
sub_pres_vlr_fsm_start() and assign the pointer *before* firing the event.
Explain so in a new comment.
I haven't checked whether that pointer is actually used at all -- this is the
easiest way to fix the use-after-free without getting sucked into semantic
questions.
Change-Id: Ibdc0b64cd12ba3e2b9737e3517d8484e67abcf04
The log message after the nullpointer check for conn tricks Coverity
Scan into detecting a nullpointer deref.
Include the log message into else branch to state the program flow
more clearly
Fixes: Coverity CID#178656
Change-Id: If6e962f4033c955ecd3539a719031a83c9b6205a
The reset context contains a string buffer to allow for setting
a human readable name, that is then displayed in the logs. Since
OSMO-FSMs already have such a feature there is no need for an
extra name variable.
Use LOGPFSML and the name parameter of osmo_fsm_inst_alloc()
to display the name of the FSM
Fixes: Coverity CID#178664
Change-Id: I5b051606791c5e085ca6bb1be20592127d48ceb5
Wen there's no SMPP support compiled in, and routing was successful,
we shouldn't return an uninitialized value.
Change-Id: I4abbbb5ab336a7e8da08d682f396baec3b56fa3a
Fixes: Coverity CID#174176
Stefan Sperling
Philipp Maier
Daniel Willmann
Pau Espin
Harald Welte
Alexander Huemer