GSUP supports different message classes (e.g. SMS, USSD, Subscriber management),
within a daemon, the messages are usually handled in different parts of it.
The gsup client mux allow to place callbacks for the different message class.
This code original comes from the osmo-msc code and is here
re-licensed under the GPLv2.
Change-Id: I916c1bb6cfc48f92fc5db2b5c914eb1b4e25fa7f
In may be desirable for some users to assign deterministic MSISDNs
when subscriber-create-on-demand is enabled. This can be achieved
by assigning MSISDN=IMSI. This commit adds a new mode for that.
Change-Id: I3470492f5e46de7246d9a74e80c37f80f455d851
This commit prepares for adding a new subscriber-create-on-demand
mode (MSISDN=IMSI), which is implemented in a follow-up patch.
* add an enumerated type for subscriber-create-on-demand mode;
* store the related parameters in an anonymous structure.
Change-Id: Ib553172655f83dad1ac0e0254615c8c207d79ca9
Fix GCC 13.2.0 refuses to build this with -Werror:
src/mslookup/osmo-mslookup-client.c: In function 'socket_client_respond_result':
src/osmo-hlr/src/mslookup/osmo-mslookup-client.c:432:9: error: ignoring return value of 'write' declared with attribute 'warn_unused_result' [-Werror=unused-result]
432 | write(c->ofd.fd, response, strlen(response));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/mslookup/osmo-mslookup-client.c: In function 'socket_accept':
src/osmo-hlr/src/mslookup/osmo-mslookup-client.c:530:17: error: ignoring return value of 'write' declared with attribute 'warn_unused_result' [-Werror=unused-result]
530 | write(c->ofd.fd, CSV_HEADERS, strlen(CSV_HEADERS));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Change-Id: I4b2e5cabe5306a999197f7c98362d872a3739078
Do not attempt to change permissions/ownership if the package gets
upgraded from a version higher than the next release.
Do not fail if the user deleted the config file.
Be verbose when changing permissions.
Related: OS#4107
Change-Id: I1bcbe414fd18101e4d875a16539deab7baf9cb5f
* Explicitly chown /var/lib/osmocom to osmocom:osmocom, instead of
relying on systemd to do it when the service starts up. This does not
work with the systemd versions in debian 10 and almalinux 8.
* deb: Use "useradd" instead of the interactive "adduser" perl script
from Debian. This makes it consistent with how we do it in rpm, and
avoids the dependency on "adduser".
* deb: Remove support for the "dpkg-statoverride --list" logic. This
seems to be a rather obscure feature to override permissions for
certain files or directories. Let's rather remove this complexity to
make the postinst script more maintainable and more similar to the
rpm spec file. If users need this, they can achieve something similar
by using their own Osmocom config file in a different path with
different permissions.
* deb: Consistently use tabs throughout postinst, instead of mixing
tabs and spaces.
Related: OS#4107
Change-Id: Ib20406dd253f5e8720552e92e9002e45591218fa
Created osmocom user & group during package installation.
Fix the configuration dir/files permission to match.
Related: OS#4107
Tweaked-By: Oliver Smith <osmith@sysmocom.de>
Change-Id: I625c993ab03dfe32976c651acca9c35c33a768e7
There may be a need in various OsmoCNI-attached entities (for example,
external SMSC implementations) to perform a mapping from known MSISDN
to unknown IMSI, querying OsmoHLR subscriber db for it. Querying for
subscriber.by-msisdn-*.imsi will be much more efficient (and easier on
client-side implementors) than querying for subscriber.by-msisdn-*.info
and fishing the IMSI out of the long multiline response, discarding all
other irrelevant info.
Related: OS#6312
Change-Id: Icea1a74d0c664047f46758ab4ad75508782f3d12
When an MS indicates that it is ready to receive MT SMS, the MSC will
send us a READY-FOR-SM.req message. Handle it by sending copies of
the same message to all connected SMSCs and returning OK result
to the MS that indicates its ready status.
Related: OS#6135
Change-Id: I731545a3a0d0804289e24a7769e13bfd3f645132
When an SMSC tries to deliver an SM to a subscriber, it will send us
an MT-forwardSM.req GSUP message. We look up the subscriber by IMSI
and see if they are attached to a VLR. If the subscriber is attached,
we forward the message to the MSC/VLR, otherwise return an error
to the SMSC.
Related: OS#6135
Change-Id: Ib3551bf7839690606c677461758c5cfef5f0aa7b
MO-forwardSM.req messages are now forwarded to a connected SMSC
based on the SMSC address (SM-RP-DA) in the MO SM and the vty-defined
mapping from SMSC numeric addresses to IPA names.
Related: OS#6135
Depends: Iea5c29909c5be80f81dbbc2873656ff5cf590a5d (libosmocore)
Change-Id: Iaad4531922c41583d261c79f42561a1bdbe03521
At the user-visible level (advanced settings menus on phones,
GSM 07.05 AT commands, SIM programming) each SMSC is identified
by a numeric address that looks like a phone number, originally
meant to be a Global Title. OsmoMSC passes these SMSC addresses
through as-is to MO-forwardSM.req GSUP message - however, SMSCs
that connect to OsmoHLR via GSUP identify themselves by their
IPA names instead. Hence we need a mapping mechanism in OsmoHLR
config.
To accommodate different styles of network design ranging from
strict recreation of classic GSM architecture to guest roaming
arrangements, a two-level configuration is implemented, modeled
after EUSE/USSD configuration: first one defines which SMSCs exist
as entities, identified only by their IPA names, and then one
defines which numeric SMSC address (in SM-RP-DA) should go to which
configured SMSC, with the additional possibility of a default route.
Related: OS#6135
Change-Id: I1624dcd9d22b4efca965ccdd1c74f0063a94a33c
Previously the HLR sent in the Insert Subscriber Data call only the
wildcard APN as a single entry.
This violates the spec because the first entry (with the lowest context_id) is
always the default APN, but it is forbidden to have a wildcard APN as default apn.
Introduce a default template/profile which can contain multiple APNs.
This profile is always sent out to the SGSN/MME as part of Insert-Subscriber-Data.
In the future a subscriber might have a profile template name written into the
database which will resolve to a "pdp-profile premium" in the configuration.
To be backward compatible, if the pdp-profile default section is missing,
the HLR will send out only a wildcard APN.
Config example:
hlr
ps
pdp-profile default
profile 1
apn internet
profile 2
apn *
Changes to the apn list will be only handed out to subscribers
when the subscriber do a location update.
Related: SYS#6391
Change-Id: I540132ee5dcfd09f4816e02e702927e1074ca50f
Other UMTS AKA algorithms than MILENAGE (notably TUAK) support K sizes
of up to 256bit, or mandate a OP/OPc size of 256 bit.
Let's extend our database schema to accommodate such larger sizes.
Change-Id: Ibbde68484c904507a15c35cbfdf88cd47d0c7039
The usual Data Coding Scheme value in the mobile-originated USSD
request (processUnstructuredSS-Request) is 0x0f, which means:
0000 .... = Coding Group: Coding Group 0 (Language using the GSM 7 bit default alphabet)
.... 1111 = Language: unspecified
However some modems are known to use a different default value, if
not specified explicitly (AT+CUSD has optional DCS parameter):
0000 .... = Coding Group: Coding Group 0 (Language using the GSM 7 bit default alphabet)
.... 0000 = Language: German (0)
In function rx_proc_ss_req(), we should not be using req.ussd_text,
because this field has been deprecated and may contain unexpected
data. For example, in the abovementioned case it would contain the
7 bit encoded ussd-String 'aa510c061b01'O and osmo-hlr would indeed
fail to find a matching route for a non-ASCII string.
Instead of relaying on gsm0480_parse_facility_ie(), let's check the
Data Coding Scheme value and decode the request string ourselves.
Expect the Coding Group 0, but be more tolerant to the indicated
language: print a warning and treat it as '1111'B (unspecified).
Change-Id: Ib7bac660b1a7942adcfbe7b14f162c95061a25db
Related: OS#6075
I noticed that inability to send IPA PONG in response to IPA PING
from osmo-{msc,sgsn} results in an "IPA Multiplex" chunk being leaked.
No matter what's returned from ipa_server_conn_ccm(), we need to free
the msgb containing the incoming IPA message.
Change-Id: I5c5acbffc2913f78db4894ae3633b5eca9c2e8d6
Currently osmo-hlr leaks memory (msgb holding 1203 bytes of data and
a struct osmo_gsup_req) on receipt of OSMO_GSUP_MSGT_INSERT_DATA_ERROR.
Change-Id: I4c70a06169158c869360707a7a62436dbf13b9b3
This is primarily to make the linter happy, which spews "static const
char * array should probably be static const char * const" errors in
gerrit when adding similar new code to this existing file. So let's
first convert the old code and then add new code that makes the linter
happy. I guess it does have a point, as both the individual string
pointers as well as the array of the pointers are constant.
Change-Id: I39e9fb6bd8052f4878cfc95061775bf940631ae5
libosmogsm has recently introdcued a 'struct osmo_sub_auth_data2' as
successor to 'struct osmo_sub_auth_data', together with updated
osmo_auth_gen_vec2/osmo_auth_gen_vec_auts2 API.
The rationale of this new API is to enable
* support for AKA algorithms which use K and/or OP[c] values of 256bit
(instead of the classic 128bit)
* support for RES length sizes of 4 and 16 bytes (instead of the classic
8 bytes)
This commit just jumps over to the new API without adding any related
functionality to osmo-hlr. The latter is left for subsequent commits.
Change-Id: I3207c7bfb73e9ff5471e5c26b66639549e4d48a2
Depends: libosmocore.git Ie775fedba4a3fa12314c0f7c8a369662ef6a40df
This templates is used for generating C code, so it should use our
normal tab-based code indenting.
Change-Id: I0be7eb2d7b551d7eaaee15994ef37262694819f6
So far we supported a "xor" algorithm in osmo-hlr, without specifying
whether it's the XOR-3G or the (different) XOR-2G algorithm.
Furthermore, it was buggy in the sense that it permitted the XOR[-3G]
for 2G authentication data in the database.
This patch
* renames existing "xor" to "xor-3g"
* disallows "xor-3g" usage with 2G authentication data
* introduces support for XOR-2G as "xor-2g" in the VTY
Change-Id: I039a1f84fda54a908a82fe621e7fd078cb85e4c6
Depends: libosmocore.git I0ee0565382c1e4515d44ff9b1752685c0a66ae39
Don't use static buffers for APN and MSISDN.
When encoding multiple APNs the static buffer might be too small.
In prepration to support multiple APNs in subscriber data
Change-Id: I00b5c2dfadcf6e0740e93b4c3292d2654d22e80c
Adjust the test to the related libosmocore change.
Related: libosmocore I446e54d0ddf4a18c46ee022b1249af73552e3ce1
Change-Id: I68878d24340659f888e5e348b937161cffbd54e2
Allow to set the LU reject cause independently for both of the
following cases; either when an IMSI is unknown to the HLR or
when the mslookup client does not a receive a timely response
to a GSUP request for the remote home HLR.
Original patchset modified by <keith@rhizomatica.org>
Change-Id: Icea39020c23fbbea9e92847df76af8986fdbf48a
This commit fixes the following errors:
Missing timeout param for mslookup.
Fails to start reading a written config if an msc node
is configured in the mslookup server.
Places the individual msc node services in the
top-level wildcard node due to incorrect indentation.
* Add missing timeout param.
* Add missing "ipa-name" part to mslookup-server-msc section.
* Add one extra space indentation for msc services.
This commit also adds a DEFINE for the default timeout value.
Change-Id: Ibb60e74a0803f05f37ac13ca529d77b4cb736025
Use the apn functions from libosmocore to encode and decode qnames to
avoid code duplication and to avoid unnecessary dynamic allocation.
The unit tests for encoding and decoding rfc_question / rfc_record are
still passing and have the same output.
Fixes: OS#5821
Change-Id: I09d3c617fd6eb4075084ee106d3f3c5803861d2f
