Flush the cache after changing the version, to make the scenario less
likely that after an unclean shutdown the DB gets restored with the
right table layout but wrong version.
When that happens, osmo-hlr tries to upgrade the database layout again
and fails with errors like "duplicate column name".
Related: SYS#7394
Change-Id: I5943a1cb3447c038c6e7972f68f9656b73a9248b
This callback was drepecated and is not ever called since
libosmocore.git 70ce871532ab21955e0955d7e230eae65438f047 (release 1.3.0).
See also libosmocore.git d31de237582f6fe3315d61bb9a488d4cda92654e.
Change-Id: I0a77ff4c0a880230116a361651c78c77328db989
Direct include of abis/ipa.h is not needed there, remove it to ease
later deprecation of such header.
Change-Id: I72d0787d4f5641a6a2fbe51427ac490120cbc616
This is a first step towards changing gsup_client implementation to use
an osmo_stream_cli instead of libosmo-abis' ipa_client_conn.
The libosmo-abis' ipa_client_conn will eventually be deprecated together
with all IPA related code in libosmo-abis.
In order to be able to make the implementation change, we first need to
make sure no users are using the struct fields of gsup_client (this
patch); 2nd step will be making the struct private by moving it to a
private header; 3rd step will be changing the implementation to use
osmo_stream.
Related: OS#5896
Change-Id: I401af83232022f1c141eef1f428cbe206a8aaaa2
That header is only really used to provide an old hack for
ipaccess-proxy tool in openbsc.h/osmo-bsc.h, and will be deprecated
soon.
Take the chance to organize a bit better the includes based on dependency
chain.
Change-Id: I393cd23a09af6d1eefa68dc955415f4fe334d71b
If LU has to be rejected because DGSM mechanism cannot reach the
needed HLR, then returning reject cause #17 (Network Failure)
is the most accurate and truthful description of what is actually
happening.
Reject cause #2 (IMSI unknown in HLR) is unlikely to be a good
choice: in areas where regular commercial cell services are present
alongside with experimental/adventurous Osmocom-based GSM networks,
this reject cause is acutely dangerous as described in the previous
commit, and even in areas where no regular commercial cell services
are present (the presumed intended use case for DGSM), the behavior
of commanding LU-failing phones "please don't ever again try to
connect to ANY network until the user power-cycles you" is unlikely
to be correct/desirable. If that behavior _is_ desired, it should
be configured explicitly, not by default.
Change-Id: I557ae1d3291066a87228b5db4f2e207ea721329c
Unless the Osmocom-based network operator has very carefully
considered what they are doing, returning MM/GMM reject cause #2
(IMSI unknown in HLR) to LU requests from bystander phones is a
very bad idea. Here is what typically happens when someone sets
up an Osmocom-based GSM network for development, testing or
research, without roaming interconnection with any commercial
operators:
* Even when the private network operates its BTS at very low power
levels, bystander phones in close proximity (e.g., in directly
adjacent neighbor apartments or office suites) will receive a much
stronger signal from the private/test network BTS than from any
commercial operator, i.e., the private/test network will be
the strongest signal.
* Many phones will attempt to "jump ship" to this strongest signal
even if it broadcasts a completely unknown PLMN ID that is not in
the preferred operator list, and even when they were previously
not roaming at all, registered to their most preferred home operator
with perfectly good reception quality.
* If these wayward phones receive reject cause #2 in response to their
LU attempt, the spec effectively requires them to go into a "black
hole" where they no longer attempt to register to any operator,
including their own legitimate one.
Returning reject cause #11 instead (PLMN not allowed) solves this
problem: wayward phones that erroneously attempted to register to the
private/test network go back to their own legitimate commercial
operator, and everyone is happy.
This bug should be considered critical: when the reject cause is set
to #2 by default, any private Osmocom-based network, no matter how
low-power, will effectively cause service disruption to all nearby
commercially-served phones even when there is no clash in terms of
used radio frequencies.
Change-Id: Icff1d19670c398b119ec68b1d5f0fad87b605702
When reject-cause (not-found|no-proxy) setting was added, it was
implemented such that the new setting is not written into saved
config files if it equals the default of 'imsi-unknown'. Change
this behavior to always write out the current setting for each of
not-found and no-proxy, whether or not they match compiled-in
defaults.
Change-Id: I18708fc1c08a85e98582c97ec59dd3822a0767fb
Use the libosmocore API, which does the same except setting the l2h
pointer, which we don't really need here.
Change-Id: I7a4d05a0b09032d8133d8775fb4707a4da8f0cf3
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
