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, the site's MSC and SGSN compete for 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 source_name as
indicator, which reflects the actual remote VLR's name.
Furthermore, make 100% sure that CS and PS pools can never collide, by keeping
all CS pools odd numbered and all PS pools even numbered.
Persist the site <-> IND assignments in the database.
Add an IND test to db_test.c
Related: OS#4319
Change-Id: I6f0a6bbef3a27507605c3b4a0e1a89bdfd468374
D-GSM will store in the HLR DB whether a locally connected MSC has attached the
subscriber (last_lu_seen[_ps]), or whether the attach happened via a GSUP proxy
from a different site.
Add columns for this separately in this patch.
Change-Id: I98c7b3870559ede84adf56e4bf111f53c7487745
Location Updating procedures from both CS and PS overwrite the same
last_lu_seen field of a subscriber. For upcoming D-GSM it will be important to
distinguish those, because only CS attaches qualify for MSISDN lookup.
Add column last_lu_seen_ps, and upon PS LU, do not overwrite last_lu_seen, so
that last_lu_seen now only reflects CS LU.
In the VTY, dump both LU dates distinctively.
Change-Id: Id7fc50567211a0870ac0524f6dee94d4513781ba
Instead of a switch() for each version number with identical switch cases
except for the function name, use an array of function pointers and loop.
Also print a success message after each individual version upgrade, instead of
only one in the end (see change in db_upgrade_test.ok).
Change-Id: I1736af3d9a3f02e29db836966ac15ce49f94737b
db_upgrade_test.sh:
- If an ~/.sqliterc file exists, it causes output of '-- Loading resources from
~/.sqliterc'. Use -batch option to omit that.
- To make sure that column headers are off when required, add -noheaders in
some places.
Change-Id: I279a39984563594a4a3914b2ce3d803ad9468fe8
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
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
Neels Hofmeyr