The function msc_paging_request() is only called from within
gsm_subscriber.c but never from outside. Lets make it static.
Change-Id: I2efc8eac01a4dd8733118067eecf566c13062106
gsm_subscriber.h contains some legacy cruft, part of which is that the VLR's
max MSISDN length should rather be defined in vlr.h. Same for GSM_NAME_LENGTH
-> VLR_NAME_LENGTH.
Adjust some sms_queue stuff that anyway includes vlr.h already.
Drop gsm_subscriber.h from vlr.h.
Add other (more concise) includes that thus become necessary, since the include
chain vlr.h->gsm_subscriber.h->gsm_data.h is no longer in place.
Change-Id: Iab5c507ec04fc2884187cf946f6ae2240e4a31f8
Along goes GSM_KEYSEQ_INVAL as VLR_*.
It's where it logically belongs, and is almost the only reason why vlr.h
includes gsm_data.h. The remaining reason, GSM_EXTENSION_LENGTH, will be moved
by upcoming patch.
Change-Id: I122feae7ee3cbc59e941daef35a954bce29fec76
For hysterical raisins, there are some header files that contain few
declarations, and where the name doesn't reflect the content. Combine them to
new msc_common.h:
- common.h
- common_cs.h
- osmo_msc.h
Change-Id: I9e3a587342f8d398fb27354a2f2475f8797cdb28
With the dawn of inter-BSC,MSC handover, adopting the MSC-A,-I,-T roles from
3GPP TS 49.008, the RAN connection shall soon be a neatly separated corner of
osmo-msc, so gravitate ran_conn decarations to files of matching name.
Also, the current chaos of API defined in files with mismatching/meaningless
names drives me crazy.
Change-Id: Ice31e6c43e46678538c65261f150c67e1d0845e5
Following previous rename of gsm_subscriber_connection:
Some functions and #defines are still called like "msc_conn" or just "msc_",
while they are clearly about a RAN conn.
To avoid confusion with the future separate concepts of MSC roles and a RAN
connection, rename all those to match the common "ran_conn" prefix.
Change-Id: Ia17a0a35f11911e00e19cafb5d7828d729a69640
In preparation for inter-BSC and inter-MSC handover, we need to separate the
subscriber management logic from the actual RAN connections. What better time
to finally rename gsm_subscriber_connection.
* Name choice:
In 2G, this is a connection to the BSS, but even though 3GPP TS commonly talk
of "BSS-A" and "BSS-B" when explaining handover, it's not good to call it
"bss_conn": in 3G a BSS is called RNS, IIUC.
The overall term for 2G (GERAN) and 3G (UTRAN) is RAN: Radio Access Network.
* Rationale:
A subscriber in the MSC so far has only one RAN connection, but e.g. for
inter-BSC handover, a second one needs to be created to handover to. Most of
the items in the former gsm_subscriber_connection are actually related to the
RAN, with only a few MM and RTP related items. So, as a first step, just rename
it to ran_conn, to cosmetically prepare for moving the not strictly RAN related
items away later.
Also:
- Rename some functions from msc_subscr_conn_* to ran_conn_*
- Rename "Subscr_Conn" FSM instance name to "RAN_conn"
- Rename SUBSCR_CONN_* to RAN_CONN_*
Change-Id: Ic595f7a558d3553c067f77dc67543ab59659707a
msc_compl_l3() always returns MSC_CONN_ACCEPT, because the conn FSM handles (or
should handle) all reject cases. The accept/reject return value is a legacy
from libbsc internally passing a conn over to libmsc, in osmo-nitb.
Drop enum msc_compl_l3_rc.
Change msc_compl_l3_rc() to return void.
Change all callers to always act like for acceptance, as they always did anyway.
Drop some local variables now no longer needed.
Adjust the comment to msc_compl_l3().
Drop a bunch of #if-0'd code from msc_compl_l3().
Change-Id: I759d15f4e820d5fc16397ed7210ce92308e52a09
On UTRAN, Security Mode is used instead of Ciphering Command, which does not
feature an A5 algorithm id.
Change-Id: Idc7ca9da1aa13ae16f5db2cb1024676cbc770820
The gsm_subscriber_connection->encr is never used. Use it.
When sending the Ciphering Mode Command, populate the encryption key.
When receivint the Ciphering Mode Complete, populate the chosen alg_id.
Out of paranoia, store the enc key only if the size is large enough.
Hence the vty_dump_one_conn() now reports the actually chosen A5 algorithm ID
used.
For 3G connections, though, this will still remain 0 in the VTY, since there is
no explicit A5 algorithm negotiated on UTRAN. (Security Mode Command and
Security Mode Complete instead of the GERAN Ciphering.)
(Note, 'struct gsm_encr encr' will be renamed to 'struct geran_encr geran_encr'
in Idc7ca9da1aa13ae16f5db2cb1024676cbc770820)
Change-Id: Ice2c470c360612249f97301944c6fdf9443c7dce
In I4a07ece80d8dd40b23da6bb1ffc9d3d745b54092 I've introduced a
regression. According to GSM TS 04.11, section 2.3, SAPI 3 shall
be used for both MO/MT SMS transmissions. Due to a mistake,
caused by misunderstanding of the meaning of trans->dlci, SAPI 3
was not assigned to SM transactions if there is already an active
RAN connection with subscriber. Let's fix this.
Let's also drop this misleading comment:
/* FIXME: specify SACCH in case we already have active TCH */
because it's a task of the BSC/BTS to decide which lchan to use.
Change-Id: I08d0801a89d377441e95fb8e3dd27c8d587f89e9
Related: OS#3716
gsm_network contains an int handover.active which is always zero. Drop it.
There is real handover code coming up soon, one part of this is to avoid
confusion.
The internal MNCC code queried it to decide whether to MNCC_BRIDGE or proxy RTP
(MNCC_FRAME_RECV). Since RTP is being handled by osmo-mgw since forever, drop
that entire condition from mncc_builtin.
Change-Id: Ie16e718266882588b38297121364ca0b7fdfe948
According to GSM TS 04.11, the SMC (Short Message Control) state
machine is a part of CM-sublayer of L3, that is responsible for
connection management (establisment and releasing), and SM-RP
(Relay Protocol) message delivery.
For some reason, the connection establisment request from SMC
(GSM411_MMSMS_EST_REQ) was not handled properly - it was
always assumed that connection is already established.
This is why the code initiating a MT (Mobile Terminated) SMS
transfer had to establish a radio connection with subscriber
manually.
Let's benefit from having the SMC state machine, and offload
connection establishment to it. This change makes the local
implementation closer to GSM TS 04.11, and facilitates the
further integration of GSUP transport.
NOTE: the expected unit test output is changed, because now we
always allocate a transaction first, and then establish a
connection, not vice versa.
Change-Id: I4a07ece80d8dd40b23da6bb1ffc9d3d745b54092
According to GSM TS 04.11, section 8.2.3, the RP Message Reference
is a mandatory field for all messages on the SM-RL (SM Relay Layer),
that is used to link an RP-ACK or RP-ERROR message to the associated
(preceding) RP-DATA or RP-SMMA message transfer attempt.
This change extends the transaction state structure with SM-RP-MR,
and introduces a new function for matching transactions within a
given connection by this reference.
Change-Id: Ice47c37ecef4416e65ecee8931d946c915316791
It's much better to have both RP-DATA header parsing and validation
code in a single function. There is no need to pass all the header
fields (DA, OA, UI) to gsm411_rx_rp_ud() because they are not
used there.
Change-Id: Iaf295949148e2a613c5403d1f7a926fcd6849c15
Passing a message buffer containing the whole encoded message, and
a pointer to the RP header (struct gsm411_rp_hdr) is redundant.
Change-Id: I0eb5c7c485ab7d109966431bd875fa74e00936d7
| ../../../git/src/libmsc/msc_vty.c:1202:44: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'uint64_t {aka long long unsigned int}' [-Wformat=]
| vty_out(vty, "Location Update : %lu attach, %lu normal, %lu periodic%s",
| ^
Change-Id: Iae1c0b20a519ce71a21f72cea3c63694ef10adb4
When using smpp-first, after the ESME accepts our STATUS REPORT,
we were sending it locally into gsm340_rx_sms_submit() anyway.
In the case of the ESME mirroring the report back to us, this
would result in two copies of the status report in the SMS
database, which were also both then delivered to the MS.
This causes no visible error to the user but is a waste of radio
resources.
With this patch, we check if it is the sms_report that has had
receiver set in sms_route_mt_sms() and not the original SMS we
are reporting on, which of course already has receiver set.
Change-Id: I3529b89535800eaa1127721d613fa7bbcb8b23be
the control interface command subscriber-list-active-v1 contains a stray
debug printf, lets remove it.
Change-Id: I085cf7b4a45708ccb883f70f71f4fbcfda58d332
Count COMPLETE and REJECT messages. Besides general troubleshooting
that's also useful for TTCN-3 tests to check that OsmoMSC processed
those messages as expected.
Change-Id: I5822b2b38b64f1a691b26c926a8e2bece21dc624
Related: OS#3187
The external MNCC handler may hang indefinitely in cases where the remote
end of the MNCC ceases to work properly. Add a global guard timer to
make sure the call reaches ACTIVE state.
Change-Id: I7375d1e17cd746aac4eadfe1e587e82cf1630d3d
Related: OS#3599
The function _handle_error() initalizes a struct gsm_mncc variable
on startup. The initalization accesses mgcp_ctx->trans->callref. All
this is done before the assertion on mgcp_ctx. Later in the code one
finds an if which tests on mgcp_ctx->free_ctx. This is the only part of
the code that accesses the mncc struct variable. We should move the
initalization there as well.
- Move initalization of struct gsm_mncc mncc into the if body
that uses it.
Change-Id: I86983eabd999c4275dcc0e4a169ef2aa1e33c747
Related: OS#3635
Move code which needs to test the mgcp_ctx->free_ctx flag upwards
such that it runs before we're calling functions which will
potentially free mgcp_ctx. The code being moved up takes effect
only in case mgcp_ctx won't be freed, so there should be no
functional difference.
Change-Id: I5df17c19e2a68c019f7eaf582b14585caa54b32a
Related: OS#2885
At the moment osmo-msc populates the member ip in struct gsm_mncc_rtp
with the wrong byte ordering. This causes LCR or
osmo-sip-connector to receive the IP address in the wrong order, which
eventually leads into a reversed IP address in the SDP part of the SIP
messages.
Change-Id: I86148179b549b511528e4c65213eb6c204cc609e
Related: OS#3431
This recent patch moves Classmark storage to the VLR subscriber, and introduced
a segfault when a Classmark Update is received during IMSI detach:
commit 986fe7ed18
change-id I27081bf6e9e017923b2d02607f7ea06beddad82a
Mon Sep 17 01:12:13 2018 +0200
"store classmark in vlr_subscr, not conn"
It assumed that we would never accept any Classmark Update messages unless we
also have a valid subscriber for it. Well, that is proven wrong by the
ttcn3-msc-test TC_imsi_detach_by_imsi(), which brings osmo-msc to its knees.
Fix: in case of no valid vlr_subscr being present, store Classmark in the conn
temporarily, and copy any received Classmark to VLR subscriber as soon as it
gets associated with the conn (if at all).
Change-Id: Ib2a2ae6bf86e8f29fc6751a8b5cdb7187cd70290
When the VLR requests a Ciphering Mode with vlr_ops.set_ciph_mode(), and if we
need a ciph algo flag from a Classmark information that is not yet known
(usually CM 2 during LU), send a BSSMAP Classmark Request to get it.
To manage the intermission of the Classmark Request, add
- msc_classmark_request_then_cipher_mode_cmd(),
- state SUBSCR_CONN_S_WAIT_CLASSMARK_UPDATE,
- event SUBSCR_CONN_E_CLASSMARK_UPDATE.
From state AUTH_CIPH, switch to state WAIT_CLASSMARK_UPDATE. Once the BSSMAP
Classmark Response, is received, switch back to SUBSCR_CONN_S_AUTH_CIPH and
re-initiate Ciphering Mode.
To be able to re-enter the Ciphering Mode algo decision, factor it out into
msc_geran_set_cipher_mode().
Rationale:
In the following commit, essentially we stopped supporting A5/3 ciphering:
commit 71330720b6
"MSC: Intersect configured A5 algorithms with MS-supported ones"
Change-Id: Id124923ee52a357cb7d3e04d33f585214774f3a3
A5/3 was no longer supported because from that commit on, we strictly checked
the MS-supported ciphers, but we did not have Classmark 2 available during
Location Updating.
This patch changes that: when Classmark 2 is missing, actively request it by a
BSSMAP Classmark Request; continue Ciphering only after the Response. Always
request missing Classmark, even if a lesser cipher were configured available.
If the Classmark Update response fails to come in, cause an attach failure.
Instead, we could attempt to use a lesser cipher that is also enabled. That is
left as a future feature, should that become relevant. I think it's unlikely.
Technically, we could now end up requesting a Classmark Updating both during LU
(vlr_lu_fsm) and CM Service/Paging Response (proc_arq_fsm), but in practice the
only time we lack a Classmark is: during Location Updating with A5/3 enabled.
A5/1 support is indicated in CM1 which is always available, and A5/3 support is
indicated in CM2, which is always available during CM Service Request as well
as Paging Response. So this patch has practical relevance only for Location
Updating. For networks that permit only A5/3, this patch fixes Location
Updating. For networks that support A5/3 and A5/1, so far we always used A5/1
during LU, and after this patch we request CM2 and likely use A5/3 instead.
In msc_vlr_test_gsm_ciph, verify that requesting Classmark 2 for A5/3 works
during LU. Also verify that the lack of a Classmark Response results in attach
failure.
In msc_vlr_test_gsm_ciph, a hacky unit test fakes a situation where a CM2 is
missing during proc_arq_fsm and proves that that code path works, even though
the practical relevance is currently zero. It would only become interesting if
ciphering algorithms A5/4 and higher became relevant, because support of those
would be indicated in Classmark 3, which would always require a Classmark
Request.
Related: OS#3043
Depends: I4a2e1d3923e33912579c4180aa1ff8e8f5abb7e7 (libosmocore)
Change-Id: I73c7cb6a86624695bd9c0f59abb72e2fdc655131
Store all Classmark information in the VLR.
So, we now always know the Classmark 1 (mandatory IE for LU). This is visible
in the msc_vlr_tests -- they no longer indicate "assuming A5/1 is supported"
because classmark 1 is missing, because we now know the Classmark 1.
Rationale:
During Location Updating, we receive Classmark 1; during CM Service Request and
Paging Response, we receive Classmark 2. So far we stored these only for the
duration of the conn, so as soon as a LU is complete, we would forget CM1.
In other words, for anything else than a LU Request, we had no Classmark 1
available at all.
During Ciphering Mode Command, we rely on Classmark 1 to determine whether A5/1
is supported. That is moot if we don't even have a Classmark 1 for any CM
Service Request or Paging Response initiated connections.
The only reason that A5/1 worked is that we assume A5/1 to work if Classmark 1
is missing. To add to the confusion, if a phone indicated that it did *not*
support A5/1 in the Classmark 1, according to spec we're supposed to not
service it at all. A code comment however says that we instead want to heed the
flag -- which so far was only present in a Location Updating initiated
connection. Now we can make this decision without assuming things.
This got my attention while hacking on sending a BSSMAP Classmark Request from
the MSC if it finds missing Classmark information, and was surprised to see it
it lacking CM1 to decide about A5/1.
Change-Id: I27081bf6e9e017923b2d02607f7ea06beddad82a
For networks without Authentication, the conn is already accepted when
SUBSCR_CONN_E_COMPLETE_LAYER_3 is emitted. Mute that misleading error message.
All is actually fine.
Adjust expected test logs.
Change-Id: I2d19d0a7cf3226ee1456f75a68e007ba98232402
lchan_type was removed from gsm_mncc and the hello message
on initial import from legacy OpenBSC in
Change-Id: Id3705236350d5f69e447046b0a764bbabc3d493c
This patch follows on from Change-Id: Ia02373a36df7605507ee3de49173a9fd6547b726
which reintroduced lchan_type to the gsm_mncc struct.
This patch restores the lchan_type_offset to the hello protocol message
Without this patch, LCR will issue an error and disconnect from the MNCC socket.
Change-Id: I65312082fa5dc0721170f923840e992ef9481a63
Closes: OS#3461
When the assignment completes a choosen codec is returned. At the
moment we do not use this information.
- add struct members for codec info (both, RAN and CN)
- parse codec info in BSSMAP ASSIGNMENT COMPLETE
- use codec info on mgcp
Since the MNCC API is not complete yet, we currently only use the
codec info only on the internal MNCC yet.
Change-Id: I9d5b1cd016d9a058b22a367d0e5e9f2ef447931a
Related: OS#2728
Philipp Maier
Neels Hofmeyr
Pau Espin
Keith Whyte
Harald Welte