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
Send updated subscriber data out to exactly those GSUP clients that match the
last LU operations (depending on each client sending distinct identification).
As this adds logging on DLGSUP, also change adjacent GSUP related logging from
DMAIN to DLGSUP.
Related: OS#2785
Change-Id: I7c317de8329d9a115d072fc61ddb9abc21b7e8d8
As we don't store any SS related information (e.g. call forwarding
preferences) in the database, we don't handle 'structured' SS
requests at all. Let's reject them by sending error message
with FACILITY_NOT_SUPPORTED code.
Change-Id: Ia1317c5d372a42473cce65c0c985103e43be77fd
Related: OS#3651
Store the GSUP client's IPA_IDTAG_SERNR in vlr_number or sgsn_number (depending
on is_ps), just before sending the Insert Subscriber Data message after a
successful LU Req. Log about it.
Original patch: Ib2611421f3638eadc361787af801fffe9a34bd8a by laforge
Related: OS#2796
Change-Id: If438664faa5d68404f465f8b2002c6d03bbf3ceb
To be able to handle our 20 chars long IPA tags, enlarge the vlr_number and
sgsn_number storage in struct hlr_subscriber.
Technically, osmo-hlr should be able to store any type of Global Title, blob of
arbitrary size. For our purposes, 32 is enough for now.
Related: OS#2796
Change-Id: I0121f1c4dbda3a076d780a3834281b21dab85493
A missing 'else' in rx_upd_loc_req() causes *all* clients to be indicated as
is_ps=true regardless of the GSUP CN Domain IE that was received.
Replace that odd if cascade with a switch() that fixes the flawed logic. Hence
osmo-hlr now correctly indicates each client's is_ps, iff the client sends CN
Domain IEs in GSUP LU Request messages.
Related: OS#2796, OS#3601
Change-Id: I2c5fa9f5cae25cfd66afbf088303edff7d045a00
Before this patch, the default route logic was not implemented. The
user could specify a default-route, but it wouldn't be used by the
actual routing logic. Let's fix that.
Change-Id: I0b04a75dc297f088f13da413d08c52e0747e46e6
According to GSM TS 03.38, section 6.1.2.1, CR symbol at the end
is optional, and moreover libosmogsm encoding API will carry
about the bit padding itself.
Change-Id: I09e8a67758698f3b7a578eab956311e269d091ee
We need to distinguish between both EUSE and IUSE, and properly
print their names. Otherwise, garbage is printed in case of IUSE.
Change-Id: I497e7c1fe41279afdb1256ee69e166066a6462bb
There are some requests that are best served inside the HLR, as it
has access to subscriber information such as MSISDN and IMSI.
This unfortunately required quite some restructuring of the USSD
related structures including the VTY syntax for adding routes.
The default config file has been updated to replicate the *#100#
built-in behavior of old OsmoNITB.
Closes: OS#2566
Change-Id: I1d09fab810a6bb9ab02904de72dbc9e8a414f9f9
This is a small program which simply echo's the USSD request message it
gets in a quote back to the sender. Its purpose is to illustrate how
EUSEs can be implemented using libosmo-gsup-client.
Change-Id: I3fb8554ca329cb609c591058254117006f665e73
We don't want any SS session to run for more than 30s. The timeout
is currently not refreshed.
If we need more comprehensive timeout handling, using osmo_fsm for SS
sessions might make sense.
Change-Id: I5c9fb6b619402d2a23fea9db99590143d85ac11a
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
Thanks to ASAN, it was discovered that some part of heap
is not released on exit:
==19736==ERROR: LeakSanitizer: detected memory leaks
Indirect leak of 94616 byte(s) in 214 object(s) allocated from:
#0 0x4e05c6 (/home/wmn/osmocom/osmo-hlr/src/osmo-hlr+0x4e05c6)
#1 0x7f9b01061dc6 (/usr/lib/x86_64-linux-gnu/libsqlite3.so.0+0x33dc6)
Indirect leak of 1160 byte(s) in 1 object(s) allocated from:
#0 0x4e097d (/home/wmn/osmocom/osmo-hlr/src/osmo-hlr+0x4e097d)
#1 0x7f9b01061d58 (/usr/lib/x86_64-linux-gnu/libsqlite3.so.0+0x33d58)
SUMMARY: AddressSanitizer: 95776 byte(s) leaked in 215 allocation(s).
After a long investigation, it was figured out that *sqlite never
closes the database* due to 'unfinalized statements or unfinished
backups'.
The problem was in db_bootstrap(), where several statements were
prepared, but not finalized in loop. This was also the reason of
*.db-shm / *.db-wal files remaining after the program is closed,
and the reason of the following message
db.c:77 (283) recovered 18 frames from WAL file *.db-wal
Let's fix this and stop ignoring the result of sqlite3_close().
Change-Id: Ibe620d7723b1947d4f60f820bd18435ad0193112
Related: OS#3434
As we're moving this to a common/shared library now, we need to use
the osmo_ namespace prefix for symbol names, struct/type names and
constants.
Change-Id: I294f8f96af4c5daa2b128962534426e04909290e
This imports the code from osmo-msc 6afef893e17bce67e4d4119acd34d480ed03ba77
with minimal changes to make it compile. Symbol renaming ot osmo_
prefix is done separately in a follow-up patch to have a as-clean-as-possible
import first.
Requires: libosmocore.git Change-Id Ie36729996abd30b84d1c30a09f62ebc6a9794950
Change-Id: Ief50054ad135551625b684ed8a0486f7af0b2940
Tracking NULL memory contexts allows one to detect memory chunks
allocated outside the application's root context, which in most
cases are the result of some mistake.
For example, the VTY implementation still uses the NULL context,
so we have to clean up it manually until this is fixed.
At the moment we have at least one chunk allocated outside the
application's root context (excluding the VTY context):
full talloc report on 'null_context' (total 24 bytes in 2 blocks)
struct lookup_helper contains 24 bytes in 1 blocks
Change-Id: I7ea86730e090c06b2a5966ae4d04b8144b1cd20a
This makes both ASAN and Valgrind happy, because they do expect
all allocated heap chunks to be released on exit.
Change-Id: I7345dec8d06b0b71a859c16132dc0008cfe17cba
There were a few lines of dead code below the osmo_select_main()
loop, while the actual deinitialization code was a part of SIGINT
handler. Let's reanimate this dead zone by moving the code there
and introducing a global 'loop-breaker' variable.
Change-Id: I0e2d673b420193e2bdc1a92377aca542f3a19229
During the attempt to fix OS#2785 in Change-Id
I6a92ca34cdaadca9eacc774bb1ca386c325ba865, we introduced logic that
would blindly insert a subscriber *concurrently* in all VLRs/SGSNs of
the network on any update of the subscriber.
Before that patch, we didn't update the current serving SGSN/VLR,
and after the change we created subscribers in all SGSNs/VLRs, of which
all-1 are not serving the subscriber at that time.
We'll have to go back to the original behavior until a proper fix can
be introduced.
Change-Id: Ibf6f1b21b08560d4d8f41bbe7782d40abf4585f8
Related: OS#3091
Related: OS#2785
Move code to create an Insert Subscriber Data message into a common
function which can be shared by hlr.c and luop.c.
As a consequence, we always encode gsup.cn_domain in the corresponding
msgb and must adjust expected output of the 'gsup' test accordingly.
Change-Id: I6a92ca34cdaadca9eacc774bb1ca386c325ba865
Requested-by: neels
Related: OS#2785
Encode an Insert Subscr Data with is_ps == true to trigger the encoding bug
described in OS#3231, i.e. show that it is fixed.
Move osmo_gsup_addr_send() to a separate .c file, so that it can be overridden
in the regression test to just dump the msgb instead.
I used this test to reproduce issue OS#3231, and now that it's here we might as
well keep it, and possibly expand on it in the future.
Related: OS#3231
Change-Id: Id1453351758f3e1a9ff03bd99fefaf51886e77da
In osmo_gsup_configure_wildcard_apn(), do not compose APN into a local buffer
that becomes invalid as soon as the function exits. Instead, use a caller
provided buf.
Fixes OS#3231 crash:
==20030==ERROR: AddressSanitizer: stack-buffer-underflow on address 0x7fffffffd9c0 at pc 0x7ffff6e9b6c2 bp 0x7fffffffd900 sp 0x7fffffffd0b0
READ of size 2 at 0x7fffffffd9c0 thread T0
#0 0x7ffff6e9b6c1 (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x766c1)
#1 0x7ffff6314419 in tlv_put ../../../../src/libosmocore/include/osmocom/gsm/tlv.h:107
#2 0x7ffff6314419 in msgb_tlv_put ../../../../src/libosmocore/include/osmocom/gsm/tlv.h:299
#3 0x7ffff6314419 in encode_pdp_info ../../../../src/libosmocore/src/gsm/gsup.c:419
#4 0x7ffff6314419 in osmo_gsup_encode ../../../../src/libosmocore/src/gsm/gsup.c:535
#5 0x555555580016 in _luop_tx_gsup ../../../src/osmo-hlr/src/luop.c:54
#6 0x5555555809d8 in lu_op_tx_insert_subscr_data ../../../src/osmo-hlr/src/luop.c:264
#7 0x55555558b356 in rx_upd_loc_req ../../../src/osmo-hlr/src/hlr.c:306
#8 0x55555558b356 in read_cb ../../../src/osmo-hlr/src/hlr.c:365
#9 0x555555586671 in osmo_gsup_server_read_cb ../../../src/osmo-hlr/src/gsup_server.c:105
#10 0x7ffff5b35911 in ipa_server_conn_read ../../../src/libosmo-abis/src/input/ipa.c:356
#11 0x7ffff5b35911 in ipa_server_conn_cb ../../../src/libosmo-abis/src/input/ipa.c:387
#12 0x7ffff5e5541f in osmo_fd_disp_fds ../../../src/libosmocore/src/select.c:216
#13 0x7ffff5e5541f in osmo_select_main ../../../src/libosmocore/src/select.c:256
#14 0x5555555791b6 in main ../../../src/osmo-hlr/src/hlr.c:600
#15 0x7ffff4707a86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21a86)
#16 0x555555579679 in _start (/usr/local/bin/osmo-hlr+0x25679)
Address 0x7fffffffd9c0 is located in stack of thread T0 at offset 16 in frame
#0 0x7ffff63131ff in osmo_gsup_encode ../../../../src/libosmocore/src/gsm/gsup.c:481
This frame has 1 object(s):
[32, 64) 'bcd_buf' <== Memory access at offset 16 underflows this variable
Related: OS#3231
Change-Id: I83d9ef2868bbb01e3f1ddb7920fe735aca172b15
In rx_upd_loc_req() we set the connection's supports_ps field but
forgot to also set the equivalent field in the corresponding luop.
Change-Id: Ie175a067ac1324cdd39d7f756a40fab923421793
Related: OS#2785
This function relied on implementation details of the luop code.
Port what is necessary for an independent Insert Subscriber Data
Tx operation from the luop code into this function.
A next possible step would be to try to merge both of these
into a common implementation. This will be addressed in a
follow-up change as soon as this change is merged.
The TTCN3 test TC_vty_msisdn_isd is still passing (it currently
triggers the "circuit switched domain" case because it does not
advertise itself as an SGSN in the IPA unit name).
Change-Id: I06c43ece2b48dc63d599000eb6d6d51e08963067
Related: OS#2785
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
Use osmo_timer_setup() to set up the luop timer, instead of
settting the timer up manually.
Delete the timer before the luop is freed to prevent a potential
crash in case the timer is already armed and the function call
chain leading up to lu_op_free() does not cancel the timer.
Found while studying code to prepare work on issue OS#2785.
This change has been tested with 'make check' and TTCN3 HLR tests.
Related: OS#2785
Change-Id: I1a7596675b2d94217895f0f3d3f67b86ef123c2e
Neels Hofmeyr
Harald Welte
Pau Espin