2019-11-20 09:56:35 +00:00
|
|
|
SUBDIRS = \
|
|
|
|
gsupclient \
|
|
|
|
mslookup \
|
|
|
|
$(NULL)
|
2018-07-23 12:25:33 +00:00
|
|
|
|
2016-12-10 23:27:48 +00:00
|
|
|
AM_CFLAGS = \
|
|
|
|
-Wall \
|
|
|
|
$(LIBOSMOCORE_CFLAGS) \
|
|
|
|
$(LIBOSMOGSM_CFLAGS) \
|
|
|
|
$(LIBOSMOVTY_CFLAGS) \
|
2017-03-02 11:12:00 +00:00
|
|
|
$(LIBOSMOCTRL_CFLAGS) \
|
2019-11-20 02:35:37 +00:00
|
|
|
$(LIBOSMOMSLOOKUP_CFLAGS) \
|
2016-12-10 23:27:48 +00:00
|
|
|
$(LIBOSMOABIS_CFLAGS) \
|
|
|
|
$(SQLITE3_CFLAGS) \
|
|
|
|
$(NULL)
|
|
|
|
|
2018-07-28 20:00:08 +00:00
|
|
|
AM_CPPFLAGS = -I$(top_srcdir)/include \
|
2019-11-19 23:37:07 +00:00
|
|
|
-I$(top_builddir)/include \
|
2018-07-28 20:00:08 +00:00
|
|
|
$(NULL)
|
|
|
|
|
2016-12-10 23:27:48 +00:00
|
|
|
EXTRA_DIST = \
|
|
|
|
populate_hlr_db.pl \
|
2018-12-04 13:13:47 +00:00
|
|
|
db_sql2c.sed \
|
2016-12-10 23:27:48 +00:00
|
|
|
$(NULL)
|
|
|
|
|
automatically create db tables on osmo-hlr invocation
If a database file is missing, osmo-hlr creates it, as is the default sqlite3
API behavior -- before this patch, that db file is created, but lacks useful
tables. Actually also create initial tables in it, as osmo-nitb did.
In effect, the 'vty-test' target in tests/Makefile.am no longer needs to create
a database manually. (The 'ctrl-test' still does, because it also wants to add
subscriber data on top of the bare tables.)
Note: it could be desirable to bail if the desired database file does not
exist. That is however a different semantic from this patch; this is not
changing the fact that a db file is created, this just creates a usable one.
Note: I am about to add osmo-hlr-db-tool to do database migration from
osmo-nitb. For that, it is desirable to bootstrap a usable database, which is
the core reason for this patch.
Don't plainly duplicate hlr.sql to .c, but create db_bootstrap.h as a
BUILT_SOURCE from reading in sql/hlr.sql and mangling via sed to a list of SQL
statement strings. On each db_open(), run this bootstrap sequence.
In sql/hlr.sql, these tweaks are necessary:
* Add 'IF NOT EXISTS' to 'CREATE TABLE', so that the bootstrap sequence can be
run on an already bootstrapped db.
* Drop the final comment at the bottom, which ended up being an empty SQL
statement and causing sqlite3 API errors, seemed to have no purpose anyway.
Note: by composing the statement strings as multiline and including the SQL
comments, sqlite3 actually retains the comments contained in table definitions
and prints them back during 'sqlite3 hlr.db .dump'.
Change-Id: If77dbbfe1af3e66aaec91cb6295b687f37678636
2017-10-24 21:26:27 +00:00
|
|
|
BUILT_SOURCES = \
|
|
|
|
db_bootstrap.h \
|
|
|
|
$(NULL)
|
|
|
|
CLEANFILES = $(BUILT_SOURCES)
|
|
|
|
|
2016-12-10 23:27:48 +00:00
|
|
|
noinst_HEADERS = \
|
automatically create db tables on osmo-hlr invocation
If a database file is missing, osmo-hlr creates it, as is the default sqlite3
API behavior -- before this patch, that db file is created, but lacks useful
tables. Actually also create initial tables in it, as osmo-nitb did.
In effect, the 'vty-test' target in tests/Makefile.am no longer needs to create
a database manually. (The 'ctrl-test' still does, because it also wants to add
subscriber data on top of the bare tables.)
Note: it could be desirable to bail if the desired database file does not
exist. That is however a different semantic from this patch; this is not
changing the fact that a db file is created, this just creates a usable one.
Note: I am about to add osmo-hlr-db-tool to do database migration from
osmo-nitb. For that, it is desirable to bootstrap a usable database, which is
the core reason for this patch.
Don't plainly duplicate hlr.sql to .c, but create db_bootstrap.h as a
BUILT_SOURCE from reading in sql/hlr.sql and mangling via sed to a list of SQL
statement strings. On each db_open(), run this bootstrap sequence.
In sql/hlr.sql, these tweaks are necessary:
* Add 'IF NOT EXISTS' to 'CREATE TABLE', so that the bootstrap sequence can be
run on an already bootstrapped db.
* Drop the final comment at the bottom, which ended up being an empty SQL
statement and causing sqlite3 API errors, seemed to have no purpose anyway.
Note: by composing the statement strings as multiline and including the SQL
comments, sqlite3 actually retains the comments contained in table definitions
and prints them back during 'sqlite3 hlr.db .dump'.
Change-Id: If77dbbfe1af3e66aaec91cb6295b687f37678636
2017-10-24 21:26:27 +00:00
|
|
|
db_bootstrap.h \
|
2016-12-10 23:27:48 +00:00
|
|
|
$(NULL)
|
|
|
|
|
|
|
|
bin_PROGRAMS = \
|
|
|
|
osmo-hlr \
|
2017-10-24 21:26:53 +00:00
|
|
|
osmo-hlr-db-tool \
|
2018-07-28 20:00:08 +00:00
|
|
|
osmo-euse-demo \
|
2016-12-12 16:34:25 +00:00
|
|
|
$(NULL)
|
|
|
|
|
2016-12-10 23:27:48 +00:00
|
|
|
osmo_hlr_SOURCES = \
|
|
|
|
auc.c \
|
2017-03-02 11:12:00 +00:00
|
|
|
ctrl.c \
|
2016-12-10 23:27:48 +00:00
|
|
|
db.c \
|
|
|
|
db_auc.c \
|
|
|
|
db_hlr.c \
|
|
|
|
gsup_router.c \
|
|
|
|
gsup_server.c \
|
|
|
|
hlr.c \
|
|
|
|
logging.c \
|
|
|
|
rand_urandom.c \
|
2017-01-30 22:30:26 +00:00
|
|
|
hlr_vty.c \
|
2017-10-06 00:59:54 +00:00
|
|
|
hlr_vty_subscr.c \
|
2018-05-04 14:06:32 +00:00
|
|
|
gsup_send.c \
|
2023-09-21 01:55:51 +00:00
|
|
|
hlr_sms.c \
|
2018-06-15 20:04:28 +00:00
|
|
|
hlr_ussd.c \
|
2019-11-20 02:35:37 +00:00
|
|
|
proxy.c \
|
|
|
|
dgsm.c \
|
|
|
|
remote_hlr.c \
|
1/2: refactor: add and use lu_fsm, osmo_gsup_req, osmo_ipa_name
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
2019-11-20 01:36:45 +00:00
|
|
|
lu_fsm.c \
|
2019-11-20 02:35:37 +00:00
|
|
|
timestamp.c \
|
2019-11-20 02:35:37 +00:00
|
|
|
mslookup_server.c \
|
|
|
|
mslookup_server_mdns.c \
|
|
|
|
dgsm_vty.c \
|
2016-12-10 23:27:48 +00:00
|
|
|
$(NULL)
|
|
|
|
|
|
|
|
osmo_hlr_LDADD = \
|
1/2: refactor: add and use lu_fsm, osmo_gsup_req, osmo_ipa_name
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
2019-11-20 01:36:45 +00:00
|
|
|
$(top_builddir)/src/gsupclient/libosmo-gsup-client.la \
|
2019-11-20 02:35:37 +00:00
|
|
|
$(top_builddir)/src/mslookup/libosmo-mslookup.la \
|
2016-12-10 23:27:48 +00:00
|
|
|
$(LIBOSMOCORE_LIBS) \
|
|
|
|
$(LIBOSMOGSM_LIBS) \
|
|
|
|
$(LIBOSMOVTY_LIBS) \
|
2017-03-02 11:12:00 +00:00
|
|
|
$(LIBOSMOCTRL_LIBS) \
|
2019-11-20 02:35:37 +00:00
|
|
|
$(LIBOSMOMSLOOKUP_LIBS) \
|
2016-12-10 23:27:48 +00:00
|
|
|
$(LIBOSMOABIS_LIBS) \
|
|
|
|
$(SQLITE3_LIBS) \
|
|
|
|
$(NULL)
|
|
|
|
|
2017-10-24 21:26:53 +00:00
|
|
|
osmo_hlr_db_tool_SOURCES = \
|
|
|
|
hlr_db_tool.c \
|
|
|
|
db.c \
|
|
|
|
db_hlr.c \
|
|
|
|
logging.c \
|
|
|
|
rand_urandom.c \
|
|
|
|
dbd_decode_binary.c \
|
2019-12-04 00:04:32 +00:00
|
|
|
$(srcdir)/gsupclient/cni_peer_id.c \
|
2017-10-24 21:26:53 +00:00
|
|
|
$(NULL)
|
|
|
|
|
|
|
|
osmo_hlr_db_tool_LDADD = \
|
|
|
|
$(LIBOSMOCORE_LIBS) \
|
|
|
|
$(LIBOSMOGSM_LIBS) \
|
|
|
|
$(SQLITE3_LIBS) \
|
|
|
|
$(NULL)
|
|
|
|
|
2018-07-28 20:00:08 +00:00
|
|
|
osmo_euse_demo_SOURCES = \
|
|
|
|
osmo-euse-demo.c \
|
|
|
|
$(NULL)
|
|
|
|
|
|
|
|
osmo_euse_demo_LDADD = \
|
|
|
|
$(top_builddir)/src/gsupclient/libosmo-gsup-client.la \
|
|
|
|
$(LIBOSMOCORE_LIBS) \
|
|
|
|
$(LIBOSMOGSM_LIBS) \
|
|
|
|
$(NULL)
|
|
|
|
|
2018-07-31 15:40:30 +00:00
|
|
|
if DB_SQLITE_DEBUG
|
|
|
|
osmo_hlr_SOURCES += db_debug.c
|
|
|
|
osmo_hlr_db_tool_SOURCES += db_debug.c
|
|
|
|
endif
|
|
|
|
|
automatically create db tables on osmo-hlr invocation
If a database file is missing, osmo-hlr creates it, as is the default sqlite3
API behavior -- before this patch, that db file is created, but lacks useful
tables. Actually also create initial tables in it, as osmo-nitb did.
In effect, the 'vty-test' target in tests/Makefile.am no longer needs to create
a database manually. (The 'ctrl-test' still does, because it also wants to add
subscriber data on top of the bare tables.)
Note: it could be desirable to bail if the desired database file does not
exist. That is however a different semantic from this patch; this is not
changing the fact that a db file is created, this just creates a usable one.
Note: I am about to add osmo-hlr-db-tool to do database migration from
osmo-nitb. For that, it is desirable to bootstrap a usable database, which is
the core reason for this patch.
Don't plainly duplicate hlr.sql to .c, but create db_bootstrap.h as a
BUILT_SOURCE from reading in sql/hlr.sql and mangling via sed to a list of SQL
statement strings. On each db_open(), run this bootstrap sequence.
In sql/hlr.sql, these tweaks are necessary:
* Add 'IF NOT EXISTS' to 'CREATE TABLE', so that the bootstrap sequence can be
run on an already bootstrapped db.
* Drop the final comment at the bottom, which ended up being an empty SQL
statement and causing sqlite3 API errors, seemed to have no purpose anyway.
Note: by composing the statement strings as multiline and including the SQL
comments, sqlite3 actually retains the comments contained in table definitions
and prints them back during 'sqlite3 hlr.db .dump'.
Change-Id: If77dbbfe1af3e66aaec91cb6295b687f37678636
2017-10-24 21:26:27 +00:00
|
|
|
BOOTSTRAP_SQL = $(top_srcdir)/sql/hlr.sql
|
|
|
|
|
2018-12-04 13:13:47 +00:00
|
|
|
db_bootstrap.h: $(BOOTSTRAP_SQL) $(srcdir)/db_sql2c.sed
|
|
|
|
echo "/* DO NOT EDIT THIS FILE. It is generated from files in osmo-hlr.git/sql/ */" > "$@"
|
automatically create db tables on osmo-hlr invocation
If a database file is missing, osmo-hlr creates it, as is the default sqlite3
API behavior -- before this patch, that db file is created, but lacks useful
tables. Actually also create initial tables in it, as osmo-nitb did.
In effect, the 'vty-test' target in tests/Makefile.am no longer needs to create
a database manually. (The 'ctrl-test' still does, because it also wants to add
subscriber data on top of the bare tables.)
Note: it could be desirable to bail if the desired database file does not
exist. That is however a different semantic from this patch; this is not
changing the fact that a db file is created, this just creates a usable one.
Note: I am about to add osmo-hlr-db-tool to do database migration from
osmo-nitb. For that, it is desirable to bootstrap a usable database, which is
the core reason for this patch.
Don't plainly duplicate hlr.sql to .c, but create db_bootstrap.h as a
BUILT_SOURCE from reading in sql/hlr.sql and mangling via sed to a list of SQL
statement strings. On each db_open(), run this bootstrap sequence.
In sql/hlr.sql, these tweaks are necessary:
* Add 'IF NOT EXISTS' to 'CREATE TABLE', so that the bootstrap sequence can be
run on an already bootstrapped db.
* Drop the final comment at the bottom, which ended up being an empty SQL
statement and causing sqlite3 API errors, seemed to have no purpose anyway.
Note: by composing the statement strings as multiline and including the SQL
comments, sqlite3 actually retains the comments contained in table definitions
and prints them back during 'sqlite3 hlr.db .dump'.
Change-Id: If77dbbfe1af3e66aaec91cb6295b687f37678636
2017-10-24 21:26:27 +00:00
|
|
|
echo "#pragma once" >> "$@"
|
2023-06-04 08:48:04 +00:00
|
|
|
echo "static const char * const stmt_bootstrap_sql[] = {" >> "$@"
|
automatically create db tables on osmo-hlr invocation
If a database file is missing, osmo-hlr creates it, as is the default sqlite3
API behavior -- before this patch, that db file is created, but lacks useful
tables. Actually also create initial tables in it, as osmo-nitb did.
In effect, the 'vty-test' target in tests/Makefile.am no longer needs to create
a database manually. (The 'ctrl-test' still does, because it also wants to add
subscriber data on top of the bare tables.)
Note: it could be desirable to bail if the desired database file does not
exist. That is however a different semantic from this patch; this is not
changing the fact that a db file is created, this just creates a usable one.
Note: I am about to add osmo-hlr-db-tool to do database migration from
osmo-nitb. For that, it is desirable to bootstrap a usable database, which is
the core reason for this patch.
Don't plainly duplicate hlr.sql to .c, but create db_bootstrap.h as a
BUILT_SOURCE from reading in sql/hlr.sql and mangling via sed to a list of SQL
statement strings. On each db_open(), run this bootstrap sequence.
In sql/hlr.sql, these tweaks are necessary:
* Add 'IF NOT EXISTS' to 'CREATE TABLE', so that the bootstrap sequence can be
run on an already bootstrapped db.
* Drop the final comment at the bottom, which ended up being an empty SQL
statement and causing sqlite3 API errors, seemed to have no purpose anyway.
Note: by composing the statement strings as multiline and including the SQL
comments, sqlite3 actually retains the comments contained in table definitions
and prints them back during 'sqlite3 hlr.db .dump'.
Change-Id: If77dbbfe1af3e66aaec91cb6295b687f37678636
2017-10-24 21:26:27 +00:00
|
|
|
cat "$(BOOTSTRAP_SQL)" \
|
2018-12-04 13:13:47 +00:00
|
|
|
| sed -f "$(srcdir)/db_sql2c.sed" \
|
automatically create db tables on osmo-hlr invocation
If a database file is missing, osmo-hlr creates it, as is the default sqlite3
API behavior -- before this patch, that db file is created, but lacks useful
tables. Actually also create initial tables in it, as osmo-nitb did.
In effect, the 'vty-test' target in tests/Makefile.am no longer needs to create
a database manually. (The 'ctrl-test' still does, because it also wants to add
subscriber data on top of the bare tables.)
Note: it could be desirable to bail if the desired database file does not
exist. That is however a different semantic from this patch; this is not
changing the fact that a db file is created, this just creates a usable one.
Note: I am about to add osmo-hlr-db-tool to do database migration from
osmo-nitb. For that, it is desirable to bootstrap a usable database, which is
the core reason for this patch.
Don't plainly duplicate hlr.sql to .c, but create db_bootstrap.h as a
BUILT_SOURCE from reading in sql/hlr.sql and mangling via sed to a list of SQL
statement strings. On each db_open(), run this bootstrap sequence.
In sql/hlr.sql, these tweaks are necessary:
* Add 'IF NOT EXISTS' to 'CREATE TABLE', so that the bootstrap sequence can be
run on an already bootstrapped db.
* Drop the final comment at the bottom, which ended up being an empty SQL
statement and causing sqlite3 API errors, seemed to have no purpose anyway.
Note: by composing the statement strings as multiline and including the SQL
comments, sqlite3 actually retains the comments contained in table definitions
and prints them back during 'sqlite3 hlr.db .dump'.
Change-Id: If77dbbfe1af3e66aaec91cb6295b687f37678636
2017-10-24 21:26:27 +00:00
|
|
|
>> "$@"
|
|
|
|
echo "};" >> "$@"
|