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
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
The mncc_rtp_create_pending and mncc_rtp_connect_pending members
were unused, let's remove them.
Related: OS#2528
Change-Id: I417e23ec53323ddd8e1e5d18952566fe8fd6ac24
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