Overlong IMSIs in ID RESP messages were accepted and used in
truncated form.
Log an error when truncation occurs, and prevent truncated IMSIs
from being installed for a subscriber via ID RESP messages.
Other code paths leading to vlr_subscr_set_imsi() with truncated
IMSIs will only a leave a trail of log entries for now, because
vlr_subscr_set_imsi() is currently unable to return an error code.
Change-Id: I785c994f41a646d8d83d3d82f5a9ae6b572eb641
Related: OS#2864
Remove subscribers which fail to send periodic Location Updates from the
list of subscribers known to the VLR. This complements the IMSI detach
procedure: periodic LU expiry triggers an implicit IMSI detach.
Expired subscribers are purged from a periodic timer which iterates
over all subscribers once per minute.
Subscribers with an active connection do not expire. This is controlled
by the subscriber conn FSM which sets a subscriber's the LU expiry timeout
value to GSM_SUBSCRIBER_NO_EXPIRATION while a connection is active.
Add support for fake time with osmo_clock_gettime() to msc_vlr tests.
This functionality existed in OpenBSC but was lost during the nitb split.
This code took some inspiration from the OpenBSC implementation.
Related: OS#1976
Change-Id: Iebdee8b12d22acfcfb265ee41e71cfc8d9eb3ba9
The FSM that controls the VLR ACCESS uses cause code 9
(GSM48_REJECT_MS_IDENTITY_NOT_DERVIVABLE) to signal that the
identity of the MS is currently not known in VLR (MSC-Reboot)
However, this cause code is from the GMM domain and is interpreted
as GSM48_REJECT_SRV_OPT_TMP_OUT_OF_ORDER by the MS, which cauese
the MS not to make a new LOCATION UPDATE on CM SERVICE REQUEST
- use GSM48_REJECT_IMSI_UNKNOWN_IN_VLR and
GSM48_REJECT_IMSI_UNKNOWN_IN_VLR instead of
GSM48_REJECT_IMSI_UNKNOWN_IN_VLR
Change-Id: Ic058c93387f9be9af4940f8961839c02b93ee370
Closes: OS#3266
The only reason to use int instead of the enum was the lack of header
iu_client.h when not building with Iu support. Rather use the configure result
properly, include the header when Iu support is built and use the proper enum.
Omit the entire iu sub-struct when building without Iu.
Add LIBOSMORANAP_CFLAGS to libvlr, in order to find the iu_client.h header (now
also included from gsm_data.h).
Rationale: Instead of using a questionable typecast from int* to enum*, we can
now use the enum member directly without needing to silence compiler warnings.
Change-Id: Ic9f8bf53f4b605c166e84cd7edd90c10fe7d7a1f
Instead of keeping separate enums for FSM results and translating between those
and the actual 04.08 reject causes that will ultimately reach the MS, just pass
enum gsm48_reject_value cause codes around everywhere.
Collapse some VLR *_timeout() and *_cancel() api to just *_cancel() with a
gsm48 cause arg.
(Hopefully) improve a few reject causes, but otherwise just aim for more
transparent decisions on which cause value is used, for future fixes of
returned causes.
Depends: I6661f139e68a498fb1bef10c266c2f064b72774a (libosmocore)
Change-Id: I27bf8d68737ff1f8dc6d11fb1eac3d391aab0cb1
Drop tall_bsc_ctx; in mncc_sock_init(), talloc the mncc_sock_state from
gsm_network.
In tests or utils, move from using an extern tall_bsc_ctx to a local root
context pointer.
Change-Id: I92c252be1d1e7634f1653de47d37c99d77d9501c
Also indicate in msc_vlr_test_gsm_authen.c that we're indeed sending no
capability to do R99 in the Classmark 1 during LU request.
Change-Id: Id79a77ca1f218d55dad21d9dd3de92445fb5d6bf
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
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
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
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
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
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
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
* 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
This avoids potential licensing incompatibility and makes integration of
Debian packaging patches easier.
Related: OS#1694
Change-Id: I71cd631704a4dc155c6c752fee2a42cd6e2fa336
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
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
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
When using ciphering, the TMSI is an important part of the ciphering. To guard
against users forgetting to set 'assign tmsi' in the config and compromising
their ciphering unknowingly, the default should be to use a TMSI.
To optimize in an unencrypted network, 'no assign tmsi' config can still switch
off TMSI use.
Change-Id: If115e95bebc314bedb50faf3993b52071fee5c1e
The name auth_tuple_max_use_count suggests that if I want to use each auth
tuple exactly once, I need to set it to 1. Curiously, so far you need to set
to intended uses - 1.
Reflect this in its name by renaming to auth_tuple_max_reuse_count.
I first considered to not rename but change the if-conditions so that == 1
means each tuple is used once, and upon struct vlr allocation, set the default
to 1. That would also logically entail that setting to 0 means to re-use
vectors infinitely often, like now a value < 0 does. That means, when
allocating a vlr struct zeroed out, we would by default have the most
dangerous/unsafe configuration. It's no problem to set a default to 1 upon
allocation, but by renaming the variable instead, we get safer alloc-zero
behavior and don't need to change any conditionals in the code (even though the
patch ends up considerably larger from all the renaming).
Change-Id: I0b036cae1536d5d6fb2304f837ed1a6c3713be55
In vlr_core.h, "pre-declare" a struct used in function declaration.
In vlr_lu_fsm.c, gsup.h is not used, drop the #include.
Change-Id: I61d793c3001abbe6d381be1ae0bb350b07403e88
Add required msgb_free() to vlr_gsupc_read_cb().
Adjust msc_vlr_tests.c gsup_rx() to *not* free the msgb again after
vlr_gsupc_read_cb() did.
Related: OS#2476
Change-Id: I347c53f57a7fa79921aed3f6e42599841acf27c0
The MSC should not fiddle with low-level SI details like rest octets
anyway. Unfortunately simply removing the header is impossible as it
causes massive fallout due to missing includes. Fixed it as well.
The only other parameter which required removal is cell_ro_sel_par which
is not referenced anywhere in the code anyway.
Change-Id: Ibff77330de056fad4288cd4c48d016aad8105354
osmo-nitb becomes osmo-msc
add DIUCS debug log constant
add iucs.[hc]
add msc vty, remove nitb vty
add libiudummy, to avoid linking Iu deps in tests
Use new msc_tx_dtap() instead of gsm0808_submit_dtap()
libmgcp: add mgcpgw client API
bridge calls via mgcpgw
Enable MSC specific CTRL commands, bsc_base_ctrl_cmds_install() still needs to
be split up.
Change-Id: I5b5b6a9678b458affa86800afb1ec726e66eed88
Original libvlr code is by Harald Welte <laforge@gnumonks.org>,
polished and tweaked by Neels Hofmeyr <nhofmeyr@sysmocom.de>.
This is a long series of trial-and-error development collapsed in one patch.
This may be split in smaller commits if reviewers prefer that. If we can keep
it as one, we have saved ourselves the additional separation work.
SMS:
The SQL based lookup of SMS for attached subscribers no longer works since the
SQL database no longer has the subscriber data. Replace with a round-robin on
the SMS recipient MSISDNs paired with a VLR subscriber RAM lookup whether the
subscriber is currently attached.
If there are many SMS for not-attached subscribers in the SMS database, this
will become inefficient: a DB hit returns a pending SMS, the RAM lookup will
reveal that the subscriber is not attached, after which the DB is hit for the
next SMS. It would become more efficient e.g. by having an MSISDN based hash
list for the VLR subscribers and by marking non-attached SMS recipients in the
SMS database so that they can be excluded with the SQL query already.
There is a sanity limit to do at most 100 db hits per attempt to find a pending
SMS. So if there are more than 100 stored SMS waiting for their recipients to
actually attach to the MSC, it may take more than one SMS queue trigger to
deliver SMS for subscribers that are actually attached.
This is not very beautiful, but is merely intended to carry us over to a time
when we have a proper separate SMSC entity.
Introduce gsm_subscriber_connection ref-counting in libmsc.
Remove/Disable VTY and CTRL commands to create subscribers, which is now a task
of the OsmoHLR. Adjust the python tests accordingly.
Remove VTY cmd subscriber-keep-in-ram.
Use OSMO_GSUP_PORT = 4222 instead of 2222. See
I4222e21686c823985be8ff1f16b1182be8ad6175.
So far use the LAC from conn->bts, will be replaced by conn->lac in
Id3705236350d5f69e447046b0a764bbabc3d493c.
Related: OS#1592 OS#1974
Change-Id: I639544a6cdda77a3aafc4e3446a55393f60e4050
Original libvlr code is by Harald Welte <laforge@gnumonks.org>,
polished and tweaked by Neels Hofmeyr <nhofmeyr@sysmocom.de>.
This is a long series of trial-and-error development collapsed in one patch.
This may be split in smaller commits if reviewers prefer that. If we can keep
it as one, we have saved ourselves the additional separation work.
Related: OS#1592
Change-Id: Ie303c98f8c18e40c87c1b68474b35de332033622
Stefan Sperling
Philipp Maier
Harald Welte
Alexander Huemer
Neels Hofmeyr