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
The db bootstrap as well as the upgrade code all execute a number of
statements, and have massive code dup around each statement execution. Instead
have one db_run_statements() that takes an array of strings and runs all.
Change-Id: I2721dfc0a9aadcc7f5ac81a1c0fa87452098996f
The osmo-hlr DB schema indicates a hlr_number column and references it as 3GPP
TS 23.008 chapter 2.4.6. However, chapter 2.4.6 refers to the "MSC number",
while the "HLR number" is chapter 2.4.7.
Taking a closer look, 2.4.6 says "The MSC number is [...] stored in the HLR",
while 2.4.7 says "The HLR number may be stored in the VLR". As quite obvious,
the HLR does not store the HLR number. This was a typo from the start.
The osmo-hlr code base so far does not use the hlr_number column at all, so we
get away with renaming the column without any effects on the code base.
However, let's rather make this a new schema version to be safe.
Change-Id: I527e8627b24b79f3e9eec32675c7f5a3a6d25440
Skip the test if the installed sqlite version is older than 3.16.2
(current version of debian 9). This prevents test failures caused by
the way we dump tables in the test, which does not work with older
versions.
This patch is a middle ground between reverting the db upgrade patch,
and spending lots of time to replace the table dumping code with
something that works with old sqlite versions to fix current build
failures in OBS.
Usually version checking is done in configure.ac, however I could not
find a good way to pass the result to testsuite.at. So I decided to
use pkg-config to do the test there.
Fixes: 5b65461d68 ("add db_upgrade test")
Related: https://lists.osmocom.org/pipermail/openbsc/2019-November/013063.html
Change-Id: I348c133003a95badbd6807d1519aa669115872fb
We have a database schema upgrade path, but so far nothing that verifies that
we don't break it. It almost seems like the user data weren't important to us!?
Add a db upgrade test:
- Create a db with an .sql dump taken from a db created with an old osmo-hlr,
producing DB schema version 0.
- Run osmo-hlr --db-upgrade --db-check
- Verify that the upgrade exited successfully.
- Verify that restarting with the upgraded DB works.
If python tests are enabled, also:
- create a new database using the new osmo-hlr (just built).
- replay a VTY transcript to create subscribers as in the old snapshot.
- replay some sql modifications as done in the old snapshot.
- Get a list of sorted table names,
- a list of their sorted columns with all their properties,
- and dump the table contents in a column- and value-sorted way.
- Compare the resulting dumps and error if there are any diffs.
(This is how I found the difference in the imei column that was fixed in
I68a00014a3d603fcba8781470bc5285f78b538d0)
Change-Id: I0961bab0e17cfde5b030576c5bc243c2b51d9dc4
Move a comment for ind_bitlen column to a separate line, so that it doesn't
show in PRAGMA_TABLE_INFO('subscriber').
An upcoming patch introduces db_upgrade_test, which dumps a sorted db schema.
In newer sqlite3 versions, a comment following a 'DEFAULT' keyword actually
shows up in the PRAGMA_TABLE_INFO() results (on my machine), but older versions
(on the build slaves) drop that comment. The ind_bitlen column is the only one
producing this odd side effect, because it is the last column and has no comma
between 'DEFAULT' and the comment.
The easiest way to get matching results across sqlite3 client versions is to
move the comment to above ind_bitlen instead of having it on the same line.
(Adding a comma doesn't work.)
Change-Id: Id66ad68dd3f22d533fc3a428223ea6ad0282bde0
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
A subsequent commit will add a db_upgrade test, which verifies that the db
resulting from an upgrade is identical to one created from scratch in the new
version. That test currently would show a diff: an upgraded 'imei' column has
'default NULL', where a new db created in version 2 has no default value on the
imei column.
Fix the upgrade path to add an imei column without 'default NULL', so that
adding the upgrade test will result in success. The test is added in
I0961bab0e17cfde5b030576c5bc243c2b51d9dc4
Change-Id: I68a00014a3d603fcba8781470bc5285f78b538d0
Use three dots to avoid checking for exact commands between help and
exit, which originate from libosmocore. This avoids test failues when
we slightly change the commands, like the change from "write file" to
"write file [PATH]" in [1] that is currently causing the vty tests to
fail.
[1] libosmocore I38edcf902a08b6bd0ebb9aa6fc1a7041421af525
Change-Id: I4a964b86195141e5a50705425206f3602f908999
Previous commit changed db_test to output code names to fix issues on
some platforms (I guess due to different error code values), but somehow
this log line was not updated.
Fixes: 8b860e54be
Change-Id: I598de6f83a86d528174d3d188596314572f5d70d
Current code uses GSM23003_MSISDN_MAX_DIGITS, which is only available in
libosmocore 1.2.0 onwards. Let's update configure.ac accordingly.
Fixes: 2e403d6c3f
Change-Id: Iad03a8cf7a36bdc824ec2acc8fb8f9c27a1c0421
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
This change introduces an optional feature that allows to make
SQLite3 use talloc for all internal allocations. This would
facilitate finding memleaks. OsmoHLR needs to be configured
with '--enable-sqlite-talloc'.
full talloc report on 'OsmoHLR' (total 292168 bytes in 449 blocks)
struct osmo_gsup_server contains 162 bytes in 3 blocks (ref 0)
...
struct db_context contains 288407 bytes in 420 blocks (ref 0)
hlr.db contains 7 bytes in 1 blocks (ref 0)
SQLite3 contains 288192 bytes in 418 blocks (ref 0)
db.c:95 contains 48 bytes in 1 blocks (ref 0)
db.c:95 contains 2 bytes in 1 blocks (ref 0)
...
Unfortunately, old SQLite3 versions (such as 3.8.2) run out
of memory when trying to initialize a new database:
DDB ERROR db.c:88 (7) statement aborts at 3: []
DDB ERROR db.c:420 Unable to set Write-Ahead Logging: out of memory
DDB ERROR db.c:88 (7) statement aborts at 3: []
DDB ERROR db.c:238 Unable to prepare SQL statement
'SELECT name FROM sqlite_master WHERE type='table' AND name=?'
...
I've noticed a huge difference in heap usage footprint compared to
generic malloc. At the same time, the recent versions (at least
3.24.0), work just fine.
Change-Id: Icfe67ed0f063b63e6794f9516da3003d01cf20a7
Somehow both 'db_test_SOURCES' and 'db_test_LDADD' ended up in
'src/Makefile.am'. This causes automake / autoconf to complain.
Let's get rid of both useless declarations.
Furthermore, the actual 'db_test_LDADD' in 'tests/Makefile.am'
contained references to the source files from '$(top_srcdir)'.
Most likely, the original intention was to depend on the object
files in '$(top_builddir)'. Let's also fix this.
Change-Id: Ib2e436ed91d9b7551dc5b205329d468c2b0ced04
Replace commented out size check for Ki with a real check, and use it
consistently for Ki, K, OP and OPC. Add a test that sets all keys to the
wrong size and tries to read them.
Related: OS#2565
Change-Id: Ib8e8e9394fb65c6e7932ce9f8bebc321b99f7696
The SS payload is mandatory for GSUP PROC_SS_{REQ,RSP} messages
with session state BEGIN or CONTINUE, and optional for the END.
Make sure that it's present for both BEGIN and CONTINUE, consider
received message as incorrect otherwise. In case of the END, call
handle_ussd() / handle_ss() only if SS payload is present.
Change-Id: Ia71cabbf396bd1388e764a1749e953ac1782e307
Fixes: CID#188841
Write all VTY commands in monospace and add configuration example
blocks. Add an example VTY session for enabling CS and PS NAM.
Realted: OS#2542
Change-Id: I54f80810db3dac7a4a56ad42c5d2154b6006108c
Allow updating the NAM (Network Access Mode) of subscribers with the
VTY. This is important for the subscriber create on demand use case
where subscribers get created without access to PS and CS NAM by
default. Regenerate hlr_vty_reference.xml.
Related: OS#2542
Change-Id: I231e03219355ebe6467d62ae2e40bef9d8303e3b
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
The last LU time gets read from the database as string, parsed with
strptime to "struct tm", and then gets converted to time_t with mktime.
A recent behavior change in glibc's mktime implementation unconvered,
that we don't have tm.tm_isdst (daylight saving time) set properly. As
"struct tm" was not initialized, and strptime did not write to tm_isdst,
it was set to a random value. When it was not 0, db_test failed on UTC
systems with a more recent glibc (e.g. Ubuntu 19.04).
Fix this by zero-initializing "struct tm" and remove the previous
workaround that made db_test pass on UTC systems.
Related: OS#4026
Change-Id: Iebbbe42fc5cd43324206d9433ede67b39251389c
Apply workaround for db_test failure on ubuntu 19.04 in OBS. When the
timezone is set to UTC (default in OBS), and the glibc version is 2.29,
the test case is failing sometimes (not always) with the following
errors in the test log:
DAUC Cannot convert LU timestamp '2019-05-26 03:05:03' to time_t: Value too large for defined
Force the timezone to be CET when running the test, so it passes again.
I found this workaround in a Fedora bugreport [1], and tested with an
ubuntu 19.04 system running in docker, that setting the environment
variable like this makes the test pass 25 times in a row. Without it, it
fails every two or three times. Then I verified in my OBS namespace,
that the test also passes in OBS again.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1653340
Related: OS#4026
Change-Id: Ic8080ba1914bb364169ab0c563b132a4ab9a9aab
Add a new section in the subscribers chapter, with detailed explanation
of the use cases and related OsmoHLR and OsmoMSC configuration.
Related: OS#2542
Change-Id: I2dd4a56f7b8be8b5d0e6fc32e04459e5e278d0a9
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
Check if a subscriber exists without generating an error log entry if
it does not. This is cheaper than db_subscr_get_by_msisdn(), as it
does not fetch the subscriber entry.
subscriber-create-on-demand will use this function to generate
a random unique MSISDN for new subscribers.
Related: OS#2542
Change-Id: Ibfbc408c966197682ba2b12d166ade4bfeb7abc2
Check if a subscriber exists without generating an error log entry if
it does not. This is cheaper than db_subscr_get_by_imsi(), as it does
not fetch the subscriber entry. subscriber-create-on-demand will use
this function.
Related: OS#2542
Change-Id: I63818c0dd4fd22b41dadeeba2a07a651b5454c54
Allow creating new subscribers without giving them access to CS or PS.
This will be used by the create-subscriber-on-demand feature.
Related: OS#2542
Change-Id: I1a6dd85387723dab5487c53b33d2d9ec6d05d006
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
We have nothing to do with GSM 04.80 at the HLR - it's only used to
encapsulate the SS payload between MS and MSC. This is not that
critical, but may be misleading.
Also, gsm0480_msgb_alloc_name() allocates a smaller buffer:
return msgb_alloc_headroom(1024, 128, name);
than osmo_gsup_client_msgb_alloc() does:
return msgb_alloc_headroom(4000, 64, __func__);
Change-Id: Icdab40c6a933888eb9f51bee9c5264c8919dbf7b