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
Save the source IPA name in ss_session, so we can send "invalid IMSI"
messages to the originating MSC.
Remove the fixed size from ss->vlr_number (we don't know the size of the
IPA name when it does not come from the database). Add
ss->vlr_number_len to give osmo_gsup_addr_send() the format it expects,
and to have one less place in the code where the IPA names are not
stored as blob.
Looking up the IPA name from struct osmo_gsup_conn could either be done
like in osmo_gsup_server_ccm_cb() by reading the IPA IEs (which has a
FIXME comment), or by finding the route associated with conn. I went
with the latter approach, because it seems cleaner to me.
Related: OS#3710
Change-Id: If5a65f471672949192061c5fe396603611123bc1
hlr_ussd.c so far hardcoded osmo-msc's default IPA-name and hence was
only able to negotiate USSD sessions to
- a single osmo-msc
- that has no custom IPA-name set.
Fix: correctly route USSD to any number of MSC with any custom IPA
names.
Resolve the right MSC's IPA name from the USSD session's IMSI, using
hlr_subscriber->vlr_number to determine the right GSUP peer. Cache it in
ss_session->vlr_number to have at most one db hit for routing per
session.
Related: OS#3710
Change-Id: I18067bfadd33a6bc59a9ee336b6937313826fce3
Describe the addr, addrlen parameters in gsup_route_find() and (more
commonly used) osmo_gsup_addr_send(). Without this description, it is
easy to get the parameters wrong and have routes not being found, as
shown with debug prints like these:
gsup_route_find: addr, addrlen: "MSC-13-37-00-00-00-00", 21
gsup_route_find: comparing with: "MSC-13-37-00-00-00-00\0", 22
Change-Id: Ib79878970bd07caac6eb921af8ae95403b90a4cb
This ensures that the rpath of the generated binaries is set to use only
the just-compiled so-files and not any system-wide installed libraries
while avoiding the ugly shell script wrapper.
Change-Id: I927561289b17b313d52fb5c1da55e237fc1d33be
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
Display the IMEI in "subscriber ... show", allow showing and modifying
subscribers by their IMEI with: "subscriber imei ...". For debug
purposes (and to have proper VTY tests), make it possible to change the
IMEI with "subscriber ... update imei".
IMEIs are saved in the database without the 15th checksum number. When
the checksum gets passed, verify it and cut it off.
Related: OS#2541
Depends: I02b54cf01a674a1911c5c897fbec02240f88b521 (libosmocore)
Change-Id: I1af7b573ca2a1cb22497052665012d9c1acf3b30
Create a test_subscriber.vty.sql file with a dummy entry that has the
ID 100. All entries created in test_subscriber.vty have an ID > 100
now. This will be used in follow-up commit [1] to create a database
entry with an invalid IMEI value to test the related error handling
code path (that entry could not be created through the VTY).
[1]: change-id I1af7b573ca2a1cb22497052665012d9c1acf3b30
"VTY: integrate IMEI"
Related: OS#3733
Change-Id: I48a3a503d7ca96798e2d5f70429b5fc36393420e
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
Extend the database scheme, add imei to the hlr_subscriber struct and
create db_subscr_update_imei_by_imsi() and db_subscr_get_by_imei(). The
new functions are used in db_test, and in follow-up commits [1], [2].
Upgrade DB schema to version 2. SQLite can only insert new columns at
the end of the table, so this happens when upgrading the database. In
new databases, the column is placed after the IMEISV column (where it
makes more sense in my opinion). This should not have any effect, as
we never rely on the order of the columns in the tables.
Follow-up commit [1] will make use of this column to save the IMEI as
received from the MSC/VLR with the Check-IMEI Procedure. It was
decided to use Check-IMEI instead of the recent Automatic Device
Detection Procedure (which would send the IMEISV) in OS#3733, because
with Check-IMEI we don't need to rely on very recent releases of the
specification.
[1] change-id I09274ecbed64224f7ae305e09ede773931da2a57
"Optionally store IMEI in subscriber table"
[2] change-id I1af7b573ca2a1cb22497052665012d9c1acf3b30
"VTY: integrate IMEI"
Depends: Id2d2a3a93b033bafc74c62e15297034bf4aafe61 (libosmocore)
Related: OS#2541
Change-Id: If232c80bea35d5c6864b889ae92d477eeaa3f45d
The output of "logging level" was wrongly indented with two speaces, and
in commit 0d67f483e2d240089105a4d241cb8c9085e245af of libosmocore, first
released as part of libosmcoore-1.0.0 it was fixed.
This makes "make check" pass against libosmocore-1.0.0, but not against
earlier releases.
Change-Id: I2cc12b3f0df19d9055022db41f7f3f2789bd19c6
Change the Synopsis and Options sections of the Running OsmoHLR chapter
to list the arguments in the same order as osmo-hlr. This makes it
easier to compare, which options are already documented, and which ones
are missing.
A follow-up commit will document the missing -U/--db-upgrade option.
Change-Id: If866124e9cfb43c6986d458712961713541e03b6
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
Several parts of OsmoMSC (e.g. GSM 04.11, 09.11, etc.) are dealing
with GSUP message encoding and sending towards OsmoHLR. In order
to avoid code duplication, let's have a shared function here.
Change-Id: I0589ff27933e9bca2bcf93b8259004935778db8f
Read the subscriber's last location update timestamp from the
database and display it in the output of 'show subscriber'.
For example:
OsmoHLR> show subscriber id 1
ID: 1
IMSI: 123456789000000
MSISDN: 543210123456789
VLR number: 712
SGSN number: 5952
last LU seen: Fri Dec 7 11:30:51 2018 UTC
While the database stores the timestamp as a string, we
convert the timestamp into time_t for internal use.
This allows for flexible potential use of the timestamp
in contexts other than the VTY in the future.
The timestamp displayed in the VTY is created with ctime_r(3).
It does not match the format of the raw string in the database:
sqlite> select id,last_lu_seen from subscriber;
1|2018-12-07 11:30:51
Related: OS#2838
Change-Id: Ie180c434f02ffec0d4b2f651a73258a8126b2e1a
Avoid string concatenations without interleaving whitespace.
Some compilers don't like "foo""bar", they only like "foo" "bar".
Requested by: Pau
https://gerrit.osmocom.org/c/osmo-hlr/+/12121/5/src/db_hlr.c#637
Change-Id: Ic7a81114f9afbefcbd62d434720854cfdd4a2dd9
Timestamps are stored in the HLR DB in the new 'last_lu_seen' column
of the 'subscriber' table, in UTC and in granularity of seconds.
At present, osmo-hlr only records these timestamps but otherwise
makes no use of them. Because the timestamps are stored in a
human-readable form, they may already provide value to external
processes which need this information. For example:
sqlite> select imsi,last_lu_seen from subscriber;
901990000000001|2018-12-04 14:17:12
I didn't bother adding additional tests because the code added
with this commit is already being exercised by several calls
to db_subscr_lu() in db_test.c.
This change requires a HLR DB schema update. Existing databases
won't be upgraded automatically. However, osmo-hlr will refuse
to operate with databases which are not upgraded.
Change-Id: Ibeb49d45aec18451a260a6654b8c51b8fc3bec50
Related: OS#2838
Add a new API which allows creating a GSUP client connection with
more identification information than just a unit name. Instead of
being selective about which idenfifiers callers may use, allow
callers to pass a full-blown struct ipaccess_unit. This allows
applications to use entirely custom identifiers on GSUP client
connections.
This change is a prerequisite for inter-MSC handover because MSCs
will need to use unique identifiers towards the HLR, which isn't
very easy to do with the old osmo_gsup_client_create() API. While
it's always been possible to pass a unique unit_name, this is not
as flexible as we would like.
The old API remains for backwards compatibility.
struct osmo_gsup_client grows in size but is allocated internally
by the library; old calling code won't notice the difference.
Change-Id: Ief09677e07d6e977247185b72c605f109aa091f5
Related: OS#3355
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.
For some reason, it wasn't properly resceduled in case of
subsequent SS/USSD activity, so the lifetime of a session
was limited. Let's properly (re)schedule it.
Change-Id: I11aeacf012b06d3d0b5cc6e64baecf857b645fda
Related: OS#3717
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
Oliver Smith
Vadim Yanitskiy
Harald Welte