So far we have only GERAN-A and UTRAN-Iu, but to be future compatible,
implement an arbitrary length list of RAT types: add DB table subscriber_rat.
Backwards compatibility: if there is no entry in subscriber_rat, all RAT types
shall be allowed. As soon as there is an entry, it can either be false to
forbid a RAT or true to still allow a RAT type.
Depends: I93850710ab55a605bf61b95063a69682a2899bb1 (libosmocore)
Change-Id: I3e399ca8a85421f77a9a15e608413d1507722955
So far, the time string format comes from ctime_r, and we manually add "UTC" to it.
The ctime_r format is wildly chaotic IMHO, mixing weekday, day-of-month and
hour and year in very unsorted ways.
Adding "UTC" to it is non-standard.
Instead use an ISO-8601 standardized time string via strftime().
Change-Id: I6731968f05050399f4dd43b241290186e0c59e1a
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
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
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
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
Add the first "official" way to remove the MSISDN from a subscriber entry, to
go back to 'MSISDN: none' like just after 'subscriber create'.
Add VTY command 'subscriber <ID> update msisdn none' to drop the MSISDN from
the subscriber. (Like 'subscriber <ID> update aud3g none')
Add DB_STMT_DELETE_MSISDN_BY_IMSI.
In db_subscr_update_msisdn_by_imsi(), allow passing a NULL msisdn, and if NULL,
call above delete SQL statement.
Change-Id: I15419105ea461137776adb92d384d8985210c90e
When I wrote the osmo-hlr subscriber command, I failed to heed the common
'show foo' scheme and instead created a 'subscriber [...] show' command.
Relieve that weirdness by creating an alias that has 'show' at the start.
Arrange string macros so that the 'show subscriber' cmd doesn't end in a space
(the SUBSCR macro ends in a space ' ' to implicitly include the space to
commands like 'create', 'show', 'update').
Add the new command to test_nodes.vty and test_subscriber.vty.
Change-Id: I01ce9b0868302d40ed05c6a588316a194d6071e4
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
Add a function which triggers subscriber update notifications to
all connected GSUP clients, and invoke it when the MSISDN of a
subscriber is changed via VTY.
This makes the TTCN3 HLR test TC_vty_msisdn_isd pass.
Note that the new function currently relies on implementation
details of the Location Update Operation (luop) code.
Because of this we currently log a slightly misleading message
when the updated Insert Subscriber Data message is sent:
"luop.c:161 LU OP state change: LU RECEIVED -> ISD SENT"
This message is misleading because, in fact, no location update
message was received from a GSUP client at that moment.
So while this change fixes the externally visible behaviour, we may
want to follow this up with some refactoring to avoid relying on
luop internals. It seems acceptable to do that in a separate step
since such a change will be more involved and harder to review.
We may want to trigger such notifications in other situations as well.
This is left for future work, too. There are no TTCN3 test cases for
other situations yet, as far as I can see.
Related: OS#2785
Change-Id: Iffe1d7afb9fc7dbae542f70bbf5391ddc08a14b4
It's a bit confusing to the user if he wants to set AUD=none
and it's already none. Avoid printing error messages in that case.
Change-Id: I5f32dd5d6e4939c738faf442c7e86671d18777f8
Differentiate between "IMSI unknown" and "IMSI has no auth data": in case of
known IMSI lacking auth data, return -ENOKEY instead of -ENOENT.
Fix API doc comments to reflect what the functions actually return, on top of
adding the -ENOKEY detail.
Adjust db_test expectations from -ENOENT to -ENOKEY where appropriate.
Adjust VTY and CTRL command rc evaluation.
A subsequent patch will use these return values to log details on each of these
situations.
Change-Id: Icf6304d23585f2ed45e050fa27c787f2d66fd3f7
Check *subscr->imsi, not subscr->imsi, since it is a char[]; same as msisdn
below already does.
Was introduced in change I42b3b70a0439a8f2e4964d7cc31e593c1f0d7537 / commit
183e7009af.
Fixes: coverity CID 178166
Change-Id: I72e13efefbac0495b8dd1949a39fa44ebfd46b56
Implement VTY commands for subscriber manipulation:
- create / delete subscriber
- modify MSISDN
- add/edit/remove 2G and 3G authentication data
- show by IMSI, MSISDN or DB ID.
(enable/disable CS/PS and purge/unpurge to follow later.)
Implement VTY unit tests for the new commands using new
osmo_verify_transcript_vty.py from osmo-python-tests.
Depends: libosmocore I1e94f5b0717b947d2a7a7d36bacdf04a75cb3522
osmo-python-tests Id47331009910e651372b9c9c76e12f2e8964cc2c
Change-Id: I42b3b70a0439a8f2e4964d7cc31e593c1f0d7537