Each VLR requesting auth tuples should use a distinct IND pool for 3G
auth. So far we tied the IND to the GSUP peer connection; MSC and SGSN
were always distinct GSUP peers, they ended up using distinct INDs.
However, we have implemented a GSUP proxy, so that, in a distributed
setup, a remotely roaming subscriber has only one direct GSUP peer
proxying for both remote MSC and SGSN. That means as soon as a
subscriber roams to a different site, we would use the GSUP proxy name
to determine the IND instead of the separate MSC and SGSN. The site's
MSC and SGSN appear as the same client, get the same IND bucket, waste
SQNs rapidly and cause auth tuple generation load.
So instead of using the local client as IND, persistently keep a list of
VLR names and assign a different IND to each. Use the
gsup_req->source_name as indicator, which reflects the actual remote
VLR's name (remote MSC or SGSN).
Persist the site <-> IND assignments in the database.
Add an IND test to db_test.c
There was an earlier patch version that separated the IND pools by
cn_domain, but it turned out to add complex semantics, while only
solving one aspect of the "adjacent VLR" problem. We need a solution not
only for CS vs PS, but also for 2,3G vs 4G, and for sites that are
physically adjacent to each other. This patch version does not offer any
automatic solution for that -- as soon as more than 2^IND_bitlen
(usually 32) VLRs show up, it is the responsibility of the admin to
ensure the 'ind' table in the hlr.db does not have unfortunate IND
assignments. So far no VTY commands exist for that, they may be added in
the future.
Related: OS#4319
Change-Id: I6f0a6bbef3a27507605c3b4a0e1a89bdfd468374
Firstly, vlr_number[] is an array and we need to check the first char for nul
instead of the pointer.
Also, osmo_ipa_name_set_str() returns zero on success, so the condition is
reversed.
hlr_subscr_nam() was rewritten in I3a8dff3d4a1cbe10d6ab08257a0138d6b2a082d9
ad868e29ba and this likely fixes a bug introduced
there.
Related: coverity CID#210169
Change-Id: I3a0e9ed4b865c88aa4a6341a3bf1a96c10d20ed9
Add mslookup client to find remote home HLRs of unknown IMSIs, and
proxy/forward GSUP for those to the right remote HLR instances.
Add remote_hlr.c to manage one GSUP client per remote HLR GSUP address.
Add proxy.c to keep state about remotely handled IMSIs (remote GSUP address,
MSISDN, and probably more in future patches). The mslookup_server that
determines whether a given MSISDN is attached locally now also needs to look in
the proxy record: it is always the osmo-hlr immediately peering for the MSC
that should respond to mslookup service address queries like SIP and SMPP.
(Only gsup.hlr service is always answered by the home HLR.)
Add dgsm.c to set up an mdns mslookup client, ask for IMSI homes, and to decide
which GSUP is handled locally and which needs to go to a remote HLR.
Add full VTY config and VTY tests.
For a detailed overview of the D-GSM and mslookup related files, please see the
elaborate comment at the top of mslookup.c (already added in an earlier patch).
Change-Id: I2fe453553c90e6ee527ed13a13089900efd488aa
Implement the mslookup server's mDNS responder, to actually service remote
mslookup requests:
- VTY mslookup/server config with service names,
- the mslookup_mdns_server listening for mslookup requests,
For a detailed overview of the D-GSM and mslookup related files, please see the
elaborate comment at the top of mslookup.c (already added in an earlier patch).
Change-Id: I5cae6459090588b4dd292be90a5e8903432669d2
Implement the mslookup server to service remote mslookup requests.
This patch merely adds the logic to answer incoming mslookup requests, an
actual method to receive requests (mDNS) follows in a subsequent patch.
- API to configure service names and addresses for the local site (per MSC).
- determine whether a subscriber is on a local MSC
(checking the local proxy will be added in subsequent patch that adds proxy
capability).
- VTY config follows in a subsequent patch.
For a detailed overview of the D-GSM and mslookup related files, please see the
elaborate comment at the top of mslookup.c (already added in an earlier patch).
Change-Id: Ife4a61d71926d08f310a1aeed9d9f1974f64178b
To be prepared for the future in public API, wrap the new osmo_ipa_name struct
in an enum-type and union called osmo_cni_peer.
During code review it was requested to insert an ability to handle different
kinds of peer id, in order to be able to add a Global Title in the future.
Use the generic osmo_cni_peer only in the publicly visible API. For osmo-hlr
internal code, I intend to postpone implementing this into the future, when a
different peer identification actually gets introduced.
This way we don't need to implement it now in all osmo-hlr code paths (save
time now), but still make all external API users aware that this type may be
extended in the future.
Change-Id: Ide9dcdca283ab989240cfc6e53e9211862a199c5
These are seemingly orthogonal changes in one patch, because they are in fact
sufficiently intertwined that we are not willing to spend the time to separate
them. They are also refactoring changes, unlikely to make sense on their own.
** lu_fsm:
Attempting to make luop.c keep state about incoming GSUP requests made me find
shortcomings in several places:
- since it predates osmo_fsm, it is a state machine that does not strictly
enforce the order of state transitions or the right sequence of incoming
events.
- several places OSMO_ASSERT() on data received from the network.
- modifies the subscriber state before a LU is accepted.
- dead code about canceling a subscriber in a previous VLR. That would be a
good thing to actually do, which should also be trivial now that we record
vlr_name and sgsn_name, but I decided to remove the dead code for now.
To both step up the LU game *and* make it easier for me to integrate
osmo_gsup_req handling, I decided to create a lu_fsm, drawing from my, by now,
ample experience of writing osmo_fsms.
** osmo_gsup_req:
Prepare for D-GSM, where osmo-hlr will do proxy routing for remote HLRs /
communicate with remote MSCs via a proxy:
a) It is important that a response that osmo-hlr generates and that is sent
back to a requesting MSC contains all IEs that are needed to route it back to
the requester. Particularly source_name must become destination_name in the
response to be able to even reach the requesting MSC. Other fields are also
necessary to match, which were so far taken care of in individual numerous code
paths.
b) For some operations, the response to a GSUP request is generated
asynchronously (like Update Location Request -> Response, or taking the
response from an EUSE, or the upcoming proxying to a remote HLR). To be able to
feed a request message's information back into the response, we must thus keep
the request data around. Since struct osmo_gsup_message references a lot of
external data, usually with pointers directly into the received msgb, it is not
so trivial to pass GSUP message data around asynchronously, on its own.
osmo_gsup_req is the combined solution for both a and b: it keeps all data for
a GSUP message by taking ownership of the incoming msgb, and it provides an
explicit API "forcing" callers to respond with osmo_gsup_req_respond(), so that
all code paths trivially are definitely responding with the correct IEs set to
match the request's routing (by using osmo_gsup_make_response() recently added
to libosmocore).
Adjust all osmo-hlr code paths to use *only* osmo_gsup_req to respond to
incoming requests received on the GSUP server (above LU code being one of
them).
In fact, the same should be done on the client side. Hence osmo_gsup_req is
implemented in a server/client agnostic way, and is placed in
libosmo-gsupclient. As soon as we see routing errors in complex GSUP setups,
using osmo_gsup_req in the related GSUP client is likely to resolve those
problems without much thinking required beyond making all code paths use it.
libosmo-gsupclient is hence added to osmo-hlr binary's own library
dependencies. It would have been added by the D-GSM proxy routing anyway, we
are just doing it a little sooner.
** cni_peer_id.c / osmo_ipa_name:
We so far handle an IPA unit name as pointer + size, or as just pointer with
implicit talloc size. To ease working with GSUP peer identification data, I
require:
- a non-allocated storage of an IPA Name. It brings the drawback of being
size limited, but our current implementation is anyway only able to handle
MSC and SGSN names of 31 characters (see struct hlr_subscriber).
- a single-argument handle for IPA Name,
- easy to use utility functions like osmo_ipa_name_to_str(), osmo_ipa_name_cmp(), and copying
by simple assignment, a = b.
Hence this patch adds a osmo_ipa_name in cni_peer_id.h and cni_peer_id.c. Heavily
used in LU and osmo_gsup_req.
Depends: libosmocore Id9692880079ea0f219f52d81b1923a76fc640566
Change-Id: I3a8dff3d4a1cbe10d6ab08257a0138d6b2a082d9
Previous the hlr always returned the maximum possible auth vectors (5)
to the client. Even when only asked for a single auth vector.
Change-Id: I20c2b648456bc7ba1fc1321a7d42852158a3523c
Despite LTE/EUTRAN using the same authentication procedure (UMTS AKA)
as 3G, there's one difference: The "operator defined" 16bit AMF field
is reduced to 15 bits, with the first bit now being used as 'separation
bit'. That bit should be '0' for 2G/3G (as it is right now) and '1'
for authentication vectores generated for authentication over
EUTRAN/EPS.
Depends: libosmocore I93850710ab55a605bf61b95063a69682a2899bb1 (OSMO_GSUP_RAT_TYPES_IE)
Change-Id: Ic766bc40f6126bb479bd0a05b0e96bec3e240008
Throughout osmo-hlr's code, the GSUP msgb allocation is duplicated as:
msgb_alloc_headroom(1024+16, 16, "foo");
Instead, use one common function to keep the magic numbers in one place.
Change-Id: I40e99b5bc4fd8f750da7643c03b2119ac3bfd95e
Apply the same headers structure that we keep in most Osmocom source trees:
Keep noinst_HEADERS in include/osmocom/hlr and include them using
#include <osmocom/hlr/*.h>
The only header kept in src/ is db_bootstrap.h, because it is generated during
build time. If it was built in include/osmocom/hlr, we would need db.o to
depend on db_bootstrap.h in a different subdir, which automake can't do well.
Change-Id: Ic912fe27f545b85443c5fb713d8c3c8aac23c9ad
This allows starting osmo-hlr to merely open the database, do upgrades if
necessary, and quit, without opening any ports.
So that no ports are opened, move the telnet VTY startup to below the database
check.
Needed for upcoming patch that introduces a db_upgrade test, in
I0961bab0e17cfde5b030576c5bc243c2b51d9dc4.
Change-Id: I1a4b3360690acd2cd3cffdadffbb00a28d421316
Since March 15th 2017, libosmocore API logging_vty_add_cmds() had its
parameter removed (c65c5b4ea075ef6cef11fff9442ae0b15c1d6af7). However,
definition in C file doesn't contain "(void)", which means number of
parameters is undefined and thus compiler doesn't complain. Let's remove
parameters from all callers before enforcing "(void)" on it.
Related: OS#4138
Change-Id: I6d0dbbd83ce17ee798bfb6e30378ed1dbae19134
IMEIs (without the checksum) always have 14 digits. Replace the previous
check (length <= 14) with a proper one (length == 14) and set the buffer
to the right size. While at it, add the return code of
gsm48_decode_bc_number2() to the error log message.
I have tested with new TTCN3 tests, that the length check is working
properly now.
Related: OS#2541
Change-Id: I060a8db98fb882e4815d1709a5d85bc0143a73a6
Add a new vty option and allow to optionally generate a random msisdn,
as well as setting the default NAM:
subscriber-create-on-demand (no-msisdn|<3-15>) (none|cs|ps|both)
Thanks to Vadim for the random MSISDN patch [1], which was squashed into
this one.
[1] Change-Id: I475c71f9902950fa7498855a616e1ec231fad6ac
Depends on: Idc74f4d94ad44b9fc1b6d43178f5f33d551ebfb1 (libosmocore)
Change-Id: I0c9fe93f5c24b5e9fefb513c4d049fb7ebd47ecd
Related: OS#2542
So far, the cmdline argument was the only way to set a database config file.
Add a similar config to VTY as 'hlr' / 'database'. The cmdline arg is stronger
than the 'database' cfg item. DB is not reloaded from VTY command.
Change-Id: I87b8673324e1e6225afb758fb4963ff3279ea3d8
Checking the presence of msgb->l2h in read_cb_forward() doesn't
make sense, since in read_cb() we pass it to osmo_gsup_decode().
Let's rather do this before calling osmo_gsup_decode().
Fix for Change-Id: Ia4f345abc877baaf0a8f73b8988e6514d9589bf5
Change-Id: I69a3d31aacbbb1abef3d83e42e46c899fe2f914b
Printing 'OSMO_GSUP_MSGT_E_ROUTING_ERROR' in routing error messages
instead of the original message type may be confusing. Let's store
the original message type, and change just before sending.
Fix for Change-Id: Ia4f345abc877baaf0a8f73b8988e6514d9589bf5
Change-Id: Ic1db1e089fc0f8e03653a9f05058e95d2adaee39
If the session state is not set (OSMO_GSUP_SESSION_STATE_NONE),
osmo_gsup_encode() would omit the OSMO_GSUP_SESSION_ID_IE.
Fix for Change-Id: Ia4f345abc877baaf0a8f73b8988e6514d9589bf5
Change-Id: Idcd209a59d1ee5230104f3101740140d366b0646
Allow clients to forward any GSUP message between clients. Determine the
sender and receiver from the new {source,dest}_name{,_len} IEs. Reject
messages with a forged source name.
This will be used for the inter-MSC handover.
Depends: Ic00b0601eacff6d72927cea51767801142ee75db (libosmocore.git)
Related: OS#3793
Change-Id: Ia4f345abc877baaf0a8f73b8988e6514d9589bf5
As per the systemd.kill manual, when a service is going to be
stopped by systemd, the process will first be terminated via
SIGTERM. If then, after a delay, processes still remain, the
the termination request is repeated with the SIGKILL.
It was observed that osmo-hlr immediately terminates on SIGTERM,
leaving the SQLite database open. As a result, several temporary
files (such as hlr.db-shm, hlr.db-wal) remain, allowing the
further recovery:
DDB ERROR <0001> db.c:86 (283) recovered 10 frames from WAL file
Let's properly handle SIGTERM in the same way as we handle SIGINT.
Change-Id: I1a4a48b95bbaed74ff5a03fb5797a44bdb1fcd3a
Allow all functions to use hlr_ctx, so it can be used by the upcoming
read_cb_forward() function in [1]. That new function is placed next to
the existing read_cb() function, which is above the current hlr_ctx
declaration.
[1]: Change-Id: Ia4f345abc877baaf0a8f73b8988e6514d9589bf5
Related: OS#3793
Change-Id: I5edf0a233ff323a63e321a1ca47736b5b212d1bb
Use OSMO_GSUP_TO_MSGT_ERROR() instead. The other function has been
deprecated in [1].
Remove the < 0 return check, because the macro doesn't do any error
handling. It relies on all "request" messages having an appropriate
"error" message, which is part of the GSUP spec now (see [2]).
[1] change-id I46d9f2327791978710e2f90b4d28a3761d723d8f (libosmocore)
[2] change-id Iec1b4ce4b7d8eb157406f006e1c4241e8fba2cd6 (osmo-gsm-manuals)
Change-Id: I5435ec4c29d6acee814c33499c68d18aaa91d4fb
Add VTY config option "store-imei". When it is set, store the IMEI
sent from the VLR with CHECK-IMEI in the database.
Related: OS#2541
Change-Id: I09274ecbed64224f7ae305e09ede773931da2a57
Remove a misleading block in rx_upd_loc_req() around the call to
lu_op_tx_insert_subscr_data(). At least for me, this made the block look
like it belonged to the if statement above (which has no brackets),
before I looked more closely at it.
Change-Id: I96d3ba4108f4811279caf088a9179afce24e8112
Decode the IMEI from incoming CHECK-IMEI messages, print the IMEI to
the log and always send ACK back to the VLR/MSC.
In the future, we will not only log the IMEI, but store it in the HLR
(OS#2541). This is not the original intention of CHECK-IMEI from the
3GPP spec, but an useful side effect.
Depends: I085819df0ea7f3bfeb0cabebb5fd1942a23c6155 (libosmocore)
Related: OS#3733
Change-Id: Ib240474b0c3c603ba840cf26babb38a44dfc9364
It may happen that either the MS or an ESME would become
unresponsive, e.g. due to a bug, or a dropped message.
This is why we have SS session timeout, that prevents
keeping 'stalled' sessions forever.
Let's introduce a VTY option, which can be used to configure
this timer (by default it's set to 30 seconds):
hlr
...
! Use 0 to disable this timer
ncss-guard-timeout 30
Change-Id: I971fc2cee6fd46d4d5d6dac6c634e0b22fff183d
Related: OS#3717
Make use of pragma user_version to store our database schema version.
The present schema is now identitifed as 'version 0', which is also
the default value for databases on which we never ran the statement
'pragma user_version' before.
Only bootstrap the database if it hasn't been bootstrapped yet.
Previously, bootstrap SQL statements ran every time osmo-hlr
opened the database, and any errors were being ignored in SQL.
Instead, we now first run a query which checks whether tables
already exist, and only create them if necessary.
This change will allow future schema updates to work properly.
Prepare for future schema upgrades by adding a new command-line
option which enables upgrades. This option defaults to 'false'
in order to avoid accidental upgrades.
Change-Id: I8aeaa9a404b622657cbc7138106f38aa6ad8d01b
Related: OS#2838
Send updated subscriber data out to exactly those GSUP clients that match the
last LU operations (depending on each client sending distinct identification).
As this adds logging on DLGSUP, also change adjacent GSUP related logging from
DMAIN to DLGSUP.
Related: OS#2785
Change-Id: I7c317de8329d9a115d072fc61ddb9abc21b7e8d8
Store the GSUP client's IPA_IDTAG_SERNR in vlr_number or sgsn_number (depending
on is_ps), just before sending the Insert Subscriber Data message after a
successful LU Req. Log about it.
Original patch: Ib2611421f3638eadc361787af801fffe9a34bd8a by laforge
Related: OS#2796
Change-Id: If438664faa5d68404f465f8b2002c6d03bbf3ceb
A missing 'else' in rx_upd_loc_req() causes *all* clients to be indicated as
is_ps=true regardless of the GSUP CN Domain IE that was received.
Replace that odd if cascade with a switch() that fixes the flawed logic. Hence
osmo-hlr now correctly indicates each client's is_ps, iff the client sends CN
Domain IEs in GSUP LU Request messages.
Related: OS#2796, OS#3601
Change-Id: I2c5fa9f5cae25cfd66afbf088303edff7d045a00
There are some requests that are best served inside the HLR, as it
has access to subscriber information such as MSISDN and IMSI.
This unfortunately required quite some restructuring of the USSD
related structures including the VTY syntax for adding routes.
The default config file has been updated to replicate the *#100#
built-in behavior of old OsmoNITB.
Closes: OS#2566
Change-Id: I1d09fab810a6bb9ab02904de72dbc9e8a414f9f9
We don't want any SS session to run for more than 30s. The timeout
is currently not refreshed.
If we need more comprehensive timeout handling, using osmo_fsm for SS
sessions might make sense.
Change-Id: I5c9fb6b619402d2a23fea9db99590143d85ac11a
It is a global variable, and it's sort of bogus if every C file
re-declares it as a static global variable that is assigned to the
same value as the "real" global one during start-up.
Change-Id: I6f3e50f071fb2fbbe58413b4760dc2215055a444
Tracking NULL memory contexts allows one to detect memory chunks
allocated outside the application's root context, which in most
cases are the result of some mistake.
For example, the VTY implementation still uses the NULL context,
so we have to clean up it manually until this is fixed.
At the moment we have at least one chunk allocated outside the
application's root context (excluding the VTY context):
full talloc report on 'null_context' (total 24 bytes in 2 blocks)
struct lookup_helper contains 24 bytes in 1 blocks
Change-Id: I7ea86730e090c06b2a5966ae4d04b8144b1cd20a
This makes both ASAN and Valgrind happy, because they do expect
all allocated heap chunks to be released on exit.
Change-Id: I7345dec8d06b0b71a859c16132dc0008cfe17cba
There were a few lines of dead code below the osmo_select_main()
loop, while the actual deinitialization code was a part of SIGINT
handler. Let's reanimate this dead zone by moving the code there
and introducing a global 'loop-breaker' variable.
Change-Id: I0e2d673b420193e2bdc1a92377aca542f3a19229
During the attempt to fix OS#2785 in Change-Id
I6a92ca34cdaadca9eacc774bb1ca386c325ba865, we introduced logic that
would blindly insert a subscriber *concurrently* in all VLRs/SGSNs of
the network on any update of the subscriber.
Before that patch, we didn't update the current serving SGSN/VLR,
and after the change we created subscribers in all SGSNs/VLRs, of which
all-1 are not serving the subscriber at that time.
We'll have to go back to the original behavior until a proper fix can
be introduced.
Change-Id: Ibf6f1b21b08560d4d8f41bbe7782d40abf4585f8
Related: OS#3091
Related: OS#2785
Neels Hofmeyr
Harald Welte
Pau Espin
Oliver Smith