Now that all VTY definitions are in the same file, we no longer need
gsmnet_from_vty(). Just have one static struct gsm_network *gsmnet populated by
msc_vty_init() and use it in all VTY functions.
Change-Id: I5cb3712a4f4245feb62d42f1b041fe94de5fac1b
From openbsc.git, we still have osmo-msc's VTY definitions spread across
various places. Combine:
- Move the go_parent_cb() and is_config_node() to msc_main.c, drop
common_vty.c.
- Move all of vty_interface_layer3.c into msc_vty.c.
- Move all of common_cs_vty.c into msc_vty.c.
- Move bsc_vty_init_extra() into msc_vty_init().
- Drop some unused definitions
No functional nor cosmetic changes have been made in the moved code, plain
copy-paste moving (even though the unidiff might look like edits in some
places). I might have adjusted some blank lines though.
Change-Id: Ia818c00ab613a19a34080b160d763b55c19f76b1
In trans_free(), call subscr_conn_release_when_unused(), so that we are sure to
clean up after the last transaction is done.
This fixes an error where a conn lingered after a CC failure, because that code
path forgot to trigger cleanup.
Rationale: so far we were triggering the release check after each DTAP dispatch
(compl_l3 and "normal" DTAP), which is sufficient for properly closed
transactions. We also need a check for when a timeout clears an erratic trans.
Adjust test expectation of test_call_mo_to_unknown_timeout to show that the
error is now fixed.
msc_vlr_test_reject_concurrency now sees an additional release checking event
when the SMS transaction is done, which is expected and does not affect the
test otherwise.
Related: OS#2779
Change-Id: I46ff2e9b09b67e4e0d79cccf8c04936f17281fcb
It's pretty amazing that we print error messages anrd return error
codes, but nobody ever looks at the error code and/or closes the
connection. Let's change that.
Change-Id: Iec693d8012a7816d1ded8206c2d979ac0546fb6e
If both sides are sending RESET at the same time, they are not aware
of each other. This leads to synchronization problems in wich
the remote side is transmitting e.g. a COMPL L3 INFO after receiving
a RESET ACK, but before even receiving or processing the RESET in
the inverse direction. So let's treat receiving a RESET as an implicit
RESET ACK to any RESET we may have sent.
Change-Id: I0ae34fbb3735592bb7cffa5aaf421b14a8acc90e
Fixes several of these type of warnings:
include/osmocom/core/fsm.h:123:38: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 9 has type ‘char *’ [-Wformat=]
LOGP((fi)->fsm->log_subsys, level, "%s{%s}: " fmt, \
^
src/libmsc/msc_mgcp.c:277:71: note: format string is defined here
"CRCX/RAN: creating connection for the RAN side on MGW endpoint:0x%x...\n", mgcp_ctx->rtp_endpoint);
~^
Change-Id: I17b7bed8fc39612286ba66f250b6b26da01d38c0
The higher layers (gsm_04_08.c) are informed errors occur. But it
is not checked if the call was already released. If an error occurs
after the call control stack calls msc_mgcp_call_release() then
the higher layers might already have cleaned up and the code
accesses memory that is already freed (trans)
- fix use after free by guarding the call to mncc_tx_to_cc()
Change-Id: I78f1b6a9149488a4ad3f120c1e190a83c07d4b89
Related OS#2881
Related OS#2882
These tests helped to debug issue OS#2779. Now that they're here we might as
well keep them.
The test test_call_mo_to_unknown shows that an MS answering to the Release
Request works as it should: the conn is torn down.
The test test_call_mo_to_unknown_timeout currently expects the error: the conn
remains active if the CC Release times out. This bug and the test expectations
will be fixed in I46ff2e9b09b67e4e0d79cccf8c04936f17281fcb.
Change-Id: Ic3c84520bff8c3fc82512d03ff6ab97d21b8fb7a
The naming of "bump" was short and made sense to me at the time of writing, but
it is keeping pretty much everyone else at a distance, no-one intuitively gets
what it is supposed to mean.
Clarify by renaming to "release_when_unused".
Adjust test expectations.
Change-Id: I4dcc55f536f63b13a3da29fff1df5fe16751f83a
There are a number of bad failures in CC teardown handling we're solving. It
helps to see CC logging in the msc_vlr_tests.
Change-Id: I56ac269d46b48b6b85efad81c4d2343bfc41ea90
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
gsm_04_08.c seems to contain some lines of old debug code that
is commented out. Presumably the commented lines are a leftover
from a debug session.
- remove those commented code lines
Change-Id: Ifb84e4b0696fef1326c3f9ebc8427581057db44f
Use the new gsm0808_dec_cell_id_list2() API to decode the cell
identifier in the bssap COMPLETE LAYER 3 information message.
Also, actually compare the MCC-MNC in WHOLE_GLOBAL and LAI_AND_LAC
cell identifiers to the network configuration, and drop messages
with mismatching MCC-MNC (addresses OS#2980).
Related: OS#2847
Related: OS#2980
Change-Id: I855477507e4d65fb9890da0ceea26dd2c4dfaf82
osmo-msc still uses endpoints that are allocated locally by the
MGCP-Client. Since osmo-mgw now supports the more comfortable,
dynamic variant we should make use of it.
- Replace the endpoint numer allocation by the client with a
wildcarded CRCX. Use the endpoint that is assigned by the
MGW.
Related: OS#2710
Change-Id: Iee3e446b6689626516f01c521abe3d4603cd3e13
When a truncation check (osmo_strlcpy()) fails handle_error()
is called with MGCP_ERR_NOMEM as cause code. Which finally
results in an "out of memory" message. MGCP_ERR_NOMEM is only
used for failed truncation checks, so it makes sense to choose
a message that describes the cause of the problem better.
- rename MGCP_ERR_NOMEM to MGCP_ERR_TOOLONG
- replace error message string
Change-Id: Ifedb85c1933a30b2aa491b495119919f45782e2c
Make sure to deactivate trans.cc.timer when freeing a CC transaction.
Log an error if should be necessary.
This prevents a segfault when we receive a BSSMAP Clear Request from BSC during
an ongoing CC operation. The BSSMAP Clear Request currently triggers immediate
freeing of the conn, while we should still do a graceful release first. While
this patch does not fix the underlying error, it does prevent the MSC from
crashing due to a stale timer, whatever the cause might be.
Related: OS#3062
Change-Id: I86b666f23402a6d94af2d903e514770d1fd5157f
When the FSM reaches ST_HALT it frees itsself and all context
information but it is not ensured that there are still pending
MGW transactions that might hit late and eventually cause a use after
free situation.
- if an MGW transaction is still pending, cancel it.
Change-Id: I8ff55e48a95cc4c556a97ad2593bad1cc1aa69bd
When the MGW does not respond to an MGCP message then the mgcp FSM
terminates, but the CC handler (gsm_04_08.c) is not informed. This
lets the CC handler think that the MGCP connection would be successful,
so it also does not take any action to release the non functional
connection.
- make sure the CC handler is always informed on any kind of
error, especially on MGW timeouts
Change-Id: I3fcd0d71fad53274e82f6d87c80042d06283bc5d
Related OS#2881
Related OS#2882
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
Provide a sane means of adding the -Werror compiler flag.
Currently, some of our jenkins.sh add -Werror by passing 'CFLAGS="-Werror"',
but that actually *overwrites* all the other CFLAGS we might want to have set.
Maintain these exceptions from -Werror:
a) deprecation (allow upstream to mark deprecation without breaking builds);
b) "#warning" pragmas (allow to remind ourselves of errors without breaking
builds)
As a last configure step before generating the output files, print the complete
CFLAGS and CPPFLAGS by means of AC_MSG_RESULT.
Change-Id: I0528dcb14bf79d0920905a718cc2edea1434c0e5
See also change-id I72a1dbb30e0a39dbf4b81c7e378d5607b62e10d3 in
osmo-ttcn3-hacks.git, which adds a similar test to the MSC_Tests.ttcn suite.
Writing this test helped me fix the issue faster, why not keep it now that it's
there.
Related: OS#2947
Change-Id: Iba56556207cf6e79e6531b0e7dd3eaec28fb5eaa
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
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. In that case, we must
make sure to send the GSM AKA Kc for ciphering.
Add test_gsm_ciph_in_umts_env() to msc_vlr_test_gsm_ciph.c to answer an Auth
Request with a GSM AKA response (see the log stating "AUTH established GSM
security context" after we sent a UMTS AKA challenge).
In the test, show that we currently send the *wrong* Kc, i.e. the UMTS AKA
derived Kc for GERAN, instead of the correct Kc for GSM AKA (which was received
from the HLR in the auth tuples).
Subsequent patch I42ce51ae979f42d173a45ae69273071c426bf97c will fix this and
correct the test expectations.
Related: OS#2793
Change-Id: I85f12a20dcd701e671188e56811ec7b58d84da82
Clearly distinguish between Ciphering Mode Command on GERAN and Security Mode
Control on UTRAN.
Cosmetic: explicitly verify the key strings in the testing code (not only in
the expected output).
Change-Id: Ica93ed06c4c63dc6768736d25231de8068001114
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
All functions in the individual msc_vlr_test_*.c files should be static; hence
we would be warned if one of them were unused (forgotten to add to the tests
array).
Change-Id: Ia169c6a1443a48879ab4777e09c2040c48810bf6
Three recently merged commits take the msc_vlr_tests in a wrong direction.
The IMSI is usually encoded in the hex streams. The rationale behind hex
streams is that it is a) easily copied from a wireshark trace and b) exactly
the bytes as sent by an actual phone. It is hard to parameterize the IMSI
because we would have to employ our encoding functions, which I intentionally
want to keep out of the loop here.
The test number should not appear in the normal test output, so that adding a
test or changing their order does not affect expected output for following
tests. The nr is simply for manual invocation, only seen when invoked with -v.
Revert
- "VLR tests: always print test parameters"
b0a4314911.
- "Expand VLR tests"
d5feadeee8.
- "Move IMSI into test parameters"
093300d141.
Change-Id: Ie1b49237746751021da88f6f07bbb9f780d077c9
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