Those graphs + message sequence charts are not yet used by any
of our manuals, but they should become used by the OsmoMSC user
manual once SGs interface support is added.
Related: OS#2583
Change-Id: Idfd3a66c18131b5458d183b8e66f62eaaab65991
This is the first update since the libosmocore changes to the 'show
online-help' generated output. Hence the produced document now benefits from
the structural improvements:
- not repeating common commands for every node;
- using section names that match the VTY prompt.
Update msc_vty_additions.xml to match the new node ID scheme.
Change-Id: I6f1698dbc205334cf69234f88b124abfce54cc9a
Since the NITB split, GSUP is used in all three network elements, so
make the protocol a shared chapter
Change-Id: Id2d7c27ef16eb0ebe5f60d625a1fcf42f1603f4f
The initial goal was to make sure we don't have overall FORCE rules causing
unnecessary rebuilds -- annoying while writing documentation. As I looked
through possible dependencies, I finally understood what's going on here.
Remove code dup and nicely sort which belongs where in build/Makefile.*.inc. In
each, describe in a top comment how to use it, and also unify how they are
used:
- Rename Makefile.inc to Makefile.docbook.inc and refactor
- Add Makefile.vty-reference.inc
- Add Makefile.common.inc
Make sure that we accurately pick up all dependencies.
Drop use of the macro called 'command', that silenced the actual command lines
invoked and replaced them with short strings: it obscures what is actually
going on and makes the Makefiles hard to read and understand.
Each manual's makefile is greatly reduced to few definitions and a Makefile
include, e.g. one for asciidoc, one for VTY reference.
Move common/bsc_vty_additions.xml to OsmoBSC/vty/libbsc_vty_additions.xml, link
from OsmoNITB. It applies only to OsmoBSC and OsmoNITB.
Add a script that combines a VTY reference file with *all* additions files
found in a manual's vty/ dir. Call this from Makefile.vty-reference.inc.
Change-Id: I9758e04162a480e28c7dc83475b514cf7fd25ec0
Add OsmoMSC and OsmoHLR to bibliography (even though the OsmoHLR manual does
not yet exist, a reference to it has been added in OsmoMSC's manual).
Change-Id: I9ecff2837fbf5fdc19675a726f6d70c21eb178ee
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 function vlr_subscr_req_lu() has a parameter is_ps, which is set
to vsub->vlr->cfg.is_ps by the only caller in vlr_lu_fsm.c. Inside the
function one can see that vsub->vlr->cfg.is_ps is used directly to
decide between PS or CS LU, we could also use is_ps there. Presumably
the parameter is_ps had been abandonned in an early development stage
and was not removed, so lets drop the parameter.
Change-Id: Id239721773b90099d122b232dae1ba457be9d255
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
enum gsm48_gmm_cause is the wrong enum to pass to lu_fsm_failure(). Use enum
gsm48_reject_value instead.
Change-Id: If661f72056decb28c0ee82ad2449630a24d4f31c
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
Give the HLR a chance to send us updated subscriber data by indicating the CN
domain to be Circuit Switched, only during a LU Request GSUP message.
Adjust msc_vlr_tests to expect the added GSUP CN domain IE to indicate CS, i.e.
append '280102'.
Related: OS#3601
Change-Id: I0c2d33fbfdb4728e480679120d06b7f3a2ccfd76
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
In the msc_vlr_tests, instead of printing the algo IDs, rather print the
corresponding A5/n name, for clarity.
Change-Id: Ic00f1e54490650bcb40170647b8ffd52ede23fd3
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
The intention was to use the file's basename, but __BASE_FILE__ means "the root
file that is being parsed and contains #include statements".
If we had a function using __BASE_FILE__ and that was defined in an #included
file, __BASE_FILE__ would indicate the first file where the #include is, and
not the file where the function is defined. __BASE_FILE__ works for us because
we don't ever include function definitions that log something, so __BASE_FILE__
always coincides with __FILE__ for our logging; but still __BASE_FILE__ is
semantically the wrong constant.
Related: OS#2740
Change-Id: I1c8122c909938daaf782468c1c5b0262d555c3ce
Otherwise they end up in the NULL ctx.
Depends: libosmocore Change-Id Id58ca18eb826b8f4183a7cf0dbb2b38cba702a09
Change-Id: I5d5b456eb85fbdb0ca2140c56ebf3d207b4a0bba
Tracking NULL memory contexts allows one to detect memory chunks,
allocated outside the application's root context, which in most
cases are results of some mistake.
In b874486e8e the repotring of
NULL-context state was introduced, but without asking talloc
to track the use of NULL memory contexts it doesn't make sense.
Change-Id: I4b5e3946ee21c7d0ed6c66b1059dbce5ad312f88
This is a follow up change before enabling the track of NULL talloc
contexts. Since there is no other way to deinitialize libosmovty,
let's free its root context on exit. Otherwise one would see
lots of memory chunks on exit...
Change-Id: I278f85f023210de6b4626d4493d10d20996f606a