laforge has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/28141 )
Change subject: RAN_Emulation: f_ran_unregister_imsi complement for f_ran_register_imsi
......................................................................
RAN_Emulation: f_ran_unregister_imsi complement for f_ran_register_imsi
We have a function to register an IMSI but we're missing a function
to unregister it from RAN_Emulation. This will cause resource leaks
and eventually an overflow of the ImsiTable. We don't notice this yet
as we don't have long enough running tests in the test suite yet.
Change-Id: I1f5d86c999d4495d661166f98183dfbc48f05f47
---
M library/RAN_Emulation.ttcnpp
1 file changed, 28 insertions(+), 2 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-ttcn3-hacks refs/changes/41/28141/1
diff --git a/library/RAN_Emulation.ttcnpp b/library/RAN_Emulation.ttcnpp
index e6d36e6..3198ee1 100644
--- a/library/RAN_Emulation.ttcnpp
+++ b/library/RAN_Emulation.ttcnpp
@@ -1254,7 +1254,10 @@
f_create_imsi(imsi, tmsi, vc_hdlr);
PROC.reply(RAN_register_imsi:{imsi, tmsi, vc_hdlr}) to vc_hdlr;
}
-
+ [] PROC.getcall(RAN_unregister_imsi:{?,?}) -> param(imsi, vc_hdlr) {
+ f_destroy_imsi(imsi, vc_hdlr);
+ PROC.reply(RAN_unregister_imsi:{imsi, vc_hdlr}) to vc_hdlr;
+ }
}
}
@@ -1287,6 +1290,7 @@
/* procedure based port to register for incoming IMSI/TMSI */
signature RAN_register_imsi(in hexstring imsi, in OCT4 tmsi, in RAN_ConnHdlr hdlr);
+signature RAN_unregister_imsi(in hexstring imsi, in RAN_ConnHdlr hdlr);
/* If DTAP happens across other channels (e.g. GSUP), provide manual advancing of the n_sd sequence number */
signature RAN_last_n_sd(in RAN_ConnHdlr hdlr, out N_Sd_Array last_n_sd);
@@ -1295,7 +1299,7 @@
signature RAN_continue_after_n_sd(N_Sd_Array last_n_sd, in RAN_ConnHdlr hdlr);
type port RAN_PROC_PT procedure {
- inout RAN_register, RAN_register_imsi, RAN_register_handoverRequest, RAN_last_n_sd, RAN_continue_after_n_sd;
+ inout RAN_register, RAN_register_imsi, RAN_unregister_imsi, RAN_register_handoverRequest, RAN_last_n_sd, RAN_continue_after_n_sd;
} with { extension "internal" };
#ifdef RAN_EMULATION_BSSAP
@@ -1425,6 +1429,19 @@
testcase.stop("No space left in ImsiTable");
}
+private function f_destroy_imsi(hexstring imsi, RAN_ConnHdlr hdlr)
+runs on RAN_Emulation_CT {
+ for (var integer i := 0; i < sizeof(ImsiTable); i := i+1) {
+ if (ImsiTable[i].imsi == imsi and ImsiTable[i].comp_ref == hdlr) {
+ ImsiTable[i].comp_ref := null;
+ ImsiTable[i].imsi := omit;
+ ImsiTable[i].tmsi := 'FFFFFFFF'O;
+ log("Removed IMSI[", i, "] for ", imsi, " to be handled at ", hdlr);
+ return;
+ }
+ }
+ testcase.stop("Unable to find to-be-destroyed IMSI in ImsiTable");
+}
private function f_expect_table_init()
runs on RAN_Emulation_CT {
@@ -1451,6 +1468,15 @@
}
}
+/* helper function for clients to register their IMSI/TMSI */
+function f_ran_unregister_imsi(hexstring imsi)
+runs on RAN_ConnHdlr {
+
+ BSSAP_PROC.call(RAN_unregister_imsi:{imsi, self}) {
+ [] BSSAP_PROC.getreply(RAN_unregister_imsi:{?,?}) {};
+ }
+}
+
/* register an expect with the BSSMAP core */
function f_ran_register_exp(octetstring l3_enc) runs on RAN_ConnHdlr {
BSSAP_PROC.call(RAN_register:{l3_enc, self}) {
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/28141
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: I1f5d86c999d4495d661166f98183dfbc48f05f47
Gerrit-Change-Number: 28141
Gerrit-PatchSet: 1
Gerrit-Owner: laforge <laforge(a)osmocom.org>
Gerrit-MessageType: newchange
laforge has submitted this change. ( https://gerrit.osmocom.org/c/osmo-msc/+/28130 )
Change subject: db: Switch from 'synchronous = FULL' to 'synchronous = NORMAL'
......................................................................
db: Switch from 'synchronous = FULL' to 'synchronous = NORMAL'
As we're using WAL mode, it is not neccessary to use synchronous=FULL
but rely on synchronous=NORMAL mode while still guaranteeing database
consistency.
To do this, we can fix the typo in one of our two PRAGMA statements,
and remove the other.
See https://www.sqlite.org/pragma.html#pragma_synchronous for the
sqlite3 documentation on that topic.
Change-Id: Ie782f0fe90e7204c4d55cdb3948b728c348367d1
Closes: OS#5566
RelateD: OS#5564, OS#5563
---
M src/libmsc/db.c
1 file changed, 1 insertion(+), 10 deletions(-)
Approvals:
Jenkins Builder: Verified
fixeria: Looks good to me, but someone else must approve
laforge: Looks good to me, approved
pespin: Looks good to me, but someone else must approve
diff --git a/src/libmsc/db.c b/src/libmsc/db.c
index 000002a..07081d5 100644
--- a/src/libmsc/db.c
+++ b/src/libmsc/db.c
@@ -562,7 +562,7 @@
}
char *err_msg;
- rc = sqlite3_exec(g_dbc->db, "PRAGMA journal_mode=WAL; PRAGMA synchonous = NORMAL;", 0, 0, &err_msg);
+ rc = sqlite3_exec(g_dbc->db, "PRAGMA journal_mode=WAL; PRAGMA synchronous = NORMAL;", 0, 0, &err_msg);
if (rc != SQLITE_OK) {
LOGP(DDB, LOGL_ERROR, "Unable to set Write-Ahead Logging: %s\n", err_msg);
sqlite3_free(err_msg);
@@ -617,13 +617,6 @@
return 0;
}
-static int db_configure(struct db_context *dbc)
-{
- const char *sync_stmts[] = { "PRAGMA synchronous = FULL" };
-
- return db_run_statements(dbc, sync_stmts, ARRAY_SIZE(sync_stmts));
-}
-
int db_prepare(void)
{
unsigned int i;
@@ -642,8 +635,6 @@
return -1;
}
- db_configure(g_dbc);
-
/* prepare all SQL statements */
for (i = 0; i < ARRAY_SIZE(g_dbc->stmt); i++) {
rc = sqlite3_prepare_v2(g_dbc->db, stmt_sql[i], -1,
--
To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/28130
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-msc
Gerrit-Branch: master
Gerrit-Change-Id: Ie782f0fe90e7204c4d55cdb3948b728c348367d1
Gerrit-Change-Number: 28130
Gerrit-PatchSet: 2
Gerrit-Owner: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: merged
Attention is currently required from: laforge.
Hello Jenkins Builder,
I'd like you to reexamine a change. Please visit
https://gerrit.osmocom.org/c/osmo-msc/+/28136
to look at the new patch set (#5).
Change subject: smpp: Parse and use SMPP-provided validity period
......................................................................
smpp: Parse and use SMPP-provided validity period
Before this patch, we always ignored any SMPP-provided validity period
and used '0' which is now, and means it expires immediately.
As SMPP allows for validity_period of NULL, use 7 days as SMSC default
in such situations.
Change-Id: Iad9f2697f045ed3bc0eb74c3a9730861f82e6c48
Closes: OS#5567
---
M configure.ac
M src/libmsc/smpp_openbsc.c
M src/libmsc/smpp_smsc.h
M src/libmsc/smpp_utils.c
M tests/smpp/smpp_test.c
M tests/smpp/smpp_test.ok
6 files changed, 165 insertions(+), 2 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-msc refs/changes/36/28136/5
--
To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/28136
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-msc
Gerrit-Branch: master
Gerrit-Change-Id: Iad9f2697f045ed3bc0eb74c3a9730861f82e6c48
Gerrit-Change-Number: 28136
Gerrit-PatchSet: 5
Gerrit-Owner: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-MessageType: newpatchset